[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 Contact

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 ACCOUNTING 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 ACCOUNTING 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 ACCOUNTING 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 ACCOUNTING 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

Roles and Responsibilities

Level 2 Process Description

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 user 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
designing 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 Accounting Reports

This provide list of various reports, which can be

produced as a part of CI status accounting
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 verify
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:
Account 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 inventorys 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 verify 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 Accounting 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 support
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
Accounting
various status accounting 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 unregistered 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 organizations 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
administration 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 designing
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 Accounting 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

A/R

A (Change Mgr)
R (Configuration
Librarian)
I

A/R

A/R
A

I
R

I
R

A/R

A/R

Function
Publish Audit report
Legend:

Configuration
Manager
A/R

Asset
Manager
I

Subject Matter
Expert
I

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

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

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

= 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 CIs 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 support 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 Accounting and Reporting

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

Figure 6: Configuration Status Accounting and Reporting Sub-process

Table 6: Configuration Status Accounting 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 accounting 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 verify 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

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=Total no. of
SLA breaches

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

Number of wasted
licenses

A=Total no. of
licenses being
wasted

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

CI Name

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

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.

Category

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

Type

Description of CI type, amplifying 'category' information (e.g. hardware

configuration, software package, hardware device or program module).

Model Number (hardware)

Model of CI (corresponding, for example, to supplier's model number e.g.

Dell model xxx, PC/aa model yyy).

Warranty expiry date

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

Version Number

The version number of the CI.

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.

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 projects 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 Accounting Sets down how and when status accounting information will be recorded
and released for the project. Information contained in status accounting 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:
Registered: 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 User Name
Assigned User 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 ACCOUNTING REPORTS

Typical reports, which can be produced as a part of CI status accounting 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 verify that the 'as-built' configuration of a CI
conforms to its 'as-planned' configuration and its associated documents.
Non-registered 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