Terms & definitions
Priority is the most important control factor to be applied in many processes and enables a reasonable scheduling of tasks and resources.
- Any physical (e.g. person, computer system, space) or virtual (e.g. time, knowledge, computing power) entity being restricted in its availability and/ or quantity.
- An activity, or part of an activity, within a process that requires resources for its execution.
- The decision through which resources are assigned to tasks within a specified piece of time.
Priorities in IT Service Management
The restrictive availability of resources is the main driver for prioritization. In IT Service Management, the following can/must be prioritized carefully:
- Incidents and problems, according to their:
- impact, defined as the number of affected users, AND
- urgency, as a quantification of factual or potential SLA violations
- The fulfillment of customer demands according to an expected quantified value/revenue
- Changes needed due to:
- priorities from the underlying incident(s) and/or problem(s) OR
- priorities of the underlying customer demands
Record attributes X activities
The following icons are used in an „attributes X activities matrix“:
The value of the attribute may be automatically generated or recalculated by the supporting management tool within the current activity.
|System Write (Mandatory field)
The value of the attribute must be automatically generated or recalculated by the supporting management tool within the current activity.
The value of the attribute may be set or updated by the person responsible (agent) for the current activity (refer to RACI matrix)
|Agent Write (Mandatory field)
The value of the attribute must be set or updated by the person responsible (agent) for the current activity (refer to RACI matrix)
|Agent Read Only
The attribute is displayed to the agent as within the current activity this information is useful.
|[blank]||The information in the attribute is not useful within the current activity.|
There are the following different types of Rules
- process-specific rules are defined in the section „process specific rules“ within the process description for each process
- activity-specific rules are defined in „activity specific rules“ within the process description in each activity
- service-specific rules are defined in the Service Description
- customer-specific rules are defined in the appropriate Service Level Agreement
Standard Operating Procedure
A Standard Operating Procedure (SOP) is a set of instructions having the force of a directive. These instructions describe the processing of given work tasks and are process, service or workplace driven. SOPs are often used for the education of new staff or as a tool to drive performance improvement and improving organizational results.
There is no given template or form for the SOP description. Flow charts, process descriptions and checklists are often used.
Ticket, Ticket Owner and Ticket Agent
A ticket is an instance of a process. According to the process, the ticket often has different names. e.g. this is simply called „Incident“ in the Incident Management process , or „Change“ in the Change Management process.
This is the person in charge of performing the required actions in the current activity of a process. Concerning the RASCI diagram, the Ticket Agent is Responsible for the activity.
This is the person responsible for effective and efficient handling of a specific ticket throughout the entire Ticket life cycle . Concerning the RASCI diagram, the Ticket Agent is Accountable for the activity.
When a Ticket is functionally escalated, the value of „Ticket Agent Attribute“ in the record is set to the new Group or Person. The „Ticket Owner“ stays the same.
When a Ticket is hierarchically escalated, the value of the „Ticket Owner Attribute“ in the record is set to the new Group or Person e.g. the appropriated Process Manager. The „Ticket Agent“ stays the same.
Most of the time the „Ticket Owner“ and the „Ticket Agent“ are set to the same group or person at the beginning of the first process activity. In the Incident Management Process, the first activity is called „Incident Recording“ and the Ticket is called Incident.
Initially the value of the attributes „Incident Agent“ and „Incident Owner“ are set to the group (function) „Service Desk“. This means the „Service Desk“ is responsible for this Incident throughout the whole life cycle until the Incident can be closed. The „Service Desk“ must also perform the activity „Incident Recording“.
In case of a Functional Escalation the value of the attribute „Incident Agent“ is set to the appropriated „Expert Team“ or „Expert“ (2nd Level). They have to perform the next activity. However, the Service Desk stays as the „Incident Owner“ and is responsible for the incident coordination.
In case of an Hierarchical Escalation the „Incident Owner“ is set to the „Incident Manager“. They are now responsible for the Incident until it is closed or they give it back to the Service Desk. There must be a reason for the escalation e.g. the „Incident Agent“ is not willing to start working on the Incident, which may not changed during the Hierarchical Escalation. When the reason can be eliminated, the Ownership can be transferred to the Service Desk again. If the reason is not eliminated, a new Hierarchical Escalation can be triggered.