As service organizations mature, and Incident and Service Request Management start to jell, executive management begins to get very interested in Service Asset and Configuration Management. And this is a very good thing. Knowing what assets we have and can provide service for is a powerful thing. It can drive increased budgets and resource allocation for IT, especially when we can point directly to how much time our staff spend on various CIs that might be obsolete or completely unused. If any of us look around, I'm sure we could find a lot of servers doing very little, if any work, but because of their age they require a great deal of resources to keep them "green" on our Event Monitors.
However, inventorying Service Assets and Configuration Items is really only half the battle—and it is the last half. I have been a part of several ‘asset inventory’ parties in datacenters over a long weekend. They are a huge time sink, and most IT staff will do almost anything to avoid them. Now, stack on top of these things the fact that by Thursday of the following week, the data will be completely out of sync, and we have created unhappy staff, and even unhappier management.
Ready to take this a step further?
Start logging your organization's long term projects and goals with our CSI Register!
Without Change Management, all of the inventorying in the world will not help an organization. I have heard client after client lament that they have no idea what is on their network, or what certain assets actually do for the organization. But the very next idea out of their head is to do a physical inventory. Just like the one they did last quarter (or last year). Not that a physical inventory is the wrong idea. It’s a great idea. However, if we don’t want to be right back here next quarter, we need to build a really great Change Management Process.
So when do we build it? It really does depend on the maturity of the organization, but the wrong time to start working on a Change Management process is after the inventory. By the time all of the processes and policies are in place, well communicated, and being enforced, our CMDB and wider CMS are completely obsolete and useless. We have closed the stable door after the horse has bolted.
A lot of organizations do not see the value of Change Management until the consequences of its absence hit their bottom line. It is a common growing pain among younger companies, especially those whose growth is outpacing their ability to hire quality IT staff. But this pain can be avoided, even eliminated, by considering Change first, rather than as something to do once we have our Incident load under control. If your organization has loose, unenforced, or non-existent Change Management, think about what causes the vast majority of incidents. Is it technology failure? Is it capacity issues? Is it gremlins? Chances are, most, if not all of our daily incidents are caused by poorly executed—and more often undocumented—changes to production systems. And if the change did not cause an incident directly, the now out-of-sync CMDB will suffer, and the chances of additional incidents occurring will increase.
We need to formalize our Change process. Transition of a Service is a key component in overall Service Management, whether it is adding, changing or even retiring a Service, System, or Configuration Item, we must build an ironclad process around it to keep it safe. And that process has to be followed. No exceptions. No ‘Executive Exemptions’. Buy-in must occur at every level of the business to be successful.