9 Steps Closer to a Successful CMS

There is no doubt that the information technology infrastructure library (ITIL) has grown to become a widely accepted reference for information technology (IT) best practices. Its version 3 (v3) approach for service lifecycle management was long overdue and offers some tremendous insight around Service Strategy, Design, Transition, Operation and Improvement. However, it would be a great misnomer to think that after reading any of the books in the ITIL library a practitioner would be in a position to take what they just read and make it actionable.

Service asset and configuration management (SACM) is one such area. In reading the ITIL v3 service transition book, one discovers that ITIL identifies five key activities for asset and configuration management:

1) management and planning;

2) configuration identification;

3) configuration control;

4) status accounting and reporting; and

5) verification and audit.

However, upon closer examination, the first two sentences under SACM section 4.3.5.2 management and planning state: "There is no standard template for determining the optimum approach for SACM. The management team should decide what level of configuration management is required for selected service or project that is delivering changes and how this level will be achieved."

With this limited guidance, it is surprising to see many organizations jump right into configuration management tool set implementation without establishing a clear vision of their objectives.

To help you with this task, consider using this nine-step process for creating an actionable strategy and plan for successfully implementing a configuration management system (CMS). The efforts made in properly planning and designing your CMS will place you in a better position to add value and enhance your organization's management capabilities.

Step 1: Establish a governance framework and policy

Start by assigning a configuration management process owner who will be responsible for owning the configuration management strategy, structure and process. One of the first tasks that the process owner should undertake is creating and ratifying a SACM policy. In general, a SACM policy should define:

• Scope
• Roles and responsibilities
• Policy statements
• Guiding principles
• Reference to other relevant resource material

Work to integrate the governance of the configuration management policy with the service management strategy established by your organization's senior leadership team. In a perfect world, the process owner should wield enough authority within the organization to make sure everyone is following the process.

Step 2: Define roles and responsibilities

All participants in the SACM process must understand their roles and responsibilities in order to understand the boundary and scope of their own roles, as well as related roles. During the CMS planning and design stage, plan for a higher level of resource demand and utilization. Common configuration management roles and related responsibilities include:

• Configuration manager: Oversees the process. Performs qualitative management as the highest ranking manager involved in the day-to-day process. Responsible for the day-to-day maintenance of the CMS.
• Configuration database administrators: Responsible for the day-to-day maintenance and updates to the configuration management data bases (CMDBs).
• Configuration item (CI) owners: Responsible for the status and attributes of the CI.
• Configuration database developers: Design solutions and provide technical knowledge.

Step 3: Determine the CMS primary usage

With the process owner and roles identified and positioned, this team should then consider how the CMS will facilitate all IT disciplines throughout the entire service lifecycle. Will its primary use be to facilitate incident management by identifying the caller information or identifying CI owners and support groups? Or maybe support change management by making it easier to assess impact and risk?

Other usages can include visualizing and displaying service representations, and identifying application and infrastructure component dependencies to support problem management triage. Make sure you recognize the key benefits and value propositions for each usage identified. This information can be used in the development of a business case justification, as well as in providing the necessary detail to properly prioritize each usage. An implementation roadmap should be developed that can introduce these capabilities in an orderly fashion.

Common CMS usages include:

• Incident management
• Event management
• Problem management
• Change and release deployment management
• Measurement and reporting
• Service continuity and disaster recovery
• Processes external to IT (vendor, contracts, organizational)

Step 4: Determine what types of records it will hold

By definition, a CMS provides the representation of all of the information for configuration items within scope of your organization's configuration management effort. Based upon the outcome of Step 3, determine what types of records and data will be needed to enable these capabilities. Generally speaking, a CMS integrates information from many sources including:

• Incident, problem, change and release records
• Known error and knowledge management records
• Application and infrastructure records
• IT support groups, service level agreements (SLAs), operating level agreements (OLAs) and underpinning contracts
• Corporate data about employees, suppliers, business units and services
• Measurement and reporting detail

Remember, the CMS can represent data from several different CMBDs or management data repositories (MDRs), constituting a federated CMDB.

Step 5: Determine existing data repositories

Begin by taking an inventory of your organization's existing data repositories. This should include data sources both internal and external to IT, in accordance with your organization's data requirements identified in Step 4 and will facilitate establishing priorities for each usage. This information may appear in the form of a list or spreadsheet, or reside in formal databases. Once these data repositories are identified, it is equally important to discover the following information for each:

• Primary purpose of the data
• Location
• Owner
• Users of the data
• Accuracy of the data
• Completeness of the data
• Level of data detail (too little or too much)
• How is the data supported and maintained?
• Is the data integrated with change management?
• What is the single trusted source for the data?
• Is the data federated or is it replicated?

Next assess and plan the level of work associated with scrubbing the data and gathering new data in support of the requirements. In some instances, you might even find that discarding data will be required.

In part II, Marty will go over what tools are avaialbe to help, how to decide on CIs and a CMS structure, and the outlines of a continuous improvement process.

Marty Likier is a senior consultant in Forsythe's IT service management practice. He can be reached at mlikier@forysthe.com.