Known Error Management

Da itm wiki.

The known error management process is supported by a SM workflow cartridge that enables the execution of the process.

Of course the preconfigured process (the workflow cartridge) is just an accelerator and the tuning / completion of the initial configuration will still be required. To this aim, the Workflow Engine guide may be useful.

IMPORTANT NOTE: the configuration below is only one of the possible configuration to deal with the known error management process. The need for a different behaviour of the process may be fulfilled by simple changes of the configuration.

Operational model

The preconfigured process has the objective to facilitate and support the management of known errors which provides a workaround to solve one or more incidents. At the core of the process configuration is the following operational model.

Known Error Management operational model

The technical teams member generate the known error proposals which are examined by the KE authority who decides if thy are valuable solutions to be published to the users. The criteria usually to be met to accept and publish a known error are usually the following:

  • it is the best suitable applicable workaround;
  • it is well written, according to the standard format and easy to understand;
  • all side effects are identified and described.

However, each organization may define its own criteria.

Roles

For this process, the following organizational roles are defined:

Organizational role Description itmSUITE® role mapping
Requester There are several technical teams predefined for different domains. The following table shows which users are members of each team and, therefore, requesters.
Domain Group Member

users

Application management "Application Management" "AppManager"

"AppSpecialist"

Personal devices management "Personal Management" "PersonalManager"

"PersonalSpecialist"

Network management "Network Management" "NetManager"

"NetSpecialist"

Server management "Server Management" "ServerManager"

"ServerSpecialist"

Additionally, the members of the group "Service Desk" and, specifically, the user "SDSpecialist" is enabled to this role.

KE owner
  • The KE owner follows the life cycle of the known error
  • He/she completes or prepares the workaround if not done by the requester
  • He/she verifies that the known error fulfils the acceptance criteria and submits it to the KE authority for approval
  • He/she complete corrects it according to the KE authority suggestions
  • Finally he/she closes the known error if this is not automatically done (by the closure of the related problem)
 Any requester may become KE owner. Usually, the group manager assigns it.
KE authority The group managers of the following groups, "Application Management", "Personal Management", "Network Management", "Server Management" are made part of "KE authority" group.
User Searches for a published known error and uses the associated workaround. Any user may play this role.

Process

As for all workflows, new service requests can be created by using the self service portal, accessible by means of Self Service menu.

The following requests which trigger a new instance of the request fulfilment process are configured and available to all organizational roles in the self service portal:

Self service topic Self service category Self service request Authorized roles
"Applications" "itmCLOUD" "Service Request" (open a service request) Requesters, service desk members, technical team members, service managers.
"Personal Devices" "Personal Computers" "Service Request" (open a service request) Requesters, service desk members, technical team members, service managers.
"Personal Devices" "Peripherals" "Service Request" (open a service request) Requesters, service desk members, technical team members, service managers.
"Personal Devices" "Telephony" "Service Request" (open a service request) Requesters, service desk members, technical team members, service managers.
"Network" "Networking Management" "Service Request" (open a service request) Requesters, service desk members, technical team members, service managers.
"Technical Services" "Server Management" "Service Request" (open aservice request) Requesters, service desk members, technical team members, service manager.

A workflow is configured to support the request fulfilment process. The workflow is characterized by workflow statuses and workflow transitions. The figure below illustrates the process.

Incident management process.

The table below explains the meaning of each workflow status.

Workflow status Description
"Default" A preliminary status which is displayed when an service request is created.
"Opened" The service request has been recorded and activities to fulfil it started.
"In Charge" The service desk has taken the service request in charge and started to work on it directly or by routing to other teams.
"Resolved" A service request has been fulfilled.
"Suspended" The activities to fulfil the service request are suspended.
"Cancelled" The service request has been rejected or has not been confirmed.
"Closed" The service request closure has been confirmed. No other changes are possible.

And finally the table below explains the roles authorized to execute the workflow transitions.

Source status Destination status Authorized executors Comment
"Default" "Opened" Requesters, service desk members, technical team members, service managers. See the self service portal configuration previously described.
"Opened" "In Charge" Service desk member Service desk members are configured through master solution group.
"Opened" "Cancelled" Creator or Service desk member Service desk members are configured through master solution group.
"In Charge" "Resolved" Service desk member or Technical team member Technical team members are configured through solution group.

Service desk members are configured through master solution group.

"In Charge" "Suspended" Service desk member or Technical team member Technical team members are configured through solution group.

Service desk members are configured through master solution group.

"In Charge" "Cancelled" Service desk member Service desk members are configured through master solution group.
"Resolved" "Closed" Creator or Service desk member Service desk members are configured through master solution group.
"Resolved" "In Charge" Creator or Service desk member Service desk members are configured through master solution group.
"Suspended" "In Charge" Service desk member or Technical team member Technical team members are configured through solution group.

Service desk members are configured through master solution group.

Related processes

Several other IT Service Management processes are related to the request fulfilment one. Some basic interfaces are provided. The tab Related Items of the request and, in particular, the sub tab Tickets of it allows to view all the existing between the service request and other processes (managed through tickets).

Change management

It is possible to create a new change, managed via the change management process. The GENERATE CHANGE command allows to instantiate a new change by copying some service request information and by creating a relationship between the service request and the generated change.

Asset management and configuration management

It is possible to relate configuration items to a service request by using the tab Related Items and, in particular, the sub tab Configuration Items. The ASM and/or CMS modules features are made available here (e.g. view of configuration item details, configuration exploration or impact analysis).

Release and deployment management

A release may include the solution of one or more service requests. The relationship between a release and a service request is more frequently created working on the release. In any case, this can be also done from the tickets tab Related Items and, in particular, the sub tab Configuration Items by using the ADD EXISTING or SELF SERVICE commands.

Services

Different services are configured for different service requests domain areas as illustrated in the following table.

Service requests domain areas Service Service manager
Application management Only one application, and the related service ("itmCLOUD") is configured. The user "servicemanager" is configured as service manager.
Personal devices management "Personal Device Management". The user "personalmanager" is configured as service manager.
Network management "Network Management" The user "netmanager" is configured as service manager.
Server management "Server Management" The user "servermanager" is configured as service manager.

Management information

Many management information are available as fields in the service request management configured form. The following table illustrates the intended use of key information and its behaviour. NOTE: information are available (visible) and can be modified according to a specific configuration which is meant to be suitable for the organizational roles involved in the process.

Information group or tab Field Purpose Comments
General Information Ticket Op Status To show the operational status of the service request, see workflow statuses in Process section of this page. Status changes are performed by means of the Save&Next command.
General Information Request Name Service desk members are configured through master solution group.
General Information Short Description To provide a short description of the service request. Always visible, can be managed according to workflow status and organizational roles.
General Information Requester To identify the name of the requester (who has experienced the service requestt). A list is presented, influenced by.... TBC
General Information Creation Date To show the date and time the service request was created. This information is automatically recorded and cannot be manually changed. See History tab for more detailed tracking information.
General Information Edit Date To show the date and time the service request was last updated. This information is automatically recorded and cannot be manually changed. See History tab for more detailed tracking information.
General Information Creation User To show the user who created the service request. This information is automatically recorded and cannot be manually changed. See History tab for more detailed tracking information.
General Information Edit User To show the user who updated the service request last. This information is automatically recorded and cannot be manually changed. See History tab for more detailed tracking information.
Ticket Classification Project/Service To show the service (or project) to which the service request is related. This is automatically set at open time and can't be modified.
Ticket Classification Ticket Type To show the type of workflow executed. This is automatically set at open time and can't be modified.
Ticket Classification Ticket Area Ticket Category Ticket Topic To set the service request key classification information..This is used for statistic reasons but also to drive the best possible routing of the service request to the suitable technical team in order to analyze and/or solve it. The classification information is managed through these three related fields..The selection of a value of the Ticket Area will influence the values of the Ticket Category which finally is influencing the values of Ticket Topic.The values defined influence the Solution Group field. The available values and the corresponding driven team configuration can be changed.
Prioritisation & Planning User Priority To provide the priority given to the service request by the Requester. A four level scale is set but it can be changed.
Prioritisation & Planning Ticket Priority To assign the priority to the service request. A four level scale is set but it can be changed.
Prioritisation & Planning Forecast Solution Date To define the expected fulfilment date and time for the service request.
Ownership and Groups Master SG To define the supervising and first line support team. The "Service Desk" is automatically set as master solution group at open time and cannot be changed.
Ownership and Groups Solution Group To define the team to which the service request is assigned for analysis and/or fulfilment. The team may change during the service request lifecycle.
Ownership and Groups Owner To define who is the request owner who should monitor the lifecycle of the service request. The request owner is automatically set to the resource who takes in charge the service request. He/she can be changed by the service desk members to another member of the service desk.
Ownership and Groups Ticket Worker To set the resource who shall work in order to analyse and/or fulfil the service request. If the analysis is performed by the request owner, the Ticket Worker is normally not set. He/she is a member of the team defined in the Solution Group field. However setting him/her is not mandatory. Alternatively, it is possible to assign specific tasks to resources by using the Ticket Activities tab.
Ticket Details Description To provide a more detailed description of the service request. An auto tracking field is used enabling to view the user who has updated.
Ticket Details Fulfilment To provide any information about the what and how for the fulfilment of the service request. This field is only visible to service desk and technical team members.

An auto tracking field is used enabling to view the user who has updated.

Ticket Details Comments To provide comments helpful for the fulfilment of the service requet or for future memory (es. continual improvement).. This field is only visible to service desk and technical team members.

An auto tracking field is used enabling to view the user who has updated.

Ticket Details Comments for Requester To provide comments to the requester of the service request. An auto tracking field is used enabling to view the user who has updated.

This field is not the only way to interact with the requester. To this aim messages, manage via the Messages tab, can be very useful

Fields can be mandatory to save the service request in some workflow statuses. These fields are highlighted with a red asterisk.

Views

The following views are made available in the Tickets area of the home page:

View Content Requester Service desk Technical team
Requests resolved Service requests in status "Resolved". X
Requests opened Service requests in status "Opened". X
Requests owned Service requests in status "Opened", "In Charge" and "Resolved" where Owner is the logged resource. X
Requests routed to my team Service requests in status "In Charge" where Solution Group is the solution group to which the logged resource belongs to. X X
Reuests assigned to me Service requests in status "In Charge" where the Ticket Worker is the logged resource. X X

Additionally, the following views are made available in the Service Request menu for all the organizational roles:

View Content
Requests active Service requests in status "Opened", "In Charge", "Resolved"
Requests suspended Service requests in status "Suspended
Requests closed Service requests in status "Closed"
Requests cancelled Service requests in status "Cancelled"

Notifications

The following notifications are configured:

Trigger Recipients Purpose
A service request is opened Solution group members of "Service Desk" Alert that there is a service request to manage.
A service request is taken in charge The service request creator Alert that someone has started to work on the service request.
A service request is resolved The service requestt creator Alert that the service request is resolved.
A solution group is assigned or changed for the service request Solution group manager Alert that there is a resource to allocate to manage the service request.
A ticket worker is assigned The assigned ticket worker Alert that there is work to be done.
A service requestt is suspended The service request creator Alert that the service request is suspended.
A service request is closed Solution group members of "Service Desk" Alert that the service request has been closed.
A service request is cancelled The service request creator Alert that the service request has been cancelled.

Reporting

A set of standard reports are made available for the request fulfilment process. It is not required to have the REP module to use them, however the module is required if new or changed reports are needed. The available reports are placed under Service Request/Reporting menu.

The following table lists the reports available by default and their visibility:

Report name Content Access
Servicve Requests per priority - trend An histogram showing the service request volumes per priority monthly trend. Service desk and technical team members.
Service Requests per priority - volume A pie containing the split of service requests per priority. Service desk and technical team members.
Service Requests per service - trend An histogram showing the service request volumes per service monthly trend. Service desk and technical team members.
Service Requests per service - volume A pie containing the split of service requests per service. Service desk and technical team members.
Service Requests per service/priority - volume An histogram showing the service requests volume per service and priority. Service desk and technical team members.
Service Requests - in charge time A pie showing the percentage of service requests respecting the target defined for the take "In charge time"* objective (the time elapsed from the "Opened" to the "In Charge" workflow status. Service desk and technical team members.
Service Requests per priority - resolution time An histogram showing, per priority, the percentage of service requests respecting the target defined for the "Resolution time"* objective (the time elapsed from the "In Charge" to the "Resolved" workflow status. Service desk and technical team members.

* "In charge time" and "Resolution time" objectives are defined within the OCE module.

A basic form of reporting is also provided by views. Views basically allow to list service requests and their attributes but may also be configured to calculates sums, averages on some of them. The available views are illustrated in the dedicated section of this page.

Examples of use

In this section some examples of use of the configured request fulfilment process are given.

If you get lost, any time use the EXPLORE WORKFLOW command of the service request management form. This enables to view the status of the workflow as shown in the figure below. By clicking on a relationship between workflow statuses, roles and users enabled to perform it are presented.

Explore Workflow window

NOTE: the EXPLORE WORKFLOW command is available only if the ticket is first saved.

For more information on how to use any workflows, including incident management, please refer to the workflow execution guide.

Create a new service request as a final user

  1. Login as "finaluser" user
  2. Activate the Self Service menu
  3. Choose a self service topic, self service category and finally "Service Request" as self service request (this determines the creation of a new service request)
  4. Fill the service request form, at least with mandatory form and save with the SAVE command

You have now saved the service request, take note of the ticket number for further reference or use.

Take in charge a service request as service desk member

  1. Login as "sdspecialist" (therefore a service desk member)
  2. Open the the desired service request; you can do it quickly either by
  3. Take in charge the service request by

The incident is now in workflow status "In Charge".

Resolve a service request as service desk member

  1. Login as "sdspecialist" (therefore a service desk member)
  2. Open the the desired service request; you can do it quickly either by
  3. Update service request information (at least fill mandatory fields for resolution, Analysis and Solution)
  4. Set the incident in "Resolved" workflow status
    • Press the SAVE & NEXT command
    • Choose the "1. Resolve" workflow transition and press the APPLY & SAVE command

The incident is now in workflow status"Resolved".

Route a service request to a technical team

  1. Login as "sdspecialist" (therefore as a service desk member)
  2. Open the the desired service request; you can do it quickly either by
  3. Update Solution Group field with the technical team you want to assign
  4. Save with the SAVE command

At step 3, you might also want to set a specific member among those of the select technical team by defining the Ticket Worker.

Take in charge a service request as a technical team member

  1. Login as a technical team member (for available logins, refer to the Role section of this page)
  2. Open the the desired service request; you can do it quickly either by
  3. Press SET ME AS TICKET WORKER command
  4. Press SAVE command

Close a service request as a final user

  1. Login as "finaluser"
  2. Open the the desired service request; you can do it quickly either by
  3. Close the service request by

The incident is now in workflow status "Closed".

Estratto da "http://wiki.itmsuite.eu/index.php?title=Known_Error_Management&oldid=1150"