Introduction to 8D problem solving: including practical applications and examples 9780873899550, 0873899555

Citation preview

Introduction to 8D Problem Solving Including Practical Applications and Examples

68997_Benbow_pi-050.indd 1

3/20/17 9:01 AM

Also available from ASQ Quality Press: The Certified Six Sigma Black Belt Handbook, Third Edition T. M. Kubiak and Donald W. Benbow The Certified Quality Technician Handbook, Second Edition H. Fred Walker, Donald W. Benbow, and Ahmad K. Elshennawy The Certified Six Sigma Yellow Belt Handbook Govindarajan Ramu The Certified Six Sigma Green Belt Handbook, Second Edition Roderick A. Munro, Govindarajan Ramu, and Daniel J. Zrymiak Practical Engineering, Process, and Reliability Statistics Mark Allen Durivage The ASQ Pocket Guide for the Certified Six Sigma Black Belt T.M. Kubiak Process Improvement Using Six Sigma: A DMAIC Guide Rama Shankar Statistics for Six Sigma Black Belts Matthew Barsalou The ASQ Pocket Guide to Statistics for Six Sigma Black Belts Matthew Barsalou The Quality Toolbox, Second Edition Nancy R. Tague Root Cause Analysis: Simplified Tools and Techniques, Second Edition Bjørn Andersen and Tom Fagerhaug The Certified Manager of Quality/Organizational Excellence Handbook, Fourth Edition Russell T. Westcott, editor The ASQ Quality Improvement Pocket Guide: Basic History, Concepts, Tools, and Relationships Grace L. Duffy, editor To request a complimentary catalog of ASQ Quality Press publications, call 800-248-1946, or visit our website at http://www.asq.org/quality-press.

68997_Benbow_pi-050.indd 2

3/20/17 9:01 AM

Introduction to 8D Problem Solving Including Practical Applications and Examples

Ali Zarghami and Don Benbow

ASQ Quality Press Milwaukee, Wisconsin

68997_Benbow_pi-050.indd 3

3/20/17 9:01 AM

American Society for Quality, Quality Press, Milwaukee 53203 © 2017 by ASQ All rights reserved. Printed in the United States of America 22 21 20 19 18 17   5 4 3 2 1 Library of Congress Cataloging-in-Publication Data Names: Zarghami, Ali, author. | Benbow, Donald W., 1936– author. Title: Introduction to 8D problem solving : including practical applications and examples / Ali Zarghami and Don Benbow. Description: Milwaukee, Wisconsin : ASQ Quality Press, [2017] | Includes bibliographical references and index. Identifiers: LCCN 2017006518 | ISBN 9780873899550 (pbk. : alk. paper) Subjects: LCSH: Group problem solving. Classification: LCC HD30.29 .Z37 2017 | DDC 658.4/036—dc23 LC record available at https://lccn.loc.gov/2017006518 No part of this book may be reproduced in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher. Director of Products, Quality Programs and Publications: Ray Zielke Managing Editor: Paul Daniel O’Mara Sr. Creative Services Specialist: Randy L. Benson ASQ Mission: The American Society for Quality advances individual, organizational, and community excellence worldwide through learning, quality improvement, and knowledge exchange. Attention Bookstores, Wholesalers, Schools, and Corporations: ASQ Quality Press books, video, audio, and software are available at quantity discounts with bulk purchases for business, educational, or instructional use. For information, please contact ASQ Quality Press at 800‑248‑1946, or write to ASQ Quality Press, P.O. Box 3005, Milwaukee, WI 53201–3005. To place orders or to request a free copy of the ASQ Quality Press Publications Catalog, visit our website at http://www.asq.org/quality-press.   Printed on acid-free paper

68997_Benbow_pi-050.indd 4

3/28/17 11:40 AM

Table of Contents

List of Figures and Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Chapter 1  Introduction and Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3  The 8Ds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Chapter 2  Tools for Finding the Root Cause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1  Building the ­Problem-­Solving Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2 Brainstorming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3  The Fishbone Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4 Flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.5  Five Whys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.6  Checklists and Check Sheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.7  Problem Solving as a Discipline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Chapter 3  Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.1  Split Land Parcels Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2  Logistics Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.3  Progressive Die Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.4  Public Library Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.5  Medication Administration Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.6  Document Control Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.7  Medical Diagnosis Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.8  Hidden Porosity Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Chapter 4  Unsolved Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.1  Problems in Education . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.2  Problems in Healthcare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

v

68997_Benbow_pi-050.indd 5

3/20/17 9:01 AM

vi

Table of Contents 4.3  Problems in the Food Service Industry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.4  Problems in Manufacturing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.5  Problems in the Financial Sector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Chapter 5  Concluding Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 About the Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

68997_Benbow_pi-050.indd 6

3/29/17 9:24 AM

List of Figures and Tables

Figure 1.1

Example of an 8D document. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Figure 2.1

Example of bare fishbone diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Figure 2.2

Example of fishbone diagram with team contributions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Figure 2.3

Example of alternate fishbone diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Figure 2.4

Sample of conventional flowchart symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Figure 2.5

Flowchart example for an auto insurance claim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Figure 2.6

Flowchart example using multiple outputs for a decision point. . . . . . . . . . . . . . . . . . . . . . . 11

Figure 2.7

Example of five whys analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Figure 2.8

Five whys analysis for failed error detection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Figure 2.9

Example of a checklist: building security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Figure 2.10

Example of a check sheet: mall information booth. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Figure 2.11

Example of a check sheet: maintenance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Figure 2.12

Example of a check sheet: operator activities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Figure 2.13

Example of a check sheet using time blocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Figure 3.1

Example 8D form at the beginning of team activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Figure 3.2

Data for the last 10 applications of the most recent year . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Figure 3.3

Example 8D form section D4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Figure 3.4

Example 8D form section D5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Figure 3.5

Example 8D form at the beginning of team activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Figure 3.6

Example partial 8D form. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Figure 3.7

Final 8D form for the logistics problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Figure 3.8

Sketch of the part. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Figure 3.9

Sketch of the progressive die setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Figure 3.10

Example of a containment plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Figure 3.11

Final 8D form for the public library problem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Figure 3.12

Example of a medication list. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Figure 3.13

First three steps for the medication error team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Figure 3.14

Cause and effect diagram for medication errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Figure 3.15

Sections D4 and D5 of the medication team’s report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Figure 3.16

Containment plan for the document control problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

vii

68997_Benbow_pi-050.indd 7

3/20/17 9:01 AM

viii List of Figures and Tables Figure 3.17

Sections D4 and D5 of the documentation control team’s report. . . . . . . . . . . . . . . . . . . . . . 29

Figure 3.18

Sections D6 and D7 of the documentation control team’s report. . . . . . . . . . . . . . . . . . . . . . 29

Figure 3.19

Simplified decision tree. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Figure 3.20

Die halves. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Figure 3.21

Containment plan for the hidden porosity problem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Figure 3.22

Cause and effect diagram for hidden porosity problem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Figure 3.23

Location of porosity as indicated by X-ray images. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Figure 3.24

Location of coolant runs in the die. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

68997_Benbow_pi-050.indd 8

3/20/17 9:01 AM

Preface

We received a call from the local community college’s business and technology coordinator requesting we teach a class in 8D for two local manufacturing operations. We had never delivered this training before, although we had been teaching application of statistical tools in many industries to improve efficiency and solve technical problems for over 30 years. To understand the client requirements, we met with the HR manager, the operations manager, and the two plant quality managers. We wanted to understand client requirements before we developed the training. We wanted to connect the 8D process as much as we could to traditional quality tools, mainly more statistical tools. The more we tried to enforce our agenda, the tools that we liked, the less the clients agreed with our approach. The clients did not have much interest in hard statistical tools. They were more interested in simple tools that can be easily learned and applied and that are available to everyone, not in tools that a few chosen people can use. They were saying, “The simpler the tools, the more people we can get involved, and the better off we will be.” The clients did not want any computer, Microsoft Excel worksheet, or data analysis tools. They wanted a pencil and paper and an open mind. For old folks like us, that is a hard paradigm shift. Less than enthusiastically we accepted this project and developed a simple 8D training program for the clients. This 8D training reminded us of the quality circles that were popular in the 1970s and used by many industries. As we recalled, the quality circle used simple tools and tried to get everyone to participate, in particular those on the shop floor who were closest to the processes. It seems like every few years we repeat ourselves. The concept is the same, the name is different. We designed the course per client requirements and taught it in two different plants. Participants were from the traditional manufacturing areas of industrial engineering, maintenance, shop floor management, quality, purchasing, scheduling, and human resources. The course lasted 16 hours, conducted four hours a week for four weeks. We did this purposely so we could repeat training material several times and work on as many projects as possible to reinforce learning. One thing that separates the training in this book from other training is the requirement for documentation of learning for immediate communication and future use. Unfortunately, each customer has its own format to document learning, which makes paperwork confusing for the client’s workers to learn. We have addressed this shortcoming by recommending an 8D documentation format. It is targeted to anyone who wants to improve quality regardless of the industry they come from. Healthcare, retail, finance, government, and even manufacturing people can use it. It was a pleasure to see the aha moments on the participants’ faces as they addressed real customer issues. At the end of the day, what our clients requested was what was needed; and maybe the ones who required change were us. There should definitely be room for a simple tool, and the 8D format provides an excellent structure for teamwork. There are some good tools in this cookie jar. The cookie jar is not on the top shelf; it is on the table. And it is ready for everyone’s use. The more you use it, the better you get at it. What are you waiting for?

ix

68997_Benbow_pi-050.indd 9

3/20/17 9:01 AM

68997_Benbow_pi-050.indd 10

3/20/17 9:01 AM

1 Introduction and Documentation

1.1 Introduction Problem solvers are a very important resource in any organization. These are the people who are able to creatively identify and remove barriers that keep the organization from accomplishing its mission. All personnel should understand that part of their job is to solve problems, that is, identify and overcome barriers to improvement. Some organizations find it useful to require periodic written reports detailing problems identified and progress toward their resolution. Many problems can be solved by an individual working alone. Other problems require a group effort involving people with various skills and knowledge bases. The purpose of this book is to provide a structure for the ­problem-­solving process. What does “fad” mean? Merriam-Webster OnLine defines “fad” as “a practice or interest followed for a time with exaggerated zeal” (https://www.merriam-webster.com/dictionary/fad). Is the 8D process another fad that will fade away in a few years? Before we answer this question, let us review a practice called the quality circle (QC), which was popular beginning in the 1970s. The QC worked as follows: • • • • • • • • • •

A team of volunteers was assembled The team members worked in the same area The team members selected their own project/problem to work on Almost all of the projects were related to the area they worked in Typical projects addressed safety, human resources, and other ­area-­related issues On most projects, the team used very basic analysis tools to solve problems Once the problem was solved, the team reported its findings to management The team selected another project and started working on it Eventually the team ran out of meaningful projects The team failed to receive managerial support and the QC died

We are not here to judge whether management made a good or bad decision. The bottom line is that management often perceived team projects with a ­short-­term return on investment (ROI) perspective. If the project did not pay back for the time the team was spending on it, the QC was abandoned. There was nothing wrong with the QC team concepts and basic statistical tools that the team used to solve problems. It appears as though the type of project the team selected was not judged to have sufficient return for the time being invested, thereby killing the QC. That is exactly why the 8D process will not die. In the current environment it is not the worker or management selecting projects; it is the customer. Management and workers have a similar interest in solving the problem. Both parties want to save the job, making it a win–win for everyone. The customer who pays the bill demands a solution to the problem. The customer wants to know why the quality system in place to protect the customer has failed, and perhaps caused production issues on the customer’s production floor. It is also an issue that could have surfaced after the consumer received the product, which is the worst case. The bottom line is that a solution to the problem is in everyone’s interest. ­ roblem-­solving tools around that are The 8D format itself is not unique. There are dozens of multistep p 1

One 68997_Benbow_pi-050.indd 1

3/20/17 9:01 AM

2

Chapter One very similar. For example, the s­ even-­step method we put together in the 1980s denoted step three “Quick Fix: Procedure used to keep alligators at bay during swamp draining.” The 8D process is almost a de facto standard in the manufacturing sector and is unique in its origination with the customer. In its simplest form, this is how the 8D process works: • • • •

Customer has a very specific problem and requests a solution Producer of problem assembles a team of experts to address the problem Team resolves the issue and reports finding Team disbands

Of course, the problem could come from anywhere, not exclusively from the customer, as long as the project is deemed important enough to assemble a team to work on it.

Overview of the 8D ­Problem-­Solving Methodology 8D stands for eight discipline ­problem-­solving methodology. The 8Ds are: 1. Select an appropriate team 2. Formulate the problem definition 3. Activate interim containment 4. Find root cause(s) 5. Select and verify correction(s) 6. Implement and validate corrective action(s) 7. Take preventive steps 8. Congratulate the team There is some parallelism between the 8D steps and the DMAIC steps used by Six Sigma practitioners in that D2 is essentially the DMAIC Define step, D4 is similar to the DMAIC Analyze step, D5 and D6 are like the DMAIC Improve step, and D7 parallels the DMAIC Control step. The 8D objective is to define the problem, implement containment, correct and eliminate the concern, improve quality control systems, and document and report findings. It is important to note that the problem could be product or process related and the 8D process is well equipped to address both. The 8D is a highly structured and scientific approach to problem solving.

1.2 Documentation The next few paragraphs cover the 8D steps in more detail. As each step is completed it should be added to the 8D document. This document could be developed internally or specified by a customer. Figure 1.1 illustrates the 8D document format that will be used in our examples in Chapter 3.

1.3 The 8Ds D0 Initiation We call this step D0 because it precedes the formal steps D1–D8. In this phase, a customer or internal management indicates they have a specific problem that needs to be addressed. At this time a quality alert is generated and vigorous containment effort is started to isolate the problem from the customer(s). Management will decide whether this problem is simple and can be handled by an individual, or whether it is significant enough to launch an 8D ­problem-­solving team. The 8D effort requires significant time and resources, management support allocating time, and team authorization, all of which are essential for the success of the team.

68997_Benbow_pi-050.indd 2

3/20/17 9:01 AM



Introduction and Documentation

Team 8D Working Document

Concern no.

3

Date initiated

D1: Team Members:

D2: Problem Statement/Description:

D3: Interim Containment Action(s):

D4: Root Cause(s):

D5: Choose and verify permanent correction(s):

D6: Implement and validate corrective actions:

D7: Take preventive actions:

D8: Congratulate your team: Date/Notes

Figure 1.1  Example of an 8D document.

D1 A Team Approach Management is responsible for assembling a team that has relevant knowledge and experience to address the issue. Management needs to allow time for the team to go through the four phases of team development—forming, norming, storming, and performing—to be effective. In some organizations a

68997_Benbow_pi-050.indd 3

3/20/17 9:01 AM

4

Chapter One senior manager is assigned as champion for the team to provide additional support and remove barriers for the team. It is very important that management assign a team leader for the project. The team leader should be experienced (subject matter expert) and should have completed a few 8D projects. The team leader must have the authority as needed to allocate time and acquire other resources needed for the team. In manufacturing cases, the team members could be from production, industrial engineering, design engineering, purchasing, programming, human resources, quality, and so forth. In retail cases, the team members could be retail associates, shift supervisors, marketing representatives, maintenance workers, delivery persons, and so forth. For healthcare, the team members could be nurses, nurse supervisors, programmers, doctors, and so forth. In the food industry the team members could include hostesses, servers, bus people, cooks, bartenders, shift supervisors, dietitians, accountants, and so forth. Depending on the team’s level of experience, the team leader might facilitate some root cause analysis training (which we discuss in the next chapter) with the team members. It is the team leader’s responsibility to keep the team on track and provide an open line of communication among all stakeholders. It is also the team leader’s responsibility to ensure that all team meeting minutes are kept, including team progress, action plan, and individual assignments and dates. Documentation of learning is a very important part of the 8D process. A form is provided on the Iowa Quality Systems website called the 8D Documentation Form. It is suggested that as each step is completed, every attempt be made to complete and update this form.

D2 Define and Explain the Problem The team will precisely detail the problem. It is extremely important that the problem be described in measurable terms. It is important to remember that it is difficult to improve something that can’t be measured. A nice tool available to define the problem is called the 5W & 2H. It is defined as follows: • • • • • • •

Who? Who is complaining? What? What are they complaining about? When? When did it start? Where? Where is the problem occurring? Why? Why is this problem occurring (an educated guess)? How? How did this problem occur (an educated guess)? How? How many problems (measurable and magnitude)?

Document your learning on the 8D documentation form.

D3 Interim Containment Action All nonconforming material must be isolated from the customer. This step is typically already in progress as discussed in step D0. An open and honest line of communication is required in this step between producer and recipient of the problem. Every effort is taken to isolate the problem from the customer. It may involve 100% inspection of the product in house and in the customer’s warehouse and additional steps in the process to ensure that the integrity of the product being produced is maintained. It is the team’s responsibility to review whether the containment action taken already is appropriate and to modify the action plan if needed. Containment action is not a substitute for a permanent solution. Most containment actions are inspection in nature, are temporary B ­ and-­Aids, add cost, and are no substitute for a permanent solution. The containment action plan must be documented on the 8D form and reviewed periodically.

68997_Benbow_pi-050.indd 4

3/20/17 9:01 AM



Introduction and Documentation

5

D4 Root Cause Analysis Finding the root cause is the most difficult part of the 8D process. If this problem were simple and easily solved, it would be resolved already. Two types of variability exist that should be considered: special cause and random cause. Naturally, we are interested in finding the special cause that is deeply hidden in the process. The main reason teams with subject matter experts are formed is to find the special cause. Problem-solving tools are sometimes categorized as soft or hard. The term “hard” here refers to those using statistical analysis. In this book we concentrate on the following soft tools: • • • • •

Team brainstorming event Five whys process Flowchart Checklists and check sheets Fishbone diagram

Fortunately, these simple tools are easy to learn and very effective in solving the majority of problems. If the team is working on a complex and more sophisticated problem, statistical tools such as hypothesis testing, analysis of variance (ANOVA), and design of experiments (DOE) are needed. In this case, a statistical expert should be engaged with the team. In many situations, sophisticated statistical tools will not be needed to solve the problem. The key is to have all team members engaged and contributing. The root cause solution must be documented on the 8D form and reviewed periodically.

D5 Develop Permanent Corrective Action Once the root cause of the problem has been identified, a number of corrections may be discussed. Scientific methods should be utilized to screen for the best solution. It is essential that the correction(s) be realistic, practical, c­ ost-­effective, and robust against process variability. Error proofing the process is a preferred method. The team must ensure that the correction does not create unintended consequences. At this stage, the correction should be implemented on a small scale to verify its effectiveness. Permanent corrective action should be documented on the 8D form.

D6 Implement Permanent Corrective Actions At this stage a permanent correction has been verified. The next step is to validate the correction on a large production scale. Again the team needs to ensure the correction does not create other issues. All changes need to be documented and all procedures updated. As the team implements the permanent solution, other people will be affected and need to be made aware and trained. An environment needs to be created so that the user(s) of the new method will have an opportunity to participate and be encouraged to do so. All suggestions from other groups need to be reviewed and, if valid, be incorporated into the total change process. Implementation of permanent corrective action should be documented on the 8D form.

D7 Prevent Future Reoccurrence For a reasonable time, the team should monitor whether the improved process is meeting all team goals set at the onset, and should ensure that the ongoing performance metrics are not negatively affected and

68997_Benbow_pi-050.indd 5

3/20/17 9:01 AM

6

Chapter One are meeting all requirements. The lessons learned from this effort should now be leveraged on similar processes. All quality control systems should now be in place and validated. Permanent future reoccurrence effort should be documented on the 8D form.

D8 Recognizing the Team Once the team task is completed and results meet all customer requirements, the team needs to be formally recognized and thanked by the management. The team members should thank all others who helped them to succeed, and they should complete all relevant paperwork and publish their work for future use. Team focus should especially be on lessons learned and application to similar processes. At this time, the team is dissolved and members wait for another opportunity to serve.

68997_Benbow_pi-050.indd 6

3/20/17 9:01 AM

2 Tools for Finding the Root Cause

2.1 Building the ­P roblem-­Solving Team As discussed in D1 of Chapter 1, the use of a team is central to 8D methodology. In fact, an early reference to 8D uses the term “TOPS 8D,” where TOPS stands for team oriented problem solving. Teams often go through several growth stages as they reach the ability to solve problems. These stages, along with thoughts team members might have or express, are as follows: 1. Forming—team members struggle to understand the purpose of the team and how it impacts them personally. –– “What’s this meeting for?” –– “Why am I here?” –– “How can I get my work done if I spend all my time at meetings?” 2. Storming—members tend to act as individuals rather than a team, expressing frustration with ideas they disagree with. –– “The only way to solve this problem is to . . .” –– “No matter what any of you say, . . .” –– “We tried Bill’s idea last year and it didn’t work.” 3. Norming—team members start to feel like a team and recognize that they have common goals. –– “If that’s what most of the team favors, let’s give it a try.” –– “Can we talk about Jan’s idea a little more? I’d like to hear what logistics thinks about it.” 4. Performing—the team works together to achieve its purpose. –– “I like Sam’s and Sally’s inputs. Can we blend those with the proposed specifications?” –– “We’re making good progress . . .” It takes skilled team leadership to help a team negotiate through these growth stages. The stages aren’t always followed linearly and simultaneously by all team members. Teams sometimes backslide to a previous stage. There are also documented cases of teams that have completed all stages except number four. Once the 8D team is assembled and the problem temporarily contained, it is time to search for the root cause, step D4. In some cases the root cause is easy to find. More often it requires some tools. The tools listed here have been found to be useful for directing team activities. While these tools may be used in any order it is common to begin with divergent tools, those that generate a wide variety of ideas, and follow up with techniques that narrow the list and generate more data about the process.

2.2 Brainstorming One way to help the team with its performing stage is to use a brainstorming session. The purposes here are to generate a large number of ideas and to get everyone to participate. The standard way is to ask each person to express one idea regarding the solution of the problem. The principal rules are that 7

Two 68997_Benbow_pi-050.indd 7

3/20/17 9:01 AM

8

Chapter Two all ideas are recorded for all to see, and criticism is not allowed. Often one person’s idea will generate similar ideas by others. This often produces a large number of ideas, and thus some way to organize or prioritize them will be needed. The next section addresses this issue.

2.3 The Fishbone Diagram Most teams begin with a general discussion of the problem and its possible causes. The fishbone diagram is a good guide to this conversation. The fishbone diagram is also known as an Ishikawa diagram and a cause and effect diagram. Its purpose is to identify all possible causes of a problem. The fish is drawn with four “bones” or cause categories, as shown in Figure 2.1. After a ­large-­scale fishbone outline is drawn, team members suggest possible causes of the problem in each of the categories. For instance, if the problem is the high number of errors in the billing process, the team might produce the diagram shown in Figure 2.2. More recent versions of the categories have replaced Manpower with People (or Manual to stay with the “M” words). Additional categories sometimes used include Management, Measurement, and Environment (or Mother Nature for those hung up on “M” words). Figure 2.3 illustrates a fish with six main bones used to help a team studying medication errors in a healthcare facility. One of the ground rules for listing potential causes is that no criticism of ideas is permitted. Judgments will come later. The main advantage of the fishbone approach is that when it is properly constructed by a ­well-­informed team there is a good chance that the cause or causes of the problem are somewhere on the finished diagram. This exercise is an example of what is called divergent thinking, and its principal disadvantage is the need for ­follow-­up convergent thinking to narrow the list of potential causes. This should be done carefully lest a real cause be lost. Machine

Methods

Materials

Manpower

Figure 2.1  Example of bare fishbone diagram. Machine Software Wrong tax table Interference in line to printer Toner low

Obsolete tax table No multicolored copies

Methods Inadequate double-checking Entering same data in several places

Typos Inexperience Failing to check with supervisors Inadequate training and instructions

Materials

Manpower

Figure 2.2  Example of fishbone diagram with team contributions.

68997_Benbow_pi-050.indd 8

3/20/17 9:01 AM



Tools for Finding the Root Cause Manual Failure to read wristband Failure to check time of day on med packet

Measurement Scales not accurate Different pills contain different percentage of active ingredient BP device not calibrated

Med packets not sealed Pills not uniform; half pill doesn’t have half the active ingredients

Diet not coordinated with meds (e.g., statins vs. citrus)

Materials

Methods

9

Mother Nature Humidity blurs labels Meds deteriorate when cart is left in sun

Need reading lamp on med cart Pill crusher has residue of previous pill Machine

Figure 2.3  Example of alternate fishbone diagram.

One method for converging the list is to ask team members to investigate various potential causes to help determine whether they should be studied further. This works best if people are asked to study ideas that they suggested. Another converging technique is to vote on the list to determine prioritization for further study. Multivoting is a process in which each person chooses their favorite four causes and assigns a value of four to their top choice, three to their next choice, and so forth. Again, the original diagram is preserved for possible further study and possible expansion at future meetings.

2.4 Flowchart The team will often find the need for more detailed understanding of the processes and procedures related to the problem. The best tool to guide them is the flowchart. Some conventional symbols used in a flowchart are shown in Figure 2.4. The use of these symbols can best be illustrated through the use of examples. Figure 2.5 shows basic steps followed by a customer with an auto insurance claim. Some decision points require multiple outputs as illustrated in this example. Figure 2.6 shows an example from the medical field. A diagnosis indicates that a patient should receive a prescription. The flowchart can provide improved understanding of a process. This is especially important if the process is complex or some team members are unfamiliar with it. It is often useful to zoom in on individual steps to better illustrate details. For instance, to zoom in on a step labeled “Machine the part” or “Provide copies to departments,” one could make a mini flowchart showing the various activities required to complete the step. A team should also consider extending a flowchart in both directions to help capture valuable information. Flowcharts have proven useful in finding the source of undesirable events.

Example Tiny bits of glass have been occasionally detected in a ground beef product. A flowchart was extended from the calving process all the way through the final packaging operation. A thorough study of the feed lots discovered that a bottle had broken in an area where animals often lay down. Some shards of glass had worked their way through the hide into the meaty portions of the steer.

Example A sawmill was finding chipped corners on treated 2×6s. Each sawing and planing operation was studied for possible tool failure. The team zoomed in on the arrow between sawing and planing and found a bend in the conveyor system that occasionally jammed up, causing the problem.

68997_Benbow_pi-050.indd 9

3/20/17 9:01 AM

10

Chapter Two

Activity or step

Decision point

Preparation

End

Continued elsewhere

Figure 2.4  Sample of conventional flowchart symbols.

A

Policyholder receives auto damage

Insurance adjuster surveys damage and writes estimate

Call body shop

Have claim number?

No

Get claim number from insurance company

Insurance company estimate = body shop’s?

No

Negotiate

Yes Yes Make appointment for estimate

Repair car

Present car for estimate

Complete paperwork and money transfers; close files

End Estimator provides estimate to shop office

Body shop office puts estimate in insurance company format

Body shop office double-checks data and transmits to insurance company

A

Figure 2.5  Flowchart example for an auto insurance claim.

68997_Benbow_pi-050.indd 10

3/20/17 9:01 AM



Tools for Finding the Root Cause

11

Drug XYZ is indicated

Determine patient weight

Patient weight 25–50 lbs. Prescribe 20 mg/day

Patient weight 51–75 lbs. Prescribe 40 mg/day

Patient weight 76–100 lbs. Prescribe 60 mg/day

Patient weight over 100 lbs. Prescribe 80 mg/day

Figure 2.6  Flowchart example using multiple outputs for a decision point.

Another use for a flowchart is in process design or redesign. The completed flowchart invites questions such as: • “Why do we do it like that?” • “Is that step necessary?” • “Couldn’t we go directly from here to here if condition A is met?” These questions are often asked by people new to the process who feel comfortable asking vital “dumb questions.” Often the answers to these questions are something like: • “A former customer required that step.” • “The equipment we used to have could not copy and staple.” • And the ever popular “We’ve always done it that way.”

2.5 Five Whys One of the hazards of team problem solving is the tendency to quit too soon. When the immediate cause of a problem is found it is tempting to terminate the search for underlying causes. The five whys tool helps the team dig deeper. Once an immediate cause is found, the team is challenged to consider that cause as an effect and ask why it occurred. When this cause is found, the team determines why this cause occurred, and so forth. Figure 2.7 illustrates this process. The ­problem-­solving team’s principal mission is to determine the root cause and devise a corrective action so that the problem never reoccurs. However, if the error or defect gets to a customer, an additional task is to answer the question “Why did our detection system fail to protect our customer from this problem?” A five whys approach is helpful, as shown in Figure 2.8.

68997_Benbow_pi-050.indd 11

3/20/17 9:01 AM

12

Chapter Two

Problem: Machine 209 produced a defective part. First Why: Why did 209 produce a defective part? After some detective work the team discovers that the machine stopped during production of the part, causing the defect. Second Why: Why did 209 stop? The team uses a fishbone to help with this investigation and discovers that an internal thermal-switch cut off power to the drive motor. Possible fixes: 1. Provide better ventilation for the switch 2. Rewire the machine, bypassing the switch 3. Reset the switch and keep rolling Number 3 is, in fact, what is usually done, perhaps as part of a short-term containment measure. But obviously the team should not stop here. They should ask the third why. Third Why: Why did the thermal switch cut off power? Possible causes to be investigated include: 1. Faulty thermal switch 2. Incorrect setting on the thermal switch 3. The machine is overheating The switch is found to be functional and properly set, so the team is ready to ask the fourth why. Fourth Why: Why is the machine overheating? Possible causes 1. Fan not running correctly 2. Amperage exceeds rating 3. Filter clogged The team finds that the amount of current to a motor exceeds the manufacturer’s specification. Fifth Why: Why is the machine drawing too much current? The team reviews the machine specifications and discovers that the machine is being overloaded, which brings up the sixth why. Sixth Why: Why is the machine being overloaded? Further investigation shows that machine specifications are not consulted when deciding machine loading. The team reports that it has found the root cause and recommends that machine 209’s specifications be consulted when determining its loading. But the team should probe further. A new five whys analysis could be initiated where this one left off, digging into company policy. First Why: Why aren’t machine specifications consulted when determining loading? The team finds that the company has no policy on this matter. Second Why: Why hasn’t the company developed a policy on this? Because machine overloading was not considered a failure mode when possible process failures were studied. Third Why: Why wasn’t machine overloading considered? Lesson Learned: Machine overloading should be considered on all process failure modes and effects analysis studies.

Figure 2.7  Example of five whys analysis.

Problem: A farmer has returned a bag of seed corn because the label location for the hybrid number is blank. First Why: Why did the blank label go undetected? Because the sensor on the printing machine didn’t catch it. Second Why: Why didn’t the sensor catch it? Because it only looks for company name and date; it does not look for number. Third Why: Why doesn’t the sensor look for the number? Because it wasn’t programmed to look for the number. Lesson Learned: All printer error sensors should be reprogrammed to look for the hybrid number.

Figure 2.8  Five whys analysis for failed error detection.

68997_Benbow_pi-050.indd 12

3/20/17 9:01 AM



Tools for Finding the Root Cause

13

2.6 Checklists and Check Sheets A checklist consists of a list of activities to be executed. The checklist in Figure 2.9 could be used by building security personnel. This list may be the product of a p ­ roblem-­solving team’s effort to anticipate and prevent various problems with overnight security. A ­problem-­solving team might be able to use the information in the checklist to determine the cause of some additional failure. The team might prevent future occurrence of this failure by adding an item to the night security checklist. A similar checklist could be constructed showing: • • • • •

Items to be included to fulfill a customer order Steps that must be completed to close a transaction Measurements to be verified prior to initiating a manufacturing process Items that will be checked during an audit Switch positions to be set before takeoff of a commercial airplane

An application of a check sheet is shown in Figure 2.10, which displays data collected from the information booth of a retail shopping mall. One hash mark (/) is placed in the appropriate row each

11/24/17 #418

Date/Associate No.

initial/time/note Door A LOCKED Lobby lights ON Thermostat at 505 Café window LATCHED Lot lights ON Smoke alarm CHECKED Aquarium light OFF Door D LOCKED Tap R OFF Cameras & DVR OK Entry signal ARMED Notes

DB 2110 DB 2115 A DB 2118 DB 2145 DB 2151 DB 2205 B DB 2212 DB 2225 DB 2235 DB 2242 DB 2255 A: Ceiling bulb out B: Replaced 9v in room 306

Figure 2.9  Example of a checklist: building security.

Date

3/14/17

3/15/17

3/16/17

Restrooms?

////////

/////////

//////////

First aid?

////

/////

////

Security?

/////

//

///

Sears?

////

///

//////

Wet Seal?

//

///

/

Food court?

////////

//////////

////////

Information desk?

//

/

Figure 2.10  Example of a check sheet: mall information booth.

68997_Benbow_pi-050.indd 13

3/20/17 9:01 AM

14

Chapter Two time the desk personnel answer a question. This information could be used to help with signage decisions. Figure 2.11 illustrates a similar check sheet used to track maintenance activity. The data from this check sheet could be used in planning preventive maintenance procedures. It is sometimes possible to use data from a check sheet to gain insight into cause and effect relationships. The check sheet in Figure 2.12 shows an operator’s routine activities during a 12‑day period. One of the more ­time-­consuming activities is the replacement of the drive coupling. This was done four times during the 12‑day period. A team responsible for reducing the number of drive coupling replacements noticed an unusual pattern in the check sheet in that the replacements occurred only after repeated greasing of bearing 21. Hmmm. Did greasing cause the deterioration of the coupling? Did a third event cause both the bearing to require more grease and the coupling to fail? Fertile fields for investigation. If it is important to connect events with the order they occurred, the columns may be used to represent blocks of time, as shown in Figure 2.13. For this example, the team wanted to determine how the diameters varied over time. Ten parts were selected randomly between 7 a.m. and 8 a.m. and their diameters recorded on the check sheet. This was repeated each hour until noon. Your analysis?

Date

3/16/17

3/19/17

Idler adjustment

////

//////

Chiller reset

//

/

Chuck realigned

////

///

Mandrel realigned

/

Channel unblocked

/

Chute cleaned out

///////

///////

Collector emptied

/

Figure 2.11  Example of a check sheet: maintenance.

Date

11/10

Bearing 20 greased

/

11/11

11/13

/

Bearing 21 greased

////

Bearing 22 greased

/

Hone facets replaced Parting tool replaced

11/12

11/14

11/15

11/16

/

11/17

11/18

/ ///

/ /

/

/

/

11/20

11/21

/

/ /

//// / /

/

Drive coupling replaced

11/22 /

////

/

/

11/19

/ /

Facing tool replaced

/

/

U-joint lubricated

/

/

Display battery replaced Coolant recycled

/

/

Lasers recalibrated

/

Binders tightened

/

/ / /

/

Figure 2.12  Example of a check sheet: operator activities.

68997_Benbow_pi-050.indd 14

3/20/17 9:01 AM



Tools for Finding the Root Cause

Diameters Part: Measurement

#HJ355

7 AM–8 AM

Start time:

8 AM–9 AM

7 AM

9 AM–10 AM

Inspector:

15

#45

10 AM–11 AM

11 AM–Noon

2.500 2.501 2.502 2.503 2.504

//

2.505

///

2.506

///

2.507

/

2.508

/

2.509 2.510 2.511 2.512

/

2.513

/

//

2.514

///

////

/ // //

///

2.515

////

//

////

///

2.516

//

/

//

/

/

/

2.517 2.518 2.519 2.520

Figure 2.13  Example of a check sheet using time blocks.

2.7 Problem Solving as a Discipline Problem solving is one of the most important functions of any organization; in fact, some would say it is the most important function. There was a time when problem solving was considered primarily a management responsibility. That responsibility is now recognized as everyone’s. This recognition has come about as it became clear that those best equipped to determine causes and appropriate corrective actions are those closest to the problem. This means that all members of an organization need to look at their job as at least p ­ art-­time problem solver. This section provides some tools for this valuable function. If data analysis is required, more sophisticated tools are needed. The reader is referred to The Certified Six Sigma Black Belt Handbook, by T. M. Kubiak and Donald W. Benbow, published by ASQ Quality Press.

68997_Benbow_pi-050.indd 15

3/20/17 9:01 AM

68997_Benbow_pi-050.indd 16

3/20/17 9:01 AM