Differenze tra le versioni di "Incident Management"

Da itm wiki.
(Roles)
(Etichetta: visualeditor)
(Etichetta: visualeditor)
 
(4 versioni intermedie di un altro utente non mostrate)
Riga 10: Riga 10:
 
[[File:Incident Management Operational Model v1.0.JPG|centre|thumb|500x500px|Incident Management operational model]]
 
[[File:Incident Management Operational Model v1.0.JPG|centre|thumb|500x500px|Incident Management operational model]]
  
The requester requires to open an ''[[Glossary|incident]]'' by contacting the s''[[Glossary|ervice desk]]''. One of the members of the [[Glossary|s''ervice desk'']] takes the request in charge,
+
The requester requires to open an ''[[Glossary|incident]]'' by contacting the [[Glossary|s''ervice desk'']]. One of the members of the [[Glossary|s''ervice desk'']] takes the request in charge,
  
 
becoming the owner of it, and starts to manage it. The owner may find a ''[[Glossary|workaround]]'' (which is published through the ''[[Glossary|known error management]]'' process) and/or solution for the ''[[Glossary|incident]]'' and, therefore, may close it. Alternatively, the owner may not be able to find any solution or ''[[Glossary|workaround]]'' and may need to involve technical staff to investigate and find it. In such a case, he/she will route to the technical staff the ''[[Glossary|incident]]'', still remaining accountable for it. In other words, the [[Glossary|service desk]] always acts as a single point of contact (SPOC) for the requester.   
 
becoming the owner of it, and starts to manage it. The owner may find a ''[[Glossary|workaround]]'' (which is published through the ''[[Glossary|known error management]]'' process) and/or solution for the ''[[Glossary|incident]]'' and, therefore, may close it. Alternatively, the owner may not be able to find any solution or ''[[Glossary|workaround]]'' and may need to involve technical staff to investigate and find it. In such a case, he/she will route to the technical staff the ''[[Glossary|incident]]'', still remaining accountable for it. In other words, the [[Glossary|service desk]] always acts as a single point of contact (SPOC) for the requester.   
Riga 50: Riga 50:
 
* Watches over and monitors the ''[[Glossary|incident]] ''along all its life cycle ensuring target service levels are achieved
 
* Watches over and monitors the ''[[Glossary|incident]] ''along all its life cycle ensuring target service levels are achieved
 
* Checks the implemented resolution and sets the ''[[Glossary|incident]] ''to resolved
 
* Checks the implemented resolution and sets the ''[[Glossary|incident]] ''to resolved
* If needed, closes the ''[[Glossary|incident]]''
+
* If needed (the requester doesn't do it), closes the ''[[Glossary|incident]]''
 
|| The role is set to the service desk member who takes in charge the incident.   
 
|| The role is set to the service desk member who takes in charge the incident.   
 
   
 
   
 
|-
 
|-
 
| Technical team member  ||  
 
| Technical team member  ||  
* He/she receives the notification on the assignment of an activity concerning an ''[[Glossary|incident]] ''(e.g. conducting the analysis and finding to find a resolution or ''[[Glossary|workaround]] ''for it)
+
* He/she receives the notification on the assignment of an activity concerning an ''[[Glossary|incident]] ''(e.g. conducting the analysis and finding a resolution or ''[[Glossary|workaround]] ''for it)
  
 
* Carries out the assigned tasks
 
* Carries out the assigned tasks
Riga 87: Riga 87:
 
* Receives the notification on the assignment of the ''[[Glossary|incident]] ''to his/her team in order to find a resolution or ''[[Glossary|workaround]] ''for it
 
* Receives the notification on the assignment of the ''[[Glossary|incident]] ''to his/her team in order to find a resolution or ''[[Glossary|workaround]] ''for it
 
* Assign the member of his/her team who should work on it (this can be done by setting the ''[[Glossary|ticket worker]]'' or creating and assigning ''[[Glossary|ticket activities]]'')
 
* Assign the member of his/her team who should work on it (this can be done by setting the ''[[Glossary|ticket worker]]'' or creating and assigning ''[[Glossary|ticket activities]]'')
* Watches over and monitors the work of his team
+
* Watches over and monitors the work of his/her team
 
|| There are several technical teams predefined for different domains. The following table shows which ''[[Glossary|users]]'' are set as ''[[Glossary|solution group manager]]'' for each domain.
 
|| There are several technical teams predefined for different domains. The following table shows which ''[[Glossary|users]]'' are set as ''[[Glossary|solution group manager]]'' for each domain.
  
Riga 283: Riga 283:
  
 
|-
 
|-
| <u>''Ticket Classification''</u> || <u>Project/Service</u> || To show the ''[[Glossary|service]]'' (or [[Glossary|''project'']]) to which the ''[[Glossary|incident]]'' is related. ||This is automatically set at open time and can't be modified.
+
| <u>''Ticket Classification''</u> || <u>Project/Service</u> || To show the ''[[Glossary|service]]'' (or [[Glossary|''project'']]) to which the ''[[Glossary|incident]]'' is related. ||This is automatically set at open time.
  
 
|-
 
|-

Versione attuale delle 15:41, 26 giu 2015

Incident Management process is supported by a SM workflow cartridge that enables the execution of the process according to the ITIL and ISO/IEC 20000 guidelines.

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 incident 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 resolution of incidents or the provision of workarounds. At the core of the process configuration is the following operational model.

Incident Management operational model

The requester requires to open an incident by contacting the service desk. One of the members of the service desk takes the request in charge,

becoming the owner of it, and starts to manage it. The owner may find a workaround (which is published through the known error management process) and/or solution for the incident and, therefore, may close it. Alternatively, the owner may not be able to find any solution or workaround and may need to involve technical staff to investigate and find it. In such a case, he/she will route to the technical staff the incident, still remaining accountable for it. In other words, the service desk always acts as a single point of contact (SPOC) for the requester.

Roles

For this process, the following organizational roles are defined:

Organizational role Description itmSUITE® role mapping
Requester
  • Opens incidents on behalf of himself/herself or for a third party
This role is mapped on a system resource with user of user type "Requester". The login identifier of this user is "FinalUser".
Service desk member
  • Also known as First Line Support, it is the Single Point of Contact (SPOC) for the requester
  • This group receives the notifications of all the incidents opened
  • One of the members decides to deal with the incident and takes the incident owner role
This role is mapped on a system resource with user of user type "Resource". The login identifier of this user is "SDSpecialist". The resource is also member of the "Service Desk" solution group which is set as master solution group.
Service desk manager The role is assigned to the service desk member, user "SDSpecialist", who is also member of the "Service Desk"solution group and is set as solution group manager for it.
Incident owner
  • Role taken on by someone who is part of  the service desk team
  • Offers initial support and attempts to resolve the incident
  • Activates escalation/ routing/ requests
  • Manages all the communications with the requester
  • Watches over and monitors the incident along all its life cycle ensuring target service levels are achieved
  • Checks the implemented resolution and sets the incident to resolved
  • If needed (the requester doesn't do it), closes the incident
The role is set to the service desk member who takes in charge the incident.
Technical team member
  • He/she receives the notification on the assignment of an activity concerning an incident (e.g. conducting the analysis and finding a resolution or workaround for it)
  • Carries out the assigned tasks
  • Notices when completed or unable to complete
There are several technical teams predefined for different domains. The following table shows which users are members of each team.
Domain Solution 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"

Technical team manager
  • Receives the notification on the assignment of the incident to his/her team in order to find a resolution or workaround for it
  • Assign the member of his/her team who should work on it (this can be done by setting the ticket worker or creating and assigning ticket activities)
  • Watches over and monitors the work of his/her team
There are several technical teams predefined for different domains. The following table shows which users are set as solution group manager for each domain.
Domain Solution group Solution group manager
Application management "Application Management" User "AppManager".
Personal devices management "Personal Management" User "Personal Manager".
Network management "Network Management" User "NetManager".
Server management "Server Management" User "ServerManager".
Service manager This role is mapped on a system resource with user of user type "Project/Service Manager". There are different service managers configured for specific services. See Services section in this page for further information.

Process

As for all workflows, new incidents 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 incident management 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" "Incident" (open an incident) Requesters, service desk members, technical team members, service managers.
"Personal Devices" "Personal Computers" "Incident" (open an incident) Requesters, service desk members, technical team members, service managers.
"Personal Devices" "Peripherals" "Incident" (open an incident) Requesters, service desk members, technical team members, service managers.
"Personal Devices" "Telephony" "Incident" (open an incident) Requesters, service desk members, technical team members, service managers.
"Network" "Networking Management" "Incident" (open an incident) Requesters, service desk members, technical team members, service managers.
"Technical Services" "Server Management" "Incident" (open an incident) Requesters, service desk members, technical team members, service manager.

A workflow is configured to support the Incident management 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 incident is created.
"Opened" The incident has been recorded and activities to resolve it started.
"In Charge" The service desk has taken the incident in charge and started to work on it directly or by routing to other teams.
"Resolved" A workaround or a definitive solution has been found.
"Suspended" The activities to analyse and solve the incident are temporarily suspended.
"Cancelled" The incident has not been rejected or has not been confirmed.
"Closed" The incident 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 incident management one. Some basic interfaces are provided. The tab Related Items of the incident and, in particular, the sub tab Tickets of it allows to view all the existing between the incident 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 incident information and by creating a relationship between the incident and the generated change.

Asset management and configuration management

It is possible to relate configuration items to an incident 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).

Problem management

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

Known error management

It is possible to create a new known error, managed via the known error management process. The GENERATE KE command allows to instantiate a new known error by copying some incident information and by creating a relationship between the incident and the generated knonw error.

Release and deployment management

A release may include the solution of one or more incidents even if this may happen rarely (more frequently a release includes changes generated to fix incidents and related to them, The relationship between a release and an incident is more frequently created working on the release. In any case, this can be 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 incident domain areas as illustrated in the following table.

Incidents 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 incident 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 incident, 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 incident. 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 incident). A list is presented, influenced by.... TBC
General Information Creation Date To show the date and time the incident 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 incident 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 incident. 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 incident 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 incident is related. This is automatically set at open time.
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 Security Incident To enter the information whether the incident is a security one or not. This is only an informational field.
Ticket Classification Ticket Area Ticket Category Ticket Topic To set the incident key classification information..This is used for statistic reasons but also to drive the best possible routing of the incident to the suitable technical team in order to analyse 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 incident by the Requester. A four level scale is set but it can be changed.
Prioritisation & Planning Ticket Urgency To define the urgency for the resolution by the service desk. A three level scale is set but it can be changed.
Prioritisation & Planning Ticket Impact To define the impact on the business of the incident by the service desk. A four level scale is set but it can be changed.
Prioritisation & Planning Ticket Priority To view the priority given to the incident by the Requester. The priority is automatically set based on Ticket Urgency and Ticket Impact. The driving matrix can be configured.
Prioritisation & Planning Forecast Solution Date To the expected resolution date and time for the incident.
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 incident is assigned for analysis and/or resolution. The team may change during the incident life cycle.
Ownership and Groups Owner To define who is the incident owner who should monitor the lifecycle of the incident. The incident owner is automatically set to the resource who takes in charge the incident. 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 resolve the incident. If the analysis is performed by the incident 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 incident. An auto tracking field is used enabling to view the user who has updated.
Ticket Details Analysis To provide the analysis of the cause(s) of the incident. 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 Solution To describe the solution applicable to the incident. 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 analysis and/or resolution of the incident or for future memory (e.g. 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 incident. 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 incident 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
Incidents resolved Incidents in status "Resolved". X
Incidents opened Incidents in status "Opened". X
Incidents owned Incidents in status "Opened", "In Charge" and "Resolved" where Owner is the logged resource. X
Incidents routed to my team Incidents in status "In Charge" where Solution Group is the solution group to which the logged resource belongs to. X X
Incidents assigned to me Incidents in status "In Charge" where the Ticket Worker is the logged resource. X X

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

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

Notifications

The following notifications are configured:

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

Reporting

A set of standard reports are made available for the incident management 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 Incident/Reporting menu.

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

Report name Content Access
Incident per priority - trend An histogram showing the incident volumes per priority monthly trend. Service desk and technical team members.
Incident per priority - volume A pie containing the split of incidents per priority. Service desk and technical team members.
Incident per service - trend An histogram showing the incident volumes per service monthly trend. Service desk and technical team members.
Incident per service - volume A pie containing the split of incidents per service. Service desk and technical team members.
Incident per service/priority - volume An histogram showing the incidents volume per service and priority. Service desk and technical team members.
Incident - in charge time A pie showing the percentage of incidents 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.
Incident per priority - resolution time An histogram showing, per priority, the percentage of incidents 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 incidents 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 incident management process are given.

If you get lost, any time use the EXPLORE WORKFLOW command of the incident 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 incident 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 "Incident" as self service request (this determines the creation of a new incident)
  4. Fill the incident form, at least with mandatory form and save with the SAVE command

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

Take in charge an incident as service desk member

  1. Login as "sdspecialist" (therefore a service desk member)
  2. Open the the desired incident; you can do it quickly either by
  3. Take in charge the incident by
    • Pressing the SAVE & NEXT command
    • Choose the "1. Take In Charge" workflow transition
    • Fill the incident form and save with the SAVE command

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

Resolve an incident as service desk member

  1. Login as "sdspecialist" (therefore a service desk member)
  2. Open the the desired incident; you can do it quickly either by
  3. Update incident 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 an incident to a technical team

  1. Login as "sdspecialist" (therefore as a service desk member)
  2. Open the the desired incident; 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 an incident 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 incident; you can do it quickly either by
  3. Press SET ME AS TICKET WORKER command
  4. Press SAVE command

Close an incident as a final user

  1. Login as "finaluser"
  2. Open the the desired incident; you can do it quickly either by
    • Access the "Incident resolved" view in the Tickets window of the home page and pick an incident among those listed
    • Insert the reference number of an incident in workflow status"Resolved" in Quick Search, after selecting the search context "Ticket"
  3. Close the incident by

The incident is now in workflow status "Closed".