Transcript ITILv3 Introduction and Overview

LECTURE 3



SERVICE Transition
SERVICE Operation
Continual SERVICE Improvement
Stage 3 – Service Transition
 Build
 Testing
 User acceptance
 Deployment
 Bed-in
Good service transition
 Set customer expectations
 Enable release integration
 Reduce performance variation
 Document and reduce known
errors
 Minimise risk
 Ensure proper use of services
S. Transition at a glance
Knowledge management
 Vital to enabling the right information to
be provided at the right place and the
right time to the right person to enable
informed decision
 Stops data being locked away with
individuals
 Obvious organisational advantage
Data ► Information ►
Knowledge ► Wisdom
Data
Information
- who, what , where?
Knowledge
- How?
Wisdom
- Why?
Wisdom cannot be assisted by technology
– it only comes with experience!
Service Knowledge Information
Management System is crucial to retaining
this extremely valuable information
Service Asset and
Configuration
 Managing these properly is key
 Provides Logical Model of Infrastructure
and Accurate Configuration information
 Controls assets
 Minimises costs
 Enables proper change and release
management
 Speeds incident and problem resolution
Configuration
Management System
Service
Management
KB
Asset and
Configuration
Info
Change Data
Release
Data
Application
Data
Document
Definitive
Media
Library
Configuration
Management
DB
Painting the Forth
Bridge ...
 A Baseline is a “last known good
configuration”
 The CMS will always be a “work in
progress” and probably always out of
date. But still worth having
 Current configuration will always be the
most recent baseline plus any
implemented approved changes
... just Some parts of a theoretical CMDB
HARDWARE
Specification
Location
Owner
SOFTWARE
Licenses
Versions
Financials
USERS
INCIDENTS
CHANGES
Applications
Applications
Applications
Contracts
Hardware
Users
Incidents
Resolutions
Equipment
KNOWN
ERRORS
RELEASES
Software
APPLICATIONS
O/S
Equipment
Users
SLA
Applications
Hardware
Users
Contracts
Applications
Incidents
INFRASTRUCTURE
SOFTWARE
e.g. Oracle
SERVICES
AVAILABILITY
Applications
STATISTICS
PROBLEMS
BCP
Incidents
DOCS
Resolutions
NETWORK
Linkages
Dependencies
DEFINITIVE SOFTWARE LIBRARY
DEFINITIVE HARDWARE STORE
Change Management
 Respond to customers changing
business requirements
 Respond to business and IT requests
for change that will align the services
with the business needs & with the IT
state of the art
 Roles
 Change Manager
 Change Authority
 Change Advisory Board (CAB)  approving
requested changes and assisting in prioritization
 Emergency CAB (ECAB)  the same, for
emergency changes
Change Management
… or
what we all get wrong!
 “Dad, my mobile went off !!!
…”
“… what did you change ? …”
 80% of service interruption is
caused by operator error or
poor change control
(Gartner)
Change Types
 Normal
 Non-urgent, requires approval
 Standard
 Non-urgent, follows established path, no
approval needed
 Emergency
 Requires approval but too urgent for normal
procedure
Change Advisory Board
 Change Manager (VITAL)
 One or more of





Customer/User
User Manager
Developer/Maintainer
Expert/Consultant
Contractor
 CAB considers the 7 R’s
 Who RAISED?, REASON, RETURN, RISKS,
RESOURCES, RESPONSIBLE,
RELATIONSHIPS to other changes
Release Management
 Release is a collection of authorised and
tested changes ready for deployment
 A rollout introduces a release into the live
environment
 Full Release
 e.g. Office 2007
 Delta (partial) release
 e.g. Windows Update
 Package
 e.g. Windows Service Pack
Release test & deploy (1/2)
 Release Manager will produce a
release policy
 Release MUST be tested and NOT
by the developer or the change
instigator
 Deploy can be manual or automatic
 Automatic can be push or pull
Release test & deploy (2/2)
 Phased vs. big-bang deploy
PREP-1
PREP-2
PREP
 Consider:





Release preparation time
Concurrent changes
Interactions with other internal/external systems
Test complexity
Is the date your own choice? (… hardly ever !)
 Phased generally less painful but more work
Stage 4 – Service Operation
 Maintenance
 Management
 Realises Strategic
Objectives and is where
the Value is seen
Service Operation Balances
A
B
Reactive
Proactive
Responsiveness
Stability
Cost
Quality
Internal
External
Processes in Service
Operation
1.
2.
3.
4.
5.
Request Fulfilment
Access Management
Event Management
Incident Management
Problem Management
P#1 – Request Fulfilment
 Information, advice or a
standard change
 Should not be classed as
Incidents or Changes
P#2 – Access Management
 Right things for right users at right time
 Concepts





Access
Identity (Authentication, AuthN)
Rights (Authorisation, AuthZ)
Service Group
Directory
P#3 – Event Management
 3 Types of events
 Information
 Warning
 Exception
 Need to make sense of events and have
appropriate control actions planned and
documented
P#4 – Incident Management
 Incidents are a subset of Events
 IM deals with unplanned interruptions to
IT Services or reductions in their quality
 Failure of a configuration item that has
not impacted a service is also an incident
(e.g. Disk in RAID failure)
 Reported by:
 Users
 Technical Staff
 Monitoring Tools
Incident Management (1/3)
An incident defined as an unplanned, unexpected
or unexplained disruption in service (any event
which is not part of the standard operation of a
service and which causes or may cause an
interruption to or a reduction in the quality of the
service that is provided).
 Objective is to restore normal service operation as
quickly as possible and minimize the adverse
impact on business operations.
 The process responsible for managing the life-cycle
of all incidents.
Incident Management (2/3)
Incident Management input and output of the process, and its activities
Incident Management (3/3)
ESCALATION = the mechanism that assists timely resolution of an Incident
Levels of support are specific to technical expertise
P#5 – Problem Management
 Don’t confuse a Problem (the cause) with
an Incident (the effect)
 Aims to prevent problems and resulting
incidents
 Minimises impact of unavoidable incidents
 Eliminates recurring incidents
 Proactive Problem Management
 Identifies areas of potential weakness
 Identifies workarounds
 Reactive Problem Management
 Indentifies underlying causes of incidents
Problem Management (1/2)
A Problem is defined as the unknown underlying
cause
• Problem Management aims to Stabilize IT
services through:
•Minimizing the consequences of incidents
•Removal of the root causes of incidents
•Prevention of incidents and problems
•Prevent recurrence of incidents related to
errors
•Both reactive process and proactive process.
Problem Management (2/2)
Problem
Management
takes time to
identify the
cause and
eliminate it.
Functions in Service
Operation
 Service Desk
 Technical Management
 IT Operations Management
 Applications Management
Service Desk (1/3)
 Local, Central or Virtual
 Single point of contact (POC)
 “Call Centre” & “Help Desk”: particular
instances of S.D.
 Skills for operators







Customer Focus
Articulate
Interpersonal Skills (patient!)
Understand Business
Methodical/Analytical
Technical knowledge
Multi-lingual
 Service desk often seen as the bottom of
Service Desk (2/3)
Change
Management
•Integrated function, not
a process, to all of the
“operational” process.
•Serves an intended
purpose
•Single point of contact
between service
providers, customers
and users.
•Manages incidents and
escalates according to
agreed service levels.
•Manage requests,
incidents, service
requests and
communications with
customer and users.
Incident
Management
Release
Management
Service
Support
Service Desk
Configuration
Management
Problem
Management
Service Desk (3/3)
Telephone
Requests
Email/voice/video
requests
Hardware/
application
events
Internet/browser
requests
single POC
Local
Central
Virtual
Service Desk
Computing
Services
IT Training
Fax
requests
Networks
Operations
Learning
Technologies
Telecommunications
Management Information,
Reports, Metrics
Distributed
Computing
Security
Enterprise
Applications
Project and Service
Management
Contracts and
Licensing
Stage 5 – Continual
Service Improvement
 Focus on Process owners and Service
Owners
 Ensures that service management
processes continue to support the
business
 Monitor and enhance Service Level
Achievements
 PDCA (Deming cycle:
plan, do, check, act)
Service Measurement
 Technology (components, MTBF etc)
 Process (KPIs - Critical Success Factors)
 Service (End-to end, e.g. Customer
Satisfaction)
 Why?




Validation – Soundness of decisions
Direction – of future activities
Justify – provide factual evidence
Intervene – when changes or corrections are
needed
7 Steps to Improvement
What should
we measure?
Corrective
action
Present and
use info
Analyse data
What can we
measure?
Gather data
Process data