ITIL 4 introduces several new concepts, which include the following:
- Service Value System
- Value Co-Creation
- Service Relationship Model
- Value, Outcomes, Costs, and Risks (VOCR)
- Value Streams
- ITIL’s Guiding Principles (updated from the ITIL Practitioner publication, released in 2016)
- General Management Practices (which include the following new ITIL practices: Architecture Management, Measurement and Reporting, Organizational Change Management, Project Management, Risk Management, and Workforce and Talent Management)
- Technical Management Practices (which include the following new ITIL practices: Infrastructure and Platform Management and Software Development and Management)
ITIL 4 also includes details on new(-ish) emerging technologies like cloud computing, infrastructure as a service (IaaS), machine learning, blockchain, etc. and weaves in concepts from Lean, Agile, Scrum, DevOps, and other modern ways of working. The topics included here will be further detailed in the following sections.
What is the ITIL Service Value System or SVS?
A Service Value System (shown in the diagram below) is a foundational concept in ITIL 4. The SVS shows how an organization takes opportunities and/or demand and rapidly provides value to customers using a combination of guiding principles, governance, service value chains (This concept is a subset of an organization’s overarching SVS and described in more detail below), practices, and continual improvement. To be successful (and for service management to work properly), an organization can no longer think in disparate silos, but work as a larger system.
What is the Service Value Chain or SVC?
The ITIL Service Value Chain (SVC) is a subset of an organization’s Service Value System. It’s defined as a set of interconnected activities that an organization performs to deliver a valuable product or services to its consumers and to facilitate value realization. Each of ITIL 4’s practices interact with different parts of the Service Value Chain at different times, often several times in the delivery of products and services.
What are the key Service Value Chain activities?
The six key activities of the Service Value Chain are Plan, Improve, Engage, Design and Transition, Obtain/Build, and Deliver and Support. Each of these contributes to value creation by transforming various inputs into specific outputs. These inputs may be external, or they may come from other activities within the value chain itself. Each activity is supported by one or more ITIL Practices. This combination of Service Value Chain activities and practices is then transformed into a value stream for specific tasks, or to respond to situations.
The Service Value Chain has key inputs and outputs for each activity. Inputs can come from external sources, such as Governance; they also come from other activities in the Service Value Chain, such as Improve, Engage, and Obtain/Build. Similarly, outputs can be provided to external consumers, as well as to other activities within the Service Value Chain. Here’s a deeper dive into each SVC activity:
- Plan: The Plan activity ensures understanding of the vision, current status, and improvement direction for all four dimensions of Service Management, as well as products and services across the organization. This is a strategic activity.
- Improve: The Improve activity’s purpose is the continual improvement of products, services, and practices across all the Service Value Chain activities and the four dimensions of service management.
- Engage: The Engage activity provides understanding of stakeholder needs, transparency, and good relationships with all stakeholders. This activity includes, often times, face-to-face human interaction, taking requirements from customers and transforming them into design requirements for the Design and Transition activity.
- Design and Transition: The Design and Transition activity ensures that services and products meet stakeholder expectations, considering quality, cost, and time-to-market. The primary focus of this activity is to take the requirements from Engage and provide specifications (this is a key output) for Obtain/Build. This activity also delivers new and changed services and products to the Deliver and Support activity.
- Obtain/Build: The Obtain/Build activity is responsible for ensuring that all service components are available when and where needed, and that they meet the agreed specifications. Requirements delivered by Design and Transition are transformed into service components that are, in turn, provided to the Deliver and Support activity, as well as to Design and Transition.
- Deliver and Support: The Deliver and Support activity delivers services and products to the customer, ensuring that product and service delivery meets agreed specifications and stakeholders’ expectations. This is where the proverbial rubber meets the road, and where the customer sees and co-creates value. Its primary inputs are the services and products delivered by Design and Transition as well as service components delivered by Obtain/Build.
What is Value Co-Creation?
In ITIL v3, value was described as something we created for customers. ITIL 4 takes a different perspective, putting more of a concentrated focus on the idea that service providers and service consumers must work together to create value, thereby co-creating it. Service providers cannot and should not create products and services (see diagram below) in a vacuum. Instead, we should actively collaborate with our customers on what is of value to them.
Within the ITIL 4 publication, a service is defined as:
- Service: The means of enabling value co-creation by facilitating outcomes that customers want to achieve, without the customer having to manage specific costs and risks.
There are also two types of key stakeholders defined within ITIL 4:
- Service Provider: When provisioning services, an organization takes on the role of the service provider. The provider can be external to the consumer’s organization, or they can both be part of the same organization.
- Service Consumer: When receiving services, an organization takes on the role of the service consumer. Service consumer is a generic role that is used to simplify the definition and description of the structure of service relationships.
Just as there can be different provider roles, consumers are also divided into different categories, namely:
- Customer: a person who defines the requirements for a service and takes responsibility for the outcomes of service consumption
- User: a person who uses the service
- Sponsor: a person who authorizes budget for the service
In some instances, the same person may serve in several roles. In other cases, different people may fill the various roles. As a Service Provider organization, it’s helpful to understand who fills each these roles.
What is the Service Relationship Model?
There are often multiple service relationships involved in providing products and services to customers; and a service provider for a consumer of that service may be a consumer of a service with a different service provider (as shown in the diagram below). The ITIL 4 Foundation publication provides an overview of the different types of service providers, including service customers and other stakeholders.
What are the 4 Dimensions of Service Management?
This concept replaces and expands upon the concept of the 4 Ps described in the ITIL v3 Service Design publication. It shows that there are several parts of an organization that need to be considered when delivering products and services; and that there should be a balanced focus between each of the four dimensions.
Note that ITIL 4 has moved Products—or more precisely, Products and Services—front-and-center as the final output of the 4 Dimensions. This makes sense, as each of these concepts is considered to co-create value. Additionally, Information and Technology has been added as a key component in this model. Information represents the knowledge necessary to manage services. While ITILv3 presented technology as important process enablers, ITIL 4 recognizes that technology itself is now being provided as a service. Software, storage, infrastructure, even information security can now be consumed through third-party suppliers and partners, making this dimension a critical component of the overall Service Management framework.
What is Value, Outcomes, Costs, and Risks (VOCR)?
In ITIL 4, there is a much larger emphasis on enabling customer value; and value is now defined as:
- Value: The perceived benefits, usefulness, and importance of something.
In evaluating whether a product or service has value for a customer, they are looking at the outcomes (What does this product or service allow me to do? What costs or risks does this product or service remove?), not just the output of the work. ITIL 4 defines the difference between the two:
- Output: a tangible or intangible deliverable of an activity (for example, an application)
- Outcome: results for a stakeholder enabled by one or more outputs (what that application allows me to do)
ITIL 4 also distinguishes cost from value. Where value is defined through the service consumer’s perception, cost is defined as:
- Cost: the amount of money spent on a specific activity or resource.
There are two types of cost from a consumer perspective. First, there are costs that are removed from the consumer by the product or service. This might be costs associated with staff that has been outsourced, technology provided as a service (cloud services), etc. Second, there are those costs that are imposed on the consumer by the product or service. Examples may include training, network or storage utilization, procurement, etc. This is commonly referred to as what a consumer must ‘invest’ to consume a service. In the end, the advantages of using a service (the removal of costs and risks) need to outweigh the disadvantages (the addition of negative outcomes, costs, or risks).
- Risk: a possible event that could cause harm or loss or make it more difficult to achieve objectives.
Risk may also be defined as uncertainty of outcome. When assessing the value of a service, risk may be used in the context of measuring both negative and positive outcomes. So, we also describe two types of risk. The first are risks removed from a consumer by the service (positive outcomes). This might include hardware failure if the consumer is moving to a cloud model, or staff availability if a function is being outsourced. Risk may not be entirely eliminated, only reduced, but the consumer may consider such reduction sufficient to support the value proposition of the service. Second, there are risks imposed on the consumer by the service (negative outcomes). This might be realized as a data security breach of the service provider.
What are Value Streams?
A new concept in ITIL 4 is that of value streams, defined as:
- Value Stream: A series of steps that an organization uses to create and deliver products and services to a service consumer.
A value stream is the string of activities that we as an organization perform to deliver value to a customer. Identifying and understanding the various value streams that an organization has is critical to improving our overall performance. When we as an organization examine how we perform work and map out our value streams, it allows us to analyze how work is being done across the organization and identify any barriers to workflow and non-value-add activities (i.e., waste). We also want to make sure we’re focusing on improving those activities contained within our value streams as shown in the diagram below.
What are ITIL’s Guiding Principles in ITIL 4?
ITIL 4’s Guiding Principles (pictured below) are as follows:
- Focus on value: Everything that an organization does needs to map to value for stakeholders
- Start where you are: Do not start from scratch and build something new without considering what is already available to be leveraged; investigate and observe the current state directly to ensure it is understood
- Progress iteratively with feedback: Do not attempt to everything at once; continuously gather and use feedback—before, during, and after—each iteration to ensure activities are appropriate and focused on the right outputs, even when circumstances change
- Collaborate and promote visibility: Working together across boundaries produces results that have greater buy-in, more relevance to objectives, and increased likelihood of long-term success; avoid hidden agendas, promote transparency, and share information to the greatest degree possible
- Think and work holistically: No service, or element used to provide a service, stands alone; outcomes will suffer unless the organization works as a whole, not just on its parts
- Keep it simple and practical: If a process, service, action, or metric fails to provide value or produce a useful outcome, eliminate it; use outcome-based thinking to produce solutions that deliver results
- Optimize and automate: Resources of all types should be used to their best effect; eliminate anything that is truly wasteful and leverage technology to its greatest capability
These principles should be kept in mind whenever approaching implementation of ITIL concepts. Not all principles will be critical in every situation, but they should all be reviewed on each occasion to determine how appropriate they are. While processes or practices may change over time or depending on the situation, guiding principles will not. ITIL’s Guiding Principles are universal and enduring.
How do the ITIL v3 processes map to the ITIL 4 practices?
For ITIL practitioners that are familiar with ITIL v3 processes, the table below provides a breakdown of the changes in terminology from ITIL v3 to ITIL 4.
- The black text below shows where the practice has the same name as a corresponding ITIL v3 process
- The blue text below shows were a practice has a changed or different name from an ITIL v3 process
- The orange text below shows where a new ITIL practice has been named. In some cases, a practice may have existed as a concept in the ITIL v3 publications (for example, Service Design existed as a Phase and Service Desk existed as a function in ITIL v3).
As the below table shows, not only have there been changes to naming conventions, the Practices have been divided into three broad domains, based on where the practice originated:
- General Management Practices have been adopted and adapted from general business management domains
- Service Management Practices have been developed in service management and ITSM industries
- Technical Management Practices have been adapted from technology management domains for service management purposes by expanding or shifting their focus from technology solutions to IT services
In each domain, there are some key Practices which have been either carried over or adapted from ITIL v3 processes. They include:
General Management Practices
- Continual Improvement. This practice is concerned with aligning an organization’s practices and services with changing business needs through the ongoing identification and improvement of services, service components, practices, or any element involved in the efficient and effective management of products and services. Included in the scope of the continual improvement practice is the development of improvement-related methods and techniques along with a continual improvement culture and mindset across the organization, in alignment with the organization’s overall strategy. The commitment to and practice of continual improvement must be embedded into every fiber of the organization. If it is not, there is a real risk that daily operational concerns and major project work will eclipse continual improvement efforts. The continual improvement practice also includes an update of the CSI model covered as part of ITIL v3 (see diagram below).
- Information Security Management. This practice is concerned with protecting the information needed by the organization to conduct its business. The required security is established by means of policies, processes, behaviors, risk management, and controls, which must maintain a balance between Prevention – Ensuring that security incidents don’t occur, Detection – Rapidly and reliably detecting incidents that can’t be prevented, and Correction – Recovering from incidents after they are detected. It is also important to achieve a balance between protecting the organization from harm and allowing it to innovate. Information security controls that are too restrictive may do more harm than good or may be circumvented by people trying to do work more easily. Information security controls should consider all aspects of the organization and align with its risk appetite.
- Relationship Management. This practice is focused on establishing and nurturing links between the organization and its stakeholders at strategic and tactical levels. The relationship management practice ensures that:
- Stakeholders’ needs and drivers are understood, and products and services are prioritized appropriately
- Stakeholders’ satisfaction is high and a constructive relationship between the organization and stakeholders is established and maintained
- Customers’ priorities for new or changed products and services, in alignment with desired business outcomes, are effectively established and articulated
- Any stakeholders’ complaints and escalations are handled well through a sympathetic (yet formal) process
- Products and services facilitate value creation for the service consumers as well as for the organization
- The organization facilitates value creation for all stakeholders, in line with the organization’s strategy and priorities
- Conflicting stakeholder requirements are mediated appropriately
- Supplier Management. This practice is concerned with ensuring the organization’s suppliers and their performance are managed appropriately to support the seamless provision of quality products and services. Activities that are central to the supplier management practice include:
- Creating a single point of visibility and control to ensure consistency
- Maintaining a supplier strategy, policy, and contract management information
- Negotiating and agreeing contracts and arrangements
- Managing relationships and contracts with internal and external suppliers
- Managing supplier performance
Service Management Practices
- Service Level Management. This practice is focused on setting clear business-based targets for service performance, so that the delivery of a service can be properly assessed, monitored, and managed against these targets. Service level management provides the end-to-end visibility of the organization’s services and helps negotiate and manage performance against Service Level Agreements (SLAs).
- Service Desk. The purpose of this practice is to capture demand for incident resolution and service requests. Service desks provide a clear path for users to report issues, queries, and requests, and have them acknowledged, classified, owned, and actioned. How this practice is managed and delivered may vary from a physical team of people on shift work to a distributed mix of people connected virtually, or automated technology and bots. The function and value of the service desk remain the same, regardless of the model.With increased automation and the gradual removal of technical debt, the focus of the service desk is to provide support for ‘people and business’ rather than simply technical issues. Service desks are increasingly being used to get various matters arranged, explained, and coordinated, rather than just to get broken technology fixed, and the service desk has become a vital part of any service operation. A key point to be understood is that, no matter how efficient the service desk and its people are, there will always be issues that need escalation and underpinning support from other teams. Support and development teams need to work in close collaboration with the service desk to present and deliver a ‘joined up’ approach to users and customers.The service desk may not need to be highly technical, although some are.However, even if responsibility of the service desk is simple, it still plays a vital role in the delivery of services and must be actively supported by its peer groups. It is also essential to understand that the service desk has a major influence on user experience and how the service provider is perceived by users. Another key aspect of a good service desk is its practical understanding of the wider organization, the business processes, and the users. Service desks add value not simply through the transactional acts of, for example, incident logging, but also by understanding and acting on the business context of this action. The service desk should be the empathetic and informed link between the service provider and its users.
- Incident Management: This practice is concerned with minimizing the negative impact of incidents by restoring normal service operation as quickly as possible. Incident management can have an enormous impact on customer and user satisfaction, and on how customers and users perceive the service provider. Every incident should be logged and managed to ensure that it is resolved in a time that meets the expectations of the customer and user. Target resolution times are agreed, documented, and communicated to ensure that expectations are realistic. Incidents are prioritized based on an agreed classification to ensure that incidents with the highest business impact are resolved first. Organizations should design their incident management practice to provide appropriate management and resource allocation to different types of incidents. Incidents with a low impact must be managed efficiently to ensure that they do not consume too many resources. Incidents with a larger impact may require more resources and more complex management.There are usually separate processes for managing major incidents, and for managing information security incidents. As with ITIL v3, the concept of a “Major Incident” is included in the ITIL 4 material and this term is defined as: Major Incident: The highest category of impact for an incident. A major incident results in significant disruption to the business. Major incidents have their own procedure with shorter timeframes, when compared to day-to-day incidents, and will often invoke an organization’s disaster recovery / service continuity management activities.
- Service Request Management. This practice focuses on supporting the agreed quality of services by handling all pre-defined, user-initiated service requests in an effective and user- friendly manner. Service requests are a normal part of service delivery and are not a failure or degradation of service, which are handled as incidents. Since service requests are pre-defined and pre- agreed as a normal part of service delivery, they can usually be formalized, with a clear, standard procedure for initiation, approval, fulfillment, and management. Service request management is dependent upon well-designed processes and procedures, which are operationalized through tracking and automation tools to maximize the efficiency of the practice. Different types of service request will have different fulfilment workflows, but both efficiency and maintainability will be improved if a limited number of workflow models are identified. When new service requests need to be added to the service catalog, existing workflow models should be leveraged whenever possible.
- Monitoring and Event Management. The purpose of this practice is to systematically observe services and service components, and record and report selected changes of state identified as events. The monitoring and event management practice manages events throughout their lifecycle to prevent, minimize, or eliminate their negative impact on the business. Monitoring and event management helps to identify and prioritize infrastructure, services, business processes, and information security events, and establishes the appropriate response to those events, including responding to conditions that could lead to potential faults or incidents. The monitoring part of the practice focuses on the systematic observation of services and the CIs that underpin services to detect conditions of potential significance. Monitoring should be performed in a highly automated manner and can be done actively or passively. The event management part focuses on recording and managing those monitored changes of state that are defined by the organization as an event, determining their significance, and identifying and initiating the correct control action to manage them. Frequently the correct control action will be to initiate another practice, but sometimes it will be to take no action other than to continue monitoring the situation.Monitoring is necessary for event management to take place, but not all monitoring results in the detection of an event. Not all events have the same significance or require the same response. Events are often classified as informational, warning, and exceptions. Informational events do not require action at the time they are identified, but analyzing the data gathered from them later may uncover desirable, proactive steps that can be beneficial to the service. Warning events allow action to be taken before any negative impact is experienced by the business, whereas exception events indicate that a breach to an established norm has been identified (for example, to a service level agreement). Exception events require action, even though business impact may not yet have been experienced.
- Problem Management. This practice is concerned with reducing the likelihood and impact of incidents by identifying actual and potential causes of incidents and managing workarounds and known errors. Every service has errors, flaws, or vulnerabilities that may cause incidents. They may include errors in any of the four dimensions of service management. Many errors are identified and resolved before a service goes live. However, some remain unidentified or unresolved, and may be a risk to live services. In ITIL, these errors are called problems and they are addressed by the problem management practice. Problems are related to incidents, but should be distinguished as they are managed in different ways:
- Incidents have an impact on users or business processes and must be resolved so that normal business activity can take place.
- Problems are the causes of incidents. They require investigation and analysis to identify the causes, develop workarounds, and recommend longer-term resolution. This reduces the number and impact of future incidents.
In the problem management practice, there are three phases that generally take place as shown below.
- Change Control. The goal of the change control practice is to maximize the number of successful IT changes by ensuring that risks have been properly assessed, authorizing changes to proceed, and managing the change schedule. The scope of change control is defined by each organization. It typically includes all IT infrastructure, applications, documentation, processes, supplier relationships, and anything else that might directly or indirectly impact a product or service. It is important to distinguish change control from organizational change management. Organizational change management manages the people aspects of changes to ensure that improvements and organizational transformation initiatives are implemented successfully. Change control is usually focused on changes in products and services.Change control must balance the need to make beneficial changes that will deliver additional value with the need to protect customers and users from the adverse effect of changes. All changes should be assessed by people who are able to understand the risks and the expected benefits; the changes must then be authorized before they are deployed. This assessment, however, should not introduce unnecessary delay. The person or group who authorizes a change is known as a change authority. It is essential that the correct change authority is assigned to each type of change to ensure that change control is both efficient and effective. In high-velocity organizations, it is a common practice to decentralize change approval, making the peer review a top predictor of high performance.As with ITIL v3, ITIL 4 defines three main categories of change – Normal, Emergency, and Standard changes (as shown below). However, the idea of the Change Advisory Board (CAB) is replaced by “change authority” to account for decentralization and other techniques that allow organizations to increase the speed of making changes (as seen in DevOps and Agile environments).
- IT Asset Management. This practice is concerned with planning and managing the full lifecycle of IT assets. The scope of IT asset management typically includes all software, hardware, networking, cloud services, and client devices. In some cases, it may also include non-IT assets such as buildings or information where these items have a financial value and are required to deliver an IT service. IT asset management can include operational technology (OT), including devices that are part of the Internet of Things. These are typically devices that were not traditionally thought of as IT assets, but that now include embedded computing capability and network connectivity. Understanding the cost and value of assets is essential to also comprehending the cost and value of products and services and is therefore an important underpinning factor in everything the service provider does. IT asset management contributes to the visibility of assets and their value, which is a key element to successful service management as well as being useful to other practices. The ITIL v3 process named Service Asset and Configuration Management was separated into two ITIL 4 Practices – IT Asset Management and Service Configuration Management, which will be detailed further below.
- Service Configuration Management. The purpose of this practice is to ensure that accurate and reliable information about the configuration of services, and the CIs that support them, is available when and where it is needed. Configuration management provides information on the CIs that contribute to each service and their relationships: how they interact, relate, and depend on each other to create value for customers and users. This includes information about dependencies between services. This high-level view is often called a service map or service model, and forms part of the service architecture. It is important that the effort needed to collect and maintain configuration information is balanced with the value that the information creates. Maintaining large amounts of detailed information about every component, and its relationships to other components, can be costly, and may deliver very little value. The requirements for configuration management must be based on an understanding of the organization’s goals, and how configuration management contributes to value creation. In short, the IT Asset Management practice is about understanding “content” (what we have), and the Service Configuration Management practice is about understanding “context” (the relationships between what we have).
- Release Management. This process is focused on making new and changed services and features available for use. A release may comprise many different infrastructure and application components that work together to deliver new or changed functionality. It may also include documentation, training (for users or IT staff), updated processes or tools, and any other components that are required. Each component of a release may be developed by the service provider or procured from a third party and integrated by the service provider. Releases can range in size from the very small, involving just one minor changed feature, to the very large, involving many components that deliver a completely new service. In either case, a release plan will specify the exact combination of new and changed components to be made available, and the timing for their release. A release schedule is used to document the timing for releases. This schedule should be negotiated and agreed with customers and other stakeholders. A release post-implementation review enables learning and improvement and helps to ensure that customers are satisfied. In some environments, almost all the release management work takes place before deployment, with plans in place as to exactly which components will be deployed in a release. The deployment then makes the new functionality available. The ITIL v3 process named Release and Deployment Management was separated into two ITIL 4 Practices – Release Management and Deployment Management, which will be detailed further below.
Technical Management Practices
- Deployment Management. The purpose of this practice is to move new or changed hardware, software, documentation, processes, or any other component to live environments. Deployment management works closely with release management and change control, but it is a separate practice. In some organizations, the term ‘provisioning’ is used to describe the deployment of infrastructure, and deployment is only used to mean software deployment, but in this case the term deployment is used to mean both. In short, the Deployment Management practice is typically an IT decision to move components to live environments, whereas the Release Management practice is typically a business decision to make services and features available for use by customers. These practices can be performed separately as seen within Agile/DevOps environments and pictured in the diagram below.