The document discusses key concepts in IT service management (ITSM) and ITIL. It covers the core ITSM components including service strategy, service design, service transition, service operation, and continual service improvement. Some key processes explained in ITIL include change management, problem management, and incident management. The benefits of adopting ITSM best practices like ITIL are also highlighted.
2. Today’s 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
3. •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
Today’s Topics
4. Business Challenges
IT Responsibilities
Minimizing risk in a dynamic
business scenario
Minimizing cost & time-to-
market
Improving ROI
Increasing Business Performance
IT enables the business to meet its goals
Ensuring a stable & flexible IT
environment
Optimizing resources & costs
Minimizing costs & complexity
Adapting quickly to changing
needs
IT Organization Current Challenges
5. The IT organization of the future
will have a different focus
Today’s focus Tomorrow’s focus
Dependable and efficient
operations
Commodity computing utility
Broad technology focus Narrow technology focus;
broad business focus
Stretched across proprietary
technologies
Exploiting standards
Poorly documented, widely
variable procedures
Transparent, consistent, and
easily audited processes
Collection of stovepiped
functions
Process-based, both inside IT and
with the business
7. 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
8. What is IT Service Management?
IT Service Management is the totality of IT
Service Provision, including the management of
the infrastructure and the environment
IT Service IT Service IT Service IT Service
INFRASTRUCTURE ENVIRONMENT
Good IT Service Management ensures that Customer
requirements; and expectations are met with consistency.
9. 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
10. Key Elements
Customer / End Users Service Manager / Team
PEOPLE Production Acceptance
TeamExecutive Sponsor
Change Control Hardware
Problem Management
Software
PROCESS PRODUCTS
Project Manager / Team Suppliers / Outsourcers
Capacity Planning
Configuration
Management
PARTNERS
Tools / Technology
11. ITIL : Information Technology Infrastructure Library
• 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
12.
The History behind ITIL
ITIL
Version 1 ITIL
Version 2
British civil
service
10+30 books
2+N books
The Netherlands
Rest of the
world
ITIL
Version 3
2+N books
16.
Ten core processes of ITIL
(… and one function)
Service Desk
Incident mgmt
Problem mgmt
Config. mgmt
Change mgmt
Release mgmt
Service Level mgmt
Financial mgmt
for IT-services
Capacity mgmt
IT Services
Continuity mgmt
Availability mgmt
ITIL
17. 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.
20. 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
21. “ 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”
22. ITIL is a CATALYST for transforming IT.
Traditionally IT has operated in functional silos
with separate goals and objectives.
But in Today’s 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.
24. Key Concepts
Configuration Management System (CMS)
Tools and databases to manage IT service provider’s
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
25. 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
26. 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 organization”
27. •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.
•Product Manager – Accountable for development, performance, and
improvement of a group of related services.
Key Concepts
28. More Roles
Business Relationship Manager
Service Asset & Configuration
Service Asset Manager
Service Knowledge Manager
Configuration Manager
Configuration Analyst
Configuration Librarian
CMS tools administrator
33. SERVICE STRATEGY
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
34. SERVICE STRATEGY HAS FOUR ACTIVITIES
Define the Market
Develop the Offerings
Develop Strategic Assets
Prepare for Execution
35. SERVICE ASSETS
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
36. SERVICE PORTFOLIO MANAGEMENT
Prioritises and manages investments and
resource allocation
Proposed services are properly assessed
Business Case
Existing Services Assessed. Outcomes:
Replace
Rationalise
Renew
Retire
37. Service Design
• How are we going to provide it?
• How are we going to build it?
• How are we going to test it?
• How are we going to deploy it?
Holistic approach to determine the impact of
change introduction on the existing services and
management processes
38. Processes in Service Design
• Availability Management
• Capacity Management
• ITSCM (disaster recovery)
• Supplier Management
• Service Level Management
• Information Security Management
• Service Catalogue Management
39. 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 easy-to-
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!)?
40. Things you might find in an SLA
Service
Description
Hours of
operation
User Response
times
Incident
Response
times
Resolution
times
Availability &
Continuity
targets
Customer
Responsibilities
Critical
operational
periods
Change
Response
Times
41. 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
42. Right Capacity, Right Time, Right Cost!
• This is capacity management
• Balances Cost against Capacity so minimises
costs while maintaining quality of service
43. 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
44. ITSCM – what?
• IT Service Continuity Management
• Ensures resumption of services within agreed
timescale
• Business Impact Analysis informs decisions
about resources
– E.g. Stock Exchange can’t afford 5 minutes
downtime but 2 hours downtime probably wont
badly affect a departmental accounts office or a
college bursary
45. 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
46. 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
48. 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
49. 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
50. 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
51. 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
53. 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
54. 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)
55. 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
56. 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
57. 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
58. 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
63. 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
64. 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
65. Request Fulfilment
• Information, advice or a standard change
• Should not be classed as Incidents or Changes
• Can we give more examples?
66. 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
67. Access Management
• Right things for right users at right time
• Concepts
– Access
– Identity (Authentication, AuthN)
– Rights (Authorisation, AuthZ)
– Service Group
– Directory
68. 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!
69. 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)
70. 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
71. 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
72. 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
73. Benefits of ITIL Service Transition
Align the new or changed service with the
Organization’s 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
74. 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
75. 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”
76. 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.
77. Relationship to other processes
Change
mgmt
Release
mgmt
Config.
mgmt
Problem mgmt
Incident mgmt
Capacity mgmt
Availability mgmtIT service
cont mgmt
Service level
mgmt
78. 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.
79. Rôles
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.
80. Activities
RFC submission, Recording
Acceptance; filtering RFCs
Configurationmgmtprocessesinfo
andmonitorsthestatusofCIs
Classification, category and priority
Urgent?
Planning; Impact and Resources
Coordination
Build Test
Implement Working
Evaluation and Close
Rejection,
possibly
new RFC
Start back-out
plan
Urgent
procedures
Yes
No
81. 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
82. 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.
83. 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
85. 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.
86. Coordination
Key notions:
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
Build
Test
Implement
87. Evaluation
There should be a Post-
implementation 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?
88. 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.
89. 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.
90. 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
92. THE ROLE OF THE HELPDESK
Helpdesk
IT-sysadmin-
staff
Customers
Single
point of
entry
E-mail
Physical
access
Telephone
Web
ChatPorjects Interrupt-
controlled
93. SINGLE POINT OF ENTRY – WHY
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
94. KEY POINTS FOR HELPDESK
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
96. LOCATION AND INTERIOR (IF PHYSICAL)
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’
97. HOW MUCH STAFF IS SUFFICIENT?
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)
98. INFORMATION AND ANNOUNCEMENTS
“Nobody” read the
documentation
Docs must be
Especially designed
Location
Timing
Repetition
Variation
Focus
Briefness
ComprehensibleRelevance &
Usefulness
99. METRICS FOR HELPDESK
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
100. METRICS FOR TIMING
Problem
Symptom
Error message
First feedback
Analysis
Fixing Final
feedback
Closure
1 minute
10 minutes
1 hour
Note: the times
given is just
examples for
discussion
101. INCIDENTS IN A HELPDESK
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
102. PRIORITY AND PARAMETERS
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)
103. STATE DIAGRAM FOR AN INCIDENT
New
Open
More info
Archived
ClosedWait
In work
Analysed
104. DEFINITION OF THE COVERAGE
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
106. THE WELCOME PHASE
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.
107. PROBLEM IDENTIFICATION
1. Classification – which area is this problem within.
Might be partly automatic
2. Description – Make a short and explicit description
of the incident,
3. Verification – check that the problem is
reproducible
108. EXECUTION PHASE
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
109. VERIFICATION PHASE
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.
110. INCORRECT ROLES
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
(doesn’t tests)
The Sandman – closes ticket – nice and quetly
111. 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
112. 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