Sei sulla pagina 1di 114

ITIL Overview

Presented By: ADNAN ABBAS

Todays Topics
IT Organizations Current Challenges
IT Organization focus Today vs Tomorrow
Service & IT Service Management
ITIL
History
Problem Definition
WHY ITIL
Ten Core processes of ITIL
Service Lifecycle

Key Concepts to understand


CORE ITSM Components

Todays Topics
Service Strategy
Service Design
Service Transition
Service Operation
Continual Service Improvement
Benefits of These Core Components
Change Management Process explained in ITIL
Helpdesk Management Process explained in
ITIL
Benefits of ITSM
Conclusions and Recommendations

IT Organization Current Challenges


Business
Challenges

Increasing Business
Performance
Improving ROI
Minimizing cost & time-tomarket
Minimizing risk in a dynamic
business scenario
Adapting quickly to
changing needs

IT enables the business to meet its goals

IT Responsibilities

Minimizing costs &


complexity
Optimizing resources &
costs
Ensuring a stable & flexible
IT environment

The IT organization of the


future will have a different
focus

SERVICE
A service is a means of delivering value to
customers by facilitating the outcomes that
customers want to achieve without the
ownership of specific costs and risks.

What is an IT Service?
An "IT Service" is a set of IT-related functions (HW & SW)

User

Web Server

Application Server

Database Server

What is IT Service
Management?
IT Service Management
is the totality
of IT Service Provision, including the
management of the infrastructure and
ENVIRONMENT
INFRASTRUCTURE
the environment
IT Service

IT Service

IT Service

IT Service

Good IT Service Management ensures that Customer


requirements; and expectations are met with consistency

IT Service Management Objectives


To align IT Services with the current and future needs of the
Business and its Customers
To improve the quality of the IT services delivered
To reduce the long term cost of service provision

Needs

Cost

Quality

Key Elements
Customer / End Users

Executive Sponsor

PEOPLE

Service Manager / Team


Production Acceptance
Team

Hardware
Change Control
Problem Management

Software

PROCESS

PRODUCTS

Capacity Planning

Tools / Technology

Configuration
Management

PARTNERS
Project Manager / Team

Suppliers /
Outsourcers

ITIL : Information Technology Infrastructur


Developed in late 1980s in the UK in response to growing
dependence on IT
Now a public body of knowledge for Service Management
best practices
Helps organizations improve service levels and reduce the
cost of IT operations
A framework, defining ten interlocking processes for service
support and service delivery
Also provides guidance on IT security, business
management
The ten ITIL processes are described in two volumes:
- Service Support focuses on management of essential
operational processes
- Service Delivery on strategic management of the IT
services

The History behind ITIL


198
0s

British civil
service

ITIL
Version 1
10+30 books
199
0

ITIL
Version 2
2+N books

2000
s
The Netherlands
Rest of the
world

ITIL
Version 3
2+N books

Defining the Problem

WHY ITIL? Because IT is critical to t

ITIL is process-oriented

Leaders

People

ITIL

Roles
Subtasks

Traditionally

Middle mgmt

Processes
Task-oriented, non-hierarchical

Employees

Areas of work
Top-down, controlling
areas of responsibility

Ten core processes of ITIL


( and one function)
Service Desk

Service Level mgmt


Financial mgmt
for IT-services

Incident mgmt
Problem mgmt
Config. mgmt
Change mgmt
Release mgmt

ITIL

Capacity mgmt
IT Services
Continuity mgmt
Availability mgmt

What ITIL is not?


A complete blue-print, but bricks and material

from which you can build your own building


depending on your needs.
A quick fix, but a set of processes that you have
to build into the mind-set of your employees, and
which must be continually updated and improved.
Something you buy, although you can buy help
to implement it, the core of the work is changing
your own organization and how it thinks and
functions.
Another method of control, but a way of
setting up your organizaton so that it works
towards the goals without controlling
management.

ITIL Service Lifecycle

Five Phases of ITILv3

ITIL: the process


improvement program
Typical program elements
People Allocate roles and responsibilities (reorganization?)
Align skills to business needs
Organize ITIL training and motivation
Project/change management

Processes Define processes and process tasks and document


Define process metrics/KPIs
Integrate process information
Initiate customer survey cycle

Tools Process automation, process integration


Asset management repository
Configuration management database (CMDB)
Business service definition and mapping

Think of ITIL not as a


destination, but as a vehicle you
can use to help you travel more
quickly and efficiently on your
ongoing journey of continuously
improving service levels

ITIL is a CATALYST for transforming IT.


Traditionally IT has operated in
functional silos with separate goals
and objectives.
But in Todays environment, IT is
changed with transforming itself into a
service oriented culture, where cross
functional teams are unified in the
common pursuit of service excellence
and business alignment.

ITIL is DESCRIPTIVE
versus
PRESCRIPTIVE

ITIL describes what needs to be done to improve


BUT
It does not explain how to do it.

Key Concepts
Configuration Management System (CMS)
Tools and databases to manage IT service

providers configuration data


Contains Configuration Management Database
(CMDB)
Records hardware, software, documentation and

anything else important to IT provision

Release
Collection of hardware, software, documentation,

processes or other things require to implement


one or more approved changes to IT Services

Key Concepts
Incident
Unplanned interruption to an IT service or an

unplanned reduction in its quality


Work-around
Reducing or eliminating the impact of an

incident without resolving it


Problem
Unknown underlying cause of one or more

incidents

Key Concepts
Processes(s): are structured sets of
activities designed to achieve a specific
objective.
Function(s): are self-contained subsets of an
organization intended to accomplish specific
tasks. They usually take the form of a team or
group of people and the tools they use.
Processes help organizations accomplish
specific objectives often across multiple
functional groups
whereas
Functions add structure and stability to

Key Concepts
Roles: are defined collections of specific
responsibilities and privileges. Roles may be held by
individuals or teams. Individuals and teams may hold
more than one role. ITIL emphasizes a number of
standard roles include, most importantly:
Service Owner -- Accountable for the overall design,
performance, integration, improvement, and
management of a single service.
Process Owner -- Accountable for the overall design,
performance, integration, improvement, and
management of a single process.
Service Manager -- Accountable for the development,
performance, and improvement of all services in the
environment.

More Roles
Business Relationship Manager
Service Asset & Configuration
Service Asset Manager
Service Knowledge Manager
Configuration Manager
Configuration Analyst
Configuration Librarian
CMS tools administrator

CORE ITSM COMPONENTS

What are we going to provide?


Can we afford it?
Can we provide enough of it?
How do we gain competitive advantage?
Perspective

Vision, mission and strategic goals

Position
Plan
Pattern

Must fit organisational culture

Resources

Things you buy or pay for


IT Infrastructure, people, money
Tangible Assets

Capabilities

Things you grow


Ability to carry out an activity
Intangible assets
Transform resources into Services

Prioritises and manages investments


and resource allocation
Proposed services are properly assessed

Business Case

Existing Services Assessed. Outcomes:

Replace
Rationalise
Renew
Retire

Service Design

How
How
How
How

are
are
are
are

we
we
we
we

going
going
going
going

to
to
to
to

provide it?
build it?
test it?
deploy it?

Processes in Service Design

Availability Management
Capacity Management
ITSCM (disaster recovery)
Supplier Management
Service Level Management
Information Security Management
Service Catalogue Management

Service Level Management


Service Level Agreement
Operational Level Agreements
Internal

Underpinning Contracts
External Organisation
Supplier Management

Can be an annexe to a contract


Should be clear and fair and written in easyto-understand, unambiguous language

Success of SLM (KPIs)


How many services have SLAs?
How does the number of breaches of SLA
change over time (we hope it reduces!)?

Things you might find in an


SLA

Types of SLA
Service-based
All customers get same deal for same
services

Customer-based
Different customers get different deal
(and different cost)

Multi-level
These involve corporate, customer and
service levels and avoid repetition

Right Capacity, Right Time,


Right Cost!
This is capacity management
Balances Cost against Capacity so
minimises costs while maintaining
quality of service

Is it available?
Ensure that IT services matches or
exceeds agreed targets
Lots of Acronyms
Mean Time Between Service Incidents
Mean Time Between Failures
Mean Time to Restore Service

Resilience increases availability


Service can remain functional even though
one or more of its components have failed

ITSCM what?
IT Service Continuity Management
Ensures resumption of services within
agreed timescale
Business Impact Analysis informs
decisions about resources
E.g. Stock Exchange cant afford 5 minutes
downtime but 2 hours downtime probably
wont badly affect a departmental accounts
office or a college bursary

Standby for liftoff...


Cold
Accommodation and environment ready
but no IT equipment

Warm
As cold plus backup IT equipment to
receive data

Hot
Full duplexing, redundancy and failover

Information Security
Management
Confidentiality
Making sure only those authorised can
see data

Integrity
Making sure the data is accurate and not
corrupted

Availability
Making sure data is supplied when it is
requested

Service Transition
Build
Deployment
Testing
User acceptance
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
Some things excluded
Swapping failed device
Adding new user
Installing standard software

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-KnowledgeWisdom

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
Minimised costs
Enables proper change and release
management
Speeds incident and problem resolution

Configuration Management
System

BASELINE
A Baseline is a last known good

configuration
But the CMS will always be a work in
progress and probably always out of
date.
Current configuration will always be the
most recent baseline plus any
implemented approved changes

Change Management or what


we all get wrong!
Respond to customers changing business

requirements
Respond to business and IT requests for
change that will align the services with the
business needs
Roles
Change Manager
Change Authority
Change Advisory Board (CAB)
Emergency CAB (ECAB)

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 Rs


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

Phased or Big Bang?


Phased release is less painful but more

work
Deployment can be manual or
automatic
Automatic can be push or pull
Release Manager will produce a release
policy
Release MUST be tested and NOT by the
developer or the change instigator

Service Operation
Maintenance
Management
Realises Strategic Objectives and is
where the Value is seen

Processes in Service
Operation

Incident Management
Problem Management
Event Management
Request Fulfilment
Access Management

Functions in Service
Operation

Service Desk
Technical Management
IT Operations Management
Applications Management

Service Operation Balances

Incident Management
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

Event Management
3 Types of events
Information
Warning
Exception

Can we give examples?


Need to make sense of events and
have appropriate control actions
planned and documented

Request Fulfilment
Information, advice or a standard
change
Should not be classed as Incidents or
Changes
Can we give more examples?

Problem Management
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
Identifies changes to prevent recurrence

Access Management
Right things for right users at right
time
Concepts
Access
Identity (Authentication, AuthN)
Rights (Authorisation, AuthZ)
Service Group
Directory

Service Desk

Local, Central or Virtual


Examples?
Single point of contact
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 the pile


Bust most visible to customers so important to get right!

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
Plan do check act (Deming)

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

Benefits of ITIL Service


Strategy

Alignment of new & changing services to


organizational strategy
Supports business cases for investment
Resolves conflicting demands for services
Improves service quality by strategic
planning
Ensures that organizations can manage
the costs and risks associated with their
Service Portfolios

Benefits of ITIL Service Design


Agreeing service level agreements
with internal departments and
external third party suppliers
Measuring IT quality in business terms

Reduced total cost of ownership

Improved quality/consistency of service

Improved IT governance

More effective Service Management

Benefits of ITIL Service


Transition

Align the new or changed service with


the Organizations requirements &
business operations
Ability to adapt quickly to new service
requirements
Improved success rate of changes
Improved organisational agility and
flexibility
Provides a consistent & rigorous framework
for evaluating the service capability & risk
before a new or changed service is released

Benefits of ITIL Service


Operation
Delivering & managing services at
agreed levels to Organizational
customers & users
Management & monitoring of the technology
that is used to deliver & support services
Management of Incidents, including Major
Incidents, & ensuring recovery of service
Ensuring the appropriate IT organisation is in
place to support the overall service
requirements of the Organization
Cost-effective Service Delivery

Benefits of ITIL Continual


Service Improvement
Commitment to ongoing service quality
Ongoing improvements to service &
supporting processes
Review & implementation of appropriate
business-focused service measures
ROI (Return on Investment)
VOI (Value on Investment)
Continual improvement becomes part of
Business as Usual

Change Management process


explained in ITIL
It is one of the most central and most
important ITIL processes
Everything that changes a status in a CI in
CMDB in ITIL
Change mgr should have a good broad
overview, some in-depth knowlegde in key
areas, and know lots of the local history.

Relationship to other processes


Incident mgmt
Release
mgmt

Problem mgmt

Change
mgmt

Config.
mgmt

Service level
mgmt

Capacity mgmt
IT service
cont mgmt

Availability mgmt

Goal
Ensure that all changes are performed
in a structured, documented and
well-planned process.
Balance between flexibility (what
needs to be done right now) and
stability (so that changes does not
break anything.

Rles
Change manager
Change coordinator
Change Advisory Board (CAB)
Change mgr, Service Level mgr, repr/service
desk, repr/problem mgmt, management,
business rep, user reps, development rep,
system administrators, vendor reps.

CAB/Emergency Commitee (CAB/EC)


Only the most essential members of CAB.

Activities
RFC submission, Recording

Rejection,
possibly
new RFC

Classification, category and


priority
Urgent?

Yes

Urgent
procedures

Planning; Impact and Resources

Coordination

Configuration mgmt processes info


and monitors the status of CIs

Acceptance; filtering RFCs

Build
Implement

Evaluation and Close

Test
Working

No

Start back-out
plan

Registration of an RFC

Identification number
References to problems and known errors
Description and references to CIs involved
Rationale for the change
Current and future CIs that will be changed
Name and contact info for the person that
suggested the RFC
Date etc
Overview of resource usage and time
estimates

Acceptance
The process of accepting an RFC,
has as its goal to filter out proposed
changes that are incomplete,
impractival, impossible, too
expensive, unclear, that is untimely
(must wait to a better time), or that
has unwanted consequences.

Further information in an RFC

Data on categorization and priority


Estimate on how it will affect the rest of the system
Recommendations from change mgr
History of the handling of this RFC, including acceptance
and autorization
Plans for backup
Requirements for maintenance
Plan for implementation
Roles for the implementation phase, including casts
Timing for the implementation
Timing for evaluation
Test results and observed problems
If the change is rejected, a reason why
Information on scenarios and evaluation

Classification
Priority:
Low (postponable)
Normal
High
Urgent (must do
now)

Categories
Low impact
Significant
impact
Great impact

Planning and Acceptance


Three levels of
acceptance:

Financial (can we
afford this?
Cost/benefit?)
Technical (is it
doable and is it
smart to do it?)
Business (is it
constructive
compared to focus
of what we do as
an organization?)

Forward Schedule
of Change (FSC):
overview over future,
planned changes
CAB should discuss:
1. Unautorized changes
2. Autorized changes that
shortcut the CAB
3. RFCs for review in CAB
4. Changes that is open or
that was recently closed.
5. Review of changes that
have been implemented.

Coordination
Key notions:
Build

Test

Implement

Iterative process
Should be tested in a
laboratory
Holistic view: SW,
HW, docs,
procedures etc
RFC is the plan that
controls the changes
No change without a
RFC

Evaluation

There should be a
Postimplementation
Review (PIR) after
the completion of the
change.
This must be
governed by the CAB.

Was the goals for the


change achieved?
What is (if relevant)
the satisfaction of
the users?
Was any side effects
discovered after this
change?
Was the change on
budget and on time?
Are there any points to
follow up?

Standard changes
For small, structured, frequent, trivial and
easily understandable changes, it is
possible to give acceptance in advance
as a standard change.
Std chg are like templates or procedures
which are to be used in certain,
predefined situations with-out further
process.
Std chg must be logged, but Change mgr
is not involved in each specific case.

Emergency changes
If absolutely necessary, every non-essential,
non-technical stage can be circumvented

but the procedures for such must be


defined for the organization in advance:
CAB/EC is a sub-set of CAB and it is easier to
arrange for a meeting
Change mgr can make decisions by himself
Testing, documentation etc can be done post
factum.

Important: all shortcuts must be evaluated


afterwards.

Reporting
Reports:
Number of changes pr
time unit and pr CI
Overview of origin for
changes and RFCs
No of successful
changes
No of back-outs
No of incidents that can
be related to changes
Graphs and trends

Performance indicators:
No of changes pr time
unit.
Avg time to perform a
change
No of rejected changes
No of incidents that can
be related to changes
No of back-outs
Costs related to changes
Share of changes that is
within time and budget

Input and output


FSC (forward schedule of change)
FSC
RFC

CMDB

Change
mgmt

Triggers for
other proc

History

Reports

Single
point of
entry

IT-sysadminstaff

Porjects

HelpdeskE-mail
Physical
access
Telephone
Web
Chat
Interruptcontrolled

Customers

To maintain control over the speed


To make things more uniform for the users
To prioritize between different tasks
To get an overview over which tasks
remains
To limit interruptions to a small part of
the organization
Centralize expertize on user
communication

Not everybody is suitable for work there

Consider interior and location


Estimate sufficient staffing
Announce it actively, target user groups
Monitor it for performance
Use relevant tools to support the
helpdesk

If we stopped caring
about the customers,
maybe they would stop
bothering us?

Location

An area where lots of people pass by


Preferably a neutral area

Interior:

Sufficient room (space and air)


Friendly colors and furniture
No hang-arounds, old friends or
pentioneers

Ratio between helpdesk staff and users


depends on the situation:
University environment (emploees): 50-100
Students: 300-2000
ISP: 5000-50000
Note: these numbers are only examples (and
they change all the time)

Nobody read the


documentation

Location

Focus
Timing
Briefness

Docs must be
Especially designed

Repetition
Variation

Relevance &
Usefulness

Comprehensible

Number of customers by helpdesk


staffer
Volume of contact, and the change over
time to this volume
Degree of fulfillment of SLA
Need for personalized training and
education
Share of incidents that is escalated

Problem
Closure
Symptom
Fixing

Error message
1 minute

Final
feedback

1 hour

First feedback
Note: the times
given is just
examples for
discussion

Analysis
10 minutes

Priority
Ownership
Contact-info and
customer info
Timestamps
Refs to CIs
Status
Categorizations
History

Connect similar cases


Close old cases
Dispatch cases
Make statistics
Search in old cases
Prioritize between
cases
Escalate cases

Coverage How many are covered by the


error (1 5 100 all)?
Severity what is the consequence if the
error is not corrected (beauty-error
inconvenience error crisis)?
Frequency how often does this error ocurr?
(continually daily monthly once)?
Status how important is the reporter of the
error (your boss -- paying non-paying)

New

Analysed
Open

More info

Archived
In work

Wait

Closed

Which machines and applications


Who can contact the helpdesk
Where can they get help
When can they get help
How long must they expect to wait
How is the incident escalated

Welcome

Greet them

Problem
identification

Classification
Description
Verification

Planning and
execution

Verification

Alternatives
By sysadmin
Selection a
By user
Solution
Closure
Implementation

This phase is often under-estimated


(But, it is just a nice hello)
It is often a critical phase it is a first
impression, and some users can easily feel
dismissed.
If done well, it will facilitate the next
message from that user.

1.

2.

3.

Classification which area is this


problem within. Might be partly automatic
Description Make a short and explicit
description of the incident,
Verification check that the problem is
reproducible

Suggest different solutions maybe on


temporary for today and a possible
permanent for the future. Often a task for
experts
Select a solution prioritize between
the solutions, involve the user, and a
suitable solution.
Execution let a sysadmin execute the
solution if neccessary, or otherwise help
the user

Sysadm-verification Let those who


have changed something or suggested a
solution test it before forwarding it to the
user
User-verification Let the user himself
test the solution, and come with feedback
on whether the solution worked or not.

The bogeyman frightens the user away no


work
The forwarder sends the user somewhere else
The assumptionist knows what the problem is,
even without having studied the problem and
symptoms
The conceptualist who fixes minor things by
changing everything
The typo-ist who never is able to write docs,
commands, or scripts without typos.
Hit-and-run-Sysadm comes, writes
commands, runs (doesnt tests)
The Sandman closes ticket nice and quetly

The Benefits of ITSM


Cut IT costs

Streamline IT support through automation of processes


Optimize resource usage through better visibility and planning
Measure, monitor and reduce cost of service provision

Maximize productivity and customer retention


through better services and support

External IT support is more responsive and consistent, increasing customer


satisfaction and retention
Internal IT support is more effective, keeping business users productive
and increasing capacity to generate revenue

Gain a competitive edge through increased agility


Become more responsive to the needs of the business
Streamline IT support and drive a transformation from reactive to
proactive IT
Take new lines of business to market quicker through faster delivery of
supporting IT services

Mitigate risk and ensure business continuity


Plan changes and assess impact
Escalate decision-making to management

Conclusions and
recommendations

ITIL is an enabler for process improvement


A combination of processes/people/tools is

required
Only tools can provide effective automation
The tool investments will generate ROI, not
the ITIL project
Always measure your progress by measuring
before and after process improvements
IT process planning tool other departments
may already have a tool to plan/measure
business processes

ITIL v3 Certification Roadmap

Thank You

Potrebbero piacerti anche