ITIL® V3 and ISO/IEC 20000 White Paper
- White Paper
- Service management
- Methods & frameworks
- Incident management
March 21, 2008 |
13 min read
- White Paper
- Service management
- Methods & frameworks
- Incident management
For some years the close relationship between ITIL V2 and BS 15000, then ISO/IEC 20000 has benefited both sets of documents and those that relied on them. Rules on the development of UK standards meant that the alignment between BS 15000 and ITIL was one of spirit and intent and not of direct control by either OGC (owners of ITIL) or BSI (owners of BS 15000). Editorial rules also meant that BS 15000 was also written so
that best practices other than ITIL could be used to achieve the requirements of BS 15000. Very similar editorial rules apply to international standards so that the standards cannot include references to ITIL.
There were documented differences between ITIL V2 and ISO/IEC 20000. However, the most common route to
achieving the requirements of ISO/ IEC 20000 is still via the use of ITIL advice, to the extent that ISO/IEC 20000 is frequently referred to as ‘the ITIL standard’ and ISO/IEC 20000 is often adopted by service providers that wish to demonstrate they have adopted ITIL advice in an effective manner. Support for closer alignment
between ISO/IEC 20000 and ITIL was expressed during the fast tracking of BS 15000 and during subsequent discussions by the international standards committee responsible for the development of ISO/IEC 20000.
ITIL V3 was published in May 2007 and over time will replace ITIL V2. One of the objectives for the ITIL V3 project was to retain, and where appropriate, improve alignment. There are less differences between ISO/IEC 20000 and ITIL V3 than with ITIL V2. Changes from ITIL V2 to ITIL V3 include the service lifecycle approach in ITIL V3, which is a closer alignment to the service lifecycle approach of ISO/IEC 20000 (ITIL V2 was rooted in separate processes, grouped according to how they may be found in an organisation).
The table included within this white paper is an ISO/IEC 20000-1 centric document. It identifies clauses where
there are notable differences between ISO/IEC 20000 and ITIL V3 that are not simply due to the different purposes of the two sets of documents. Few differences in terminology are referenced, as there is no requirement in ISO/IEC 20000-1 for a service provider to use a specific set of terms, even though some are defined in clause 2 of the standard. For example, a service provider aiming to achieve ISO/IEC 20000 may use completely different names for processes, roles and responsibilities than used in ISO/IEC 20000. It does not cover topics in ITIL V3 that are out of the current scope of ISO/ IEC 20000:2005.
|ITIL V3 and the differences ISO/IEC
20000: 2005 clause number and text
|ITIL V3 and the differences|
|2 Terms and definitions|
|Activity: Not defined in the standard||Activity: In ITIL V3 the meaning is: ‘a set of actions designed to achieve a particular result. Activities are usually defined as part of processes and plans and are documented in procedures’.
NOTE: The term ‘activity’ does not have a special meaning in ISO/IEC 20000. However, as this term is used in international standards such as ISO/IEC 12207/15288/15504 there may be changes to ISO/IEC 20000 Ed. 2, which is currently in early draft.
|Asset: Not defined in the standard||Asset: In ITIL V3 assets is used as either capabilities, resources or both, depending on the context. Assets include anything that could contribute to the delivery of a service. Assets can be one of:
management, organization, process, knowledge, people, information, applications, infrastructure and
financial capital. This does not match the current use of the term asset in ISO/IEC 20000, where the word is used as for financial asset, but only for assets used in delivery of the service.
NOTE: See comments on service asset against clause 9.
|2.5 configuration management database
(CMDB) – database containing all the
relevant details of each configuration
item and details of the important
relationships between them
|In ITIL V3 a CMDB is used to store configuration records throughout their lifecycle. ITIL V3 also uses the term configuration management system (CMS) as a set of databases, tools used to manage configuration data and data such as incident, problem … employee data … locations … users. CMS is therefore not simply a new name for a CMDB, as a CMS may contain several CMDBs as well as tools and a wide range of data types collected for many different purposes.
From the perspective of the standard CMS is most easily envisioned as a logical grouping of service management data and tools. It is very unlikely to be a single physical data store or even a single
logical data store or a single tool. ISO/IEC 20000 does not specify where all the data used in service management should be stored or what name should be given to the (logical) store, so use of the term
CMS is not a barrier to achieving 20K’s requirements.
NOTE: Although the use of CMS does not present a barrier to achieving the requirements of ISO/IEC 20000, when reading the standard a service provider who has adopted the use of CMS could
interpret all requirements that refer to configuration management data base (or CMDB) as referring to CMS. It will be advisable when doing this to also consider what type of data store, tool or type of data is appropriate as CMS may be wider than CMDB.
|2.7 incident: any event which is not part of the standard operation of a service and which causes or may cause an interruption to, or a reduction in, the quality of that service
NOTE This may include request questions such as “How do I...?” calls.
|This term is used differently in ITIL V3.
NOTE 1: See comments on event management against clause 6.3.
NOTE 2: See comments on incidents against clause 8.2.
|6.1 Service level management The full range of services to be provided together with the corresponding service
level targets and workload characteristics shall be agreed by the parties and
|Part 1 refers to the need for a definitive source of information on the services etc, and does not require that this is given a special name. That ITIL V2 generally referred to this as ‘Catalogue’ and ITIL V3 uses ‘Portfolio’ is not significant in achieving the requirements in Part 1 as the service provider may use any appropriate term, as long it refers to a definitive source of information.|
|6.3 Service continuity and availability management||ITIL V3 describes the subject of clause 6.3 in separate processes. Both are referenced in several books but are covered in more detail in the Service Design book. ITIL V2 also described them as separate processes.
The requirements are both in clause 6.3 because there was strong similarity between the two sets of requirements. As ISO/IEC 20000 does not require the two processes to be combined, even though they are in a single clause. This was not a barrier to achieving the requirements with ITIL V2 and is not with ITIL V3.
Event management in ITIL V3 is partly covered in clause 6.3, as part of availability management and
partly in clause 8.2 a part of incident management.
NOTE: As previously, a single process or activity in ITIL V3 mapping to more than one clause in ISO/IEC 20000 is not a barrier to achieving the requirements. The reverse is also the case.
|8 Resolution processes||Many international standards refer to a broad-based category of ’defects’ or similar terms. However,
ITIL V3 draws a more detailed distinction:
Events: Neither defects nor requests, but actions that are monitored in order to detect deviations from normal behaviour referred to as exceptions.
Incidents: Defects that have degraded or disrupted services, that are managed so that there is the minimum of business impact. This may not actually resolve the underlying defect.
Problems: Root cause analysis to identify and resolve incidents that have occurred and the prevention of potential defects.
Requests: These are typically small, low risk changes that can be dealt with in timescales similar to problems and incidents.
Many organisations currently treat requests as a form of incident. The approach in ITIL V3 differs from ISO/IEC 20000, in which service requests may be managed by the incident management process.
For the purpose of achieving the requirements of ISO/IEC 20000 requests of any type, such as requests
for access, may be managed by:
a) the incident management process, as in ITIL V2 (clause 8.2)
b) by separate processes such as request fulfilment and access management (clause 8.2)
c) or even as part of change management (clause 9.2).
NOTE: Different types of event may be managed in different ITIL processes and contribute to different clauses in the standard. For example, incident management, capacity management, security management. Although adopting the ITIL V3 approach would not prevent a service provider achieving the requirements of ISO/IEC 20000-1, this is one of the differences that may cause some confusion.
|8.2 Incident management
8.3 Problem management
|In ISO/IEC 20000 both of the words ‘known’ and ‘error’ are used in their normal sense as found in commonly used English language dictionaries, (i.e. defect …that is recognised to exist). ITIL defines ‘known error’ as: ‘…Problem that has a documented root cause and a workaround…Known errors are created and managed throughout their lifecycle by [the] problem management [process].’
NOTE: Because the standard does not use ‘known error’ with a special meaning, a service provider may choose to ignore both the ITIL definition and the advice linked to that definition, i.e. a known error is simply a ‘defect …that is recognised to exist’, without reference to whether there root cause has been established or not.
Event management in ITIL V3 is partly covered in availability management (clause 6.3) and incident management (clause 8.2).
Request fulfilment in ITIL V3 is partly covered by incident management (clause 8.2).
|9.1 Configuration management
NOTE: Financial asset accounting falls outside
the scope of this section.
|ITL V3 refers to ‘service asset and configuration management’ (also referred to as ‘service asset
management including configuration management’). In this context the term asset is used in a very broad sense as either capabilities, resources or both, depending on the context. This subject is mainly covered in the service transition book.
Configuration management manages service assets from acquisition to disposal and provides a configuration model of services, assets and infrastructure, and their relationships
The differences in terminology and what is meant by service asset and configuration management requires a brief explanation of how the changes in ITIL still provides a route to clause 9.1.
CMDB, CIs and assets are all referred to in ISO/IEC20000:
To quote ITIL V3: ‘Services are provided by the deployment of service assets and service management acts as an operating system for service assets by deploying them to provide a service’.
NOTE The terminology and grouping in ITIL V3 is different to both ITIL V2 and ISO/IEC 20000 (neither use the term ‘service asset’). This is likely to be seen as one of the big differences and may need to be described in more detail. The difference may cause some concerns on the interpretation of the standard but does not present an actual barrier to achieving the requirements of either clause 6.4 or clause 9.1. The use of the term ‘service asset’ and how the role of ‘service assets’ in service management is compatible with a focus on service as well as process that is a characteristic of the standard.
|9.1 Continued…(penultimate para of clause)
All configuration items shall be uniquely
identifiable and recorded in a CMDB to which update access shall be strictly controlled. The CMDB shall be actively managed and verified
to ensure its reliability and accuracy. The
status of configuration items, their versions,
location, related changes and problems and associated documentation shall be visible to those who require it.
|The standard requires that information is held and managed in a logical and secure way, with ease of access to those that need the information. The standard does not require that all the information is held in a single physical data store, although all stores of data should be understood and where
necessary linked so that they can be managed as a single logical data store to improve efficiency. ITIL V3 uses service knowledge management system (SKMS) and configuration management system (CMS).
NOTE The changes make little difference to achieving the requirements of the standard as there is no requirement in clause 9.1 that a single physical data store is used. As and when this is realised it may actually simplify using ITIL V3 as a route to achieving the requirements.
|10 Release process||Release and deployment management are mainly covered in the service transition book. It additionally covers deployment approaches and knowledge transfer in more detail, plus ‘early life support’. The term ‘release and deployment management’ in ITL V3 is used where ‘release management’ is used in the standard. The different titles are the main difference between the two, with ITIL V3 effectively using Release as if it did not include deployment, and the standard using release to include deployment.
Requirements for deployment are covered in clause 10, primarily by the last paragraph of requirements.
Although the standard includes requirements for planning for handover, early running and the actual handover, there are a few requirements for the actual handover in the standard.
|…refer to related change requests, known errors and problems.||Please see comments against clause 8.2 about the use of the words known error.|
Jenny is a consultant working for Service Matters and the technical expert on ISO/IEC 20000 for the UK Accreditation Service. She chairs the international committee responsible for the ISO/IEC 20000 series and the
BSI’s service management committee. Jenny is the co-author of the BSI’s ‘Achieving ISO/IEC 20000’ series, ‘A
Managers’ Guide to Service Management’ and ‘IT Service Management Selfassessment Workbook’.
Sharon Taylor is owner of the Aspect Group Inc and Chief Architect, OGC IT Service Management Practices.