Differenze tra le versioni di "Incident Management"
(→Process) (Etichetta: visualeditor) |
(→Process) (Etichetta: visualeditor) |
||
Riga 157: | Riga 157: | ||
|- | |- | ||
− | | "Deafult" || | + | | "Deafult" || "Opened" || cccc || |
Riga 177: | Riga 177: | ||
|- | |- | ||
− | | | + | | "Resolved" || "Closed" || cccc || |
|- | |- | ||
− | | | + | | "Resolved" || bIn Charge"bbb || cccc || |
|- | |- | ||
− | | | + | | "Suspended" || "In Charge" || cccc || |
|- | |- |
Versione delle 21:43, 13 apr 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.
Indice
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.
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 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 alwasy 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 |
|
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 |
|
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. | |||||||||||||||
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 |
|
The role is set to the service desk member who takes in charge the incident. | |||||||||||||||
Technical team member |
|
There are several technical teams predefined for different domains. The following table shows which users are members of each team.
| |||||||||||||||
Technical team manager |
|
There are several technical teams predefined for different domains. The following table shows which users are set as solution group manager for each domain.
| |||||||||||||||
Service manager |
|
This role is mapped on a system resource with user of user type "Project/Service Manager". The login identifier of this user is "ServiceManager", who is responsible for the "itmCLOUD" service. |
Process
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.
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. |
"Canceled" | The incident has not been rejected or has not been confirmed. |
"Review" | The incident is under review. |
"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 |
---|---|---|---|
"Deafult" | "Opened" | cccc |
|
"Opened" | "In Charge" | cccc |
|
"Opened" | "Canceled" | cccc | |
"In Charge" | "Resolved" | cccc | |
"In Charge" | "Suspended" | cccc | |
"In Charge" | "Canceled" | cccc | |
"Resolved" | "Closed" | cccc | |
"Resolved" | bIn Charge"bbb | cccc | |
"Suspended" | "In Charge" | cccc | |
aaaa | bbbb | cccc | |
aaaa | bbbb | cccc |
Management information
Visibility
Incidents, information
Notifications
Views, notifications
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. |
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. |
Examples of use
Try the following sequence:
(table with steps, etc.)