Enable unprecedented levels of automation and agility with cloud computing solutions.
Why enterprises still need ITIL
For decades, the IT Infrastructure Library (ITIL) has been a mainstay of enterprise technology teams.
First, a refresher course: The ITIL is a framework of processes that establish a standardized practice and align IT service management with the business’s needs. There are 25 standard processes, organized in five primary areas: service strategy, service design, service operations, service transition, and continual service. These processes are generic, meant to be adapted to fit an organization’s specific needs.
Some worry that the ITIL standards-based process may impede or impact digital transformation efforts, especially those involving the cloud and DevOps. Naively, they suggest replacing ITIL or augmenting it with other adjunct frameworks.
We disagree with that premise. Ditching ITIL would be a huge setback, impacting teams, their members’ skills, and established workflows. We say, don’t throw the baby out with the bathwater!
Today’s concerns are less about the ITIL framework itself than with how companies implement it. The answer is to change the manner in which ITIL is implemented, rather than give up on ITIL’s workflow management and its benefits.
It might seem easy to point a finger at ITIL when bureaucracy gets out of hand. In one company, for example, 20 layers of change management controls had to be approved before a process change could be deployed into production. In another company, gigabytes of data were emailed to business and IT staff, requiring multiple reviews. But neither of those were ITIL’s fault. Nowhere in ITIL does the standard state you need that many layers for change management.
One issue is that IT has been in charge, and the business stakeholders typically are not included in ITIL planning or implementation. Employees who simply want to get the work done—without being held back by cumbersome processes—are inclined to work around IT with partners or solution providers who present themselves as solving the agility problem. Business peers have taken more ownership for selecting and deploying technology, such as shadow IT and software-as-a-service applications. It is easy for business units to set up their own tech without going through central IT—and to go outside of any IT process management.
But ITIL still makes sense. It does, however, need some adjustments.
Focus on ITIL-like business processes
Business processes and customer experiences are increasingly mediated by technology. As a result, companies need business-qualified technologists to support those efforts strategically.
One important element in that process is to take ITIL outside of IT, which means engaging with people in other departments. That’s acutely important when you interact with departmental workers who may not be certified in or even know about ITIL.
The beauty of ITIL is that its basic constructs are apparent in our everyday lives. ITIL by any other name breaks down to the same core functions. That’s particularly true of its concepts of managing change, incident, and problem management.
To make these concepts more understandable, many ITIL top performers have adopted terminology from standard business processes. Whatever language you use, each part in the ITIL chain can be mapped back to critical business process elements such as Access, Change, Incident, Problem, and Asset Management. Start with core action processes. Keep it simple and avoid eye charts.
That means thinking about business processes in terms the non-IT (and non-ITIL staff) understand. The following outlines what every ITIL process leader should consider:
- Which individuals are involved in the change management process, in both IT and corporate departments?
- What have they automated? Why?
- What are the process hierarchies? Who is responsible for them?
- What common business terms could we incorporate or keep?
- What is the impact to technology, the business, and the company if the processes are incorporated or integrated?
- What key performance indicators or benefits derived are missing in our current implementation?
- What is the best way to simplify these in a single process?
Does IT need to be involved? Not everything needs to be under ITIL purview. Are there requests or processes that can be handled through the business or automated to reduce escalations and impact on IT?
For instance, let’s say an IT department wants to help a city government implement an IoT project to connect traffic lights to an existing citywide IT control center. The ITIL leader would ensure sufficient capacity is available, the IoT specifications are ready, and planned assets are in place. There are many more requirements, as you’d expect from a complex project. ITIL has 25 processes that managers can use to create a checklist to integrate the new technology into existing systems.
Understand and eliminate ITIL bottlenecks
You don’t want to put more burden on the system by introducing unnecessary players and layers. So look for the road blocks.
Top performers start with the ITIL Change Records and migrate to other areas. Examine details of failed changes. Look at which changes were recorded and which ones were not, and then decide how to address the failures.
Consider how to best streamline and automate changes. For example, one large financial institution we worked with realized that changing the business process for releasing a new price list required gigabytes of documents to be emailed for approval across a hierarchy of both business and technology leaders.
An email-centric process made sense 15 years ago, when email was the primary means of business communication. While it evolved over time, the company’s process hadn’t adjusted to current methods. In this case, the change committee replaced its email review with a centralized document repository. The new workflow eliminated a lot of lost time that had been spent responding to email messages.
One of our favorite examples of automating several ITIL processes comes from a large manufacturing company. As part of its software-defined data center strategy, it automated ITIL as a DevOps process improvement. If a monitoring tool reported that one application in its cloud service platform framework fell below the expected service-level agreement, the system would take action.
The framework relied on orchestration tools that alerted a microservice. The microservice then executed an automation recipe for that given business service (as long as the task did not bring production down or supply a mission-critical service).The microservice included several steps, including kicking off a script, creating an incident report, checking the code repository for the latest version, and updating the IT service management system.
In other words, the system programmatically addressed issues without human intervention unless a bigger issue emerged. This streamlined the process, required fewer resources, and made both technology and business teams happy. It didn’t have to label this as “self-healing” using ITIL definitions; it just took care of it.
Create a unified framework
Finally, ITIL process experts should empower their businesses within a new unified ITIL framework.
IT needs to give more credit and capability to business managers and their teams. Business team members, who work to serve the company’s customers, need the power to take action instead of waiting on a technology team or the systems it designs. It goes against human nature for people to sit and wait when they are under pressure to take action.
Create a system that empowers business users to take small but meaningful steps to assist customers. ITIL is based on recording the lifecycle of a service or an application, logically following its lifecycle and ensuring that participants can concentrate on managing relevant services.
One example of digital transformation automating ITIL processes highlights self-service and assisted service. We worked with one pharmaceutical company in which the technology team created a portal where business users or end users could perform basic functions such as resetting a password or updating a customer address. This seems obvious: “Born in the cloud” applications such as Facebook, Airbnb and Netflix regularly allow users to do that today. But many organizations still struggle to provide such basic online self-serve portals. It shouldn’t be that hard.
In another example, a DevOps team identified the business’s super-users (what Gartner refers to as “citizen developers”) and asked them to assist their peers during a new product rollout. The citizen developers created knowledge base articles with frequently asked questions. They also responded to repetitive questions and reported issues to the technology team, which enabled the business to prioritize changes and desired enhancements. The streamlined process created a much more collaborative environment. Empowering the best and brightest change agents enabled the DevOps team to focus on technology gaps instead of user errors while still tracking incidents, problems, and change tickets.
Ultimately, the IT Infrastructure Library is as critical today as it was when it started over 50 years ago. But it must be adapted, updated, and automated as part of a digital transformation strategy. DevOps and ITIL can be and should be companions in a continuous integration and continuous delivery process.
Lessons for leaders
- As users change behavior, the ITIL process implementation needs to change and adapt to fit the company’s needs.
- Identify the company’s preferred communication vehicle moving forward and rework your ITIL approval process to fit it.
- Instead of trying to retrain your entire IT department on a new process or methodology, consider streamlining and automating the current ones. Start with the change agents in the business employing shadow IT or otherwise working around the current processes. Map back what they are doing and why to address the core concepts in ITIL. Identify areas of automation and improvement within your current offerings.
This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.