ITIL 4: Connecting key concepts

1. Products, Services, and Service Relationships

A bit of context before I start: When I was in India last November, I was challenged by a group of
trainers to create a single diagram on a flipchart that depicted all the key elements of ITIL 4. Not
to blow my own trumpet, but I did come up with a diagram which shows how key concepts of ITIL
4 come together to create a flexible and effective service management architecture.

I’d like to start off by talking about a fundamental change that is needed in service management:
value is co-created, not delivered. In other words, the activities that a service provider undertakes
do not create value by themselves. Value is realized only when the consumer engages with the
service provider through the means of a service relationship. For further reading about value co-
creation, use your favorite search engine to look up “Service Dominant Logic”. Be warned, some
of the links will be academic journals, or focused on marketing. I rather like this document as an
introduction to the topic.

And so, in ITIL 4, we have modified the definition of a service:

Services: A means of enabling value co-creation by facilitating outcomes that customers want to
achieve, without the customer having to manage specific costs and risks

Long-time ITIL practitioners will recognize the changes made: the use of “value co-creation”, and
the clarification that the customer doesn’t have to manage specific costs and risks.

And so now let’s talk about products and services. These terms are often used almost
interchangeably, especially when there isn’t much differentiation between them. So, for example,
is the mobile bank app you use on your phone a product, or a service? The focus of product
management is typically on technology components – software and infrastructure – but this can
be generalized to the following definition:

Products: A configuration of an organization’s resources designed to offer value for a consumer

So, in ITIL 4, the product is a configuration of resource
that have the potential to co-create value with
customers (or more broadly, with consumers). The
service provider might have a product, or portfolio of
products, that have the potential to co-create value
with multiple customer segments.

Thus, we find the service provider can use its product

portfolio to create one or more service offerings. These
service offerings describe what the consumer can
expect from the service – quality, cost, time, risks, and
so on. Consumers choose the service offering that has
the greatest appeal and enter into a service
relationship where they interact with the provider’s
products to co-create value.

But wait! …… Value isn’t just for the consumer!

Let’s explore that in the next section.

2. Value for Stakeholders, PESTLE and the Four
Dimensions
In the last article, we briefly discussed the concept of value co-creation, and I’d like to expand on
that here.

While value is generated through interactions between service provider and customer, that value
may also be shared (or apportioned out) with multiple stakeholders. Some of these stakeholders
may even be external to the service provider.

Let’s take the mobile banking app I’d mentioned in my first post. While value is (visibly) generated
when the customer uses the app to pay bills, behind the scenes value is also generated for
auditors and tax authorities through the records created through the transaction. Additional value
may be generated through the interaction between the bank and an external supplier of services,
for example a payments processer.

So a single transaction must generate value for the customer – but it must also generate enough
additional value to meet the needs of other relevant stakeholders who might not actively
participate in the transaction. Failure to consider these multiple needs can lead to unwanted
consequences (suppliers refusing to renew contracts, tax authorities imposing fines, and so on).

These stakeholders in turn influence or constrain the service organization in a myriad of ways. In
ITIL 4, we looked at a common business analysis tool to help describe these influences – the
PESTLE model:

 Political
 Economic
 Social
 Technological
 Legal
 Environmental

Let me step away briefly and describe another concept in ITIL 4 – The Four Dimensions of Service
Management. At its heart, the Four Dimensions represent an evolution of the “4Ps of Service
Design” and can be traced back to the service assets model in ITIL v3. The Four Dimensions are:

 Organizations and People

 Value Streams and Processes
 Information and Technology
 Partners and Suppliers

The Four Dimensions interact and combine to create the products and service offerings that the
service organization provides to its customers (see blog post 1). To put it another way, a service
organization must take into account these Four Dimensions when planning, designing,
developing, and operating its products and services. Failure to adequately manage any of these
dimensions, or the interactions between these dimensions, can lead to failure to co-create
sufficient value for all stakeholders.

I believe the Four Dimensions also provide a lens through which to design and operate IT service
management as well. In other words, when creating an Incident Management Practice (more on
practices in later post), an ITSM professional must take into account the organization and its
people (management structure, culture, etc.), the value streams and processes the organization
needs to follow, the information assets and tools needed, as well as the support of partners and
suppliers.

The PESTLE model therefore describes external influences (or constraints) that impact the
management of products and services, or the management of IT service management
capabilities. For example, the introduction of GDPR has impacted the way an organization
manages its work, its information assets, and even the work of its partners and suppliers. And the
same regulation has impacted the way an organization collects and processes information
needed to execute its service management capabilities.

Generically speaking, the Four Dimensions model influences the system in which organizations
convert customer demand into value for multiple stakeholders – something that ITIL 4 refers to
as the Service Value System.
3. The Service Value System
In the last section, we briefly covered concepts such as multiple stakeholders, PESTLE, and the
Four Dimensions of Service Management. In this article we will be looking at the service value
system.

The service provider can be regarded as a system that converts demand from a myriad of sources
into value for multiple stakeholders. ITIL 4 calls this the service value system (SVS) and describes
five component parts that interact with each other and external stakeholders to co-create value.

The five parts of the SVS are:

1. Guiding Principles: These are recommendations on how to work, or make decisions,

for example: focus on value, think and work holistically, or collaborate and promote
visibility. Guiding Principles were first introduced in ITIL Practitioner in 2016. There are
now 7 guiding principles in ITIL 4, including a new one: optimize and automate.

2. Governance: ITIL v3 covered Governance in the Service Strategy book focused on

evaluating, directing and monitoring organizational performance but didn’t include it in
the examinations. As a result, most practitioners weren’t exposed to the concept through
training programmes. ITIL 4 repositions governance as a necessary component of the
SVS that allows the provider to convert demand into value for one or more stakeholder.

3. Service value chain: This is a set of loosely coupled activities (or archetypes) that any
service provider undertakes at some point (or even repeatedly). The service value chain
is made up of six value chain activities – Plan, Engage, Design & Transition,
Obtain/Build, Deliver & Support, and Improve. To put it another way the service provider
– be it a developer managing a micro-service, or an enterprise delivering technology-
enabled business services – will be engaging with external stakeholders, planning work,
delivering and supporting live products and services, and so on. A journey through the
Service Value Chain to convert demand to value is known as a Service Value Stream,
and I’ll cover this concept in my next blog post.
4. Practices: One of the challenges with ITIL v3 was that although the guidance was quite
vast (some might say too vast!), the reality was that most practitioners only saw small
subsets, usually through the lens of training and exams or a consulting engagement.
Thus, the world came to see ITIL as a process framework, which couldn’t be further
from the truth! With ITIL 4, we moved the focus towards “practices”, which is a holistic
view of the resources and capabilities needed to deliver service management work.

Practices follow the Four Dimensions model and talk about:

a. Organizations & People
b. Value Streams & Processes
c. Information & Technology
d. Partners & Suppliers

There are 34 practices in total, many of which are new to ITIL 4, and there are some
processes in ITIL v3 that don’t have an equivalent in ITIL 4. Fun insider titbit: Practices
were referred to as capabilities in early drafts of ITIL 4. Our crack team of translation
experts pointed out that the word capability doesn’t translate well into many of the
languages AXELOS supports, and suggested “practices” from the ITIL v3 glossary.

5. Continual improvement: The entire SVS is in scope for improvement! It’s not just
practices that can be improved – the way the organization works and makes decisions
can be improved; the way the provider evaluates, directs and monitors its performance
can be improved; certainly, the way the organization converts demand to value can be
improved. We had many discussions in our Lead Architect Meetings about where to
place continual improvement, and as a result you’ll see it both as a component of the
system and as a practice.
4. The Service Value Chain, and Service Value Streams
In the last section we briefly covered the service value system (SVS) and its five components.
One of those components is the service value chain.

The service value chain is a set of loosely coupled activities (or archetypes) that any service
provider undertakes at some point (or even repeatedly). Regardless of the size of the service
provider, the industry, the geography, or even the level of automation, the organization will
conduct the following activities at some point (perhaps even continuously):

 Engage: Interacting with external stakeholders to provide a good understanding of

needs, to promote transparency, and to foster good relationships with all stakeholders

 Plan: Creating a shared understanding of the vision, status and improvement directions
for all four dimensions and all products and services

 Improve: Ensuring continual improvement of products, services and practices across all
value chain activities and the four dimensions

 Design and Transition: Ensuring that products and services continually meet
stakeholder expectations for quality, cost, and time to market

 Obtain/ Build: Ensuring that service components are available when and where they
are needed, and that they meet agreed specifications

 Deliver and Support: Ensuring that services are delivered and supported according to
agreed specifications and expectations.

These activities can be combined and integrated in a myriad of ways to create a “journey” from
demand to value that reflects how the service provider completes work. ITIL 4 calls this “journey”
a value stream, and each value stream represents how the organization responds to specific
scenarios or types of demand. Techniques like value stream mapping can help organizations
streamline and optimize their value streams.

Value streams can be defined at any level of the organization, so there may be value streams at
the enterprise level, and completely different (yet ultimately connected) value streams for each
development or support team.

A value stream can be as linear or as waterfall (or not) as the organization requires. Equally, it
can be as dynamic or as agile (or not) as the organization requires. There are two key points to
always keep in mind about value streams:

 Value chain activities can repeat themselves over the course of a value stream – for
example, a value stream to respond to customer incidents would have an Engage activity
at the start (number 1, acknowledging the incident), and another at the end (number 6,
verifying resolution and customer satisfaction). It might have additional Engage activities
representing post-incident reviews or customer satisfaction surveys.
 Value streams ALWAYS start with Demand, and ALWAYS end with Value. Remember,
the goal of a value stream is to convert demand to value.

Practices support value chain activities at various points in the value stream. For example, when
engaging with a customer needing help (i.e. an incident), we might call upon the following
practices:

 Service Desk: Provides us with the tools, techniques, and even an empathetic mindset
and service-orientation to understand the customer’s needs
 Relationship Management: Provides us with the information and communication skills
to manage customer expectations
 Knowledge Management: Might provide access to a knowledge base which the service
provider can use to offer potential fixes
 Incident Management: Provides us with the tools, techniques, and workflows to register,
triage, classify, prioritise and assign the incident.
The list of practices above isn’t meant to be exhaustive! It serves to illustrate that practices support
and contribute to value chain activities. In ITIL v3 Incident Management has been seen purely as
a Service Operation activity. By decoupling the service value chain and practices, practitioners
can understand how a practice can contribute to several activities – in some cases to a greater
extent, and in some cases a lesser extent. In the ITIL 4 Foundation book, the reader will find a
colour-coded “heatmap” for each of the 34 practices that details the degree of interaction with the
service value chain, for example:

The other interesting thing about a value stream orientation is that it allows organizations to define
their common scenarios and workflows and map out the contributions needed from each practice.

In the example below, I have three value streams with seven identified contributions from the
incident management practice – thus, it only needs to support these seven touchpoints, and no
more.
To put it another way, the practices can be designed to only meet the needs of defined value
streams and nothing more. This is a “minimum viable service management” approach and will
hopefully push practitioners away from blindly copying or implementing process guidance found
in a book. It’s a very Lean way of defining service management practices!

The result of the value stream is a live, functioning product or service – something that the service
provider organization uses to co-create value with consumers…and thus we come full circle.

Welcome to ITIL 4!