Top 6 Pitfalls to Avoid When Implementing a CMDBBy avoiding these pitfalls, organizations can significantly increase the likelihood of a successful CMDB implementation, writes ITSM Watch guest columnist Randal Locke of CA.
Pitfall 1: Failing to identify the goals and benefits of a CMDB.
The importance of given items and relationships varies from one organization to the next, but the CMDB cannot, and should not, manage every asset, document, or process throughout your entire enterprise. In this broad landscape, do not lose sight of the specific goals and benefits that apply to your own organization.
If you know how a CMDB can be used, such as understanding the impact of change, you can conduct a cost-benefit analysis that measures project objectives against the cost of CMDB purchase and implementation. Having clearly defined short-term goals and long-term plans is critical to the initial stages of a CMDB project. If you fail to properly define the goals and quantify ROI, you may have difficulty gaining management approval.
Pitfall 2: Turning your CMDB into a metadata dumping ground.
There is a difference between what can be managed in a CMDB and what should be managed in a CMDB in order to derive maximum business value. Organizations sometimes initiate their CMDB implementations by indiscriminately dumping all the data from all of their CI repositories into their CMDB, without adequately documenting relationships or managing change for the CIs.
Your CMDB should contain only those CIs that you plan to actively manage. If you dump data into the CMDB without a plan, you will quickly find yourself with a repository that is hard to manage and provides little value. When CIs are actively managed, you can perform impact analysis to understand the risks associated with current outages and pending changes in the environment. This is a crucial step in realizing value from your CMDB initiative.
Pitfall 3: Ignoring the need for effective change management.
Without an effective change management process, a CMDB will soon be out of sync with reality. Thus, the CMDB and configuration management processes must be tightly aligned to the change management process. Only authorized changes should be incorporated into the CMDB, and only CIs that are part of a request for change (RFC) should be updated. Avoiding this requirement will place the CMDB implementation on a downward spiral to failure.
Pitfall 4: Proceeding without buy-in from key stakeholders.
By their nature, CMDB implementations have a wide range of touch points within an organization. Financial, capacity and availability attributes of CIs all require input from separate departments. If key stakeholders are not involved from the beginning and if they dont buy in to the true value that a CMDB can deliver to the organization, it will be very difficult to get them to assist in the building of a CMDB that contains all necessary attributes and relationships.