Posted: Fri Jun 22, 2007 8:24 pm Post subject: Business Case
Hi - I'm in the process of putting a business case together on whether to develop an in house CMDB or to look at CMDB tools on the market. There are a few useful posts already on this forum which should help. One of the main areas though is to try and sell the idea to senior management as to why we need to spend so much money on a tool. The problem I have is actually trying to show what savings can be made! Not easy. I would like to ask your views on how I can show some ROI. A couple of ideas include:
1) We are moving data centres within the next 2 years
2) Improving the way changes are made in the organisation as we would have the ability to do impact analysis
Have you put a business case together on this? Are you able to share experiences? Thoughts and Comments?
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Fri Jun 29, 2007 10:36 am Post subject:
You have to be very careful about this. There are fundamentally two types of CMDBs that you will need to consider. The first is what is called a "Non-Operational CMDB" (or NOCMDB) and the second is called an "Operational CMDB" (or OCMDB).
A NOCMDB, which is very much the traditional CMDB that most people are referring to when they talk about CMDBs, is one that is no more than a basic data warehouse that gets its data from upstream systems and is used as a hub that can feed down stream systems. The best you can do with something like this is put a Reporting and Business Intelligence solution over it and understand that because the data comes from upstream systems, your NOCMDB can "never" be the true source of data. Since this system is an addition to your environment, it automatically drives your Total Cost of Ownership (TCO) up. It becomes hard to prove a tangible cost savings or revenue increase due to such an implementation. This is more than likely why you're having a hard time proving a solid ROI. Most people suffer the same pain, here. Another big disadvantage of a NOCMDB is that it becomes very difficult to manage Relationships between entities, as you're pulling data in from multiple, disjoint sources and correlating it all, after the fact, becomes a huge effort to implement and to maintain.
An OCMDB is a different beast, altogether. People actually work in such a system, directly, and create, manage and share information, right from within it. So, for example, Engineers will register and manage their assets in an OCMDB. Product Managers will register their Products and Product Releases in an OCMDB. Help Desk/Service Desk personnel will create and track Incidents in an OCMDB. Etc. As a result, there is no need for a separate Incident Management tool because the OCMDB becomes your Incident Management tool. There is no need for a Product Catalog because your OCMDB becomes your Product Catalog. Etc. This means that your OCMDB has the potential to "take out" / "decommission" other tools. Such decommission equate to tangible savings, because you're going to be able to prove that costs for those other systems go away (after recouping your investment to migrate and shut them down). A major advantage to an OCMDB is that everything is transactionally linked and integrated, so Relationships are much easier to create and manage. In many cases, they will get implemented, implicitly, without you even known (although they will allow explicit creation and modification of Relationships, too).
Anyhow, I hope this helps. Please feel free to contact me offline at Frank.Guerino<@>TraverseIT.com, if you feel you would like to discuss it further.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum