Do you have immature ITIL processes? If you do, you are wasting some of your valuable IT operating budget and losing company revenue.
Mature ITIL processes improve the reliability and repeatability of the IT services you provide. In addition, mature processes reduce the amount of labor spent on outage recoveries and failed changes. They also ensure that the systems are readily available so customers can utilize your company’s services.
ITIL v4 is a big body of work, so rather than tackling it all at once, I suggest starting with these five processes:
- Asset Management
- Configuration Management
- Incident Management
- Change Management
- Problem Management
Small and Medium companies may find Asset and Configuration Management too daunting to tackle first. If that is your situation, feel free to focus on Incident, Change and Problem Management first. You can always further mature them in the future by incorporating and maturing the Asset and Configuration Management processes.
Asset Management is part of the ITIL Configuration Management System and is a critical foundation to other ITIL processes. This is where IT keeps a record of everything that is running. This is different than the asset database maintained by Finance which is tracking the financial details of an asset such as Purchase Order, Depreciation/Amortization, Asset Tag, etc. The IT Asset Database should contain: Make, Model, Version, Location, IP Address, Owner, Support Vendor, etc. You need these details for everything IT is running to ensure you can properly maintain, support, patch, and secure it. If IT doesn’t have these asset details, it will be a rude awakening when something breaks or gets hacked. In addition, having a mature database of all your assets helps you negotiate better maintenance, support, and MSP contracts.
Configuration Management is the second of what I consider the foundations of the other ITIL processes. It is made up of records that are called Configuration Items (CIs). At the most basic level a CI is an Asset as I discussed above; however, they can be much more informative than that. A CI can also represent the topology of the IT environment. As a starting point the topology can represent how items are connected to each other (e.g., Database to Storage to Server to Network). But at the mature end, CIs can represent a business service (e.g., these combined items make up the order-to-cash service). Maturing the Configuration Management processes to the point of being able to represent these topologies will save you so much in the Incident and Change processes.
Incident Management is the process that IT follows when something breaks (e.g., sometimes nicknamed a fire). An immature process usually looks like Jane fixing things differently than Joe. These individuals are fixing things by trial & error or with tribal knowledge. This results in very inconsistent firefighting and sometimes masks an arsonist who is putting out a fire they started. This inconsistency frustrates the business, wastes IT’s time and is a huge risk if Jane or Joe decide to quit and take their tribal knowledge with them. You can have similar problems at the team level if, for instance, the database team follows a different process than the server team. The mature Incident Management process follows the same process to put out the fire regardless of person, team, or time. In addition, the mature process uses the business service topologies in Configuration Management to identify which business service(s) are being impacted to determine if this is a minor Incident or an all-hands-on-deck business critical incident. This repeatability and business service knowledge instills confidence for the business and also minimizes the Mean Time to Restore the service saving both time and money.
Change Management is the process IT follows for any modification to a Configuration Item (CI) in the IT landscape. This could be minor such as changing a power cord or major such as releasing a new version of an application. An immature Change Management process thinks it knows (tribal knowledge) the potential Impact (what’s going to break if the Change goes bad), the Risk (how likely it is the Change won’t work), and how to back out the change if it goes bad. In contrast, a mature Change Management process:
- uses the Configuration Management system to determine the possible Impact based on the business service(s) attached to the CI.
- determines the Risk based on how many times this type of change has been done before, reviewing the test plans and results and assessing the experience level of the individual(s) performing the change, etc.
- validates the viability of the Backout Plan. (e.g., is it going to work, is it going to take too long)
- uses what is known about the Risk, Impact and Backout Plan to determine what, if any, additional oversight or support is required before the Change can be approved.
This reduces the time spent by Change Advisory Boards reviewing Changes that are low Impact and low Risk, the time and cost of reworking failed Changes, and minimizes the Impact on any business service.
Problem Management can best be thought of as a continuous improvement area for IT. An immature process allows for the same Incidents and failed Changes to continue to occur unchecked. This results in the services IT offers never improving and they continue to frustrate the business. A mature Problem Management process always asks the five “whys” after an Incident is resolved or a Change fails in order to ensure that it never happens again. As an example:
- Why did this change fail? Answer: I made a mistake
- Why did you make a mistake? Answer: I didn’t test it
- Why didn’t you test it? Answer: I didn’t know how
- Why didn’t you know how? Answer: I wasn’t trained
- Why weren’t you trained? Answer: My leader didn’t let me take the class
Therefore, the root cause would not be “I made a mistake”; it is a lack of training that should be remedied. There will always be multiple causes and it will never be this simple. For instance, why wasn’t there a second set of eyes reviewing the Change, why wasn’t the Risk level High for the Change? A mature Problem Management process saves time and reduces business impact by ensuring the same issues don’t occur multiple times.
To conclude, if you successfully mature these five processes, there are added benefits beyond increasing the reliability of your IT services. Since the processes are consistent and repeatable, you can start to use automation to self-heal the most common Incidents and execute the most common Changes. Adding this layer of automation not only saves you more, but it also frees up your valuable employees to perform value added work for the business instead of performing low value commodity work.
Finally, a mature process produces measurable metrics indicating where you need to improve and that you can also use to compare to industry best practice… If you can’t measure it you can’t improve it.
Do you need help maturing your ITIL processes or do you want to learn about more ways to save money and reduce your IT budget and/or find monies to invest in new IT capabilities? Schedule a chat with me and we can discuss my offerings. I’ll be happy to talk. Calendly – Andy Smith