12 minute read
2 Service asset and configuration management process
2.1 Overview and process diagram
The process of service asset and configuration management is shown in Figure 1 and summarised below.
Figure 1: Service asset and configuration management process
Source: Based on ITIL Service Transition Book 2011. Copyright © AXELOS Limited 2011. Reproduced under license from AXELOS.
Management and planning will take place at two main levels. The first is at the overall management level and will encompass the definition of the approach for service asset and configuration management, including the creation of a policy and the configuration management system (CMS). The second level is at the start of a project for a new or changed service, during which a SACM plan will be defined for that specific project, including procedures for the identification of CIs and the establishment of baselines.
Configuration identification will involve the documentation of the individual CIs, including their attributes, unique identifiers, configuration structures and relationships.
Once the CIs have been identified, procedures will be defined for their proper control so that their integrity and that of the CMS records is maintained. Use of these procedures will ensure that all activity with regard to CIs, such as adding, modifying, replacing or removing them is carried out in a standardized way.
During their lifecycle, CIs will go through a series of statuses (e.g. draft, approved, withdrawn) which at key points need to be updated and reports produced for use in other service management processes e.g. release and deployment management.
Verification and audit of configuration records is essential to ensure that they stay accurate and reflect the real world. This may consist of physical audits at specific locations (e.g. for desktop computers and printers) and logical audits for software CIs and bespoke modules, in addition to other forms of verification where required.
2.2 Process triggers
The service asset and configuration management process is initiated as a result of one or more of the following triggers:
• Initiation of a project that requires the introduction or changing of CIs • Requests from change management and release and deployment management • Significant events such as an ITSCM or security incident • Changes to legal, regulatory or contractual requirements • In response to audit requirements
2.3 Process inputs
The process of service asset and configuration management requires a number of inputs in order to be able to function effectively. These may not always be available but will ideally be:
• Definitions of service asset and configuration management requirements from projects • New configuration item details e.g. hardware manufacturer, model, serial number
• Requests for Change (RFCs) • Audit records • Hardware and software disposal records
2.4 Process activities
The individual process activities at each step are detailed as follows.
2.4.1 Management and planning
Planning of SACM will take place at the high level to establish and operate the process and at a lower level for individual projects.
The initial high-level planning of service asset and configuration management within [Organization Name] will establish the following factors:
• The scope of SACM and CIs to be recorded • The objectives to be achieved • Resources to be allocated both for initial setup and for on-going operation of the
SACM process • Tools to be used to identify, record, manage and report on configuration items within the CMS • Timescales for the establishment of an effective process • Roles and responsibilities in the configuration management process
This will include the definition of a SACM policy which describes the principles that will be adopted and the general rules that will be followed.
At the project level a SACM plan will be produced for each project that involves significant change within the areas in scope. This will set out the approach that will be taken to SACM within the project, including:
• Identification of configuration items • Storage of CIs within the various environments used (development, test etc.) • Check in/check out procedures for software components • Configuration and management of build environments • Definition of baselines and their timing within the project • Approach to the retirement of replaced CIs
Project-specific procedures will be produced where required.
2.4.2 Configuration identification
Configuration Items (CIs) will be identified based on the following general principles:
• There will be three types of CI, namely hardware, software and documentation • The level of CI will be determined according to the value of the information to the delivery of IT services • The attributes recorded for each CI type will be determined based on a balance of usefulness and ease of maintenance
The following attributes will be recorded according to the CI type:
Hardware
The following types of configuration items will be recorded (this list will be updated as further types of hardware items are implemented):
• Desktop hardware • Monitors • Laptops • Printers • Servers • Firewalls • Routers • Switches • Other
The attributes listed below will be recorded.
ATTRIBUTE
Asset Number
Description
Status
Relationships
Location/User
Type
Manufacturer
Serial number
Model number
Supply Date
Supplier
DESCRIPTION
The asset number assigned to the CI
A text description of the CI e.g. “Internet Router” Whether the CI is live, disposed etc.
How this CI is related to other CIs and service components
The current user or location of the CI
The type of hardware e.g. desktop, router, laptop
The manufacturer’s name The unique manufacturers serial number
The manufacturers assigned full product code
The date the CI was supplied
Where the CI was sourced from
ATTRIBUTE DESCRIPTION
Cost The costs of the CI when sourced
Purchase Order Number Reference for the PO on which this CI was ordered
PO Date
Invoice # Date of approval of the PO
If known
Invoice Date If known
Date of Installation The date the CI was installed into the live environment
Change Numbers The numbers of all change records affecting this CI
Problem Numbers The numbers of all problem and known error records affecting this CI
Incident Numbers The numbers of all incident records affecting this CI
Comment A free-format text field for any relevant information
Table 1: Hardware CI attributes
Software
All application software in use will be recorded as CIs in the CMDB. This includes serverbased systems as well as desktop software such as office suites. The attributes listed below will be recorded.
ATTRIBUTE DESCRIPTION
CI Name
Description
The unique name by which this CI is known
A text description of the CI
Status Whether the CI is live, disposed etc.
Relationships
Supplier How this CI is related to other CIs and service components
The supplier’s name Version number The manufacturers assigned version number e.g. R33 DML Reference/location The reference of this software item within the Definitive Media Library
Supply Date
Supplier
Cost The date the CI was supplied
Where the CI was sourced from
The costs of the CI when sourced
Date of Installation The date the CI was installed into the live environment
Maintenance/ Warranty Provider
Maintenance/ Warranty Contract Number Which organization provides maintenance/warranty services for this CI
The contract number under which maintenance/warranty is provided
Maintenance/ Warranty Expiry Date The date the relevant maintenance/warranty ends
ATTRIBUTE DESCRIPTION
Change Numbers The numbers of all change records affecting this CI
Problem Numbers The numbers of all problem and known error records affecting this CI
Incident Numbers The numbers of all incident records affecting this CI
Comment A free-format text field for any relevant information
Table 2: Software CI attributes
Documentation
It is essential that correct versions of documentation are used and updated when their subject material changes. Requests for change must include the consideration of documentation so that it remains relevant to the area it covers.
The attributes listed below will be recorded.
ATTRIBUTE DESCRIPTION
CI Name
Description
Status
Relationships
Supplier
Version number The version number of the documentation
Reference/location The location of this item of documentation within the filing structure
Date of Installation The date the CI was accepted into the live environment
Change Numbers The numbers of all change records affecting this CI
Problem Numbers The numbers of all problem and known error records affecting this CI
Incident Numbers The numbers of all incident records affecting this CI
Comment A free-format text field for any relevant information
The unique name by which this CI is known
A text description of the CI e.g. “Network Diagram” Whether the CI is live, disposed etc.
How this CI is related to other CIs and service components
The supplier’s name (if supplied or internal if not)
Table 3: Documentation CI attributes
2.4.3 Configuration control
On-going control of the configuration items recorded in the CMS will be exercised via the change management process. No CIs will be added, changed or removed unless the appropriate change management documentation has been completed and approved. Part of the change management process will be the updating of the CMS to ensure that it remains current and always reflects a true record of installed items.
Installation of common items such as desktop PCs and laptops will be treated as service requests and there will be an interface between the procurement process and SACM that ensures that items purchased are created as CIs when installed.
2.4.4 Status accounting and reporting
A set of reports will be regularly generated from the CMS in order to provide management information on the status of configuration items. These reports will include:
• List of all configuration items by site • Rack listings by server room • CIs having incidents associated with them • CIs having problems associated with them • CIs having changes associated with them • Discrepancies between the recorded status of CIs and that most recently discovered by the automated asset management tool
Ad-hoc reports will also be required to satisfy information requirements for support contracts. These may require the creation of new reports.
Other reports may be required for:
• Equipment refresh programmes • Financial or insurance purposes e.g. value of kit at a location
2.4.5 Verification and audit
An automated asset management software tool will be used to verify the hardware and software configurations of all CIs to which it has access. This exercise will be carried out on a monthly basis initially, with the frequency being adjusted according to the number of discrepancies found.
A programme of physical audits will be instituted to verify the data collected via the tool with the intention of visiting all locations within a specified period of time. This approach will be validated in the light of the results obtained – if the tool is found to maintain a very high degree of accuracy and completeness then the number of physical audits may be minimised. The IT service desk will also be used to verify data on an on-going basis when users report incidents.
Verification of CIs not covered by the software tool will be performed manually at least every six months.
2.5 Process outputs
The outputs of the service asset and configuration management process will be the following:
• New and updated configuration records • Configuration baselines • Status and accounting reports • Relationship information for use in assessing changes • An accurate CMS that provides input to the wider service knowledge management system (SKMS)
There are a number of key software tools that underpin an effective service asset and configuration management process. These are subject to change as requirements and technology are updated and so specific systems are not described here. However, the main types of tools that play a significant part in the process within [Organization Name] are as follows.
2.6.1 Configuration management system
The configuration management system (CMS) provides a way to store configuration records together with the attributes that are defined against them. It also allows relationships between CIs to be reflected so that a more effective impact assessment of changes can be made.
The CMS is interfaced with the incident, problem and change management tools so that records in each system can be linked together e.g. changes to a specific CI can be recorded and reported upon.
2.6.2 Automated asset management system
This system is capable of discovering assets located within the IT estate and automatically capturing key attributes of them such as their type, configuration and software versions. The automated asset management system works with the CMS to provide regular updates without the need to physically visit remote locations.
2.7 Communication and training
There are various forms of communication that must take place for the service asset and configuration management process to be effective. These are described below.
2.7.1 Communication with change management
SACM effectively provides a service to change management so that the potential impacts of changes can be better understood. SACM will obtain feedback from change management about the accuracy and usefulness of the information provided so that any required improvements can be identified.
Change management also provides updates to the CMS on a regular basis and the smoothness of the interface should be a subject of frequent communication.
For both these reasons the SACM process manager should be a regular attendee at Change Advisory Board (CAB) meetings.
2.7.2 Communication with IT teams
SACM needs to communicate the importance of keeping the CMS up to date to IT support teams so that there is no temptation to bypass change management and avoid updating the CMS. This will be done via awareness sessions delivered during team meetings and via other appropriate methods depending on the need.
2.7.3 Communication with projects
Project teams may need a significant degree of assistance with assessing and planning their configuration management requirements at the start of a project. This will depend upon the type and scope of the project but the SACM process manager’s attendance at progress meetings may be useful to all parties involved.
2.7.4 Process performance
It is important that the performance of the service asset and configuration management process is monitored and reported upon on a regular basis in order to assess whether the process is operating as expected. The content of performance reports is set out in section 6 of this document, but it is vital that the reports are not only produced but are also communicated to the appropriate audience.
This will include the management of IT concerning resource utilisation and allocation. Depending on the health of the process it may be appropriate to hold regular meetings with IT management to discuss the performance and agree any actions to improve it.
In addition to a well-defined process and appropriate software tools it is essential that the people aspects of service asset and configuration management are adequately addressed. The process requires that training be provided to all participants in order that it runs as smoothly as possible.
The main areas in which training will be required for service asset and configuration management are as follows.
• The service asset and configuration management process itself, including the activities, roles and responsibilities involved • Service Asset and Configuration management software tools such as the configuration management system • The basics of the technology and how it is implemented within [Organization Name] • The business, its structure, locations, priorities and people
