Introduction Itil Process Map
Introduction Itil Process Map
Contents
Introduction ................................................................................................... 1
ITIL and the ITIL Process Map...................................................................................................... 1
How the ITIL Process Map was created from the ITIL Books ....................... 8
Differences between a Book and a Process Model ......................................................................... 8 Where the ITIL Process Map goes beyond the ITIL Books .......................................................... 9 Processes vs. Functions ................................................................................................................. 18
History of ITIL
The Beginnings
ITIL1 was developed at the end of the 1980's by the Central Computing and Telecommunications Agency (CCTA), a government agency in Great Britain. The reason for commissioning the CCTA was a lack of quality of the IT services procured by the British Government, so that a method had to be found to achieve better quality and simultaneously decrease their costs. The objective was to develop effective and efficient methods for the provision of IT Services - in other words a catalogue of best practices for the IT organization, which today is known as ITIL. The essence of the methods is to make IT services explicit and strictly focused on client needs. This is combined with clearly defined responsibilities for the service provision within the IT organization and effectively designed IT processes. As a result, the IT organization concentrates on the services required by the business, rather than being focused on technologies. The recommendations thus compiled are very broadly valid. It was found that the requirements of the businesses and organizations examined by the CCTA were mostly similar, independent of their size or industry sector. A series of books on ITIL has been issued since 1989 by the Cabinet Office, an administrative body of the Government of Great Britain which is the successor of the CCTA. ITIL is a registered trade mark of AXELOS Limited.
Recognition as a Standard
In the past years, ITIL has become the de-facto standard for IT Service Management. Increasingly, IT managers developed awareness for the service- and customer-driven approach championed by ITIL, and the ITIL terminology is widely understood and used.
-1-
The ITIL philosophy has found its way into a multitude of other models related to IT Service Management, as for example: ISO/IEC 20000 (formerly BS 15000): Information Technology Service Management HP ITSM Reference Model (Hewlett Packard) IT Process Model (IBM) Microsoft Operations Framework
-2-
-3-
Service Strategy
Service Strategy
+
Service Portfolio
Service Design
+
Customer Process
Business Planning Information Desired Service Outcomes
Customer Process
Service Catalogue
Service Transition
+
External Supplier Process
Supplier Service Level Report
Service Operation
CSI Register
The Service Lifecycle is about managing services from their creation to retirement. Each of the five stages is focused on a specific phase of a services lifecycle: Service Strategy determines which types of services should be offered to which customers or markets Service Design identifies service requirements and devises new service offerings as well as changes and improvements to existing ones Service Transition builds and deploys new or modified services Service Operation carries out operational tasks Continual Service Improvement learns from past successes and failures and continually improves the effectiveness and efficiency of services and processes.
-4-
Service Strategy
Service Strategy
+
Service Portfolio
Service Design
+
Customer Process
Business Planning Information Desired Service Outcomes
Customer Process
Service Catalogue
Service Transition
+
External Supplier Process
Supplier Service Level Report
Service Operation
IT Service Management
+
Superior Process
CSI Register
Customer Process Change Schedule
Customer Process
Project Mgmt. (Transition Planning and Support) User Manual Project Plan (Service Transition Plan) Project Portfolio Status Report
Change Record
External Supplier Process
Support Request
Service Strategy
+ +
Change Record
Request for Change (RFC) Service Design Package (SDP) Service Design Service Acceptance Criteria (SAC)
Release and Deployment Management Development Work Order Application Development
Development/ Install. QA Documentation User Manual Technical/ Administration Manual CMS/ CMDB
Service Design
+
Release Record
+
Service Catalogue
+
Release Policy
Purchase Request
Service Operation
Processes outside the IT Organization ITIL Processes outside Service Transition Service Transition Processes Service Transition Processes ITIL Processes outside Service Transition Processes outside the IT Organization
CMS/ CMDB
Change Model
+
IT Service Management Customer Process
+
Change Record Change Schedule Technical/ Administration Manual Change Request to CMS Structure Service Asset and Configuration Management CMS Change Policy User Manual
Customer Process
Service Transition
+
Superior Processes
CMS/ CMDB
CMS/ CMDB
+
Request for Change (RFC) Service Design Package (SDP) Service Design
+
All information originating from Service Management processes is input for the Knowledge Management process. Displaying all inputs within this Overview Diagram is therefore not practicable.
CMS/ CMDB
Change Record
Suggested Process Improvement Knowledge Management Service Knowledge Mgmt. System (SKMS)
Change Model Service Design
Change Management Support Change Model
Service Catalogue
Change Schedule
RFC Template
Change Schedule
Assessment of Change Proposals Change Proposal
Service Operation
Service Operation
Incident Record
Change Schedule
Change Evaluation Report RFC Logging and Review Assessment and Implementation of Emergency Changes Suggested Process Improvement
Change Record
Change Record
+
Change Evaluation Change Evaluation Report
+
Change Schedule
Change Evaluation
Change Record Change Assessment by the Change Manager Change Record Minor Change Deployment
Change Record
Change Model
Change Record
Project Mgmt. (Transition Planning and Support)
+
Change Model
Application Development
+
Change Record
+
Release and Deployment Management
Release and Deployment Management
Release Policy
Change Schedule
+
Release Record
+
Service Validation and Testing Post Implementation Review and Change Closure Change Model
+
Service Asset and Configuration Management CMS/ CMDB
CMS/ CMDB
+
CMS Change Policy
Knowledge Management
Knowledge Management
Superior Processes
Change Manager
IT Service Management
Change Schedule
+
Change Model Service Asset and Configuration Management Change Schedule Change Management Support Service Transition
CMS/ CMDB
+
Service Strategy Change Proposal Process Objective: To asses Change Proposals which are typically submitted for significant Changes by Service Strategy. The purpose of assessing Change Proposals is to identify possible issues prior to the start of design activities. Change Proposal
Change Management
+
Service Catalogue
Service Design
Resource Check proposal for completeness and practicability Change Proposal to be assessed. Determine required CAB members Circulate documents for preparation State reasons and document rejection Notify Change Proposal initiator of rejection Change Proposal rejected.
Change Manager
If required, consult with the initiator prior to rejecting the Change Proposal.
CAB meetings may be a mix of formal and electronic meetings, depending on the complexity of the issues to be discussed.
Provide CAB members in advance with information, in particular the Change Proposal and any supporting documents. Change Proposal may be authorized
This possibly includes suggestions on how to modify the proposed Change before it can be re-submitted.
Add the Change Proposal to the Change Schedule Change Proposal authorized.
Resource Change Advisory Board (CAB) Assess risks associated with the Change Proposal Assess risks related to Business processes on the client side. Services. Important parts of the infrastructure. If required, consult with technical experts. Assess the proposed schedule for implementation Assess risks related to Check if there are any reasons to object to the proposed implementation date (e.g. conflicts with the existing Change Schedule). Determine any required modifications to the Change Proposal
If the assessment leads to the conclusion that a higher level of authority is required to authorize the proposed Change (e.g. proposal must be authorized by IT Management or the Business Executive Board).
Level 3: Sub-Processes
The High Level View shows the ITIL Service Lifecycle and its most important external relationships on one single page Zooming in by clicking the corresponding process object, the viewer is presented an overview of the Service Transition process. This diagram illustrates what Service Transition is about: It includes all sub-processes with their interrelationships, as well as all the interfaces to processes outside of Service Transition. Zooming in once again leads to an overview of Change Management and finally to a detailed process flow for the Change Assessment by the CAB process, which also includes a complete list of inputs and outputs, and linked checklists/ document templates.
-5-
Structure of Agreements
The layered structure of ITIL agreements ensures that the IT organization is aligned with the business needs:
Business
Customer Process
i
IT Service Management
Service Operation
Service Level Agreements (SLAs) define the service requirements from the business perspective
-6-
Operational Level Agreements (OLAs) and Underpinning Contracts (UCs) make sure those service requirements are matched from within the IT organization
Business
New or modified service required
IT Service Management
IT Service Management
Agreed service levels are not achieved and service must be improved
A new service is required, either because a customer is requesting it or because Service Portfolio Management decided that a new service must be created Service levels which are already agreed cannot be achieved in this case the service must be redesigned to fulfill the commitments Better ways to provide a service become available, for example in the form of new technologies or improved external service offerings the service will be redesigned in such cases to make it more economical
-7-
How the ITIL Process Map was created from the ITIL Books
Our decision to create the ITIL Process Map was based on the insight that books are not ideally suited to describe complex bodies of knowledge - like ITIL. Hence, the ITIL Process Map takes a different approach to presenting ITIL Best Practice in the form of a clearly structured and layered Reference Process Model. It provides overview diagrams to illustrate the ITIL big picture and allows drilling down into details where necessary.
Where the ITIL Process Map goes beyond the ITIL Books
While we followed the books as closely as possible, we decided in some instances to introduce improvements or clarifications which assign clear responsibilities and make it easier to implement the processes:
ID
Notes on Differences
1
1.1 --
1.2
--
1.3
--
1.4
--
1.5
--
-9-
ID
Notes on Differences
2
2.1 ITIL states that the main triggers for Design Coordination are Requests for Change and the creation of new projects. There is also the concept of Change Proposals, which according to ITIL allow service design activity to begin once they are authorized. In this context, the ITIL Process Map takes the following approach: Design Coordination starts once Service Portfolio Management has chartered a new service and obtained approval for a Change Proposal from Change Management. A project is initiated at the same time, and Project Management calls upon the Design Coordination process for the detailed planning of the design stage. Once the Service Design Package is complete, one or several RFCs are submitted to Change Management for evaluation and authorization.
2.2
--
2.3
The ITIL books suggest that complaints and customer satisfaction are managed through both Service Level Management and Business Relationship Management. In the ITIL Process Map, complaints and customer satisfaction are managed as part of Business Relationship Management. Service Reviews are conducted as part of Continual Service Improvement.
- 10 -
ID
Notes on Differences
2.4
ITIL calls for coordinated risk assessment exercises, so we assigned clear responsibilities for managing risks by introducing a specific Risk Management process. Having a basic Risk Management process in place will also provide a good starting point for applying best-practice Risk Management frameworks like M_o_R (as recommended in the ITIL books) --
2.5
2.6
--
2.7
ITIL provides some guidance on the invocation of ITSCM plans in Service Design. In Service Operation, however, it also states that restoring services is an operational activity. The ITIL Process Map takes the approach of dealing with major incidents, including disaster events and the invocation of ITSCM and recovery plans, through the Incident Management processes, especially Handling of Major Incidents.
2.8
Since the ITIL Process Map has a Risk Management process in place, Risk Management identifies and assesses all the risks that would be faced by services, including information security risks. Our Information Security Management process addresses the management of information security risks, including their mitigation.
- 11 -
ID
Notes on Differences
2.9
Compliance is an increasingly important topic for IT organizations; this called for introducing a specific Compliance Management process Having a well-defined architecture blueprint in place is very important for IT organizations; as a consequence, we defined a specific Architecture Management process --
--
Architecture Management
2.10
Supplier Management
Supplier Management
2.11
Service Transition
Change Management Change Evaluation Transition Planning and Support
Service Transition
Change Management Change Evaluation
3
3.1 --
3.2
--
3.3
The Transition Planning and Support process was renamed and enhanced to provide a fullfeatured Project Management process; this will also provide a good starting point for introducing best-practice Project Management frameworks like PRINCE2 or PMBOK (as recommended in the ITIL books) The ITIL books do not cover Application Development in detail and, as a consequence, do not provide for this process; a complete ITIL Process Model, however, must at least show the interfaces between Application Development and the other Service Management processes, so we decided to introduce a basic Application Development process.
--
3.4
- 12 -
ID
Notes on Differences
3.5
--
3.6
--
3.7
--
3.7
--
Service Operation
Event Management
Service Operation
Event Management
4
4.1 ITIL allows for the available response options to be tailored to the needs of specific organizations. The ITIL Process Map uses the approach that Exception Events may trigger the creation of an Incident Record. If Problems or RFCs need to be opened in response to an Event, this will be done by Incident Management while dealing with the Incident.
- 13 -
ID
Notes on Differences
4.2
ITIL states that Incident Management is about restoring services as quickly as possible, by either resolving the underlying causes or applying a workaround, while Problem Management is about diagnosing and resolving the root causes of Incidents. Individual organizations, however, are given some freedom regarding the precise rules on when to invoke Problem Management from Incident Management. The ITIL Process Map adopts the following approach: Incident Management focuses on restoring services as quickly as possible. If an Incidents underlying cause can be fixed within the committed resolution time using a preauthorized minor change, then Incident Management will make the change to do so. Otherwise, the Problem Management process will be invoked.
Request Fulfilment
4.3
--
Access Management
4.4
--
Problem Management
4.5
The ITIL books explain several problem analysis techniques and highlight in what situations the various techniques may be applied. These contents are not reproduced in the ITIL Process Map. For further explanations on the ITIL Process Maps approach to implementing the interface between Problem and Incident Management, see the notes above on Incident Management.
- 14 -
ID
Notes on Differences
4.6
ITIL treats IT Operations Control as a function. The ITIL Process Map uses an IT Operations Control process to describe the IT Operations Control activities which are not covered by any other ITIL process (see p. 18: Processes vs. Functions) ITIL treats Facilities Management as a function. The ITIL Process Map uses a Facilities Management process to describe the Facilities Management activities which are not covered by any other ITIL process. (see p. 18 : Processes vs. Functions) ITIL treats Application Management as a function. The ITIL Process Map uses an Application Management process to describe the Application Management activities which are not covered by any other ITIL process. Application Management activities embedded in other processes are shown with the Application Analyst as the responsible role. As a result, the RASCI matrix provides an overview of where Application Management activities take place (see also p. 18 : Processes vs. Functions).
Facilities Management
4.7
Application Management
4.8
- 15 -
ID
Notes on Differences
4.9
ITIL treats Technical Management as a function. The ITIL Process Map uses a Technical Management process to describe the Technical Management activities which are not covered by any other ITIL process. Technical Management activities embedded in other processes are shown with the Technical Analyst as the responsible role. As a result, the RASCI matrix provides an overview of where Technical Management activities take place (see also p. 18 : Processes vs. Functions).
--
5.4
CSI is focused on the improvement of two elements of Service Management: Services and Processes. This focus is not clearly reflected by the processes suggested in the ITIL books, so while staying true to the ITIL principles the ITIL Process Map adopted a different process structure: Service Review and Process Evaluation with the aim of finding improvement potentials, plus Definition of Improvement Initiatives and CSI Monitoring to design and monitor specific improvement activities.
- 16 -
ID
Notes on Differences
The "Seven-Step Improvement Process" presented in the ITIL books is in fact the description of a methodology which can be universally applied to identify shortcomings in services and processes and to implement improvements. The principles it contains are applied in a number of ITIL processes, most importantly in Service Design (e.g. in the Service Level Management, Capacity Management, and Availability Management processes). As a result, the "Seven-Step Improvement Process" cannot be treated as a standalone ITIL process, and there is no such process in the ITIL Process Map. The "SevenStep Improvement" principles, however, are included in a checklist.
- 17 -
As per BPMN, "ad-hoc" processes "do not contain a complete, structured BPMN diagram description from start event to end event [... and] may also contain data objects and data associations. (Source: Business Process Model and Notation (BPMN) version 2.0 - Specification, as of January 2011)
- 18 -
- 19 -
Following the introduction of the Strategy Management for IT Services process, Service Portfolio Management has been re-focused to cover activities associated with managing the Service Portfolio. New checklists for Change Proposals, Service Charters and Service Models have been added.
-/-
The previous edition of the ITIL Process Map treated Demand Management as part of Capacity Management. Since the latest guidance includes clarifications on the differences in scope between Demand and Capacity Management, a dedicated Demand Management process has been introduced as part of Service Strategy. The role Demand Manager has been introduced to perform the activities in the Demand Management process.
- 20 -
- 21 -
The process interfaces have been adapted following the introduction of the Design Coordination process. The Supplier and Contract Database (SCD) has been renamed to Supplier and Contract Management Information System (SCMIS), in line with the terminology used in the latest ITIL edition.
- 22 -
Project Management has been revised to highlight that its main responsibility is to coordinate the various service transition projects and resolve conflicts. Projects are initiated when Service Portfolio Management has chartered a new or substantially changed service. The Project Management process now calls upon other processes, for instance Design Coordination and Release Planning to perform planning activities on a detailed level.
A dedicated sub-process for Release Planning has been added, which is called upon from Project Management to perform the detailed planning of Release build, test and deployment. Minor Release Deployment has been removed, as the latest ITIL guidance specifies that minor Changes are implemented by Change Management without the involvement of Release Management. Additional interfaces to Project Management have been added to make sure that Project Management is constantly provided with current planning information
Additional interfaces to Project Management have been added to make sure that Project Management is constantly provided with current planning information. The process interfaces have been updated to reflect the new structure of the Service Transition processes. The checklists CMS/ CMDB and DML have been completely revised to better explain the concept of the Configuration Model and its use in the context of defining the DML.
- 23 -
Incident Management
Guidance has been improved on how to prioritize an Incident, including the addition of a new checklist Incident Prioritization Guideline. Additional steps have been added to Incident Resolution by 1st Level Support to explain that Incidents should be matched (if possible) to existing Problems and Known Errors. Incident Resolution by 1st Level Support and Incident Resolution by 2nd Level Support have been considerably expanded to provide clearer guidance on when to invoke Problem Management from Incident Management. The emphasis is now on restoring services as quickly as possible, and to seek the help of Problem Management if the underlying cause of an Incident cannot be resolved with a minor Change and/or within the committed resolution time. Incident Closure and Evaluation now states more clearly that it is important to check whether there are new Problems, Workarounds or Known Errors that must be submitted to Problem Management.
- 24 -
Access Management
An interface between Access Management and Event Management has been added, to emphasize that (some) Event filtering and correlation rules should be designed by Access Management to support the detection of unauthorized access to services. A dedicated activity has been added to revoke access rights if required, to make this point clearer. It has been made clearer in the Request Fulfilment and Incident Management processes that the requesters authorization must be checked.
- 25 -
IT Operations Control
IT Operations Management has been renamed to IT Operations Control, to improve alignment with the ITIL books. IT Facilities Management has been renamed to Facilities Management, to improve alignment with the ITIL books. A new process Application Management has been added, showing Application Management key activities. The Application Analyst role has been added to a number of processes where Application Management expertise is required. The RASCI Matrix has been adjusted accordingly.
Facilities Management
Application Management
Technical Management
A new process Technical Management has been added, showing Technical Management key activities. The Technical Analyst role has been added to a number of processes where Technical Management expertise is required. The RASCI Matrix has been adjusted accordingly.
- 26 -
CSI Monitoring
- 27 -
5.3
5.4
6
6.1 6.2 6.3
- 29 -
Relationship Processes
Business Relationship Management Supplier Management Business Relationship Management Supplier Management
8
8.2
Resolution Processes
Incident and Service Request Management Problem Management Incident Management, Service Request Management Problem Management
8.3
9
9.1 9.2 9.3
Control Processes
Configuration Management Change Management Release and Deployment Management Service Asset and Configuration Management Change Management Release and Deployment Management
- 30 -
IT Process Maps GbR Dipl.-Ing. Stefan Kempter & Dr. Andrea Kempter Am Hrnle 7 87459 Pfronten Germany Tel. + 49-8363-927396 Fax + 49-8363-927703 [email protected] www.IT-ProcessMaps.com Member of itSMF IT Process Maps GbR, 2013
ITIL is a registered trade mark of AXELOS Limited. All processes and methods in our products were compiled with the greatest of diligence. Despite this fact, errors may not be ruled-out. IT Process Maps GbR therefore makes no guarantee nor accepts any type of liability for consequences, which may be associated with incorrect statements. Each user must decide in his own particular case, whether the illustrated procedures are respectively applicable to his own person or his business.
- 31 -