quality standard for itil process implementation - itsmf international

©itSMF International 2012

Finalist in the itSMF International Whitepaper Submission Competition 2012

Quality Standard for ITIL Process Implementation Version 1.0

Authors: Lubomir Lukac, Matej Kyncl

ANECT Corporation



1. Document Content and Purpose

1.1. Purpose and Summary This document describes the scope and quality of ITIL process implementation documentation. It defines 3 types of standard:

• Advanced Documentation – contains all process documentation in full detail. • Average Documentation – contains usual process documentation. Some documents contain full detail,

some contain limited detail. • Basic Documentation – contains only essential process documentation in unavoidable detail.

Main mission of this document is to show, what the minimum level of documentation required for successful process implementation is (Basic Documentation) and how excellent implementation looks like (Advanced Documentation). This white paper helps a reader to recognize a level of his/her process implementation and shows the way forward in his/her efforts.

1.2. Scope The standard described in this document is primarily focused on process documentation description and structure. Project documentation is out of scope.

ITSM Project

Implementation Project Documentation

Process Policy

ReportsProcess Design

OLA, UC

Working Instruction

…….

Project PlanProcess Roles Assignement

…...

Process Documentation

Processes

ToolsPeople



2. Advanced Documentation

2.1. Voice of Customer (VOC) + Critical to Quality (CTQ) • VOC is an Excel table with all (IT, business …) customer requirements aggregated in the initial

requirements collection meetings • The VOC table is later amended by quantification of a final state as requested by the customer (CTQ), i.e.

inaccuracy of data can’t be greater than 3% • Afterwards the process implementation Process Owner makes the table part of Continual Improvement

evidences

2.2. Process Policy General process rules in the company. Policy content:

• Process scope • Principles (i.e. Financial Manager is responsible for Asset Tags accuracy) • Mission and Vision • Process documentation list and description • Roles, their general responsibilities and descriptions • Integration with other processes

2.3. Process Design 2.3.1. Process Design – 1. level (high level view)

Contains:

• Process diagram (flowchart) • Basic activities • Process inputs and outputs • Data sources and outputs • RACI table for the first level • Communication channels (touch points) with other processes and third parties (if they exist)



Create, Update & Archive CI

CMDB Integrity Check

Work Order

Request for Change (RFC)

Time

CMDB Data Report

CMDB Data Report

Work Order

CMDB CMDB

Data WH

CMDB

Create RFC

CMDB Reporting

CMDB

Automatically Discovered Data

E-mail

2.3.2. Process Design – 2. level (details for high level view activities) Contains:

• Process Diagram (flowchart)

• Process Diagram Activities description (numbered Process Diagram activity list), i.e.:



• RACI table (table of responsibilities for particular activities), i.e.:

2.3.3. Working Instructions - 3. level (deep detailed view)

Contains detailed working instructions within a specific tool, i.e.:

2.4. Risks and Countermeasures (FMEA) Activity list (from 2. level of Process Design) amended by possible risks and their acceptance, reduction or elimination.



2.5. Critical Success Factors (CSF), Key Performance Indicators (KPI)

KPIs are defined based on CSFs. Particular KPIs contain:

• Name • Description • Calculation • Time range • Relation to CSF

2.6. Operational Level Agreement (OLA), Underpinning Contract (UC)

Agreements between the Process Owner and other internal parties (OLA) or third parties (UC) contain:

• Parties definition • Name • Description • Calculation formula • Revision periods

2.7. Supporting Tool Functional Specification is used as a basis for tool customization for a specific process (at the beginning) and tool fields description (when the tool is in production). It contains:

• Proposal of how to implement the process diagram into the tool • Fields description, format and content, i.e.:

• Process Roles to Tool Roles mapping • Automatic triggers definition according to the defined process, i.e. after Change Implementation, a Task

for CMDB Update is automatically generated



• Notification Rules in case of an event, i.e. information about raised RFC

2.8. Reports Reports definition contains:

• Report name • Report purpose • Description • Report type • Visualization style • Report sources • Field name in the report and its description • Filters definition • Person responsible for the report • Report customer • Report generation frequency • Report history (report updates and their purpose) • Report security classification • Relations to metrics, KPIs and CSFs

Example:

2.9. Training materials Regular training for all teams as requested by the customer must be organized. Different training materials for different groups (management, trainers, end users, administrators …) are created, according to the specific level of interest. For example; “one training session, 4 hours duration.” Likely content would be:

• A short process theory summary according to ITIL • Process diagrams, activities and responsibilities presentation • Process impact on specific teams • Live show • Practical exercises



2.10. Communication Channels 2.10.1. Towards Customers Interaction definition between the process and a customer. It can be covered within the 2. level process diagram. In some cases it makes sense to create a standalone document (i.e. in case of multiple, differentiated customers).

2.10.2. Within ITSM Process Interaction definition between the process and other ITSM processes. It can be covered within the 2. level process diagram.

2.11. Formalized description of the Continual Improvement Process

A specific document describing Continual Improvement methods for the process. It contains:

• Process Policy • Process Diagram in agreed detail • Process activities, inputs and outputs description • RACI table • Tracking tool for opportunities for improvement • CSF, KPI, OLA • Reports



2.12. Glossary Unified glossary for all processes, i.e.:

2.13. Process Forms and other process details Forms, tables and lists that are necessary to keep the process running and don’t belong to any documents described in previous chapters. I.e.:

• Change, Incident and Problem input forms • Feedback forms • Change, Incident and Problem Category lists • Table describing mapping process roles to jobs in organization



3. Average and Basic Standards

Activity Advanced Average Basic

VOC + CTQ

Process Policy

Process Design 1. level

Process Design 2. level 1

Working Instructions 3. level

Risks and Countermeasures (FMEA)

CSFs, KPIs 2

OLAs, UCs 3

Supporting Tool Functional Specification

Reports 4 Training Materials 5

Communication Channels

Formalized description of Continual Improvement Process

Glossary

Document in full detail

Document in limited detail

Document is not part of Standard

1 Like in Advanced documentation, but only for selected blocks of High Level View diagram 2 Particular KPIs contain just name, description and relation to CSFs 3 Particular OLAs and UCs contain just name and description 4 Reports contain just name and short description 5 Training Materials just of one type for all trained groups



4. Risks

This chapter describes possible risks related to simplification of document content or structure or to their withdrawal from the scope, i.e. to save money or speed up implementation.

4.1. Process Design 2. level and Working Instructions If Process Designs or Working Instructions are not in the full detail warranted, the following negative effects are possible:

• Creation of space for misinterpretation of particular activities • Process mutations in time • Workarounds in violation of the process • KPI and OLA breaches

4.2. CSFs, KPIs, OLAs, UCs If details of CSFs, KPIs, OLAs or UCs are not defined, we risk:

• Report inaccuracies because different parties use different interpretations • Untrustworthy report results leading to inappropriate process management

4.3. Risks and Countermeasures (FMEA) If risks and countermeasures are not defined for particular process steps, we risk:

• Risk realization without defined countermeasures, leading to lengthened recovery times • Unclear responsibilities for risk mitigation / low quality of mitigation strategies

4.4. Supporting Tool Functional Specification Failure to utilize this document means we will use our current tool without change or we will use (for example) a simple Excel table. Insufficient definition of Supporting Tool Functional Specification leads to:

• Difficult tool usage for users and therefore users working around the process • Impossible or difficult KPI and OLA measurements leading to vague process management • Unclear / incomplete / inaccurate reporting

4.5. Reports Risks of insufficient report definition means:

• More effort spent on report creation • Reporting inconsistencies

4.6. Training Materials Insufficient quality of or missing training materials will lead to:

• Insufficient buy-in of processes implemented • Misunderstandings in process production



• Process violations due to user ignorance of the processes

4.7. Communication Channels If Communication Channels with customers or other ITSM processes are improperly defined we risk:

• Insufficient process integration within the organization • Process delays caused by unclear rules of interaction

4.8. Formalized description of Continual Improvement Process

If Continual Improvement for the process is improperly set up, it may lead to:

• Changes implemented within the process without proper controls • Slow tuning of the process, early process obsolescence • Inflexible processes unable to react to new challenges



5. Abbreviations

Abbreviation Explanation

FMEA Failure Mode and Effects Analysis. Method, how to find potential failures within process activities and understand their impact.

SLA Service Level Agreement. Agreement between IT Service Provider and a customer.

CTQ Critical to Quality. Thresholds determining quality. Quantified customer requirements that are used to determine, if they were fulfilled.

UC Underpinning Contract. Contract between IT Service Provider and a third party.

OLA Operational Level Agreement. Agreement between IT Service Provider and other internal part of the same organization.

KPI Key Performance Indicator. Means for process efficiency measurement.

quality standard for itil process implementation - itsmf international

Documents