|
| Recent
Articles |
How To Negotiate And Purchase Your ERP System
There are many sources of information on how to select and implement software, but there is little information on how to negotiate and make the purchase of the software. The uninformed can spend thousands of...
ERP: Discrete Vs. Process
One of the saddest things is a manufacturer who chooses an ERP software system that does not a fit with what they do. For example, a chemical producer who selects and implements software designed for a type of company which manufactures solid objects such as...
Business Intelligence Gets Smart(er)
Companies are using business intelligence software for more than simple data mining. They're using it to identify hot sellers, cut costs and discover new business. IT LOOKED LIKE your average faux fish, mounted on...
Exposing The Hidden Costs Of Putting Off Your ERP...
It's very easy for business managers to put off an enterprise application upgrade. The tendency is to only look at the immediate and obvious impact on cash flow. There are other factors so often overlooked that...
A Non-value-add Critique Of The Value Chain Concept
Recently I've become aware of a value chain critique called "value network." As stated on Wikipedia, "The value networks model challenges the traditional notion of a value chain. Historically we have been in an...
|
|
05.25.07
Configuration Management Metrics
 By
Charles Betz
Like my friend the IT Skeptic, I am interested in getting more emprical in my ITSM approaches. In particular, I want to focus on metrics that indicate results, not just activity. (Results don't have to be financial.)
In the area of configuration management, a variety of operational reports and metrics are suggested by ITIL v2, many of them in the "activity," not "results," category.
An interesting "results" metric to me is requests for change that are not successful.
Another one is the cycle time to reduce incidents/problems.
I have an intuitive sense that a CMDB, in its role as knowledge repository, can "move the needle" on both of these metrics. But can I prove it? What if I implement a CMDB, along with a bunch of other effort, and availability improves. What do I say to the skeptic who challenges, "Prove that your CMDB contributed"?
One means might be a form of post-mortem change/problem analysis in which the contribution (positive or negative) of the CMDB data to specific changes or incidents/problems is assessed. That is, for each change or incident/problem, questions would be asked such as
• Was the CMDB consulted and found to be accurate?
• Did the CMDB data contribute in any way to the success or failure of the change or incident/problem resolution?
This is a difficult and subjective assessment for which we'd need to train the potential assessors in order to achieve any kind of consistency.
Pre-implementation baselining would be especially difficult, because you would have to ask the question in terms of "if we had a CMDB, would it have helped?" - an even harder judgement call for an analyst to make.
But without asking such questions prior to implementation, how do you prove the CMDB really helped? "Because ITIL says it's best practice" is not sufficient, I think...
Very interested in any thoughts.
Comments
About the Author:
Charles Betz is a Senior Enterprise Architect, and chief architect for IT
Service Management strategy for a US-based Fortune 50 enterprise. He is author of the forthcoming Architecture and Patterns for IT Service
Management, Resource Planning, and Governance: Making Shoes for the Cobbler's Children (Morgan Kaufman/Elsevier, 2006, ISBN 0123705932). He is the sole author of the popular www.erp4it.com weblog.
|
