3 What we will cover today Understanding of the key elements of a Continual Service Improvement programSimple approaches to beginning a program of your ownCommon pitfalls when implementing a Service Improvement ProgramAligning with a formal “Quality” program (Six Sigma, TQM, TPS, etc..)Gathering the Voice of your CustomerMeasuring the results of your program
5 A Service Centric Viewpoint $ell InsuranceMarketSellOnboardSupportApplication1Business ProcessApplication3Application4Application3IT Service 1IT Service 2IT Service 3InfrastructureService 1InfrastructureService 2InfrastructureService 3C I 1CI 2CI 3C I 4
6 What is Continual Service Improvement? Aligning and realigning IT services to changing business needsThe 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.
9 What does ITIL say about CSI Focused on all aspects of the ITIL Core processesApplies to service improvement and process improvement for related processes.Should be systematically applied throughout the entire Service LifecycleIdentifies 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 dataProcess the dataAnalyze the dataPresent/assess the dataImplement corrective actions
11 Define what you should measure What should be measured based upon:Business RequirementsFunctional RequirementsExpected outcomes of Business ProcessesExisting Service Improvement PlansDefined Service/Process KPIs and MetricsShould provide a balanced ViewQualitative - 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 PlanHow 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 planDepending 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 dataPresent the data and recommendations to key stakeholders / decision makersDetermine 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 DemingBorn in 1900Focused on Statistical Quality ControlWas instrumental in the 1940 U.S. CensusDemonstrated the link between training and product qualityAfter WWII worked with the Japanese to improve the quality of products produced in JapanHad two major area of PhilosophyFourteen PointsSeven 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 DiseasesLack 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 SigmaSystematically improve processes to increase efficiency and reduce process defectsTypically does well in a data rich environmentHelps 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) Define1 - Define what you should measure2 - Define what you can measureMeasure3 - Gather the DataAnalyze4 - Process the data5 - Analyze the dataImprove6 – Present /Assess the data7 - Implement Corrective ActionsControl
23 Key Process ElementsProcess Diagram Defines the inputs, outputs, providers, receivers, activities and critical success factors of the processBenefits 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).
26 Process Benefits (Example: Incident) DetailsQuick restoration of service following an incidentUsers’ service or business operation will be restored fasterIncidents are not lost or forgottenAll incidents are recorded and trackedCurrent status of incidents is availableStatus is available on for current open and recently closed incidentsReduces duplication of effortIt will be easily determined if an incident is currently being worked and who is designated as the resource focal pointClear view of status and priority of incidentsMore effective management decisions can be made for assignments and escalation when status of incidents and committed available resources is knownPossible to measure performance and trendsStatistical analysis will be made possible by using common records and formats and thereby providing the opportunity for problem preventionIncreased end user satisfactionUsers will recover faster and their reported incidents will be handled in accordance with applicable SLAs resulting in high satisfaction with IT servicesHigh impact, critical, or urgent incidents are prioritized according to the Service Level Agreements for that service or business operationImpact, criticality, and urgency will be determined prior to incident triage for assignment and escalationProductivity gain through high system availabilityBusiness users will gain productivity from reduced down timeManagement information related to Incidents is readily availableAccurate 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 measuredService Desk function will be established as the user interface with IT to initiate service requests and information needsDistribution 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 criteriaService 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 severityService 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 contactProduce 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 IncidentsKPIMetricReduced response timePercentage reduction in average time to respond to calls for assistance by Service Desk AgentsIncreased resolution by level 1 supportPercentage increase in number of Incidents resolved by Service Desk AgentsIncreased first call resolutionPercentage increase in number of Incidents resolved by Service Desk Agents on first responseDecreased inaccurate assignmentsPercentage reduction of Incidents incorrectly assignedAccurate categorizationPercentage reduction of Incidents incorrectly categorizedMeeting service level objectivesIncreased percentage of Incidents resolved within SLA parametersDecreasing MTTRReduced mean time to resolution of IncidentsCSF: Improve Business and IT ProductivityKPIMetricReduced cost of incident responsePercentage reduction in average cost of handling IncidentsIncreased first call resolutionImprove percentage of Incidents resolved by Service Desk AgentsReporting on timeElimination of delays in producing management reportsCSF: User SatisfactionKPIMetricIncrease in customer satisfactionImproved scores on Customer Satisfaction Surveys
30 Process Policies (Example: Incident) PolicyDetailPurposeIncident OwnershipThe 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 ProcessThere 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 ProductsThe 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 CommunicationThe 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 familyTo ensure minimal disruption to business operations and the assignment of resources that is commensurate with commitments and expectations.Incident EscalationThere 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) PolicyDetailPurposeIncident Reporting, Recording, and ResolutionThe 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 ReportingMetrics 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 UpdateStatus 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 stateIncident ClosureClosure 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 PrioritySupport 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 OwnerAttributeDetailsRoleOwn and maintain the Incident Management processResponsibilitiesDocument the process Ensure proper staffing levels for execution Ensure proper training for execution Maintain the process Manage the incident staffOrganizational PositionManagerSkillsManages people Understands all ITSM processes Verbal and written communicationExperienceManagement 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:EventsCustomer ContactsThe outputs are:Restored serviceRequests for changeProblem recordsService Impact MeasurementsThe major activities are:Detection and recordingClassification and initial supportInvestigation and diagnosisResolution and recoveryIncident record administration and controlScope 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 ProcessesDon’t strive for perfection out of the gatePlan 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 CustomerQualitative 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 onceBalance strategic vision with tactical executionBe realistic about what can be achieved given the time and resources you have availableStriving for perfection on the initial release:Engineering in unnecessary complexityIntroducing too much change at one timePlan 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 sayDon’t’ be afraid to make the best decision you can make even in light of less than perfect data.
38 CSI ExerciseBased 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 ManagementYour 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 AssumptionsService 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 HoursPriority 2 – 8 HoursPriority 3 – 3 Business DaysPriority 4 – 5 Business Days
42 Service EvaluationThe following information is typically recorded within the Service Evaluation Report:Name of the IT service under reviewDate and time of the reviewPerson in charge of the reviewParticipants of the Service Review MeetingBusiness and user representativesService provider representativesSummary presentation of agreed vs. achieved service levelsReport on exceptional situationsSatisfaction regarding service quality on the client-sideComplimentsComplaintsAreas 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 serviceChanges in business processes or strategy which lead to new functional requirementsChanges in risk perceptions, priorities and criticalities which lead to changed Service Level TargetsAnticipated changes in service consumption, short term as well as medium and long-termRequired short-term modifications (e.g. due to current/ recent problems)Changed requirements with respect to service level reportingFrom the IT viewpointAreas where service quality is to be improvedConceivable 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 concernedPerson 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 initiativeSource of the measure (e.g. Service Review, Process Audit)Business caseExpected outcome of the initiativeCost estimateSpecific desired result of the initiative, e.g. a specific decrease in cost for providing a serviceImplementation schedule and statusTarget dateCurrent status
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!!!
48 CSI Exercise (Downtime for WS Service by dept )
49 Review Exercise Results Pick a representative of the GroupDescribe how you approached the exerciseTalk about your recommendations.
50 Recap Start simple and add complexity as you go Balance your strategic vision with your tactical outcomesMost quality programs come from the same foundational rootsContinuous Service Improvement is a lifestyle not a journey.Be sure you are committed for the long haul.Be sure management is committedIf you stand still, you will be left behind.In the long run, Good Enough is NEVER good enough.
51 Q&AAny questions?Comments?Areas of additional discussion?
52 Resources: Process Improvement ITIL and Six Sigma Process ITIL and Six SigmaSigma-to-Complement-ITIL-v3/Process
Your consent to our cookies if you continue to use this website.