Those who would promote CMDB should promote CMDB

Much of what we read about CMDB is actually singing the praises of asset management, network discovery or other simpler technologies. Other benefits attributed to CMDB actually come from process improvement and do not depend on the technology at all. When all you want to sell is a hammer...

I missed this article when it came out: Strategies for justifying CMDB ROI. Forgive me for quoting extensively but I think the article is peppered with false assumptions about what a CMDB is and what it does.

"Determining an ROI around CMDBs and ITIL is hard, because we're talking about productivity gains," said Jay Long, manager of IT service management at Forsythe Solutions Group Inc., an IT consulting company based in Chicago. "One of the big benefits of [CMDBs] is return on avoided outages, but that's tough to calculate because there's no empirical evidence available."

A February 2007 study by Framingham, Mass.-based research firm IDC identified a potential pitfall of CMDB projects: organizations' difficulty in articulating the ROI that justifies the time, money and effort. In particular, the study noted that making the case for a CMDB's ROI tends to focus primarily on short-term cost savings. The problem, of course, is that many organizations will realize savings only in the long term -- that is, once a CMDB has been up and running for a while.

Further such longer-range savings won't become apparent unless you invest the time and effort to develop process standards for change management. Then a CMDB can support improvements in service delivery, which can generate cost-saving benefits.

So is it the tool which is providing the ROI or the improved processes? Guess which one I think.

All told, a large enterprise may spend several million dollars and up to three years to get a CMDB fully functional, according to EMA...
IT managers who have deployed CMDBs cite several additional areas of savings:

  • Reducing or eliminating unnecessary servers and other hardware
  • Better license and maintenance contract management
  • Tighter management of outsourcing agreements
  • Labor savings

No, that's asset management. All of these benefits focus on the better management of individual physical CIs, with no reference to their conceptual groupings (services) or their inter-relationships, the attributes that characterise a CMDB.

"In terms of server management, our costs are primarily in resource time and manpower," Giblin said. Now information on the hospital's 100 physical servers, such as names of host bus adapters, are included in the CMDB. "We don't have to go out and physically touch the machines anymore," he added. "This takes our server management up a notch."

Asset management again.

The real value of CMDBs comes from service excellence, and fostering a service-oriented culture," said Long. "Service resolution time, business alignment, customer satisfaction—that's what we're talking about at the end of the day."

No, that's cultural change. It needs no technology to be done effectively. If tools are involved, a Service Catalogue is a much more effective artifact for focusing minds on a service-oriented culture than a geeky inward-looking technology-centric CMDB.

But the biggest payoff from CMDBs comes when organizations use them to gain visibility into configuration information to make better decisions about change management processes... According to Drogseth, one of the best ways to frame the ROI argument (at least in terms near and dear to a financial analyst) is to look at repair times. "The dominant metric for financial types is reducing the mean-time-to-repair," he said.

It is true that this is CMDB's biggest payoff. But change impact analysis is not a process under time pressure. The IT Skeptic proposes that just-in-time on-demand assembly of the configuration data is more cost effective [there is an article on this in the pipeline - look for more on this soon]. And the assumption that impact analysis is a major component of MTTR is highly debatable.

most organizations don't have the luxury of investing in a CMDB and implementing it purely on the faith that a tool will lead to service management nirvana -- and thereby deliver a solid ROI. IT managers should look carefully at the immediate, short-term and midterm benefits they can deliver along the road to nirvana and determine if there's enough there to build a case for a CMDB project.

Go, sister! Finally we agree.


CMDB is a tool, not THE tool

A CMDB is a tool, not THE tool. A tool that (can) support virtually all ITIL/ITSM processes to some degree, but still a tool. ITIL v3 re-enforces the notion that the CMDB is not a THE sole repository of truth. The sophistication that YOUR particular CMS requires will depend on what process areas and improvements you are focusing on, which should be driving your selection of a CMDB.

Putting tools into ITIL boxes is vendor spin, not good practice. Find out what areas are hurting you the most, and look for tools that directly address YOUR needs, NOW, with an acceptable ROI.

Process improvement and cultural change take time and effort, with or without tools.

Skep, I think you're right on. Slow and steady wins the race.

John M. Worthington
MyServiceMonitor, LLC

Syndicate content