A CMDB for your CMDB
"I want to implement my Service Management tool out of the box. Minimum customization absolutely."
Given the ballooning costs of maintaining highly customized products, associated vendor lock-in worries and the nightmare of product upgrades on customized product sets, more organizations prefer to go out of the box or with minimum customization with their ITSM product implementations.
Wonderful so far. But how do you decide how much customization is enough? What is that minimum customization threshold value? And more importantly, how do you know when you breach that threshold?
The story of minimum customization
Charles Betz, in his well written book, Architecture and Patterns for IT Service Management, Resource Planning, and Governance, calls it making shoes for the cobbler's children. I interpret it in this case as how do you manage the complexity and implementation of the ITSM product itself?
An excellent way to start an IT Service Management product implementation is with an understanding of the as-is environment. Knowing how things work currently helps prepare and answer questions on the new process and softens the organizational change process. Questions such as - Why can't I book outages through the new Change Management system like I used to? Or why do I need to create and assign these tasks? Or I need to capture the business request number which is not mentioned here. And numerous others arise in any typical implementation.
And among these questions, there are some that get pushed really hard - which eventually become what I call arm-twisted requirements leading to tool customizations. When such customizations are kept track of through documents and spreadsheets, that's when the trouble starts.
- How do you know how much of the product set you are changing. Is there a way an ITSM product set can tell me that by making a tweak here and a tweak there, I am making an impact to the overall solution that is quantifiable? Say adding a field that has no interfaces with any other data feed would have an impact of 0%. But adding a field that feeds information from an external source which is outside this tool adds an impact of 0.75% to the overall solution. And this percentage is arrived at through consideration of impacts on all data models, relationships and all associated process flows.
- Now the second point. With an upgrade, how do you manage these customizations? Go back to the drawing board? How about if these entities are modelled into an automated data modelling set and each time there is a change to the entities, click a button and you know what has changed and what remains. And you also know what impact these changes have had to your overall solution.
Something to think about.
So, what does getting there involve? You guessed it - a CMDB for your ITSM product. Are we there yet? Tell me when you see a good solution.
