ITIL Foundation (Version 5)

ITIL Foundation (Version 5) provides the building blocks of ITIL (Version 5) and is the first step in the ITIL learning journey.

Module 6: Value chain and ITIL management practices

 

Operating models and value chains

Operating Model Canvas

This is a highly-regarded tool to understand or design the operating model of an organisation. Written by Andrew Campbell, Mikel GutiƩrrez and Mark Lancelott. See https://operatingmodelcanvas.com/ for the blog and videos, as well as links to purchase the book and course.

I don't think the diagram on slide 136 is correct. The L in the POLISM model does not correspond to Technology in the ITIL VS model. The ITIL model doesn't have a separate concept of "location".

Purpose, operating model, and value chain

TODO

 

Discover

 

Design

Human-centred design

https://en.wikipedia.org/wiki/Human-centered_design

Two books I own, both of which are very good.
IT service by design by Mark Smalley and Catherine Zuim. Note that Mark Smalley is one of the contributors to the Foundation official book.
The Design of Everyday Things by Don Norman (one of the pioneers of HCD).

 

Acquire

SCM, ITAM

The slides define the CMDB but should also define the IT asset register.

Configuration Management System (CMS): A set of tools, data, and information that is used to support the service configuration management practice.br /> Configuration Management Database (CMDB): A database used to store configuration records throughout their lifecycle. It also maintains the relationships between configuration records.
Service configuration management practice § 2.2.2.

IT asset register: A collection of information about IT assets that includes their ownership, cost, and other key characteristics. The IT asset register makes it possible to quickly understand the lifecycle stage of all IT assets.
IT asset management practice § 2.2.3.

 

Build

Testing

Service validation and testing practice guide § 2.1.1 and § 2.1.2.

CICD

The "central repository" is a key point for CI. One of our other staff here uses the phrase "CI is about not letting programmers trample all over each others' code".

Note that the rest of CICD is defined in the Transition section.

 

Transition

CI/CD

I don't think the definition of continuous delivery is not technically correct.

Continuous delivery is a set of techniques and tools that automate development so that the software is in a deployable state. Actual deployment and release activities are manual.

Continuous deployment automates the deployment and/or release of the software.

https://en.wikipedia.org/wiki/CI/CD

 

Operate

When?

Operate starts the minute Transition completes (or maybe earlier) and continues for the entire lifetime of the product.

Terms

Reliability: The ability of a product, service, or other configuration item to perform its intended function for a specified period of time or number of cycles.
Maintainability: The ease with which a service or other entity can be repaired or modified.
Observability: The organization’s ability to understand the internal state of an IT system, service, or product, based on the data it generates. May also refer to the features of an IT system, service, or product, enabling and supporting this organization’s ability.
Infrastructure and platform management practice guide § 2.2.5.

Event: Any change of state that has significance for the management of a service or other Configuration Item (CI).
Monitoring and event management practice § 2.1.

Note that an event is not intrinsically good or bad; it is just something we care about. A car going under a sensor on a toll road is an event, and is a good event (some revenue for the operators of the road).

Incident is discussed more in the Support section.

 

Deliver

Customer

Communication between the provider and the customer is (mostly) covered by the service level management practice.

Service Level Agreement (SLA): A documented agreement between a service provider and a customer that identifies both services required and the agreed level of service.
Service level management practice § 2.2.

An SLA lists what services the provider will offer to this customer and what the expected levels of those service are. The SLA includes pre-agreed BAU actions that users can request (service requests, see below).

The provider measures its actual levels against those expected levels. These are usually discussed with the customer at service reviews.

User

Communication between the provider and the user is covered by the service desk practice. User communications to the provider will almost always be one of three types. Requests for pre-agreed services (service requests), notifications that something is not working (incidents, see the support activity), or requests for new services (which need to be sent to various project teams).

Service request: A request from a user or a user's authorized representative that initiates a service action which has been agreed as a normal part of service delivery.
Service request management practice guide § 2.1.

 

Support

Incident, Disaster

An incident is an interruption or reduction in quality of the service the the provider is providing to the consumer. Incidents need to be resolved; by resuming full service (abbreviations for this include RTO and RTS). Incidents could be minor or major. The incident management practice covers incidents.

A disaster is something that causes massive damage. It possibly involves evacuations, engagement with emergency services, and major disruption to operations. The service continuity management practice covers disasters.

There is a huge overlap between the two. A major incident is likely to be a disaster, and a disaster is almost certainly a major incident (unless our availability management is really, really good). The difference is the focus. Incident management only considers RTS, disaster management focuses on maintaining some level of service during the disaster.

ITIL suggests that the business develops criteria for an event to be formally classed as a disaster and/or major incident, which formally kicks off disaster recovery procedures.

Disaster: A sudden unplanned event that causes great damage or serious loss to an organization. To be classified as a disaster, the event must match certain business-impact criteria that are predefined by the organization.
Service continuity management practice guide § 2.1.

Incident: An unplanned interruption to a service or reduction in the quality of a service.
Incident management practice guide § 2.2.

Major incident: An incident with significant business impact, requiring an immediate coordinated resolution..
Incident management practice guide § 2.2.2.

Problem

Problems and known errors are part of the problem management practice, which focuses on establishing if there are actual root-causes of incidents and then fixing them or developing workarounds for them.

Problem: A cause, or potential cause, of one or more incidents.
Problem management practice guide § 2.2.

Known error: A problem that has been analysed but has not been resolved.
Problem management practice guide § 2.2.2.

Workaround: A solution that reduces or eliminates the impact of an incident or problem for which a full resolution is not yet available. Some workarounds reduce the likelihood of incidents.
Problem management practice guide § 2.2.2.

Error

Personal comment: To be honest, I don't understand this term or why it was added to ITIL (Version 5). Why do we need two terms for a cause of incidents? I guess we'll see when more version 5 books are released.