Developing Actionable ITIL Processes

The Pitfalls of Haphazardness

Thus, critical process intelligence can be lost or get out of sync when staff members leave, or when the organization grows, restructures or merges. The result is haphazard process development. Haphazard processes may have no clear entry or exit point, too much (or too little) detail, crossing lines, wordy or ambiguous procedure names, undefined roles and ownership, and a lack of clearly defined inputs and outputs to and from other processes.

Figure 1. Haphazard process development

A Sound Framework

A sound process development framework to support development of actionable ITIL v3 processes brings many benefits: centralized knowledge capture, repeatable results, reduced defects, increased collaboration, and a shared process language across the organization. It facilitates continual process improvement, and provides a consistent baseline for measurements, results tracking, and change control.

A good process development framework comprises an online tool built around a multi-layered process model. As depicted in Figure 2, each layer of the model parses the process into progressively lower levels of detail, leading the end user in an intuitive fashion to the specific actions required for thorough ITIL process implementation.

Figure 2. Multi-layered process framework

The four layers of the process framework are: process, procedures, steps, and work instructions and tool tips. Processes, procedures, steps and work instructions are housed within the online tool. The highest and lowest layers, policies and work flows physically reside outside of the online tool, but are still an integral part of an actionable process model. Each layer of an actionable process model is described in detail below.

Policies - A policy is a high-level overall plan that covers general objectives and expectations. For example, a common policy for Incident Management is to use the service desk as a single point of contact for all incidents, while common policies for change management are to establish a change advisory board (CAB) and to define rules for executing different types of changes such as emergency, standard, normal, etc.

Policy development is a responsibility and activity of management. It occurs outside of the process framework, and provides the goal posts toward which all process development is aimed.

Processes - Processes are high-level activities required to meet the policies and objectives of the organization during various phases of the IT service management lifecycle. The major activities for each process can be derived from the various books in the ITIL v3 service lifecycle. This is where it all starts and where ITIL paves the way.

Procedures - Each process should also outline the procedures that establish the set of steps required to complete the process activities. For example, the Incident Management process would have a set of procedures to identify and log; categorize and prioritize; investigate and diagnose; resolve and recover; monitor, track and communicate; and close the incident. Procedures are repeatable and static regardless of the particular incident or change request involved. A procedure is an action—its name always begins with a verb. Every procedure is triggered by a specific event or input, and results in a specific output.

Steps - Each procedure comprises a set of steps, arranged in flowchart fashion, that are followed to complete the procedure. For example, Incident Management contains a procedure to categorize and prioritize the incident. To complete this procedure, you would complete the following steps: determine the request type, record the incident details, identify the impacted configuration item, and determine the priority of the incident.

Work Instructions - Each step contains work instructions which document repeatable, role-based instructions for completing the step. Work instructions are where the processes and procedures meet the IT service management tool; as they explain how to utilize the tool to execute the step, when applicable.

To continue our example above, the work instruction for the step determine the priority of the incident would contain specific information about impact and urgency levels and criteria, and would describe how to indicate the incident's priority within the tool.

Work Flows - The lowest level of detail is the work flow. Work flows are repeatable, role-based instructions for executing a change, fixing a problem or producing a work product. Work flows are dynamic, consisting of the details tailored for each task that IT performs for the business. Documented work flows often reside in the IT service management tool in a pre-populated model or template, and are also referred to as standard operating procedures (SOP).

An example of a work flow is an incident resolution template, an automated service desk template that pre-populates an incident record with appropriate instructions for resolving a recurring incident. Other examples of work flows are standard change; a prescribed set of instructions for building, testing and implementing a repeatable change such as a password reset or a new employee setup; and a test script, a specific test scenario for confirming automated functionality.