The ITIL 4 Service Value Chain (SVC) is the central operating model in the framework. It includes six activities — plan, improve, engage, design and transition, obtain/build, deliver and support — that work together to convert demand into value. The framework presents these activities as flowing in coordinated ways with information and trigger flows linking them.
The way it's taught is tidy. The way it operates in production environments is messier in specific ways. This piece is about the gaps and what to actually do about them.
What the textbook shows
The textbook diagrams show the six activities arranged with clear information flows between them. Demand enters through Engage. Value exits through Deliver and Support. The activities work together with explicit handoffs and feedback loops. The framework feels coherent and actionable.
The training materials typically present case studies that fit this clean operating model. The case studies show coordinated work across the value chain producing measurable value outcomes. The implication is that organisations adopting ITIL 4 should expect to see their service operations align with this model.
What actually happens in production environments
Most production IT service management environments don't actually map cleanly onto the SVC activities. The work that happens day-to-day involves people doing specific tasks — handling tickets, executing changes, managing incidents, fulfilling requests, supporting projects — that don't always have clear correspondence to the SVC activities as defined.
The information flows that the textbook shows as clean handoffs are often messy in practice. Demand information might enter through Engage activities (formal service requests) but it also enters through informal channels (someone bumps into the service manager in the hallway and mentions a problem), through monitoring systems (an alert fires and someone notices), through escalation chains (a manager pushes a project that wasn't in the formal portfolio), and through various other paths the framework doesn't explicitly address.
The decision-making about what to actually do with demand is also distributed across the organisation in ways the SVC doesn't capture cleanly. Decisions about what to obtain or build, what to design or transition, what to plan or improve get made in various meetings, by various people, with various levels of process discipline. The clean Plan activity that the textbook shows is rarely the only place where planning actually happens.
Why the gap exists
The gap between textbook and production isn't because organisations are doing it wrong. It's because the framework is necessarily simplified relative to actual organisational operations.
The framework presents an idealised operating model that captures the major activities and flows. It doesn't and can't capture all the informal coordination, exception handling, and ad hoc work that real organisations rely on to actually deliver services. Trying to make production environments match the framework exactly would require eliminating most of the informal coordination, which would make the operations much less effective rather than more effective.
The framework is meant to be a reference model that organisations adapt to their context. The training material doesn't always make this adaptation step explicit. People come out of training expecting their organisations to look like the framework rather than understanding that their organisations should adapt the framework to fit their actual operating realities.
What to actually do with the SVC
The productive use of the SVC in production environments is to use it as a diagnostic tool rather than as a target operating model.
The SVC activities give you a vocabulary for talking about the work that happens in your service management operations. You can use the activities to identify where work is happening and where it isn't. You can use the information flows to identify where coordination is working and where it isn't. You can use the framework to surface gaps in your operating model that warrant attention.
This use is meaningful but is different from the use the training material implies. The training implies you should restructure your operations to fit the framework. The diagnostic use treats the framework as a lens for understanding your actual operations and identifying targeted improvements.
Most successful ITIL 4 implementations I've seen in production environments take the diagnostic approach rather than the restructuring approach. They use the framework to talk about service management more clearly, to identify specific gaps that warrant attention, and to align improvement work across the organisation. They don't try to make their day-to-day operations look exactly like the textbook diagrams.
The specific gaps that matter most
Across the production environments I've worked in, certain gaps between textbook and reality come up consistently and warrant explicit attention.
The Plan activity is often disconnected from the operational activities. The strategic planning work that produces service portfolio decisions often happens in isolation from the operational realities that the plans need to account for. This produces plans that look good on paper but don't survive contact with operational reality.
The Improve activity is often under-resourced relative to what the framework implies. Continuous improvement work requires sustained attention and effort that operational pressures often consume. The "Improve" activity in the SVC is real but is rarely happening at the intensity the framework would suggest.
The information flows between activities are often broken or unclear. The handoffs that look clean in the diagram are often unclear in practice — who is supposed to communicate what to whom, in what format, at what trigger points. Making these flows explicit and functional is often the highest-leverage SVC-related work in production environments.
The Engage activity often captures only formal demand and misses the informal demand that actually drives a lot of service work. Building Engage capability that captures the broader demand picture is usually meaningful work for organisations trying to improve their service management.
What the training material should say
If I were redesigning the ITIL 4 training, I would spend more time on the gap between the framework and production realities and less time on the framework's internal consistency.
Trainees should leave the courses understanding that the SVC is a reference model that they need to adapt to their context, not a target state they should be trying to make their organisations match. They should have specific tools for identifying gaps between their operations and the framework, and for prioritising which gaps to address based on their organisation's specific situation.
This kind of training is harder to deliver than the textbook approach because it requires engaging with the messy realities of production environments rather than the clean abstractions of the framework. It's also more useful to actual practitioners.
The training market hasn't moved much in this direction because the cleaner training is easier to standardise and easier to certify against. The trade-off is that practitioners come out of training with less practical capability than the training time would suggest.
What I tell people taking the courses
When colleagues ask me about ITIL 4 courses I tell them to take the courses for the credentials and the conceptual vocabulary, but to expect to do their own work to translate the framework into their production context. The translation work is where the value actually accrues.
I tell them not to be disappointed when their organisations don't match the textbook. The textbook is necessarily simplified. The work of making the framework useful in their specific context is the actual job, not the failure of their organisation to match an idealised model.
I tell them to use the SVC as a vocabulary for talking about service management work, as a diagnostic tool for identifying gaps, and as a way to align improvement work across the organisation. I tell them not to try to restructure their operations to fit the framework directly.
This advice is more useful than the official training material's framing. It also matches what successful ITIL 4 practitioners actually do in their own work. The framework is a tool. The tool is useful when used in a context-aware way and is much less useful when applied as if it were a target operating model.
The honest assessment of ITIL 4 in production is that the framework is good and the training is okay and the gap between the two is the practitioner's responsibility to close. Once you understand this, the framework becomes much more useful than it appears from the training experience alone.
