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?

Step 6: Understand what tools are available to support the process

Investigate what current tools are available within your organization for collecting, storing, managing and updating the CMS data. Identify which tools meet the defined requirements, and which requirements have yet to be met by existing tools. Knowing your tool inventory will have a huge affect on the creation of your organization's eventual data model and CMS structure.

Use tools to automate data collection and help mitigate the risk of errors that can be introduced by manual data entry and maintenance. An effort should be made to identify any additional tools that could help in the automation process and determine if a business case can be made to support their purchase. While developing a business case can be difficult, aligning it back to the planning activities conducted in steps three and five will help justify their purchase.

Step 7: Decide on a configuration item (CI) categorization and naming scheme

Start by determining how the CIs will be categorized. Many organizations find using Type; Family; Class; to be an acceptable starting point. An example of this would include be: Type: Hardware; Family: Server; Class: Windows.

Next, decide on a naming convention. A naming convention is essential for organizations where data needs to be integrated into the CMS, but is stored in multiple CMDBs across the enterprise. Utilizing a standard naming convention helps to ensure the integrity of other IT service management processes such as incident management and measurement and reporting.

Step 8: Decide on CMS structure

After categorization and naming conventions are in place, design your CMS structure. Your CMS structure should be aligned with the primary usages established in Step 3 and designed with the goal of satisfying their priorities. Many organizations design their CMS structure in a manner where is a balance between:

1. Breadth: the number of families and categories of CIs that will be tracked.
2. Depth: the extent to which component CIs will be tracked. For example, the disk drives or cards within a server can be tracked as CIs.
3. Detail: the number of attributes and types of relationships for each class of CI that will be tracked.

A good rule of thumb when designing a CMS structure is to lean on the side of collecting less detail rather than more. Not all available data provides value. In fact, collecting excessive data can lead to a CMS system that is expensive and difficult to build and maintain.

Once the CMS structure is defined, you should determine your organization’s CI population approach (this can include using a phased or wave approach) and the order of execution. It is also important to identify ownership and support group structure for all CIs. The following table provides an example of what this approach might look like.

Step 9: Establish an improvement process

It is extremely important to plan for improvements and their implementation. Usually, the most successful improvement programs are the ones that are designed to bring gradual but continual improvement. One of the most widely used improvement processes is the Deming Cycle: Plan; Do; Check; Act.

To ensuring your CMS is providing the expected value, review each of the CMS usages defined in Step 3, and then validate how well the CMS is meeting those needs. This requires a measurement and reporting strategy coupled with a continual improvement process. The ITIL library has dedicated a whole book to the subject of continual improvement and includes a detailed seven-step improvement process that provides a circular set of activities designed to help organizations improve. ITIL's continual service improvement book is a great starting point to address this need.

Benefits of the 9 steps

Using this nine-step approach can help you develop your own configuration management plan and reduce many of the frustrations experienced by your IT staff that read the ITIL library and still feel like they don’t know where or even how to begin. This approach also reduces the risk associated with attempting to implement a CMS/CMDB without adequate analysis and design, namely the risk of an outcome that is not required, or of a tool set that provides little value or management capability.

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

Source: itsmwatch