Presentations
on Classical ITIL
By Robert E. Perrine.
Smashwords Edition.
Copyright 2010 Robert E. Perrine.
Copyright
Copyright held by Robert Perrine and Marlene Weldon, Long Beach, California. You may not copy or distribute this document without advanced written permission from the document authors. Contact Robert E. Perrine at http://www.robertperrine.biz.
This ebook is licensed for your personal enjoyment only. This ebook may not be re-sold or given away to other people. If you would like to share this book with another person, please purchase an additional copy for each person. If you are reading this book and did not purchase it, or it was not purchased for your use, then please return to Smashwords.com and purchase your own copy. Thank you for respecting the hard work of this author.
Acknowledgements
I want to thank all of the friends I have worked with over the years who helped me learn about project management and about people. Special thanks go to Brian, Franklyn, Lesley, Tom and Travis for their support and encouragement while I was working on this book.
Disclaimer
The purpose for this ebook is education. This ebook is a collection of notes, handouts and presentations that Robert Perrine has used when teaching about Version 2 of the Information Technology Infrastructure Library (ITIL). The purpose for this ebook is to share information. No warranty is made or implied as to the suitability of the description contained in this ebook. It has been helpful to me. I hope it is helpful to you.
Also note that the format of a PowerPoint presentation is somewhat inconsistent with the ideal format for an ebook. I did some trivial testing with the Mobi reader on my laptop and on my Blackberry – and I felt the results were tolerable. If you have input regarding this, then send me an email and I will discuss it with you. I am always looking for better ways to spread the message. I can only do so many live presentations. I found significant limitations in what I could do when I posted this material onto my web site. I hope this ebook is an effective way to distribute this material. Let me know what you think.
Table of Contents
Topic 1: Introduction
Topic 2: Change Management
Topic 3: Service Desk
Topic 4: Incident Management
Topic 5: Problem Management
Topic 6: Configuration Management
Topic 7: Service Level Management
Topic 8: Availability Management
Topic 9: Release Management
Topic 10: Capacity Management
Topic 11: IT Service Continuity Management
Topic 12: IT Financial Management
Topic 13: ITIL as a Way of Life
Topic 14: Memory Aides
Topic 15: Service Management
If you work in Information Technology (IT), then you probably already know a lot about ITIL, without even knowing that you know it. The Information Technology Infrastructure Library (ITIL) is the concepts good companies use, packaged nicely, and then turned into a standard.
This ebook is focused on Version 2 – the classic ITIL – the one in most common usage. These concepts carry over into Version 3. And then Version 3 adds more. Personally, I have never found a company made full use of Version 2. I have helped companies do a lot with Version 2 – but never do all that could be done. And thus, I am reluctant to add even more complexity on top of this. Therefore, this ebook continues to describe the Classical ITIL.
.
.
ITIL is documented in a series of books published by the British Office of Government Commerce (OGC). Additional guides and teaching materials are available online. This series of presentations is focused on two of the Version 2 books: “Best Practices Guide to Service Delivery” and the “Best Practices Guide to Service Support”.
--
Most IT organizations already do nearly all of the Service Support processes.
Incident Management is typically oriented around a ticketing system.
Problem Management is what is done to resolve recurring problems.
Configuration Management is how you keep track of what is where.
Change Management is how you authorize changes.
And Release Management is a way of bundling changes into packages.
--
You probably already do most of this, even if you did not know it had a name.
Service Delivery is also used in nearly every IT shop, but it is typically informal.
Service Level Management is how you ensure your customers are happy.
Financial Management is how you ensure the bills get paid.
Capacity Management is how you ensure the systems run efficiently.
Availability Management is how you ensure the systems are up when they should be.
And IT Service Continuity Management is the planning you do for major catastrophes.
--
You already do this.
You just need to learn some vocabulary.
And then watch out for the differences between the standard and what you now do.
--
The following acronyms will help:
BSI: British Standards Institute
EFQM: European Foundation for Quality Management
ISO: International Standards Organization
ISO 9000 & 9001: ISO standards on Quality
ITSM: IT Service Management
ITSMF: IT Service Management Forum
OGC: Office of Government Commerce
Service Desk: Help Desk + Network Operations Center + Customer Care
--
Knowing the ITIL processes is important.
It is also important to see how they link together.
Consider the following example.
1. A User (Customer) calls the Service Desk (Help Desk) to report response difficulties with the on-line service.
2. The Incident Management process (Help Desk scripts) guides the first response to the Incident (Ticket).
3. The Problem Management (technical escalation) process investigates the underlying cause and calls in Capacity Management (data center management) to assist with this process. Service Level Management (Marketing) is alerted that the SLA (customer contract) has been breached.
4. The Change Management process raises and co-ordinates a Request For Change (RFC). Most companies do this. ITIL goes further.
5. The IT Financial Management process assists with the business case cost justification for the hardware upgrade.
6. The IT Service Continuity process gets involved in the Change Management process to ensure recovery is possible onto current back-up configuration.
7. The Release Management process controls the implementation of the Change by rolling out replacement hardware and software. Release Management updates Configuration Management with details of new Releases and versions.
8. The Availability Management process is involved in considering the hardware upgrade to ensure that it can meet the required availability and reliability levels.
9. The Configuration Management process ensures the CMDB information is updated throughout the process.
10. The Customer Relationship Management process liaises with Customer throughout the process to ensure he/she is kept abreast of progress
--
Well, that does get a bit complicated.
The point is not to do all ten steps for every trivial incident.
But, the other point is to have all ten steps pre-defined for those times when they are needed.
.
Change Management is like the traffic cones that guide automobiles around construction.
Change Management helps prevent accidents.
--
Change arises because of business needs and because of IT needs.
IT can facilitate change to allow the business to change.
-Such as upgrading systems to support increased customers sales.
The business might need to change to support IT updates.
-Such as moving off the old application and onto a web based version.
The business occasionally thwarts IT efforts.
-For example, insisting that the old system must remain even though no longer supported.
And IT sometimes prevents the business from moving forward.
--
ITIL Change Management is broader than what most companies do.
True Change Management begins with project inception.
Anything less is just a variation on Release Management.
--
Think about this example:
A web development team has finished testing their new application.
They fill out the forms and submit their Request For Change (RFC).
The Change Advisory Board (CAB) reviews the form and has one question:
“Is there enough power in that part of the data center to add all these new computers?”
If the answer is no, then there is a major problem.
Suddenly, a couple million invested in software development is put on hold.
Change Management could have added value months earlier.
--
And thus, ITIL Change Management is different from what most companies do.
Most companies wait until the last minute, and then vote yes or no.
ITIL Change Management is proactive.
It starts much earlier in the process.
The key step most often left out of the Change Management process is: PLANNING.
--
The Change Manager (CM) has duties that interrelate with the Change Implementer (CI).
CM - Register the change; CI – Plan the change.
CM – Approve the change; CI – Build the change.
CI – Test the change; CM – Verify the testing.
CM+CI: Implement the change.
CM – Evaluate the process.
--
Even so, most companies already have the fundamentals.
ITIL is focused on IT and not on other business units.
ITIL is focused on Operations, not projects.
So, developing the web application is something excluded from ITIL.
But anything that touches the infrastructure is in scope for ITIL.
--
ITIL also narrows the scope more than many companies do.
ITIL has an exception clause for “business as usual” activities.
ITIL has a category called “Service Requests” for typical activities.
And anything that can be done through the existing systems is typically excluded.
For example, adding new customers to a database through the screens is excluded.
But uploading a few thousand new customers through a SQL script is in scope.
Unless uploading through SQL is something that the Change Advisory Board has already decided falls into the category of “business as usual”.
--
Change Management is closely tied to other ITIL disciplines.
Capacity Management assists with trend analysis and requirements analysis.
Configuration Management identifies the configuration items.
Release Management packages large changes into manageable bundles.
Service Level Management negotiates the change windows.
One of the most important relationships within ITIL is the communication between Change Management and Configuration Management.
--
Change Management: The process of controlling Changes to the infrastructure or any aspect of services, in a controlled manner, enabling approved Changes with minimum disruption.
Configuration Management: The process of identifying and defining Configuration Items in a system, recording and reporting the status of Configuration Items and Requests for Change, and verifying the completeness and correctness of Configuration Items.
--
ITIL’s view of the benefits of Change Management
Increased Visibility
Increased ability to properly assess the risk
Increased ability to properly assess the cost
Better Planning
Reduced adverse impact on SLAs
Fewer failed changes
Better able to back out when a change fails
Less disruption
To users
To IT staff
--
ITIL’s view of the costs of Change Management
Increased Overhead
Time spent filling out forms
Time spent in reviews and in meetings
Cost of the portal or other tracking system
Excessive Burden
If not properly balanced, CM will strangle forward progress
Our Company: Corporate, Emergency, Departmental and Business-as-Usual
Some companies try to fit everything under one system
Change in Philosophy
Need to plan ahead for the change windows
Need to anticipate the questions the CAB will ask
--
It is important that the benefits outweigh the costs.
This is a trap many companies fall into when they first start to do ITIL.
Too many companies place a burden on the staff in the name of Change Management.
For Change Management to be successful, staff must realize benefits.
--
One ITIL technique is to scale the size of the Change Management burden to fit the need.
Small changes might have an informal approval process.
Medium changes might go through the normal Change Advisory Board.
Large changes might require executive approval in addition to the CAB approval.
And Standard Change are documented, approved once, and executed repeatedly.
--
More ITIL acronyms.
CAB = Change Advisory Board
CAB/EC = CAB / Emergency Committee
CI = Configuration Item (item within Configuration Management)
CM = Change Management
CMDB = Configuration Management DataBase
CM Metrics – Measurements that show the benefit of CM
FSC = Forward Schedule of Changes (calendar of changes)
PR = Problem Report
PSA = Projected Service Availability (calendar of SLA impact)
RFC = Request For Change
Standard Change = A repeatable operation that is approved once and executed repeatedly
IMPORTANT: Benefits outweigh the Costs
--
REVIEW ON TOPIC 2
When does ITIL CM begin?
What is the name of the form used to start the CM process?
Does CM cost the company money?
What are key benefits from CM?
What processes support ITIL CM?
--
REVIEW ON TOPIC 1
Name the 5 ITIL Service Support Processes
Name the 5 ITIL Service Delivery Processes
--
Service Support
Incident Management
Problem Management
Configuration Management
Change Management
Release Management
--
Service Delivery
SLA Management
Financial Management
Capacity Management
IT Service Continuity Management
Availability Management
(The answers to this quiz are the first line in the Synopsis that follows.)
1. The Service Support Processes are:
a. Incident Management, Problem Management, Configuration Management, Change Management, Release Management
b. Service Level Management, IT Financial Management, Capacity Management, IT Service Continuity Management, Availability Management
c. Incident Management, Problem Management, Configuration Management, Capacity Management, Performance Management
d. Service Level Management, IT Financial Management, Change Management, Release Management, IT Service Continuity Management
2. The Service Delivery Processes are:
a. Incident Management, Problem Management, Configuration Management, Change Management, Release Management
b. Service Level Management, IT Financial Management, Capacity Management, IT Service Continuity Management, Availability Management
c. Incident Management, Problem Management, Configuration Management, Capacity Management, Performance Management
d. Service Level Management, IT Financial Management, Change Management, Release Management, IT Service Continuity Management
3. In addition to these classes, it is important to:
a. Use the ITIL books when evaluating RFCs
b. Refer to the ITIL books when responding to Problem Reports
c. Study the ITIL books
d. Memorize the ITIL books
4. ITIL is an abbreviation for:
a. Information Technology Infrastructure Library
b. Infrastructure Technology Information Library
c. Informal Technical Individual Library
5. ITIL is important because it describes:
a. Guidelines for increasing sales
b. Guidelines for training IT staff
c. Guidelines for organizing an IT department
6. Attending ITIL training helps everyone use the same words to mean the same thing:
a. True
b. False
7. In the ITIL model, Change Management is most tightly integrated with:
a. Incident Management
b. Configuration Management
c. Service Level Agreement Management
d. Release Planning
8. Key benefits from Change Management are:
a. Better planning and increased visibility
b. Better planning and increased capacity
c. SLA compliance and capacity management
d. CAB and RFC compliance
9. The Acronym CAB stands for:
a. Configuration Advisory Board
b. Change Advisory Board
c. Change Approval Board
d. Capacity Analysis Board
10. An ITIL “Standard Change” is:
a. A change that has failed before and must be re-evaluated
b. A change that keeps repeating until it is finally done right
c. A change that is documented and approved once for repeated use
d. A change that no longer requires a change implementer
11. The Change Management Process should
a. Include all hardware changes, but exclude software changes
b. Include selected hardware changes and selected software changes
c. Exclude hardware changes, but always include software changes
d. Exclude all software changes
12. The Change Management Process should include all of the following except:
a. Hardware in production
b. Software in production
c. Hardware in the test environment
d. Software in the test environment
(The answers to the prior quiz are: A,B,C,A,C,A, B,A,B,C,B,D).
CHANGE MANAGEMENT SYNOPSIS
Goals:
Standardized methods
Efficient and prompt handling of Changes
Minimize impact from Change
Improve day-to-day operations
Benefits
IT aligned with business
Increased visibility and communication
Improved risk assessment
Reduced impact from Changes
Fewer Changes backed-out
Provide data to PM and Availability
Increased productivity of users
Fewer IT diversions
Ability to absorb more Changes
Enhanced business perspective on IT
Critical Success Factors
CM requires an appropriate tool
Implement CM with Configuration & Release
Plan, test and train for CM process
Management commitment
Audit trails in the tool
CAB requires authority
Introduce regular Change Slots
Key Performance Indicators
Number of Changes, grouped
Breakdown reasons for Change
Number successful
Number backed-out
Number secondary Incidents
Number and trends on RFCs
Size of review backlog
High RFCs due to fragile components
Prior year comparison
Number of RFCs rejected
.
The service desk is the people who interface with the customers.
Call Center is a subset of a Service Desk.
Call Center have high volume of telephone traffic.
Help Desk is a subset of a Service Desk.
Help Desk typically provide a quick resolution via tools.
The typical tools used by a Help Desk include:
Configuration Management
Known Errors database
Automated jobs
--
A Service Desk is:
More than a Call Center and more than a Help Desk
Integrated with business processes
One interface for all ITIL processes
--
Many companies jump into ITIL and quickly set up a Service Desk.
It will not succeed without management commitment.
A Service Desk is not a “silver bullet”.
There is no magic is changing the name of the department.
--
Startup will encounter obstacles
It is important that the effort be communicated to the customers
The customers need to be trained on what to expect
Metrics must be defined and implemented.
--
Typical Service Desk metrics
Types of calls
Call volumes
Closure Codes
How an Incident was resolved
Record Every Incident
Including monitoring
Questions
Change requests
“whether it took one minute or one month to fix.”
--
Goals for the Service Desk
Ease of use
High quality service
Integration with other ITIL processes
Customer in control
--
Types of Service Desks
Local
Central
Virtual
--
ITIL often starts out with enthusiasm.
As the cost of implementation increase people question the benefit.
It takes time for the benefits to accrue.
There is often a “Period of Blame” or “Trough of Disillusionment”.
If the effort can be sustained, then the benefits should rise above the costs.
--
Adoption of change follows a typical curve.
There is initial enthusiasm, followed by disappointment.
If the team persists, the benefits finally rise.
And then the enthusiasm returns.
This is known as the “Hype Cycle”.
.
Key Duties for the Service Desk
Classification
Notification
Information Distribution
OPTIONALLY: Restore “normal” operations
--
Classification
Specify the service and equipment
Define the priority
Associate to SLA
Defined questions to ask
Match solutions, Known Errors or Work-arounds
Assign to appropriate resource
Summarize and define the final action taken
Gather metrics
--
Notification
Customer telephone calls and emails
Monitoring jobs
Automated scripts
--
Information Distribution
Internet portal
Automated emails
Telephone calls and emails
Database of Known Errors
--
Most companies implement Incident Management within the Service Desk.
The Service Desk, however, is a business unit, it is not a process.
Remember there are five processes in Service Delivery
And five processes in Service Support
The Service Desk is not a process
--
The primary duty of Incident Management is to:
Restore “Normal Operation”
As quickly as possible
Either by Resolution or Work-Around
As “Normal Operation” is defined in the SLA
--
Key benefits from a Service Desk:
Customer Service
Improved Customer service, perception and satisfaction
Increased accessibility
Better-quality and speedier turnaround
Internal Service
Improved teamwork and communication
Enhanced focus and a proactive approach
Improved usage of IT resources
Increased productivity of business personnel
Better metrics
Better managed infrastructure and control
--
More ITIL acronyms
Active Listening = Working at listening and eliciting information
First Line, Second Line, Third Line = support levels in the Service Desk
IVR = Interactive Voice Response
KPI – Key Performance Indicator, a key metric
Quick Win = Simple to implement successfully with high visibility
Self-Service = Tools to let customer resolve themselves
Portals, IVR and Knowledge Base
Service Catalog = Comprehensive list of services agreed to deliver
Showcase = Enhanced visual impact to impress customers
Soft Skills = People skills
Super User = User with skill to help other users
VOIP = Voice Over Internet Protocol
Work Around – Not a resolution, but a temporary means to alleviate
SERVICE DESK SYNOPSIS
Goals
Global approach
Integrated
Handles incidents & Problems
Provides interface to other processes
Benefits
Improved Customer service – both perception and satisfaction
Single point of contact
Better-quality and speedier
Improved teamwork and communication
Focused and proactive
Reduced negative
Better managed infrastructure
Improved usage of resources
Increased productivity of business personnel
Better management information
Critical Success Factors
Business needs understood
Customer requirements understood
Investment in training
Service objectives and deliverables defined
Service levels - practical, agreed, and reviewed
Benefits accepted by the business
Key Performance Indicators
Number of requests
Requests taking most time
Request taking Customer longest time
Which Customers require the most support?
Possible Implementation Problems
Unrealistic expectations
Back-door support options
Misaligned communications
Tools
Configuration Management Database
Service Catalog
Service Level Agreements
Operational Level Agreements
Underpinning Contracts
Users Manual
Support procedures
Notification and escalation lists
Customer Surveys
Knowledge base including list of known errors
Soft skills such as active listening
Time tracking
Reports
Work load analysis
Activities
Receiving calls & Customer liaison
Recording and tracking Incidents and complaints
Customers informed
Initial assessment & attempt to resolve
Monitoring and escalation by SLA
Full life-cycle
Communicate changes
Coordinating support groups
Management information and recommendations
Identify Problems
Highlight Customer training needs
Confirm closure with Customer
Contribute to Problem diagnosis
Inputs
Data feeds (assets, etc)
Incidents
Requests for status
Questions
Service Requests
Outputs
Management Information and Monitoring
Support to groups with Incidents
Third Party Support
Sales, Purchase, Contract & Account Management
Communicate status and schedules
Informal user training
Manager’s Duties
Coordinate distributed SD resources
Support the Service Management processes
Implement Incident Management
Workload monitoring to manage staffing level
Management reporting
Conduct & analyze customer satisfaction surveys
Classification Process Reviews
Review & revise SD tools & procedures
Other Roles
Subject matter expert on the typical calls that come to the Service Desk
Ability to assist the First Line and Second Line technicians
Public image for the Service Desk
.
Incident Management is like playing table tennis (ping pong). The goal is to put the ball back onto the other side of the net. Do not drop the ball. Do not knock it out of bounds.
In ITIL language, the goal for Incident Management is:
Restore “Normal Operation”
As quickly as possible
Either by Resolution or Work-Around
As “Normal Operation” is defined in the SLA
--
Incident Management needs tools.
Configuration Management Database (CMDB)
Knowledge Base
Known Errors
Work-Arounds
--
Incident Management also depends on
Service Desk
The other 4 Service Support Processes
Linkage to Service Level Management
--
Key definitions:
Incident: “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 that service.” Incidents include “Events,” “Service Request,” etc.
Problem: “Unknown underlying cause of one or more Incidents.” “It can be seen therefore that a Problem Record is independent of associated Incident Records, and both the Problem Record and the investigation into its cause can persist even after the initial Incident has been successfully closed.”
Incident Management fails when it tries to do Problem Management’s job.
--
Incident Management relies on processes.
The flow of a typical incident might follow a path like the ones shown below.
.
Incidents originate in many ways:
Phone calls and email to the Service Desk.
Phone calls and emails from other IT staff.
Automated alerts.
And many other ways.
--
Incidents are an interruption or degradation in service.
Service Requests often look like an Incident.
But a Service Request is a request to do something that utilizes the system.
For example, if a user cannot login because the server is down, then it is an Incident.
But if the user just forget his or her password, then it is a Service Request.
--
Incidents have a life cycle.
Event – Incident – Problem – Known Error – Requests for Change – Structural Resolution
Key vocabulary terms:
Category = Grouping of services
Impact = Business criticality
Urgency = Duration allowable
Functional Escalation = Escalate for different skill set
Hierarchical Escalation = Escalate based upon time
Major Incident = Extreme Impact to the user community
WIP = Work in Progress
Workflow = the flow through the Incident Management process
--
Priority is defined in ITIL as: “Sequence in which an Incident or Problem needs to be resolved, based on impact and urgency”
This is an important ITIL concept.
INCIDENT MANAGEMENT SYNOPSIS
Goals
Restore normal service operation quickly
Minimize adverse impact
Maintain service quality & availability
Benefits
Reduced business impact
Timely resolution
Proactive identification of enhancements
Improved monitoring on SLAs
Management information on service quality
Better staff utilization
Elimination of lost Incidents
More accurate CMDB information
Improved User and Customer satisfaction
Critical Success Factors
Up-to-date CMDB
Knowledge Base
Automated Incident Management system
Close link to SLM for SLA targets
Key Performance Indicators
Numbers of Incidents
Mean time to resolution
Percentage within agreed response time
Average cost per Incident
Percentage closed by Service Desk
Incidents per SD workstation
Percentage resolved without a visit
Possible Implementation Problems
Management or staff commitment
Clarity about business needs
Practices not reviewed or changed
Poor objectives, goals and responsibilities
No provision of agreed Customer service levels
Lack of knowledge
Inadequate training
Lack of integration
Tools to automate the process
Resistance to change
Tools
CMDB with automated matching
Automated monitoring to create Incidents
Escalation timers
Ability to route to other groups
Automation for Classification
Auto-Call Distribution telephone system
Diagnostic tools
Knowledge base including list of known errors
Activities
Incident detection and recording
Classification and initial support
Investigation and diagnosis
Resolution and recovery
Incident closure
Ownership, monitor, track and communicate
Inputs
Incident details
Configuration Items
Matching against Problems and Known Errors
Resolution details
Response on RFC
Outputs
RFC for resolution
Updated resolution & Workarounds
Resolved and closed Incidents
Communication to Customers
Management information (reports)
Manager’s Duties
Drive efficiency and effectiveness of IM Process
Produce management information
Managing the work of IM staff
Monitoring the effectiveness of IM
Make recommendations for improvement
Develop and maintain the IM systems
Other Roles
Service Desk Manager
First, Second & Third-line
.
The key goal for Problem Management is to create a structural resolution to the problem.
Not a work-around, but a permanent fix.
However, a work-around is sometimes the most cost effective response to the problem.
--
Problem Management is linked to the other processes.
Closely tied to Incident Management through the CMDB and the Knowledge Base
Dependent on Change Management
Incident Management does not require “Change”
Problem Management means “Change”
Linked to the Service Desk
But, Problem Management must not do Incident Management or Service Desk work
--
Do not create a back-door for service
A back door is when the customer bypasses the Service Desk
--
Key definitions
Incident: Interruption or degradation of normal operations
Problem: Unknown underlying cause of one or more Incidents
Category = related group or domains
Impact = business vulnerability
Urgency = time available
Priority = relative order
--
Key benefits
Fewer Incidents
Learn from history
Better + Faster time to resolve Incidents
Permanent Fixes rather than just Work-Arounds
Net Effect = Improved Service Quality
--
Primary Duties
Problem Control
Error Control
Proactive
--
Problem Control
Transform Problems into Known Errors
Find a work-around
--
Error Control
Resolve Known Errors structurally
Through the Change Management process
--
Proactive
Monitoring
Trends analysis
Management reporting
Problem reviews (post mortem)
--
Key techniques
Troubleshooting techniques
Cause-and-effect diagramming
Brainstorming sessions
Process analysis
--
Basic troubleshooting is based on the scientific method.
State the problem
Propose a possible solution
Test the solution
If it works, then implement it
If it fails, then try again
--
An example of a cause-and-effect diagram is shown below.
.
Brainstorming Technique
Open discussion
Collect ideas
No criticism
Far fetched ideas offer alternatives
Goal is to generate new ideas
Then evaluate the most likely
--
Process analysis
Document the process
Ensure the documentation is accurate
Ensure the documentation is maintained
Then use the documentation when there is a problem to analyze
--
More acronyms
CIP = Continual Process of Improvement
Fragile = Failing repeatedly
Known Error = A Problem, successfully diagnosed With a work-around or resolution
--
Review on the Service Desk
How is a Service Desk different from a Call Center?
How is a Service Desk different from a Help Desk?
What types of data do you gather during “Classification”?
--
Review on Incident Management
How does a CMDB help Incident Management?
What is the goal for Incident Management?
What are the two types of escalation?
What types of Incidents generate Problem Reports?
--
Review on Problem Management
What is the goal for Problem Management?
What are the 3 Duties for Problem Management?
Name four of the techniques used in Problem Management?
(The answers to this quiz are the first line in the Synopsis that follows.)
1. A Service Desk is more than a Help Desk because it:
a. Manages both Incidents and Problems
b. Integrates with the ITIL processes
c. Supports many user groups
d. Uses tools such as a Known Errors database
2. Key Incident criteria are:
a. Category, Urgency, Impact and Priority
b. Category, Frequency, Impact and Priority
c. Category, Urgency, History and Priority
d. Category, Frequency, History and Priority
3. The primary duty of Incident Management is to:
a. Restore limited operations as quickly as possible
b. Restore normal operations as quickly as possible
c. Restore normal operations through Change Management
d. Improve operations through Change Management
4. An Incident is:
a. An interruption in service
b. An authorized change from the normal operation
c. An interruption or a degradation
d. Any interruption, whether planned or unplanned
5. Which of the following is true:
a. Functional Escalation occurs when you run out of time on the SLA
b. Functional Escalation occurs when the error is an Unknown Error
c. Hierarchical Escalation occurs when you run out of time on the SLA
d. Hierarchical Escalation occurs when the error is an Unknown Error
6. A Service Desk is often used to do the work in:
a. Incident Management
b. Problem Management
c. Configuration Management
7. Three types of Service Desk described by ITIL are:
a. Local, remote and off-shore
b. Local, central and off-shore
c. Local, central and virtual
8. The “period of blame” often occurs when:
a. A new service is first initiated
b. After a service has run for a while and before the new service has proven beneficial
c. After the service has proven beneficial and users become complacent
9. The work flow through Incident Management generally goes through this cycle:
a. Classification, Investigation, Detection, Closure and Resolution
b. Detection, Classification, Investigation, Resolution and Closure
c. Investigation, Detection, Classification, Resolution and Closure
d. Resolution, Classification, Detection, Investigation and Closure
10. Problem Management is often responsible for the creation of the ITIL:
a. Change Request
b. Incident Report
c. Reason for Outage
d. Request for Change
11. A Problem is:
a. The solution to a series of Incidents
b. The work-around for prior Incidents
c. The cause of prior Incidents
d. The result of prior Incidents
12. An Incident generates a new Problem when
a. The error is occurring frequently
b. The error is unknown
c. The error is known
d. The error is resolved
13. Error Control is the part of Problem Management responsible for:
a. Creating work-arounds
b. Creating resolutions
c. Creating known errors
d. Creating management reports
(The answers to the prior quiz are: B,A,B,C,C,A,C,B,B,D,C,B,B)
PROBLEM MANAGEMENT SYNOPSIS
Goals
Minimize the adverse impact from IR & PR
Prevent recurrence
Seek root cause
Initiate actions to improve or correct
Benefits
Improved IT service quality
Incident volume reduction
Permanent solutions
Improved organizational learning
Better first-time fix rate for SD
Critical Success Factors
Effective automated registration & classification
Achievable objectives to use Problem-solving talents
Balance potential conflict between IM & PM
Key Performance Indicators
Number of Problems and errors grouped
Elapsed time to close
Elapsed time on outstanding
Expected resolution time on outstanding
Mean and maximum elapsed time to confirm KE
Any temporary resolution actions
Possible Implementation Problems
Absence of good IM process
Absence of good historical data
Failing to link IR with PR and KE
Management commitment
Do not undermine SD with back-door
Time spent on Knowledge Base
Inaccurate prioritization
Tools
CMDB
Scientific Method
Ishikawa
Brainstorming
Flowcharting
Activities
Problem control
Error control
Proactive prevention
Identify trends
Management information from PM data
Major Problem reviews
Inputs
Incident details from IM
Configuration Items
Workarounds from IM
Outputs
Known Errors
Requests for Change
Updated PRs with resolutions & workarounds
Properly closed PRs
Matched IR to PR and KE
Management information
Manager’s Duties
Develop and maintain Problem Control process
Efficiency and effectiveness of Problem Control
Produce management information
Manage Problem support staff
Allocating resources
Effectiveness of Error Control
Recommendations to improve Error Control
Develop and maintain Problem/Error Control systems
Efficiency and effectiveness of Proactive activities
Other Roles
Problem support team
Topic 6: Configuration Management
.
Configuration Management is responsible for ensuring the right hardware and software is in the right place for the right purpose. It is also responsible for documenting the relationships between the components in the infrastructure.
--
Configuration Management is similar to Asset Management
Know what the inventory is
Know where it is
Hardware, Software and Documentation
Configuration Items
--
But ITIL Configuration Management is broader than what most do in Asset Management
Manage the configuration
Integrated into Change and Release Management
Identify the relationships between the CIs
--
This is a foundation for other ITIL processes
Doing it right requires planning
Build or buy a Configuration Management Database (CMDB)
Difficult to justify without other ITIL processes
But other processes cannot start until CMDB is ready
Recommendation is to phase this in simultaneously
--
DUTIES
Configuration Planning
-Design of the CMDB and Rollout planning
Configuration Items
-Link CIs to Incidents, Problems, RFCs, etc.
-Link CIs to each other, parent-child relationships
Configuration Control
-Lock down
-ITIL recommends CMDB updates 7x24 if Changes are 7x24
Configuration Status
-Pre-live, Live, Retired, etc.
Configuration Verification and Audits
-Initial verification followed by periodic audits
Configuration Baseline
-A good CMDB should be able to report at a point-in-time
CMDB
-Paper? Spreadsheet? Access? Purchased Application?
-Maintenance, backups, etc.
-Then use the tool to aid Change Management planning
-Which servers have this version?
-Which servers need a drive mirror?
Software and Documentation Library
Definitive Software Library
-The original copies of vendor and internal software
-Locked down
-Tied directly to Release Management
License Management
-Maintain the vendor license originals
-Manage the Configuration to insure license compliance
--
ITIL suggests one group can manage 3 key processes
Configuration Management
Change Management
Release Management
--
Configuration Management (CFG) and Change Management (CM) are mutually dependent
CM – Receive and RFC; CFG – assess the scope.
CM – Assess the impact; CFG – document the pending CI updates.
CM – Implement the change; CFG – make the CI updates.
--
Configuration Items - How deep?
Version number on every card ?
Or just a generic specification of make and model ?
Trade-off between effort and benefit
Too much detail increases the cost with little extra benefit
--
Configuration Item Audits
Open every machine and verify every card ?
Or just track the machine and let Change Management update parts?
--
Variant
Begin with a standard configuration with 100 systems
Change one disk drive
Fairly small change
But this system no longer matches the standard “CI”
Term is Variant – a close cousin to the standard
--
Linkages
Key distinction: Configuration versus Asset Management
For example, if one database goes down, then several web servers can be affected
Difficult to document all the complexity
Parent – Child relationship
Each Child CI has only ONE parent
But it can be linked to other CIs that “use” it
PC uses LAN
Web servers uses databases
There are limits to what you can do with CIs
Is a keyboard linked to a PC, does it float, or is it “expended”?
Probably not cost justifiable to track keyboards or mice
--
The CI Life Cycle
IT registers a CI
Configuration Management accept the CI
Release Management or Change Management implements the change.
Configuration Management updates the CI status.
Eventually the component is retired.
And Configuration Management retires the CI.
--
Examples of CIs
Category (hardware, software, document)
Make
Model
Version
Serial Number
Warranty
Location
Owner
Status
Acceptance Date
Links to Incident Reports (IRs), Problem Reports (PRs) and Request For Change (RFCs)
Links to other CIs
--
More acronyms and vocabulary
As Built = What actually exists
Baseline = Configuration at a point-in-time
Definitive Copy = Clean copy of the software
Definitive Software Library = Storage of definitive copy
Configuration Librarian = Person who runs the DSL
Greenfield Site = Location that has not done this before
KSF = Key Success Factors
Variant = Change from a base CI
CONFIGURATION MANAGEMENT SYNOPSIS
Goals
Account for all IT assets
Provide CIs to other Processes
Sound basis for IM, PM, CM & RM
Verify and correct CIs
Benefits
Accurate information on CIs
Control valuable CIs
Adhere to legal obligations
Help Financial planning
Make Changes visible
Contribute to Contingency planning
Improve Release Management
Security by controlling versions
Reduce unauthorized software
Perform Impact Analysis on Changes
Trend data for Problem Management
Critical Success Factors
Correct & accurate CIs to support SM
Defined procedures and tools
Identify, label, record CIs with history
Train organization on control processes
Reporting and auditing
Key Performance Indicators
Unauthorized configurations
IR & PR from wrongly made Changes
RFCs failed due to bad CIs or version control
Cycle time to approve & implement Changes
Licenses unused
Exceptions found in configuration audit
Unauthorized IT components
Possible Implementation Problems
CIs at wrong level
Inadequate analysis & design
Schedules overly ambitious
Commitment lacking
Too bureaucratic
Routinely circumvented
Processes inefficient or errors in process
Unrealistic expectations about tool
Tool lacks flexibility
Insufficient Change or Release processes
Unrealistic expectations about process
Controls not in place
Tools
Configuration Management Database
Software configuration management tools
Change Management support (impact analysis)
Automation for configuration auditing
Automation for release deployment
Definitive Software Library
Definitive Hardware Store
Document management system
Design, analysis and build tools
Report generation tools
Activities
Configuration Management planning
Configuration Identification
Control of CIs
Configuration status accounting
Configuration verification and audit
CMDB back-ups, archives and housekeeping
Add value to the SM organization
Inputs
Incidents, Problems, Known Errors & RFCs with updates
SW & HW for DSL/DHS
Configuration audits
Outputs
Forward Schedule of Changes
Projected Service Availability
RFC, assessment and updates
Releases from DSL/DHS & library
Updated CIs and relationships
Management information
Linkages to the CDB
Manager’s Duties
Implements agreed CM policy
Develop/improve CM systems
Propose/agree CM scope and plan
Propose/agree Standards & procedures
Awareness campaign
Arrange for recruit/train of staff
Propose/agree CI conventions & standards
Provides management information
RFC impact assessment & updates
Configuration Audits and corrective actions
Other Roles
Configuration Librarian
Topic 7: Service Level Management
.
SLM Goals
Improve Service
Improve Service Perception
-Set realistic expectation
-Define an external standard to measure against
-Identify gaps
--
Duties
Measurement and Reporting
-Monitor before agreeing to SLA metrics
Agreements
-Service Level Agreements
-Operational Level Agreements
-Underpinning Contracts
-Mutually beneficial
-Easy to read and interpret
-Widely distributed and understood
Renegotiate
-Management Perception
-User Perception
-Provider Perception
Service Catalog
-Linked into the CMDB
-Used by the Service Desk and connected to Incident Reports
-Used in service level audits
-ITIL recommends listing all services as CIs in the CMDB
Escalation Paths
Priority Levels
Satisfaction Surveys
--
Key SLM concept
“Satisfaction = Expectation – Perception”
--
SLA Life Cycle
.
Service Level Agreements
Can be layered
I. Customer Level
A. Specific agreement for web site availability
1) Detailed agreement on the database cluster
Must be Realistic, Achievable and Affordable
Must be Measurable
-SLM is closely tied to Availability Management
-Measure what the agreement says is covered
--
Suggested SLA format
Introduction
Hours of Coverage
Metrics
-Availability or Unavailability
-Reliability
-Mean Time Between Failures (MTBF)
-Mean Time Between System Incidents (MTBSI)
-Response Time or Throughput
Service Hours
-Target Time to Respond
-Target Time To Resolve
How to process a Request For Change
-Targets times for responding and implementing
-Based on Category, Impact, Urgency and Priority
IT Service Continuity plans
Reporting schedule and details
Charge Rates
Incentives and Penalties
--
More acronyms and vocabulary
BIA = Business Impact Analysis
Charging = Internal “billing”
KISS = Keep It Simple Suzy
RAG = Red-Amber-Green indicators
SLAM = Service Level Agreement Monitoring
SIP = Service Improvement Program
Service = 1 or more IT systems that enable a business process
SMART = Specific, Measurable, Achievable, Realistic, Timely
SLR = Service Level Requirement. This is an SLA recommendation, not implemented
.
Goals
Maintain and improve IT Service quality
Constant cycle of agree, monitor, report and act
Better relationship with Customer
Benefits
Services designed to meet SLRs
Improved relationship with satisfied Customers
Clear roles and responsibilities
Specific targets
IT aligned with business
Clear and consistent expectations
Service monitoring to find and improve weak areas
Service monitoring identifies training needs
Underpins supplier management
Demonstrates value to enable Charging
Critical Success Factors
Clear and accurate SLAs
Regular reviews
Monitoring to confirm compliance
Clear communication to Customers, Users & staff
Key Performance Indicators
Percent of services covered by an SLA
Percent of SLAs backed by OLA and UC
SLAs monitored and reported regularly
Review meetings with minutes
Issues raised in reviews are worked and resolved
Percent of SLAs, OLAs and UCs needing review
Percent met and percent breached
Severity of the breaches
Are breaches reviewed effectively?
Are service levels improving?
Are Customer perceptions improving?
Are IT costs decreasing for stable services?
Possible Implementation Problems
Monitor and match perceptions before agreeing
Ensure targets are achievable
Verify targets prior to agreeing
Unrealistic SLAs
Inadequate focus, resources and time given to SLM
Inadequate authority/seniority for SLM negotiation
Inadequate UCs
Unclear responsibilities
IT bias when business does not know own needs
SLA too lengthy or verbose or unfocused
SLAs not properly communicated
Company views SLM as an overhead
Focus on contracts instead of relationships
Tools
Service Catalog
Service Level Agreements
Operational Level Agreements
Underpinning Contracts
Service Level Requirements
Accurate Configuration Items
Monitoring and reporting from CDB
Activities
Produce Service Catalog
Plan, draft, negotiate & agree the SLA
Monitor, report & review
Service Improvement Programs
Inputs
Prior informal processes & artifacts
Input from Customer, User, IT & vendors
Monitoring and reporting
Incidents, Problems, breaches and near misses
Outputs
SLM processes & artifacts
Formal Catalog of Services
Finalized SLA, OLA and UC agreements
Negotiations, agreements and periodic reviews
Reports
Requests for Change
Manager’s Duties
Create & maintain Service Catalog
Formulate, agree, maintain, monitor, report & review on SLM, SLAs, OLAs & UCs
Negotiate & agree SLRs
Topic 8: Availability Management
.
Availability Management is the group responsible for all those things that absolutely must be up and running. The life and death of the business depends on Availability Management.
Business survival depends on IT
Internal users
Customers
Investor confidence
But, Availability must be Cost Effective
--
Duties
Assist in defining SLAs
Measure and report Availability
Identify and implement improvements
But, Availability Management is not IT Service Continuity Management
--
Guiding Principles
“Availability is at the core of business and User satisfaction”
This is the most important service that IT delivers
“Recognizing that when things go wrong, it is still possible to achieve business and User satisfaction”
Stuff happens
Now, what are you going to do about it ?
Pre-defined processes and tools impress the customer with IT competence
“Improving Availability can only begin after understanding how the IT Services support the business”
Availability means that user can do their job
Not just a simple measure of “components”
--
There are many inputs into Availability Management.
Business requirements.
Business impact analysis.
Availability and capacity metrics.
Reliability and resiliency assessments.
Incident and Problem reports.
Service Level Agreements and breaches to SLAs.
--
The key outputs from Availability Management include:
Design criteria for updates.
Risk Management Plans.
Updated SLA agreements.
Published reports.
Projects to make improvements.
--
Key vocabulary
Availability = Ability to perform during the agreed hours
Unavailability = Easier to measure, better to report
Reliability = Probability a component will work
Resiliency = Ability to mask a component failure
Maintainability = Ease of maintenance and ease of recovery
Security = CIA (Confidentiality, Integrity and Availability)
Serviceability = Vendor maintenance agreements
Vital Business Function (VBF) = minimal essential functions
--
Example
There are four changes scheduled for today
Router security patch will take 15 minutes
Web server security patch will take 30 minutes
Server security patch will take 30 minutes
Database security patch will take 45 minutes
What is the net availability for this day?
The right answer is: it all depends
If this is a scheduled maintenance window, then maybe the patches are done sequentially
If there is redundancy, then maybe the patches are done without any impact on availability
Or, maybe Availability Management needs to work with the Change Implementers to plan
--
The infrastructure is built on layers.
Hardware comes together to create physical systems.
Applications relies on the physical systems.
Business functions rely on groups of applications.
--
Availability is scalable – for a cost
Availability Management is responsible for finding the cost effective solution
.
Availability Management designs for cost effectiveness
Design for Availability and Recoverability
Cost Justified Availability
Not over designed and not under delivered
Built in, not added later
Small changes in thinking, not large change in technology
Better service
Continuous Process Improvement
Reactive becomes Proactive
--
Outages cost money
Tangible Costs = Directly attributed to the outage
Intangible Costs = Satisfaction, opportunity, confidence, etc.
.
Availability Management tools
CFIA = Component Failure Impact Assessment
FTA = Fault Tree Analysis
CRAMM = A security assessment technique
SOA = System Outage Analysis
Incident Lifecycle = analyze phases of IM
Continuous Improvement
TOP = Technical Observation Post
Availability Plan = Agreed goals for 6-months or more
--
More acronyms and vocabulary
Frequency of Failure = How often in a reporting period
Duration = Length of an outage
Impact of Failure = ITIL recommends (#Users) * (Duration)
SPOF = Single Point of Failure
Vulnerability = Susceptibility to an outage
High Availability = Masks the effect of a component failure
Continuous Operation = Minimize the effect of scheduled downtime
Continuous Availability = Masks ALL failures and maintenance
Scheduled Downtime, Planned Downtime, Maintenance Downtime
SMO = Service Maintenance Objective: total time unavailable
SIP = Service Improvement Program = A project
(The answers to this quiz are the first line in the Synopsis that follows.)
1. How is Configuration Management broader than Asset Management?
a. Configuration Management records the inventory.
b. Configuration Management measures system availability.
c. Configuration Management links the Configuration Items through relationships.
d. Configuration Management is responsible for managing incidents.
2. The Definitive Software Library should contain:
a. Copies of software so that users can check the reference manuals.
b. Copies of software so that Release Management can rebuild servers.
c. Copies of software so that Incident Management can resolve problems.
d. Copies of software so Availability Management can establish a configuration baseline.
3. Configuration Management can join with which other processes to form one organization:
a. Incident Management and Problem Management
b. Service Level Management and Availability Management
c. Restoration Management and Impact Analysis
d. Change Management and Release Management
4. A Configuration Management audit is:
a. Required by ITIL
b. A periodic verification of the configuration items
c. A periodic review of the availability metrics
d. Required when implementing Asset Management
5. Incident Management can assist Configuration Management by:
a. Looking up Configuration Items in the CMDB
b. Identifying errors in the CMDB
c. Reporting Problems so they can be resolved
6. ITIL suggests that Satisfaction is:
a. Expectation - Perception
b. User Expectation – Management Expectation
c. Provider Expectation – Management Expectation
7. Key Service Level Management agreements are:
a. Service Level Agreement, Operational Level Agreement, Availability Agreement
b. Service Level Agreement, Operational Level Agreement, Underpinning Contract
c. Service Level Agreement, Organizational Level Agreement, Vendor Business Agreement
d. Service Level Agreement, Organizational Level Agreement, Underpinning Contract
8. The metrics included in an SLA should always be:
a. Measurable and accurate
b. Measurable and achievable
c. Meaningful and as close to 100% as possible