Managing Risk and Improvement in the Extended Enterprise via Corrective Action

Both continuous improvement and risk management are considered minimum compliance process requirements in the latest versions of Quality Management System (QMS) regulatory standards including ISO9001, AS9100, and ISO13485. Corrective and Preventive Action (CAPA) projects can be used to manage both risk mitigation and process improvement types of projects. 

When we look at processes in the entire product lifecycle starting at the supplier, continuing through manufacturing into aftermarket maintenance and repair services on the product, we find the following sources for potential CAPA projects:
• Audit Findings
• Inspection Findings
• Discrepancy Reports
• Equipment Maintenance Trouble Calls
• Product Warranty Claims
• Customer Complaints
• Performance Metrics Analysis

Whether a project is needed to mitigate risk or improve performance, many of the steps we follow are common and merit a similar discipline. Lean Manufacturing and Six Sigma practitioners use slightly different terminology and methodologies for process improvement, but they are really more similar than different.

Six Sigma practitioners use the DMAIC process to systematically reduce variability in a manufacturing process. Lean practitioners refer to the Toyota problem solving methodology and to kaizen events.

For diving down into specific urgent issues once they are uncovered, the Toyota Problem Solving process and the 8-Discipline (8D) process are very similar. The 8-Disciplines (8D) process is often used because it adds steps to contain the problem.

The Toyota Problem-Solving process and the 8D process have a lot of similarities but in many ways do not exactly align. The 8D process has an emphasis on corrective and preventive actions which are more appropriate to obvious quality issues, and the Toyota Problem-Solving process has more emphasis on defining the problem which might not be obvious on productivity issues.

Form the Team – The 8D process recognizes the importance of assembling the right team and places it as the first step. A small team is needed with the right mix of skills, experience and authority to resolve the problem and implement solutions. Ensure that everyone on the team has the time and inclination to work on the problem together. Formal meetings should initiate the effort and monitor progress. The company’s Corrective Action Database should be used to document findings, decisions and progress.

Describe the Problem – It is critical to define a clear problem. The problem statement provides the starting point for investigation. Terms used in the description must be understood by the entire team. Problem description should include the following:
(a) Who – Who is affected by the problem? Who first observed the problem? To whom was the problem reported to?
(b) What – What type of problem? What has the problem? What is or isn’t happening? What is the physical evidence?
(c) When – When did it first happen? When was it first observed? Is it a recurring problem? How often? What is the trend? (random, cyclical, continuous) Has it been observed before?
(d) How Much – What is the magnitude of the problem? How many units or components are affected? How much cost (labor and material) is associated to this problem?
(e) Why – Why is it a problem? What is the impact? What processes are affected? Is production stopped completely or partially? Is there a work-around? Are customer delivery dates impacted?

Some of the questions above might also be viewed as assessing the risk and impact of a potential problem recurrence. The risk can be given a risk score by multiplying a Likelihood Rating, Severity Rating and a Detectability Difficulty Rating.

Contain the Problem – Identify interim containment actions to prevent further cost impact from the problem. Is the problem tied to a machine? Is it tied to a supplier component? Are more lots affected by this problem? Suppliers must be informed as soon as possible about issues to prevent further shipments with problems. Inventory parts which might be affected must be identified and inspected. If problem has a life- threatening consequence, products in the field have to be identified for potential recall.

Identify the Root cause – An investigation and failure analysis is performed to determine the root cause of the problem. It is not enough to identify the first-level or intermediate-level causes of the problem. The true root cause has to be uncovered and corrected or a similar problem will eventually manifest itself.

Root cause analysis may start with brainstorming sessions among team members and move on to data analysis that further explores multiple potential causes. Different kinds of charts and diagrams are used in data analysis including histograms, Pareto charts, scatter charts, and concentration and affinity diagrams.

It is important to document the analysis discussion, findings and conclusions using cause-and-effect charts and fault tree diagrams. A five-whys type of analysis is also useful to understand all the intermediate-level causes between the root cause and the problem manifestation.

Corrective Actions – This discipline entails identifying all possible corrective actions to address the root cause of the problem. The owners of the corrective actions, the target dates for completion and the rationale behind each should be documented. It is sometimes a good idea to have a preliminary evaluation of the corrective action to test its effectiveness before wasting time and money on fully implementing an incorrect solution.

Corrective action includes further containment of potentially affected similar production or inventory based on the root cause identified. If problem has a life-threatening consequence, products in the field have to be identified and notifications issued for recall or repair.

Permanent Correction – Once the corrective actions have been defined and tested, the next step it to implement them and verify their effectiveness. If the corrective actions are found to have deficient effectiveness it might be necessary to return to the prior step and create new corrective actions.

Preventive Actions – Lessons learned from the above investigation and corrective actions might be able to benefit other processes or areas with similar vulnerabilities even if not affected under the current situation. Preventive measures should be outlined if it is possible to prevent similar problems in the future. Preventive actions, like corrective actions, require owners and target dates.

Acknowledge Success – The last step of the 8D process is management’s formal recognition of the accomplishments of the team. This demonstrates the commitment of the management team to the continuous improvement process and is good internal publicity for the effectiveness of these initiatives.

 

Comments

[Merveil Nzitusu]

Hello!

I am a student and for my graduation thesis,i would like to develop a (mobile) application for monitoring "breakage" in companies. For example, a manufacturing company with hundreds of different machines will have various technical problems. The application would allow with a smartphone to create a request to the appropriate team according to breakage that may affect someone to repair and have a follow-up of each step (Request, assignment, start of work, end of work, approval.)
The company then has statistics on the time to solve a problem. The application would take a photo of the break, scan a barcode on the machine to identify it and know its location, priority)

My problem is that I do not have any knowledge about these different steps, I would like to have much more information on how this is going in a real company

[Conrad]

Check out MIMOSA standards and use cases for data exchanges monitoring machines for maintenance purposes and triggering maintenance orders with EAM systems. Also OAGIS and ISA95 standards for talking to MES and ERP systems for scheduling the maintenance time and updating production schedules. Scenarios like these are currently being documented in a paper coming out pretty soon from NIST.gov. It talks about how we can leverage and bridge across different standards domains to thread business processes digitally that used to be handled in silos.