ROI in a cmdb implementation? How the business perceive?

RhondaFromGoodw
Kilo Explorer

on ‎07-24-2015 02:04 PM

Hi,

I received today an interesting tweet and I wanted enough space to answer, so I share my thoughts here with you

Summary

As a summary, "When we plan to build a CMDB/CMS, we should start by identifying the recurring costs of the absence of CMDB, then start small and think big in an agile way. It means starting with the common vocabulary and the quick wins who annoys everyone to gain the people commitment and make a program to see what we want to achieve according the real needs and adjust the goals (what is allowed by the agile methods)". Each "wave" of the CMDB implementation should answer identified costs to have a justification for both Technical and Business people.

ps: I won't speak about Services because I think that for speaking Services, we need to be mature enough and if we're starting to implement the CMDB, we don't have this experience yet.

I'm now going to try to explain that:

Firstly, what is the CMDB/CMS?

In one sentence, it's the "documentation of the CIs in the organization + the relationships between these CIs", I like to say "it's the production IT map".

Secondly, what does the theory propose?

In theory, we should have ALL the CIs/relationships into the CMDB and every time we modify something, we have to make a change and the change will modify the CMDB.

But, in the theory, we have no constraints of time/money/... but it's not the case in the real life...

In my mind, I would say the CMDB should be in theory to the IT Department, what Google Maps / OpenStreetMap is to the maps for people, most complete as possible but to have all the details like this "drinkable water public fountain" OpenStreetMap, you need a lot of money and time... So yes it's a dream to have absolutely everything, but in the meantime, we'll start by the country borders, then the main cities and regions/states, then the minor cities or the streets of the main cities... and for each "wave" of improvement, we have to justify why we need it, what are the mistakes we'll avoid by adding that info on the IT map...

And in concrete terms, how to evaluate a ROI?

As usual, if we want to prove something, we need data on the current situation. So we should start by asking "How many issues (incident) did we provoke by modify (change) something in the IT Department in the last year, what was the cost of it and most importantly, did we do these mistakes by a lack of documentation?"

2 situations:

==> We might had to shutdown a server because we had to patch Oracle and the windows version wasn't the one we thought and the OS was frozen. An also, we didn't know that this server was used for an important Business Application for the Sales Department. We discovered when the Sales Manager called the CIO to know why his team couldn't work

==> We just have few servers and a small team and we never had issues by lack of documentation in the last 5 years and the Business people can confirm that

In the first case, you really need a CMDB, in the second case, it'll be a "nice to have" but well it won't be urgent. And your ROI will be calculated by the investment you'll make to implement the CMDB and the cost of the incidents you had in the past due to the lack of the CMDB. If the organization doesn't have strict "incident costs", at least the Managers should be able to agree on a rough global estimate saying "Yes, we had costly issues and this proposition of the CMDB should reduce the costs and is acceptable"

What are the factors to implement?

The implementation of the CMDB should depend from 3 factors:

  1. the organization requirements due to the past issues
  2. the requirements from the regulations/laws/external auditors
  3. The human reluctance (because we want a CMDB really used, not just a beautiful model on the desk of the CIO)

With these 3 points, we should be able to build a strategy, a path to a better CMDB.

How to start the journey, how to embark the Business people on a CMDB transformation?

The first point of ITIL is to share vocabulary, so my first question is "What is the common layer understandable by both people (Technical and Business)?"

Usually (when the IT isn't Service Oriented yet) I see the Business Applications as this layer, because for business people, it's what they use to "do business" and for technical people, it's the reason of having technical CIs... So this word is usually understood by everyone.

So, our first move is to create this Business Application layer (it could be for 1 workshop or for several years, the principle is the same "start with a common vocabulary") and then, according the 3 principles given previously, we'll expend the CMDB to the services (regrouping the business applications) and to the technical CIs (supporting them).

Additional info:

How to know if an "item" should be or not in the CMDB?

A quick example: "Do I need to put my test environment server into my CMDB?" (What should we do with test/dev environments is always a question)

  1. It's only used for a project, we can do whatever we need on it without change, we will never declare incidents... ==> No need
  2. In fact, it's used for both tests and productions systems, you know sometimes a test environment could become prod because of budget / time / ... ==> Yes, you have to consider this server as a prod even if it runs mainly test environment
  3. I have regulations and I have to ensure that the Test environment is an exact replication of the Production environment. ==> Yes, you will have to put your Test server as a CIs to track the changes of this server and of the prod one...

How to know if an information is a CI or an attribute of a CI or could be not there?

Well, the granularity will depend from the real needs:

  1. I have ServiceNow (platform) hosted by ServiceNow (company)
    1. Attribute "hosted by" will be enough (or a CI "ServiceNow infra" if I want to consider the 3rd party partner infra as a global CI because I have X instances and when I see an outage on the ServiceNow infra, it'll be used on all instances) or we don't have the info if we don't need it
  2. I have NAS with hard drives and i want to know the lifetime / capacity / ... of all the hard drives because I have contracts and if the results are bad, I'll discuss price with my supplier
    1. You'll need a CI by hard drive

And you, want to you think about it?

Best regards,

Thanks for this explanation and overview, It's very helpful!

Thanks for the discussion.   there are also other angles =>

1) From my experience it's very usefull to have a CMDB in complex production landschapes. Especially the links between Customers Services and the CI's are extremely usefull.   In the cloud / virtual area more and more is shared. In case shared components fail there is an impacted on other Customer Services.   This is directly visible in the CMDB and key in case of high available business services. E.g. Payment industry, car and semiconductors manufacturing.   Reaction time is often directly related to money.

2) A link between the CMDB and an ERP solution makes it possible to have a look from the contractual and financial view into the infra and application landschapes. Experience learns that this is often the best business case as most companies pay for licenses and maintenance long AFTER they were closed...

A good process (ITSM and financial / purchase) and discpline are the driving factors.   It's were Management of Change is needed. Technical people don't administrate by nature.

Jan Jansen

+31688806529

jan_jansen_47@hotmail.com

Would anyone have documentation as to how to implement CMDB processes for the internal IT staff?   example: how to control and manage how users are using the CMDB?

This document was generated from the following discussion: ROI in a cmdb implementation? How the business perceive?

0 Helpfuls
  • 1,384 Views
Version history
Last update:
‎07-24-2015 02:04 PM
Updated by: