Incident Management
The content of Incident Management is to respond to unplanned situations
where services are not provided at agreed Service levels (e.g. loss or reduction
in the availability of Exchange Server) and to restore normal service operation
as quickly as possible. Emphasis is placed on minimizing the impact of a service
outage on the business of the company (a.k.a. Business Impact).
The above implies that the incidents that can not be resolved by the 1st line
support within internally agreed due dates (e.g. by using the Known Error
Database and the Knowledge Base) must be immediately escalated to the
specialized technical teams (functionally) or responsible managers (hierarchically).
Incident records workflow can be defined according to the service, level of
which was reduced below an agreed limit by the incident. However, from a
practical viewpoint due to commonness we recommend not to present a number of
statuses and use only the statuses New – Solution – Resolved - Closed.
Difference of typical procedures leading to removal of the incident affecting
various services can be documented in the Instructions for solver within the
workflow itself to be clearly visible during the incident resolution process.
This is subject of the customer needs analysis.
Various Incident models can be specified using the
templates functionalityto support consistent handling of frequently
occuring situations.
Incident Record recommended attributes
The following table presents the recommended set of
attributes used throughout the Incident records workflow.
| Attribute name |
Attribute type |
Mandatory for statuses |
|
Impact |
List of values
|
|
|
Urgency |
List of values
|
|
|
Priority*
|
List of values
|
|
|
Category
|
Hierarchical list of values
|
Resolved
|
|
Symptoms
|
Multiline text
|
Resolved
|
|
Diagnosis
|
Multiline text
|
Resolved
|
|
Resolution
|
Multiline text
|
Resolved
|
|
Problem candidate
|
Boolean
|
Resolved
|
|
Incident closure category
|
List
of values
|
Resolved
|
*Priority is calculated based on Impact and Urgency
values. The Priority value can, in turn, be used to determine the
Service level associated to particular Incident record using
the Quality index field.
Incident Record sample workflow
This is the default process sample which the customer can further edit
according to his own needs.
| Status |
Description |
Instructions for solver |
| New |
Pending classifying Incident. |
Make sure that this is an Incident. If
it is not the case, click on "Move to
another service" to move the request to the
correct service.
Specify the solution
priority.
Then use "Assign to solver" to
hand the request over to a specific solver. |
| Solution |
Incident is being solved. |
Re-establish normal task operation as
soon as possible.
Click on "Resolve" to
resolve the incident.
If this is a known
issue, link it to the Incident and use the "related"
status. |
| Resolved |
The incident has been resolved.
| |
| Closed |
The incident has been closed. No further
actions are required. |
|
Did not find what you were looking for? Ask our technical support team.
|