Actually, it won’t take you nearly 4.5 million steps, but creating a valuable, well maintained Configuration Management Database (CMDB) is not something that will happen overnight. It takes effort. And it takes a lot of buy-in up and down the org chart. The good news is you probably already have a solid start, or maybe even a complete CMDB waiting to be maintained. Ultimately, active administration is the key to success when it comes to configuration management.
What is a CMDB – and what is it not?
The CMDB is a collection of data points that are under the control of Change Management. What the heck does that mean? Well, it means that any service asset (be it hardware, software, contract, SLA, what have you) that should only be modified under an approved request for change (RFC) belongs in your CMDB. And, not surprisingly, anything that is in your CMDB can only be modified under an approved RFC. This is an important distinction because you undoubtedly have many service assets which are not controlled by your Change Management process. Most organizations do not track things like free software, keyboards and mice, sometimes even monitors. This is primarily because 1) these items are generally very low cost, and 2) they are very hard to track. However, if you do happen to track these types of service assets, that’s OK, too. Just remember that they must also be maintained under Change Management. But, a CMDB is not just a repository of data points. It also should provide relationships between these data points to ensure smooth transitions within the larger ecosystem. For example, if you know that Server A is connected to redundant Switches 1 and 2, which are, in turn uplinked to Router C4, and that Server A is critical to the business as it relates to Service 12G, then you have the type of risk analysis data that will help determine the likelihood that you can reboot Router C4 at 2:00PM on a Thursday afternoon without causing an unplanned, major outage. This is why maintaining the CMDB is so critical. Without vigilant updates, it becomes an obsolete data repository that no one trusts, and it undermines your organization’s Change Management process.
How do you create and maintain a valuable CMDB?
Perfect Your Change Management Process. The single most critical factor in a successful CMDB rollout is the process that it most directly supports: Change Management. There is virtually no point or value in creating a CMDB that is not controlled by a rigorous, stable, and mature Change Management process. So, if you have one, awesome. If you don’t, you’d best get to work. Lack of mature Change Management means that your CMDB will not be maintained properly, and, as I said earlier, this makes your CMDB obsolete and widely untrusted. Lack of trust leads to lack of buy-in, which ultimately leads to a failed CMDB.
Take a Complete Asset Inventory
So, now you’ve got your Change Management process under control (or you already did this before you started reading). What next? Inventory. Yep. It’s tedious, painful, and your staff will not like you for a very long time, but a physical inventory of every service asset you plan to track in the CMDB is absolutely necessary. Tracking software licenses? You’ll need an inventory of those, too. Gather up your Service Desk staff, give them the lousy news that they are about to lose a Saturday (and maybe a Sunday, too, if you have a lot of hardware assets), and then order pizza (or BBQ). Food motivates IT staff like nothing else. Get in there, and inventory everything. Then, compare it to the data you already have. This is going to help call out mistakes, and it will help to fill in those blanks that inventory may have missed.
Enter Your Inventory Data into the CMDB
Is your inventory done? Is it solid? Would you bet your own paycheck that it’s 100% accurate? Excellent, get that data into the CMDB. If you are just getting started, your CMDB could be something super simple, like a spreadsheet. If you’ve been doing this for a while, you almost certainly have a tool to handle this data. Likely, this tool is either part of, or directly integrated with, your ITSM tool. Which is terrific because this integration is going to make maintenance much simpler (and probably at least a little bit easier). We have been using Cherwell Service Management for over four years, and its CMDB is tightly integrated with Change Management, Problem Management, and Incident Management and Service Request Fulfillment. These are the primary processes that will impact—and be impacted by—the CMDB.
Now you’ve got a solid inventory and it has been dumped into your CMDB. What’s next? Maintenance. Your Change Manager is going to have to be the main driver behind this effort, and (s)he is definitely going to need buy-in from above and below to be successful. No more ad hoc (and likely undocumented) changes to anything in that CMDB. If no one knows it happened, then the CMDB is not going to reflect it. And that leads, once again, to a failed CMDB. Everyone, from the C-level on down, needs to follow the Change Management process. If the CIO walks into the Service Desk and demands an update to a server without documentation, then (s)he needs to be reminded of the chaos that is about to ensue. Does this mean we don’t follow the instruction? No. It means we write up an Emergency Change request and update the CMDB properly, even if only after the fact. But the Change Manager also needs to reinforce the importance of following the process, even if it is the CIO making the request.
Document Your Process
Finally, document the processes. Nothing compels leadership like a good process document (especially if it has graphic workflows and charts). Make everyone sign the document, or at least acknowledge that they’ve read it, understand it, and agree to adhere to it. This is key, especially for those special snowflakes that do not like process and would prefer to do their own thing. You will get pushback. Seek out those who are opposed and get their concerns on paper. Make sure they are specific about the issues that make the process unworkable for them. If it’s just an overall unease about documented processes, or a complaint that process will slow things down, then gather evidence to the contrary. There’s plenty of it out there. Well documented and maintained processes actually have a tendency to decrease time on task by introducing repeatable steps and templates that can be used over and again. And, they make it much easier to demonstrate to the business that IT provides value. Turn the naysayers into allies. If you can prove the benefits to the biggest critics, you will win every time.
Definitely fewer than 4.5 million steps, but these are not easy steps. They take time, maturity, and a willingness at all levels to adhere to process and policy. Talk to experts and organizations that have been successful at implementing these processes. Nothing plays like experience. And, finally, believe in the process. You never want to introduce overhead just for the sake of creating a new process or policy. That is a sure path to failure. CMDB works. Change Management works. These processes, however you choose to implement them, have been proven successful in thousands of organizations over the past 30+ years. Trust in the advice of ITIL experts and industry leaders but make the process your own. No two organizations have precisely the same needs, and this is not a copy-and-paste operation. Tailor the best practices to meet the needs of your ecosystem.