In my last blog I laid out the proposition that Configuration Management and a CMDB is all about Change and that CMDB and Change are ‘partners’ in executing the work of IT efficiently and accurately. Seems pretty clear, right? Then it should be easy to justify and implement a CMDB based on large numbers of Changes, right again?

Not necessarily. Justifying, developing and implementing a CMDB is not an isolated activity, a technology implementation or a database development effort. A CMDB is a means to an end, not an end in itself, and the end(s) are increased ITIL best practice Change Management and control and increased Configuration and Release Management control.

So the business value of a CMDB has to be built on results achieved in other ITIL practice areas, including an improved Change and Configuration Management process, better Change control and overall better service level management. These objectives have to quantified to prove metrics that could include:

• Business process re-engineering
• Change Management lifecycle improvements
• Change Management approval board activities
• Change and Configuration Management executions
• Metrics to support and make the case for improved Change and Configuration Management and the CMDB

Ultimately the CMDB should be profiled as a crucial tool to the improvement of overall ITIL best practice Service Level Management and an important underpinning to an accurate and effective Asset Management system.

A good CMDB is good for Change, Configuration and Release management and ultimately good for the entire ITIL Service Level Management process.

Do you agree?

Until next time,

Don

Also, don’t forget to register for Evergreen’s change management webinar and learn how to Take Change Management from Firefighting to Fire Prevention

Are you trying to build a business case for a CMDB? Download Evergreen’s newest white paper on the subject: “The Business Case for Change and Configuration Management and the CMDB”.

Is the business value of a CMDB all about Change Control? And what if your organization performs root cause analysis? Do you really need a CMDB? We’ll address these and other CMDB, Change and Configuration Management issues in a new series of blogs this month.

As enterprises and their IT support organizations grow, their infrastructures become increasingly fragmented and spread across a variety of functions, technologies and organizations. As this IT infrastructure ‘sprawl’ continues, efficiency, optimization and overall control over IT resources suffers. Organizations often address the IT infrastructure ‘sprawl’ issue with automated or, in some cases manual, Change ‘root cause’ analysis tools. These tools analyze changes, in many cases failed changes, to get at the ‘root cause’ of the problem.

Although root cause analysis is critical to the improvement of change control, analysis that doesn’t take into account all configuration items (CIs) and their inter-relationships can be reactive, incomplete and in some cases, downright ineffective. Spreadsheets and manually maintained asset and specific purpose configuration repositories also do not sufficiently take into account the inter-relationships of CIs and can fall far short of effective root cause analysis for complex IT infrastructures.

So here’s my proposition - change process and CMDB are ‘partners’ in executing the work of IT efficiently and accurately. At the highest level, change is the workflow of IT and the CMDB is the information store that provides data to support the decision-making process. This partnership is the functionality that drives an efficient change flow engine.

Until next time,

Don

Also, don’t forget to register for Evergreen’s change management webinar and learn how to Take Change Management from Firefighting to Fire Prevention

What do you think about the relationship between Change and Configuration Management? Download Evergreen’s newest white paper on the subject: “The Business Case for Change and Configuration Management and the CMDB”.