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. But to think that after reading any of the books in the ITIL library, a practitioner would be in a place to take what they read and make it actionable, is at most very optimistic.
With this limited guidance, organizations should not jump right into implementing a configuration management system (CMS) without establishing a clear vision of their objectives. This nine-step plan can help you create an actionable strategy and plan for successfully implementing a CMS and 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 Service Asset and Configuration Management (SACM) policy. In general, a SACM policy should define scope, roles and responsibilities, policy statements, guiding principles, and references to other related policies, and standard operating procedures.
Step 2: Define roles and responsibilities
All participants in the SACM process should understand their roles and responsibilities. Common roles and related responsibilities include:
Configuration owner: Responsible for the overall CMS strategy and process maturation.
Configuration manager: Oversees the process and is the highest ranking manager involved in the day-to-day CMS activities. Responsible for the day-to-day maintenance of the CMS.
Configuration database administrator(s): 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.
Ensure you recognize the key benefits and value propositions for each usage identified so you can develop a business case and provide the necessary details 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, and processes external to IT (vendor, contracts and 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 outcomes of step three, determine what types of records and data can 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
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 that are internal and external to IT, in accordance with your organization’s data requirements identified in step four. This 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
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 may even find it more effective and efficient to discard existing data and start anew.
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 effect 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 may 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 and class to be an acceptable starting point. Then, decide on a naming convention. A naming convention is essential for organizations where data should 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, including incident management, 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 three 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. Not all available data provides value and collecting excessive data can lead to a CMS system that is expensive, difficult to build and challenging to 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.
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 and act).
To ensure your CMS is providing the expected value, review each of the CMS usages defined in step three and then validate how well the CMS is meeting those needs. This may require a measurement and reporting strategy combined 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 organisations improve. ITIL’s continual service improvement book is a great starting point to address this need.
The key benefits
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.