Presentation is loading. Please wait.

Presentation is loading. Please wait.

Why good enough, is NEVER good enough.

Similar presentations

Presentation on theme: "Why good enough, is NEVER good enough."— Presentation transcript:

1 Why good enough, is NEVER good enough.
Continual Service Improvement: Why good enough, is NEVER good enough. 17 October 2008

2 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

3 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

4 What are Services? IT Service – Business 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)

5 A Service Centric Viewpoint
$ell Insurance Market Sell Onboard Support Application1 Business Process Application3 Application4 Application3 IT Service 1 IT Service 2 IT Service 3 Infrastructure Service 1 Infrastructure Service 2 Infrastructure Service 3 C I 1 CI 2 CI 3 C I 4

6 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.

7 What is Continual Service Improvement?


9 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)

10 7 Steps Define what you should measure Define what you can measure
Gather the data Process the data Analyze the data Present/assess the data Implement corrective actions

11 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?

12 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?

13 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.

14 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.

15 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.

16 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)

17 Implement corrective actions
Execute according to standard Release and Change Management processes.

18 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 Fourteen Points Seven Deadly “Diseases”

19 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.

20 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.

21 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.

22 Aligning to CSI to Six Sigma (DMAIC)
Define 1 - Define what you should measure 2 - Define what you can measure Measure 3 - Gather the Data Analyze 4 - Process the data 5 - Analyze the data Improve 6 – Present /Assess the data 7 - Implement Corrective Actions Control

23 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.

24 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).

25 Process Diagram (Example: Incident)

26 Process Benefits (Example: Incident)
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 to the Service Level Agreements for that service or business operation Impact, criticality, and urgency will be determined prior to incident triage for assignment and escalation 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

27 Process Controls (Example: Incident)
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 Agreements / Objectives and the Service Desk will monitor all incidents through to their closure % of incidents closed within SLA criteria Service Desk procedures will include escalation criteria and communication procedures for incidents that cannot be resolved according to limits set in their respective OLAs/SLAs, and/or if appropriate workarounds are not available % of incidents requiring escalation  % of incidents without suitable workarounds  Distribution of incidents by severity Service Desk procedures for the timely monitoring and clearance of customer queries will include resolution / closure and confirmation steps to ensure that the action taken has been agreed to by the customer % of unresolved incidents required to be forwarded to Problem Management.  % 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

28 Process Goal (Example: Incident)
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.

29 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

30 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 defined to provide IT related technical support and Service Request handling for all internal customers. To provide definitive management of all IT related events that disrupt normal operations. Incident Supported Products The Incident Management process will only be responsible to support standard hardware, software, and applications that have been approved for use within the IT infrastructure. To ensure resources are managed to meet agreed to business commitments and service level objectives. 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.

31 Process Policies (Example: Incident)
Policy Detail Purpose Incident Reporting, Recording, and Resolution The Incident Management Process acts as the initial 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 customers throughout the Incident Management Process lifecycle. To let the customer and management know the status of an Incident at any point during 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.

32 Process Team Role Name Area/Division Phone E-mail Process Owner
Process Manager

33 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

34 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.

35 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.

36 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.

37 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.

38 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.

39 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).

40 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.

41 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

42 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

43 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

44 CSI Exercise (Supporting Data – Cust Sat)

45 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!!!

46 CSI Exercise (Open Incidents by Service)

47 CSI Exercise (Service Levels Met By Service )

48 CSI Exercise (Downtime for WS Service by dept )

49 Review Exercise Results
Pick a representative of the Group Describe how you approached the exercise Talk about your recommendations.

50 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.

51 Q&A Any questions? Comments? Areas of additional discussion?

52 Resources: Process Improvement ITIL and Six Sigma Process
ITIL and Six Sigma Sigma-to-Complement-ITIL-v3/ Process

Download ppt "Why good enough, is NEVER good enough."

Similar presentations

Ads by Google