Understanding Root Cause Analysis: BRC Global Standards
Understanding Root Cause Analysis: BRC Global Standards
6/1/2012
Contents
1. What is Root Cause Analysis? ................................................................................................... 1
2. Where in the Standard is RCA Required?................................................................................ 3
3. How to Complete Root Cause Analysis?.................................................................................. 3
4. Methods of Root Cause Analysis ............................................................................................... 5
4.1 The ‘5 Whys’:.............................................................................................................................. 5
4.2 Fishbone Diagrams: .................................................................................................................. 7
5. Common Mistakes ....................................................................................................................... 9
5.1 Unmanageable Conclusions .................................................................................................... 9
5.2 Duplication of the Immediate Corrective Action .................................................................. 10
5.3 People ....................................................................................................................................... 11
5.4 Proposed Action Plan Doesn’t Prevent Re-occurrence ..................................................... 12
5.5 Extra Checks ............................................................................................................................ 14
6. Preventative Action .................................................................................................................... 14
7. Additional Documentation ......................................................................................................... 15
8. Glossary of Terms ...................................................................................................................... 15
9. Appendices .................................................................................................................................. 16
9.1 Inclusion of Root Cause Analysis in the Audit Report ....................................................... 16
9.2 ‘5 Whys’ Route Cause Analysis Template ........................................................................... 18
9.3 Fishbone Diagram Template.................................................................................................. 19
Root cause analysis is a problem solving process for conducting an investigation into an
identified incident, problem, concern or non-conformity. Root cause analysis is a completely
separate process to incident management and immediate corrective action, although they are
often completed in close proximity.
Root cause analysis (RCA) requires the investigator(s) to look beyond the solution to the
immediate problem and understand the fundamental or underlying cause(s) of the situation
and put them right, thereby preventing re-occurrence of the same issue. This may involve the
identification and management of processes, procedures, activities, inactivity, behaviours or
conditions.
Step 1
Define the Non-Conformity
Step 2
Investigate the Root Cause
Step 3
Create Proposed Action Plan & Define Timescales
Step 4
Implement Proposed Action
Step 5
Verification & Monitoring of Effectiveness
It should be noted that this is a simplified process flow, which is typical of the majority of
situations required by the BRC Standards. However, for a complex non-conformity, such as a
serious incident involving a microbiological outbreak, root cause analysis will become
proportionally more detailed, require extra activities and can require considerable time. For
example, some or all of the following steps may be required:
An important part of any non-conformity management is the identification of the root cause
and the implementation of suitable action. There are a number of requirements in the BRC
Standards for root cause analysis:
There is no single prescribed method of conducting root cause analysis and any structured
approach to identifying the factors that resulted in the non-conformity could be used, many
tools and methods have therefore been published (two popular methods are highlighted
below). The choice of root cause methodology may be a matter of personal choice, company
policy or dependent on the type of issue/non-conformity being investigated. Some companies
Whichever method of root cause analysis is used it is usually necessary to commence with,
and record the known facts. Depending on the situation these may include:
Throughout the process it should be remembered that the key question that root cause
analysis is seeking to answer is: What system or process failed so that this problem could
occur?
In these situations the subsequent steps of the investigation and action can be planned
immediately.
On other occasions the cause is not immediately clear and investigative steps will be
required, for example:
Once this information is collated, it should be possible to draw conclusions or to establish the
areas where further focus/questions are required.
Once the underlying cause has been established, the next stage of the process is to
establish a proposed action plan, indicating the action that will be taken to prevent the non-
conformity recurring. The action plan should include a defined timescale in which the action
will be completed and define who is responsible for completion.
Once it is demonstrated that an action is fully embedded and effective, a review can
consider whether the additional monitoring is still required or can be reduced to a lower
frequency.
The ‘5 Whys’ is the simplest method for structured root cause analysis.
It is a question asking method used to explore the cause/effect relationships underlying the
problem. The investigator keeps asking the question ‘Why?’ until meaningful conclusions are
reached.
Root
Why? Why? Why? Why? Why? Cause
An operator is instructed to perform a simple action ‘weigh out ingredient A’, however the
operator inadvertently used ingredient B instead.
In this example it would be easy for the investigator to stop the analysis part way through
thinking that all the conclusions had been reached (ie that this was purely a training issue),
however, the further questions reveal useful information about the nature of the cause and
therefore the appropriate action.
The issue actually had a number of causes that contributed to the incident:
Update training procedure to ensure sign off (& possibly a supervision step)
Replace ingredient labels – if practical with ones that cannot be removed.
If labels must occasionally be removed, ensure that post cleaning line checks include
A second commonly used method of root cause analysis, is the use of fishbone diagrams
(sometimes referred to a Ishikawa models or Herringbone diagrams). They are most useful
when the ‘5 whys’ is too basic, for example, where a complex issue needs to be considered
in bite size pieces or where there is a lot of data that needs to be trended.
In the diagram, the various causes are grouped into categories (such as equipment,
materials or processes) and the arrows in the image indicate how the causes cascade or flow
toward the non-conformity.
Equipment – this should include consideration of all equipment that could have a role
in the non-conformity, for example, production line, facilities, computers or tools
Processes or Methods – how work is performed, policies, procedures, rules or work
instructions
Measurements – any data collection or measurement, either from a process or
subsequent to the non-conformity, for example metal detection records, check
weights or final product analysis
Materials – any information relating to raw materials or final products, for example raw
material specification or goods receipt checks for a specific batch of ingredient.
Environment – The location, time, temperature, culture, standards of cleanliness or
available time, for an activity.
People – Any role involved in the implicated process.
For example:
As with the ‘5 Whys’ it is important to initially investigate the cause and then examine the
cause of the cause to ensure the root cause has been correctly identified (fishbone diagrams
sometimes refer to this as examining primary and secondary causes).
Using the same scenario as for the ‘5 Whys?’ in which an operator is instructed to perform a
simple action ‘weigh out ingredient A’, however inadvertently uses ingredient B. The causes
would be tabulated as discovered and proposed action developed:
To help users avoid a number of common mistakes, which are known to hinder the formation
of quality proposed action plans, an explanation of each mistake given below. This
explanation includes an example of the incorrect approach (indicated by an ‘X’), which is
immediately followed by the same non-conformity being accurately investigated, leading to a
better proposed action plan (indicated by a ‘’).
The root cause should be something that can be managed or changed, which means that it
normally relates to a system or process and occasionally an alterable behaviour. For
example, it is often tempting to reach a conclusion such as ‘they forgot’, ‘not enough time’,
‘not enough money’, ‘not enough staff’, ‘staff sickness’ or ‘made a mistake’, these answers
may be true, but in most cases they are out of our control, whereas root cause analysis
should lead to controllable, manageable or adjustable processes. If these answers are
evident it is worth going back into the process to establish whether there is any other cause,
for example by asking specific questions such as, ‘Why did the process fail?’ or ‘What system
allowed the mistake to be made?’
For example:
This example again highlights that in practice there may be more than one cause (no
deputies, out of date policy and a lack of training) and therefore the proposed corrective
action plan may require multiple actions.
For example:
calibrated devices.
Actions in case of an
nor installation policies
documented the need to define
these criteria before use of new
the device is incorrect or out of out of calibration device equipment.
BRC026 Issue 1 Understanding Root Cause Analysis
Released 13/6/2012 Page 10 of 20
calibration range were not documented.
defined. PAP: HACCP procedures reviewed
and updated to ensure that all
steps are documented and the
requirement to validate any
changes to CCPs is documented in
the policy.
Policies regarding the purchase
and installation of new equipment
also updated to reflect requirement.
All relevant staff (HACCP team and
production managers) trained in
new requirements
5.3 People
For example:
Throughout the process it must be noted that root cause analysis is not designed to
establish who is to blame for a non-conformity, but to correct the underlying cause and
prevent re-occurrence.
Occasionally, despite root cause analysis and the implementation of a proposed action plan
the non-conformity re-occurs. There are a number of potential reasons why this might
happen, including:
In these situations it may be necessary to re-visit the root cause analysis and identify
additional causes and appropriate controls.
Example 1:
Example 2:
This example again highlights that once actions have been implemented best practice is to
introduce monitoring or verification activity to demonstrate that the action has effectively
prevented re-occurrence of the non-conformity. (It should be noted that clause 1.10.1 of the
Food Standard requires senior managers to ensure that the root causes have been
effectively addressed, monitoring and verification activity can be used as evidence, not only
to the site’s management, but also for the auditor).
Whilst extra checks are often required for verification or monitoring (refer to section 3), it is
preferable that the proposed action plan is not solely an extra check(s). The reason for this is
twofold:
For example:
6. Preventative Action
Although not specifically required by the BRC Standards, good practice is to ensure that once
a root cause and proposed action plan is identified, consideration is given to whether any
other systems, processes or procedures are susceptible to the same failure. Where
appropriate, this provides an opportunity to introduce preventative action on these other
systems before a non-conformity actually occurs.
When documenting the root cause investigation and output good practice is to include:
8. Glossary of Terms
Root Cause: The underlying cause of the problem which, if adequately addressed, will
prevent a recurrence of that problem.
Corrective Action Plan: Following an audit, sites in the Enrolment Programme are required
to develop a Corrective Action Plan which outlines the non-conformities observed during the
audit and the action that has/will be taken to address the non-conformity.
Proposed Action Plan: Following root cause analysis, the site must develop a proposed
action plan to correct each of the root causes, such that they prevent recurrence of the non-
conformity.
Preventative Action: On some occasions, root cause analysis will identify an underlying
cause that indicates systems or processes other than that with the current non-conformity,
are susceptible to the same failure. In these situations, in additional to the normal proposed
action plan, it is good practice to complete preventative action on the implicated systems
before a non-conformity actually occurs.
Evidence provided
No Requireme Details of non- Corrective action document, Date
nt ref.
Root cause analysis and proposed action plan Reviewed by
. conformity taken photograph, reviewed
visit/other
1 3.4.1 Internal audit of Audit now Root Cause: Copy of audit reports 2012-08-06 M Oliver
supplier completed as Procedures didn’t recognize the need for deputies
management have audits and therefore no alternative staff had the
systems scheduled for appropriate qualifications/ training when key staff
scheduled for October, were on long term sickness.
January had not November and
been carried out. December. Proposed Action:
Internal audit procedures updated to incorporate
deputies. The size of the internal audit team will be
increased to include sufficient members. These staff
will be trained, as appropriate, for the systems to be
audited.
Proposed Action:
1) procedures updated to incorporate deputies. The
size of the internal audit team will be increased
to include sufficient members. These staff will be
trained.
2) Review format of Incident procedure to facilitate
less frequent or easier updates. For example, by
including roles (& deputies) in the main
procedure and appending a spreadsheet with
names, contact details etc.