Read an Excerpt
The Lean Six Sigma Pocket Toolbook
A Quick Reference Guide to Nearly 100 Tools for Improving Process Quality, Speed, and Complexity
By Michael L. George David Rowlands Mark Price John Maxey
McGraw-Hill
Copyright © 2005 George Group
All right reserved.
ISBN: 978-0-07-150573-4
Chapter One
Using DMAIC to Improve Speed, Quality, and Cost
DMAIC (pronounced "Duh-MAY-ick") is a structured problem-solving methodology widely used in business. The letters are an acronym for the five phases of Six Sigma improvement: Define-Measure-Analyze-Improve-Control. These phases lead a team logically from defining a problem through implementing solutions linked to underlying causes, and establishing best practices to make sure the solutions stay in place.
When to use DMAIC
The structure of DMAIC encourages creative thinking within boundaries such as keeping the basic process, product, or service. If your process is so badly broken that you need to start over from scratch or if you're designing a new product, service, or process, use Design for Lean Six Sigma (DMEDI), not covered in this book.
Selecting DMAIC projects
This book assumes that most readers will work on DMAIC projects selected for them by managers or sponsors. (If this is not the case and you are involved in the project selection process, see p. 26 at the end of this chapter for a quick overview.
Implementation Options for DMAIC
There are two primary options for implementing DMAIC:
1) Project-team approach
Black Belts deployed full-time to projects
Team members work on the project part-time—work on the project is interspersed with regular work
Full involvement by all team members in all phases of DMAIC
Duration can be 1 to 4 months depending on scope (some go longer; shorter is better because you can realize gains more quickly)
2) Kaizen approach
Rapid (1 week or less), intense progress through all of DMAIC except full-scale implementation
Preparatory work on Define, and sometimes on Measure, done by a subgroup (team leader and a Black Belt, for instance)
Rest of the work done by the full group during several days or a week when they work ONLY on the project (participants are pulled off their regular jobs)
The basic DMAIC steps (pp. 4 to 19) apply to both of these models. Additional guidance on conducting a Kaizen project is provided on pp. 20 to 25.
"Do we have to follow all of DMAIC?"
DMAIC is a valuable tool that helps people find permanent solutions to longstanding or tricky business problems. The basic framework works well in a wide variety of situations, but using DMAIC does involve time and expense. So you should weigh the costs of using DMAIC against the benefits and the costs of skipping some steps or jumping right into solutions. Two indicators that you should follow all of DMAIC:
1) The problem is complex. In complex problems, the causes and solutions are not obvious. To get at the root of a complex problem, you need to bring together people with different areas of knowledge or experience. You may have to gather lots of different data before you discover patterns that provide clues about the causes.
If you have a simple problem (or one you think is simple), often an experienced person can gather and analyze data and find a solution without going through all of the DMAIC steps.
2) The solution risks are high. A key part of the DMAIC methodology is developing, testing, and refining solution ideas before you impose them on the workplace and on customers. So you should use DMAIC any time the risks of implementation are high, even if you think a solution is obvious. However, if you've stumbled on an obvious problem and the risks of implementing the solution are minor—meaning little disruption to the process, little or no impact on customers, little cost—go ahead and try it out (using proper "solution implementation" procedures, see Chapter 11).
For most projects, it's risky to skip any DMAIC steps. The logic that links the DMAIC phases is key to success. But we recognize that it is human nature to want to jump to solutions and quickly make the improvement.
If you think you have an obvious solution with minimal risks, you can try skipping some of the DMAIC steps. But before you do so, ask:
What data do I have to show that this idea is the best possible solution?
How do I know that the solution will really solve the targeted problem?
What possible downsides are there to the solution idea?
If you can't provide data to support your answers to these questions, you need to work through all the DMAIC phases.
If you want to skip steps, see p. 152 for guidelines on how to test obvious solutions
If you encounter problems with an "obvious solution to a simple problem" and cannot prove with data that the situation has improved, be prepared to launch a full DMAIC project
Define
Purpose
To have the team and its sponsor reach agreement on the scope, goals, and financial and performance targets for the project
What you need before you start
First draft of project charter from sponsor(s)
Resource allocation (time of team members, initial budget)
Deliverables
1. A completed project charter (covering the problem statement, business impact, goals, scope, timeline, defined team)
2. Documentation showing what customers (internal and external) are or will be affected by this project and what their needs are
3. High-level process map(s), at least a SIPOC diagram, p. 38
4. Completed project plans. Requirements will vary by company but often include Gantt charts; stakeholder analysis; resistance analysis; risk analysis; action logs, responsibility assignments, and communication plans (not covered in this book)
5. Outcomes from the project launch meeting showing team consensus around project purpose, charter, deliverables, and team responsibilities
Key steps in Define
Note: Some companies have the full team do all of this work. Others have the Black Belts do some or all of the background work before bringing together the team. Do what makes sense for your situation.
1. Review project charter. Have your team discuss the draft charter from sponsors. Get answers to questions. Negotiate compromises or adjustments to scope, resources, timing, team membership as needed.
2. Validate problem statement and goals. Review existing data or other sources of information to confirm that the problem you've been given ...
Exists
Is important to customers (collect the Voice of the Customer)
Is important to the business (collect Voice of the Business information)
Can reasonably be expected to be improved using Lean Six Sigma (DMAIC) methodologies
3. Validate financial benefits. Use existing data to calculate current costs, profits, margins, or other financial metrics relevant to your project. Estimate the financial impact if you achieve the project goal, and verify that it meets management expectations.
4. Create/validate process map and scope. Document the main steps of the process (with a SIPOC diagram, p. 38) to verify project scope; see if data exists to provide baseline measures on time, defects/errors, rework, etc., for a value stream map.
5. Create communication plan. Identify project participants and stakeholders (sponsors, customers, managers, process operators, etc.) and develop plans for keeping them informed about and/or involved in the project.
6. Develop project plans (schedule, budget, milestones).
7. Complete the Define gate review.
Gate review checklist for Define
A. An updated Project Charter
Problem Statement detailing when the problem has been seen, what the problem is, the magnitude of the problem, and the impact or consequence of the problem (such as effect on customer Critical-to-Quality expectations). Make sure the problem statement focuses on symptoms only (not on causes or solutions).
Key stakeholders: Who are they? How will they be involved in the project? How will progress be communicated to them?
Business Impact reflecting expected financial benefits and assumptions.
Goal Statement clearly identifying the key output metric (Y) to be improved.
Verification of Project Scope: broad enough to achieve the project objectives yet narrow enough to be completed within the Project Plan timeframe.
High-level Project Plan showing the targeted completion date for the project and intermediate milestones.
List of team members representing key stakeholders, appropriate mix of skills, and knowledge (especially about the current process).
B. Documentation on your customer knowledge
Primary external and internal customers identified
Voice of the Customer gathered
Customer needs evaluated for priority and importance (through Kano analysis, p. 64, for example)
Ability to measure customer requirements
C. A high-level process map and/or SIPOC diagram (p. 38)
High-level map showing major steps or activities (details will come in Measure)
SIPOC map completed to identify key Suppliers, Inputs, Process boundaries, Outputs, Customers (should demonstrate that the process boundaries align with the project goals)
Key process output variables (KPOVs) such as time, quality, and cost metrics (to show process links to project goals)
Optional: Key data on time, delays, queues, defects, etc. (see p. 47)—if you don't gather these data here, you'll be collecting them in Measure
D. Detailed Project Management plans
More detailed schedule of activities, especially for Measure (using a Gantt chart, for example)
List of stakeholders who will be impacted by the project, and their expectations and concerns
Communications Plan for the identified stakeholders and their concerns
Risk management plans
Identification of barriers/obstacles that could hinder the team (will likely require help from the Black Belt and sponsors to overcome these barriers)
Tips for Define
If you have to spend longer than one to two days (full time) or one to two weeks (part time) in Define, that's an indication that the scope may be too broad or too vague. Talk to your manager or sponsor to see if you can rescope the project (choose a narrower topic), divide the project into phases, or adjust team membership to give you the knowledge/resources needed to complete the task.
Speed up DMAIC by doing Define as mini-Kaizen event, where people come together for a half- or full-day session and complete all the required work (no disruptions allowed). Post documents on the wall as you work so you can update your sponsor at the end of the meeting.
Do a thorough job of capturing customer needs as that can reveal important critical inputs (Xs).
Make sure the team is well balanced. Try to include team members from areas both upstream and downstream from the process that's being studied.
– If the project will require assistance from another area/specialty (such as Information Systems, finance, marketing) establish those links as early as possible. Ask representatives from that area to sit in on a team meeting and/or send a team member to meet with them one on one.
Measure
Purpose
To thoroughly understand the current state of the process and collect reliable data on process speed, quality, and costs that you will use to expose the underlying causes of problems
Deliverables
Fully developed current-state value stream map
Reliable data on critical inputs (Xs) and critical outputs (Ys) to be used for analyzing defects, variation, process flow, and speed
Baseline measures of process capability, including process Sigma Quality Level, and lead time
Refined definitions of improvement goals
A capable measurement system
Revised project charter (if data interpretation warrants a change)
Key steps in Measure
1. Create/validate a value stream map to confirm current process flow. Use a basic process map (p. 39) or deployment flowchart (p. 43) to get started. Add defect, time, and other process data to generate a value stream map (p. 45).
2. Identify the outputs, inputs, and process variables relevant to your project. You want to collect data that relates to your project goals and targeted customers.
3. Create a data collection plan including operational definitions for all measures.
4. Create a data analysis plan. Verify what types of tools can be used for the type of data you will collect. (See p. 72.) Modify your data collection plan as needed.
5. Use Measurement System Analysis and Gage R&R (p. 87), or other procedure to ensure accurate, consistent, reliable data.
If using measurement instruments, be sure to calibrate them if it hasn't been done recently
Make sure Operational Definitions (p. 76) of all metrics are commonly used and applied by all data collectors
6. Collect data to establish baselines.
7. Update value stream map with data.
8. Use Little's Law (p. 202) to calculate lead time.
9. Perform process capability evaluation (p. 138).
10. Make quick-hit improvements if warranted by data analysis and risk analysis so you can get partial benefits now (be sure you are in a position to measure and show improvement), then continue with project.
Use a Kaizen approach or, minimally, follow guidelines on implementing obvious solutions (p. 152)
If solution ideas pop up but the risks are high or unknown, keep track of the ideas for potential implementation but continue with your DMAIC project
11. Prepare for Measure gate review.
Gate review checklist for Measure
A. Detailed value stream map (VSM)
Documentation of people who were involved in creating the value stream map (should include representative operators, technical experts, supervisors, perhaps customers and selected suppliers)
Map showing the main process steps relevant to the project scope, along with the inventories/work in process, lead times, queues, customer demand (takt) rate, and cycle times for those steps
Supplier and customer loops clearly identified; output and inputs clearly understood
B. Data and Metrics
Lists of key process output variables (KPOVs) and key process and input variables (KPIVs) identified and checked for consistency against the SIPOC diagram
Indications of how KPOVs are tied to Critical-to-Quality customer requirements (CTQs)
Notations on which KPOVs are selected as the primary improvement focus
Operational Definitions (p. 76) and data collection plans (p. 72) that were created, tested, and implemented for all metrics
Documentation of measurement system analysis (p. 87) or its equivalent performed to ensure accuracy, consistency, and reliability of data
Notes on problems or challenges with data collection and how they were addressed
Notes on ANY assumptions that were made
Copies or printouts of completed data collection forms
C. Capability Analysis
Time-ordered data collected on process outputs, charted on a control chart (p. 122), and analyzed for special and common causes (p. 133)
Baseline capability (p. 135) calculations for key output metrics (Ys)
Product/service specifications framed in terms of external customer requirements or internal performance expectations (note any assumptions made)
Documentation on reliability of the capability estimates (is the measurement process stable, and does it have the expected distribution?)
Project goals reframed in terms of shifting the mean, reducing variation, or both
D. Updated project charter and plans
Project charter, financial benefits, and schedule timeline updated to reflect new knowledge
Project risks re-evaluated
Documentation of issues/concerns that may impact project success
Team recommendation on whether it makes business sense to continue with project
Detailed plans for Analyze, including anything that requires sponsor approval (changes in scope, budget, timing, resources)
E. Quick improvements
Actions recommended for immediate implementation, such as:
Non-value-added process steps, sources of special cause variation that can be eliminated to improve process time and/or capability
Required resources (budget, training, time) for implementation
Tips for Measure
Be sure to check your measurement system. You'll end up wasting a lot of time and effort if you get unreliable data. Use Measurement System Analysis (p. 87) or Gage R&R (p. 88).
Be sure your team understands the difference between lead time, takt rate (customer demand rate), and process capacity—these are commonly confused.
Build your value stream map manually. Include pictures of tools, templates, documents or other devices used at each step in the process. This help the team members to "see" what is really going on in the process.
Analyze
Purpose
To pinpoint and verify causes affecting the key input and output variables tied to project goals. ("Finding the critical Xs")
Deliverables
Documentation of potential causes considered in your analysis
Data charts and other analyses that show the link between the targeted input and process (Xs) variables and critical output (Y)
Identification of value-add and non-value-add work
Calculation of process cycle efficiency
(Continues...)
Excerpted from The Lean Six Sigma Pocket Toolbook by Michael L. George David Rowlands Mark Price John Maxey Copyright © 2005 by George Group. Excerpted by permission of McGraw-Hill. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.