Home    ITIL  Index

Developing Actionable ITIL Processes

A sound framework coupled with cultural transformation and results tracking are essential for successfully implementing ITIL, write ITSMWatch columnists Micheal Tainter and Kristy Smith of Forsythe.
Mar 5, 2009
By

Mike Tainter,Kristy Smith





Effective adoption of ITIL requires not only the application of ITIL best practices, but also a sound process development framework. Coupled with a campaign of cultural transformation and consistent measurement and results tracking, solid process development techniques will yield repeatable, integrated and actionable processes for managing services and operations across the IT organization.

The Pitfalls of Haphazardness

Haphazard processes can perpetuate inefficiencies, if not chaos, in an IT organization. For example, the complete set of knowledge of an IT organization's activities is usually spread among its many employees. This applies to process documentation, which is too often located in disparate repositories—such as hard drives, shared drives, email folders and people's memories—and is typically stored in many formats such as Word, Visio, PowerPoint, or not documented at all.

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.

 


    1 2 >> Last Page


Comments  (click to add your comment)

Comments

    Name or nickname

    Email address

    Website

    Write comment
    You have characters left. (Maximum characters: 1200).

     


    IT Management Daily Newsletter




    Related Articles

    Most Popular