Cost Benefits of implementing a CMDB

[SandraDee]

Hi,

I am preparing a business case for the implementation of a CMDB. We have a Configuration Management Process but are in the market for the CMDB tool. Whilst we are all in agreement about the benefits of having a CMDB we are having difficutly putting together the financial benefits to the organisation. Like any business case, the business will be looking for tangible cost benefits to the organisation as a whole. Anyone run into this problem or can offer suggestions on cost benefits/savings...

Thanks

SandraDee

[alphasong]

Hi, here are a couple of things I have seen work:

- Find out for your core systems how much revenue depends on them and how much is lost during an outage. This is possible for some business processes and not for others. Then, make a measurable commitment to reducing outages through configuration management by managing change risk better and resolving incidents more quickly. I know of one large organization (Fortune 20) that was able to do this, and the CFO signed off that the savings were true hard dollar savings.

- A less well recognized opportunity would be to make a business case on the elimination of redundant re-surveying of the environment. So many IT business decisions and change initiatives start with a survey, to the point where beleagured application and engineering teams get essentially a new blank spreadsheet every week. "What applications, what servers, what databases, what do they do, etc., etc.,..."

This is more soft dollar, but I have seen substantial political traction on this - "if you guarantee my teams will not have to answer yet another survey, I'll support the darn CMDB, I don't care what it costs or if we can show hard ROI!"

For what they are worth - they are real examples, not conjecture, nor "friend of a friend" ...

-Charlie
_________________
Charles T. Betz

[Guerino1]

Hello SandraDee,

Like any justification, you're going to have to weigh the full investment vs. the full return.

On the investment side you'll have to worry about two types of costs...

Initial Rollout Investment

This includes all your up front costs to get into something. In the case of a CMDB, it will include but is not limited to:

• Labor for defining processes
  
• Labor for selecting software
  
• Labor for planning customization of software
  
• Labor for training of processes, tools, etc. (time to have employees in training)
  
• Cost of training/trainers
  
• Software build or purchase costs
  
• If purchased, software licensing costs (which are usually separate than the purchase, itself)
  
• Software customization costs
  
• Software packaging costs
  
• Software testing costs
  
• Software deployment costs
  
• Hardware costs (servers, storage, etc.)
  
• Cost of integration efforts (should usually be broken down by each integration from the CMDB out to/from each independent system
  
• New labor for any dedicated stakeholders you will hire for managing/implementing any parts of the process.
  
• New labor for any dedicated stakeholders you will hire to manage/support the CMDB system.
  
• New labor for any dedicated stakeholders you will hire to manage/support any related infrastructure.
  
• Etc.
  

Year-Over-Year Total Cost of Ownership (TCO)

This includes all your related year-over-year costs to keep/maintain something. In the case of a CMDB, it will include but is not limited to:

• Yearly software license renewal costs
  
• Average yearly infrastructure refresh costs (hardware, network, storage, etc., all need to be upgraded regularly)
  
• Average yearly integration costs (the CMDB will continue to be integrated to/from other systems because you'll never get it all in the first year)
  
• Average yearly SW repackaging costs
  
• Average yearly SW retesting costs
  
• Average yearly SW redeployment costs
  
• Year-Over-Year Labor for dedicated process stakeholders
  
• Year-Over-Year Labor for SW support/maintenance
  
• Year-Over-Year Labor for HW support/maintenance
  
• Year-Over-Year training costs (new employees, etc.)
  
• Etc.
  

The two items, above, should give you two cost line items:

1) Cost to Get In, and
2) Cost to Stay In.

Your job will be to minimize both of these.

Once you have your costs clearly defined, the next step is to understand how you're enterprise plans to use the CMDB. Doing so will allow you to understand your benefits.

Benefits

• Better Knowledge Discovery/Impact Analysis/Reaction Time (Less down time due to change. Faster recovery time due to incidents like viruses, denial of service attacks, etc. Happier clients due to faster reponse time and less down time.)
  
• Knowledge Retention (CI Details are documented.)
  
• Auditability/Cost of Audit/Compliance Issues (Far less time to see auditable details, which reduces the time and impact of audits on the enterprise.)
  
• Transparency (Can see what you own, what your current state is, what your past states were.)
  
• Faster/More Efficient Information Sharing (CMDB can be used as a reference to feed other systems)
  
• Etc.
  

Given all of your benefits, you'll need to put some type of a value on each and justify why you came up with those values. Realistically, most of the efficiencies you get because of a CMDB will come from things like response time (time to discover & time to react).

The best alternative for saving a great deal of money is when you can have your CMDB act as the operational system that can replace other existing systems. So, for example, if your Asset Inventory/Register is maintained solely in the CMDB, you can shut down any other Asset Inventories/Registers, which correlates to hard savings. If, for example, you maintain your definitive Product Inventory in the CMDB, you can shut down your other Product Catalogs, which correlates to hard savings. Etc. However, most CMDBs don't allow for such things. We offer one that does.

Having a CMDB that allows you to operate in it (Track and manage assets in it, track and manage incidents in it, track and manage problems in it, etc.) allows your CMDB to be the strategic move-to system that allows you to decommission all the ancillary point solutions for each of those operational spaces. If you can achieve this, you will have an opportunity to show some very large savings because one system acts as the "take-out" for many other systems.

Note: Something important to note is that if your CMDB is a separate system than the systems that feed it data, contrary to popular belief, your CMDB cannot act as the definitive/true source of data. The definitive/true sources will be those systems that feed it. However, if your CMDB is an operational system (i.e. people work in it and generate the data/information right in it) that data created directly within the CMDB can be considered the definitive/true source of data.

Anyhow, I hope this helps.

My Best,

Frank
_________________
[Edited by Admin to remove link]

[Cotswolddave]

Hi sandradee,

Think the other answers missed the basic point that a CMDB by itself does not offer any financial benefit. It what it enables you to do that you can't currently do that is important, so that where the financial benefit comes in.

In my experience, CMDBs are not implemented because of a financial justification (though officially that may be the reason), they are normally implemented because control has been seen to be lost across teams. Better control processes require better processes, which require commonality of systems. Costs may be out of control, but the root cause is control, not cost.

I am full time CM specilaist (develop software, advise, capture data, implement etc,) and my orders come always as a result of organisation who recognise that improved management processes require a CMDB. Orders are probably placed on the basis of 50% credibility, 30% functionality and 20% cost.

So don't waste too much time trying to create detailed financial cases as the decision to go ahead will probably be taken on other factors, so it is best to explore those in detail.

Dave

[jpgilles]

I would agree with Dave that there is no real cost justifications for a CMDB.

However you can financially justify Incident Management, Problem management, Change management, Capacity management, Continuity management and so on....

NONE of these processes can be implemented without a proper CMDB, hence the justification...

rgds
JP
_________________
JP Gilles

[Guerino1]

Hello Dave & JP,

You both make the point that there is no real cost justification for a CMDB. However, done correctly, there really is a very large cost justification for a CMDB. Aside from the soft saves, like quicker access to data/information, there can be very tangible hard savings, if done correctly.

For example, if instead of putting in a CMDB that acts as nothing more than a data hub (i.e. a Hub-based CMDB, which is what most enterprises do), you put in a CMDB that is "Operational" (i.e. people perform their work (such as Incident Management, Asset Management, Change Management, Problem Management, etc.) right in the CMDB, itself, then the Operational CMDB allows you to start shutting down other stand alone systems and all the integrations between them. In this case alone, the cost justification for an Operational CMDB can be huge, as one system allows you to shut down many systems and all the integrations that have to be implemented/managed between them. The hard dollars saved can be very large, if done correctly.

Also, in the case of an Operational CMDB, instead of a Hub-based CMDB, data stewardship/ownership work gets eliminated, since the Operational CMDB acts as the true source/point of origination for a great deal of data. In a Hub-based CMDB, data gets fed into the CMDB by other upstream sources. In such a case, the Hub-based CMDB can never be the true source of data (since it originates in other upstream systems). Hub-based CMDBs cause a tremendous amount of unnecessary and ugly work to integrate to them and maintain the data within them, where Operational CMDBs help eliminate other systems and have transactionally fresh data, within them, that eliminate data synchronization and integrity issues.

Anyhow, going back to the original point, done correctly, an Operational CMDB can provide very tangible cost justifications and ROI. We see it all the time.

I hope this helps.

My Best,

Frank Guerino, CEO
TraverseIT
On-Demand ITIL