itSMF Finland Conference 2015It Feels Good!
Phil GreenIn God We Trust Everyone Else Bring Data
When people are pressured to meet a target value, how might they proceed?1
They can work to improve the system
They can distort the system
They can distort the data
1 Brian Joiner, Fourth Generation Management, McGraw-Hill
These are examples of a small number of data points or observations without proper context.
February deficit 1.4 billion larger than January things are worse!February deficit 1.6 billion smaller than previous February things are better!2
The table tops do not look alike but they are!1 Good or bad?
1 - Source: Roger N Shepard, Mind Sights: Original Visual Illusions, Ambiguities and Other Anomalies, WH Freeman and Company2 - Derived from Understanding Variation: The Key to Managing Chaos, Donald J. Wheeler, SPC Press Inc.
Things arent always what they seem!
INVENTORY IN DEPARTMENT 50A Case in Point
Derived from Understanding Variation: The Key to Managing Chaos, Donald J. Wheeler, SPC Press Inc.
Inventory in has fallen to the lowest level recorded in three years!
The Manager rewards everyone with a celebration!
But then inventory rises again
The Manager regrets giving the award time to have a serious talk with the team!
Inventory levels fall again
The Manager thinks tough talk gets results!
But then inventory rises to the highest level recorded in two years!
Manager throws a tantrum, demands improvement plans.The team keep a low profile, hoping things get better, hiding inventory in dark corners, under their desks, etc.
And once again Inventory falls
Once again, the manager thinks tough talk works!
But then inventory rises yet again
And around and around we go. Lather, rinse, repeat!
So what went wrong?
Award Given
Team needs talking to!
Tough talking works!
Tantrum!
Theyre finally getting the message!
Here we go again!
Weve been reacting to data points, comparing numbers to specifications the Voice of the Customer (VoC) which hasnt worked.To understand, we need to listen to the Voice of the Process (VoP)
VoP The Control Chart Approach
CL
LCL
UCL
So what is wrong with this process?Statistically, nothing! The process is in control not one of the data points is a signal to be concerned about.The process shows only common cause variationA change in process requires a structured improvement such as Plan-Do-Check-Act (PDCA), not reacting to normal data points (known as tampering!)
Anything noticeable here?
A signal an assignable cause
And here?
A set of consecutive points below the centre line.A change in the process has occurred
Control Limits can be changed
Centre line has movedProcess variation has been reduced
What have we learned? Without proper context, data is meaningless! Comparing data points to specifications (VoC)
and reacting is merely tampering and wont drive sustainable improvement
The VoC defines what you want from a system, whereas the VoP defines what you will actually get
A control chart will shows us the VoP The VoP will filter out the noise (common
cause variation) so we can clearly see the signals (assignable cause variation)
A SUMMARY OF THE THEORYSix Sigma Overview
Introduction to Six Sigma Pioneered by Motorola in the
1980s, providing $16 Billion in savings
Widespread adoption since, e.g., GE, Ford, Honeywell, GSK, Nokia
Proven to yield dramatic improvements in business results
Lean (Six) Sigma drives process improvement by reducing waste
Six Sigma drives improvement by reducing variation
Variation why does it bother us?Some things varying can be ok, but not others: Quality of food or service at your
favourite restaurant? Unreliable buses or trains? Call wait time telephoning your bank? Produce freshness at the food store? Cycle time from order to delivery of
items needed to manufacture goods?
Sigma as a Quality MeasureDPMO = defects per million opportunities for errorA Case in Point: Concert tickets printed
5 opportunities for error (venue, date, act, time, seat)
1000 tickets issued, 50 defects DPO = 50/(5 x 1000) = 0.01 Yield = (1 - 0.01) x 100 = 99% DPMO = 0.01 x 106 = 10,000 (3.8 achieved1)
Rule of thumb: You need 4 or higher to satisfy most customers2
1 Research has shown that the centre of a processes can naturally shift over time by up to 1.52 Joe Parito, iSixSigma
Control Chart Basics Centre line is the arithmetic mean of
the data points Limits are 3 (3 standard
deviations1) either side of CL UCL/LCL are not specification limits The Empirical Rule
About 60-75% of the data points will be 1 from the CL
About 90-98% of the data points will be 2 from the CL
About 99-100% of the data points will be 3 from the CL
Control limit calculations:
1 Standard deviation = mean of (variation of each point from CL)2
Upper Control Limit (UCL)
Lower Control Limit (LCL)
Centre Line (CL)
Assignable Cause Area
Assignable Cause Area
Voice of the Customer
Voice of the Process
Control Chart: Case In Point Example
0
10
20
30
40
50
60
70
80
90
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
UCL = 88.3
LCL = 32.2
CL = 60.3
Looking for Assignable Causes
One or more points outside the control limits
Looking for Assignable Causes
Eight or more consecutive points the same side of the Centre Line
Looking for Assignable Causes
Sixteen points alternating up and down (rare)Other repeating patterns should also be investigatedA rule of thumb: a pattern repeating 8 times
Learning Models DMAIC & DMADV
DMADV is also known as Design for Six SigmaThis presentation will discuss the DMAIC model.
The DMAIC Improvement Cycle Define articulate the problem quantifiably, the
underlying process and the goal for improvement. Measure collect data to establish current baseline,
and to identify & monitor the gap between current and required performance.
Analyze identify and prioritise potential root causes for elimination to close the gap. Use statistical tools to guide the analysis.
Improve identify and implement (creative) solutions; use statistical methods to validate the improvement.
Control identify and implement sustainment strategies that ensure the improvement is embedded and sustainable.
Tools & Techniques
Analyse
Select Priorities: Affinity Diagrams System / Process Map Benchmarking Project Charter Pareto
Learn About Process: Run Chart Process Map (e.g., flow chart) Histogram SIPOC VoC tools (surveys, focus
groups, etc.)
Investigate Sources of Variation: Run Chart Ishikawa Diagram Pareto Scatter
Test Theories: Ishikawa Diagram Process Maps Control Charts / SPC Brainstorming Matrix Design of Experiments Simulations
Study Results: Control Charts /
SPC Pareto FMEA
Implement: Proto type / Pilot studies Gantt Chart Matrix
Standardise: Control Chart /
SPC FMEA Reporting
Systems
SERVICE OPERATIONS CASE STUDYIncident Resolution Improvements Application Support Service
DMAIC Define StageSelect Priorities Shared Application Support Service Several hundred applications,
supporting 90K+ business users across 100+ countries
Target agreed with business to drive incident resolution 90th percentile down to 40 hours or below.
Learn About Process Baseline compliance to incident
resolution target 79% Baseline 90th percentile 263 hours
SIPOC
Project Title: Incident Resolution 90th Percentile Reduction
Project Leader: Phil Green
Suppliers:
Users (incident details)
IT Help Desk
Offshore Suppliers
Inputs
User supplier information
Remedy Incident ticket
Open Problem tickets
IT Knowledge base
Process:
Resolution of Service Incidents
Owner:
Phil Green, Service Owner
Purpose:
To resolve service incidents for supported applications in a consistent, satisfactory and timely manner.
Outputs:
Resolution provided to customer
Remedy ticket closed
Communication to Problem Mgmt on underlying issues
Customers:
Primary:
BU IT Service Owners
Secondary:
Users (of the process)
BU & IT Management
Process Steps:
(Help Desk resolves incident or forwards to a Resolving Agency) (Business user experiences an IT incident) (Business user submits Incident ticket (e.g., on self-help portal or calling help desk)) (Ticket closed) (Resolving Agency resolves Incident) (Resolving Agency responds to Incident)
Results Measures:
Percentage of incidents resolved within SLA
Incident Resolution time 90th Percentile
Customer Needs:
1. Fast response to Incidents raised
2. Incidents resolved to customer satisfaction
3. Incidents resolved with a sense of urgency
4. Frequent, courteous communication throughout process
Process Measures:
Incident Response time; Incident Resolution time (measured from time ticket reaches RA through to resolve time).
Present Data:
263 hours to resolve 90% of Incident tickets.
Opportunities for Improvement
Improve IT Knowledge Base (especially during Transition and 1st 3 months of early life support)
Better policy/usage of Resolving Agencies
Improve notifications prior to tickets breaching SLA
Work with Help Desk and Service Owners to eliminate opportunities for ticket misrouting
Improve / accelerate Problem Management capability, especially during early life support
Improved reporting capability (e.g. mechanism to exclude apps in transition from resolution metric)
Goal Performance:
Resolve 90% of all Incident tickets within 40 hours for all supported applications that have been in steady state for three months or greater.
Sources of Variation
Portfolio of supported applications continually expanding; skills/capabilities of support analysts; gaps in application knowledge base; tickets misrouted by Help Desk; sharing of RA with non-supported apps; user not available to progress; incorrect sense of urgency during resolution; changes releasing bugs into Production; changes in customer demand; non-compliance with correct process.
Impact on Performance:
Incident not resolved within required SLA escalating impact; dissatisfied customers.
DMAIC Measure StageInvestigate Sources of VariationTechniques selected
Brainstorming Cause & Effect (Ishikawa) diagram Pareto charts
Cause & Effect (Ishikawa) Diagram
Sheet1
Effect: Variation in Incident Resolution Times
Tools
Process
Measurement
Help Desk
Customers
People (RA)
RFCs logged as Incidents
Service Requests logged as Incidents
Incorrect handling of 'hold' times
Unable to measure at source (Remedy)
Incorrect SLA being followed
Sharing of RAs
Incorrect case_type usage
Gaps in IT Knowedgebase
Incorrect urgency to response
Incorrect urgency to resolve
Changes processed as Incidents
Different resolutionprocesses in use
Incidents not in Remedy
No oversight of ticket queue
Too many lowpriority tickets
Processing RFCs as incidents
Incorrect downgradingof priority
Not following correct resolutionsteps per good ITSM practice
Insufficient senseof urgency
Incomplete knowledgetransition to offshore
Using support throughinformal channels
User not available to progress ticket
User not available to confirm resolution
Change in customer demand (service growth)
Assigning ticket to wrong RA
Taking too long to assignticket to an RA
Setting incorrectticket priority
Not logging ticket in Remedy when contacted informally
Sheet2
Sheet3
Pareto Chart
DMAIC Analyse StageForm & Test TheoriesNot following good ITSM practice
Closing incidents on the basis that a corresponding Problem record was raised
Incorrect hold times calculations Clock was being stopped
Changes logged as Incidents! Categorisations in system not clear
Root Causes Selected to Address
Sheet1
Effect: Variation in Incident Resolution Times
Measurement
Help Desk
Customers
People (RA)
RFCs logged as Incidents
Incorrect handling of 'hold' times
Incorrect SLA being followed
Not following correct resolutionsteps per good ITSM practice
User not available to progress ticket
Assigning our tickets toanother group's RA
Sheet2
Sheet3
DMAIC Improve StageImplement Re-training in good ITSM practice Change on hold time calculations System usability adjustmentsStudy Results Incident resolution control chart 90th percentile control chart Reactivation rates control chart
(Balancing measure)
Incident Resolution Control Chart
UCL=13.068
LCL=0.0
CEN=4.0
UCL=7.9341
LCL=0.0
CEN=2.4286
-4-202468
101214
Jun-06 Jul-06 Aug-06 Sep-06 Oct-06 Nov-06 Dec-06 Jan-07 Feb-07 Mar-07 Apr-07 May-07 Jun-07 Jul-07 Aug-07 Sep-07 Oct-07 Nov-07
Moving R Chart
UCL=89.973
LCL=68.693
CEN=79.333
UCL=97.26
LCL=84.34
CEN=90.8
65
70
75
80
85
90
95
100
105Jun-06 Jul-06 Aug-06 Sep-06 Oct-06 Nov-06 Dec-06 Jan-07 Feb-07 Mar-07 Apr-07 May-07 Jun-07 Jul-07 Aug-07 Sep-07 Oct-07 Nov-07
Percent Incidents Resolved in SLA
Signal: 8 consecutive points above CL
Control Chart Limits Re-drawn
UCL=89.973
LCL=68.693
CEN=79.333
UCL=98.881
LCL=80.261
CEN=89.571
UCL=95.295
LCL=88.455CEN=91.875
65
70
75
80
85
90
95
100
105Jun-06 Jul-06 Aug-06 Sep-06 Oct-06 Nov-06 Dec-06 Jan-07 Feb-07 Mar-07 Apr-07 May-07 Jun-07 Jul-07 Aug-07 Sep-07 Oct-07 Nov-07
Percent Incidents Resolved in SLA
UCL=13.068
LCL=0.0
CEN=4.0
UCL=11.435
LCL=0.0
CEN=3.5 UCL=4.2004
LCL=0.0CEN=1.2857
-4-202468
101214
Jun-06 Jul-06 Aug-06 Sep-06 Oct-06 Nov-06 Dec-06 Jan-07 Feb-07 Mar-07 Apr-07 May-07 Jun-07 Jul-07 Aug-07 Sep-07 Oct-07 Nov-07
Moving R Chart
90th Percentile Control Chart
Reactivation Rates Control Chart
DMAIC Control StageImprovements 90th percentile improved 82% from 263 to 45 hrs Incident Resolution SLT compliance raised from
79% to 92% Reactivation Rates reduced from 8% to 3%
Sustainment Actions New practices formalised within procedures,
knowledge base, training materials, etc. Training and communication ITSM tool changes made permanent
Additional ResourcesLinkedIn GroupsLean Six Sigma (and sub-groups)Lean Six Sigma Worldwide
Computing ResourcesSPC XL Software (Excel plug-in, Windows only)QI Macros (SPC & Statistical software for Mac)Excel (calculates mean and standard deviation)Graphical CalculatorsUseful Websites
http://www.isixsigma.com http://iso-qms.blogspot.com.au http://statstuff.com http://www.qualitydigest.com/sixsigma/index.lasso
Training/Certifications http://www.processexcellencenetwork.com/lean/videos/online-six-sigma-training-with-pex-
institute/ http://www.6sigmastudy.com http://www.lsssp.org
Books Donald J Wheeler, Understanding Variation, The Key to Managing Chaos, SPC Press Thomas Pyzdek, The Six Sigma Handbook, McGraw-Hill George/Rowlands/Price/Maxey, The Lean Six Sigma Pocket Toolbook, McGraw-Hill Quentin Brook, Lean Six Sigma and Minitab: The Complete Toolbox Guide for All Lean Six Sigma
Practitioners, OPEX Resources http://www.spcpress.com/index.php
http://www.isixsigma.comhttp://iso-qms.blogspot.com.auhttp://statstuff.comhttp://www.qualitydigest.com/sixsigma/index.lassohttp://www.processexcellencenetwork.com/lean/videos/online-six-sigma-training-with-pex-institute/http://www.6sigmastudy.comhttp://www.lsssp.orghttp://www.spcpress.com/index.php
Questions?
Phil GreenDirector, G3 Service Solutions LimitedEmail: [email protected]: www.linkedin.com/in/philxgreen
mailto:[email protected]?subject=itSMF%20Finlandhttp://www.linkedin.com/in/philxgreen
Thank You!
Slide Number 1When people are pressured to meet a target value, how might they proceed?1Things arent always what they seem!Inventory in Department 50Inventory in has fallen to the lowest level recorded in three years!But then inventory rises againInventory levels fall againBut then inventory rises to the highest level recorded in two years!And once again Inventory fallsBut then inventory rises yet againSo what went wrong?VoP The Control Chart ApproachAnything noticeable here?And here?Control Limits can be changedWhat have we learned?A Summary of the theoryIntroduction to Six SigmaVariation why does it bother us?Sigma as a Quality MeasureControl Chart BasicsControl Chart: Case In Point ExampleLooking for Assignable CausesLooking for Assignable CausesLooking for Assignable CausesLearning Models DMAIC & DMADVThe DMAIC Improvement CycleTools & TechniquesService Operations Case StudyDMAIC Define StageSIPOCDMAIC Measure StageCause & Effect (Ishikawa) DiagramPareto ChartDMAIC Analyse StageRoot Causes Selected to AddressDMAIC Improve StageIncident Resolution Control ChartControl Chart Limits Re-drawn90th Percentile Control ChartReactivation Rates Control ChartDMAIC Control StageAdditional ResourcesQuestions?Slide Number 45