EN 9136:2018

SLOVENSKI STANDARD
01-julij-2018
Aeronavtika - Analiza izvornih vzrokov in reševanje težav (metodologija 9S)
Aerospace series - Root cause analysis and problem solving (9S Methodology)
Luft- und Raumfahrt - Ursachenanalyse und Problemlösung (9S Methodik)
Série aérospatiale - Analyse de cause racine et résolution de problème (9S
méthodologie)
Ta slovenski standard je istoveten z: EN 9136:2018
ICS:
03.120.01 Kakovost na splošno Quality in general
49.020 Letala in vesoljska vozila na Aircraft and space vehicles in
splošno general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EN 9136
EUROPEAN STANDARD
NORME EUROPÉENNE
May 2018
EUROPÄISCHE NORM
ICS 03.120.10; 49.020
English Version
Aerospace series - Root cause analysis and problem
solving (9S Methodology)
Série aérospatiale - Analyse de cause racine et Luft- und Raumfahrt - Ursachenanalyse und
résolution de problème (9S méthodologie) Problemlösung (9S Methodik)
This European Standard was approved by CEN on 20 November 2017.

CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this
European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references
concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN
member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management
Centre has the same status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2018 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 9136:2018 E
worldwide for CEN national Members.

Contents Page
European foreword . 3
Rationale . 4
Foreword . 4
Introduction . 5
1 Scope . 6
1.1 General . 6
1.2 Purpose . 6
2 Normative references . 6
3 Terms and definitions . 6
4 General Process . 9
4.1 Basic Principles . 9
4.1.1 Cultural Change . 9
4.1.2 Effective Communication . 10
4.2 When to Apply a Structured Root Cause Analysis and Problem Solving Process . 10
4.3 Process Step Description . 12
5 Process Steps . 14
5.1 Step 0 – Start Immediate Containment Actions . 14
5.2 Step 1 – Build the Team . 16
5.3 Step 2 – Define Problem . 18
5.4 Step 3 – Complete and Optimize Containment Actions . 20
5.5 Step 4 – Identify Root Cause(s) . 21
5.6 Step 5 – Define and Select Permanent Corrective Actions . 23
5.7 Step 6 – Implement Permanent Corrective Action and Check Effectiveness . 24
5.8 Step 7 – Standardize and Transfer the Knowledge Across Business . 26
5.9 Step 8 – Recognize and Close the Team . 27
6 Information and documentation . 29
6.1 Information data definition and documentation. 29
6.2 Forms . 30
6.3 Control of records . 30
(informative) Acronym log . 31
(informative) Information data definition . 32
(informative) Form examples . 48

European foreword
This document (EN 9136:2018) has been prepared by the Aerospace and Defence Industries
Association of Europe - Standardization (ASD-STAN).
After enquiries and votes carried out in accordance with the rules of this Association, this Standard has
received the approval of the National Associations and the Official Services of the member countries of
ASD, prior to its presentation to CEN.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by November 2018, and conflicting national standards
shall be withdrawn at the latest by November 2018.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent
rights.
According to the CEN-CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria,
Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia,
France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta,
Netherlands, Norway, Poland, Portugal, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and the United Kingdom.
Rationale
The objective of root cause analysis and problem solving is to not only reduce the number of issues
(i.e. undesirable conditions, defects, failures), but to minimize their impact on quality, delivery
performance, costs, and ultimately on the customer. Often big issues originate with small problems that
were discovered too late or were discovered, but were never resolved due to a lack of understanding
the actual issue(s), incorrect analysis of the root cause, and/or ineffective actions being taken.
This guidance document was created to provide a methodology for performing root cause analysis to
resolve a significant or recurrent issue [e.g. quality, On-Time Delivery (OTD), process, documentation),
as guidance within the aviation, space, and defence industry and/or when contractually invoked at any
level of the supply chain.
Foreword
In December 1998, the aviation, space, and defence industry established the International Aerospace
Quality Group (IAQG) with the purpose of achieving significant improvements in quality and reductions
in cost throughout the value stream. This organization, with representation from aviation, space, and
defence companies in the Americas, Asia-Pacific, and Europe and sponsored by SAE International,
Society of Japanese Aerospace Companies (SJAC), and AeroSpace and Defence Industries Association of
Europe -Standardization (ASD-STAN), has agreed to take responsibility for the technical content of this
document to promote best practices that would satisfy associated requirements of Aerospace Quality
Management System (AQMS) standards (i.e. 9100, 9110, 9120).
To assure customer satisfaction, aviation, space, and defence industry organizations must produce and
continually improve safe, reliable products that meet or exceed customer and regulatory authority
requirements. This includes having processes in place to detect and eradicate significant and recurrent
issues. This document standardizes methodology to perform root cause analysis and problem solving to
support these efforts. The establishment of a common methodology, for use by organizations at all
levels of the supply-chain should result in improved action plans and a standardized way of exchanging
information between organizations and external stakeholders (e.g. suppliers, partners, customers,
regulatory agencies).
Introduction
This document has been developed by the IAQG. In accordance with the continual improvement
requirements defined in the 9100-series standards (see Clause 8, “Measurement, Analysis, and
Improvement”), it was deemed useful to promote those industry recognized best practices for
identifying the root causes of nonconformities or undesirable conditions (including potential issues and
conditions) and implementing correction(s) and associated corrective/preventive actions. The process
described in this document was created by comparing and mixing root cause analysis and problem
solving methodologies [e.g. 7 Steps, 8D, Root Cause Corrective Action (RCCA)] used by main actors of
aviation, space, and defence industry.
Unless contractually specified, other root cause analysis processes with slightly different sequencing of
activities and/or different names of process steps may be acceptable, provided that these activities
meet the intent of this document and deliver the same outcomes (i.e. immediate protection, temporary
fix, durable solution, systemic improvement) and provides the same level of information.
Throughout this document, the words “should” and “required” indicate strong recommendations to
apply and correspond to actions that the authors of this document consider important in order to
deliver robust root cause analysis. When strict application of this document is decided by an
organization or is mandated by a customer, they shall be interpreted as an obligation to be complied
with (i.e. interpreted as “shall” and “must”).
1 Scope
1.1 General
The objective of any organization, as part of continual improvement, is to reduce the number of issues
(i.e. undesirable conditions, defects, failures) and to minimize their impact on quality, delivery
performance, and cost.
This includes having processes in place to detect and eradicate significant and recurrent issues, which
implies having well identified problems, a common understanding of their impact and associated root
causes, and having defined and implemented adequate actions so that these problems, including similar
issues will not happen again.
1.2 Purpose
Propose a methodology to improve the way escapes and issues are managed, including communication
between all parties [e.g. engineering, Materials Review Board (MRB), manufacturing, manufacturing
engineering, supplier, customer] to reduce their impact, contain them as far upstream as possible, and
prevent recurrence (i.e. ensure the right measures are taken at the right location and at the right time).
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
EN 9100, Quality Management Systems — Requirements for Aviation, Space and Defence Organizations
EN 9110, Quality Management Systems — Requirements for Aviation Maintenance Organizations
EN 9120, Quality Management Systems — Requirements for Aviation, Space and Defence Distributors
EN ISO 9000:2015, Quality management systems — Fundamentals and vocabulary (ISO 9000:2015)
3 Terms and definitions
Definitions for general terms can be found in EN ISO 9000 and the IAQG Dictionary, which is located on
the IAQG website. An acronym log for this document is presented in Annex A.
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
• IEC Electropedia: available at http://www.electropedia.org/
• ISO Online browsing platform: available at http://www.iso.org/obp
3.1
apparent cause
(also referred to as obvious cause, direct cause, or immediate cause)
event or action that immediately results in or precedes the nonconformity
Note 1 to entry: This is generally NOT the root cause.
3.2
containment
action to control and mitigate the impact of a problem and protect the organization and/or customer
(i.e. stop the problem from getting worse), includes correction, immediate corrective action, immediate
communication, and verification that problem does not further degrade
3.3
contributing causes
causes that by themselves would not cause the problem, but can increase the risk of the issue to occur.
Analysis for these causes generally requires taking a closer look at the existing conditions and
associated actions
3.4
correction
(also referred to as Immediate Correction)
action taken to eliminate a detected nonconformity
[SOURCE: EN ISO 9000:2005, 3.6.6, modified]
Note 1 to entry: A correction can be made in conjunction with a corrective action.
Note 2 to entry: For product nonconformity, correction might be understood as reworking the part, accepting
the nonconformance through concession process, or scrapping the product.
Note 3 to entry: For a system issue, it may include correcting the paper work or issuing a new purchase order.
Note 4 to entry: For a delivery issue, it may include revising to air transportation instead of delivering product
by truck or ship, increasing production rate, etc.
3.5
corrective action
action taken to eliminate the cause of a detected nonconformity or other undesirable situation to
prevent recurrence
[SOURCE: EN ISO 9000:2005, 3.6.5, modified]
Note 1 to entry: A correction can be made in conjunction with a corrective action.
Note 2 to entry: Corrective action may address all types of causes (i.e. apparent, contributing, root causes).
3.6
immediate corrective action
action taken to eliminate, prevent, or reduce the probability of any additional nonconformances related
to the apparent cause from happening again in the short term
Note 1 to entry: These actions may be temporary and should remain in place until the root cause(s) is identified
and permanent RCCA is implemented and verified to be effective.
3.7
nonconformity
non-fulfilment of a requirement
[SOURCE: EN ISO 9000:2005, 3.6.2]
Note 1 to entry: It may be a nonconforming product, but may also be a late delivery, incorrect paperwork,
incorrect process [production or Quality Management System (QMS) related], etc.
3.8
preventive action
action to eliminate the cause of a potential nonconformity or other undesirable potential situation
[SOURCE: EN ISO 9000:2005, 3.6.4, modified]
Note 1 to entry: Preventive action is taken to prevent occurrence whereas corrective action is taken to prevent
recurrence.
3.9
root cause
original event(s), action(s), and/or condition(s) generating (directly or in cascade) an actual or
potential undesirable condition, situation, nonconformity, or failure
Note 1 to entry: There is sometimes more than one root cause associated to a single nonconformity or one root
cause with multiple contributing causes.
3.10
root cause analysis
process of identifying all the causes (root cause and contributing causes) that have or may have
generated an undesirable condition, situation, nonconformity, or failure
3.11
Root Cause Corrective Action
RCCA
(also referred to as Permanent Corrective Action)
action implemented to address the root cause(s) and contributing cause(s) of the undesirable condition,
situation, nonconformity, or failure; action taken to prevent recurrence
3.12
Root Cause Corrective Action (RCCA) Effectiveness Verification
action taken to verify that the planned corrective action(s) have prevented recurrence of the identified
root cause or contributing causes, and have consequently eradicated the problem
Note 1 to entry: This may include auditing, monitoring of specific metrics, or any other reporting
methodologies.
3.13
Root Cause Corrective Action (RCCA) Implementation Verification
action taken to verify that the planned actions were taken as scheduled
Note 1 to entry: This includes specific actions, milestones, completion dates, and responsibilities.
4 General Process
4.1 Basic Principles
a) In many instances, organizations and their suppliers do not provide adequate root cause analysis
and problem solving results because:
— no clear criterion exists for an acceptable corrective action plan; organizations are satisfied
when they no longer receive defective parts;
— the organization continues to accept inadequate corrective action plans as priority is given to
schedule versus quality;
— organizations (internal/external) do not have a root cause analysis mind set; people don’t
know or understand the process and/or have not been effectively trained.
b) A robust root cause analysis and problem solving process should provide visibility of the following
information:
— how the issue is managed and communicated between all stakeholders (e.g. engineering, MRB,
suppliers, customer);
— how it is ensured that the actual root cause(s) has been identified;
— how it is ensured that the right measures are taken at the right location, at the right time, and
by the right individuals;
— how containment actions taken to protect the customer and production efforts are identified
and managed.
c) Problem solving approaches can be summarized as:
— Reactive Mode – solving the abnormality that has occurred; gathering and analysing data aims
to provide customer protection and associated countermeasures;
— Proactive Mode – analysing failures and looking for product, process, or system improvements;
— Preventive Mode – putting in place solutions before an undesirable condition, defect, or failure
occurs.
4.1.1 Cultural Change
Cultural change is generally required to progress from a “reactive” mode to “proactive” and/or
“preventive” modes.
a) Examples of traditional behaviours:
— quick fix;
— not taking adequate time for analysis;
— going from one crisis to another;
— looking for the guilty party – “Who did that?”
— blaming or transferring responsibility;
— generate laundry list of solutions to firefight the symptoms;
— narrow focus taken to address the immediate problem;
— focus on performance metrics/measures (e.g. sales, profits) with hope that processes will
improve by themselves.
b) Expected “systems thinking” behaviour to get “systemic solutions”:
— understanding that many factors contribute to a complex situation;
— fully understanding the actual problem and then addressing the systemic root cause(s);
— permanently fixing and improving performance;
— seeking total understanding of the process – “How did that happen?”
— taking time to understand the big picture; to dialogue and elicit diverse perspectives before
applying the solution;
— focusing on improving processes; actually effecting process performance.
4.1.2 Effective Communication
The behaviour of all process performers and stakeholders are key factors of success in the application
of a robust root cause analysis and problem solving process.
Effective communication is mandatory:
— Within the organization where the problem originated, and between process performers and
stakeholders of the supply chain to ensure effective root cause analysis and corrective action
implementation.
— Between supplier and customer to immediately stop the problem from getting worse, ensure full
understanding of the problem, and verify that implemented solutions are satisfactory.
NOTE The conditions where the customer must be notified should be established and documented. If the
conditions cannot be specified with tangible trigger points, then direction should be given for how to evaluate
each situation to ensure the customer is kept informed, as appropriate.
4.2 When to Apply a Structured Root Cause Analysis and Problem Solving Process
Launching a formal root cause analysis and problem solving process should always be considered, when
an issue (undesirable conditions, defects, and failures) is detected and the cause is unknown or
inconclusive (not obvious). The decision to apply or not apply the process should be made at the
appropriate level of management within the company based on the level of risk and whether the risk
associated is acceptable or not, using a rational decision making process and maintaining records of
significant decisions.
The process should always be applied, if one or more of these conditions exist:
— safety impact (product/personal);
— product strength, performance, and/or reliability issue;
— high impact on production/maintenance operations:
— stop the production/maintenance line; prevent next operation to occur satisfactorily, etc;
— regulatory authorities and/or customer dissatisfaction;
— costs issue (generated to the customer or the organization);
— disruption of supplier’s process or customer's operations.
— repetitive problems to one part or similar activities/processes;
— difficulty to detect;
— customer request;
— significant quality or QMS issue;
— complex problem that cannot be solved without assistance of other people than those located
where the problem occurred.
Generally speaking, the impact of an issue and the frequency of its occurrence should always be
considered when deciding to launch or not launch a formal root cause analysis (see Figure 1).
Key
1 Not required
2 Optional
3 Recommended
4 Mandatory
5 Customer request shall always take precedence
X Frequency
Y Impact
Figure 1 — Applying a structured root cause analysis and problem solving process depending on
the impact and frequency of a problem
4.3 Process Step Description
The process is described in nine steps by S0 to S8 (see Figure 2).
Figure 2 — Root cause analysis general process mapping
The criticality of the problem should be determined, based on evaluation of the risk(s) it generates,
taking into consideration the following elements: the severity of the issue (i.e. its impact on the
business, the product, and/or the customer) its detectability, its probability to occur, etc.
This document defines the elements for each of the nine process steps:
a) objective(s) of the step;
b) output(s) of the step;
c) what are the associated actions for this step;
d) why this step is necessary and the potential risk if no action is taken;
e) when does the activity take place;
f) who are the principle process performers and applicable stakeholders;
g) how to manage this process step so that it is effective, including providing some proposed tools to
be used;
h) communication aspects to take into consideration;
i) specific Items to be considered.
5 Process Steps
5.1 Step 0 – Start Immediate Containment Actions
a) Objective: To mitigate the impact of the problem, to protect customer operations and the
organization (i.e. stop the problem from getting worse), and verify that the situation does not
deteriorate until the root cause and contributing causes are known.
b) Output: Immediate containment actions defined and implemented; customer protected.
c) What: Actions required to protect the customer and the organization from negative impacts
associated to the problem.
d) Why: If the problem that has been identified is having an impact on the customer or organization,
the situation will continue to deteriorate, especially if no action is taken. This justifies a
development and deployment of a containment plan.
e) When: As soon as the problem is detected and perceived impact on customer or organization
operations is suspected.
NOTE For most critical cases and/or to be in line with customer/regulatory requirements, immediate
containment action may be required within one business working day of detection or less.
f) Who: Should be assigned to an individual or organization, as appropriate.
g) How: Launch immediate preliminary analysis to understand the problem and its immediate impact;
ensuring adequate focus on the effects of the problem, not its cause(s).
Depending on the results of this analysis:
— identify and isolate defective parts or data, and perform immediate containment and/or
correction, as required;
— identify apparent cause and perform immediate corrective action to eliminate, prevent, or
reduce the probability of any additional nonconformances from happening and/or escaping in
the short term.
Typical immediate containment actions may include:
— immediate suspension of Work-in-Progress (WIP);
— stop deliveries;
— recall product (still within the organization or already delivered);
— strengthen associated quality assurance/inspection processes (i.e. inspections, checks, tests);
“Build the wall higher”;
— conduct inventory checks and segregate defective parts;
— temporary update and/or reinforcement of processes, instructions, activities, and documents;
particularly in the case of QMS deficiencies.
Identify immediate/potential risk for affected parts if not detected.
Determine criticality based on the facts and information available at this time (may evolve at future
steps once there is a better understanding of the problem and associated conditions):
— Can the team assess criticality?
— If not, who should be contacted (e.g. customer, design office, type certificate holder,
airworthiness office) to assist in evaluating the criticality?
NOTE Immediate containment actions should be limited in time and terminate, when root cause corrective
action(s) is in place and has been determined effective, or when further study has found a more effective
containment action (see Step 3 or Step 6).
h) Communication: The process should require that visibility of action(s) taken and/or to be taken be
communicated to applicable entities and organizations.
Identify who (internally and externally) is affected or impacted by the current problem and/or
associated conditions, including any required customer notification and inform all impacted parties
(e.g. internal organizations, suppliers, customers) about the following, as applicable:
— product or data impacted;
— nature of the issue, as understood at this time;
— how and when it was detected;
— consequence of the problem, as identified at this point in time, based on the available facts and
information;
— containment actions taken and recommendations for actions to be taken by the customer
and/or affected parties;
— identify the next steps/actions to be taken (e.g. root cause analysis launched; see criteria
defined in section 4.2);
— whether customer assistance is required (e.g. to determine criticality, to return impacted
product);
— existing plans regarding future communication;
— identification of the organization focal point.
Immediate information to the customer is mandatory for specific conditions, especially if product
that has been delivered is known or suspected to be affected by the issue, potentially impacts
product safety, and more generally when it is known or perceived that the issue will have a
significant impact on customer’s operations.
i) Specific Items: Items that should be considered include the following:
— identify the entities and organizations that are or may be impacted by the current issue;
— identify other products, production lines, locations, data, processes, etc. that could be affected
by similar issues and may also require containment actions to be taken;
— determine how and where it is appropriate to contain the problem;
— determine whether products in stores, WIP, at suppliers, and customers are affected;
— provide visibility of investigation efforts that are to be undertaken to enhance current
knowledge of the existing problem and associated conditions;
— identify what checks/verifications are being performed or should be conducted, including
associated details (e.g. where, by whom, when);
— identify data/information that will need to be collected to support root cause analysis;
— provide the customer with visibility of applicable containment actions and assurance that
appropriate measures are being taken;
— Estimate how long the containment actions are likely to remain in place.
5.2 Step 1 – Build the Team
a) Objective: To ensure that all process performers and applicable stakeholders and functions
(e.g. organizations, departments, suppliers, customers) that may have an influence on the
corrective action process and associated investigation are on the team.
b) Output: Cross-functional team of experts in place to support the corrective action process.
c) What: Gather a team representing different functions that may have an influence on the problem
and are able and willing to assist in the associated investigation and problem solving activities.
d) Why: The corrective action process, including root cause analysis, is normally more successful when
conducted by a team with intimate knowledge of the process and performance data.
e) When: As soon as the problem is considered as requiring a root cause analysis.
NOTE Step 1 (Build the Team) and Step 2 (Define Problem) may be conducted concurrently in an iterative
process.
f) Who: Management within the organization where the problem originated, at a level commensurate
with the importance of the problem, to ensure correct dimensioning and team empowerment.
NOTE For big issues, it is recommended to set up a steering committee composed of members at
appropriate levels of management (not participating on the working team) to validate all decisions taken; in
particular, the implementation of final solutions.
Team leader (facilitator) should:
— preferably be someone without a hierarchical role. An independent role supporting, but not
directing the analysis; ensuring targets and timing are met;
— be nominated based on experience with root cause analysis techniques or have access to the
appropriate specialists, but should not necessarily be an expert in the process being analyzed;
— be empowered by the appropriate level of management; commensurate to the existing
issue/problem.
g) How: Identify representatives from various functions that would be able to contribute to the
corrective action process and associated investigation. An example of a team composition template
is provided in Figure 3.
NOTE 1 Remember to include those performing the job (e.g. operators, inspectors, assemblers); they may
be best suited to identify the actual causes. Don' leave them off the team; however, limiting team members to
process performers reduces the possibility to think “out of the box”.
NOTE 2 The size and composition of the team depends on the complexity and impact of the problem.
NOTE 3 The composition of the team is not fixed and may evolve (i.e. additions, deletions), depending on
the analysis results and support needed. However, there should be level of stability to maintain team
dynamics and productivity.
Expanding the size of the core team over six to eight members generally results in less efficiency.
When additional members or skills are required, sub-teams should be considered.

NOTE Selection criteria defined above is merely an example; other criteria may be defined.
Figure 3 — Team Composition Template (Example)
h) Communication: The team leader and all team members need to know they have been nominated to
their respective roles/responsibilities, understand the team objectives and any existing constraints,
and understand how they contribute to the team objectives.
Each team member's manager needs to know their level of involvement (e.g. time/duration, role).
Other stakeholders should be informed of the team composition and objectives.
i) Specific Items: Items that should be considered include the following:
— People joining the team should be selected based on their process knowledge, including those
impacted by the problem, and skills (e.g. investigation background, RCCA process knowledge)
they have that can assist in finding an effective solution.
— Team dynamics can have positive or negative impact on process results. It is therefore
important to ensure that the team leader is selected on their ability to effectively manage team
dynamics.
— How team members are nominated, including the size and composition of the team, can depend
on the impact of the issue and the frequency of its occurrence.
— Use of a RASCI (Responsible, Accountable, Supportive, Consulted, and Informed) chart could be
considered a useful way of defining team roles and responsibilities.
5.3 Step 2 – Define Problem
a) Objective: To understand the significance, impact, and size of the problem (i.e. depth and breadth of
current conditions) and ensure the situation (i.e. problem) is accurately defined and thoroughly
understood by the team and applicable stakeholders.
b) Output: Problem defined [e.g. which product, what process(es), actual defect or process deviation]
and agreed upon.
c) What: This step helps to fully describe the current situation/problem; precise analysis of all its
elements and aspects to gain a common understanding, from which a relevant root cause analysis
can be performed (see Step 4) and an effective corrective action plan can be defined (see Step 5).
d) Why: Often the first time a problem is put into words it is vague, subjective, or even abstract.
Without a proper problem statement (definition), it is unlikely that the root cause will be identified
and incorrect or insufficient corrective actions will be put in place.
The accuracy and completeness of the problem description are decisive factors for the quality of the
root cause analysis and associated problem solving efforts. The team will benefit from investing
adequate time upfront defining the problem to ensure subsequent process steps proceed accurately
and efficiently.
e) When: As soon as possible after the team is formed.
NOTE Step 1 (Build the Team) and Step 2 (Define Problem) may be conducted concurrently in an iterative
process.
f) Who: All team members.
g) How: A good problem statement is supported by objective evidence, based on facts and figures, not
on perception. The scope and extent of the problem and the associated symptoms being
experienced by the customer (internal or external) should be understood by and/or communicated
to all people involved in finding an effective solution.
NOTE 1 The robustness of the problem definition is based on the relevance and accuracy of the data, facts,
and information collected about the problem.
NOTE 2 This may be an iterative process and could take some time.
NOTE 3 The problem statement should be updated, as appropriate, when additional information becomes
available.
Step 2 should always be concluded by confirmation that all team members agree on the problem
statement and resulting impact.
h) Communication: Communication between all team members should be structured with regular
reviews, until the problem statement is identified, adequately defined, and agreed by all.
The problem statement, including its depth and breadth, should be communicated to all applicable
stakeholders (internal or external), including the customer when appropriate.
i) Specific Items: Items that should be considered include the following:
— Which elements (e.g. operations, products, materials, defects, malfunctions) characterize the
current situation?
— Who reported the problem?
— When was the problem reported?
— Who is affected by the problem?
— Who was involved in producing the nonconformance; in particular, identify if human factors
should be considered, but ensure no blaming culture;
— Where is it seen (e.g. shop floor, services, machine, process step)?
— When does the problem appear (e.g. time, date, when does it start, how long does it last, how
often)?
— Has it occurred before?
— If yes, identify relevant historical information, including previous corrective actions taken.
— How does the event appear?
— How is the effect/impact of the problem being measured (e.g. costs, delays, scrap rate,
customer complaints, return rate, concessions, reliability rate)?
— What is the actual effect/impact of the problem (e.g. customer impact, cost impact, safety
impact)?
— How is the problem currently being addressed?
— How is it being corrected?
At this point, the natural tendency is to try and find the root cause before being sure the actual
problem is clearly defined and understood. The focus of this step should be to analyze the problem
and ensure it is adequately described, not to identify the root cause (this will be done during
Step 4).
Check every answer to the various questions by asking: Do we know this for sure or are we merely
making an assumption that this is the way things are?
Some tools that may be used to gather/analyze data for the problem statement (definition) include:
— brainstorming;
— comparison sheets;
— check sheets;
— tally charts;
— histograms;
— scatter diagrams;
— control charts;
— pareto analysis;
— is/is not.
5.4 Step 3 – Complete and Optimize Containment Actions
a) Objective: To ensure containment actions suitably address the problem statement and to verify that
immediate corrective action is commensurate with the problem, implemented, and effective.
b) Output: Completed (implemented) and optimized containment actions (issue contained).
c) What: To check that all nonconforming product or data has been isolated and corrected to prevent
escape, and optimize immediate corrective action(s) to minimize impact on the customer,
operation, and organization until the root cause of the problem is understood, permanent
corrective action is taken, and their effectiveness is verified.
d) Why: When the problem statement is defined, it is very likely that immediate containment actions
implemented in Step 0 may need to be further developed, enhanced, or optimized and some may
need to be removed.
e) When: As soon as team members reach consensus regarding the problem statement and resulting
impact.
f) Who: The owner of each containment action and all team members, to verify effectiveness of
actions taken to date.
g) How: Identify containment actions and associated owners and time frames. Identify potential risks
on similar items, if not detected. Confirm criticality with all team members, including suppliers and
the customer, if required.
Generally, additional containment actions may include:
— temporary increase of production to support product needs;
— over-inspection upstream in the process;
— stock segregation at suppliers and sub-tiers, as applicable; and
— product recall (still within the organization or already delivered).
h) Communication: Communication between all team members is mandatory, for instance through
regular reviews, until containment actions are re-evaluated and optimized (as necessary), agreed
upon by all, and implemented.
The nature of containment actions should be communicated to applicable stakeholders, especially
to the customer if defective product or data has been delivered and/or might be negatively
impacted (e.g. stoppage in deliveries).
i) Specific Items: Items that should be considered include the following:
— identify why the problem was not detected and act accordingly;
— identify whether further containment actions are required;
— the containment plan may include additional equipment, areas, data, processes, etc., that could
potentially be affected. The containment plan should prevent the same issue arising at other
sites, products, or production lines;
— identify what checks need to be performed, by who, and when;
— evaluate how products in stores, WIP, at suppliers, and customers are
...