Upgrade Your Knowledge | USU Blog

ITIL 4: New Concepts, More Service Value

Written by Martin Landis | Oct 22, 2020 8:33:08 AM

ITIL 4 replaced silos with value streams connecting IT to business outcomes. Understand why the new framework matters for IT service management

ITIL 4, released in 2019, fundamentally reshaped how organizations approach IT service management. Instead of organizing IT work into isolated processes, ITIL 4 introduced the "service value system"—a framework that connects every IT activity to a business outcome. This shift reflects the real world: cloud adoption, DevOps, and automation made the old process-siloed model obsolete. The new model is value-driven, not process-driven.

The practical impact: IT teams can now map their work to business impact, reduce hand-offs between teams, and see where their efforts actually deliver value. This is why IT leaders migrating from ITIL v3/2011 to ITIL 4 often restructure their entire operating model.

What is ITIL 4's service value system? 

ITIL 4's service value system is a generic operating model that defines how IT organizations should work: what they do (processes), who does it (organization), and what tools they use (technology). The core principle is that all IT activity must start with a business demand and end with delivered value.

The model is organized around six generic activity types—the building blocks of any value-creating workflow. These aren't rigid processes; they're archetypes that teams use to label the steps in their own workflows. For example, resolving an incident follows a demand→engage→deliver→value sequence. Launching a new service follows the same pattern. This consistency across different IT activities is what makes the service value system powerful: one framework, many applications.

The six generic activity types:

    • Plan — Assess business needs and define IT strategy and direction
    • Engage — Coordinate with internal and external stakeholders; gather requirements
    • Design & Transition — Develop solutions; prepare for deployment
    • Deliver & Support — Execute and maintain the service
    • Improve — Monitor performance; identify and implement improvements
    • Obtain/Build — Procure, build, or configure components needed to deliver the service

These activity types replace the old v3 concept of isolated IT functions. Now, a single business outcome might touch multiple activity types across multiple IT teams. The service value system makes that orchestration visible and intentional.

Key takeaways:

    • Service value system maps IT work to business outcomes, not just internal processes
    • Six generic activity types apply across all IT service management work
    • Consistent framework reduces hand-offs and clarifies accountability
    • All activities should start with business demand, end with delivered value
    • This is fundamentally different from ITIL v3's process-siloed approach

How do ITIL 4 practices differ from ITIL v3 processes? 

ITIL v3/2011 organized IT disciplines into 26 processes grouped into four functions (Service Strategy, Service Design, Service Transition, Service Operation, Continual Service Improvement). ITIL 4 replaced this with 34 "practices" that cut across the old functional boundaries.

A practice is broader than a process. Each ITIL 4 practice PDF includes:

    • The practice's role in the service value chain (e.g., does it focus on Plan or Deliver & Support activities)
    • Applicable processes within the practice
    • Organizational roles and responsibilities
    • Information and technology requirements
    • Supplier and partner considerations

Examples: "Incident Management" and "Service Catalog Management" are familiar ITIL v3 processes; they exist in ITIL 4 too, but now as practices embedded in the service value system. Completely new practices like "Workforce and Talent Management" and "Monitoring and Event Management" reflect modern IT realities that v3 didn't address.

The shift from processes to practices means:

    • Less rigid; more adaptable to your organization's structure
    • Explicit connection to business value, not just internal workflow
    • Guidance on organization and technology, not just steps
    • Accounts for modern tools, cloud, automation, and DevOps

Compared to v3's 26 processes organized by function, ITIL 4's 34 practices are outcome-oriented and cross-functional.

Key takeaways:

    • ITIL 4 practices replace ITIL v3 processes; 34 practices vs. 26 processes
    • Practices are broader; include roles, technology, suppliers, not just workflows
    • Practices connect to the service value system; v3 processes were siloed by function
    • New practices like Monitoring and Event Management reflect modern IT operations
    • Practice-based approach is more flexible than rigid process definitions


What are ITIL 4 service value streams?

A service value stream is a specific workflow that delivers value for a particular business scenario. It's not an abstract concept—it's a concrete sequence of activities, practices, and roles that tie together to solve a real problem.

ITIL 4 defines four canonical value stream scenarios:

    • End user needs an incident resolved — Typical for service desk workflows
    • Third-party software creates an end user issue — Requires vendor coordination
    • Business requirement for a new IT service — Involves planning, design, and rollout
    • Regulatory change requires new software development — Involves compliance and change management

Let's trace the first example: incident resolution. A warehouse manager detects a WiFi outage affecting order transmission. Here's how the service value stream flows:

This value stream shows four key insights:

    • Multiple practices involved — Not just Incident Management; also Change Enablement, Configuration Management, and Continual Improvement
    • Explicit improvement loop — The "Improve" activity type appears twice, showing that learning happens during resolution and after
    • Business outcome is the end point — Value is realized when the warehouse manager can work, not when the ticket is closed
    • Clear accountability — Each activity type has defined roles; hand-offs are visible

This is fundamentally different from ITIL v3, which would describe incident handling as a linear process: Detect → Log → Prioritize → Investigate → Resolve → Close. ITIL 4's value stream shows the same work, but with improvement woven in and business value as the target.

Key takeaways:

    • Service value streams are concrete workflows for specific business scenarios
    • Each stream combines activity types, practices, and roles into a coherent sequence
    • Improvement is built into the flow, not tacked on afterward
    • Business value is the end point, not ticket closure
    • Value streams make hand-offs and dependencies visible across teams

 Why does the SVS matter for your IT?  

The service value system isn't academic. It has three practical implications:

1. Clarity on value — IT teams can now point to any workflow and say "here's where we create value for the business." This shifts conversations from "Did we follow the process?" to "Did we deliver the outcome?" This clarity is essential for IT leaders justifying budget and for teams understanding why their work matters.

2. Reduced hand-offs — By mapping work to the six activity types instead of rigid functional silos, teams see where work moves between departments. This visibility often reveals unnecessary hand-offs that slow down delivery. DevOps teams, for example, can now combine Design & Transition, Deliver & Support, and Improve into continuous workflows instead of sequential stages.

3. Easier adoption of new tools and practices — ITIL 4's flexibility means teams can adopt practices like AI-driven monitoring or infrastructure as code without rebuilding their entire operating model. ITIL v3's process silos made this harder.

Key takeaways:

    • Outcome-driven approach aligns IT with business strategy
    • Value stream mapping reveals and removes unnecessary hand-offs
    • Flexible framework accommodates modern tooling and practices (automation, AI, cloud)
    • Less organizational restructuring required; more evolutionary adoption