RCCA turns failures into future success

Failure analysis methodologies like root cause corrective action give organizations tools to uncover problems and improve processes.


Root cause corrective action (RCCA) is a term used to describe a reactive problem solving process using the Eight Disciplines (8D) methodology. Reactive is a negative term. People tend to view being assigned RCCAs as negative (since they are generally in response to an event), but a positive spin is that, properly done, RCCA helps us learn about new failure modes, create more robust products and processes and hopefully prevent future issues.


The 8D problem solving model was developed by the Ford Motor Co. as a methodology to analyze and prevent problems, failures and errors. It consists of eight steps that guide a problem-solving team through the process of analyzing an issue, discovering the causes and recommending actions to prevent recurrence. By working within this framework, manufacturing organizations can improve products and better serve customers.


The steps of 8D are as follows:

V2N2 quality table


At Cypress Semiconductor Corp., we have evolved several different RCCA templates but all follow the 8D model. Let's take a closer look at the critical elements of the process and common pitfalls to avoid.


Doing it right

D1: Form the team/team composition: This critical step requires that you assemble a team with cross-functional membership such that diverse viewpoints and process interactions are all taken into account.


D2: Describe the problem: It is imperative that the problem is defined properly and that the description is updated as new learning occurs. A common failure mode here is to only define a problem by what you initially think you know about it. Just as important is what you do not know (part of the investigation) as well as refining the problem statement as you learn. Tools that exist to help define the problem include the timeline and the “is-is not” analysis.


D3: Containment (implement and verify): It is expected that containment be implemented as quickly as possible. Some automotive customers want containment in place within 24 hours, for example. A common error is to delay implementing containment as a way to avoid quarantining too much material, but you should always err on the side of protecting the customer from receiving potentially bad product. If necessary, you can shut down multiple process steps and then release each one as it is eliminated as contributing to the problem. You must demonstrate the effectiveness of your screens to prove to yourself (and customers) that the organization can prevent defective material from being shipped. This is especially true if additional screens such as testing or inspections are required.


D4: Define and verify the real root causes: This step is extremely important in that you can often be led astray by contributing factors that are not necessarily the real root cause. The fishbone (Ishikawa) diagram is a good tool to use to list all of the possible contributing factors—often the main fish bones are broken out by man, machine, method and materials (see figure 1). Sometimes management and environment are also used as main fish bones.


V2N2 quality fig1


Figure 1: Example of a fishbone (Ishikawa) diagram showing potential causes.


The 5-Why tool is the preferred method used to nail down the real root cause. 5-Why analysis is a structured inquiry process that begins with the failure mode and involves asking a series of questions designed to analyze events in order to discover an opportunity to correct the problem for future reference. (Note, some Japanese companies have begun working more frequently with fault-tree analysis.) Proof that you have found the real root cause would be to demonstrate that you can toggle the defect or failure mode from existing to not existing depending on whether or not the organization implements corrective action.


For engineering-focused organizations, it can be easy to get caught up in solving the technical root cause of a failure and forget about addressing the important contributing factors. At Cypress, our 5-Why tool requires us to investigate these factors (see figure 2), in particular looking for:


  • The escape root cause—how the defect escaped detection to reach the next step (or the customer)
  • The business process/management root cause—the set of conditions that led to the creation of the defect

This management root cause analysis was validated in a recent 8D training session with a top automotive customer.


V2N2 quality fig2


Figure 2: Tools like 5-Why analysis broaden failure assessment from finding the technical root cause to addressing key contributing factors such as escape root cause that allowed the failure to go undetected and process/management root causes that led to the creation of the defect.


D5: Choose/verify corrective actions: Choosing real corrective actions means that you must show evidence that our corrective actions address the real root cause (verification). You should also provide corrective actions for the escape and business process/management root causes. It can be tempting to “dumb down” the management root cause—no one wants to admit that they deliberately chose a course of action that contributed to this failure (for example, focusing on cost reductions, ease of implementation, short-term solutions). This would be the time to confront these issues and determine whether this is still the right decision for the longer term now that it has been identified as leading to failures.


D6: Implement corrective actions: This step naturally flows from the D5 step. It requires objective evidence of the implementation of the corrective action with additional validation data showing the problem has been addressed. Objective evidence would include changes to the control plan, new statistical process control (SPC) charts/limits as well as engineering change notices (ECNs) to revise specifications and/or procedures. A bonus here would be to provide evidence of the effectiveness of these changes, backing up the claims made in D5.


D7: Prevent recurrence/fan out: Next to identifying the real root cause and implementing the corrective action, this is the most critical step because it involves fan out to other related processes, devices and sites, including external locations. Done with thoughtful consideration, this step can be the proactive portion of the exercise that enables us to prevent further incidents. Objective evidence of this activity would include updates to failure-mode effects and analysis (FMEA) documentation, updates to design specifications, updates to business processes/methodologies as well as external site (baseline) specifications.


D8: Congratulate your team: Take care to acknowledge contributions and their value to the company.


In this highly technical, fast-paced industry, problems are impossible to avoid entirely. The key to staying competitive and delighting customers is to have fewer problems than the competition. When problems arise, they need to be small, of minimal impact to customers and quickly contained. Finally, you need to treat RCCAs (8Ds) as important and positive opportunities to learn. Approach corrective action with objectivity and diligence, and if you take the prevent-recurrence (fan out) activity seriously, you can prevent new events and proactively improve your products and business processes.


Also in this issue:

AS-MCUs bring TFT HMIs to cost-sensitive home appliances

Answers to your data-retention specs and testing questions

Accelerate product development with Bluetooth® low energy modules

PSoC controllers speed design of smart home appliances

Prequalified APIs and software keep white goods safe

Bus Analyzer uncovers root cause of failure in flash-enabled systems

How to implement liquid-level measurement using capacitive sensing technology

Get More from Core & Code Subscribe

Leave a Reply

Your email address will not be published. Required fields are marked *

Other stories in this issue

Product Spotlight

AS-MCUs bring TFT HMIs to cost-sensitive home appliances

With a powerful graphics processor unit (GPU) and onboard VRAM, application-specific MCU designed for the white-goods market speeds HMI design while controlling costs.