In part 2 of the series, we discussed some key considerations for a CMDB solution and expanded on those areas such as the Scope, the Roles and Responsibilities, and the Data Model. In this post, we will discuss additional areas such as Control and Verification, Key Performance Indicators, and Awareness Campaign, Communication & Training.
- Control and Verification: Who can add, change, or delete information from the CMDB and under what circumstances? Will you use some type of a gate-keeper process, like Change Management, to regulate how information coming into and being updated in CMDB? Remember trust and authenticity of the CMDB data are what make the CMDB useful. How do the relationships between CIs get determined and mapped? Not all relationships can be mapped automatically by the tools, so some manual changes to the CIs and relationships are still necessary. All updates, automated or manual, to the CIs should be tracked by the CMDB tools with a complete history and audit trails. How often do you audit the accuracy of the CMDB and reconcile the differences? Can your CMDB tools help by automating the verification and reconciliation tasks as much as possible? When you have hundreds and thousands of CIs in the CMDB, manual audit and reconciliation get labor-intensive really quickly and degrade CMDB’s usefulness rapidly over time. This area will need some well-thought-out and clear work instructions, so people will know exactly how the CMDB will be maintained.
- Key Performance Indicators: What metrics will you track in order to measure the effectiveness of your CMDB solution? I will outline some potential metrics, and you need to decide what ultimately is important to your organization. When I was planning for a CMDB solution not too long ago, I used Randy Steinberg’s “Measuring ITIL” book for gathering metric ideas and inspiration. I would recommend checking out Randy’s book, not just for configuration management but for other ITSM processes as well. The lists below outline some metrics suggested in Randy’s book and some of my own.
- Some example operational metrics:
- A: Total Number of CIs
- B: Number of CIs Audited
- C: Number of CI Errors Discovered
- D: Number of CI Changes
- E: Number of CI Changes Without Corresponding RFC
- F: Number of Incidents Related to Inaccurate CI Information
- G: Number of Change Failures Related to Inaccurate CI Information
- H: Number of CIs Without Assigned Ownership
- Some potential indicators:
- CMDB Audit Ratio: B / A (Target 100%)
- CMDB Accuracy Ratio: 1 – (C / A) (Target 100%)
- CMDB Compliance Ratio: 1 – (E / D) (Target 100%)
- CMDB Support to Incident Index: F (Target 0)
- CMDB Support to Change Index: G (Target 0)
- CMDB Ownership Rate: 1 – (H / A) (Target 100%)
- Some example operational metrics:
- Awareness Campaign, Communication & Training: What mechanisms will you use to get the words out about the CMDB solution? I can guarantee you that, as soon as people find out a CMDB is in the work with information that can impact or benefit their lives, they will want to have their say. This is where the governance decisions come in. Everyone is welcome to provide input, and they should especially during the data model design phase. How will the input get taken into account and how will the decisions be made? During the implementation, how will the progress be communicated? Expectations need to be reasonable and in-check because my experience tells me that people often have an inflated idea about CMDB and what it can do. Sometimes we don’t do ourselves a favor by hyping up the CMDB solution too much at the beginning. After the CMDB is ready, who will operate the tool and need to get trained? A CMDB solution is a good thing to get excited about, and people intuitively understand the benefits of CMDB when it is done well. However, we often get into the trouble of promising too much and delivering too little when it comes to CMDB. Awareness and communication are two things that will need to be sustained during design, during implementation, and well into the maintenance / care-and-feeding phases.
There are a lot to think about when planning for a CMDB solution and, for many organizations, those consideration areas I have mentioned barely scratch the surface of the real issues they face. Like many ITSM initiatives, SACM and CMDB solutions are very much people endeavors, with the process and tools, while still important, playing more of a secondary role. In the next post, I will walk through an example CMDB solution implementation scenario. It is by no mean and end-all-be-all approach, but it can be a starting point for some organizations that can use a starting position.
Links to other posts in the series
- SACM and CMDB Tools – Initial Considerations – Part 1
- SACM and CMDB Tools – Some Planning Considerations – Part 2
- SACM and CMDB Tools – Implementation Considerations – Part 4
You must be logged in to post a comment.