By Chris Pope - 2014-06-10
Step 1: What problem are you trying to solve?
In this seven-step series, I'll be discussing techniques to simplify and change how you look at managing services. Let’s focus on delivering an entirely better work life!
I am lucky to have a role in which I make hundreds of customer visits each year, and to have grown up in several IT organizations that taught me the fundamentals of good CMDB design and implementation. I have found that too many CMDB projects fail before they even get started. Two of the most common reasons for this include:
For many organizations, initial scope is to import as much data from as many sources as possible. This typically happens in the vain hope that all this data will somehow reconcile together, relationships will auto-magically occur, and data quality will be higher than ever thought possible. In reality, ownership and accountability for sorting out the mess has now transferred to the owners of the new toolset and a major deliverable of the service management project is now data quality. There is always some aspect to data quality in deployment of any new enterprise system, but why add to the scope unnecessarily?
Presentation of the data is often as important and the data itself. If it's not easy to understand, digest and make decisions from, then you could easily argue what's the point of having it? Any data in the CMDB should have a purpose. The list could be fairly long depending on circumstance, but generally the following objectives should apply:
I often work with customers using a variety of techniques, but one of my favorites that regularly create a ‘lightbulb’ moment is the following:
Step 1: Something occurs which is highlighted on the left monitor (phone call, shoulder tap, monitoring event, email, etc.).
Step 2: A ticket is created, usually an incident, in the tool on the middle monitor. What do you know at this point that could have been passed to the incident from the left monitor: i.e. User, Service Impacted, Priority, Time of Day?
Step 3: From within the incident what do you know or need to know that will enable you to either resolve first time, assign right time first time every time, escalate due to impact, make this a priority over all other incidents in the queue?
Step 4: The Incident has now been assigned to a support team. What do we know about the incident that will make this more important that others, or when viewing the incident and seeing the related CI, will now enable the technician to resolve faster or in most cases drive them to the SME tool of choice? If a Server Support team, it’s highly likely they will try to connect to the server or use some remote takeover capability. What gets them to that point, what information can we gather in step 1 and step 2 to make a better and more reliable decision using data in the CMDB?
The above graphic represents quite a simplistic view of achieving the desired outcome. The goal is to capture day-to-day behaviors that you and your teams are already doing, and understand them in a way where CMDB data can optimize a process. By doing this, more complex use cases can be built while keeping to the fundamental method.
When running this scenario recently, a customer I was working with was really struggling to get buy-in from the network team to get complex and ever changing data into the CMDB. The first step was for me to ask a very fundamental question, “When a network related incident occurs, what is the first thing you do?”
Amazingly this had NEVER been asked! After a brief pause, the customer answered, "Open a console and try to connect!”
The original plan and design using an overly elaborate drawing of many ‘cylinders and arrows’ was torn up and forgotten fairly quickly. After about 45 minutes of sitting with the network team and watching what they did, and asking them what was needed, when it was needed and where we could get the trusted data from, we had a set of very engaged stakeholders who then offered to do most of the work in getting the data.
This model was then repeated across all the service providers in IT. The goals were more easily met while reducing the project time to implement CMDB, and delivering a successful outcome.
Before embarking on an epic journey to implement your CMDB, step back and understand your users’ daily life, what should you be providing them rather than could be providing them. Be open and prepared for the answer and most importantly don’t be afraid to ask the question!
Next up, I will cover Step 2: What is a CI?