Configuration Management Process Guide 2r5c41

[CONFIGURATION MANAGEMENT PROCESS GUIDE] Sanmar Group

Configuration Management Process Guide Version 1.0 September 2012

Wipro Infotech

Internal Use Only

Page

I of 35

[CONFIGURATION MANAGEMENT PROCESS GUIDE] Sanmar Group 2012 This is a controlled document. Unauthorised access, copying and replication are prohibited.

This document must not be copied in whole or in parts by any means, without the written authorisation of the Head, Enterprise Quality Management, WI.

Wipro Infotech

Internal Use Only

Page

II of 35

[CONFIGURATION MANAGEMENT PROCESS GUIDE] Sanmar Group

DOCUMENT RELEASE NOTICE

This Change Management Process Guide, Version 1.0, is released for use in IT IS OU, Wipro Infotech (WI) with effect from 7th Sep 2012. This manual is subject to WI Document Control Procedure. Softcopy of the latest version of the document is available in the Process Document Repository. Comments, suggestions or queries on this document should be addressed to the IT IS Process Excellence Lead. Approved By: _________________________ Date: (Quality Head ) Authorised By: ________________________ Date: (Program Delivery Head)

Wipro Infotech

Internal Use Only

Page

III of 35

DOCUMENT REVISION LIST

Document Name:

Configuration Management Process Guide

Document No.

WI-Sanmar_group-XXX

Version No:

1.0

Owner

Configuration Management process

Revision No.

Revision Date

Wipro Infotech

Revision Description

Page Number

Rationale for change

Internal Use Only

Change Type (Add/Modify/Delete)

Update by

Page

Reviewed by

1 of 35

[CONFIGURATION MANAGEMENT PROCESS GUIDE] Sanmar Group

Abbreviations The following abbreviations have been used in the document: Abbreviation AMR CAB CI CMDB CSF DML ESM IM IT IT IS ITIL ITSM KPI OLA RFC / CR SDM SLA SME SOP SPOC

Wipro Infotech

Expansion Asset Management Repository Change Advisory Board Configuration Item Configuration Management Database Critical Success Factor Definitive Media Library Enterprise System Management Incident Management Information Technology Information Technology Infrastructure Services Information Technology Infrastructure Library Information Technology Service Management Key Performance Indicators Operational Level Agreement Request For Change / Change Request Service Desk Manager Service Level Agreement Subject Matter Expert Standard Operating Procedures Single Point Of

Internal Use Only

Page

2 of 35

[CONFIGURATION MANAGEMENT PROCESS GUIDE] Sanmar Group

TABLE OF CONTENTS ABBREVIATIONS.................................................................................................................. 5 ABOUT THE DOCUMENT.....................................................................................8 PURPOSE........................................................................................................................... 8 TARGET AUDIENCE.............................................................................................................. 8 ORGANIZATION OF THE DOCUMENT......................................................................................... 8 SECTION 1 - HIGH LEVEL PROCESS DESCRIPTION....................................................9 PROCESS OBJECTIVES.......................................................................................................... 9 POLICY.............................................................................................................................. 9 ENTRY CRITERIA.................................................................................................................. 9 PROCESS FLOW DESCRIPTION.............................................................................................. 11 SECTION 2 - ROLES AND RESPONSIBILITIES.........................................................13 PROCESS ORGANIZATION.................................................................................................... 13 CONFIGURATION MANAGER.................................................................................................. 13 ASSET MANAGER.............................................................................................................. 14 SUBJECT MATTER EXPERT................................................................................................... 14 RACI CHART.................................................................................................................... 14 SECTION 3 - LEVEL 2 PROCESS DESCRIPTION.......................................................16 (1.0) CONFIGURATION PLANNING.........................................................................................16 (2.0) CONFIGURATION IDENTIFICATION..................................................................................18 (3.0) CONFIGURATION CONTROL..........................................................................................20 (4.0) CONFIGURATION STATUS ING AND REPORTING....................................................22 (5.0) CONFIGURATION VERIFICATION AND AUDIT.....................................................................24 EXIT CRITERIA.................................................................................................................. 25 THE PROCESS IS CONSIDERED COMPLETE WHEN THE AUTHORIZED AND IDENTIFIABLE CI INFORMATION IS RECORDED ARE RECORDED AND CMDB IS UP TO DATE.............................................................25 SECTION 4 – METRICS AND EFFECTIVENESS GUIDELINES........................................26 PROCESS METRICS............................................................................................................ 26 EFFECTIVE GUIDELINES....................................................................................................... 27 APPENDIX A – CMDB TEMPLATE.........................................................................28 APPENDIX B – CONFIGURATION MANAGEMENT PLAN GUIDELINE..............................29 APPENDIX C – CI STATUS..................................................................................30 APPENDIX D – CI ATTRIBUTES...........................................................................31 APPENDIX E – STATUS ING REPORTS.....................................................32 APPENDIX F – GUIDELINES FOR CMDB AUDIT........................................................33 APPENDIX G - RELATIONSHIP WITH OTHER PROCESSES..........................................34

LIST OF FIGURES FIGURE 1: CONFIGURATION MANAGEMENT PROCESS FLOW....................................................10 Wipro Infotech

Internal Use Only

Page

3 of 35

[CONFIGURATION MANAGEMENT PROCESS GUIDE] Sanmar Group FIGURE 2: CONFIGURATION MANAGEMENT PROCESS ORGANIZATION CHART......................13 FIGURE 3: CONFIGURATION PLANNING SUB-PROCESS..............................................................16 FIGURE 4: CONFIGURATION IDENTIFICATION SUB-PROCESS....................................................18 FIGURE 5: CONFIGURATION CONTROL SUB-PROCESS...............................................................20 FIGURE 6: CONFIGURATION STATUS ING AND REPORTING SUB-PROCESS...........22 FIGURE 7: CONFIGURATION VERIFICATION AND AUDIT SUB-PROCESS....................................24

LIST OF TABLES TABLE 1: CONFIGURATION MANAGEMENT PROCESS FLOW......................................................11 TABLE 2: RESPONSIBILITY MATRIX FOR CONFIGURATION MANAGEMENT PROCESS............14 TABLE 3: CONFIGURATION PLANNING SUB-PROCESS................................................................17 TABLE 4: CONFIGURATION IDENTIFICATION SUB-PROCESS......................................................19 TABLE 5: CONFIGURATION CONTROL SUB-PROCESS.................................................................21 TABLE 6: CONFIGURATION STATUS ING AND REPORTING SUB-PROCESS..............23 TABLE 7: CONFIGURATION VERIFICATION AND AUDIT SUB-PROCESS......................................25 TABLE 8: PROCESS METRICS FOR CONFIGURATION MANAGEMENT PROCESS.....................26

Wipro Infotech

Internal Use Only

Page

4 of 35

[CONFIGURATION MANAGEMENT PROCESS GUIDE] Sanmar Group

ABOUT THE DOCUMENT Purpose The document details the implementation and the execution of the Configuration Management process. The guide is based on the best practices described in the Information Technology Infrastructure Library (ITIL) framework Version 3.

Target Audience The target audience for this document includes all Configuration Management process roles, Service Desk Agents and Managers, other service management process owners (such as Incident Manager, Change Manager, Release Manager, Capacity Manager, Asset Manager, Availability Manager, Service Level Manager), Application Development and Maintenance staff involved in Configuration Management, and Customers’ IT representatives.

Organization of the Document The document has been organised as follows: Section No. 1

Section Name

Description

Configuration Management Process Overview

2

Roles and Responsibilities

3

Level 2 Process Description

4

Metrics and Guidelines

Appendix A

CMDB Template

Appendix B Appendix C Appendix D Appendix E Appendix F

Configuration Plan Guideline CI Status

This section provides a high-level description of Configuration Management process. It describes the process objective, policies, and process flow of Configuration Management process. It also clarifies and defines how the process interrelates with other Information Technology Service Management (ITSM) processes. This section describes the key responsibilities of various roles. It represents the roles and responsibilities of Configuration Management process roles in a RACI matrix. This section provides Level 2-process description of Configuration Management process. It includes process flows, their inputs, activity, outputs and measures for each of these detailed flows. This section describes the high-level process metrics and the guidelines to ensure process effectiveness and efficiency. This template can be used as a guideline for deg CMDB This template can be used for preparing the Configuration Management Plan This provide list of possible CI status

Appendix G

Relationship processes

Effectiveness

Management

CI Attributes

This provide list of possible CI attributes

Status ing Reports

This provide list of various reports, which can be produced as a part of CI status ing This provide guidelines for conducting the CMDB audit List Configuration Management process interfaces with other IT IS processes

Guidelines for CMDB audit

Wipro Infotech

with

other

Internal Use Only

Page

5 of 35

SECTION 1 - HIGH LEVEL PROCESS DESCRIPTION Process Objectives The Configuration Management Process is used to identify, control, record, report, audit, and authorized and identifiable configuration items (CI) including their versions, baselines, constituent component, their attributes and relationships. The objectives of the Configuration Management Process include the following:  for IT assets and Configuration items within the organization and its services  Provide for the timely recording of authorized and identifiable configuration items in inventory upon acquisition or deployment  Ensure that changes to the inventory’s configuration items are controlled, reviewed and logged  Provide for the authorized disposal of configuration items recorded in inventory  Ensure that the configuration records reflect the actual status of all the configuration items  Ensure periodic review of the organization's Personal Computers to detect the use of unauthorized software, and to the compliance with the software and hardware license agreements.  Underpin and enable other Service Management processes like Incident Management, Problem Management, Change Management and Release Management

Policy Configuration Management Process policies are guiding principles for creating, deploying and managing the Configuration Management Process. The following are the policies on which this Configuration Management Process is designed.  There will be one process that will be followed for Configuration Management  All configuration items should be managed within a CMDB database  All CIs, including their version and relationships must be documented and maintained in accordance with the process and guidelines set out in the process document  There should be clear linkages between configuration items, incident records, problem records, known errors and requests for change.  All changes to CIs are submitted to configuration management by the time that the RFC is completed  CMDB will be updated for all changes to CI with the approval of Configuration Manager only  The CI will be baseline before any changes or updating  The CMDB will be baseline before any major changes or updating  All relevant IT assets and configurations within the organisation should be managed  CMDB will be audited at regular intervals  Configuration records need to be verified against the infrastructure and correction should be applied to take care of any exceptions  CI Status Reports will be generated at regular intervals

Entry Criteria Updates to configuration information are triggered by change requests, purchase orders, acquisitions and service requests.

High Level Process Overview The Configuration Management process consists of the following high level activities. 1.0 – Configuration Planning 2.0 - Configuration Identification 3.0 - Configuration Control 4.0 - Configuration Status ing and Reporting 5.0 - Configuration Verification and Audit The following diagram depicts the Configuration Management at a high level.

Figure 1: Configuration Management Process Flow

Process Flow Description Table 1: Configuration Management Process Flow Stage Procedure Input 1.0 Configuration  Policy Planning document  Various process documents like Asset Management , Change Management , Release Management etc 2.0

3.0

4.0

5.0

Configuration  Configuration Identification Management Plan  Established CMDB with various interfaces  CI Naming policy  New CI

Description  Design and establish CMDB database, tool(s) and process  Decide of CI naming convention and structure  Configure various ESM tool, Discovery tools, Asset Management system, Enterprise applications, Document File Store system  Decide and design process interfaces  Design and establish Definitive Media Library (DML)  Use business rules based on data status for baseline and status reporting of CI  Decide on archiving of data

 Receive CIs, which can include Hardwar, Application software, System software, Licenses and Project documents  Assign unique identifiers, naming and numbering conventions  Provide CI details that include CI level, category, relationship, baseline, version, status; enabling correlation between the product, configuration documentation and associated data  Once the CI is authorized, Asset Manager ensures that the asset is commissioned and installed by the staff in the production environment Configuration  New CIs  Ensure that only authorized and identifiable CIs are Control recorded and that no changes are made without an  RFCs authorization  System log generated by  Ensure tight integration with Change Management Process so as to ensure that CMDB is up-to-date discovery  Update RFC with related CIs tool(s)  Update CI record  Update the CMDB  Update CMDB after periodic checking of the existence of physical items Configuration  CIs  Produce status reports with listing of all CIs with current Status version and Change history. Refer to Appendix for  Request for ing various status ing reports report and Reporting  Report on the current, previous and planned states of the CIs should include: unique identifiers of CIs and their current status, e.g. 'under development', 'under test', 'live'.  Report on the configuration baselines, Releases & their status  Maintain change history/audit trail Configuration  Audit  Conduct formal CMDB audits at defined frequency Verification checklist  Investigate regarding uned and unauthorised and Audit  Audit CIs found, if any

Output  Configuration Management Plan  CMDB database with various interfaces designed and established  Establish DML  CI Naming policy  CI details updated in CMDB 

 Updated CIs  Updated CMDB

 Status reports

 Audit report  Erroneous CIs

Stage Procedure

Input schedule  Audit guidelines

Description  Check the CMDB is consistent with all CIs and viceversa  Check all change and release records are authorised and only authorised changes are implemented  Perform physical inspection of product and design information; assure accuracy, consistency and conformance with acceptable practices;  Log and report all exceptions

Output

SECTION 2 - ROLES AND RESPONSIBILITIES Process Organization A Configuration Management role would be a full-time role in a large service delivery organisation whereas the same role can be a shared role in a smaller organization.

Service Delivery Owner

Incident Manager

Configuration Manager

Domain Lead I

Domain Lead II

Domain Lead III

Team Member

Team Member

Team Member

Team Member

Team Member

Team Member

Team Member

Team Member

Team Member

Figure 2: Configuration Management Process Organization Chart

Configuration Manager Configuration Manager ensures that the Configuration Management Policy and Process are adhered to and to control and manage Changes to CI through their lifecycle. Responsibilities of Configuration Manager include:  Implements the organization’s Configuration Management policy and standards.  Creates and manages the Configuration Management plan, principles and processes and their implementation.  Proposes CI naming conventions.  Establishes interfaces with Change Management, Problem Management, Network Management, Release Management, computer operations, logistics, finance and istration functions.  Executes population of the CMDB. Manages and maintains CMDB, central libraries, tools, common codes and data. Ensures regular housekeeping of the CMDB.  Provides reports, including management reports, impact analysis reports and configuration status reports.

 Uses the CMDB to facilitate impact assessment for RFCs and to ensure that implemented Changes are as authorised. Ensures that the CMDB is updated when a Change is implemented.  Performs configuration audits to check that the physical IT inventory is consistent with the CMDB and initiates any necessary corrective action.

Asset Manager The Asset Manager owns the integrity and accuracy of the Asset data. This ensures that information provided is accurate. Responsibilities include:  Maintaining Asset data and the Asset data model  Monitoring of lifecycle events of Assets  A point of escalation for the Configuration Management process  Reporting asset data  Reviewing all asset discrepancies, assessing and providing variance resolution  Assist in the definition of CI classes, types, and data requirements

Subject Matter Expert Responsibilities include:  Helps in deploying tools and establishing monitoring  Supplies and/or maintains the data  Participates in audit report reviews

RACI Chart Table 2: Responsibility matrix for Configuration Management process Function CMDB planning and deg Establish CI Naming policy and guidelines Physical labelling of CI Provide CI details Establish CI relationships Submit RFC for CI change Analyzing Change request for changes in CI details Authorize Changes in CI details Make Changes in CI details Generate CI Status ing reports Maintain and provide CI Baseline and Release details Maintain and provide CI history details Raise request for audit Collect details from CMDB, system log and by physical inspection Analyze details and record deviation details

Configuration Manager A/R A/R A A/R A/R A

Asset Manager C C R I C I

Subject Matter Expert C C I C C R (Change Mgr)

A/R

I

C

R

I

R

I

A/R

I

A (Change Mgr) R (Configuration Librarian) I

A/R

I

I

A/R A

I R

I R

A/R

R

C

A/R

R

I

Function Publish Audit report Legend:

Configuration Manager A/R

Asset Manager I

Subject Matter Expert I

R

= Responsible for a particular action, but not necessarily the authority

A

= able for the action. There is only one person able for any given action.

C

= Consulted before the action (but not necessarily require approval)

I

= Informed after the action (need to know basis)

SECTION 3 - LEVEL 2 PROCESS DESCRIPTION This section explains various Configuration Management sub-processes and corresponding tasks, inputs and outputs in detail.

(1.0) Configuration Planning The planning of Configuration Management references existing procedures and plans, in order to keep things simple and to avoid duplication. The steps involved in Configuration Planning subprocess are illustrated in the following figure.

Figure 3: Configuration Planning Sub-process

Table 3: Configuration Planning Sub-Process No.

Procedure

Input

1.1

System Design

 Policy document

1.2

Establish DML

 Policy and process document(s )

1.3

CI Naming and Status Policy

 OEM naming standards

Description  Analyze relevant existing Configuration Management practices and their interfaces to the Service Management processes, procurement and development  Analyze interfaces with other systems like Document File Store system, Enterprise Applications, various Discovery tool(s), Asset Management tool, ESM tool etc  Evaluate, select and deploy the CMDB and Configuration Management tool  Configure existing tools and system to establish various interfaces with other Service Management Processes and third parties  Design policies for housekeeping, including license management, archiving and the retention period for CIs  Establish interfaces to other IT IS Change Management, Release Management, other Service Management processes, procurement and development  Decide design and location(s) of Definitive Media Library  Decide CIs to constitute of DML  Establish DML  Define interfaces with License Management and Release Management  Define how the classes of assets and configuration items are to be selected, grouped and classified and defined by appropriate characteristics  Decide on the Level of CI’s based on level of independent changes  Define the approach for to identify, uniquely naming and labelling all assets or service components

Output  Configuration Management Plan and procedure document  CMDB database with various interfaces designed and established

 Established DML

 CI naming policy

(2.0) Configuration Identification Configuration identification is the selection, identification and labelling of the configuration structures and CIs, including their respective ‘owner’ and the relationships between them. The steps involved in Configuration Identification sub-process are illustrated in the following figure.

Figure 4: Configuration Identification Sub-process

Table 4: Configuration Identification Sub-Process No.

Procedure

Input

Description

Output

2.1

Assign Physical and Logical ID

 CI Naming policy

 CI labels tagged (physical as well as logical)

2.2

Describe CI  CI attribute and build template relationship

2.3

Authorize CI

2.4

Commission CI

 The Configuration Manager, in co-ordination with the Asset Manager ensures that new asset along with all related documentation is added to the production inventory.  Select configuration document types & formats  Generate unique identifiers as per naming and numbering conventions  Accomplish labelling of systems and documentation with applicable identifiers, enabling correlation between the product, configuration documentation and associated data.  The unique CI label is physically tagged with the CI based on the organization labelling policy.  Baseline configurations  The relevant attributes are added with the CI.  CI owner is identified  CI level is determined and accordingly various relationships are established with other CIs  New CI is authorized before it can be installed in production environment. Only Configuration Manager should be allowed to authorize changes in the CMDB  Once the CI is authorized, Asset Manager ensures that the asset is installed by the staff in the production environment  Relevant software and hardware libraries are updated  CI is commissioned  Configuration Manager ensures that CI status is regularly updated during the various stages

 CI details  Authorised CI details

 CI details

 Authorised CI details  CI installed and commissioned

(3.0) Configuration Control The Configuration Manager, in co-ordination with the Asset Manager, the Infrastructure Manager, the Service Delivery Manager, the IT Manager and the Finance Manager manages the changes to the Configuration Items. The steps involved in Configuration Control sub-process are illustrated in the following figure.

Figure 5: Configuration Control Sub-process

Table 5: Configuration Control Sub-Process No. 3.1

3.2

3.3

Procedure Analyze Changes CI

to

Authorize Changes CI details

to

Make changes to CI

Input

Description

Output

 RFC  System log generated by discovery tool(s)

 Change Manager generate report on Change Request that impacts any of the CI attributes that is under the control of CMDB process and present the same in the CAB meeting  Configuration Manager analyzes Change Request for change in the CI details. The configuration update could be triggered by the need to: o Implement Request For Change (RFC) o Resolve an Incident o Fix a Problem o Enhance functionality o Improve Service performance  The CMDB details are verified against the detailed provided in the Change Request by the requester  In case a change is initiated through the discovery tool then it is verified against the system log  Configuration Manager analyzes various Changes to determine updates needed in CMDB or infrastructure  Once he authorizes these updates, Change Manager will mark the Change Request as Approved  Once the change is implemented, CMDB is updated accordingly for the changed configuration items. It is recommended that before the change is implemented, a snapshot of the Configuration Item (before the proposed change) is taken and recorded. The last <#> snapshots are to be kept to ensure stability and for rollback purposes.  The change can also be made through automated task, which is then verified by the Configuration Manager  The Configuration Manager ensures that the all CI are appropriately recorded, updated and disposed in their lifecycle.

 Analyzed RFC

 Analyzed RFC

 Approved change request

 Approved Change request  Updated CI details in CMDB

(4.0) Configuration Status ing and Reporting Configuration Status ing is the reporting of all current and historical data concerned with each CI throughout its life-cycle. The steps involved in Configuration status ing and reporting subprocess are illustrated in the following figure.

Figure 6: Configuration Status ing and Reporting Sub-process

Table 6: Configuration Status ing and Reporting Sub-Process No. 4.1

Procedure Receive/ Trigger Report Request

4.2

Create Baseline, Release

4.3

Maintain History

for

CI

Input

Description

Output

 Receive request for reports  Reporting schedule

 Configuration Manager should produce status reports on a regular basis, listing all CIs under control, their current version and Change history  The report includes: o unique identifiers of constituent CIs and their current status, e.g. 'under development', 'under test', 'live' o configuration baselines, Releases and their status o latest software item versions and their status for a system baseline/application o the person responsible for status change, e.g. from 'under test' to 'live' o open Problems/RFCs  Status ing report is used to establish system baselines and enable Changes between baselines and Releases to be traceable. The includes o baseline and Release identifiers o latest software item versions for a system build/application o the number of Changes for a system o the number of baselines and Releases o the usage and volatility of CIs o comparisons of baselines and Releases  Change history/ audit trail is maintained for all the changes made to the CI through out its life cycle

 Acknowledge ment of Report Request

 Guidelines for CI baseline, release

 Acknowled gement of report request  CI baseline and release created

 CI baseline and release created

 CI status report

(5.0) Configuration Verification and Audit Configuration verification and audit comprises a series of reviews and audits that the physical existence of CIs and check that the CIs are correctly recorded in the CMDB and controlled libraries. The steps involved in Configuration verification and audit sub-process are illustrated in the following figure.

Figure 7: Configuration Verification and Audit Sub-process

Table 7: Configuration Verification and Audit Sub-Process No.

Procedure

Input

Description

Output

5.1

Collect and Collate data

 Request for Audit  Audit schedule  Audit checklist

 Agreed with the scope of audit  Actual CI data collected (automatic or manual)

5.2

Extract Data from CMDB

 Scope of audit

 The need to conduct audit activities can be triggered by one of the following: o Automatic discovery tools will provide inventory data o Regular manual audits that are run in accordance with the audit schedule o Audits will be conducted on a need basis when information is provided that appear to indicate a more generalised error in CI data o When a large CR or project is destined to affect a large number of CIs  Configuration Manager collects and collates data for the CI. This could be via automatic or manual inspection by visiting the site.  Configuration Manager collects the data to be audited from the CMDB.

5.3

Analyze and records deviations

 Audit Checklist

5.4

Amend CMDB, infrastructure details

 Deviation / exception report  Audit report

 The collected data is compared with the CMDB data and exceptions/ deviations are determined  The exceptions are analysed in order to identify the errors. They could be within the CMDB or in the infrastructure  An audit report is submitted with the detailed findings of the audit  If the fault is with the CMDB, then CMDB is updated to match the audit findings. Alternatively if changes to the infrastructure are required, a RFC should be raised and progressed through Change Management  Respective stakeholder would be responsible to close the reported discrepancy and intimate the CMDB process owner

 CI data collected from CMDB  Deviation / exception report  Audit report

 Updated CMDB  RFC to update infrastructure  Incident for investigation

Exit Criteria The process is considered complete when the authorized and identifiable CI information is recorded are recorded and CMDB is up to date.

SECTION 4 – METRICS AND EFFECTIVENESS GUIDELINES Process Metrics Following are the Critical Success Factors (CSF) for Configuration Management process and its related KPIs. Table 8: Process Metrics for Configuration Management Process Process Metrics CSF

KPI Number of unauthorized CIs

Reduction in number of unauthorized CIs

Number of missing or duplicates CIs Percentage of incidents related to unauthorized CIs

Accuracy and Integrity of CMDB

Process Usefulness

Measurement A=Total no. of unauthorized CIs found A=Missing or duplicate CIs found A=Total no. of incidents due to unauthorized CIs

Measurement

Calculatio n A A

B=Total no. of incidents reported

A/B * 100

Number of incidents and problems linked to CI

A=Total no. of incidents not related to CI

B=Total no. of incidents

A/B * 100

Number of failed RFCs due to poor impact assessment

A=Total no. of failed changes due to poor change assessment

B=Total no. of changes

A/B * 100

Percentage reduction in service errors attributable to wrong CI information

A=total no. of service error

B=Service error due to wrong CI information

A/B * 100

Increase in FCR%

A=FCR%

Reduction in AHT Reduction in misrouted incidents Reduction in incidents for which priority changed at the later stage Reduction in incomplete incidents

A=Incident / problem Average Handling Time A=Total bouncing back tickets A=Incidents for which priority changed A=Total incomplete incidents

A

A

A

A A

Reduction in wrong or late escalation reporting Reduction in SLA breaches due to CMDB Number of CMDB audits completed as plan Effective audit

CMDB

A=Total instance of wrong or late escalation reporting

A

A=Total no. of SLA breaches

A

A=Total no. of CMDB audits completed

B=Total no. of CMDB audits planned

A/B * 100

Number of exceptions reported

A=Total no. of CI exceptions

A

Number of wasted licenses

A=Total no. of licenses being wasted

A

Effective Guidelines Documentation Ensure that the:  Process documentation is owned and identified as a unique CI in the CMDB, and is accessible by all delivery staff.  Changes to the process documentation are managed through the Change Management process for e.g. Document control system

Adherence to Policies Ensure the adherence to all process policies. For example:  All CIs should be recorded in a management system.  Access to CMDB is controlled rigidly.

Understanding of Roles and Responsibilities Ensure that all delivery staff understand and perform their roles and responsibilities within the Configuration Management process.

Standard Naming/ Numbering conventions Ensure that all configuration items are recorded/ updated with the standard naming/ numbering conventions.

CMDB Audit Ensure that CMDB is audited and status reports with management information are delivered.

Appendix A – CMDB TEMPLATE S. No.

Variable

Description

1

CI Name

The unique name by which this type of CI is known.

2

Copy or Serial Number

The number that uniquely identifies the particular instances of this CI - for example, for software the copy number, for hardware the serial number.

3

Category

Classification of a CI (ex. hardware, software, documentation etc.).

4

Type

Description of CI type, amplifying 'category' information (e.g. hardware configuration, software package, hardware device or program module).

5

Model Number (hardware)

Model of CI (corresponding, for example, to supplier's model number e.g. Dell model xxx, PC/aa model yyy).

6

Warranty expiry date

Date when the supplier's warranty expires for the CI.

7

Version Number

The version number of the CI.

8

Location

The location of the CI, e.g. the library or media where the software CIs reside, the site/room where a service is located.

9

Owner Responsible

The name and/or designation of the owner responsible for the CI.

10

Responsibility Date

Date the above owner became responsible for the CI.

11

Source/supplier

The source of the CI, e.g. developed in-house, bought in from company xxxxx etc.

12

License

License number or reference to license agreement.

13

Supply Date

Date when the CI was supplied to the organisation.

14

Accepted Date

Date when the CI was accepted by the organisation as satisfactorily tested.

15

Status (current)

The current status of the CI; e.g. under 'test', 'live', 'archived'.

16

Status (scheduled)

The next scheduled status of the CI (with the date or indication of the event that will trigger the status change).

17

Parent CI(s) relationships

The unique CI identifier(s) - name/copy/number/model/number/ of the 'parent(s)' of this CI.

18

Child CI(s) relationships

The unique CI identifier(s) of all 'children' of this CI.

19

Relationships

The relationship of the CI with all CIs other than 'parent' and 'child' (e.g. this CI 'uses' another CI, this CI 'is connected to' another CI, this CI is 'resident on' another CI, this CI 'can access' another CI).

20

RFC Numbers

The identification number of all RFCs affecting this CI.

21

Change Numbers

The identification number of all Change records affecting this CI.

24

Problem Numbers

The identification number of all Problem records affecting this CI.

25

Incident Numbers

The identification number of all Incident records affecting this CI.

26

Comment

A comment field to be used for textual narrative; for example, to provide a description of how this version of the CI is different from the previous version.

Appendix B – CONFIGURATION MANAGEMENT PLAN GUIDELINE The Configuration Management Plan needs to be developed and documented in the same way a software development plan is created at the initial stages of a project. Configuration Management planning begins during the initial stages of a project. Staffing, budget, schedule, process, and procedures should be planned and included in the overall project’s strategy. The following are items that should be included in a CM Plan:        

Introduction – Sets down the purpose, scope, and applicability of the CM Plan to the overall project. Organisation – Describes the relationship and integration of CM with all organisations on the project (including, Quality, Engineering, Customer, Management, and so on.) Project Phases and Milestones – Describes the evolution of the project with regard to CM and the establishment of both developmental and formal baselines. Configuration Identification – Discusses the selection of artefacts or work products, configuration identifiers, establishment of the project libraries, and naming or numbering conventions. Interface Management – Describes the procedures for identification of interface requirements, establishment of both internal and external interface agreement processes and procedures, and how the project will participate in the interface control working groups. Status ing – Sets down how and when status ing information will be recorded and released for the project. Information contained in status ing includes the current release of work products and status of change. Configuration Audits – Describes the plans and procedures for performing audits and verification of a product. Subcontractor Management – Describes the process and procedures to be used to ensure the subcontractors’ compliance with project requirements.

Appendix C – CI STATUS Following are the possible states for a CI:  ed: A new version of a CI has been identified (for example as part of the planning process) and its potential existence has been recorded in an Inventory.  Draft: The version is under development, including whatever review process is appropriate.  Tested: Some types of CI will be subject to testing, to determine if they correspond to their specifications.  Approved (Baseline): A version of a CI in this state is approved for end use and can be made available via a release process.  Specified: Used only for composite CI to describe the circumstances when all of the lower level CI have approved specifications. Also called the “Specification Baseline”.  Built: Used only for composite CI to describe the circumstances when the entire lower level CI have approved specifications and have been built but not yet tested. Also called the “Build Baseline”.  Superseded: A version of a CI may be superseded by a new version of the same item or by one or more different artefacts.  Withdrawn: A version of a CI may no longer be required.  Destroyed: A version of a CI has been physically destroyed and is no longer available for reference.

Appendix D – CI ATTRIBUTES The following is a non-exhaustive list of the CI attributes that can be captured, where applicable:                   

Location of artefact Unique Identifier Make Model Assigned Name Assigned Telephone Number Date of Purchase Supplier Name Supplier Telephone Number Warranty Expiry Date Maintenance Supplier Name Licence Number Hard Disk Capacity Memory Capacity Date First Entered into CMDB Date of Last Update Lifecycle State Status Owner

Appendix E – STATUS ING REPORTS Typical reports, which can be produced as a part of CI status ing and reporting               

Product configuration evolution history Change processing and implementation status Product documentation status and history Product configuration status Configuration documentation Current baselines Historic baselines Change requests / proposals Implementation of changes Change proposals Change notices Variances Warranty data / history Replacements by maintenance action Configuration verification and audit status / action item closeout

Appendix F – GUIDELINES FOR CMDB AUDIT The following is a set of guidelines based on which specific audit checklist can be prepared: 

     

Audit shall be conducted o Shortly after CI implementation o Before and after any Major changes o After recovering from disasters o In response to detection of any anomalies for e.g. detection by the Service Desk o Regular audits o Random audits Decide on sample to be audited Make list of recent Emergency Changes and Large changes; Make list of recent Major Incidents Physical configuration audits should be carried out to that the 'as-built' configuration of a CI conforms to its 'as-planned' configuration and its associated documents. Non-ed and unauthorized items that somehow make an appearance during configuration audits should be investigated, and corrective action should be taken to address possible issues with procedures and the behaviour of personnel. All exceptions should be logged and reported. If there is a high incidence of unauthorized CIs detected, the frequency of configuration audits should be increased

Appendix G - Relationship with Other Processes Following table provides a summarized view of the data flow relationships between Configuration Management and other Reference Model processes. ITIL Process Incident Management

Input to Configuration Management  New incidents linked with CI

Change Management

 New RFCs linked with CI

Problem Management

 New problem linked with CI

Asset Management

 Asset Data Model

Capacity Management

 Capacity details

Service Continuity and Availability Management Service Reporting

 Business continuity requirements  Reporting schedules

Release Deployment

 New Release affecting CI, Baseline and Version details

Service Management

and

Level

 Details about the services and link those services to Configuration Items

Output from Configuration Management  Impact of incidents  Related incidents  Configuration Item details and the relationship between various Configuration Items  Impact of given change  Configuration Item details and the relationship between various Configuration Items  Impact of problems  Related incidents/ problem/ Known Error  Configuration Item details and the relationship between various Configuration Items  Configuration Item details for various assets and the relationship between various Configuration Items  Capacity reports  Configuration Item details and the relationship between various Configuration Items  List of redundant/ resilient systems/ services  Periodic reports generated for measuring performance of IT Services.  Impact of given release  New Baseline and Version details  Configuration Item details and the relationship between various Configuration Items  Representation of the infrastructure in the form of Configuration Item details and relationship between them