Transcript Continual Service Improvement

Continual Service Improvement:
Why good enough, is NEVER good enough.
17 October 2008
Agenda
 9:30 – 9:45 – Introductions and Overview
 9:45 – 10:45 – Defining Continual Service Improvement
 10:45 – 11:00 Break
 11:00-12:00 – CSI Exercise
 12:00 – 12:30 – Review Exercise Results
What we will cover today
 Understanding of the key elements of a Continual Service





Improvement program
Simple approaches to beginning a program of your own
Common pitfalls when implementing a Service Improvement Program
Aligning with a formal “Quality” program (Six Sigma, TQM, TPS,
etc..)
Gathering the Voice of your Customer
Measuring the results of your program
What are Services?
 IT Service –
 “A service provided to one or more Customers by an IT Service Provider. An IT Service is based on the
use of Information Technology and supports the Customer’s Business Processes. An IT Service is made up
from a combination of People, Process and Technology and should be defined in a Service Level
Agreement”
 Business Service –
 “An IT Service that directly supports a Business Process, as opposed to an Infrastructure Service, which
is used internally by the IT Service Provider and is not usually visible to the Business”
 Infrastructure Service –
 “An IT Service that is not directly used by the Business, but is required by the IT Service Provider so
they can provide other IT Services. For example directory services, naming services, or communication
services.”
All definitions from: ITIL “Service Design” book © Crown Copyright 2007 (OCG)
A Service Centric Viewpoint
$ell Insurance
Market
Sell
Application1
Onboard
Business Process
Application3 Application4 Application3
IT Service 1
Infrastructure Infrastructure
Service 1
Service 2
CI1
CI 2
CI 3
CI4
IT Service 2
Infrastructure
Service 3
IT Service 3
Support
What is Continual Service Improvement?
 Aligning and realigning IT services to changing business needs
 The goal of Continual Service Improvement is to align and
realign IT Services to changing business needs by identifying and
implementing improvements to the IT services that support the
Business Processes.
 The perspective of CSI on improvement is the business
perspective of service quality, even though CSI aims to improve
process effectiveness, efficiency and cost effectiveness of the IT
processes through the whole lifecycle.
 In order to manage improvement, CSI should clearly define what
should be controlled and measured.
What is Continual Service Improvement?
What does ITIL say about CSI
 Focused on all aspects of the ITIL Core processes
 Applies to service improvement and process improvement for related
processes.
 Should be systematically applied throughout the entire Service
Lifecycle
 Identifies 3 metric types:
 Technology – (How is the technology performing – Monitoring, Uptime,
etc)
 Service – (How is the service performing relative to the needs of the
business)
 Process – (How is the process performing – Cycle Times, Customer
Satisfaction, etc)
7 Steps
Define what you should measure
 What should be measured based upon:





Business Requirements
Functional Requirements
Expected outcomes of Business Processes
Existing Service Improvement Plans
Defined Service/Process KPIs and Metrics
 Should provide a balanced View
 Qualitative - what does your customer think of the quality of the
product being delivered?
 Quantitative – What do your Technology and Process metrics tell
you about how your product is being delivered?
Define what you can measure
 What data is available to you?
 How are you going to collect that data?
 From an existing tool?
 From a new tool?
 Manually tallied?
 What if you can’t measure something?
 Establish a Data Capture Plan
 How are you going to get this data, and what gaps do you need to overcome if any?
 Determine which metrics are the most important.
 What is important to your customer and their business processes?
 What KPIs and Metrics align to the highest priority Business and
Functional Requirements?
Gather the data
 Gather all of your relevant data
 Execute your data capture plan
 Depending on whether your data is “Quick Turn” (lots of
transactions resulting in a large amount of data in a short period
of time) or “Slow Turn” (minimal transactions occurring over a
long period of time), combined with availability and quality of
your historical data will determine your sample data size and
time period.
Process the data
 Validate the data:
 Is the data what you expected?
 Is the quality of the data sufficient?
 Do all of the data sources validate one another?
 Ensure that all data is in a format that can be worked with while
analyzed.
Analyze the data
 Create reports that display the relevant data points.
 Be able to understand and articulate the meaning of data points,
and trend information.
 Understand any special cause data, which is outside the norms.
Present / Assess the data
 Identify opportunities to improve service based upon the
analyzed data
 Present the data and recommendations to key stakeholders /
decision makers
 Determine which Corrective actions should be taken (follow
standard release management planning and change management
processes)
Implement corrective actions
 Implement Corrective actions
 Execute according to standard Release and Change Management
processes.
Aligning your CSI Program to Other Quality Programs
 Most current quality programs have some basis on the Deming
Cycle (Plan – Do – Check – Act)
 W. Edward Deming






Born in 1900
Focused on Statistical Quality Control
Was instrumental in the 1940 U.S. Census
Demonstrated the link between training and product quality
After WWII worked with the Japanese to improve the quality of products
produced in Japan
Had two major area of Philosophy
o Fourteen Points
o Seven Deadly “Diseases”
Aligning your CSI Program to Other Quality Programs
 The Fourteen Points:
 Create constancy of purpose for improvement of product and service.
 Adopt the new philosophy.
 Cease dependence on mass inspection.
 End the practice of awarding business on price tag alone.
 Improve constantly and forever the system of production and service.
 Institute training.
 Institute leadership.
 Drive out fear.
 Break down barriers between staff areas.
 Eliminate slogans, exhortations, and targets for the workforce.
 Eliminate numerical quotas.
 Remove barriers to pride of workmanship.
 Institute a vigorous program of education and retraining.
 Take action to accomplish the transformation.
Aligning your CSI Program to Other Quality Programs
 The Seven Deadly Diseases
 Lack of constancy of purpose.
 Emphasis on short-term profits.
 Evaluation by performance, merit rating, or annual review of performance.
 Mobility of management.
 Running a company on visible figures alone.
 Excessive medical costs.
 Excessive costs of warranty, fueled by lawyers that work on contingency fee.
Aligning your CSI Program to Other Quality Programs
 Aligning CSI to a Six Sigma program:
 Goal of Six Sigma
 Systematically improve processes to increase efficiency and reduce process
defects
 Typically does well in a data rich environment
 Helps to objectively focus on the highest impact areas.
 DMAIC – (Define – Measure – Analyze – Improve – Control) is a
method employed by six sigma that aligns very well with the 7 Steps
recommended by CSI.
Aligning to CSI to Six Sigma (DMAIC)
1 - Define
what you
should
measure
2 - Define
what you
can
measure
3 - Gather
the Data
4 - Process
the data
6 – Present
/Assess the
data
5 - Analyze
the data
7Implement
Corrective
Actions
Key Process Elements
 Process Diagram Defines the inputs, outputs, providers, receivers, activities and critical
success factors of the process
 Benefits Explanation of the benefits you will receive from implementing this process.
 Controls By knowing the control objectives and being able to monitor and measure
performance of achieving those objectives, IT will be able to better manage and improve
operations, security and their audit processes. A control objective will define the enforcement
of a process and will avert high-risk activities.
 Goal Document the goal of the process. Make it SMART:
 Specific – your goal should have its expected outcome stated as simply, concisely and explicitly as




possible. This answers questions such as; how much, for whom, for what?
Measurable – a measurable goal has an outcome that can be assessed either on a sliding scale (1-10),
or as a hit or miss, success or failure.
Achievable – an achievable goal has an outcome that is realistic given your current situation, resources
and time available. Goal achievement may be more of a “stretch” if the outcome is tough or you have a
weak starting position.
Relevant – a relevant goal should help you on your mission.
Time-bound – a time-bound goal includes realistic timeframes.
Key Process Elements (Cont.)
 Metrics The metrics by which you will measure the success of your process





implementation. This page defines your Key Performance Indicators and
your Critical Success Factors.
Policies The management polices that will govern the use of this process and
all of its procedures.
Process Team The members of the process team and their contact
information.
Roles The process’ roles that will be involved with the process activities. HR
should be involved in the development, approval and assignment of all
process roles.
Scope Defines what the process covers (the extent and/or scale), the inputs,
the basic activities and the output, including the scope of responsibility of the
process owner.
Specification Summarization of the customizable process options and lists.
(ex. severity codes, closure codes, status codes, etc).
Process Diagram (Example: Incident)
Process Benefits (Example: Incident)
Benefit
Details
Quick restoration of service following an incident
Users’ service or business operation will be restored faster
Incidents are not lost or forgotten
All incidents are recorded and tracked
Current status of incidents is available
Status is available on for current open and recently closed
incidents
Reduces duplication of effort
It will be easily determined if an incident is currently being
worked and who is designated as the resource focal point
Clear view of status and priority of incidents
More effective management decisions can be made for
assignments and escalation when status of incidents and
committed available resources is known
Possible to measure performance and trends
Statistical analysis will be made possible by using common
records and formats and thereby providing the opportunity for
problem prevention
Increased end user satisfaction
Users will recover faster and their reported incidents will be
handled in accordance with applicable SLAs resulting in high
satisfaction with IT services
High impact, critical, or urgent incidents are prioritized according Impact, criticality, and urgency will be determined prior to
to the Service Level Agreements for that service or business
incident triage for assignment and escalation
operation
Productivity gain through high system availability
Business users will gain productivity from reduced down time
Management information related to Incidents is readily available Accurate MTTR and cost of outage or degradation incidents and
their recovery will be available for management decision
processes
Process Controls (Example: Incident)
Control
How control will be measured
Service Desk function will be established as the user interface
with IT to initiate service requests and information needs
Distribution of call types to service desk: information, request,
incident, etc.
Incidents will be classified according to committed Service Level % of incidents closed within SLA criteria
Agreements / Objectives and the Service Desk will monitor all
incidents through to their closure
Service Desk procedures will include escalation criteria and
% of incidents requiring escalation
communication procedures for incidents that cannot be resolved
according to limits set in their respective OLAs/SLAs, and/or if
% of incidents without suitable workarounds
appropriate workarounds are not available
Distribution of incidents by severity
Service Desk procedures for the timely monitoring and clearance % of unresolved incidents required to be forwarded to Problem
of customer queries will include resolution / closure and
Management.
confirmation steps to ensure that the action taken has been
agreed to by the customer
% of calls abandoned
Distribution of call answer times
% of calls cleared/closed during initial contact
Produce reports for the measurement of service performance
including response times and trends, to enable management to
make more informed tactical and strategic decisions governing
service support
% of customers satisfied that incident management activities met
or exceeded commitments made as part of the Service Level
Agreement
Process Goal (Example: Incident)
Goal
To restore normal service operation as quickly as possible as guided by the Service Level
Objectives and to minimize the adverse impact on business operations, thereby ensuring the best
possible level of service quality is achieved.
Process Metrics (Example: Incident)
CSF: Quickly resolve Incidents
KPI
Metric
Reduced response time
Percentage reduction in average time to respond to calls for assistance by Service
Desk Agents
Increased resolution by level 1 support
Percentage increase in number of Incidents resolved by Service Desk Agents
Increased first call resolution
Percentage increase in number of Incidents resolved by Service Desk Agents on first
response
Decreased inaccurate assignments
Percentage reduction of Incidents incorrectly assigned
Accurate categorization
Percentage reduction of Incidents incorrectly categorized
Meeting service level objectives
Increased percentage of Incidents resolved within SLA parameters
Decreasing MTTR
Reduced mean time to resolution of Incidents
CSF: Improve Business and IT Productivity
KPI
Metric
Reduced cost of incident response
Percentage reduction in average cost of handling Incidents
Increased first call resolution
Improve percentage of Incidents resolved by Service Desk Agents
Reporting on time
Elimination of delays in producing management reports
CSF: User Satisfaction
KPI
Metric
Increase in customer satisfaction
Improved scores on Customer Satisfaction Surveys
Process Policies (Example: Incident)
Policy
Detail
Purpose
Incident Ownership
The service desk will maintain ownership of all
reported Incidents and Service Requests throughout
their lifecycle, which includes monitoring, tracking
and invoking escalation procedures as necessary.
To ensure incidents are responded to in a
timely fashion and the appropriate
escalation procedures are triggered per
SLA commitments.
Incident Management Process
There will be one Incident Management Process
To provide definitive management of all IT
defined to provide IT related technical support and related events that disrupt normal
Service Request handling for all internal customers. operations.
Incident Supported Products
The Incident Management process will only be
To ensure resources are managed to meet
responsible to support standard hardware, software, agreed to business commitments and
and applications that have been approved for use
service level objectives.
within the IT infrastructure.
Incident Communication
The Incident Management Process will promptly
communicate any known or expected degradation of
service(s), as well as potential impact, to the
affected Customer community and IT support family
To ensure minimal disruption to business
operations and the assignment of
resources that is commensurate with
commitments and expectations.
Incident Escalation
There are defined assignment and escalation
models in place within the Incident Management
process to ensure timely resolution of incidents and
fulfillment of Service Requests. Assignment and
escalation occurs as defined in Service Level
Agreements or documented procedures.
The Service Level Agreements and the
process procedures will dictate escalation
and notification requirements so that
management is well informed as to the
progress and status on priority incidents.
Process Policies (Example: Incident)
Policy
Detail
Purpose
Incident Reporting, Recording, The Incident Management Process acts as the initial
and Resolution
point-of-contact for reporting, recording, and resolving
all IT related Incidents and Service Requests.
To ensure all reported Incidents and
Service Requests are recorded and
tracked through to an appropriate closure.
Incident Metric Reporting
Metrics will be collected to measure the effectiveness
and efficiency of the Incident Management process and
report to customers, management and specialty support
groups, as defined.
To meet management requirements of
process and procedures for the handling of
Incident and Service Requests, defined
metrics, targets, and the associated
attainment will be reported.
Incident Status Update
Status information on incidents will be made available to To let the customer and management know
customers throughout the Incident Management
the status of an Incident at any point during
Process lifecycle.
its active state
Incident Closure
Closure of an Incident or Service Request is dependent
on customer validation that service has been restored or
their request has been completed, or the Incident
Manager deems the incident/request to be closed.
Incident and Service Request records will be closed in
the IT Service Management tool when restoration of
service and customer validation has occurred.
To ensure incidents are closed in
accordance with agreed to process and
procedures as negotiated in the Service
Level Agreements.
Incident Management Priority
Support personnel must assess all Incidents and
Service Requests for impact to the business and
urgency to restore or provide a service. Assessing
impact and urgency thereby defines Priority.
Customers and users provide input into Priority
determination, which is defined by IT support staff using
the criteria within this Policy.
To follow pre-defined matrices and
guidelines for incident priority due to
potential or actual service or business
impact.
Process Team
Role
Process Owner
Process Manager
Name
Area/Division
Phone
E-mail
Process Roles (Example: Incident)
Role: Incident Process Owner
Attribute
Details
Role
Own and maintain the Incident Management process
Responsibilities
Document the process
Ensure proper staffing levels for execution
Ensure proper training for execution
Maintain the process
Manage the incident staff
Organizational Position
Manager
Skills
Manages people
Understands all ITSM processes
Verbal and written communication
Experience
Management
Process Design and architecture
Operations support
Process Scope (Example: Incident)

Incident Management is responsible for any reported event, by tool or user, which is not part of normal
operations that causes or may cause a disruption to or decrease in the quality of a service.
 The inputs to Incident Management are:
 Events
 Customer Contacts
 The outputs are:
 Restored service
 Requests for change
 Problem records
 Service Impact Measurements
 The major activities are:
 Detection and recording
 Classification and initial support
 Investigation and diagnosis
 Resolution and recovery
 Incident record administration and control
 Scope of activities for the Process Owner is to have the overall responsibility to ensure the process is both
suitable and relevant for the organization, for the continuous improvement of the process, and for keeping
this process guide current.
Where to start?
 Start small and gradually add complexity to your program:
 Focus on a handful of Highly Visible Services and Processes
 Don’t strive for perfection out of the gate
 Plan for a series of iterative improvements that keep the level of
change manageable for all stakeholders.
 Be sure that your release planning accounts for other initiative so as
not to stack too much change into a given period of time.
Measuring the Voice of your Customer
 There is only one person capable of the determining the quality
and value of your product:
 Your Customer
 Qualitative measure are typically gathered by surveying your
customers.
 A well developed survey can provide a tremendous amount of
good data for your Continual Service Improvement program.
Common Pitfalls
 Too much scope
 Don’t try to do everything in the book at once
 Balance strategic vision with tactical execution
 Be realistic about what can be achieved given the time and resources you
have available
 Striving for perfection on the initial release:
 Engineering in unnecessary complexity
 Introducing too much change at one time
 Plan for a series of iterative improvement releases that incrementally move
you to your ideal state.
 “Analysis Paralysis”
 It is very easy to get caught up in what the metrics say
 Don’t’ be afraid to make the best decision you can make even in light of
less than perfect data.
CSI Exercise
 Based on the following scenario, come up with a Service
Improvement Plan for the following service to include any
recommendations for process improvements for related
processes.
CSI Exercise (Scenario)






Employees of ACME products were having difficulty getting support for Incidents related to their Widget Scheduling
Service. Any time an Incident was reported, it typically took weeks to resolve regardless of the priority. During that time,
there was very little communication from IT regarding the status of the requests, and typically when the issue was
resolved they were only aware of it because they got a ticket closed notification.
In talking with the ACME IT Desktop support team, they claim that the reason why they take so long to resolve the
incidents is due to the fact that they have to work directly with the Widget Scheduling Service team to resolve all but the
most simple tasks, and that in many cases a temporary work around is put in place to get the customer working, only to
have the same problem repeat itself every few weeks.
A problem management ticket was opened and the findings indicated that the root cause was due to a Database locking
issue that the team has been aware since a previous release went in over 6 months ago. The Estimate from development is
that it would take Approx 80 hours of development time to develop, test and implement the fix. The reason why the issue
is more critical now, is that an additional 300 users were added to the system 90 days ago when they were migrated from
their old and beloved Access based scheduling system.
The next release is not scheduled until the end of the quarter which is still 6 weeks away. All of the development
resources who are capable of fixing this issue are currently 100% allocated to developing critical new functionality for the
next release of functions needed by the Marketing Team and claim that due to the needs of the business, they are unable to
dedicate any resources to fixing this issue until the new release is launched and stable.
Information from the Customer Satisfaction Surveys indicate that a growing number of users are increasingly dissatisfied
with not only the Service, but the IT team as a whole.
Business Management for the 300 users has expressed frustration with the IT Team, and also that he feels that because his
team is focused on Inventory Management and is not directly a revenue generating division, that his needs are largely
ignored. He has shared that for every hour of downtime that his users experience, he estimates that the company loses
$10, 000 in potential revenue due to unfilled orders at the regional distribution centers. (This information is based upon
a Six Sigma project from the prior fiscal year that was focused on improving Supply Chain Management).
CSI Exercise (Scenario Cont.)
 You are the Service Improvement Manager and a new
Improvement Opportunity has been brought to you as a result of
the previously mentioned Problem ticket.
 The Problem Manager has focused solely on the DB issues, but
knows that there is impact to the business because he carpools
with the Director of Inventory Management
 Your boss has cautioned you that this Marketing Release is a huge
priority for ACME and that for every day it is late, it will cost the
company $25,000 in lost revenue.
Assumptions
 Service Owner for Widget Scheduling is Wyle E. Carote a Senior
Manager in Application Development.
 The Initiative Owner is always the Service Improvement Manager
(Pick a representative from the group)
 Average fully burdened cost of an Hourly employee is $60 per hour.
 Service Level objectives for Incidents related to the WS Service are as
follows:
 Priority 1 – 4 Hours
 Priority 2 – 8 Hours
 Priority 3 – 3 Business Days
 Priority 4 – 5 Business Days
Service Evaluation

The following information is typically recorded within the Service Evaluation Report:




Name of the IT service under review
Date and time of the review
Person in charge of the review
Participants of the Service Review Meeting


Business and user representatives
Service provider representatives
Summary presentation of agreed vs. achieved service levels
Report on exceptional situations
 Satisfaction regarding service quality on the client-side





Compliments
Complaints
Areas which must be addressed by improvement initiatives (resulting in changes to the service and/ or to its underlying
processes, or to customer agreements)


From the customer viewpoint: New or changed requirements for the service

Changes in business processes or strategy which lead to new functional requirements

Changes in risk perceptions, priorities and criticalities which lead to changed Service Level Targets
 Anticipated changes in service consumption, short term as well as medium and long-term

Required short-term modifications (e.g. due to current/ recent problems)

Changed requirements with respect to service level reporting
From the IT viewpoint

Areas where service quality is to be improved

Conceivable cost-optimizations, e.g. by using new technologies or optimizing processes, or by influencing service demand
Service Improvement Plans
 The following information is typically contained within the Service
Improvement Plan:








For each defined initiative for process or service improvement:
Process or service concerned
Person in charge of the process (Process Owner) or service (Service Owner)
Initiative owner (person in charge of the initiative, often Service Management roles like e.g.
Service Level Manager, Capacity Manager, Availability Manager, Process Owner, Service
Owner)
Approval from senior management (initiative approved by …)
Description of the initiative
Source of the measure (e.g. Service Review, Process Audit)
Business case
 Expected outcome of the initiative
 Cost estimate
 Specific desired result of the initiative, e.g. a specific decrease in cost for providing a service
 Implementation schedule and status
 Target date
 Current status
CSI Exercise (Supporting Data – Cust Sat)
CSI Exercise (Cust Sat Comments)
 Joe in Desktop is Great!!
 I opened this ticket 3 weeks ago for a problem I had editing
inventory delivery schedules and was never called back. Today the
ticket is closed, and I can work again, but it would have been nice
to have been told something.
 It seems like every time I try to work in Widget Scheduling, I am
fine for a few days, then I am down again for a week or more.
When is someone going to fix this problem?
 We have the worst IT Department in the world.
 Joe in Desktop is Great!!!
CSI Exercise (Open Incidents by Service)
CSI Exercise (Service Levels Met By Service )
CSI Exercise (Downtime for WS Service by dept )
Review Exercise Results
 Pick a representative of the Group
 Describe how you approached the exercise
 Talk about your recommendations.
Recap
 Start simple and add complexity as you go
 Balance your strategic vision with your tactical outcomes
 Most quality programs come from the same foundational roots
 Continuous Service Improvement is a lifestyle not a journey.
 Be sure you are committed for the long haul.
 Be sure management is committed
 If you stand still, you will be left behind.
 In the long run, Good Enough is NEVER good enough.
Q&A
 Any questions?
 Comments?
 Areas of additional discussion?
Resources:
 Process Improvement
 http://www.gantthead.com/
 http://www.isixsigma.com/sixsigma/six_sigma.asp
 http://www.isixsigma.com/me/tqm/
 http://www.work911.com/tqmarticles.htm
 http://www.khosla.com/softwaremgmt/deming.htm
 ITIL and Six Sigma
 http://software.isixsigma.com/library/content/c080116a.asp
 http://www.eweek.com/c/a/IT-Management/How-to-Use-Six-
Sigma-to-Complement-ITIL-v3/
 Process
 http://www.pepperweedprocessmodel.com