ITIL Continual Service Improvement (CSI)

Definition of ITIL Continual Service Improvement (CSI)

ITIL Continual Service Improvement (CSI) is the fifth and final stage of ITIL Service Lifecycle under ITIL’s IT Service Management Framework (ITSM). It aims to deal with measures to be adopted to improve the service quality by learning from past successes and failures. Continual Service Improvement also aligns and realigns IT Services to the changing business requirements by identifying and implementing changes for improvements. For doing this, it takes the similar approach described in Deming Cycle (PDSA Cycle). The ITIL Continual Service Improvement (CSI) describes the best practices for achieving incremental and large-scale improvements in services quality, operational efficiency, and business continuity. It effectively describes and utilizes the concept of Key Performance Indicator (KPI), which is a metrics-driven process, for reviewing, evaluating, and benchmarking performance of services. CSI is part of all the stages and ITSM processes and services It is important to consider CSI processes subject to improve as well.

The CSI Practice relies upon five major guiding principles defined in the CSI book:

• The CSI Approach
• Seven Step Improvement Process
• The Deming Cycle
• Professor Kotter’s Eight Steps for Successful Transformation
• Knowledge Management

The figure below illustrates the Information Technology Infrastructure Library (ITIL) Continual Service Improvement (CSI) seven-step process. The individual steps overlayed by the more general Deming (plan-do-check-act) Cycle.

source: Geant.Org

Scope of Continual Service Improvement The CSI Implementation process may vary and the correct way to implement it rely upon the organization's goal; it may be long term goals or short time dependent on the nature and policy of the organization. Generally the scope looks into three areas of ITSM.

• ITSM Processes
• IT Services
• The Service Lifecycle

Cartlidge & Lillycrop(2007) thinks it is very hard to decide from where to start, but one of the above three areas can be taken as a starting point. Case ITIL (2006) suggests the organizations to address the pain points first for getting value of Investment (VOI) as well as gaining the business and functional group support. Case (2009) opines some quick wins like low hanging fruits can be experienced during the implementing process.

• ITSM Processes- Where Do we start?: Organizations are not aware of from where to start the implementation of CSI in business. They can approach through change management, Incident Management and problem management by going into mature documenting process. Case (2009) argues change management as a control process and helps in attaining a maturity level for organizations protecting the production environment with the efficiency and effectiveness the process requires. Request for Change (RFC) can be a quick win if one doesn‟t exist, or change advisory board highlighting the possible changes, procedures to implement changes, creating risk models and so forth.
• IT Services- Where do we start? Case (2009) states that it is crucial to choose right IT services once the ITSM process is implemented in our business, to ensure the business value is delivered. But the problem is to identify the right services but can be simply done through identifying the services falling out to meet the satisfaction levels or which are continuously giving a threat. In case of absence of service level data a discussion is to be carried on with the business highlighting the services that are deemed mission critical. Impact assessment is to be conducted either to give continuity to the service or discard the service.
• Service lifecycle-where do we start ? Starting the improvement initiatives of processes organization will find our many turning points for making improvements in the service lifecycle itself. Thus it is crucial that organization keeps tracks of the communication and feedbacks between different service lifecycle phases. Organizations should look for improvement opportunities associated with the business requirements Case (2009) and Nickols (2010).