Why is the CMDB inaccurate

By ITIL® from Experience©

Many things can cause the Configuration Management Database (CMDB) to be inaccurate and out-of-synch with the live environment like:

Unclear scope
Unauthorized changes
Lack of integration with IT Asset Management processes
Thinking that the CMDB accuracy is the Configuration Manager’s responsibility
Shortage of process controls

First, to avoid Configuration Item (CI) accuracy problems, the scope of the CMDB must be clear to everyone. Without a clear scope of what’s in or out of the CMDB, people will interpret what they think is important to manage and leave out some Configuration Items. When the scope is simple for people to understand it is easier for them to follow the established process thus, reducing errors.

A “change to every configuration item must be authorized by Change Management”1 thus, anything discovered in the live environment which does not match the CMDB is either: a) out of scope of Configuration Management or, b) is the result of an unauthorized change.

In addition to unauthorized changes, disparities between the production environment and the CMDB can be caused by a lack of integration with complimentary processes like IT Asset Management (ITAM). For example, let’s take the scenario where an asset is not recorded in the CMDB as part of its acquisition or provisioning process. When a device is plugged into the network to be configured for a future release it gets discovered and generates a discrepancy since it is not in the CMDB. Moreover, a process is required to add Configuration Items (CI) to the CMDB which cannot be discovered such as logical CIs like services, data center racks, specialized cables or A/C units if they are in scope and tracked in the CMDB.

Other disparities can occur when the Change Management process does not initiate or trigger the disposal of the asset and the removal of its record from the CMDB as part of the RFC to decommission a CI (see How to ensure that applications and servers are decommissioned).

A common mistake is to expect the Configuration Manager to address CMDB data errors since he/she is responsible for the accuracy of the CMDB and to maintain it as a trusted source. The challenge is that it is very difficult and merely impossible for the Configuration Manager to address data errors for CIs owned by other people. The Configuration Manager is the custodian of the CMDB container, structure, format and standard; not it’s content. The CI data, belongs to each operational group. For this reason it is important to identify CI owners that are accountable for the quality of their data. This enables CI owners or Librarians to address discrepancies by:

Investigating the cause of the disparity (e.g. an unauthorized change to their CI, the lack of IT Asset Management rigor)
Resolving the issue and to reconcile the CMDB record. (see How many Configuration Librarian(s) do we need)

These responsibilities must be clearly spelled out in a process. People also need to know that they are expected to do. Thus, work instructions and training is required (see Do people need training if the ITSM tool is easy to learn) However, no amounts of training, process guides, user guides, quick reference cards, cheat sheets or checklists will be enough to keep the process operating as designed over the long term without controls. Elements of process controls includes: Clear accountability (e.g. RACI), steps to detect lack of adherence to procedures, audits, management reports, escalation process of issues to the process owner, a mechanism to rectify process deficiencies. Moreover, anyone should be able and know how to report a data error that initiates a process whereby the CI owner or their Configuration Librarian is accountable to rectify the issue.

Thus far, technology has not been mentioned. A common mistake is to believe that implementing a CMDB is a technology project when in fact it is all about people and process. Technology on its own cannot keep a CMDB accurate. As such training, process controls will be useless if people do not see a benefit for them in an accurate and reliable CMDB.

Last updated on: 2016-06-08

"Don't build a CMDB to have a CMDB. Do it to fulfill requirements. If it delivers value people will do the processes to maintain it"

More Quotes

Related: