Problem Solving Process

  • November 2019
  • PDF

This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA


Overview

Download & View Problem Solving Process as PDF for free.

More details

  • Words: 2,452
  • Pages: 9
TDM Problem Solving Class

Problem Solving (8D Emphasis)

Emergency Response Action: (ERA) Actions applied to stop the internal or external customer from receiving the problem (i.e. quarantine, tagging, segregating, etc.). Also known as Containment. Interim Containment Action: (ICA) A temporary solution to protect the customer from the problem. ICAs usually add cost to the process (100% inspection, etc.) and is used to "buy time" until the ROOT CAUSE can be identified and corrected. Permanent Corrective Actions: (PCA) Actions applied to prevent a previously identified problem from recurring (new training, visual aids, mistake proofing, etc.). Continuous Improvement: Action applied to a procedure or process that improves cost or timing, simplifies the operation or prevents a perceived problem from occurring. Serious consequences occur when the underlying symptoms are not addressed, when the quick fix is accepted as a final, permanent solution. Excessive reliance on containment or ERAs will create a repeating cycle. Problem containment is an addiction that will only get worse until root causes are found and addressed.

Prepare for the Problem Solving Process

In response to a symptom, evaluate the need for the problem solving process. If necessary, provide an Emergency Response Action to protect the customer and initiate the process. (See Flow Chart 1) Application criteria: • The symptom(s) has been defined and quantified. • The customer(s) who experienced the symptom(s), and the affected parties, when appropriate, have been identified. • Measurements taken to quantify the symptom(s) demonstrate that a performance gap exists AND/OR priority of the symptom warrants initiation of the process. • The cause is unknown. • Management is committed to dedicate necessary resources to fix the problem at the root cause level and to prevent recurrence. • Symptom complexity exceeds the ability of one person to resolve.

Establish Team

Establish a small group of people with the process and/or product knowledge, allocated time, authority, and skill in the required technical disciplines to solve

the problem and implement corrective actions. The group must have a designated Champion and Team Leader. The group begins the team building process. (See Flow Chart 2)

Describe The Problem

Describe the internal/external customer Problem by identifying "what is wrong with what" and detail the Problem in quantifiable terms. (See Flow Chart 3)

Interim Containment Actions

Define, verify, and implement the Interim Containment Action (ICA) to isolate effects of the problem from any internal/external customer until Permanent Corrective Actions (PCAs) are implemented. Validate the effectiveness of the containment actions. (See Flow Chart 4) STEP 1 – Select an ICA An ICA is kept in place until a verified Permanent Corrective Action can be implemented. In some cases, the ICA may be the same as or similar to the Emergency Response Action. However, an ERA is implemented with minimal supporting data. An ICA provides more opportunity for investigation. Any ICA you implement must protect the customer from the problem without introduction any new problems. Also, a single ICA may not be enough. You may need to implement more than one ICA to fully protect the customer. STEP 2 – Verify an ICA An ICA can be any action that protects the customer from the problem. However, before you implement an ICA, you need to verify that the ICA will work. When you verify an ICA you: • Prove, before implementation, that it will prevent the customer from experiencing the problem. • Provide a before-and-after comparison. • Prove that the ICA will not introduce any new problems. Methods of verification may include: • Test – For example, a weld pull test would verify that a change to a welded component has achieved the desired performance level. • Demonstrations – A visual test would determine if a change in a component's handling system eliminates damage without creating a new problem. • Comparisons between the ICA and similar proven actions • Reviews of design documents such as policies, procedures, drawings, and specifications to evaluate if an ICA has accomplished what was intended without introducing a new problem Conduct trial runs whenever possible. However, in some situations, your verification may simply be a matter of common sense. For example, if an ICA involves stopping the shipment of all products, you can be sure that customers will stop experiencing the problem. Yet, this might create additional problems for

your and your customers. If your customers don't get any of your products, they might be forced to go to another vendor. You and your team must consider all of the trade-offs connected to your ICA. STEP 3 – Implement an ICA An important part of implementing an ICA is planning how you will implement the action. To implement an ICA: • Follow the management cycle – Plan (Re-plan) – Do (Implement) – Study (Monitor) – Act (Evaluate) • Create an action plan The management cycle is a process for making and effectively implementing decisions or actions.

Identify the Root Cause

Isolate and verify the Root Cause by testing each possible cause against the problem description and test data. Also isolate and verify the place in the process where the effect of the Root Cause should have been detected and contained (Escape Point). (See Flow Chart 5, 6, & 7) STEP 1 – Review the problem description • The problem description describes problems in terms of what, where, when, and how big. • The description should contain facts (observations) not assumptions. • All information must be gathered before identifying the root cause can begin. Make sure both of the above factors are true before you move to the next step. Consider any new information that the team may have gathered since completing the initial problem description. STEP 2 – Complete a comparative analysis for change-induced situations Once you've reviewed the problem description, you can begin a comparative analysis. A comparative analysis help you identify relevant changes in a change-induced situation. Then you can reduce the number of possibilities that you must consider to determine root cause. To complete a comparative analysis: • Ask yourself, "What is unique, peculiar, different, distinctive, or unusual about the symptoms? • Consider features such as people, methods, materials, machines, and the environment. • List all facts without prejudice as to the possible cause. • Keep in mind that the differences: o Are facts o Are unique to the symptoms Next, consider each difference you listed, and look for changes. • Ask: "What has changed in, on, around, or about this difference?"

• • •

Keep in mind that each difference may not have a corresponding change. List the changes next to the "difference" Look at the dates each change occurred. You may be able to eliminate some changes if they occurred after the problem started. • Consider categories of people, machines, methods, measurements, or the environment. If the problem is change-induced, the root cause must be the result of a change relative to one or more of the identified changes. It's important to remember that you haven't yet moved from the "observations" phase of the process. Any information you develop in a comparative analysis must be facts, not opinions, and must be true only for the symptoms information. Don't rule out any facts that might be valid answers. If it is a fact and it answers the question, write it down. STEP 3 – Develop Root Cause Theories Now that you've narrowed down the possible root causes, you need to develop theories about how the problem occurred. Theories are statements of ways that the changes may have created the problem. To develop your theories: • Use brainstorming techniques to generate ideas. • Ask: "How could this change have caused the problem?" Continue to ask the question until all possible theories are developed. • List at least one theory for each change. • List each theory individually on the worksheet. • List every possibility, no matter how strange or unlikely. Don't reject or qualify any theory. • Start with the simplest single change/single variable theory first. Then work up to more complex theories. • Be specific. Don't use generalities such as "poor quality" or "doesn't work." Remember to defer critical thinking at this step in the process. You will eliminate possibilities at the next step. STEP 4 – Test the Theories To test a theory, do the following: • Ask: "Does this theory explain the symptoms and data? If so how?" • Test the theory against each individual condition. • If the theory could explain the problem, but you don't have enough information to fully explain why it happens. You may need to gather more data to prove or disprove these theories. • Test simple (single change) theories first. Test highly complex or interactive theories last.

The root cause must explain all known data. Any theories that pass the trial run are most likely causes. If only one theory passes the trial run then verify this theory as the root cause. However, more than one theory may pass the trial run. In those cases (and when practical and feasible), collect and analyze any missing data for uncertain theories and reexamine information to resolve uncertainties. If additional information reveals that a theory cannot fully explain why the problem happens eliminate it from consideration. If it is not feasible to gather and evaluate additional information, try to verify each remaining theory. Start verification with the theory that best explains the symptoms. STEP 5 – Verify the Root Cause Once you've determined the most likely cause(s), verify that it actually causes the problem. Verification is the proof you need to confirm that you have identified the root cause. Verification is done passively and actively: Passive verification is done by observation. o Look for the presence of the root cause without changing anything. o If you can't prove the presence of the root cause, then this identified cause is probably not the root cause. • Active verification is done by manipulating the root cause variable. • Implement and remove the root cause variable to make the problem "come and go." • Both "coming" and "going" are essential tests to confirm the root cause. There can be more than one verified root cause. •

STEP 6 – Determine and Verify the Escape Point After you've determined and verified the root cause, you need to determine the escape point of the problem. An escape point is the point closest to the root cause at which the problem could have been detected but was not. A control system is a system deployed to monitor the product/process and ensure compliance to quality requirements. A control system consists of responsibilities, procedures, and resources. A control point is a location within the control system at which the ;product/process is checked for compliance to the quality standards. A product or process may have more than one control point within the system. When you identify the escape point, you can work to improve or establish a system to ensure that if problems occur, they will not go undetected. To understand how the problem escaped to the customer and identify the escape:



Review the process flow focusing on the location in the process where the root cause occurred. • Determine if a control system exists to detect the problem. If non exists, the development of a new control system must be considered in the problem solution. If a control system currently exists: • Identify the control point closest to the root cause. • Determine if the control point is capable of detecting the problem. If the control system is not capable, the development of an improved system must be part of the problem solution. If the control point is capable of detecting the problem, then the control point is the verified escape point.

Choose and Verify Permanent Corrective Actions (PCA's) for Root Cause and Escape Point

Select the best Permanent Corrective Action to remove the Root Cause. Also select the best Permanent Corrective Action to eliminate Escape Point. Verify that both decisions will be successful when implemented without causing undesirable effects. (See Flow Chart 8) Steps for PCA selection: • Establish Decision Criteria (What is feasible, Value added, etc.) • Identify Possible Actions. • Choose the "Best" Permanent Corrective Action (PCA) • Test & Verify the PCA • Re-evaluate the ICA & PCA for Escape Point.

Implement & Validate Permanent Corrective Actions

Plan & Implement selected Permanent Corrective Actions. Remove the Interim Containment Action. Monitor the long-term results. (See Flow Chart 9) Steps for PCA implementation: • Develop Action Plan for PCA. • Implement PCA Plan • Remove ICA and Evaluate PCA for Escape Point • Perform Validation • Confirm with Customer, using the symptom measurable, that the symptom has been Eliminated.

Prevent Recurrence

Modify the necessary systems including policies, practices, and procedures to Prevent Recurrence of this problem and similar ones. Make Recommendations for systemic improvements as necessary. (See Flow Chart 10)

Steps for Preventions: • Review the History of the Problem • Analyze how this problem occurred and escaped • Identify affected parties & opportunities for similar problems to occur and escape • Identify the System's, Policies, Practices, and Procedures that allowed this problem to occur and escape to the customer • Analyze how similar problems could be addressed • Identify and choose Preventive Actions • Verify Preventive Actions • Verify Effectivity • Develop Action Plan • Implement Preventive Actions • Develop Systemic Preventive Recommendations • Present Systemic Preventive recommendations to Process Owner.

Recognize Team & Individual Contributions

Complete the team experience, sincerely recognize both Team and Individual Contributions. (See Flow Chart 11) Steps for Recognition: • Select key documents and provide for their retention. • Review the team's process and document team Lessons Learned. • Recognize the entire team's collective efforts in solving the problem. • Mutually recognize all contributions to the problem solving process. • Celebrate completion.

Points to Remember 1. There is no such thing as perfection. Products and services can always be improved. If one process has been optimized, others can be enhanced.

2. Change is not always good. Looking for opportunity to make improvements does not mean looking to change everything. Think of the reason for change.

3. What is adequate today will not be tomorrow. Change never ceases, especially our industry. Even if we have reached the top in our field, tomorrow someone will redefine “the top”. Continuous improvement requires all to be more than just sufficient, the bar is always rising.

4. What works and what seems logical are different. For each theory that works, 99 others do not. Ideas deserve to be tested. They must be before they are accepted.

5. Realize that each new idea may create new problems. Watch for the potential repercussions of each quality improvement you make. Check your finished product against a list of quality objectives.

Related Documents

Problem Solving Process
November 2019 0
Problem Solving
October 2019 34
Problem Solving
November 2019 33
Problem Solving
July 2020 18
Problem Solving
June 2020 25