| The 8-D Methodology |
| Files Included In This Package |
| The Red Road Graphics |
| Files with the extension .swf are Macromedia Flash files (http://macromedia.com). They are Courtesy of The Red Road (http://www.sci.fi/~leo/). I have included them as I am a graphics ‘nut’ and I really believe they help a lot of text challenged people, myself included, understand several basic concepts. | |
| I develop on a Macintosh using Office 98. Work is checked for compatibility on a Compaq PC running Windows 98 and Office 2000. The free download version of Quicktime (http://www.apple.com/quicktime/) plays .swf files on both my Compaq peecee and on my Macintosh. The latest version of Quicktime is a ‘beta’ release of version 5 in which Flash is incorporated. | |
| Both computers have Shockwave and the Flash player installed, as well as the latest Quicktime. All are free downloads. There is a Quicktime Pro edition for sale, but you only need the free downloadable version. | |
| On the Macintosh platform, the files ‘play’ in Powerpoint like movies when in the SlideShow mode. On the PeeCee platform they do not. The Macintosh version of Powerpoint handles .swf files as ‘movies’ while the PeeCee does not appear to. |
| About .swf Files - 1 |
| If you have the Shockwave Flash plug-in for Internet Explorer installed, you can see these files online at: http://Elsmar.com/pdf_files/. All the .swf files are there (look by name). Using Explorer on both my PeeCee and my Mac, clicking on the file in my browser opens and allows you to ‘play’ the file. I don’t have Netscape for the PeeCee so I can’t check that, but on my Mac I cannot get the Netscape browser to play the file even though the plug-in is installed - so I doubt it will play with Netscape on the PeeCee. | ||
| NOTE: Microsoft’s Photo Editor does not ‘play well’ with animated gif files. It is not animated gif ‘aware’. You can see the first frame, but that’s it. | ||
| About .swf Files - 2 |
| To Play Animations From Within Powerpoint on a PeeCee | ||
| Except for the Histogram animation, I have included a .gif file as a counterpart to each .swf file. Any program which will play animated gif files will play these files. You can make the animations play in SlideShow mode in Powerpoint by first setting up the file links. Go to each presentation slide which contains an animation and delete the animation. Then, go to the Insert / Picture / From File… menu cascade. Releasing the mouse on the From File… menu line item will bring up a file browser. Browse to and click on the appropriate .gif file for that slide. The animation will now play (continuous looping) in the SlideShow Mode. | ||
| The controls on the files only work if you are viewing the Flash files!!! The controls on the gif files do NOT work!!! | ||
| The location of .mov (Quicktime movie) and .ani (Windows animation/movie) versions of these .swf files: | ||
| http://www.Elsmar.com/pdf_files/Red_Road_Graphics/ | ||
| Don’t Let This Happen To YOU! |
| Origins: Mil-Std 1520 |
| The origins of the 8-D system actually goes back many years. | |
| The US Government first ‘standardized’ the system in Mil-Std-1520 “Corrective Action and Disposition System for Nonconforming Material” | |
| Mil-Std-1520 - First released: 1974 | |
| Last Revision was C of 1986 | |
| Canceled in 1995 |
| The Target & Goal |
| The 8-D System |
| Typical Investigation Time Line |
| A Nonconformance Database |
| Analysis vs. Action |
| The ‘disciplines’ which make up the 8-D process are divided into Analysis and Action steps. | ||
| Analysis Steps | ||
| D2 Problem Description Analysis - A method to organize information about the Symptom into a Problem Description through the use of repeated WHYs. | ||
| D4 Root Cause Analysis - A process to arrive at Root cause paths. | ||
| Action Steps | ||
| D3 Containment - An interim Verified action that will prevent the Symptom from reaching the customer. | ||
| D5 Choose Corrective Action - The best corrective action which, when implemented in D6, permanently eliminates the Root Cause of the problem. | ||
| D6 Implement Corrective Action - The best corrective action from D5 that is introduced into the process and Validated over time. | ||
| D7 System Preventive Action - Actions which address the system that allowed the problem to occur. | ||
| Process Tools |
| Process Tools |
| Problem Solving | ||
| A systematic process which describes, analyzes and identifies Root Causes of a problem. It is used to solve ‘past’ actions that are now causing unwanted effects. Generally it takes more time, energy and resources to correct a problem than to prevent it. This tool is used in D2 and D4 for describing a problem and finding its Root Cause. | ||
| Decision Making | ||
| A process used to select the best of various options. It addresses ‘present’ situations where the correct decision needs to be made the first time in order to implement appropriate actions. The tool is used at steps D3 and D5 for determining which interim and permanent corrective actions to implement. | ||
| Planning and Problem Prevention | ||
| A process which ‘looks into the future’ to anticipate what might go wrong with a plan. The process requires team members to develop plans to prevent problems from happening or causing serious damage if they do happen. Generally, Planning and Problem Prevention provides the most cost effective way of avoiding problems. This tool is used in D6 and D7 for implementing permanent corrective actions and preventing recurrence. | ||
| Concerns Analysis | ||
| A process which breaks down complex issues into manageable concerns, prioritizes them and assigns the proper process tools. Like Decision Making, it deals with ‘present’ situations and helps to step back from a long list of ‘To Do’ activities and assess the situation from a broader perspective. Most often used at D0 and D1 by management to help assemble a team, define its goals and objectives. | ||
| Recommended Statistical Courses |
| Statistical Tools |
| Statistical Tools 1 |
| 1. Cause and Effects Diagram | ||
| 2. Operational Definitions Lay Engineering Specs |
||
| 3. Data Collection/Log/Check Sheet | ||
| 4. Pareto Diagram | ||
| 5. Histogram | ||
| Dot Plot | ||
| Stem and Leaf Plot | ||
| Box and Whisker Plot | ||
| 6. Control Chart | ||
| X-bar R Chart | ||
| X-bar and s Chart | ||
| Median and R Chart | ||
| p Chart | ||
| c Chart | ||
| u Chart | ||
| np Chart | ||
| Run Chart (chart of individuals) | ||
| Statistical Tools 2 |
| Plant Trend Charts | |
| Warranty Charts | |
| Engineering Specification Testing | |
| Fleet Testing | |
| Test Track | |
| Burn-In Results |
| Universe, Populations & Samples |
| Interpreting Statistics |
| Interpreting Statistics |
| Interpreting Statistics |
| Histogram Animation |
| Normal Distribution (Bell Curve) |
| This is a pattern which repeats itself endlessly not only with pieces of pie but in manufactured products and in nature. There is always an inherent Variability. Sometimes it’s a matter of finding a measurement device sensitive enough to measure it. | |
| Measurements may be in volts, millimeters, amperes, hours, minutes, inches or one of many other units of measure. | |
| It you take a sample of a population (such as height) and you chart their distribution, you will end up with a curve that looks like a bell. | |
| A Distribution which looks like a bell is a Normal Distribution. Normal Distributions are the most common type of distribution found in nature - but they are not the ONLY type of distribution. |
| Standard Deviation - A Measure of Dispersion |
| Basic Terms |
| Standard Deviation |
| Mean | |
| s = 0.070 |
| Cp Animation |
| Cpk Animation |
| D0 Problem Identified |
| Houston! We’ve Got A Problem! |
| Where Was The Problem Identified? |
| Typical Top Level Operations Flowchart |
| Process Flow Animation |
| Early Process Flow Diagram |
| Where Was The Problem Discovered? |
| Where Did The Problem Escape? |
| White Space Issues |
| Asking Why. How Far? Where Do I Look? |
| Design Block Diagram Example |
| Cause and Effects Animation |
| Failure Modes In Measurement Systems |
| Linearity | |
| Accuracy | |
| Repeatability | |
| Reproducibility | |
| Correlation for duplicate gages | |
| Gages may be needed prior to gage sign-off at subcontractor plant or any in-house pilot runs |
| Process Variation |
| Distinguishing between the types of causes is critical because the appropriate managerial actions are quite different for each. Without this distinction, management will never be able to tell real improvement from mere adjustment of the process or tampering. | |
| In practice, the most important difference to grasp first is the difference between special cause variation and common cause variation. | |
| The strategy for special causes is simple: Get timely data. Investigate immediately when the data signals a special cause is/was present. Find out what was different or special about that point. Seek to prevent bad causes from recurring. Seek to keep good causes happening. | |
| The strategy for improving a common cause system is more subtle. In a common cause situation, all the data are relevant, not just the most recent or offending figure. If you have data each month for the past two years, you will need to look at all of that data. |
| Distributions From Variation |
| Sometimes you can look at two slices of pie and tell which is bigger. Sometimes you cannot. | |
| Home Experiment: Slice a pie up into what you think are equal sized pieces and line them up according to size. Many look the same. If we want to arrange the pieces according to size, we need another way to tell how big each piece is. A weight scale will do quite well. Now - lets look at what we would find if we weighed each piece. | |
| There are big and little pieces, but you can see that the number of pieces in each step of the graph (weight group) varies from the largest piece to the smallest piece in a fairly regular and symmetrical pattern. This is the Distribution of the weights. The curve is what we would expect if the Distribution was a ‘Normal’ distribution. | |
| Imagine doing this with 100 pies! |
| Process Variation |
| All variation is caused. There are specific reasons why your weight fluctuates every day, why sales go up, and why Maria performs better than Robert. Management must recognize that variations in production or quality within manufacturing or service processes can be viewed as "special cause" variations, which are best removed by team members operating the process and "common cause" variations, which require management action to change some inherent feature of the process. There are four main types of causes. | |
| Common causes are the myriad of ever-present factors (e.g., process inputs or conditions) that contribute in varying degrees to relatively small, apparently random shifts in outcomes day after day, week after week, month after month. The collective effect of all common causes is often referred to as system variation because it defines the amount of variation inherent in the system. | |
| Special causes are factors that sporadically induce variation over and above that inherent in the system. Frequently, special cause variation appears as an extreme point or some specific, identifiable pattern in data. Special causes are often referred to as assignable causes because the variation they produce can be tracked down and assigned to an identifiable source. (In contrast, it is usually difficult, if not impossible, to link common cause variation to any particular source.) Special Cause variation results from events which are occurring outside the process. For example, a relatively major change in temperature or humidity could cause significant variation (points outside control limits) in the process. |
| Causes of Variation |
| Special (Assignable) Causes of Variation | |
| Special causes are problems that arise in a periodic fashion. They are somewhat unpredictable and can be dealt with at the machine or operator level. Examples of special causes are operator error, broken tools, and machine setting drift. This type of variation is not critical and only represents a small fraction of the variation found in a process. |
| Facts About Causes of Variation |
| Special Causes of Variation | |
| Accounts for 5-15% of quality problems. | |
| Is due to a factor that has "slipped" into the process causing unstable or unpredictable variation. | |
| Are unpredictable variations that are abnormal to the process including human error, equipment failure, defective/changed raw materials, acid spills, power failures, etc.; failure to remove them can result is corrosion, scale, metal fatigue, lower equipment efficiency, increased maintenance costs, unsafe working conditions, wasted chemicals, increased down-time (plant shut-down...), etc. | |
| Removal of all special causes of variation yields a process that is in statistical control. | |
| Correctable by local personnel. |
| Tampering - Process Variation |
| Tampering is additional variation caused by unnecessary adjustments made in an attempt to compensate for common cause variation. | |
| Tampering with a process occurs when we respond to variation In the process (such as by “adjusting” the process) when the process has not shifted. In other words, it is when we treat variation due to common causes as variation due to special causes. This is also called “responding to a false alarm,” since a false alarm is when we think that the process has shifted when it really hasn’t. | |
| In practice, tampering generally occurs when we attempt to control the process to limits that are within the natural control limits defined by common cause variation. We try to control the process to specifications, or goals. These limits are defined externally to the process, rather than being based on the statistics of the process. |
| Structural Variation |
| Structural Variation is regular, systematic changes in output. Typical examples include seasonal patterns and long-term trends. | |
| Problem vs. Symptom |
| At this point it is important to distinguish between a problem and a symptom. A symptom, for example, could be a split in a seam. | |
| Generally, there are a series of problems associated with a process that causes a symptom (in this case the seam split). A symptom often illustrates a ‘gap’ between the desired quality (of the seam) and its actual quality. The seam split because of a problem in the process or in the design. | |
| Every company has its own internal system for appraising symptoms and problems. Sometimes a symptom occurs where 1 person can evaluate the problem and address it. Other times the symptom is significant and requires a team to investigate and remove the cause. |
| When An 8-D Is Necessary |
| Using ‘Good Judgment’ is the first step in deciding when to start an 8-D. | |
| Often, however, an 8-D is a customer requirement in response to a problem: Feedback from the customer that there is a concern with the product. Sometimes the concern shows up as a Symptom that has been detected by the customer. | |
| Ideally, a measurable will indicate when an 8-D should be started. When an undesirable trend in a process develops, corrective action can be taken to reduce the cause of the variation before a symptom occurs in the process and escapes to the customer. | |
| If the undesirable trend triggers questions, a decision must be made whether the symptom can be fixed by an individual or whether the symptom requires further analysis. Further analysis typically indicates it’s time to assemble an 8-D problem solving team. |
| When An 8-D Is Necessary |
| At this point, each of you (in your thoughts) is wanting the instructor to provide a black & white explanation of when a formal 8-D is required. Unfortunately, the answer is that the only time an 8-D is ‘required’ is when a customer requires it. | |
| Each company provides an internal threshold. It is typically somewhat subjective. There is no ‘absolute’ in so far as when or how far. Many companies use a Review Board. But - each has it’s own path. |
| When An 8-D Is Necessary |
| Verification vs. Validation |
| Verification and Validation are often not well understood. Verification and Validation work together as a sort of ‘before’ (Verification) and ‘after’ (Validation) proof. | ||
| Verification provides ‘insurance’ at a point in time that the action will do what it is intended to do without causing another problem. Predictive. | ||
| Validation provides measurable ‘evidence’ over time that the action worked properly. | ||
| Investigative Questions |
| Investigative Questions |
| D1 Use Team Approach |
| The 8-D System |
| Team Approach |
| When a problem cannot be solved quickly by an individual, it is necessary to form a Team. The team will engage in the investigation and resolution of the problem. Many factors are critical to establish a group and to ensure that the group can work effectively together. Using a team approach is not just a step in the problem solving process, but an overriding framework for decision making. | ||
| It is necessary to reevaluate team membership continually. | ||
| Model for Effective Teamwork: | ||
| Structure | ||
| Goals | ||
| Roles | ||
| Procedures | ||
| Interpersonal Relationships | ||
| Establishing A Team (Flow) |
| The Team - Basics |
| What is a Team? | ||
| Two or more individuals who coordinate activities to accomplish a common task or goal. | ||
| Maintaining Focus | ||
| A separate team for each product or project. | ||
| Brainstorm | ||
| Brainstorming (the Team) is necessary as the intent is to discover many possible possibilities. | ||
| Brainstorming |
| What is Brainstorming? | |
| Brainstorming is a method for developing creative solutions to problems. It works by focusing on a problem, and then deliberately coming up with as many deliberately unusual solutions as possible and by pushing the ideas as far as possible. | |
| One approach to brainstorming is to 'seed' the session with a word pulled randomly from a dictionary. This word as a starting point in the process of generating ideas. | |
| During the brainstorming session there is no criticism of ideas - the idea is to open up as many possibilities as possible, and break down preconceptions about the limits of the problem. | |
| Once this has been done the results of the brainstorming session can be analyzed and the best solutions can be explored either using further brainstorming or more conventional solutions. |
| How To Brainstorm |
| The following rules are important to brainstorming successfully: | |
| A leader should take control of the session, initially defining the problem to be solved with any criteria that must be met, and then keeping the session on course. He or she should encourage an enthusiastic, uncritical attitude among brainstormers and encourage participation by all members of the team. The session should be announced as lasting a fixed length of time, and the leader should ensure that no train of thought is followed for too long. The leader should try to keep the brainstorming on subject, and should try to steer it towards the development of some practical solutions. | |
| Participants in the brainstorming process should come from as wide a range of disciplines with as broad a range of experience as possible. This brings many more creative ideas to the session. | |
| Brainstormers should be encouraged to have fun brainstorming, coming up with as many ideas as possible, from solidly practical ones to wildly impractical ones in an environment where creativity is welcomed. | |
| Ideas must not be criticised or evaluated during the brainstorming session. Criticism introduces an element of risk for a group member in putting forward an idea. This stifles creativity and cripples the free running nature of a good brainstorming session. | |
| Brainstormers should not only come up with new ideas in a brainstorming session, but should also 'spark off' from associations with other people's ideas and develop other peoples ideas. | |
| A record should be kept of the session either as notes or a tape recording. This should be studied subsequently for evaluation. It can also be helpful to jot down ideas on a board which can be seen by all brainstormers. |
| Individual vs. Group Brainstorming |
| Brainstorming can either be carried out by individuals or groups: | |
| Individual brainstorming tends to produce a wider range of ideas than group brainstorming, but tends not to develop the ideas as effectively, perhaps as individuals on their own run up against problems they cannot solve. Individuals are free to explore ideas in their own time without any fear of criticism, and without being dominated by other group members. | |
| Group brainstorming develops ideas more deeply and effectively, as when difficulties in the development of an idea by one person are reached, another person's creativity and experience can be used to break them down. Group brainstorming tends to produce fewer ideas (as time is spent developing ideas in depth) and can lead to the suppression of creative but quiet people by loud and uncreative ones. | |
| Individual and group brainstorming can be mixed, perhaps by defining a problem, and then letting team members initially come up with a wide range of possibly shallow solutions. These solutions could then be enhanced and developed by group brainstorming. |
| Define Scope Of Team |
| Select team members and functions | |
| Define roles and responsibilities | |
| Identify external customer needs, expectations and requirements | |
| Identify internal customer needs, expectations and requirements | |
| Complete preliminary studies | |
| Identify costs, timing and constraints | |
| Identify documentation process and method | |
| Develop investigation plan |
| Natural Work Group vs. Team |
| Team Structure |
| Size | ||
| Four to 10 members. Larger teams become less effective and have minimal commitment to the problem solving effort. Larger teams should assess whether a steering committee and/or subgroups should be established. | ||
| Support Needed | ||
| ‘Appropriate’ levels of the organization must be represented. | ||
| Environment | ||
| Meeting locations are critical to good teamwork. A site should be quiet and not disruptive to team members. A site near the work area permits easy data collection and customer interaction is beneficial. | ||
| Team Organization |
| Cross-functional | ||
| Design Engineering (Typically the leader) | ||
| Quality Assurance | ||
| Purchasing | ||
| Manufacturing Engineering | ||
| Material Control | ||
| Sales/Marketing | ||
| Etc. | ||
| Participation appropriate for phase being conducted | ||
| Resources - Team defines ‘Needs’ | ||
| *Should* involve customer or subcontractor participation (not always feasible) | ||
| Decision Making Criteria / Model |
| One person makes the decision | |
| One person consults the group, then makes the final decision | |
| Team or group makes decision based upon majority rule or consensus |
| Roles In A Team |
| Several roles need to be established for the team. These roles are: Leader, Champion, Record Keeper (Recorder), Participants and (if needed) Facilitator. |
| Inputs To Team |
| Field service reports | |
| Problems and issues reported from Internal customers | |
| Internal evaluations using surrogate customers | |
| Road trips (e.g.: Struts) | |
| Management comments and/or direction | |
| Government requirements and/or regulations | |
| Contract review | |
| Input from higher system level or past QFD projects | |
| Media commentary and analysis | |
| Customer letters and suggestions | |
| Things gone Right/Wrong reports | |
| Dealer comments | |
| Fleet operator comments |
| Team Goals |
| For any group to come together as a team, it is critical that everyone be clear on the team’s goal(s). All team member must share that goal. If any team members have different goals or have individual goals different or separate from the stated goal, these should be communicated to the team to avoid road blocks to the success of the team. | |
| The goal needs to be clearly specified, quantifiable, and supported by all team members. The goal should be challenging, but still be attainable. By writing (documenting) the team’s goal, all individuals on the team and the advisor to the team will ‘stick to’ and understand the goal. |
| Basic Team Rules |
| Team must develop their own ground rules | ||
| Once developed, everyone must live by them | ||
| Ground Rules are an aid to “self-management” | ||
| Team can modify or enhance the rules as they continue to meet | ||
| Determine if there should be a meeting | ||
| Decide who should attend | ||
| Provide advance notices | ||
| Maintain meeting minutes or records | ||
| Establish ground rules | ||
| Provide and Follow an agenda | ||
| Evaluate meetings | ||
| Allow NO interruptions | ||
| Team Meeting Responsibility |
| Clarify | |
| Participate | |
| Listen | |
| Summarize | |
| Stay on track | |
| Manage time | |
| Test for consensus | |
| Evaluate meeting process |
| Team-to-Team Communication |
| Manage by using a Team Captain or Champion | |
| Understanding of ‘How We Work As A Team’ | |
| Should have a Focus Person & Distributed Minutes | |
| Customer teams | |
| Internal teams | |
| Supplier teams | |
| Sub-Teams | |
| Subcontractors should be encouraged to embrace ISO 9001 or APQP and QS 9000 |
| Successful Teams |
| Are management directed and focused | |
| Build their own identity | |
| Are accountable and use measurements | |
| Have corporate champions | |
| Fit into the organization | |
| Are cross-functional |
| Team Check List |
| D2 Describe The Problem |
| The 8-D System |
| Describe the Problem |
| Describe the Problem |
| Problem definition is the basis of problem solving. The definition is used during brainstorming sessions to identify potential causes. Potential causes are those most likely causes that appear on the surface to be the source of the problem. A potential cause may be the root cause but must be supported by evidence. | |
| Part of the problem solving process is to identify the root cause of the problem and understand why it existed in the first place. Only then can a permanent solution be chosen and implemented. to make certain the problem will never surface again. The root cause is the reason the problem exists. When it is corrected or removed from the system, the problem will disappear. It is important to improve our understanding of today's technology to make possible the planning required to achieve quality and productivity breakthroughs for tomorrow and into the future. |
| Customer Complaints |
| Many problems arise from customer complaints. An internal customer’s complaint could involve one department complaining that they cannot use the output of another department. An external customer complaint could involve a customer complaining to a dealer that a transmission ‘shifts funny’. | |
| Frequently the wrong problem is solved and the customer complaint is not addressed. It is very important that the customer complaint be clearly understood. The only method to ensure this is to have direct customer contact. | |
| For internal customers, it is advisable to have representatives from the complaining organization as part of the problem solving team. In many cases this approach is the only way a problem can truly be solved. | |
| External customer complaints typically require direct interviews to understand why the customer is not satisfied. It is not unusual for a customer complaint to be misrepresented by a company reporting system that classifies problems in prearranged standard categories. |
| Operational Definition of the Problem |
| It is important that the problem be described in terms that have the same meaning to everyone. This is best achieved through an operational definition. An operational definition consists of verifiable criteria that have the same meaning to the production workers, manager, customer, engineer, buyer, technician, team members, etc., and are used for past, present and future comparisons and analysis. | ||
| Sometimes problems are mistakenly described in terms of symptoms: | ||
| Machine is down due to electrical problem. No backup machine or alternative available. | ||
| The scrap rate has increased from “X” date from 3% to 22%. | ||
| Customer warranty claims on “X” engine component is 12%. | ||
| Failure of durability tests of a transmission component at 50,000 miles will delay launch. | ||
| Symptoms vs. Causes |
| It is not uncommon for problems to be reported as symptoms. More examples are: noise, won’t work, no power, machine down, broken tool, head froze up, contaminated, rough surface, porosity, shortage of parts, rattles, quality problem, worn out, line stopped, not to specification, labour problem, management problem, too much variation, etc. | |
| The problem solving team must use a systematic approach to define the real problem in as much detail as possible. A definition of the problem can best be developed using approaches that organize the facts to get a comparative analysis. These approaches do this by asking what ‘is’ against what ‘is not’. Then they draw distinctions from this comparison, testing these against the problem definition and forming a statement or description of the problem which must be resolved. |
| Problem Solving |
| Systematic approaches to problem solving: | ||
| Business as a System (Business as a Process) | ||
| Analytical problem solving | ||
| Process flow | ||
| Problem analysis methodologies: | ||
| 5W2H | ||
| Stratification | ||
| Comparative analysis | ||
| Similarity analysis | ||
| Key questions --> 5W’s and 2H’s: | ||
| Who? What? Where? When? Why? How? How Many? | ||
| In-Depth Analysis |
| An in-depth analysis is required to clearly define a problem. There are many examples where the analysis for a complete problem definition results in the solution being identified. The analysis starts with preparation (or review of the existing) process flow diagram to define clearly the work process and alternative paths. Team preparation or review ensures that all individuals are familiar with the process. After the flow diagram is reviewed, there are three principle parts of the problem analysis we discussed earlier: | ||
| 5W2H | ||
| Stratification | ||
| Comparative/Similarity Analysis | ||
| First, quantify the 5W2H elements. In various problem analysis situations the investigators or problem solving teams must continually test to determine where they are located in the circle of circumstances. If a decision is made, what are the alternatives? | ||
| 5W - 2H Analysis |
| It is sometimes difficult to define the problem and sort out real differences. The first, most important step, however, it to determine that the customer complaint is fully understood. | ||
| 5W2H : | ||
| Who? Identity customers complaining | ||
| What? Identity the problem adequately and accurately | ||
| When? Timing - When did the problem start? | ||
| Where? Location - Where is it occurring? | ||
| Why? Identify known explanations | ||
| How? In what mode or situation did the problem occur? | ||
| How Many? Magnitude - Quantify the problem | ||
| To reduce the risk of making wrong decisions, consideration and analysis of potential problems in advance will provide contingency actions to maintain control and protect the customer. | ||
| 5W - 2H Analysis |
| Who? - Identity individuals associated with the problem. Characterize customers who are complaining. Which operators are having difficulty? | ||
| What? - Describe the problem adequately. Does the severity of the problem vary? Are operational definitions clear (e.g. defects)? Is the measurement system repeatable and accurate? | ||
| When? - Identify the time the problem started and its prevalence in earlier time periods. Do all production shifts experience the same frequency of the problem? What time of year does the problem occur? | ||
| Where? - If a defect occurs on a part, where is the defect located? A location check sheet may help. What is the geographic distribution of customer complaints? | ||
| Why? - Any known explanation(s) contributing to the problem should be stated. | ||
| How? - In what mode or situation did the problem occur? What procedures were used? | ||
| How Many? - What is the extent of the problem? Is the process in statistical control? | ||
| Stratification Analysis |
| Stratification Analysis determines the extent of the problem for relevant factors. | ||
| Is the problem the same for all shifts? | ||
| Do all machines, spindles, fixtures have the same problem? | ||
| Do customers in various age groups or parts of the country have similar problems? | ||
| The important stratification factors will vary with each problem, but most problems will have several factors. Check sheets can be used to collect data. Essentially this analysis seeks to develop a pareto diagram for the important factors. The hope is that the extent of the problem will not be the same across all factors. The differences can then lead to identifying root cause. | ||
| When the 5W2H and Stratification Analysis are performed, it is important to consider a number of indicators. For example, a customer problem identified by warranty claims may also be reflected by various in-plant indicators. Sometimes, customer surveys may be able to define the problem more clearly. In some cases analysis of the problem can be expedited by correlating different problem indicators to identify the problem clearly. | ||
| Describe the Problem |
| It has been said that there are no new problems, only different manifestations of old problems. In problem definition, it is often useful to quantify the problem in similar situations. The criteria to match similar situations will vary with the type of problem. Identifying effective matches and evaluating the presence of the problem provides useful information to generate potential causes and possible problem solutions. If the similarity analysis identifies a comparable situation where the problem does not exist, the analysis can focus on the differences in where the problem is occurring and where it is not occurring. | |
| Once the 3 types of analysis have been completed, it is sometimes possible to divide the problem into separate problems. It is easier to address these smaller problems because fewer root causes are involved. In the ideal case, a single root cause would be responsible for each problem. If the problem is separated, different teams may be required to address each problem. | |
| All three elements of the problem definition are not used for every problem. However, collectively the different analyses provide a comprehensible description. You are developing a ‘specification’ of the problem. |
| Describe the Problem Flow |
| Root Cause Analysis |
| Investigative / Tracking Charts |
| Is / Is Not Questions |
| Is / Is Not Example |
| Timing Plan |
| Depends upon | ||
| Product complexity | ||
| Customer expectations | ||
| Team plan for | ||
| Training | ||
| Event | ||
| Action | ||
| Framework for tracking | ||
| Basis for status reporting | ||
| Prepare a timing chart using available project or similar software | ||
| Describe the Problem Phases |
| Phase I | |
| State the symptom, extent and consequence of the problem. | |
| Prepare / Review process flow diagram. | |
| Start an Action Plan to define the problem. Identify Who will do What by When. | |
| Phase II | |
| Identify Who, What, Where, When, Why, How and How Much. | |
| Qualify the extent of the problem to help identify relevant stratification factors. | |
| Evaluate similar situations where the problem might be expected to occur. | |
| Use all available indicators. Be creative about these. | |
| Subdivide the problem into natural problem groups. |
| Describe the Problem Questions |
| Questions | |
| What Type of Problem Is It? | |
| Field complaint | |
| Quality improvement | |
| Manufacturing improvement | |
| Component design | |
| Labour / Personnel | |
| Supplier / Vendor | |
| Cost improvement | |
| Solution implementation | |
| Cross functional | |
| Research | |
| Safety |
| Describe the Problem - 5W-2H |
| Who, What, When, Where, Why, How, How Many | ||
| What is the extent of the problem? | ||
| Has the problem been increasing, decreasing or remaining constant? | ||
| Is the process stable? | ||
| What indicators are available to quantify the problem? | ||
| Can you determine the severity of the problem? Can you determine the various ‘costs’ of the problem? Can you express the cost in percentages, dollars, pieces, etc.? | ||
| Do we have the physical evidence on the problem in hand? | ||
| Have all sources of problem indicators been identified and are they being utilized? | ||
| Have failed parts been analyzed in detail? | ||
| Customer Terms / Symptoms |
| Who is the customer? | ||
| Is there more than 1 customer? If so, which customer first identified the problem? | ||
| To whom was the problem reported in the customer’s organization? | ||
| What is the problem definition in customer terms? | ||
| What is the problem definition in YOUR terms? | ||
| Have we verified the problem with on-site visits with the customer? | ||
| Understanding Your Processes and Systems |
| Use a Process Flow Chart! | |
| Because: | |
| You want to understand your current process. | |
| You are looking for opportunities to improve. | |
| You want to illustrate a potential solution. | |
| You have improved a process and want to document the new process. |
| Production Cause and Effects Diagram |
| Service Cause and Effects Diagram |
| Flow Charting |
| Creating a Process Flow Chart |
| 1. Identify the process or task you want to analyze. Defining the scope of the process is important because it will keep the improvement effort from becoming unmanageable. | |
| 2. Ask the people most familiar with the process to help construct the chart. | |
| 3. Agree on the starting point and ending point. Defining the scope of the process to be charted is very important, otherwise the task can become unwieldy. | |
| 4. Agree on the level of detail you will use. It’s better to start out with less detail, increasing the detail only as needed to accomplish your purpose. |
| Creating a Process Flow Chart |
| 5. Look for areas for improvement | |
| Is the process standardized, or are the people doing the work in different ways? | |
| Are steps repeated or out of sequence? | |
| Are there steps that do not ad value to the output? | |
| Are there steps where errors occur frequently? | |
| Are there rework loops? | |
| 6. Identify the sequence and the steps taken to carry out the process. | |
| 7. Construct the process flow chart either from left to right or from top to bottom, using the standard symbols and connecting the steps with arrows. | |
| 8. Analyze the results. | |
| Where are the rework loops? | |
| Are there process steps that don’t add value to the output? | |
| Where are the differences between the current and the desired situation? |
| Early Process Flow Diagram |
| GM Example Process Flow Chart |
| Basic Flow Chart Example |
| Basic Flow Chart Example |
| Control Plan Example (GM) |
| FMEAs - Predicting Failure & Problems |
| Describe The Problem Check List |
| D3 Containment |
| The 8-D System |
| Implement and Verify Interim (Containment) Actions |
| Contain Symptom Flow |
| Containment Actions Objective |
| Containment Actions |
| The main objective of this part of the problem solving process is to isolate the effects of the problem by implementing containment actions. A problem may be poor quality, marginal product design, or a process or system that is unpredictable. A containment action may be stopping production of a known source of a problem, or not shipping any parts or assemblies until the source of the problem is identified. | ||
| Once a problem has been described, immediate actions are to be taken to isolate the problem from the customer. In many cases the customer must be notified of the problem. These actions are typically ‘Band-aid’ fixes. Common containment actions include: | ||
| 100% sorting of components | ||
| Cars inspected before shipment | ||
| Parts purchased from a supplier rather than manufactured in-house | ||
| Tooling changed more frequently | ||
| Single source | ||
| Containment Actions |
| Unfortunately, most containment actions will add significant cost | |
| ($) | |
| to the product. However, it is important to protect the customer from the problem until permanent corrective actions can be verified and implemented. | |
| Most interim actions are ‘temporary short term’ actions taken until a permanent corrective action is defined, implemented and verified. The danger of many interim corrective actions is that they are considered to be a permanent solution to the problem. It must be remembered that they are typically ‘band-aids’. It is a mistake to view containment actions as a solution to the problem. Containment actions typically address the effect. They should be considered ‘immediate first-aid’ to be reviewed and removed as quickly as possible. |
| Containment Actions |
| Containment actions can and often should proceed in parallel with the root cause determination investigation. During the period in which containment actions are taking place, many useful things must be pursued as a first step in finding the root cause. These things include: | ||
| Establishing an investigative plan | ||
| Obtaining baseline data | ||
| Initiating an on-going control system | ||
| Developing a follow-up and communications system | ||
| Correcting products already produced | ||
| Start systematic investigations | ||
| Conduct special studies and statistical experiments | ||
| Understand the problem Review experiences and data with current trends | ||
| Forecast the future | ||
| Typical 8-D Time Line |
| Containment Actions |
| A design test on data collection (i.e. check sheets, control charts, etc.) can be used to evaluate the effectiveness of the actions. The process can be monitored using control charts and histograms. An action plan should define who, what and when clearly to coordinate the interim fixes. | ||
| Individuals should be encouraged to gain knowledge about the entire process. Ask - What would be the effect of: | ||
| Incorporating robust engineering designs | ||
| Establishing manufacturing feasibility | ||
| Determining how one operation or dimension affects another | ||
| Centering the process | ||
| Over adjusting and / or under adjusting a machine or process | ||
| Improving machine set-up | ||
| Changing tools | ||
| Improving maintenance, etc. | ||
| Well engineered management systems, practices and procedures need to be coupled with effective training programs. Together these can provide the best protection to prevent recurrence of the problem by new technologies, new methods, new employees, job rotation or improvement of individual skills. | ||
| Containment Actions Flow |
| Verifying Containment Actions - Pilot Runs |
| Run Pilot Tests | |
| Artificially simulate the solution to allow actual process or field variation. | |
| Field test the solution using pilot customer groups. | |
| Verify carefully that another problem is not generated by the solution. | |
| Monitor Results | |
| Quantify changes in key indicators. | |
| Stress the customer / user evaluation. |
| Containment Actions Verification Questions |
| Have all alternatives been evaluated? | |
| Are responsibilities clear and defined? | |
| Is the required support available? | |
| When will the actions be completed? | |
| Have you ensured that implementation of the interim solution will not create other problems? | |
| Will all interim actions last until long-range actions can be implemented? | |
| Is the action plan coordinated with customers? | |
| Have tests been done to evaluate the effectiveness of the interim actions? | |
| Is data being collected to ensure actions remain effective? |
| Contain Symptom Check List |
| D4 Define Root Cause(s) |
| The 8-D System |
| Define and Verify Root Cause(s) |
| Identify all potential causes which could explain why the problem occurred. | |
| Isolate and verify the root cause by testing each potential cause against the problem description and test data. Identify alternate corrective actions to eliminate root cause. |
| Root Cause Of A Failure |
| Two Root Causes |
| Initial Data Evaluation |
| Initial Data Evaluation |
| Initial Data Evaluation |
| Interpreting Control Charts |
| Control Charts provide information as to whether a process is being influenced by Chance causes or Special causes. A process is said to be in Statistical Control when all Special causes of variation have been removed and only Common causes remain. This is evidenced on a Control Chart by the absence of points beyond the Control Limits and by the absence of Non-Random Patterns or Trends within the Control Limits. A process in Statistical Control indicates that production is representative of the best the process can achieve with the materials, tools and equipment provided. Further process improvement can only be made by reducing variation due to Common causes, which generally means management taking action to improve the system. |
| Interpreting Control Charts |
| When Special causes of variation are affecting a process and making it unstable and unreliable, the process is said to be Out Of Control. Special causes of variation can be identified and eliminated thus improving the capability of the process and quality of the product. Generally, Special causes can be eliminated by action from someone directly connected with the process. | |
| The following are some of the more common Out Of Control patterns: |
| Interpreting Control Charts |
| Interpreting Control Charts |
| Interpreting Control Charts |
| Interpreting Control Charts |
| Interpreting Control Charts |
| Interpreting Control Charts |
| Interpreting Control Charts |
| Control Chart Analysis Reaction |
| Control Chart Analysis Reaction |
| Define and Verify Root Cause(s) |
| An investigation into all identified potential causes is necessary for effective problem solving. A cause and effects diagram can be used to brainstorm all potential causes of the described problem. The team should decide on what C&E diagram(s) is to be used: 5M, Process Flow and/or stratification. The more detailed the C&E diagram, the higher the chances the root cause will be included on the C&E diagram. An effective C&E diagram will include input from all team members and will be discussed in detail. | |
| Any existing data should be reviewed for clues to potential causes. Further data collection may be required to investigate additional causes. | |
| If the problem has not previously been seen, a timeline analysis should provide significant data. The timeline will identify events occurring about the time the problem developed. If enough documentation is available, potential causes can be further identified. For example, if a new operator was put on a process or if a new supplier began supplying parts. Investigation into the events occurring at the same time the problem was discovered could lead to several important potential causes. | |
| “What Changed?” “When?” are important questions. |
| Define and Verify Root Cause(s) |
| A technique used extensively in analytical problem solving is a comparison analysis. This analysis looks at what ‘is’ and what ‘is not’ in the problem description. | |
| Potential causes can be discovered by conducting a survey. By surveying the customer who has witnessed the problem, more potential causes can be highlighted. | |
| Asking ‘Why’ repeatedly is effective in driving the process toward root cause and generating more complete understanding of the cause and effect. |
| Define and Verify Root Cause(s) |
| Once the problem has been described and the potential causes identified, the team should be evaluated. Are the right members on the team to investigate the potential causes? Are technical advisors required to assist in any special studies? Do new team members need to be added? Is the authority to pursue the analysis of the potential causes well defined? All these questions must be answered to ensure the team will be successful in investigating the potential causes and determining the root cause. | |
| The cause and effect diagram is used to identify the potential causes to be investigated. What is the probability that a potential cause could be responsible for the problem? Identify all potential causes that could have been present and may have caused the problem. | |
| Once all potential causes have been agreed upon, choose several potential causes to investigate. If only one potential cause is investigated, a lot of time may be lost if that potential cause proves not to be the culprit. To expedite a solution, investigate several potential causes at the same time (Parallel actions on several potential causes). |
| Define and Verify Root Cause(s) |
| If the problem is a manufacturing process, begin to establish a stable process. Once the process is stable, definition of the potential cause will be clarified. | |
| If design causes are identified, screening experiments may help identify the key variables which are affected by subsequent processes. Design changes may be appropriate. | |
| Four or five potential causes should be identified to investigate. Identifying several potential causes forces the team to address multiple possibilities rather than searching endlessly for a single cause. An implicit part of problem analysis is investigating potential causes in parallel rather that in series. |
| Hypothesis Generation |
| Six Steps Of Investigation |
| State how the potential cause could have resulted in the described problem. | |
| Establish what type of data can most easily prove or disprove the potential cause. Develop a plan on how the study will be conducted. Identify the actions on an action plan. | |
| Prepare the required materials to conduct the study. Training may also be required. | |
| Collect the required data. | |
| Analyze the data. Use simple statistical tools emphasizing graphical illustrations of the data. | |
| State conclusions. Outline conclusions from the study. Does the data establish the potential cause as being the reason for the problem? |
| Define and Verify Root Cause(s) |
| After the cause and effect diagram has been completed, data needs to be collected to determine which potential causes are important. Pareto diagrams and check sheets are very effective in establishing the importance of the potential causes. | |
| Many folks are under the mistaken belief that data oriented problem solving can be accomplished by collecting data on a problem, analyzing the results and deciding the correct solution. Once data is collected and analyzed, new questions often arise so another data collection and analysis iteration is necessary. In addition, many problems can have more than 1 root cause. Data collected investigating one potential cause may not address other important potential causes. Thus, several potential causes need to be studied using the data collection and analysis process. |
| Define and Verify Root Cause(s) |
| Once the data has been collected and analyzed, new potential causes often surface. These potential causes should be pursued as soon as possible since they are suggested by the data. | |
| The data collection for this step in the problem solving process can be as simple as check sheets or as sophisticated as design of experiments. The data analysis can rely heavily on simple graphical techniques such as histograms, pareto charts, control charts, stem-and-leaf and dot plots. By using graphical tools, quick comprehension by all participants as well as accurately communicated information will result. Comparison plots and stratified graphs are helpful in assessing stratification factors. To evaluate the relationship between characteristics, a scatter plot would be an effective tool. |
| Identify Alternate Solutions |
| Generate a Cause & Effects diagram. | |
| Survey the customer. | |
| Identify similar problem(s) previously solved. | |
| Avoid implementing the interim actions for permanent actions /solutions. | |
| Consider new and current technology for the solution. | |
| Incorporate the solution into future products. |
| Define and Verify Root Cause(s) |
| After the root causes of a problem are identified, investigate methods to fix the problem. Evaluate several approaches to solve the problem. A thorough analysis of different approaches to eliminate a root cause is a critical part of the problem solving process. | |
| The first approach to generate alternate solutions is to develop a cause and effect diagram. The team should brainstorm solutions. One alternative is to redesign the part or the manufacturing process. This approach should eliminate an opportunity for a problem to recur. | |
| Communicate closely with the customer. How the root cause is eliminated might impact the customer in some unforeseen way. Customers should have a chance to input their needs into the problem solution. |
| Define and Verify Root Cause(s) |
| If similar problems have been previously identified and solved, assess those solutions. As part of every investigation, identify similarly engineered parts or plant processes that may have experienced this problem. Again, these could be a source of alternative solutions. | |
| Avoid ‘band-aid’ fixes - this will help prevent future recurrence of the problem. Sometimes due to cost and/or product life a compromise is to implement interim actions permanently. However, this is considered the least acceptable solution. | |
| As part of investigating problem solutions, the team should look at new and current technology around an engineered part and/or the manufacturing process. New alternatives could come from advances in these areas. In some cases a thorough understanding of the current design and/or manufacturing processes produce efficient solutions. The team should remember that the solution needs to be incorporated in future products. |
| Define and Verify Root Cause(s) |
| Identify Potential Causes - Cause & Effects Diagram |
| Define the ‘effects’ for cause and effect diagram(s). | |
| Prepare a 5M, Process or Stratification cause & effects diagram for each effect (you may want to use a combination). | |
| Team members should each assume their activity causes the problem and ask themselves “How could what I do possibly generate the problem?” | |
| Prepare a time line analysis if the problem was not always present. Identify what changed when. | |
| Perform a comparison analysis to determine if the same or a similar problem existed in related products or processes. Identify past solutions and root causes which may be appropriate for the current problem. | |
| Identify the top few potential causes. Develop a plan for investigating each cause and update the action plan. | |
| Evaluate a potential cause against the problem description. Does a mechanism exist so that the potential cause could result in the problem? |
| Analyze Potential Causes - Validate Root Cause |
| Analyze Potential Causes | ||
| Use the iterative process to analyze each potential cause. | ||
| Hypothesis generation: How does the potential cause result in the problem? | ||
| Design: What type of data can most easily prove/disprove the hypothesis? | ||
| Preparation: Obtain materials and prepare a check list. | ||
| Data Collection: Collect the data. | ||
| Analysis: Use simple, graphical methods to display data. | ||
| Interpretation: Is the hypothesis true? | ||
| Investigate several potential causes independently. | ||
| Use an action plan to manage the analysis process for each potential cause being studied. | ||
| Validate Root Causes | ||
| Clearly state root cause(s) and identify data which suggests a conclusion. | ||
| Verify root cause factors are present in the product and/or process. | ||
| Conduct with / without study to verify root cause. Can you generate the problem? | ||
| Potential Causes - Some Questions |
| Have you identified all sources of variation on the flow diagram? | |
| Have all sources of information been used to define the cause of the problem? | |
| Do you have the physical evidence of the problem? | |
| Can you establish a relationship between the problem and the process? | |
| Do you continually challenge the potential root causes with the question ‘why’ followed with ‘because’ to construct alternatives? | |
| What are the is / is not distinctions? | |
| Is this a unique situation or is the likely problem similar to a past experience? | |
| Has a comparison analysis been completed to determine if the same or similar problem existed in related products? | |
| What are the experiences of recent actions that may be related to this problem? | |
| Why might this have occurred? | |
| Why haven’t we experienced this problem before? |
| Analyze What Has Changed |
| Manufacturing | ||
| New supplier(s)? | ||
| New tool(s)? | ||
| New operator(s)? | ||
| Process change(s)? | ||
| Measurement system? | ||
| Raw material(s)? | ||
| Vendor supplied part(s)? | ||
| Do other plants have a similar problem? | ||
| Engineering | ||
| Any pattern to the problem? | ||
| Geographically? | ||
| Time of year? | ||
| Build date(s)? | ||
| Did the problem exist at program sign-off? | ||
| Was it conditionally signed off? | ||
| Did the problem exist during pre-production prototypes, functionals? | ||
| Data and Root Causes |
| What data is available to indicate changes in the process? | |
| Does data exist to document the customer’s problem? | |
| If the potential cause is the root cause, how does it explain all we know about the problem? | |
| What is the likelihood that each potential cause could explain the described problem? | |
| What is the concern that the potential cause is actually occurring? | |
| What actions have been taken to the potential causes to assure their presence? |
| Product - Process Assumptions |
| Assumptions: | ||
| Features | ||
| Design | ||
| Process concepts | ||
| Technical innovations | ||
| Advanced materials | ||
| Reliability assessments | ||
| New technology | ||
| Document assumptions as part of project plan | ||
| Utilize as inputs to plan | ||
| Consider alternate paths in case assumptions do not play out | ||
| Errors 1 |
| Almost all errors are caused by human error. | |
| Forgetfulness - Sometimes we forget things when we are not concentrating. Example: A person forgets to set his/her alarm clock at night. Safeguard: Establish a routine which includes checking before going to bed. | |
| Errors due to misunderstanding - Sometimes we make mistakes when we jump to the wrong conclusion before we’re familiar with the situation. Example: A person used to a stick shift pushes the brake petal in an automatic thinking it is the clutch. Safeguards: Training, checking in advance, standardizing work procedures. | |
| Errors in identification - Sometimes we misjudge a situation because we view it too quickly or are too far away to se it clearly. For example, a $1 bill is mistaken for a $10 bill. Safeguards: Training, attentiveness, vigilance. |
| Errors 2 |
| Errors 3 |
| Process Failure Causes |
| 1. Omitted processing | |
| 2. Processing errors | |
| 3. Errors setting up work pieces | |
| 4. Missing parts | |
| 5. Wrong parts | |
| 6. Processing wrong work piece | |
| 7. Mis-operation | |
| 8. Adjustment error | |
| 9. Equipment not set up properly | |
| 10. Tools and/or fixtures improperly prepared |
| Process Control Examples |
| 1. Standardized work instructions/procedures | |
| 2. Fixtures and jigs | |
| 3. Mechanical interference interfaces | |
| 4. Mechanical counters | |
| 5. Mechanical sensors | |
| 6. Electrical/Electronic sensors | |
| 7. Job sheets or Process packages | |
| 8. Bar coding with software integration and control | |
| 9. Marking | |
| 10. Training and related educational safeguards | |
| 11. Visual Checks | |
| 12. Gage studies | |
| 13. Preventive maintenance | |
| 14. Automation (Real Time Control) |
| The Poka-Yoke System |
| Is Zero Defects a Reality? | ||||
| We have Quality Problems! |
| In American manufacturing, this statement leads to an unsatisfactory resolution to the problem. “We have Quality Problems” shifts the concerns from the undetermined true source (operation & process) to an area where the root cause never occurred (Quality Control) and the true cause is addressed and corrected through high cost inspection methods. |
| We Have a Quality Problem! |
| If we review the manufacturing structure and the functioning elements to which the product is going to be exposed to, we will be able to determine possible root causes to the problems prior to production. This is known as Quality Planning and if done properly can eliminate the need for the Quality Control. | |
| (Man, Material, Machine, Method, or Measurement) |
| Section One |
| Shingo And The Manufacturing Structure |
| Poka Yoke Defined |
| Shigeo Shingo defines Poka Yoke as: | ||
| Poka | ||
| “Inadvertent Mistake That Anyone Can Make” | ||
| Yoke | ||
| “To Prevent or Proof” | ||
| Process vs. Operation |
| Process | |
| Operation | |
| Operation & Process |
| Operation | |
| Some People Know How to Drive a Car! Driving is an Operation. | |
| Process | |
| Some People Know How to Repair a Car! Repairing is a Process. |
| Categories of the Process Function |
| A Process is the flow by which raw materials are converted into finished goods. | |||
| Processes fall into one of the following categories: | |||
| Work: Assembly, disassembly, alter shape or quality | |||
| Inspection: Comparison with a standard | |||
| Transportation: A change of location | |||
| Delay: Time during which no work, transportation or inspection takes place | |||
| Process Delays :Lot does not move until last item finished in process | |||
| Lot Delays: lot delayed in order to maintain 100, 99, 98 ... 2,1,0 | |||
| Categories of the Operation Function |
| An Operation is an action performed on material within the process. | |||
| Operations fall into one of the following categories: | |||
| Preparation/Adjustments Phase:(setup, tool change, adjustments) | |||
| Principal Operations Phase: Operations repeated in each cycle (hole punch, drill, sheer) | |||
| Main Operations (stamping, cutting) | |||
| Incidental Operations (movement of press, movement of people) | |||
| Marginal Allowances: | |||
| Fatigue | |||
| Hygiene (wash hands, etc.) | |||
| Operations (shut-down to produce rush order, meetings) | |||
| Work place (breaks, cleaning, maintenance) | |||
| 5 Elements of Production |
| Defining The 5 Elements |
| Objects of Production: Materials: Raw, Finished, Semi-finished, In-process | |
| Agents of Production: People, Machines, Tools, Jigs, Machine Tools, Incidental Devices, Inspection Equipment, The Environment, etc. | |
| Methods: Processing System, Load & Capacity Balance, Processing Conditions | |
| Space: Left to Right, Front to Back, Top to Bottom | |
| Time: Process Time, Production Time, Task Time |
| Changes in the Elements |
| When a change occurs in the Objects of Production: | |
| Methods or the means of action may change (How) | |
| Space or size and location may change (Where) | |
| Time (overall start to finish) or Timing (task start to finish) may change (When) |
| 4 Process Phenomena's |
| Shigeo Shingo’s Five Questions |
| A Problem (or Delay) Occurs ask | |
| Why? Describe. | |
| Why? Describe. | |
| Why? Describe. | |
| Why? Describe. | |
| Why? Response! |
| Section Two |
| Is There a Difference Between An Error and a Defect? |
| Reasons Why We Don’t Need Poka Yoke |
| Workers Possess Divine Infallibility | |
| Implementation Costs are High | |
| The World is not a Dynamic Environment | |
| It is Cheaper to Hirer Sorters | |
| Quality Control & Production Would Have Nothing To Do | |
| We are All Too Busy | |
| We use SPC for Improvements |
| Separating Error From Defect |
| Humans Make Errors (Cause), Defects Arise Because Errors Are Made (Effect). | |
| It is Impossible to Eliminate Errors From Tasks Performed by Humans. | |
| Errors Will Not Turn into Defects if Feedback and Action Takes Place at The Error Stage. | |
| Changing Occurrences can reduce Reoccurrence |
| Causes of Defects |
| Process Defects | |||
| Process Failure | |||
| Operational or Procedure Failures | |||
| Process Error | |||
| Incorrect or Imprecise | |||
| Product Defects | |||
| Incomplete Product | |||
| Substandard Product | |||
| Levels of Defects |
| Level 1: Defects Shipped out of Factory (Taylor Methods) | |
| Level 2: Defects Kept within Factory (Sheward Methods) | |
| Level 3: Defects Reduced (Juran/Demming Methods) | |
| Level 4: Defects Kept within Production Stage (Juran/Demming Methods) | |
| Level 5: Defects Not Produced (Shingo Methods) |
| Section Three |
| Inspection | |
| Taylor’s Plan | |
| Shewhart, Demming & Juran’s Plan | |
| Shingo’s Plan |
| Inspection Philosophies |
| 3 Methods of Inspection |
| Judgment Inspection (Taylor’s) | ||
| Inspection That Discovers Defects | ||
| Informative Inspection (Shewhart’s) | ||
| Inspection That Reduces Defects | ||
| Source Inspection (Shingo’s) | ||
| Inspection That Eliminates Defects | ||
| Judgment Inspection |
| Attribute Inspection of Product Which Discovers Defects at the End of the Process | ||
| Rework Costs | ||
| Process Costs of Nonconformaties | ||
| Scrap Costs | ||
| No Information about Process | ||
| SPC Inspection |
| Inspection of Product Which Reduces Defects at the End of Process Using Inner Process Checks | ||
| Inspection Costs | ||
| Delay Costs | ||
| Extra Equipment Costs | ||
| Scrap Cost Reduced | ||
| Information (Grading or Variable Data) Gained about Process | ||
| Source & Sequential Inspection |
| Inspection Built into the Operation using Poka Yoke Devices to Detect Errors Before They Become Defects | ||
| Pushes Defect Detection Up-front. Cost Reduced | ||
| Nonconforming Materials are not processed. | ||
| Eliminates need for SPC | ||
| Minimal Cost of Poka Yoke Devices | ||
| Reduces Steps in Process | ||
| Section Four |
| Efficiency & Waste |
| Production Efficiency & Waste |
| Melody | ||
| Flow Production | ||
| Rhythm | ||
| Tack Time (Level Production) | ||
| Harmony | ||
| Standard Operation Man, Machine, Material, Method, Measurement | ||
| Any Element Missing or Incomplete: We Have Noise. | ||
| (Waste) | ||
| Types of Waste |
| Stock Inefficiency | |
| Excess Stock Parts & Materials | |
| Transportation Inefficiencies | |
| Inefficient worker movement | |
| inefficient results from looking for things | |
| Selection inefficient | |
| Defective production |
| Cost Contributing to Waste |
| Materials | |
| Processing | |
| Depreciation | |
| Repairs | |
| Transportation | |
| Recalls | |
| Replacement | |
| Advertising |
| Section 5 |
| Shingo’s Method |
| Shingo’s Method |
| A Poka Yoke System uses Poka Yoke Devices Built into Source or Sequential Inspection Methods. | ||
| Properly Implemented, the System Can Achieve: | ||
| Zero Defects | ||
| Zero Waste | ||
| Zero Delays | ||
| Poka Yoke Devices, Systems & Inspection |
| Poka Yoke Systems | ||
| Control Systems | ||
| Halt the operations, and require feedback and action before process can resume. | ||
| Warning Systems | ||
| Uses signals to warn the operator that the operations needs feedback and action | ||
| SQC systems have fairly long periods of time between check stages and feedback execution | ||
| Poka Yoke Devices, Systems & Inspection |
| Poka Yoke Devices | |||||
| Are Built within the Process | |||||
| In General Have Low Cost | |||||
| Have the Capacity for 100% Inspection | |||||
| Remember SQC is performed outside the process which adds cost and allows defects to escape the system. | |||||
| Every Day Examples |
| Electrical Polarity Poka Yokes |
| Floppy Disk Poke-Yokes |
| Poka Yoke Devices, Systems & Inspection |
| Inspection with Poka Yoke | ||
| Source Inspection (ZQC) | ||
| Built into process | ||
| Leads to a zero defect Systems | ||
| Self Check Informative Inspections (SQC) | ||
| Built inside or outside immediate process | ||
| Reduces defects to a minimum | ||
| Successive Check Informative Inspection (SQC) | ||
| Built inside or outside sequential process | ||
| Reduces defects to a minimum | ||
| Section 6 |
| Tools For Assessment |
| Organizing Systems for Zero Defects |
| Questions to Ask About Present Systems |
| Can we take current informative inspection systems with successive checks and improve them to get a system of informative inspections with self-check methods? | |
| Can we take current informative inspections with self-check methods and improve them to get source inspection? | |
| Since informative inspections tolerate the occurrence of defects, can we take these methods and improve them to get source inspection in which the errors that cause defects are detected and prevented from turning into defects. |
| D5 Choose, Implement & Verify Corrective Actions |
| The 8-D System |
| Choose, Implement & Verify CA Objective |
| Choose, Implement & Verify Corrective Actions |
| By far the most critical step in the problem-solving process is to verify that the solution will in fact eliminate the problem. In addition, it is often the most difficult step. The most common method to evaluate a problem solution is to wait for implementation of the solution, then see if the problem goes away. However, too much time may be lost before conclusive information is available. Verification, where ever possible, should come before implementation. | |
| Several approaches to verification are available. In engineering, design verification and production validation testing provides significant information. In the short term, a bench/lab test can be used to verify. In some cases dynamometer testing can provide verification. Long term one can monitor fleet response. For manufacturing, verification is by in-plant indicators. SPC can verify the elimination of the problem. Sometimes scrap rate reports and conformance audits provide information. Sometimes a designed experiment is part of verification. |
| Choose, Implement & Verify Corrective Actions |
| Whatever verifications you choose, a detailed verification / action plan is required to outline who will be taking what actions by when. The action plan should show what data or statistics will be collected and analyzed, who is responsible and must track actual progress and scheduled completion. The action plan is the detailed Dynamic record of all phases of the problem solving process. | |
| Good problem solution verifies the customer is satisfied with the solution. If possible, involve the customer in choosing solutions. | |
| All verification of the problem solution will require decision analysis. Decision analysis is part of the cost and timing consideration of the solution. Decisions affecting cost must include effects on quality, future problem recurrence and complete elimination of the problem. In addition, management and operating procedures may be involved when choosing the solution. Evaluation of any adverse effects caused by the solution are important. The FMEA will most surely be affected. |
| Choose, Implement & Verify Corrective Actions |
| Choose, Implement & Verify Corrective Actions |
| Choose, Implement & Verify Corrective Actions |
| Run Pilot Tests | |
| Artificially simulate the solution to allow actual process or field variation. | |
| Field test the solution using pilot customer groups. | |
| Verify carefully that another problem is not generated by the solution. | |
| Monitor Results | |
| Quantify changes in key indicators. | |
| Stress the customer / user evaluation. |
| Confirmation Questions |
| Can you list and measure all of the indicators related to the problem? | |
| Which of the indicators are most directly related to the problem? Can you use the indicators to measure problem severity? | |
| Can you determine how often or at what intervals to measure the problem (hourly, shift, daily, weekly, monthly)? | |
| If there are no changes to the indicators after taking action, can you determine what to do? Will you need to take cause, action and verification measures? | |
| Do all indicators reflect conclusive resolution? | |
| Has the team prioritized the customer / user evaluation after implementation? | |
| What scientific methods are being used to verify effectiveness in the short term and to predict the outcome long term? |
| Verification Questions |
| Has the customer been contacted to determine a date when verification will be evaluated? | |
| What data has been established for follow-up? | |
| Has a time-line (project) chart been completed? | |
| Have field tests been conducted using pilot customer groups? | |
| Have dates been established when verification of effectiveness will be evaluated? |
| Corrective Actions Check List |
| D6 Implement Permanent Corrective Actions |
| The 8-D System |
| Implement Permanent CA Objective |
| Implement Permanent Corrective Actions |
| Implement Permanent Corrective Actions |
| Once the root cause(s) have been identified, the team establishes an action plan on the permanent actions to be taken. Again, the action plan includes who will do what by when. The permanent actions are implemented to solve the problem. The question “Why did this occur?” must be answered. | |
| Establish ongoing controls on the process to ensure the process remains in control. Once the permanent corrective actions are in place, the ongoing controls will verify the effects of the actions. | |
| To forecast reduction of the problem, indicators such as scrap reports, etc., can be used. A statistical plan will verify the effectiveness of the actions. A systematic approach involves a plan to establish the facts using data or evidence as a requirement for making decisions. Data is obtained by investigations and experiments to test assumptions. These assumptions are identified by translating the customer concerns into understandable definitions of what the problem is and relating these definitions of the problem to product and processes. These definitions and data are used to verify solutions. |
| Implement Permanent Corrective Actions |
| Once permanent solutions are in place, document the changes. In addition, all customers need to be informed about what actions were taken. In most cases, some type of training is required to institute permanent corrective actions. Training may be required to implement a product design or process change. In addition, implementation of the permanent actions may need to include the effect on design or process issues. In manufacturing, maintenance personnel often need to be informed of the changes. | |
| Another important part is to correct the obvious. This includes correcting defective parts already produced, changing product design, changing tooling, reworking defective machines and/or equipment, revising ineffective operating systems or working with and/or replacing suppliers. | |
| Contingency actions should be identified if for some reason the permanent actions cannot be implemented. For example, in manufacturing a recommendation to single source a part may be recommended. But, if one vendor is unable to meet the increased productivity alternate action is necessary. Contingency actions based upon risk assessment are essential to the success of permanent corrective actions for customer protection and problem solution. |
| Implement Permanent Corrective Actions Flow |
| Implement Permanent Corrective Actions Flow |
| Validation Evidence |
| Corrective Action Questions |
| Ongoing Controls - Questions |
| Forecast Outcome |
| Implement CA and Verify Over Time Check List |
| D7 Prevent Recurrence |
| The 8-D System |
| Prevent Recurrence Objective |
| Prevent Recurrence |
| Prevent Recurrence |
| This next step in the Problem-Solving Process is the seventh step. It is important to understand what in the process allowed the problem to occur. A cause-and-effect diagram can be used to outline the reasons the problem occurred. By asking “Because?” the C&E diagram can be constructed. | |
| Another effective tool is a process flow diagram. The process flow of the manufacturing or engineering process can be effective in identifying where in the process the problem could have been prevented. To prevent recurrence of the problem, most of the time a change to the management system will be required. Managers must understand why their system allowed a problem develop. The same system will allow future problems to occur. |
| Prevent Recurrence |
| Management systems, practices and procedures need to be fully understood to be effective. Most of them are carry-overs from previous model years and organized structures. Some are outdated and need to be revised. Understanding the elements of a management system can be achieved by maintaining an up-to-date flow diagram of the system and process. Also, there should be easy to follow instructions for those who are part of the system. | |
| Management systems, practices and procedures should provide management support for ‘Never ending improvement’ in all areas and activities. The system should encourage individuals to participate freely in the problem solving process. It should help to understand more about their job and how each individuals’ effort affects the outcome of the final product on customer satisfaction. The system should encourage everyone to learn something new. And it should recognize individual and team effort when these new skills are applied. |
| Prevent Recurrence |
| Changes in the management system can require documenting new standard procedures, streamlining to remove obsolete procedures and revising previous standards. Changes in the management system need to be communicated clearly to all customers. | |
| To prevent recurrence additional training is often required. Training may be needed in statistical techniques and methodologies, new engineering or manufacturing technologies or disciplines, better process and/or project management. | |
| If concerns develop regarding changes to the system, these issues will be addressed. A new team may need to be assigned with the authority to address the management system. |
| Prevent Recurrence Flow |
| Prevent Recurrence Questions |
| Prevent System Problems Check List |
| D8 Congratulate Your Team |
| The 8-D System |
| Congratulate the Team |
| Congratulate Your Team |
| The final step in a team oriented problem solving effort is to recognize the team’s collective efforts in solving the problem and show gratitude by applauding individual contributions. Management will need to determine the best way to recognize the team’s contribution to the origination. In addition, individual effort and talents need to be highlighted and rewarded. | |
| Team oriented problem solving involves risk taking, some conflict, hard work and participation by everyone. It includes a free exchange of ideas,, individual talent, skill, experience and leadership. The team approach, when led effectively, produces a driving force of individuals motivated and committed to solving a specific problem. |
| Congratulate Your Team |
| The form of recognition can vary, depending upon the complexity and severity of the problem. It is important to document what was learned while solving the problem so that this information can be used by others for planning. A description of the various actions carried out, together with the analysis and results obtained through the problem solving process, provide information that can be used to prepare a case study report. Case study reports include the purpose and objective, the procedure or problem solving steps followed, the data obtained through various investigative methodologies and the analysis of data in the form of results shown by charts and graphs, conclusions and recommendations. | |
| This final step in the problem solving process is to conclude the successful efforts of the team is to acknowledge the significance and value, in quantifiable terms, of solving the problem for the customer and for improving quality and productivity for the company. |
| Congratulate Your Team Flow |
| Congratulate Your Team Objective & Questions |
| Congratulate Your Team Check List |