ITIL 5 is emerging at an unusual moment. For the first time since service management took shape as a discipline, some of its most basic assumptions are under strain: the role of humans in day-to-day service delivery, whether long-standing process constructs still belong at the centre of the model, and how far service management now extends beyond IT.
AI is no longer a decision-support tool but an execution engine. Product-centric operating models are replacing function-centric delivery. Service is increasingly understood as an enterprise capability rather than an IT concern. These are not incremental adjustments. They are already breaking operating models, budgets, and accountability structures in large organisations, whether leaders acknowledge them or not.
PeopleCert have been clear that ITIL 5 is intended as an evolution rather than a rupture. That framing is understandable. It is also increasingly inadequate. What is unfolding across the industry looks less like a careful step forward and more like the early stages of a fundamental change in how services are designed, delivered, and governed.
It is worth being explicit about what ITIL has achieved. Few frameworks have had comparable impact on an entire professional discipline. ITIL gave service management a shared language at a time when the field was fragmented and largely implicit. It remains one of the most effective ways to onboard people into service thinking, through training, certification, and community as much as documentation. The critique that follows only matters because ITIL has been so influential, and because it continues to shape how millions of practitioners think about service work.
There is a tension running through this argument, and it is deliberate. This paper is written in the language of ITIL and service management because that is still where much of the operational grammar of large organisations lives. The direction of travel, however, is the opposite of reinforcing IT as an organising centre. The aim is to use the language that shaped today’s operating models to argue for their transcendence: services designed around outcomes that cut across the enterprise, until internal boundaries disappear from the flow of work altogether.
Although this discussion is grounded in service management, the audience it ultimately speaks to is an executive one. The constraints described here are not IT problems; they are enterprise design failures. Leaders who continue to treat service delivery as an IT-owned concern inherit fragmented journeys, diffused accountability, and demand that recirculates endlessly. The challenge is no longer to optimise practices within a function, but to redesign how the organisation delivers outcomes end-to-end, assigning clear ownership for results that employees and customers actually experience.
The Generations of Service
Service management has already passed through several distinct generations: keeping technology running, industrialising repeatable processes, and aligning services more closely with business outcomes. Most organisations today are consolidating around what might be described as service-aware delivery, where services are observable in real time and work is increasingly organised around products and value streams.
ITIL 5 largely reinforces this position. It formalises service awareness and enterprise relevance, but there is little evidence that it compels organisations decisively beyond it. The next shift, toward genuinely autonomous and self-governing service ecosystems, is unlikely to be incremental.
There is a structural constraint at work here that applies not just to ITIL, but to all large frameworks of its kind. They are acts of codification. What they capture is not where the most forward-leaning organisations are heading next, but what a critical mass of leading organisations have been doing over the last several years. That lag has usually been tolerable. In the current environment, it is not. When execution models, funding structures, and decision rights are being reshaped in real time by AI and automation, codifying recent best practice risks locking organisations into patterns that are already expiring.
Several themes are converging: a growing recognition of failure demand as a structural problem rather than an operational nuisance; a rebalancing of human and machine roles as AI moves from decision support to execution; and an expanding view of service as an enterprise capability rather than an IT function.
Failure demand: efficiency is not progress
Failure demand is recurring operational effort and cost caused by unresolved design decisions. It appears as access requests raised because identity is inconsistent, incidents logged because status is invisible, and rework generated because underlying conditions were never addressed.
This idea is not new, yet failure demand has largely been treated as something to be managed rather than eliminated. There is little indication that ITIL 5 fundamentally reframes this stance.
Demand is still primarily described as an input to be classified, prioritised, and processed. Incidents are resolved faster. Requests are routed more intelligently. Automation and AI reduce handling time and unit cost. These approaches make failure more efficient, but they do not challenge its legitimacy.
Historically, ITIL has pointed to Problem Management as the mechanism through which failure demand is reduced. In practice, it has rarely been given the authority required to eliminate systemic causes. Those causes usually sit in product design, policy, funding, or architecture, well outside the service function’s control. Problems are analysed, documented, and tolerated.
When services are treated as products, ownership of outcomes sits with product teams. Availability, reliability, user experience, cost-to-serve, and demand profiles become signals of product quality. In this context, failure demand is not support work; it is product debt.
ITIL 5 introduces stronger product language, but it stops short of explicitly tying persistent failure demand to product accountability. Even where AI is discussed, it is more often framed as a way to handle demand better rather than to remove the conditions that create it.
A future-ready service model treats failure demand as toxic. It is measured relentlessly, routed back to accountable owners as a design signal, and reduced through changes to products, policies, and architecture wherever possible. Based on what has been published to date, ITIL 5 appears to improve the management of failure demand. Whether it reframes it as something to be systematically eradicated remains unclear.
Humans and AI: letting machines take the chair
Since ITIL was first released in 1989, service management has become one of the most proceduralised domains in technology. Few disciplines have invested so heavily in workflows, approval paths, escalation rules, and classification schemes. This work was shaped to control human variability. It is also exactly the kind of work machines exploit best.
At its core, ITIL has always been a language for humans. Its practices, roles, and artefacts exist to impose structure where human behaviour would otherwise drift toward inconsistency and improvisation. Incident, change, problem, request: these are not properties of services so much as mechanisms for coordinating large numbers of people under uncertainty.
Even as ITIL 5 incorporates AI and automation, it still largely describes a world in which humans remain central to execution. Machines do not require the same scaffolding. They execute what is encoded, consistently and repeatedly, without fatigue or interpretation.
Change enablement illustrates the tension clearly. Traditional controls exist largely because humans are fallible. Machines can evaluate dependency graphs, simulate impact, enforce policy, and execute reversibly in ways no human process can match. In an execution-first paradigm, flow is no longer something to be documented and followed. It is codified and executed directly. Governance shifts from episodic checkpoints to continuously enforced policy. Humans move out of the flow of work and into roles focused on intent, design, and constraint.
So far, ITIL 5 positions AI primarily as a participant within human-centric processes rather than as a replacement for large classes of them. Its historical strength has been coordinating human effort. Its challenge now is whether it can meaningfully describe a service model where human coordination is no longer the dominant problem.
The enterprise embrace: from alignment to coherence
ITIL has long described service rather than IT, but it has typically been implemented through an IT lens. ITIL 5 makes a more explicit attempt to address this, introducing enterprise service management, shared value streams, and cross-functional services. The structure softens, but the underlying model remains recognisable.
At its core, ITIL 5 still assumes an enterprise composed of collaborating functions. Coordination improves, but ownership often remains distributed.
Consider onboarding a new employee. Identity, equipment, payroll, access, training, workspace. From the user’s perspective, this is one outcome. From the enterprise’s perspective, it is still often several services stitched together through handoffs, tickets, and goodwill. Every handoff adds delay, cost, and silence. No single executive can credibly claim ownership of the outcome.
ITIL 5 describes how these services should collaborate more effectively. It is less explicit about how, or whether, they should cease to be operationally separate.
A genuinely enterprise-native service model aligns ownership, funding, and accountability to outcomes. Internal boundaries still exist for stewardship and expertise, but they disappear from the flow of work. Machines execute across domains based on policy, entitlement, risk, and outcome, not departmental ownership.
ITIL 5 gestures toward this through value streams, but leaves substantial room for interpretation. That flexibility enables adoption. It also enables organisations to preserve function-first accountability rather than accountability wrapped around outcomes.
Evolution is not enough
ITIL 5 arrives with good instincts and careful language. It recognises that service management now extends beyond IT, that products matter, that value flows end to end, and that AI is reshaping delivery economics. What it consistently avoids is forcing the most disruptive implications of those shifts.
Evolution works when the environment is stable. The current environment is not.
The next generation of service management will be defined less by maturity and more by subtraction: less failure demand, less human execution, fewer organisational seams. ITIL 5 reads as a stabilising framework for organisations consolidating service awareness, not yet as a blueprint for autonomous, enterprise-native service ecosystems.
Waiting for frameworks to catch up is no longer a neutral choice. It is an active risk. The leaders who move next will not be the ones with the most refined process models, but the ones willing to remove failure demand at the source, take humans out of routine execution, and design their enterprises to operate as coherent systems rather than coordinated functions. The question ITIL 5 ultimately raises is not whether the framework evolves far enough, but whether leadership is prepared to act without waiting for permission from it.
Get in touch with our team to learn more about our services, explore partnership opportunities or discuss how we can help with your challenges.