EditGeneral
ITIL recommends that an incident
priority is derived from the
Impact and the
Urgency , based on the context of an organization. Octopus can derive automatically an incident priority by selecting the impact and urgency of a incident.
This section provides few examples to help you in defining your priority level.
Note: Generally, priorities are defined and used to resolve incidents in an effective way; it is not necessary to use priorities for Service Requests, as an execution target is to be defined for each Service Request type.
EditDefinition
- Impact measure the effect of an incident on business processes.
- Urgency is the time it takes to an incident to have a significant impact on business.
- Priority is based on impact and urgency, and is used to identify required times for actions to be taken.
EditPriority Matrix
Use the following matrix as a sample to help you in establishing your own Priority Matrix.
Please note that according to the business objectives and needs, Impact and Urgency can be defined based on different criteria:
- Amount of impacted users
- Potential financial losses
- Critical periods (year, month, etc.)
- System Criticality
- Others
| |
IMPACT
|
| URGENCY |
|
High (Whole Organization) |
Medium (Department, Service
or > 5 users)
|
Low (1-5 users) |
Urgent
|
P1 |
P2 |
P3 |
Normal
|
P2 |
P3 |
P4 |
This example is built on Impact based on amount of impacted users.
EditPriority Level Definition
The following table is a model suggesting you how could be defined a Priority Level.
The description for each Priority depends on the context of your organization, and on the criteria that you may need to consider when time comes to the Service Desk Agent to establish an Incident Priority. A resolution target will be set for each Priority; the objective is to resolve incidents within this delay.
Priority |
Name |
Description |
Resolution
Time |
P1
|
Critical |
Interruption making a critical functionality inaccessible or a complete network interruption causing a severe impact on services availability. There is no possible alternative. |
4 hours
|
P2
|
Important |
Critical functionality or network access interrupted, degraded or unusable, having an severe impact on services availability. No acceptable alternative is possible. |
24 hours
|
P3 |
Normal |
Non critical function or procedure, unusable or hard to use having an operational impact, but with no direct impact on services availability. A workaround is available. |
3 days |
P4 |
Low |
Application or personal procedure unusable, where a workaround is available or a repair is possible. |
5 days |