EXIN Basic Training Material ITIL

Basic Training Material for ITIL® Foundation
Issue: December 2015

© EXIN 2015 All rights reserved
ITIL®, PRINCE2®, MSP®, M_O_R®, MoP®, MoV® and P3O® are Registered Trade Marks of AXELOS Limited.
Welcome to the Basic Training Material (1)
• These slides contain basic presentation material to prepare students for the
ITIL® Foundation examination. They may be used as a basis for an
accredited training. All the topics in the exam requirements are covered.
Trainer notes are included.
• A good training will always require extra examples, practice, elaborating

subjects of special interest to the audience and a good time schedule,
including break-out sessions. See next slide.
• The order in which the subjects are presented here, follow the order of the
exam requirements, which is not necessarily the order in a good training
course. You can change the order while turning this material into your own
training.
• When using this basic material your organization will still need to go through
the normal accreditation procedure at EXIN.
Welcome to the Basic Training Material (2)
To complete your training the following must be added:
For course participants:

• Assignments to balance theory and practice
• Material to prepare for the exam (sample exam, syllabus/preparation guide)
• Practical assignments (if part of the exam pre-requisites)
• Description of course objectives and target audience
• A basic course schedule
• All topics addressed in the relevant exam syllabus to the correct level and breadth
• All appropriate trademark and copyright statements
• A clear structure to offer a quality learning experience
• Clear instructions on how the course is used (for e-learning)
• A good mixture of text, graphics, and/or audio facilities (for e-learning)
• Mechanisms to consolidate learning points and test understanding (for e-learning)
For trainers:
• A description of how the event is intended to be run
• An hour to hour schedule
• Teaching guidelines
• Additional notes to the presentation
• Solutions/marking guidelines for exercises, assignments, and sample exams
• How a trainer can be reached in case of questions (for e-learning)
• The expected response time in case of questions (for e-learning)
About EXIN
EXIN: 30 years of experience in certifying the competences of ICT
professionals
EXIN is the global independent certification institute for ICT-professionals. With
30 years of experience in certifying the competences of over 2 million ICT-
professionals, EXIN is the leading and trusted authority in the ICT-market. With
over 1000 accredited partners EXIN facilitates exams and e-competence
assessments in more than 165 countries and 20 languages. EXIN is co-initiator of
the e-Competence Framework, which was set up to provide unambiguous ICT
certification measurement principles within Europe and beyond. For further
information, please visit www.exin.com
Trade Marks
EXIN® is a Registered Trade Mark of EXIN. is a Registered Trade Mark of EXIN.
ITIL®, PRINCE2®, MSP®, M_O_R®, MoP®, MoV® and P3O® are Registered Trade Marks of AXELOS
Limited.
IT Infrastructure Library® is a Registered Trade Mark of AXELOS Limited.

IP Guidelines
This material contains the basic building blocks for your organisation's ITIL courseware material.The visuals
have been copied from AXELOS publications. Please be aware of the following AXELOS rules below. It is your
responsibility to apply these rules to your training material.
• All material created by ATOs/ACOs/Affiliates should accurately reflect the copyright position by displaying an
appropriate copyright statement, for example:
© 2013 copyright of Joe Bloggs & Associates unless otherwise stated.
Copyright statements can be used as the master template footer and/or header provided there is clear and correct
differentiation between ATO/ACO material and AXELOS material.
• Any text taken directly from an AXELOS publication or other AXELOS source must be differentiated from ATO text.This
can be done in a number of ways and will depend largely on what suits each individual document or product.The
method used must be identified within the document/course material and be clear to the reader.
Some examples of how this can be done are illustrated on the next slide. These are from the official IP
guidelines, annex 3.
The exact guidelines can be found in the document AXELOS Accredited IP Guidelines V1, to be found on EXIN
Partnernet
Diagrams and Tables
Any diagram or table taken directly from an AXELOS publication or other AXELOS source must always include
the following acknowledgement statement at the foot of the diagram/table:
“Copyright © AXELOS Limited 20?? Reproduced under licence from AXELOS”
Please replace the “20??” with the year of publication of the document from which the diagram/table is taken, for
example:
All diagrams in this slideset
are from Axelos (the core
literature). These are also
available as separate
slidesets on the EXIN
partnernet.
a) A small comment can be added after an insertion of AXELOS text.
E.g. This is the first process in PRINCE2. It is a pre-project process, designed to ensure that the prerequisites for initiating a project are
in place. The process expects the existence of a Project Mandate that defines in high-level terms the reason for the project and what
product is required.
(Source Managing Successful Projects with PRINCE2®2009 Edition)
b) A symbol, different colour/font and/or italics can be used to distinguish AXELOS text.
E.g. *This is the first process in PRINCE2.Itisapre-projectprocess, designed to ensure that the prerequisites for initiating a project are in place. The
process expects the existence of a Project Mandate that defines in high-level terms the reason for the project and what product is required.
(*Font denotes source Managing Successful Projects with PRINCE2®2009 Edition)
c) AXELOS text can be encapsulated within a text box.

E.g.
(Text encapsulated within a box denotes source Managing Successful Projects with PRINCE2® 2009 Edition
d) Quotation marks/inverted commas can be used around AXELOS text.

E.g.
“The risk indicator is the level of acceptability of a risk. Determining the risk indicator is a technique that can be used as part of the
risk planning process prior to the evaluation activity.”
Quoted text Source is Managing Successful Projects with PRINCE2®2009 Edition. Copyright © AXELOS Limited 2009. Material is reproduced
under licence from AXELOS.
ITIL Foundation - The training
ITILFND01
Service Management as a practice
Standards Employees
Industry practices Customers
Sources Academic research Suppliers Enablers

(generate) (aggregate)
Training and education Advisers
Internal experience Technologies
Substitutes Competition
Drivers Regulators Compliance Scenarios

(filter) (filter)
Customers Commitments
Knowledge fit for business

Objectives, context and purpose
Copyright © AXELOS Limited 2013. All rights reserved. Material is reproduced under licence from AXELOS
(SS book fig. 2.3)
Why is ITIL® successful?
Vendor-neutral
Non-prescriptive
Practice
ITIL is adopted by organizations to enable them to:

Deliver value for customers through services
Integrate the strategy for services with the business strategy and
customer needs
Measure, monitor and optimize IT services and service provider
performance
Manage the IT investment and budget
• Manage risk
• Manage knowledge
• Manage capabilities and resources
• Adopt a standard approach to service management
• Change the organizational culture
• Improve the interaction and relationship with customers
• Coordinate the delivery of goods and services
• Optimize and reduce costs

I must ask, do you I believe services are a means of delivering value by
have a definition facilitating outcomes customers want to achieve without the
for services? ownership of specific costs and risks.
What would that mean

in operational terms? Well, services facilitate outcomes by
Give me a few handles. having a positive effect on activities,
objects and tasks, to create conditions for
better performance. As a result, the
probability of desired outcomes is higher.
But without the ownership of costs and
risks? Customers cannot wish them
away.
No, they cannot, but what they can do is

Manager Manager let the provider take ownership. That’s
(Operations) (Strategy)
really why it is a service. If customers
Aha! Because the provider is specialized
manage it all by themselves, they
with capabilities for dealing with those
wouldn’t need a service, would they?
costs and risks.
Yes, and also because the customer would

rather specialize in those outcomes.
(A casual conversation
at the water cooler)
And also because the provider can
Let’s write a book on
potentially spread those costs and
service management!
risks across more than one customer.
(SS book fig. 2.1)
Internal customers
• Internal customers are people or departments who
work in the same organization as the service provider
External customers
• External customers are people who are not employed
by the organization, or organizations that are separate
legal entities, that purchase services from the service
provider in terms of a legally binding contract or
agreement
Services
• A Service is a means of delivering value to customers by facilitating outcomes

customers want to achieve without the ownership of specific costs and risks
Internal Services
• Delivered between departments or business units in the same organization
External Services
• Delivered to external customers
Differentiate between Services that support an internal activity, and Services that
achieve business outcomes.
IT Service Management
• The implementation and management of quality IT services that meet the

needs of the business
• Service management is a set of specialized organizational capabilities for
providing value to customers in the form of services
• IT service management is performed by IT service providers through a
mix of people, process and information technology
IT service provider
• A service provider that provides IT services to internal or external

customers
IT Service Management
• IT is a collection of systems, applications and infrastructures which are

components or sub-assemblies of a larger product
• IT is an organization with its own set of capabilities and resources
• IT is a category of services utilized by business
• IT is a category of business assets that provide a stream of benefits for

their owners, including, but not limited to, revenue, income and profit
Functions
• Self containing units of organizations specialized to perform certain types

of work and be responsible for specific outcomes
• Functions typically define roles and the associated authority and

responsibility for specific performance and outcomes
Process
• A set of coordinated activities combining and implementing resources and

capabilities in order to produce an outcome (specific objective), which,
directly or indirectly, creates value for an external customer or
stakeholder
• A process includes all of the roles, responsibilities, tools and management

controls required to reliably deliver the outputs
• Each process should be owned by a process owner, who should be

responsible for the process, the process improvement and for ensuring
that a process meets its objectives
Processes have the following characteristics:
• Processes are measurable
• They have specific results
• Processes have customers
• They respond to specific events
Process control can be defined as:
• The activity of planning and regulating a process, with the objective of

performing a process in an effective, efficient and consistent manner
Process control
Process policy
Process owner Process objectives
Triggers Process
Process feedback
documentation
Process
Process metrics
Process activities Process roles
Process Process Process Process

inputs procedures improvements outputs
Process work
Including process
instructions
Reports and reviews
Process enables
Process
Process resources
capabilities
(SS book fig. 2.5) Copyright © AXELOS Limited 2013. All rights reserved. Material is reproduced under licence from AXELOS
ITILFND02
The ITIL service lifecycle
Continual
service
improvement Service
transition
Service
strategy
Service Service
design Operation
SERVICE STRATEGY
Purpose of Service Strategy
• Understand what strategy is

• Definition of Services and Customers
• Define how value is created and delivered
• Identification of opportunities to provide Services
• Service provision model
• Understand organizational capabilities
• Use of Service Assets
• Strategy related processes
SERVICE STRATEGY
Scope of Service Strategy
• Definition of and discussion on the generic principles and processes of

service management
• Application of these generic principles consistently to the management of
IT services
Two aspects of strategy:

• Defining a strategy whereby a service provider will deliver services to
meet a customer’s business outcomes
• Defining a strategy for how to manage those services
SERVICE STRATEGY
Goals and objectives of Service Strategy
• Service providers must think and act in a strategic manner
• Service Strategy helps organizations to transform service management into

a strategic asset
SERVICE STRATEGY
Value to the business of Service Strategy
• Ability to link activities performed by the service provider to outcomes that are
critical to customers
• Understanding of what types and levels of service will make its customers
successful
• Respond quickly and effectively to changes in the business
• Support Service Portfolio creation and maintenance
• Facilitate communication about Services

SERVICE DESIGN
Purpose of Service Design

• Design IT services, together with the governing IT practices, processes
and policies
• Realize the service provider’s strategy
• Facilitate the introduction of these services into supported environments
• Ensure quality service delivery, customer satisfaction and cost-effective

service provision
SERVICE DESIGN
Objective of Service Design
• Design IT services so effectively that minimal improvement during their

lifecycle will be required
• Continual Service Improvement should be embedded in all Service

Design activities
SERVICE DESIGN
Scope of Service Design
• Design of appropriate and innovative IT services to meet agreed business

requirements
• Identify, define and align the IT solution with the business requirement
• Introduction of the Service Design Package
• Selection of the appropriate Service Design Model
• Driven by functional requirements, requirements within service level

agreements (SLAs), business benefits and the overall design constraints
SERVICE DESIGN
Value to the business of Service Design
• Reduced Total Cost of Ownership (TCO)

• Improved quality, performance and consistency of Services and processes
• Easier implementation of Services
• Improved Service alignment (customer focused)
• Improved IT governance
• Building controls into designs
• Improved information and decision-making
SERVICE TRANSITION
Objectives of Service Transition
• Plan and manage service changes efficiently and effectively
• Manage risks for new, changed or retired services
• Successfully deploy service releases
• Set correct expectations of services
• Ensure that service changes create the expected business value
• Provide good-quality knowledge and information

SERVICE TRANSITION
To achieve the objectives
• Plan and manage the capacity and resources required
• Implement a framework for evaluating service capabilities and risk profiles

before deployment
• Ensure integrity of service assets
• Provide mechanisms for building, testing and deploying services and releases
• Ensure that services can be managed, operated and supported

SERVICE TRANSITION
Scope of Service Transition
• Development and improvement of capabilities for transitioning new and

changed services into supported environments
• Release planning, building, testing, evaluation and deployment
• Service retirement
• Transfer of services between service providers

SERVICE TRANSITION
Value of Service Transition
• Assist organizations in delivering significant benefits
• Set up service transition and the processes that support it
• Make effective use of those processes to facilitate the effective transitioning

of new, changed or decommissioned services
SERVICE TRANSITION
Value of Service Transition
• Higher volumes of successful change
• Shared and re-use of Service Transition assets
• Reduce delays from unexpected clashes and dependencies
• Increase confidence for all stakeholders involved
• New or changed services will be maintainable and cost-effective
• Improve control of service assets and configurations

SERVICE OPERATION
Purpose of Service Operation
• Coordinate and run activities and processes required to deliver and manage
services at agreed levels to business users and customers
• Management of technology used to deliver and support services
• Monitor performance, assess metrics and gather operational data

SERVICE OPERATION
Objectives of Service Operation
• Maintain business satisfaction and confidence in IT
• Effective and efficient delivery and support of agreed IT services
• Minimize the impact of service outages on day-to-day business activities
• Ensure that access to agreed IT services is only provided to those authorized

to receive those services
SERVICE OPERATION
Scope of Service Operation
• Processes, functions, organization and tools used to underpin the ongoing

activities required to deliver and support services
• The services themselves
• Service management processes
• Technology
• People
SERVICE OPERATION
Value of Service Operation
• Reduce unplanned labour and costs
• Reduce the duration and frequency of service outages
• Provide operational results and data that can be used by other ITIL processes
to improve services continually
• Meet the goals and objectives of the organization’s security policy
• Provide quick and effective access to standard services
• Provide a basis for automated operations, thus increasing efficiencies

CONTINUAL SERVICE IMPROVEMENT
Purpose of Continual Service Improvement
• Align IT services to the changing business needs
• Identifying and implementing improvements to IT Services that support Business

Processes
• Measurement of current performance

• You cannot manage what you cannot control
• You cannot control what you cannot measure
• You cannot measure what you cannot define
Objectives of Continual Service Improvement
• Review, analyze and recommend improvements
• Review and analyze Service Level Achievements
• Identify and implement activities to improve IT Service quality and Improve cost
effectiveness
• Ensure customer satisfaction
• Ensure applicable quality management methods are used to support CSI activities
• Understand what to measure, why and what the successful outcome should be
Scope of Continual Service Improvement
• Provides guidance in four main areas:
• The overall health of ITSM
• Continual alignment of the service portfolio with the current and future
business needs
• Maturity and capability of the organization, management, processes and people

utilized by the services
• Continual improvement of all aspects of the IT service

Value to the business
• Lead to a gradual and continual improvement in service quality
• IT services aligned to business requirements
• Reduction in costs and/or the capability to handle more work at the same cost
• Identify opportunities for improvement in all lifecycle stages, capabilities, partners,

technology, staff skills, training, communications and processes
ITILFND03
Generic concepts and definitions
UTILITY
Performance supported?
T/F
OR
Constraints removed? Fit for
purpose?
AND Value Created

Available enough? T/F
Fit for use?
Capacity enough?
AND
Continuous enough? T/F T: True
F: False
Secure enough?
WARRANTY
Capabilities Resources
Management Financial capital
Organization Infrastructure
Processes Applications
Knowledge Information
People (experience, skills People (number

and relationships) of employees)
(SS book fig. 2.4)

Service portfolio
Service Retired
Service catalogue
pipeline services
Configuration management system
Supplier and contract Customer

Customer Application Project
management information agreement CMDB
portfolio portfolio portfolio
system portfolio
(SS book fig. 4.14)

The service catalogue
Business Business Business Business/customer

process 1 process 2 process 3 service catalogue view
Service A Service B Service C Service D Service E
Service 1 Service 2 Service 3 Service 4 Service 5 Service 6
Technical/supporting service catalogue view
Links to related
information
Service assets/configuration records
Key = Customer-facing services = Supporting services

(SD book fig. 4.4)
The service catalogue
Wholesale service catalogue view Retail service catalogue view
Wholesale Wholesale Retail Retail

customer 1 customer 2 customer 1 customer 2
Service A Service B Service C Service D Service E
Service 1 Service 2 Service 3 Service 4 Service 5 Service 6
Links to related
information
Service assets/configuration records
Key = Customer-facing services = Supporting services
(SD book fig. 4.5) Copyright © AXELOS Limited 2013. All rights reserved. Material is reproduced under licence from AXELOS
SERVICE STRATEGY
Service Portfolio Management
Governance
• Ensures that policies and strategy are actually implemented, and that required
processes are correctly followed
• Governance includes defining roles and responsibilities, measuring and

reporting, and taking actions to resolve any issues identified
• Comply with legislation and regulations
• Defines the common directions, policies and rules

Business impact Business Objectives
Lower costs
Tangible measure:
Service delivery costs
Target:
Lower service delivery costs by 30%
Improved maintainability Customer satisfaction
Tangible measure: Tangible measure:

MTRS (mean time to restore service) Repeat rate of business
Impact: Target:
MTRS to 2 hours from 6 hours Improve rate to 60% from 25%
Market image
Tangible measure:
Customer quality surveys
Target:
Improved industry ranking to 1st from 3rd
(SS book fig. 3.40)

SERVICE DESIGN
IT Service Continuity Management
Risk Management
• Identify the risks
• Name the risk
• What are the threats
• Document the risk with its possible consequences
• Analyse the risks

• Quantify the impact and probability
• Prioritize the risk
• Put measures in place to mitigate risks

• Repetitive activity to manage the action plans
SERVICE PROVIDER
There are three main types of service provider:
• Type I – internal service provider

• An internal service provider that is embedded within a business unit
• There may be several Type I service providers within an organization
• Type II – shared services unit

• An internal service provider that provides shared IT services to more than
one business unit
• Type III – external service provider

• A service provider that provides IT services to external customers
SERVICE DESIGN
Supplier Management
Supplier
• A Third Party responsible for supplying goods or Services that are required to
deliver IT services
• Examples of suppliers
• Commodity hardware and software vendors
• Network and telecom providers
• Outsourcing Organizations
SERVICE DESIGN
Service Level Management
SLA, OLA and UC
• SLA is a written agreement between an IT service provider and the IT

customer(s), defining the key service targets and responsibilities of both parties
• OLA is an agreement between an IT service provider and another part of the

same organization that supports provision of services
• An UC is a contract with external partners and suppliers, ensuring that all

targets and measures agreed in SLAs are supported by the third party
SERVICE DESIGN
Design Coordination
Service Design Package
• Document(s) defining all aspects of an IT Service and its Requirements

through each stage of its Lifecycle at the right cost, functionality, quality
and within the right time frame
• A Service Design Package is produced for each new IT Service, major

Change to an IT Service, or IT Service Retirement
Business
Customers Customers Customers
Service level agreements

availability (service availability %)
Service A Service B Service C

IT
IT systems
Operational level agreements

Reliability and maintainability (MTBF and MTRS)
Internal support teams
Contracts and agreements

Serviceability (availability, MTBF and MTRS)
Suppliers
(book fig. 4.8) Copyright © AXELOS Limited 2013. All rights reserved. Material is reproduced under licence from AXELOS
Service knowledge Support for decisions
management system
Support for delivery of services
Configuration management
database
(book fig. 4.36)

SKMS
The CMS is Some CIs (such as

part of the SLAs or release
SKMS plans) are in the
CMS SKMS
Configuration Each configuration

records are record points to and
stored in describes a CI
CMDBs in
the CMS
Other CIs (such as

users and servers)
are outside the
SKMS
Customer Service Service
options portfolio
Banking
Contract
core service
Serviced by
E-banking Supported by Hosted Application Uses Technical

support Application hosting infrastructure
service service service
Business Data Web Network Network

Availability Usability Messaging Authentication
logic services services topology service
(book fig. 4.7)

Service knowledge management system (SKMS)
Configuration management system (CMS)
Presentation layer
Knowledge processing layer
Information
integration
layer Integrated CMDB
Schema mapping, metadata management,

reconciliation, extract, transform, mining
Data layer
Incident records HR database
Service request records Customer database
Problem records Financial database
Known error records

CMDB with External databases
configuration records Change records (examples)
Release records
CMDB with
configuration records
Records in CMS or other
parts of the SKMS
CMDB with
configuration records
Discovery, collection, audit Other items in the SKMS
CMS
DML
CMDB
Information
about the CIs
Physical CIs
Release
record
Build new release
Electronic CIs
Test new release
Deploy new release
SERVICE TRANSITION
Change Management
Scope of Change Management
• Changes to all architectures, processes, tools, metrics and documentation, as

well as changes to IT services and other configuration items
• Changes to all configuration items across the whole service lifecycle
• Definition of a Change
• Addition, modification or removal of anything that could have an effect on IT
services
SERVICE TRANSITION
Change Management
Change types
• Standard Change
• A pre-authorized change that is low risk, relatively common and follows a
procedure or work instruction
• Emergency Change
• A change that must be implemented as soon as possible, for example to
resolve a major incident or implement a security patch
• Normal Change
• Any service change that is not a standard change or an emergency change
SERVICE OPERATION
Event Management
Event
• An event can be defined as any change of state that has significance for the
management of a configuration item (CI) or IT service
• Events are typically recognized through notifications created by an IT

service, CI or monitoring tool
• Informational Events
• Warning Events
• Exception Events
SERVICE OPERATION
Event Management
Alert
• If the event requires human intervention, it will need to be escalated
• The purpose of the alert is to ensure that the person with the skills
appropriate to deal with the event is notified
• The alert will contain all the information necessary for that person to
determine the appropriate action
• Including reference to any documentation required
SERVICE OPERATION
Incident Management
Basic concepts of Incident Management
• An ‘incident’ is an unplanned interruption to an IT service or reduction in the

quality of an IT service
• Failure of a configuration item that has not yet impacted service is also
an incident (failure in a disk mirror set)
• Timescales
• Timescales agreed for all incident-handling stages
• Depending upon the priority level of the incident and Incident response
and resolution targets within SLAs
SERVICE OPERATION
Incident Management
Incident prioritization
Priority is a ranking order:
• Based on the urgency of the incident …

• (how quickly the business needs a resolution)
• … and the impact it is causing
• (number of users being affected, and impact of loss of service)
• (Services affected, financial loss, Regulatory/legislative breaches)
Priority Urgency
High Medium Low
Impact High 1 2 3
Medium 2 3 4
Low 3 4 5
SERVICE OPERATION
Request Fullfilment
Service Request
• Generic description for many varying types of demands that are placed
upon the IT organization by the users:
• Small changes with low risk, frequently occurring, low cost, etc.
• A request to change a password
• A request to install an additional software application
• A request to relocate some items of desktop equipment
• A question requesting information
SERVICE OPERATION
Problem Management
Definitions
• Problem
• Unknown, underlying cause of one or more incidents
• Proactive analyzed trends in incident records or trends reported by
tools
• Workaround
• Temporary way (solution ) of overcoming the difficulties
• Sometimes with a degraded level of service
• Work on a permanent resolution continues
SERVICE OPERATION
Problem Management
Known Error
• Underlying cause is found after successful diagnosis
• Possibly a workaround has been found
• Known Error Record in the Known Error Database
Known Error Data Base (KEDB)

• Storage of previous knowledge of incidents and problems
• Allow quicker diagnosis and resolution
• The Known Error Record should hold exact details of the fault,
symptoms, any workaround or resolution action
SERVICE OPERATION
Problem Management
Invoke problem management during an incident

• Incident management cannot match an incident
• Trend analysis of incidents reveals an underlying problem might exist
• A major incident has occurred
• Other IT functions identify a problem condition
• The service desk may have resolved an incident but has not determined a
definitive cause
• Analysis of an incident by a support group reveals an underlying problem
• A notification from a supplier that a problem exists
SERVICE OPERATION
Communication within Service Operation
Communication in Service Operation
• Routine operational communication

• Communication between shifts
• Performance reporting
• Communication in projects
• Communication related to changes, exceptions and emergencies
• Training on new or customized processes and service designs
• Communication of strategy and design to Service Operation teams
SERVICE TRANSITION
Release & Deployment Management
Release Policy
• The unique identification, numbering and naming conventions

• The roles and responsibilities
• Only use software assets from the DML
• The expected frequency for each type of release
• The approach for grouping changes into a release
• The mechanism to automate the build, installation and release distribution
• Capturing configuration baseline for the release
• Exit and entry criteria and authority
• Criteria and authorization to exit early life support and handover to the service
operation functions
SERVICE
Types of IT service
Type of service Definition Description
Supporting service A service that is not directly used Supporting services are defined to
by the business, but is required by allow IT teams to identify the
the IT service provider so they can interdependencies between IT
provide other IT services components
Internal customer- An IT service that directly supports An internal customer-facing service

facing service a business process managed by is identified and defined by the
another business unit business
External customer- An IT service that is directly An external customer-facing service

facing service provided by IT to an external is available to external customers
customer and is offered to meet business
objectives defined in the
organization’s strategy
(Table 3.4 Types of IT Service,

ITIL® Service Strategy, 2011 Edition, Page 52)
SERVICE TRANSITION
Change Management
Change Proposals
• Normally created by the service portfolio management process, passed to

change management for authorization
• Includes
• High-level description of the new, changed or retired service, including
business outcomes to be supported, and utility and warranty to be
provided
• Full business case including risks, issues and alternatives, as well as
budget and financial expectations
• Outline schedule for change design and implementation
CSI Register
Record all the improvement opportunities
• Categorized (small, medium, large)
• Important information for the overall service provider
• Held and regarded as part of the Service Knowledge Management System

(SKMS)
• Ensure all initiatives are captured and recorded, and benefits realized
• Coordinated, consistent view of the potentially many improvement activities

I must ask, do you I believe services are a means of delivering value by
have a definition facilitating outcomes customers want to achieve without the
for services? ownership of specific costs and risks.
What would that mean

in operational terms? Well, services facilitate outcomes by
Give me a few handles. having a positive effect on activities,
objects and tasks, to create conditions for
better performance. As a result, the
probability of desired outcomes is higher.
But without the ownership of costs and
risks? Customers cannot wish them
away.
No, they cannot, but what they can do is

Manager Manager let the provider take ownership. That’s
(Operations) (Strategy)
really why it is a service. If customers
Aha! Because the provider is specialized
manage it all by themselves, they
with capabilities for dealing with those
wouldn’t need a service, would they?
costs and risks.
Yes, and also because the customer would

rather specialize in those outcomes.
(A casual conversation
at the water cooler)
And also because the provider can
Let’s write a book on
potentially spread those costs and
service management!
risks across more than one customer.
Example A: Example B:
Greeting card Consulting
company company
110 550
100 500
90 450
Number of timesheet transactions

80 400
Number of cards sold

70 350
(in millions)
60 300
50 250
40 200
30 150
20 100
10 50
J F M A M J J A S O N D M T W T F
Time (months) Time (days)
Example C:
Newspaper Each chart shows patterns of business activity (PBA). Each
activity relies on IT services and each places a demand on
100
the IT service provider’s assets.
90
Example A – annual PBA: Greeting cards need to be
80 designed, manufactured and distributed for each major
holiday. The fluctuation in sales will result in a fluctuation in
70 demand for IT services.
Number of cards sold
60 Example B – weekly PBA: Consultants need access to a

(in millions)
timesheet system to track their activities so that customers

50
can be billed. Most consultants wait until the end of the week
40 to complete their timesheets. Some consultants record their
activities daily.
30
Example C – daily PBA: Journalists have to meet the
20 deadline of 6pm to submit their stories for publication. After
the deadline, only high-impact corrections are made. The
10 later in the day, the more critical the IT services become, and
also the more utilized. Most journalists use the lunch hour to
interview people for stories.
(SS book fig. 4.40)

9 10 11 12 1 2 3 4 5 6 7 8
Time (months)
CUSTOMERS, USERS, SUPPLIERS
Customers
• Those who buy goods or services
• Person or group who defines and agrees the service level targets
Users
• Those who use the service on a day-to-day basis
Suppliers
• Third parties responsible for supplying goods or services that are required to
deliver IT services
Continual quality control and consolidation
Plan Project Plan

Do Project
Check Audit
Act New actions
ACT PLAN
Business
Maturity level
IT
alignment
CHECK DO
Effective quality
improvement
Consolidation of the level reached
i.e. baseline
Timescale
ITILFND04
Key principles and models
Business
outcomes
Value
Preferences Perceptions
(SS book fig. 3.6)

Positive Negative
difference difference
Losses from
_ utilizing the
service
Net
difference
Gains from
utilizing the +
service
Based on DIY strategy or

existing arrangements
Reference Economic value

value of service
(SS book fig. 3.7)

People
Products/
Processes technology
Partners/
suppliers
(SD book fig. 3.3)
SERVICE DESIGN
Five major aspects of Service Design
• Design of:
• Service solutions for new or changed Services
• Management information systems and tools
• Service Portfolio including Service Catalogue
• Technology architectures and Management architectures
• Processes required
• Measurement methods and Metrics
Business vision,
What is the vision? mission, goals and
objectives
Baseline
Where are we now? assessments
How do we keep the Where do we want Measurable

momentum going? to be? targets
Service and process

How do we get there?
improvement
Measurements and
Did we get there?
metrics
(CSI book fig. 3.1) Copyright © AXELOS Limited 2013. All rights reserved. Material is reproduced under licence from AXELOS
Vision
Mission
Goals
Objectives
CSF
KPI
Metrics
Measurements
(CSI book fig. 5.7)
Continual Service Improvement
Critical success factors and key performance indicators
• Each organization should identify appropriate CSFs based on its objectives for
the process
• KPIs support the CSFs
• Achievement against KPIs should be monitored and used to identify

opportunities for improvement
• Logged in the CSI register for evaluation and possible implementation
Baselines
• Starting points for later comparison
• Initial data point to determine if a service or process needs to be improved
• Ensure baselines are documented, recognized and accepted throughout the

organization
• Baselines must be established at each level
• Strategic goals and objectives
• Tactical process maturity
• Operational metrics and KPIs
Types of Metrics
Technology metrics
• Component and application-based metrics
• Performance, availability etc.
Process metrics
• Process CSFs, KPIs and activity metrics
• Quality, performance, value and compliance KPIs
Service metrics
• End-to-end service performance
• Component metrics used to compute service metrics
ITILFND05
Processes
Service portfolio
Service Retired
Service catalogue
pipeline services
Supplier and contract Customer

Customer Application Project
management information agreement CMDB
portfolio portfolio portfolio
system portfolio
(SS book fig. 4.14)

Business impact Business Objectives
Lower costs
Tangible measure:
Service delivery costs
Target:
Lower service delivery costs by 30%
Improved maintainability Customer satisfaction
Tangible measure: Tangible measure:

MTRS (mean time to restore service) Repeat rate of business
Impact: Target:
MTRS to 2 hours from 6 hours Improve rate to 60% from 25%
Market image
Tangible measure:
Customer quality surveys
Target:
Improved industry ranking to 1st from 3rd
(SS book fig. 3.40)

Service Strategy
Business Relationship Management
Purpose of BRM
• Establish and maintain a business relationship between the
service provider and the customer
• Understand the customer and its business needs
• Identify customer needs and ensure that the service provider is
able to meet these needs
Service Strategy
Objectives of BRM
• Ensure that the service provider understands the customer’s perspective
of service
• Ensure high levels of customer satisfaction
• Establish and maintain a constructive relationship between the service
provider and the customer
• Understand the customer and their business drivers
• Identify changes to the customer environment that could potentially
impact services
…
Service Strategy
Objectives of BRM
• Identify technology trends that could potentially impact services
• Establish and articulate business requirements
• Ensure that the service provider is meeting the business needs of the
customer
• Work with customers to ensure that services and service levels are
able to deliver value
• Mediate in cases of conflicting requirements
• Establish formal complaints and escalation processes
Service Strategy
Scope of BRM
• For internal service providers executed between a
senior representative from IT and senior managers
(customers) from the business units
• In external service providers often executed by a
separate and dedicated function of BRMs or account
managers – each one dedicated to a customer, or group
of customers
Service-specific level SLA
Customer level SLA or

business unit level SLA
Corporate level SLA
(SD book fig.4.7)

Business requirements
Early life Live
support period operation
Design and development

Project (project team)
SAC SAC
SAC SAC SAC SAC SAC
Document and Design Develop Build Test Deploy

agree business service service service service service
requirements solution solution solution solution solution
(strategy and design) (design) (design) (transition) (transition) (transition)
Strategy
Design Improvement
Transition
Transition and operation involvement Operation
Pilot Live
SLM SLR SLR SLR SLR SLR SLR
SLA SLA
Change management
RFC Authorized for Authorized for Authorized for Authorized for Authorized for Authorized for Review and
released design development build and test deployment SLA pilot acceptance close
Release and deployment management
Plan and prepare Build and test Deploy and verify release Review and
release release (incl. early life support) close
(SD book fig.3.8)

January Febuary March April May June July August
Target Target Target

met breached threatened
(CSI book fig.4.4)

Service Design
Service Catalogue Management
Purpose of Service Catalogue Management

• Provide and maintain a single source of consistent
information on all operational services and those being
prepared to be run operational
• Ensure that the Service Catalogue is widely available to
those who are authorized to access it
Service Design
Objectives of Service Catalogue Management

• Manage the information in the Service Catalogue
• Ensure that the Service Catalogue is accurate showing
details, status, interfaces, dependencies
• Ensure that the service catalogue is made available to
those approved to access
• Ensure that the service catalogue is made available to
all other service management processes for service
catalogue information
Service Design
Scope of Service Catalogue Management

• Contribution to the definition, development and
maintenance of Services and Service Packages
• Production and maintenance of an accurate Service
Catalogue
• Interfaces, dependencies and consistency between the
Service Catalogue and the overall Service Portfolio
Service Design
• Interfaces and dependencies between all Services,

supporting Services and supporting components and
Configuration Items (CIs) within the Service Catalogue
and the CMS
• Excluded:
• Capturing, maintenance and use of service asset and
configuration data (SA & Configuration
Management)
• Capturing, maintenance and fulfilment of service
requests (Request Fulfilment)
Business
Customers Customers Customers
Service level agreements

availability (service availability %)
Service A Service B Service C

IT
IT systems
Operational level agreements

Reliability and maintainability (MTBF and MTRS)
Internal support teams
Contracts and agreements

Serviceability (availability, MTBF and MTRS)
Suppliers
(SD book fig.4.8)

Service Design
Information Security Management
Purpose of Information Security Management

• Align IT security with business security and ensure that
the Confidentiality, Integrity and Availability of the
organization’s assets, information, data and IT services
always matches the agreed needs of the business
Service Design
Objectives of Information Security Management

• Information is available and usable when required (availability)
• Information is only available for those who have a right to know (confidentiality)
• Information is complete, accurate and protected against unauthorized
modification (integrity)
• Business transactions, and information exchanges between enterprises, or
partners, can be trusted (authenticity and non-repudiation)
Service Design
Scope of Information Security Management

• Information Security Management needs to understand the
total IT and business security environment
• Business security policy and plans
• Current business operation and its security
requirements
• Future business plans and requirements
• Legislative and regulatory requirements
• Security obligations and responsibilities within SLAs
• The business and IT risks and their management
Service provider
Supplier management Finance and

process owner purchasing
Contracts
manager
Legal
Supplier Supplier Supplier Supplier

manager 1 manager 2 manager 3 manager 4
Service Service Service Service Service Service
Supplier 6
Supplier 5
Supplier 4
Supplier 3
Supplier 2
Supplier 1 Sub-contracted
supplier 2
Sub-contracted
supplier 1
(SD book fig.4.26)

Strategic
High suppliers
Operational
Value and importance

suppliers
Medium Tactical
suppliers
Commodity Operational
Low suppliers
suppliers
Low Medium High
Risk and impact
(SD book fig.4.28)

Business capacity
Strategic
management
Storage of capacity
management data
Service capacity
management
activities
Iterative
Tactical
Demand
management
Modelling
Application
sizing
Component capacity
management Operational
Capacity
management
sub-processes Production of the capacity plan
Reports on all aspects of CMIS

capacity management
(SD book fig.4.16)

Critical
Focus on risk reduction
High
Impact
Balanced
continuity
approach
Medium
Focus on recovery
Low
1 week 2 weeks 3 weeks 4 weeks 5 weeks

Time
(SD book fig.4.22)

Assets Threats Vulnerabilities
Risk
assessment
Risks
Countermeasures
Risk
management
(SD book fig.4.15)

Service Design
Design Coordination
Purpose of Design Coordination

• Ensure the goals and objectives of the service design
stage are met by providing and maintaining a single
point of coordination and control for all activities and
processes within this stage
Service Design
Design Coordination
Objectives of Design Coordination

• Ensure the consistent design of appropriate
• Services
• Service management information systems
• Architectures
• Technology
• Processes
• Information
• Metrics
• Coordinate all design activities
Service Design
Design Coordination
• Plan/coordinate required resources/capabilities

• Produce Service Design Packages (SDPs)
• Ensure service designs/ SDPs are produced
• Manage quality criteria, requirements and handover
points
• Ensure that all service models and service solution
designs conform to the requirements
• Improve the effectiveness and efficiency
• Adopt a standard, reusable design framework
• Monitor and improve SD performance
Service Design
Design Coordination
Scope of Design Coordination

• All design activity, particularly all new or changed
service solutions that are being designed for transition
into (or out of, in the case of a service retirement) the
live environment
• Some design efforts will be part of a project, whereas
others will be managed through the change process
Business Service provider Supplier
Manage the
Strategic Manage the
Manage IT services supplier’s
change business
business
Manage the Service Manage

Tactical
business portfolio external
change
processes services
Service
change
Manage
Operational business Service External
change operations operations operations
(ST book fig.4.1)

Change management
Raise and Assess Authorize/ Coordinate Review Close
record change change reject change change change
request change implementation*
Release and deploy

new/changed CIs
Service asset and configuration management

Capture
Reports Update release and Audit Check
Identify records
and audits affected items records environment items
baselines updated
* Includes build and test where applicable
(ST book fig.4.6)

Role
Create RFC
Change
initiator
Record RFC
Change
Change management
proposal Requested
(optional)
Review RFC
Change
management
Ready for evaluation
Activities assigned to the
role ‘change management’ Assess and
may be carried out by a evaluate change
change practitioner, a Change
change authority or the management
Ready for decision Work flows
change management process
owner, depending on Rejected Authorize change
Update information in CMS

organizational design build and test
Change
authority
Authorized
Rejected Coordinate change
Change build and test*
*Activities to plan, create management
and deploy releases are
part of the release and Created Work flows
deployment management Authorize change
process deployment
Change
authority
Scheduled
Coordinate change
deployment*
Change
management Implemented Work flows
Review and close

change record
Change
management, Closed
change authority,
change initiator
(ST book fig.4.2) Copyright © AXELOS Limited 2013. All rights reserved. Material is reproduced under licence from AXELOS
Change management
Auth Auth Auth Auth

Auth
Auth
Auth
Authorize Post-
Authorize Authorize Authorize
deployment/ Implementation
release planning build and test ceck-in to DML
transfer/retirement review
Release and Release

Review and
deployment build and Deployment
close
planning test
Deployment
Deployment
Change management authorization Deployment

Auth
ST slide 36 (book fig 4.23)

Context
Wisdom
Why?
Knowledge
How?
Information
Who, what,
When, where?
Data
Understanding

Service knowledge Support for decisions
management system
Support for delivery of services
Configuration management
database

Service Transition
Service Asset & Configuration Management
Purpose of SA&CM
• Ensure that the assets required to deliver services are
properly controlled
• Ensure that accurate and reliable information about
those assets is available when and where it is needed
• This includes details of how the assets have been
configured and the relationships between assets
Service Transition
Objectives of SA&CM
• Assets under the control of the IT organization are
identified and controlled
• Identify, control, record, report, audit and verify services
and other configuration items (CIs), including versions,
baselines, constituent components, their attributes and
relationships
• Account for, manage and protect the integrity of CIs
and configurations
Service Transition
• Establishing and maintaining an accurate and complete

configuration management system (CMS)
• Maintain accurate configuration information on the
historical, planned and current state of services and
other CIs
• Support efficient and effective service management
processes by providing accurate configuration
information
Service Transition
Scope of SA&CM
• Service assets that need to be managed in order to
deliver services are known as configuration items (CIs)
• Every CI is a service asset, but many service assets
are not CIs (Capabilities)
• The scope of SACM includes management of the
complete lifecycle of every CI
• The scope includes interfaces to internal and external
service providers
Service Transition
Transition Planning and Support
Purpose of Transition Planning and Support

• Provide overall planning for service transitions and to
coordinate the resources that they require
Service Transition
Objectives of Transition Planning and Support

• Plan and coordinate the resources
• Coordinate activities across projects, suppliers and
service teams
• Establish new or changed services into supported
environments
• Establish management information systems and tools,
technology and management architectures, service
management processes, and measurement methods and
metrics
Service Transition
• Ensure that all parties adopt the common framework of

standard re-usable processes and supporting systems
• Provide clear and comprehensive plans
• Identify, manage and control risks, to minimize the
chance of failure and disruption across transition
activities
• Monitor and improve the performance of the service
transition lifecycle stage
Service Transition
Scope of Transition Planning and Support

• Maintaining policies, standards and models
• Guiding each major change or new service through all
the service transition processes
• Coordinating the efforts needed to enable multiple
transitions
• Prioritizing conflicting requirements for service
transition resources
• Planning the budget and resources
Event
Web interface Phone Call Email
management
Incident
identification
To request fulfilment
(if this is a service
request) or service
Is this really portfolio management
No
an incident? (if this is a change
proposal)
Yes
Incident logging
Incident
categorization
Incident
prioritization
Major incident
Yes Major incident
procedure
No
Initial diagnosis
Functional Functional Escalation

Yes Yes
escalation escalation Needed?
No
No
No
Management Hierarchic Investigation

Yes No
escalation escalation And diagnosis
Resolution
identified?
Yes
Resolution and
recovery
Incident closure
SO slide 22 (book fig 4.3) End Copyright © AXELOS Limited 2013. All rights reserved. Material is reproduced under licence from AXELOS
Location Application
impacted impacted
Service Database
impacted impacted
OR Server
System
impacted impacted
Application Disk drive

impacted impacted
SO slide 23 (book fig 4.4)

Incident-matching
procedure (part of
initial diagnosis)
Update incident count

Extract resolution or Match on on problem record
Yes
workaround action from known error
known error database database?
Update incident count No Update incident record

on known error record with ID of problem
Match to Yes
existing problem
record?
Update incident record Update incident record
with ID of known error with classification data
No
Routine Yes
Update incident record incident?
with classification data
No
Inform customer of Log new

workaround problem
Return to
initial diagnosis
Proactive
Service Event Incident
Problem Email
desk management management
management
Problem
detection
Problem
logging
Problem
categorization
Problem
prioritization
Problem
CMS investigation
and diagnosis
Incident Implement Workaround

workaround Yes
management needed?
No
Raise known Known

error record Error
if required database
Change RFC Change

Yes
management needed?
No
Problem
resolution
No Resolved?
Yes
• Lessons learned
Problem • Review results
closure
Service
knowledge
management
system
Major Major problem

Yes
Problem? review
No Continual
Service

improvement
End
• Improvement actions
• Communications
Service Operation
Event Management
Purpose of Event Management

• Manage events throughout their lifecycle
• Activities to detect events, make sense of them and
determine the appropriate control action
• Basis for operational monitoring and control
• Automate many routine operations management
activities
Service Operation
Event Management
Objectives of Event Management

• Detect all changes of state that have significance for the
management of a CI or IT service
• Determine the appropriate control action
• Provide the trigger for the execution of many service
operation processes and activities
• Provides a way of comparing actual performance and
behaviour against design standards and SLAs
• Provide a basis for service assurance and reporting
Service Operation
Event Management
Scope of Event Management

• Any aspect of service management that needs to be
controlled and which can be automated
• Configuration items (CIs)
• Environmental conditions
• Software licence monitoring
• Normal activity
Service Operation
Request Fulfillment
Purpose of Request Fulfillment

• Request fulfilment is the process responsible for
managing the lifecycle of all service requests from the
users
Service Operation
Request Fulfillment
Objectives of Request Fulfillment

• Maintain user and customer satisfaction through efficient and
professional handling of all service requests
• Provide a channel for users to request and receive standard
services for which a pre-defined approval and qualification
process exists
• Provide information to users and customers about the availability
of services and the procedure for obtaining them
• Source and deliver the components of requested standard
services (e.g. licences and software media)
• Assist with general information, complaints or comments
Service Operation
Request Fulfillment
Scope of Request Fulfillment

• The process needed to fulfil a request will vary
depending upon exactly what is being requested, but
can usually be broken down into a set of activities that
have to be performed
• For each request, these activities should be
documented into a request model and stored in the
SKMS
• Service Requests can be handled as a particular type of
‘incident’
Service Operation
Access Management
Purpose of Access Management

• Provide the right for users to be able to use a service
or group of services
• Execution of policies and actions defined in Information
Security Management
Service Operation
Access Management
Objectives of Access Management

• Manage access to services based on policies and actions
defined in information security management
• Efficiently respond to requests for
• Granting access to services
• Changing access rights
• Restricting access
• Oversee access to services and ensure rights being
provided are not improperly used
Service Operation
Access Management
Scope of Access Management

• Execution of the policies in information security
management
• Manage the confidentiality, availability and integrity of the
organization’s data and intellectual property
• Users are given the right to use a service
• Executed by all technical and application management
functions
• Can be initiated by a service request
Wisdom 1.Identify the strategy for 2. Define what you will Data
improvement measure
• Vision
• Business need
• Strategy
• Tactical goals
• Operational goals
PLAN
7. Implement improvement 3. Gather the data
• Who? How? When?
• Criteria to evaluateintegrity
of data
• Operational goals
• Service measurement
ACT DO
6. Present and use the

information
• Assessment summary
• Action plans
• Etc.
CHECK
5. Analyse the information 4. Process the data

and data • Frequency?
• Trends? • Format?
• Targets? • Tools and systems?
• Improvements required? • Accuracy?
Knowledge Information
CSI slide 16 (book fig. 3.4)

Operational management Step 1 Step 2
PLAN
Step 7 Step 3
ACT DO
Step 4
CHECK
Step 6 Step 5
Step 1 Step 2
PLAN
Step 7 Step 3
ACT DO
Step 4
CHECK
Step 6 Step 5
Tacticle management
Step 1 Step 2
PLAN
Step 7 Step 3
ACT DO
Step 4
CHECK
Step 6 Step 5
Strategic management
CSI slide 17 (book fig. 3.5)

ITILFND06
Functions
User User User User
Customer Site
Service Desk
Technical Application IT operations Third-party Request

management management management support fulfilment
SO slide 34 (book fig 6.2) )

User User User User User User User User User User User User
Customer site 1 Customer site 2 Customer site 3
Service desk
Technical Application IT operations Third-party Request

management management management support fulfilment

San Francisco
service desk
Paris Rio de
service desk Janeiro
service desk
Virtual
Service desk
Beijing Sydney
service desk service desk
Service
Knowledge
Management
system
London
service desk

Service Operation
Technical Management
Role of Technical Management

• The custodian of technical knowledge and expertise related to
managing the IT Infrastructure
• Knowledge required to design, test, manage and improve IT
services is identified, developed and refined
• Provides the actual resources to support the ITSM Lifecycle
• Resources are effectively trained and deployed
• Organization has access to the right type and level of human
resources
• Ensure a balance between the skill level, utilization and the cost
of these resources
Service Operation
Technical Management
Objectives of Technical Management

• Assist to plan, implement and maintain a stable technical
infrastructure to support the organization’s business
processes
• Technical topology is well designed, highly resilient and
cost-effective
• Adequate technical skills to maintain the technical
infrastructure are used
• Technical skills are used to diagnose and resolve any
technical failures quickly
Service Operation
Application Management
Objectives of Application Management

• Support the organization’s business processes by identifying
functional and manageable requirements for application software
• Assist in the design and deployment of those applications and the
ongoing support and improvement
• These objectives are achieved through:
• Well designed, resilient and cost-effective applications
• Availability of required functionality
• Optimal technical skills
• Diagnose and resolve any technical failures
Service Operation
Application development versus application management

Application development Application management
Nature of activities One-time set of activities to design and Ongoing set of activities to oversee and
construct application solutions. manage applications throughout their
entire lifecycle
Scope of activities Performed mostly for applications Performed for all applications,
developed in house. purchased from third parties or
developed in house
Primary focus Utility focus. Utility and Warranty focus
Building functionality for their customer. What the functionality is as well as how
What the application does is more to deliver it
important than how it is operated. Manageability aspects of the
application, stability and performance of
the application.
(Table 6.2 Application Development versus Application Management, Copyright © AXELOS Limited 2013. All rights reserved
ITIL® Service Operation, 2011 Edition, Page 187) Material is reproduced under licence from AXELOS
Service Operation
Management mode Most development work is done in Most work is done as part of repeatable,
projects where the focus is on delivering ongoing processes.
specific units of work to specification, on A relatively small number of people
time and within budget. work in projects.
Difficult for developers to understand and Difficult for operational staff to get
build for ongoing operations (not involved in development projects (takes
available for support of the application them away from their ongoing
once they have moved on to the next operational responsibilities).
project).
Measurement Staff are typically rewarded for creativity Staff are typically rewarded for
and for completing one project so that consistency and for preventing
they can move on to the next project. unexpected events and unauthorized
functionality.
Service Operation
Cost Development projects are relatively easy Ongoing management costs are often
to quantify because the resources are mixed in with the costs of other IT
known and it is easy to link their services because resources are often
expenses to a specific application or IT shared across multiple IT services and
service. applications.
Lifecycles Development staff focus on software Staff involved in ongoing management
development lifecycles, which highlight typically only control one or two stages
the dependencies for successful of these lifecycles – operation and
operation, but do not assign improvement.
accountability for these.
Service Operation
IT Operation Management
Objectives of IT Operations Management

• Maintenance of the status quo to achieve stability of the
organization’s day-to-day processes and activities
• Regular investigations and improvements to improve
service, reduce costs, and maintain stability
• Swift application of operational skills to diagnose and
resolve any IT operations failures
Service Operation
IT Operation Management
Role of IT Operation Management

• Execute the ongoing activities and procedures
• Manage and maintain the IT Infrastructure
• Deliver and support IT Services at the agreed levels
• Operations Control
• Facilities Management
ITILFND07
Roles
Roles
• The Service Owner is accountable for the delivery of a specific IT service

• The Process Owner role is accountable for ensuring that a process is fit for purpose
• The Process Manager role is accountable for operational management of a process
• The Process Practitioner is responsible for carrying out one or more process
activities
Responsibilities
RACI Model
• When designing a service or a process, all the roles should be clearly defined
• RACI model is beneficial when decisions have to be made
• Responsible
• Person or people responsible for getting the job done
• Accountable
• only one person can be accountable for each task
• Consulted
• people who are consulted and whose opinions are sought
• Informed
• people who are kept up-to-date on progress
ITILFND08
Technology and architecture
Level of degradation
in service quality
Unacceptable
High
Low
Amount of variation
in service process
SS slide 130 (book fig. 7.2)

Context
Wisdom
Why?
Knowledge
How?
Information
Who, what,
When, where?
Data
Understanding
SS slide 131 (book fig. 7.3)


EXIN Basic Training Material ITIL

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

EXIN Basic Training Material ITIL

Uploaded by

Copyright:

Available Formats

Basic Training Material for ITIL® Foundation

Issue: December 2015

• A good training will always require extra examples, practice, elaborating

For course participants:

IT Infrastructure Library® is a Registered Trade Mark of AXELOS Limited.

c) AXELOS text can be encapsulated within a text box.

d) Quotation marks/inverted commas can be used around AXELOS text.

Industry practices Customers

Sources Academic research Suppliers Enablers

Training and education Advisers

Internal experience Technologies

Drivers Regulators Compliance Scenarios

Knowledge fit for business

ITIL is adopted by organizations to enable them to:

• Manage capabilities and resources

• Adopt a standard approach to service management

• Change the organizational culture

• Improve the interaction and relationship with customers

• Coordinate the delivery of goods and services

• Optimize and reduce costs

What would that mean

No, they cannot, but what they can do is

Yes, and also because the customer would

• A Service is a means of delivering value to customers by facilitating outcomes

• The implementation and management of quality IT services that meet the

• A service provider that provides IT services to internal or external

• IT is a collection of systems, applications and infrastructures which are

• IT is an organization with its own set of capabilities and resources

• IT is a category of services utilized by business

• IT is a category of business assets that provide a stream of benefits for

• Self containing units of organizations specialized to perform certain types

• Functions typically define roles and the associated authority and

• A set of coordinated activities combining and implementing resources and

• A process includes all of the roles, responsibilities, tools and management

• Each process should be owned by a process owner, who should be

Process control can be defined as:

• The activity of planning and regulating a process, with the objective of

Process Process Process Process

Purpose of Service Strategy

• Understand what strategy is

• Definition of and discussion on the generic principles and processes of

Two aspects of strategy:

Goals and objectives of Service Strategy

• Service providers must think and act in a strategic manner

• Service Strategy helps organizations to transform service management into

• Respond quickly and effectively to changes in the business

• Support Service Portfolio creation and maintenance

• Facilitate communication about Services

Purpose of Service Design

• Realize the service provider’s strategy

• Facilitate the introduction of these services into supported environments

• Ensure quality service delivery, customer satisfaction and cost-effective

Objective of Service Design

• Design IT services so effectively that minimal improvement during their

• Continual Service Improvement should be embedded in all Service

Scope of Service Design

• Design of appropriate and innovative IT services to meet agreed business

• Introduction of the Service Design Package

• Selection of the appropriate Service Design Model

• Driven by functional requirements, requirements within service level

Value to the business of Service Design

• Reduced Total Cost of Ownership (TCO)

• Plan and manage service changes efficiently and effectively

• Manage risks for new, changed or retired services