Thinking of implementing a CMDB?  First of all, answer the title question, “when to start…”.  Establishing a CMDB is a really big challenge.  Many different aspects are to be considered before implementing and choosing the right tools.  Many additional questions will arise like: do we already have any substitute of a CMDB in our environment; what are the needs for CMDB; what kinds of information are vital for us.  The specific state and requirements of our organization should be defined.  We have to be aware of the many problems and threats we can face, as well as opportunities. The purpose of the article is to direct all those who think of implementing CMDB in the right way.

It may be hard to believe, but CMDB is ...   „Configuration Management Database”.  It is not the „Golden Solution for all ITIL Issues” or „The Only ITIL System I Need”.  This name indicates that the time when we need a CMDB is when we need the source of information about the configuration of, in this context, IT Service.  It also points out that it is the Configuration Management process that defines the need for CMDB.

We all have some sort of CMDB in our environment.  In an extreme situation it is stored in the system administrator’s head.  This is of course a very dangerous situation in case we lose the system administrator.  The more mature our IT Service is the more complexity will be required in the CMDB.  However, since a CMDB implementation is a very expensive project, we need to tailor our expectations to our actual needs.  The ultimate question is then: “What features of CMS/CMDB tool are actually needed in the current or expected state of the IT Service”. 

Of course it is not possible to give a generic answer for all organizations.  There are though some indicators we should consider when answering the question for our specific state. Here are some examples:

·          set of attributes of the maturity level of the configuration management process,

·          maturity levels of the other processes we have in our IT Service,

·         actually used types of requests to the Configuration Management.

Having considered the above, we have a good starting point for defining CMDB requirements specific for our organization.

Many Configuration Management solutions available on the market are designed for high maturity organizations.  Using them at the beginning of our ITIL path will kill the implementation project in a short while. 

The first problem we meet in CMDB implementation is the bureaucracy revealed when we compel the operation staff to use the tools.  It will result in additional work creating resistance to change and lack of support.  Without proper training we will soon see the procedures evaded and the whole process slowly failing.  Properly implemented, the Configuration Management Database should decrease, not increase workload.  It means that a librarian should not be forced to input the required data just because some CMDB field may need it. CMDB should just ease the current data input.

The Configuration Management process exists in the context of other processes.  It is commonly known that effective Configuration Management requires appropriate Change Management in place.  It is also critical for Change Management to have input from the Configuration Management that works on a similar maturity level.  The other processes influence the Configuration Management as well.  All parts of IT Service Management should mature with the same speed.  The way the Configuration Manager collects and uses information is shaped by requirements for this information coming from all parts of the Service Lifecycle. 

What we do need is to track all types of demands for the information stored in the CMDB.  This practice provides the Configurations Manager with the knowledge about the CMDB data model and CMS features needed.  When Incident Management tries to fix an outage, the support staff searches for the point of failure.  In small organizations troubleshooting gurus know where to look for the source of an incident.  What they need is usually information about network connections between machines.  We have a different situation if initially all we know about an incident is just the statement \"service does not work\" registered by the call center.  In such a case, it is additionally important to discover the relationship between the infrastructure elements and the service itself. 

Finally, if the cost and impact of the incident is monitored we can consider measures in the CMS essential.   The requests for information should be collected.   Statistics about them will give the perspective of what is actually needed.

The CMDB project is very expensive as it brings costs of every kind as well as many risks.  Since it is supposed to be a help in the IT Service Management, the scope should be tailored to the demand. 

In fact, CMDB should not be implemented unless it is necessary.  However, it is vital not to overlook this necessity.  Monitor carefully your configuration information needs.  When the next question “is this a good time to implement CMDB” arises, be prepared to reformulate it into “Does this CMDB tool cover our requirements?” and be able to answer it.