Many organizations want to implement or re-engineer their ITIL® processes, especially when acquiring a new service management solution. To be sure, it’s a great time to rethink processes—but where do you start?
Unfortunately there is no prescriptive approach, as every organization has a different level of process maturity at the onset of its journey. But this variability can be taken into account by assessing one’s current process maturity level and tailoring the ITIL implementation roadmap based on that assessment.
The Keys to Developing a Process Roadmap Order
Many organizations overestimate their maturity level, especially with regard to the value their processes actually bring to the business. It’s crucial that you don’t fall into this trap, as it will create significant challenges down the road.
The ITIL® Maturity Model is a great place to start bringing understanding and clarity to a company’s level of reliable and repeatable execution, governance, and continual improvement for current processes. A thorough and honest self-assessment can open the organization’s eyes to the real state of things, and provide a baseline for future process improvement, although it isn’t a real substitute for the value delivered by an experienced ITIL consultant or a certified auditor.
Any given consultant may each suggest a different approach to establishing a process roadmap order. Then within any individual process, there can be a maturity roadmap for the specific process. Many stress the importance of getting basic blocking and tackling done through Incident, then Problem, then Change Management. Others will say emphatically to start with Configuration Management to provide a foundation of what is known about the IT environment. Configuration Management can be difficult if there has been little governance in the past, but yields value because the next processes you implement become easier to define and map.
What about Problem Management? Isn’t it supposed to be one process that can improve the entire environment by reducing incidents? Yes, it does that, but as you begin your process journey, you probably won’t have the needed resources to dedicate, and won’t be thinking proactively just yet. Problem Management often winds up being a sidebar for Incident Management, when in reality, it needs to be a process in itself—with a separate owner and resources from Incident. Having the dedicated resources to do root cause analysis (RCA) and to proactively look for improvement opportunities can make a world of difference, but only if you have the prerequisites in place.
So again, where should you start? What process provides the biggest bang for the buck?
There’s One ITIL Process That Leads the Way
Simply put, Change Management is king. Self-inflicted service disruptions and outages due to change “collisions”—changing one thing and breaking another as a result—continues to be a bane for IT. If you don’t have a solid, trusted process for initiating, assessing, approving, and implementing changes, your incident volume will always be high.
The Change Management process and change records are also subject to IT audit scrutiny. If the Change Management process isn’t trusted, it might be bypassed or short-circuited (e.g. inappropriate use of emergency requests), increasing the risk of outages, security breaches, and compliance violations.
If you don’t have good Change Management, your Configuration Management Database (CMDB) will also struggle as the CMDB touches every single ITIL process and needs to contain accurate data about your environment both before and after a change is made. If CMDB data is not properly maintained and updated from the change process, the Configuration Item (CI) records consumed by other processes cannot be trusted. Consequently, people stop using the CMDB, because the data it holds is perceived as unreliable.
Change Management is much more than just change approvals, so be sure to think about managing the speed and rhythm of changes your organization can handle and the types of changes that require extra scrutiny (relative to those that can be considered “standard” changes). This is especially true for organizations adopting DevOps, as the execution speed and automation of standard changes are iconic DevOps components. And be sure to consider the means by which to capture and communicate your change metrics via reports and/or dashboards.
Although there are variety of valid approaches for process implementation including maturity within an individual processes, getting your Change Management process under control and working properly within your IT service management (ITSM) tool enables your other processes to perform better and accomplish the goals you’re setting out to accomplish on your journey to continual improvement.
Next Up: Get started implementing Change Management with our definitive guide.