Below are some of the common reasons that CMDB implementations fail. They are in no particular order.
Lack of Management Buy-in
Face it, one group is going to be the buyer and installer of the CMDB, there are many other groups/departments that will be needed to help maintain the data as well as use the data. If there is no edict to leverage ITIL processes, there is a good chance that the CMDB project will fail or more accurately… not get used.
Owner of CI’s do not have easy access
I’ve seen several times that the change management team/group are the buyer/install/owner of the CMDB. There is nothing wrong with that, the problem comes in that they do not have buy in from the CI owners to help maintain (or validate) the CI’s, or the CMDB solution is cumbersome and it is implemented in a manner that makes it hard for the CI’s to be maintained. The Change Management team doesn’t want to own the CI’s (and can’t/shouldn’t), but the owners are not able to easily access the CMDB.
Garbage in, garbage out (and/or stale data)
There are lots of sources of data to populate and maintain the CMDB, exporting XML from one system and importing into another system is only part of the process of ensuring data accuracy. XML exports are not the only ways to integrate with other sources also. Make sure the vendor has ways to filter out noise (who cares about an SSH session from an admin workstation to the server, it’s not a dependency). If the there is to much data, it may be hard to find anything, if there is inaccurate data, no one will trust the CMDB. Find the middle ground.
Lack of third party Integration
There are many reasons to connect to the products to pull in additional details. You can think of some of these applications like mini silo CMDB’s. The HelpDesk system knows anything and everything about customers, the asset system knows tons-o-things about servers. Integrating with different sources is a great way to get started as well as ongoing maintenance of a CMDB.
100% or NOTHING
Do not fall into the trap of holding back releasing the CMDB to the company until it is completely done. I understand that there needs to be a certain level of data witin the system before there is value, I understand that there needs to be processes in place to maintain the data and then there is the accuracy challenges. The point is, pick a few slices of the entire pie, define what it is, set the expectations, roll it out, get some internal wins (and learn from it), then go after a few more slices of the pie.
Hard to search/find things
The interface must be intuitive, the end users shouldn’t have to understand a database schema in order to search for CI’s. Many of the users will only log into the CMDB a few times a year. A user should be able to hit some internal website, get forwarded to the CMDB interface, issue a search, press print and run off to their DR planning meeting (or Solaris migration project, etc).
Over designed/engineered Schema
For those doing a roll-your-own CMDB, good for you, it is nice that you are spending time to design the database schema and planning for the future… don’t get stuck planning for 2020, your plans for the CMDB and schema WILL NOT BE ACCURATE, accept it.
One Stop Shopping
We are looking for a CMDB, this is a good time to purchase a new Change Management System, Problem, Help, etc, etc, etc…. and you have just delayed purchasing and rolling out anything for the next 18 – 24 months between the pilots and lengthy executive signoffs due to costs and implementation time frame. Again, good idea, they need to work together in harmony, you need a plan, you need interoperability, but you also need to solve some business problems sooner.
Bottom Up = WRONG approach
If you’ve ever talked to the builders or owners of a CMDB, many times it quickly gets down into the weeds of attributes, relationships, types of CI’s. This is all interesting information and details but… who cares. In the end, who is the target audience, what is it that they will need to get out of the CMDB. Take a top down approach to the implementation. If you have a clear vision (or atleast a goal of a vision), in turn it can clearly define the types of CI’s you will initially need, potentially the specific attributes and dependency information. It probably help you determine what types of integrations the CMBD might need with other system in order to populate and maintain the CI’s. If you take a bottom up approach for the implementation of the CMDB, you will get stuck in the weeds and you may not have a clear answer if the design/approach/solution/product/etc will meet the end users vision/goals.
Okay, for those of you not counting, I only listed 9, in the comments below… give me your 10th one. Don’t be shy, share a 10th one or a funny story about one.
Tobin
