scieee AI-readable full text Open interactive document viewer

FitSM-2 Process activities and implementation

Appleton, Owen; Holsinger, Sy; Brenner, Michael; Schaaf, Thomas; LEGRÉ, YANNICK

Abstract

This document is part of the FitSM standard (www.fitsm.eu) for lightweight IT Service Management (ITSM). The process activities and related implementation aspects stated in this part of the FitSM standards series are aimed at supporting effective, lightweight IT service management (ITSM) processes in an organisation delivering IT services to customers, and harmonising ITSM across federations. This part of the standard provides: an overview of the recommended activities to be carried out to establish a service management system (SMS), based on the general requirements (GR1 to GR7) from FitSM-1. an overview of the recommended activities to set up and operate ITSM processes, based on the process-specific requirements (PR1 to PR14) from FitSM-1. This standard is applicable to all types of organisations (e.g. commercial enterprises, government agencies, non-profit organisations) from which IT services are provided, regardless of type, size and the nature of the services delivered, including federated scenarios. For the purpose of this standard, the terms and definitions according to FitSM-0: Overview and vocabulary apply.

Full text

Part 2: Process activities and implementation Version 3.0.2 This work is licensed under a Creative Commons Attribution 4.0 International License. http://www.fitsm.eu/ Part 2: Process activities and implementation FitSM was co-funded by the European Commission under contract number 312851. Document control Document Title Part 2: Process activities and implementation Document version 3.0.2 Release date 18.12.2025 Table of Contents 1. Foreword ........................................................................................................................................... 1 2. About this document ......................................................................................................................... 1 3. Recommended activities to establish an SMS ................................................................................... 2 GR1 Top Management Commitment & Accountability (MCA) .......................................................... 2 GR2 Documentation (DOC) ................................................................................................................ 3 GR3 Scope & Stakeholders of IT Service Management (SCS) ............................................................ 4 GR4 Planning IT Service Management (PLAN) ................................................................................... 5 GR5 Implementing IT Service Management (DO) .............................................................................. 6 GR6 Monitoring & Reviewing IT Service Management (CHECK) ........................................................ 7 GR7 Continually Improving Service Management (ACT) ................................................................... 8 4. Recommended activities of the ITSM processes ............................................................................... 9 PR1 Service Portfolio Management (SPM) ........................................................................................ 9 PR2 Service Level Management (SLM) ............................................................................................ 12 PR3 Service Reporting Management (SRM) .................................................................................... 15 PR4 Service Availability & Continuity Management (SACM) ........................................................... 17 PR5 Capacity Management (CAPM) ................................................................................................ 19 PR6 Information Security Management (ISM) ................................................................................. 21 PR7 Customer Relationship Management (CRM) ............................................................................ 23 PR8 Supplier Relationship Management (SUPPM) .......................................................................... 25 PR9 Incident & Service Request Management (ISRM) .................................................................... 27 PR10 Problem Management (PM) ................................................................................................... 30 PR11 Configuration Management (CONFM) ................................................................................... 32 PR12 Change Management (CHM) .................................................................................................. 34 PR13 Release & Deployment Management (RDM) ......................................................................... 36 PR14 Continual Service Improvement Management (CSI) .............................................................. 39 Part 2: Process activities and implementation Page 1 Version 3.0.2 1. Foreword FitSM is a lightweight standards family aimed at supporting the implementation of IT service management (ITSM), including federated scenarios. The FitSM approach is built on four key principles: practicality, consistency, sufficiency and extendibility. FitSM is and will remain free for everybody. This covers all parts of the standard, including the core parts and implementation aids. All parts of the FitSM standard and related material published by the FitSM working group are licensed under a Creative Commons International License. The development of FitSM was supported by the European Commission as part of the Seventh Framework Programme. FitSM is maintained by ITEMO e.V., a non-profit partnership of specialists in the field of IT management, including experts from industry and research. FitSM is designed to be compatible with other ITSM frameworks such as the International Standard ISO/IEC 20000 and ITIL good practices. However, the FitSM process model, requirements, recommended activities and role model target a lightweight and more achievable implementation. The FitSM family is made up of several documents, providing guidance and input on different aspects of ITSM: ● FitSM-0: Overview and vocabulary ● FitSM-1: Requirements ● FitSM-2: Process activities and implementation (this document) ● FitSM-3: Role model ● FitSM-4: Templates and samples (set of documents under continual development) ● FitSM-5: Implementation guides (set of documents under continual development) ● FitSM-6: Maturity and capability assessment scheme All documents are available and published in their most recent version through the website www.fitsm.eu. Enquiries about the standard and its applicability should be made via www.fitsm.eu/contact-us/. 2. About this document The process activities and related implementation aspects stated in this part of the FitSM standards series are aimed at supporting effective, lightweight IT service management (ITSM) processes in an organisation delivering IT services to customers, and harmonising ITSM across federations. This part of the standard provides: ● an overview of the recommended activities to be carried out to establish a service management system (SMS), based on the general requirements (GR1 to GR7) from FitSM-1. ● an overview of the recommended activities to set up and operate ITSM processes, based on the process-specific requirements (PR1 to PR14) from FitSM-1. This standard is applicable to all types of organisations (e.g. commercial enterprises, government agencies, non-profit organisations) from which IT services are provided, regardless of type, size and the nature of the services delivered, including federated scenarios. For the purpose of this standard, the terms and definitions according to FitSM-0: Overview and vocabulary apply. Part 2: Process activities and implementation Page 2 Version 3.0.2 3. Recommended activities to establish an SMS The following recommended activities may be applied in the context a service management system (SMS) designed according to the requirements from FitSM-1. While this section focuses on the general aspects and requirements of planning and implementing and effective SMS, section 4 of this document addresses the process-specific activities. GR1 Top Management Commitment & Accountability (MCA) OBJECTIVE To ensure that top management of the organisation(s) involved in the delivery of services is clearly committed to a serviceand process-oriented approach and that they fulfil their leadership duties KEY QUESTIONS ● Who is the overall owner of ITSM topics (the SMS owner)? ● How to ensure sufficient top management buy-in for the implementation of ITSM? ● How to ensure sufficient and broad awareness of ITSM and the ITSM goals and plans? INITIAL SETUP OF THE SMS ● Prepare a problem statement outlining the issues caused by lack of ITSM and the consequent motivation for implementing or improving ITSM. ● Define the role of the SMS owner and assign this role to a top management representative of the organisation(s) involved in delivering services to customers. ● Define and document a general service management policy (under consideration of the problem statement mentioned above), and have it approved by top management. ● Produce a communication plan considering relevant stakeholders. ● Create a clear understanding of the topics and desired outcomes of regular management reviews. OPERATION AND MAINTENANCE OF THE SMS ● Review and update the service management policy at regular intervals. ● Perform planned communication activities to ensure awareness within the service provider. ● Review and update the communication plan at regular intervals. ● Perform management reviews of the SMS at regular intervals. KEY OUTPUTS ● Assignment of the SMS owner ● General service management policy ● Communication plan ● Documented results and follow-up actions from management reviews Part 2: Process activities and implementation Page 3 Version 3.0.2 GR2 Documentation (DOC) OBJECTIVE To ensure that key elements of the SMS are sufficiently documented to support and enhance effectiveness and traceability of ITSM KEY QUESTIONS ● What is useful and necessary to be documented within the SMS? ● How can you ensure that documents are accessible, up to date and changes to them are controlled? INITIAL SETUP OF THE SMS ● Agree on the specific documents to be produced (such as policies, plans, process descriptions, service catalogue(s), SLAs, etc.). ● Define the location(s) and format(s) for key ITSM documentation (such as a central online document repository or document management tool / system, along with document templates). ● Agree on the approach and mechanisms for controlling documentation (creation and approval, communication and distribution, review and updating, as well as versioning and change tracking). OPERATION AND MAINTENANCE OF THE SMS ● Produce and maintain documentation on ITSM where agreed, defined and / or required. ● Apply document control mechanisms to all relevant pieces of documented information. KEY OUTPUTS ● Understanding of the minimum required level of documentation of the SMS ● Defined storage location(s) for ITSM documentation ● Established document control mechanisms ● Templates for key ITSM documentation Part 2: Process activities and implementation Page 4 Version 3.0.2 GR3 Scope & Stakeholders of IT Service Management (SCS) OBJECTIVE To understand stakeholders’ needs and expectations and define the scope of the SMS KEY QUESTIONS ● Who are the stakeholders of the services delivered and of the underlying SMS? ● What are the needs and expectations of these stakeholders? ● What are the relevant legal and contractual requirements that need to be taken into consideration? ● Which activities in the context of managing IT services are under control of the SMS, and which are not? INITIAL SETUP OF THE SMS ● Identify the stakeholders of the services to be delivered (such as customers, suppliers, public authorities and individual persons). ● For each stakeholder, analyse their needs and expectations with respect to the services as well as the underlying SMS. ● Discuss the required scope of the SMS by defining to which services, technologies, geographical locations, involved organisations and customers it applies. ● Produce a (formal) scope statement. OPERATION AND MAINTENANCE OF THE SMS ● Update the stakeholder analysis at regular intervals. ● Review the scope statement at regular intervals and consider extending or reducing the scope to align the SMS to relevant requirements. KEY OUTPUTS ● Stakeholder analysis ● Scope statement for the SMS Part 2: Process activities and implementation Page 5 Version 3.0.2 GR4 Planning IT Service Management (PLAN) OBJECTIVE To create plans for implementing and maintaining ITSM in an organisation or federation, based on the identified scope KEY QUESTIONS ● What are the ITSM-related goals to be achieved during the planning period? ● What is a realistic and achievable timeline of activities towards these goals, also considering available resources? ● Who is responsible for the different activities, and do they have the awareness and skills needed to carry them out? ● What tools or technologies are available or needed to effectively support ITSM-related activities? INITIAL SETUP OF THE SMS ● Assess the maturity of current ITSM. ● Set an appropriate target level of maturity for ITSM to be achieved. ● Determine and describe the gaps between defined goals and the current baseline (gap analysis). ● Identify and specify the steps towards improvement based on the identified gaps. ● Produce a service management plan. As part of this, among other things: o Define the goals and activities of implementing the SMS and the related ITSM processes, including a timeline for each planned activity and important milestones to be achieved. o Define and assign general and process-related roles and responsibilities in the SMS. o Define necessary training and awareness activities for the individuals involved in or affected by the SMS. o Clarify which tools are going to be used to support the implementation of the SMS and execution of the ITSM processes. ● Produce process-specific plans, as required (such as a plan covering the initial process setup activities for a given ITSM process). OPERATION AND MAINTENANCE OF THE SMS ● Review and update the service management plan at regular intervals. ● Review process-specific plans at regular intervals and keep them aligned to the overall service management plan. KEY OUTPUTS ● Service management plan ● Process-specific plans, as required Part 2: Process activities and implementation Page 6 Version 3.0.2 GR5 Implementing IT Service Management (DO) OBJECTIVE To implement ITSM according to plans and ensure ITSM processes are followed in practice as defined KEY QUESTIONS ● How is compliance with plans, defined processes, policies and procedures encouraged and enforced? INITIAL SETUP OF THE SMS ● Distribute and communicate the initial service management plan. ● Define how to minimise potential deviations from plans, including managing any resistance. OPERATION AND MAINTENANCE OF THE SMS ● Implement and operate the SMS according to the current version of the service management plan. ● Respond to unforeseen obstacles or issues arising in the implementation of the service management plan. ● Identify and perform actions to support and enforce the application of defined ITSM processes in practice, such as effective communication, awareness and training activities as well as disciplinary measures as a last resort for those not adhering to processes, related policies or procedures. KEY OUTPUTS ● Implementation progress according to plans Part 2: Process activities and implementation Page 7 Version 3.0.2 GR6 Monitoring & Reviewing IT Service Management (CHECK) OBJECTIVE To examine the level of conformity, effectiveness and efficiency of the SMS, and assess its organisational maturity KEY QUESTIONS ● To what extent does implementation progress of the SMS match plans? ● How effective and efficient are the ITSM processes in achieving defined goals? ● How can measurements, assessments and audits be utilised to evaluate the SMS? INITIAL SETUP OF THE SMS ● Define measurable key performance indicators in support of the most relevant goals to monitor effectiveness and efficiency of the SMS. For each key performance indicator, define target values and the means of collection and reporting. ● Define an SMS assessment or audit program taking into account the status and importance of the ITSM processes to be evaluated. OPERATION AND MAINTENANCE OF THE SMS ● Regularly monitor the defined key performance indicators and evaluate results against targets. ● Perform assessments and audits according to plans. ● Report on the results of measurements, assessments and audits to all relevant parties, including the SMS owner. ● Review and update the definitions of key performance indicators as well as the assessment and audit program based on previous results and the current maturity of the SMS. KEY OUTPUTS ● Definitions of key performance indicators ● Assessment or audit program ● Results and reports of measurements, assessments and audits ● Identified nonconformities, deviations from goals and opportunities for improvement Part 2: Process activities and implementation Page 14 Version 3.0.2 ISM SLAs with agreed information security targets as a basis for identifying overall security requirements CRM Service catalogue for available services that are offered to customers SLAs reflecting what has been agreed with customers together with service reports to support service reviews with customers SUPPM OLAs and UAs together with reports on operational targets to support supplier performance evaluation Part 2: Process activities and implementation Page 15 Version 3.0.2 PR3 Service Reporting Management (SRM) OBJECTIVE To specify reports on services and processes and ensure they are produced and delivered KEY QUESTIONS ● Which reports are required by customers and other interested parties? ● Which services are required by internal stakeholders in order to effectively manage the SMS? ● What is the required frequency and content of these reports? ● Are reports actually produced and distributed as required and agreed? ACTIVITIES: INITIAL PROCESS SETUP ● Create a list of all reports that are currently produced or will be produced on a regular basis. ● Specify every identified report by giving the report a unique name (ID), describing the purpose of the report, identifying its audience / addressee, defining its frequency, outlining the intended contents of the report and defining its format and method of delivery. ● Define templates for reports to standardise / harmonise the report structure and support effective and repeatable reporting. PROCESS INPUTS ● Reporting requirements (e.g. from SLAs) ACTIVITIES: ONGOING PROCESS EXECUTION ● Identify reporting requirements o Derive targets, events and nonconformities to be reported to customers based on SLAs o Identify targets, events and nonconformities to be reported to internal stakeholders to support management of the SMS ● Maintain report specifications o Define/specify a new report o Update a report specification o Terminate a report ● Monitor the production and distribution of reports o Verify the production and distribution of reports according to specifications o Initiate follow-up actions in case of inaccurate reporting PROCESS OUTPUTS ● List of all (agreed) reports ● Specification of all reports ● Reports PROCESS CHART Part 2: Process activities and implementation Page 16 Version 3.0.2 KEY INTERFACES From process Input / Interface SLM SLAs with agreed service targets as a basis for identifying service reporting requirements, i.e. understanding the reporting requirements agreed in SLAs Data from evaluation of SLAs, OLAs and UAs as a basis for reports SACM Service availability data as a basis for reports CAPM Performance and utilisation data as a basis for reports To process Output / Interface CRM Relevant reports as a basis for managing customer relationships and customer satisfaction CSI Service reports as an information basis related to opportunities for improving services and the SMS Part 2: Process activities and implementation Page 17 Version 3.0.2 PR4 Service Availability & Continuity Management (SACM) OBJECTIVE To ensure sufficient service availability and continuity to meet service targets KEY QUESTIONS ● How are the requirements for service availability and continuity determined? ● How are the measures planned that have to be taken to meet the requirements? ● How is service availability monitored? ACTIVITIES: INITIAL PROCESS SETUP ● Identify the most critical service availability and continuity requirements based on SLAs and other sources of information. ● Define the structure and format of a (generic) service availability and continuity plan. ● Define an approach to monitor service availability (and continuity) and to record the results on an ongoing basis. PROCESS INPUTS ● Service availability and continuity requirements (e.g. from SLAs) ● Risk factors having impact on the capability of delivering services according to agreed availability and continuity targets ACTIVITIES: ONGOING PROCESS EXECUTION ● Identify service availability and continuity requirements o Derive availability targets from SLAs o Identify continuity requirements based on SLAs and business impact analysis ● Maintain and implement service availability and continuity plans o Assess risks related to service availability and continuity o Create service continuity and availability plans o Implement preventive measures from plans o Review, update or terminate service continuity and availability plans ● Evaluate service availability and continuity o Monitor service availability o Perform service continuity tests for reactive measures from plans PROCESS OUTPUTS ● Service availability and continuity plans ● Service availability data ● Requests for change PROCESS CHART Part 2: Process activities and implementation Page 18 Version 3.0.2 KEY INTERFACES From process Input / Interface SLM SLAs with agreed service availability and continuity targets as a basis for identifying overall availability and continuity requirements To process Output / Interface CHM Requests for change addressing required updates or modifications to CIs as a basis for implementing the measures necessary to enable the IT service environment to meet identified availability and continuity requirements SRM Service availability data as a basis for reports Part 2: Process activities and implementation Page 19 Version 3.0.2 PR5 Capacity Management (CAPM) OBJECTIVE To ensure sufficient capacity and service performance to meet service targets KEY QUESTIONS ● How are the requirements for service performance and capacity determined? ● How are the measures planned that have to be taken to meet the requirements? ● How is service performance and utilisation monitored? ACTIVITIES: INITIAL PROCESS SETUP ● Define the structure and format of a (generic) capacity plan. ● Define an approach to monitor service performance and capacity (including utilisation of resources) and to record the results on an ongoing basis. PROCESS INPUTS ● Service performance and capacity requirements (e.g. from SLAs) ● Current level of capacities plus information on the past, current and future (predicted) utilisation of resources ● Information on available resources and constraints ACTIVITIES: ONGOING PROCESS EXECUTION ● Identify service capacity and performance requirements o Derive performance targets from SLAs o Translate performance targets into capacity requirements ● Maintain and implement capacity plans o Create capacity plans o Ensure capacity according to plans o Review, update or terminate capacity plans ● Evaluate service performance o Monitor performance of services and service components o Monitor capacity including assessment against thresholds o Respond when capacity thresholds are exceeded PROCESS OUTPUTS ● Capacity plans (reflecting demands, planned upgrades, downgrades and reallocations of resources) ● Capacity and service performance monitoring plans / concept ● Capacity and service performance monitoring records / reports PROCESS CHART Part 2: Process activities and implementation Page 20 Version 3.0.2 KEY INTERFACES From process Input / Interface SLM SLAs with agreed capacity and performance targets as a basis for identifying overall capacity and performance requirements To process Output / Interface CHM Request for changes addressing required updates or modifications to CIs as a basis for implementing the capacity planning to enable the IT service environment to meet identified capacity and performance requirements SRM Performance and utilisation data as a basis for reports Part 2: Process activities and implementation Page 21 Version 3.0.2 PR6 Information Security Management (ISM) OBJECTIVE To preserve confidentiality, integrity and availability of information related to managing and delivering services KEY QUESTIONS ● How are information security requirements determined? ● How are information security controls and policies established, based on an understanding of relevant risks? ● How are information security events monitored and information security incidents handled? ● How are access rights managed? ACTIVITIES: INITIAL PROCESS SETUP ● Define a scheme to classify information assets according to their sensitivity / criticality. ● Define a way to document an inventory of (information) assets. ● Identify, describe and classify the most important information assets. ● Identify the most important links between service components such as informationprocessing systems / facilities and the information assets identified before. ● Define a method / scheme to identify and assess information security risks. ● Perform an initial risk assessment, based on the identified assets, and focused on the most significant information security risks. ● Define clear information security policies as a basis for effective information security governance. ● Define a way to document information security controls and to monitor their status and progress of implementation. ● Identify and document the most important technical, physical and organisational information security controls in place. PROCESS INPUTS ● Information security requirements (from SLAs, legislation, contracts) ● Assets to be protected ● Relevant risk factors (vulnerabilities, hazards) ACTIVITIES: ONGOING PROCESS EXECUTION ● Identify information security requirements o Derive information security requirements from SLAs o Identify information (assets) to be protected and their needs in terms of confidentiality, integrity and availability ● Maintain and implement information security controls and policies o Assess risks related information security o Create information security policies and define other controls o Implement information security controls o Review, update or terminate information security policies and other controls ● Evaluate information security o Monitor, record and classify information security events o Identify and handle information security incidents Part 2: Process activities and implementation Page 22 Version 3.0.2 ● Perform access control o Process requests for access rights o Provide access rights o Modify or revoke access rights o Review access rights (at regular intervals) PROCESS OUTPUTS ● Up-to-date inventory of information assets ● Approved information security policies ● Up-to-date information security risk assessment ● Documented information security controls ● Reports on information security events, incidents and follow-up actions ● Documented information on access rights and their reviews PROCESS CHART KEY INTERFACES From process Input / Interface SLM SLAs with agreed information security targets as a basis for identifying overall security requirements To process Output / Interface CHM Requests for changes addressing required updates or modifications to CIs as a basis for implementing the information security controls as far as they relate to CIs supporting the services Part 2: Process activities and implementation Page 23 Version 3.0.2 PR7 Customer Relationship Management (CRM) OBJECTIVE To establish and maintain good relationships with customers receiving services KEY QUESTIONS ● Who are the customers and users of the IT services? ● How are the relationships with customers managed, and what are the best ways to get or stay in touch with your customers? ● Are the services matching customer needs and leading to customer satisfaction? ● How are customer complaints handled? ACTIVITIES: INITIAL PROCESS SETUP ● Set up an initial customer database, and for each service customer document the most important information including contact information. ● Decide on general communication channels to be used for customer engagement (e.g. ordering, escalation and complaints). ● Define a way to perform and document the results of a service review. ● Define a way to record, respond to and follow-up a customer complaint. ● Define a way to evaluate customer satisfaction on a regular basis, e.g. (online) surveys. PROCESS INPUTS ● Information on service customers ● Current service catalogue ● Customer demands and requirements ● Existing SLAs with customers ● Customer complaints ACTIVITIES: ONGOING PROCESS EXECUTION ● Maintain the customer database o Add a new customer to the customer database (including contact information) o Update the information on a customer in the customer database o Remove a customer from the customer database ● Perform customer service reviews o Plan and prepare service reviews with customers o Perform and record a service review with a customer ● Handle customer complaints o Register, address and close a customer complaint o Track the implementation status of actions following a customer complaint o Review all customer complaints and follow-up actions periodically ● Manage customer satisfaction o Plan and implement measures to assess customer satisfaction o Initiate follow-up actions in response to insufficient customer satisfaction PROCESS OUTPUTS ● Up-to-date database of service customers (customer database) ● Service review reports ● Customer complaints records ● Customer satisfaction reports PROCESS CHART Part 2: Process activities and implementation Page 30 Version 3.0.2 PR10 Problem Management (PM) OBJECTIVE To identify and investigate problems in order to reduce their impact or prevent them from causing further incidents KEY QUESTIONS ● How are problems identified? ● How are problems investigated and handled in a way that their impact is minimised? ● What information on known errors and workarounds need to be maintained? ACTIVITIES: INITIAL PROCESS SETUP ● Define a standardised and repeatable way to register problems, known errors and related workarounds, and set up an initial known error database (KEDB) using a suitable tool or other form of documentation. ● Set up a tool (e.g. ticket / workflow tool) supporting the recording and handling (including classification, prioritisation, escalation, closure) of identified problems. ● Make sure relevant information on incidents, including incident records and reports, and the CMDB are accessible to process staff performing problem identification and investigation. ● Ensure process staff involved in both ISRM and PM are aware of the different goals and perspectives of these processes, even when in practice some activities may overlap or happen almost in parallel. PROCESS INPUTS ● Statistics on incidents and service requests (for trend analysis) ● Incident and service request records ● Other relevant sources of information to identify (new) problems, including change and release records ● Configuration information (CMDB) ACTIVITIES: ONGOING PROCESS EXECUTION ● Identify problems o Perform regular incident pattern and trend analysis to identify (potential) problems o Register a problem ● Handle problems o Classify and prioritise a problem o Identify the root cause and categorise the problem as a known error o Identify one or more workarounds where possible o Assess options for resolution of a problem, and resolve a problem where appropriate o Close a problem (following resolution or when no longer relevant) ● Maintain the KEDB o Add a known error (including one or more workarounds) to the KEDB o Update or deactivate a known error record in the KEDB PROCESS OUTPUTS Part 2: Process activities and implementation Page 31 Version 3.0.2 ● Up-to-date KEDB with information (records) on problems, known errors and related workarounds ● Requests for changes raised to trigger the change management process, in order to resolve the underlying root cause(s) of identified problems / known errors PROCESS CHART KEY INTERFACES From process Input / Interface ISRM Trend information on incidents, including information from incident tickets and reports, to enable pattern and trend analysis CONFM CMDB containing information on configuration items and their relationships to support the classification, prioritisation and investigation of problems To process Output / Interface CHM Requests for changes to resolve / eliminate problems ISRM Known error database (KEDB) containing information on known errors and related workarounds to support the resolution of incidents caused by known errors Part 2: Process activities and implementation Page 32 Version 3.0.2 PR11 Configuration Management (CONFM) OBJECTIVE To provide and maintain a logical model of configuration items in support of other service management activities KEY QUESTIONS ● For the services offered: What is considered a CI, and what is not? ● What information needs to be maintained in the CMDB for each CI? ● How to ensure that the information in the CDMB is correct and up-to-date? ACTIVITIES: INITIAL PROCESS SETUP ● Define the scope of the configuration management process and the integrated configuration management database (CMDB). ● Agree the level of detail of configuration information to be collected. ● Identify and define CI types (including their attributes) and relationship types. ● Based on the defined scope, identify all existing sources of configuration information in the environment of the service provider. ● Define the concept for integrating available sources of configuration information and add missing configuration information to the integrated CMDB, including the selection of appropriate supporting technology / tools. PROCESS INPUTS ● Relevant information / data on configuration items (CIs) and their relationships ● Information on changes to CIs ACTIVITIES: ONGOING PROCESS EXECUTION ● Maintain configuration information o Record new CI in the CMDB (create a configuration record) o Update information on a CI ● Verify configuration information o Plan configuration verification o Perform configuration verification (to identify errors or inconsistencies in configuration information and trigger corrective actions) PROCESS OUTPUTS ● Up-to-date logical model of all relevant CIs and their attributes and relationships, reflected by the information / records stored in the configuration management database (CMDB) ● Configuration verification reports PROCESS CHART Part 2: Process activities and implementation Page 33 Version 3.0.2 KEY INTERFACES From process Input / Interface CHM Information on the deployment of releases (and the changes to CIs included in the releases) required to update the CMDB and (if necessary) introduce new CI types To process Output / Interface Any Configuration information from the CMDB to support process activities Part 2: Process activities and implementation Page 34 Version 3.0.2 PR12 Change Management (CHM) OBJECTIVE To plan, approve and review changes in a controlled manner to avoid adverse impact on services KEY QUESTIONS ● What types of changes are considered, and how are changes classified accordingly? ● How are different types of changes assessed and approved? ● How do we know if a change was successful? ● How are changes planned and coordinated with deployment? ● How to ensure that information on planned changes are available to relevant parties? ACTIVITIES: INITIAL PROCESS SETUP ● Set up a tool (e.g. ticket / workflow tool) supporting the recording and handling (including classification, evaluation, approval, implementation, post implementation review) of requested and approved changes. ● Define a standardised and repeatable way of recording requests for changes (RFCs) and resulting approved changes that specifies the sources and channels through which RFCs may be raised, the required format of an RFC, and the way in which the RFC is recorded in the recording system. ● Define the criteria for identifying emergency changes, as well as a standardised and repeatable way of dealing with emergency changes from recording to closure, including an emergency change review. ● Identify well-known and recurring changes , and for each of them create a standardised change and describe, where required, the concrete steps to be carried out in order to manage the respective change effectively from recording to closure (including the steps for implementing the change and ensuring adequate traceability and documentation). ● Create a schedule of changes (including those in releases to provide an overview of change implementation). PROCESS INPUTS ● Requests for changes (RFCs) ● Information on planned releases and deployments ACTIVITIES: ONGOING PROCESS EXECUTION ● Manage change evaluation and approval o Register a change based on a request for change (RFC) o Classify a change, including checking against major change and emergency change criteria o Assess a change o Approve or reject a change (considering special conditions for major or emergency changes) ● Manage change implementation and review (in connection with RDM where applicable) o Plan and schedule a change (including technical and non-technical actions) o Implement a change o Perform a post implementation review (considering special conditions for major or emergency changes) o Close a change Part 2: Process activities and implementation Page 35 Version 3.0.2 PROCESS OUTPUTS ● Change records ● Up-to-date schedule of changes ● Post implementation review reports ● Up-to-date list of (pre-defined) standard changes and step-by-step-workflows for handling them PROCESS CHART KEY INTERFACES From process Input / Interface Any Request for change to trigger the CHM process To process Output / Interface CONFM Information on planned, approved and / or implemented changes to CIs to be reflected in the CMDB RDM Approved and planned changes that are ready for deployment to be considered for future / upcoming releases (depending on defined criteria and applicable release and deployment strategies) Change schedule with proposed deployment dates for planned and approved changes / Basis for planning and scheduling releases Part 2: Process activities and implementation Page 36 Version 3.0.2 PR13 Release & Deployment Management (RDM) OBJECTIVE To bundle changes into appropriate types of releases and to effectively deploy them KEY QUESTIONS ● How are different release and deployment strategies applied to different CIs? ● Which changes are included in which kinds of releases? ● How can releases be planned and tested prior to deployment? ● How do we know if a release was successful? ● How can unsuccessful deployments be reversed? ACTIVITIES: INITIAL PROCESS SETUP ● Define a standardised and repeatable way of defining and planning releases, based on approved changes and the schedule of changes. ● Define criteria for identifying different types of releases, such as major releases, minor releases or emergency releases. ● Define release and deployment strategies for all CIs under control of the change management process, ensuring the approach for deploying changes to a CI or a set of CIs is understood. o Define the service components and CIs which the strategy applies to, and under what conditions o Define the frequency of releases and manner of release for the strategy o Define the testing to be performed under this strategy ● Define a way to record the results of release and deployment testing and evaluation of acceptance criteria. PROCESS INPUTS ● Information on approved changes ● Change schedule ● Any release and deployment planning constraints or requirements ACTIVITIES: ONGOING PROCESS EXECUTION ● Release planning o Build a release, based on the applicable release and deployment strategy o Test a release ● Release deployment o Plan and perform communication and training for users and support staff o Prepare deployment of a release o Deploy a release o Review a release for success o Inform stakeholders of the results of the release o Close a release PROCESS OUTPUTS ● Defined and successfully deployed releases ● Information / reports on the success and failure of releases PROCESS CHART Part 2: Process activities and implementation Page 37 Version 3.0.2 KEY INTERFACES From process Input / Interface CHM Approved and planned changes that are ready for deployment to be considered for future / upcoming releases (depending on defined criteria and applicable release and deployment strategies) Change schedule with proposed deployment dates for planned and approved changes / Basis for planning and scheduling releases CONFM Configuration information (CMDB) as a basis for informed decisions in deployment planning To process Output / Interface CHM Information on deployed releases (release records) to allow for post implementation review of the bundled changes CONFM Information on the deployment of releases (and the changes to CIs included in the releases) required to update the CMDB and (if necessary) introduce new CI types ISRM Information on planned or recently deployed releases to support incident resolution (e.g. to understand if incidents are potentially related to releases) Part 2: Process activities and implementation Page 38 Version 3.0.2 Part 2: Process activities and implementation Page 39 Version 3.0.2 PR14 Continual Service Improvement Management (CSI) OBJECTIVE To plan, implement and review improvements to services and processes KEY QUESTIONS ● How are opportunities for improving services and processes identified and evaluated? ● How is the implementation of actions for improvement controlled and monitored? ACTIVITIES: INITIAL PROCESS SETUP ● Identify all relevant sources of potential suggestions for improvement. ● Define a standardised way to record suggestions for improvements from the identified sources. ● Set up a tool (e.g. ticket / workflow tool) supporting the recording and handling (including prioritisation, evaluation approval) of suggestions for improvement. PROCESS INPUTS ● Suggestions for improvements ● Results from measurements, assessments and audits of the SMS, including: o Identified nonconformities as well as deficiencies in effectiveness and efficiency of ITSM processes, and resulting opportunities for improvement o Identified deficiencies in the performance of services or supporting service components, and resulting opportunities for improvement ● Customer feedback from service reviews, complaints and satisfaction analysis / surveys ● Other sources of improvements ACTIVITIES: ONGOING PROCESS EXECUTION ● Manage evaluation of improvements o Identify and register an opportunity / suggestion for improvement o Evaluate an opportunity / suggestion for improvement ● Manage implementation of improvements o Initiate an action to address an improvement o Track the status and progress of improvement actions PROCESS OUTPUTS ● Improvements to services or the SMS ● Requests for changes PROCESS CHART