BS en 62740. Root Cause Analysis (RCA). (Draft)

(1)

Responsible Committee Secretary: Mrs Phillippa Younas (BSI) Direct tel: 020 8996 7239

WARNING: THIS IS A DRAFT AND MUST NOT BE REGARDED OR USED AS A BRITISH STANDARD. THIS DRAFT IS NOT CURRENT BEYOND 9 April 2014

This draft is issued to allow comments from interested parties; all comments will be given consideration prior to publication. No acknowledgement will normally be sent. See overleaf for information on the submission of comments.

No copying is allowed, in any form, without prior written permission from BSI except as permitted under the Copyright, Designs and Patent Act 1988 or for circulation within a nominating organization for briefing purposes. Electronic circulation is limited to dissemination by e-mail within such an organization by committee members. Further copies of this draft may be purchased from BSI Shop http://shop.bsigroup.com

or from BSI Customer Services, Tel: +44(0) 20 8996 9001 or email [email protected]. British, International and foreign standards are also available from BSI Customer Services.

Information on the co-operating organizations represented on the committees referenced above may be obtained from http://standardsdevelopment.bsigroup.com

Latest date for receipt of comments: 9 April 2014 Project No. 2012/01932

Responsible committee: DS/1 Dependability Interested committees:

Date: 12 February 2014

Origin: European

DPC: 14 / 30267079 DC

BSI Group Headquarters

389 Chiswick High Road London W4 4AL Tel: +44 (0)20 8996 9000

Fax: +44 (0)20 8996 7400 www.bsigroup.com

Title: Draft BS EN 62740 Root Cause Analysis (RCA)

Please notify the secretary if you are aware of any keywords that might assist in classifying or identifying the standard or if the content of this standard

i) has any issues related to 3rd party IPR, patent or copyright ii) affects other national standard(s)

(2)

draft are welcome and will assist in the preparation of the consequent British Standard. Comment is particularly welcome on national legislative or similar deviations that may be necessary.

Even if this draft standard is not approved by the UK, if it receives the necessary support in Europe, the UK will be obliged to publish the official English Language text unchanged as a British Standard and to withdraw any conflicting standard.

UK Vote

Please indicate whether you consider the UK should submit a negative (with reasons) or positive vote on this draft.

EXAMPLE ONLY

Microsoft and MS-DOS are registered trademarks, and Windows is a trademark of Microsoft Corporation. Submission of Comments

- The guidance given below is intended to ensure that all comments receive efficient and appropriate attention by the responsible BSI committee. Annotated drafts are not acceptable and will be rejected.

- All comments must be submitted, preferably electronically, to the Responsible Committee Secretary at the address given on the front cover. Comments should be compatible with version 6.0 or version 97 of Microsoft Word for Windows, if possible; otherwise comments in ASCII text format are acceptable. Any comments not submitted electronically should still adhere to these format requirements.

- All comments submitted should be presented as given in the example below. Further information on submitting comments and how to obtain a blank electronic version of a comment form are available from the BSI website at: http://drafts.bsigroup.com/

Template for comments and secretariat observations Date: xx/xx/20xx Document: ISO/DIS xxxx

1 2 (3) 4 5 (6) (7)

MB Clause No./ Subclause No./Annex (e.g. 3.1) Paragraph/ Figure/ Table/Note Type of com-ment

Commend (justification for change) by the MB

Proposed change by the MB Secretariat observations on each comment submitted

3.1 Definition 1 ed Definition is ambiguous and needs clarifying.

Amend to read '...so that the mains connector to which no connection...'

6.4 Paragraph 2 te The use of the UV photometer as an alternative cannot be supported as serious problems have been encountered in its use in the UK.

(3)

56/1542/CDV

COMMITTEE DRAFT FOR VOTE (CDV) PROJET DE COMITÉ POUR VOTE (CDV)

Project number IEC 62740/Ed1

Numéro de projet

IEC/TC or SC: _{TC 56}

CEI/CE ou SC:

Secretariat / Secrétariat UK

Submitted for parallel voting in CENELEC

Soumis au vote parallèle au CENELEC

Date of circulation Date de diffusion 2014-02-07

Closing date for voting (Voting mandatory for P-members) Date de clôture du vote (Vote obligatoire pour les membres (P)) 2014-05-09

Also of interest to the following committees Intéresse également les comités suivants

Supersedes document Remplace le document

56/1527/CD and 56/1540/CC

Proposed horizontal standard Norme horizontale suggérée

Other TC/SCs are requested to indicate their interest, if any, in this CDV to the TC/SC secretary

Les autres CE/SC sont requis d’indiquer leur intérêt, si nécessaire, dans ce CDV à l’intention du secrétaire du CE/SC Functions concerned Fonctions concernées Safety Sécurité EMC CEM Environment Environnement Quality assurance Assurance qualité

CE DOCUMENT EST TOUJ OURS À L'ÉTUDE ET SUSCEPTIBLE DE MODIFICATION. IL NE PEUT SERVIR DE RÉFÉR ENCE.

LES RÉCIPIENDAIRES D U PRÉSENT DOCUMENT SONT INVITÉS À PRÉSENTER, AVEC LEURS OBSERVATIONS, LA N OTIFICATION DES DROITS DE PROPRIÉTÉ DONT ILS AURAIENT ÉV ENTUELLEMENT CONNAISSANCE ET À FO URNIR UNE DOCUMENTAT ION EXPLICATIVE.

THIS DOCUMENT IS STILL UNDER STUDY AND SUBJECT TO CHANGE. IT SHOULD NOT BE USED F OR REFERENCE PURPOSES.

RECIPIENTS OF THIS DOCUMENT ARE INVITED TO SUBMIT, W ITH THEIR COMMENTS, NOTIFICATION OF ANY RELEVANT PATENT RIGHTS OF W HICH THEY ARE AW ARE AND TO PROVIDE SUPPO RTING DOCUMENTATION.

Title :

IEC 62740/Ed1: Root Cause Analysis (RCA)

Introductory note

ATTENTION IEC – CENELEC PARALLEL VOTING

The attention of IEC National Committees, members of CENELEC, is drawn to the fact that this Committee Draft for Vote (CDV) for an International Standard is submitted for parallel voting.

The CENELEC members are invited to vote through the CENELEC online voting system.

permitted to download this electronic file, to make a copy and to print out the content for the sole purpose of preparing National Committee positions. You may not copy or "mirror" the file or printed version of the document, or any part of it, for any other purpose without permission in writing from IEC.

(4)

INTERNATIONAL ELECTROTECHNICAL COMMISSION

92

____________ 93

94

ROOT CAUSE ANALYSIS (RCA)

95 96 97 98

FOREWORD

99

1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising

100

all national electrotechnical committees (IEC National Committees). The object of IEC is to promote

101

international co-operation on all questions concerning standardization in the electrical and electronic fields. To

102

this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,

103

Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC

104

Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested

105

in the subject dealt with may participate in this preparatory work. International, governmental and

non-106

governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely

107

with the International Organization for Standardization (ISO) in accordance with conditions determined by

108

agreement between the two organizations.

109

2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international

110

consensus of opinion on the relevant subjects since each technical committee has representation from all

111

interested IEC National Committees.

112

3) IEC Publications have the form of recommendations for international use and are accepted by IEC National

113

Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC

114

Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any

115

misinterpretation by any end user.

116

4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications

117

transparently to the maximum extent possible in their national and regional publications. Any divergence

118

between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in

119

the latter.

120

5) IEC itself does not provide any attestation of conformity. Indep endent certification bodies provide conformity

121

assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any

122

services carried out by independent certification bodies.

123

6) All users should ensure that they have the latest edition of this publication.

124

7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and

125

members of its technical committees and IEC National Committees for any personal injury, property dama ge or

126

other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and

127

expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC

128

Publications.

129

8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is

130

indispensable for the correct application of this publication.

131

9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of

132

patent rights. IEC shall not be held responsible for identifying any or all such patent rights.

133

International Standard IEC 62740 has been prepared by IEC technical committee 56: 134

Dependability. 135

The text of this standard is based on the following documents: 136

FDIS Report on voting

XX/XX/FDIS XX/XX/RVD

137

Full information on the voting for the approval of this standard can be found in the report on 138

voting indicated in the above table. 139

This publication has been drafted in accordance with the ISO/IEC D irectives, Part 2. 140

(7)

The committee has decided that the contents of this publication will remain unchanged until 141

the stability date indicated on the IEC web site under "http://webstore.iec.ch" in the data 142

related to the specific publication. At this date, th e publication will be 143

• reconfirmed, 144

• withdrawn, 145

• replaced by a revised edition, or 146

• amended. 147

148

The National Committees are requested to note that for this publication the stability date 149

is 2018 150

THIS TEXT IS INCLUDED FOR THE INFORMATION OF THE NATIONAL COMMITTEES AND WILL BE

151

DELETED AT THE PUBLICATION STAGE.

152 153 154

(8)

155

INTRODUCTION

156

Root Cause Analysis (RCA) refers to any systematic process that identifies factors that 157

contributed to a particular event of interest (focus event). RCA aims to reveal root causes so 158

that either the likelihood of them occurring or their impact if they do occur can be changed. 159

RCA is performed with the understanding that events are addressed by understanding the 160

root causes, rather than the immediately obvious symptom s. 161

RCA is used to analyse the root causes of focus events with both positive and negative 162

outcomes, but it is most commonly used for the analysis of failures and incidents. Causes for 163

such events can be varied in nature, including design, processes and techniques, 164

organisational characteristics, human aspects and external events. RCA can be used for 165

investigating the causes of non-conformances in quality (and other) management systems as 166

well as for failure analysis. 167

An important distinction to make is that RCA is used to analyse a focus event that has 168

occurred and therefore analyses the past (a posteriori). However, knowledge of the root 169

causes of past events can lead to actions that generate improvements in the future. 170

This standard is intended to reflect current good pract ices in the conduct of RCA. This 171

standard is general in nature, so that it may give guidance across many industries and 172

situations. There may be industry specific standards in existence that establish preferred 173

methodologies for particular applications. If these standards are in harmony with this 174

publication, the industry standards will generally be sufficient. 175

This international standard is a generic standard and does not explicitly address safety or 176

accident investigation although the methods described in this standard may be used for this 177

purpose. 178

(9)

180

ROOT CAUSE ANALYSIS

181

1 Scope

182

This International Standard describes the basic principles of Root Cause Analysis (RCA) and 183

specifies the steps that a process for RCA should include. 184

This International Standard identifies a number of attributes for RCA techniques which assist 185

with the selection of an appropriate technique. It describes each RCA technique and its 186

relative strengths and weaknesses. 187

RCA is used to analyse focus events that have occurred, therefore this International Standard 188

only covers a posteriori analyses. It is recognised that some of the RCA techniques with 189

adaptation could be used proactively in the design and development of items and for causal 190

analysis during risk assessment; however, this Intern ational Standard focuses on the analysis 191

of events which have occurred. 192

The intent of this International Standard is to explain the techniques to identify root causes. 193

These techniques are not designed to assign responsibility or liability, which is outside the 194

scope of this International Standard. 195

2 Normative references

196

The following documents, in whole or in part, are normatively referenced in this document and 197

are indispensable for its application. For dated references, only the edition cited applies. For 198

undated references, the latest edition of the referenced document (including any 199

amendments) applies. 200

IEC 60050-191, International Electrotechnical Vocabulary – Part 191: Dependability, 201

Terminology 202

3 Terms and definitions

203

For the purposes of this document, the definitions given in IEC 60050-191 and the following 204 apply. 205 3.1 206 cause 207

set of circumstances that leads to failure or success 208

Note 1 to entry: A cause may originate during specification, design, manufacture, installation, operation or

209

maintenance.

210

[SOURCE: IEC 60050-191, definition 191-43-11 modified – to relate to failure or success] 211

3.2

212

causal factor

213

condition, action, event or state that produced or contributed to the occurrence of the focus 214 event 215 3.3 216 contributory factor 217

a causal factor regarded as secondary, according to an explicitly-given prioritisation of causal 218 factors 219 3.4 220 direct cause 221

immediate cause where there is no other cause between the direct cause and the focus event 222

Note 1 to entry: There may be more than one direct causal factor.

(10)

3.5

224

event

225

occurrence or change of a particular set of circumstances 226

Note 1 to entry: An event can be one or more occurrences, and can have several causes.

227

Note 2 to entry: An event can consist of something not happening.

228

Note 3 to entry: An event can sometimes be referred to as an “incident” or “accident”.

229

[SOURCE: ISO Guide 73 2009 [1]] 230

3.6

231

failure (of an item)

232

loss of ability to perform as required 233

Note 1 to entry: When the loss of ability is caused by a pre-existing latent fault, the failure occurs when a particular

234

set of circumstances is encountered.

235

Note 2 to entry: A failure of an item is an event that results in a fault state of that item.

236

Note 3 to entry: Qualifiers, such as catastrophic, critical, major, minor, marginal and insignificant, may be used to

237

categorize failures according to the severity of consequences, the choice and definitions of severity criteria

238

depending upon the field of application.

239

Note 4 to entry: Qualifiers, such as misuse, mishandling and weakness, may be used to categorize failures

240

according to the cause of failure.

241

[SOURCE: IEC 60050-191, definition 191-43-01] 242

Note 5 to entry: This is failure of an item, not more generally of behaviour.

243

3.7

244

failure mechanism

245

process that leads to failure 246

Note 1 to entry: The process may be physical, chemical, logical, psychological or a combination thereof.

247

[SOURCE: IEC 60050-191, definition 191-43-12 modified – psychological added] 248

3.8

249

focus event

250

event which the RCA is intended to explain causally 251

3.9

252

necessary causal factor (of an event or state)

253

condition, action, event or state, that resulted in the given event or state, without which the 254

given event or state would not have occurred 255

3.10

256

human error

257

discrepancy between the human action taken or omitted, and that intended or required 258

Note 1 to entry: Ed.1 of IEC 60050-191 identified “mistake” as a synonym for human error, but a mistake is a type

259

of human error.

260

3.11

262

item

263

subject being considered 264

Note 1 to entry: The item may be an individual part, component, device, functional unit, equipment, subsystem, or

265

system.

266

Note 2 to entry: The item may consist of hardware, software, people or any combination thereof.

267

Note 3 to entry: The item is often comprised of elements that may each be individually considered .

268

3.12

270

root cause

271

type of cause with no predecessor that is relevant for the purpose of the analysis 272

(11)

Note 1 to entry: A focus event normally has more than one root cause .

273

Note 2 to entry: In some languages the term root cause refers to t he combination of causes which have no causal

274

predecessor (a cut set of causes).

275

3.13

276

Root Cause Analysis

277

RCA

278

systematic process to identify the causes of a focus event 279

Note 1 to entry: IEC 60050-191, definition 191-52-05 provides the following more restrictive definition “systematic

280

process to identify the cause of a fault, failure or undesired event, so it can be removed by design, process or

281

procedure changes”. This standard uses an extended definition to allow a wider applicability of the process.

282

3.14

283

stakeholder

284

person or organisation that can affect, be affected by, or perceive themselves to be affected 285

by a decision or activity 286

[SOURCE: IEC 60300-1, definition 3.1.17 [2]] 287

3.15

288

stopping rule

289

a reasoned and explicit means of determining when a necessary causal f actor is defined as 290

being a root cause 291

4 Introduction to RCA

292

RCA refers to any systematic process that identifies the cause or causes that contribute to a 293

focus event. The immediate or obvious cause of a focus event is often a symptom of 294

underlying causes and may not truly identify the root cause or causes that should be identified 295

and addressed. RCA provides a greater understanding about why events have occurred. RCA 296

may identify the following: 297

 single root cause; 298

 multiple root causes in which the elimination of any cause will prevent the focus event 299

from occurring; 300

 root causes which are causal factors where elimination will change the likelihood of the 301

focus event occurring but may not directly prevent it; 302

 root causes of successes. 303

By addressing the root cause or causes it is possible to make decisions regarding appropriate 304

actions that will generate better outcomes in the future ; implementing appropriate actions 305

based on RCA are more effective at preventing the same or similar events with negative 306

outcomes occurring or increasing the probability of repeating events with positive outcomes, 307

when compared with just addressing the direct cause. 308

RCA can be applied to any focus event whether success or failure, for example: 309

 investigation for technological, medical and occupational focus events; 310

 failure analysis of technological systems , to determine why an item failed to perform as 311

and when required; 312

 analysis of quality control and business processes; 313

 analysis of successful outcomes. 314

RCA can be carried out at various levels of decomposition for example from system to 315

component level or by selecting different events or outcomes as a starting point. The level 316

appropriate to conduct the analysis will be dependent on the focus event. 317

RCA is used to analyse focus events wh ich have actually occurred and is therefore applicable 318

during the testing and operational phases of a project or product life cycle. 319

(12)

The benefits of performing RCA include: 320

 obtaining a greater understanding into what has happened; 321

 finding the source of problems so corrective action can prevent future events; 322

 identifying the causes of events with beneficial outcomes so they can be repeated; 323

 identifying more effective actions to address the causes of focus events; 324

 achieving the objectives of focus event inves tigations more effectively; 325

 supporting traceability between focus event investigation evidence and conclusions; 326

 increasing consistency between investigations of similar focus events; 327

 increasing objectivity of focus event analysis. 328

5 The RCA process

329

5.1 Overview

330

To be effective RCA should be performed systematically as an investigation, with the root 331

causes and conclusions backed up by documented evidence. To achieve this, RCA should 332

include the five steps shown in Table 1 and illustrated in Figure 1. 333

Table 1 – Steps to RCA

334

Step Concepts and tasks to be performed

Initiation Determine the need to carry out RCA and define the purpose and scope

Establishing Facts Collect data and establish the facts of what happened, where , when and who

Analysis Use RCA tools and techniques to ascertain how and why the focus event occurred

Validation Distinguish and resolve the different possibilities as to how and why the focus event was

caused Presentation of

Results

Present the results of the focus event analysis

RCA is iterative in nature especially the data collection and analysis , in that data is collected 335

on ‘what’ happened, which is then analysed in order to determine what ot her data needs to be 336

collected. Once gathered, further analysis is conducted and any gaps identified, for which 337

further data is collected. This process is repeated until the purpose of the analysis is fulfilled 338

and the root causes identified. The outputs of the RCA will be dependent on the purpose and 339 scope. 340 Establish the need, purpose & scope Immediate Facts Step 1: Initiation What, Where, When & Who Data Collection

Step 2: Establishing Facts

How and why (identify potential causes) Application of specific tools Step 3: Analysis Potential causes distinguished and resolved Further data and testing Step 4: Validation Outputs Step 5: Presentation of Results 341

Figure 1 – RCA process

342

5.2 Initiation

343

The first step initiates the RCA process by evaluating the need to carry out RCA. It defines 344

the purpose and scope of the analysis, in response to the focus event, and establishes a team 345

and resources to carry out the RCA. 346

(13)

There is usually some criterion which is used to determine when an RCA is required, which 347

may include: 348

 any single event with a large effect; 349

 multiple similar undesirable events; 350

 a parameter moving out of a defined tolerance level; 351

 failures or successes (whatever the level of effect) that involve critical items of equipment 352

or activities. 353

When defining the type of events that require the conduct of RCA, it is important to consider 354

that an event with a large effect may have common root causes to events with minor effects. 355

Analysing and addressing root causes for events with minor effects may prevent a large effect 356

event occurring. Examples of events where RCA may be required include: completion of a 357

project (successes and failures), failures that result in unacceptable costs, injury or fatality, 358

unacceptable performance or delays, large contractual consequences, and equipment 359

breakdown. 360

If a RCA is required, the focus event(s) to be analysed is/are described and an appropriate 361

team appointed for the analysis. The description should include the background and context 362

in which the focus event(s) occurred. A good description of a focus event is short, simple, and 363

easy to understand and should not be biased towards a specific solution. This description is 364

used to identify appropriate members of the analysis team and ascertain where to start 365

collecting data. 366

The purpose and scope of the RCA should be determined taking into account knowledge of 367

system, functions, interfaces etc. In some cases the purpose of the analysis is to iden tify the 368

causes of the focus event, in others the purpose may be broader. For example, to also 369

identify matters of concern outside those that led to the focus event. 370

There are in general two different types of RCA that have different objectives and should not 371

be mixed up. These two types can be described as follows: 372

 analysis of an observed focus event from other observed events; 373

 analysis of an observed focus events from potential events, not actually observed. 374

The first version focuses on observed facts onl y. It may be an analysis "per se" according to 375

the purpose of the study and no hypothesis about event occurrence is acceptable for this 376

analysis. The second version focuses on potential (non -observed) events which may have led 377

to the actually observed focus event. It can be implemented when more facts are needed and 378

the use of hypothesis on the occurrence of events is acceptable for this analysis. 379

The outputs required of the RCA should also be identified, examples are as follows: 380

 provide a description of each root cause along with sufficient background information to 381

allow the identification of suitable actions; 382

 recommend actions that, taken together, prevent further occurrences of similar events with 383

adverse consequences and improve the likelihood of succes ses; 384

 identify, implement and review actions to address root causes. 385

RCA can include the analysis of open systems ( systems which continuously interact with their 386

environment); this interaction can take the form of information, energy, or material transfer . 387

Therefore, the scope should specify the boundary of the analysis (what is included and what 388

is excluded). 389

The scope of the analysis should where possible include a definition of the ‘stopping rule’ , 390

which is the point at which action can be defined or additional proof of cause is no longer 391

necessary for the purpose of the analysis. For example the last point where corrective action 392

can be identified, before factors that cannot be influ enced e.g. weather. It may however be 393

(14)

more appropriate to ascertain the stopping rule at review points that determine whether 394

further analysis is required. 395

The team members for the analysis should be selected based on the specific expertise 396

needed to analyse the focus event. The team should include: 397

 a person or persons who between them can provide a complete systems overview and 398

knowledge of the programme or project and focus event; 399

 a facilitator skilled in the causal analysis technique, desirably trained or experienced in the 400

facilitation of the causal analysis technique; 401

 at least one member experienced in the causal analysis technique being applied. 402

Team members can change depending on the activity being conducted e.g. team members 403

responsible for data collection will not necessarily be the same as those conducting the 404

analysis. Team members can include engineers, technicians, operators, sales 405

representatives, managers etc. The use of external parties should be considered to provide 406

an independent perspective and avoid blind spots that may exist in the organisation. 407

Additional team members should be included for specific activities during the investigation to 408

either bring expertise into the team or to increase the influence of the team. The role of these 409

additional team members is to support the investigation so that it is not h alted for technical or 410

organisational boundary reasons. It is not appropriate for persons who may have had a role in 411

causation of the focus event to be part of the team. Their input should be collected during the 412

first two steps. 413

RCA can be effectively carried out by one person provided that person is experienced with the 414

causal analysis technique, is a domain expert (or has immediate access to domain experts) 415

and has access to all the data required. However, it is more common to conduct RCA as a 416

team. 417

5.3 Establishing facts

418

This step includes all the activities necessary to prepare for the analysis. Establishing the 419

facts is usually the largest part of the RCA. Facts should be determined on ‘what’ happened, 420

‘where’, ‘when’ and ‘by whom’. 421

Data should be collected, before it is lost (e.g. before evidence is disturbed or removed, or 422

memories fade). Data should aim to identify: 423

 the context in which the focus event occurred; 424

 the conditions before, during, and after the focus event; 425

 personnel involvement including actions taken (or not taken) and decisions made; 426

 context data about the surroundings, including environmental data ; 427

 how the organisation operates including organisation charts, processes and procedures, 428

training and skills data; 429

 historical data relating to similar events or precursors; 430

 deviations from the expected; 431

 interactions with other items and personnel; 432

 equipment involved and its operating state . 433

The following lists examples of data that may be relevant. 434

 Inspection of physical evidence such as failed components and failure reports. Generally, 435

it is experience that will determine what physical evidence is required. If there is doubt, 436

the evidence should be retained, it is also important to preserve the evidence. 437

 Photographs and videos taken by monitorin g cameras. Photographing the area of the 438

occurrence from several views will also b e useful in the analysis phase. 439

(15)

 Operational data, recorded by monitoring systems, control systems, alarm and event 440

loggers etc. Operator logs can be critical to understanding the operating conditions at the 441

time of failure and since they are typically dated, they are ideal for generating a timeline of 442

events. 443

 Personal testimony gathered by conducting interviews. Interviews should concentrate on 444

data collection e.g. building a consistent timeline etc; any premature discussion of the 445

causes of the failure may adversely impact the interview process. Questions should 446

be prepared before the interview to ensure that all necessary information is obtained. 447

Interviews should be conducted with those people, who are most familiar with the focus 448

event, however, consider interviewing other personnel e.g. people who have performed 449

the job in the past. All interviews should be documented. 450

 Documentary evidence of relevant procedures, o perating environment and regulatory 451

environment. 452

Once all the data associated with the focus event has been collected, the data should be 453

reviewed for correctness and suitability, missing data should be obtained and any 454

inconsistencies should be resolved to ensure a clear and consistent picture of the focus event 455

is determined. 456

This step can include failure analysis which examines failed components using a wide array of 457

methods including microscopy, spectroscopy and Non -Destructive Testing or models on the 458

development of failure such as fire modelling or crash modelling. 459

The outcome of this step is information and understanding, supported by physical evidence 460

and witness statements, concerning: 461

 what happened including the circumstances that lead to the focus event; 462

 the time sequence of events which lead to the focus event; 463

 the location of the focus event; 464

 actions of people associated with the focus event; 465

 any necessary conditions for the focus event; 466

 the consequences of the focus event. 467

5.4 Analysis

468

5.4.1 Description

469

Having determined ‘what’ happened, ‘where’, ‘when’ and ‘by whom’, this step establishes 470

‘how’ and ‘why’ the focus event occurred. The objective of this step is to understand the focus 471

event and its causes by structuring the data that has been collected into a form that allows 472

root causes to be systematically derived. 473

RCA normally analyses facts to identify the causal factors that were necessary for the focus 474

event to occur. However in some cases, for example where sufficient facts are not available, 475

the analysis may propose one or more hypotheses for cause and may also identify 476

contributing factors and prevailing conditions which were possibly associated with the focus 477

event, but cannot be proven to be necessary causes. 478

Analysis involves the following. 479

 Organising the physical evidence and witness statements concerning actions, events, 480

conditions and outcomes. 481

 Seeking how and why the focus event occurred using the data collected to justify 482

conclusions. Models of causation, laboratory testing, check lists and taxonomies or 483

statistical analysis of data may be used to assist this process. 484

 Looking beyond direct causes to why those causes occurred. The aim is to seek all factors 485

(and conditions) that contributed, not only the immediate or obvious causes. 486

(16)

 Continuing this process until the stopping rule is invoked and root causes identified. There 487

may be multiple root causes which can be independent or inter related. 488

In general causes may involve technical issues, human aspects and factors relating to the 489

physical or psycho-social environment in which the focus event occurred. All of these should 490

be considered in seeking root causes. People with expertise in these areas should therefore 491

be involved in the analysis. 492

Causes should be described clearly and unambiguously. Where a human action, omission or 493

decision is identified as a cause, the nature of the act or decision should be specified e.g. ‘the 494

operator switched off the wrong power switch’ and not the human error. 495

The analysis of cause (depending on the purpose and scope of the analysis) can consider: 496

 how the focus event occurred i.e. the physical chemical psychological or logical process 497

that was involved; 498

 preceding events or conditions that were necessary to the focus event occurring; 499

 relationships between causal factors including how they combined to cause the focus 500

event and how a root cause leads to the focus event; 501

 organisational and management influences and human factors that were involved in the 502

focus event or in the events and conditions leading up to it; 503

 prevailing conditions that may have contributed to the event occurring but were not 504

necessary causes; 505

 matters of concern that could lead to other focus events (these are not strictly causes but 506

may be an outcome of the analysis). 507

A structured analysis technique should be used to perform the analysis. S everal formal 508

techniques exist ranging from those that are based on a checklist of causes to techniques that 509

guide the analyst through consideration of causes and graphically present the results. The 510

techniques range from simple to complex and require suitably skilled practitioners or 511

facilitators to conduct the analysis. Some techniques are based on particular models of how a 512

focus event occurs and hence give a particular emphasis to the results. The different models 513

are based on different hypotheses with regard to the causation therefore they tend to lead the 514

investigator to identify different contributory factors. 515

In some cases it is appropriate to use more than one technique or take into account 516

considerations of more than one model to identify all root causes. 517

Models of causation are described in Annex B and a nalysis techniques are described in 518

Annex C. The most appropriate technique will be dependent on the focus event and the 519

purpose and scope of the analysis (see clause 6). 520

The analysis may indicate that further data is required. Requests for such data should be 521

expected to occur throughout the analysis to resolve inconsistencies or complete gaps in the 522

analysis. The analysis should continue until a ‘stopping rule’ is invoked. 523

5.4.2 The analysis team

524

A leader should be appointed for the analysis step, who is responsible for the following 525

preparatory work. 526

 Obtaining copies of the agreed role and responsibilities of the team, and purpose and 527

scope of the analysis. 528

 Obtaining copies of the focus event description and the facts established. 529

 Deciding the analysis technique(s) to be used. 530

 Converting the focus event description and facts established into a suitable format for use 531

in the analysis technique selected. 532

 Developing an analysis plan. 533

(17)

 Forming the analysis team. 534

 Facilitating or arranging for training of team members in the analysis technique selected. 535

 Selecting software tools or other templates for use during the analysis . 536

 Arranging for a search to be made of datab ases, media, legal proceedings etc. to identify 537

focus events of a similar nature, or which may have occurred with the same or similar 538

technologies. 539

The leader should review the information available to determine what analysis technique(s) 540

should be applied and what skills are required. Expert advice in the field of RCA may need to 541

be obtained regarding the selection of the analysis technique. The leader may also require an 542

expert RCA facilitator for all or part of the analysis, depending on the complexity o f the focus 543

event, the complexity or volume of evidence and data or analysis technique selected. 544

The analysis is usually carried out by a team, with each team member being chosen for their 545

experience and skills. The analysis team should be as small as pos sible, consistent with the 546

relevant technical and operating skills and experience being available. Where input will be 547

required from multiple parties, stakeholders or entities, the analysis team should contain 548

representatives of each. It is the leaders responsibility to ensure the relevant stakeholders are 549

informed, so that adequate stakeholder representation is available during the analysis. 550

The role and responsibilities of the analysis team members should be determined and 551

milestones established at the outset of the analysis. A programme of meetings should be 552

developed, which reflects the objectives and milestones provided to the analysis team. This 553

will ultimately enable any recommendations to be carried out in a timely fashion. 554

The leader should develop an analysis plan, which should contain the following: 555

 focus event description; 556

 agreed roles and responsibilities of the team, and the purpose and scope of the analysis; 557

 a list of team members and the stakeholders to be represented; 558

 time, date and location of the analysis meetings; 559

 a summary of the data available; 560

 analysis technique(s) to be used; 561

 arrangements for training the analysis team in the selected analysis technique (if 562

required); 563

 the form of recording of the analysis and the analysis results, inclu ding reference to any 564

templates or software tools to be used. 565

Adequate room facilities with visual and recording aids should be arranged by the leader for 566

the efficient conduct of the analysis meetings. A briefing package consisting of the analysis 567

plan and any essential pre-meeting reading or references should be sent to the analysis team 568

members in advance of the first meeting, to allow them to familiarise themselves with the 569

information available and the selected analysis technique. At the first analysis meeting a 570

physical review of the focus event via a re-enactment, mock-up, computer simulation or scale 571

model is desirable. 572

The leader should ensure that an appropriate communication system is in place for informing 573

and transferring the results of the anal ysis to those responsible for the next step of the RCA 574

process (see 5.5). 575

5.5 Validation

576

A number of review activities are conducted throughout the RCA process to determine 577

whether data collected is relevant and the analysis is representative of the data colle cted. 578

This step tests whether the causes identified in the analysis can be substantiated and may be 579

interleaved with the analysis or conducted as a separate activity . 580

(18)

An independent review can be carried out to assess whether the analysis is complete and 581

correct and to determine whether the purpose of the analysis has been fulfilled. The review 582

method will be dependent on the analysis technique used and on the focus event. In some 583

cases experiments can be performed to repeat the occurrence of the focus event, where 584

appropriate statistical methods should be used to assess the degree of confirmation of the 585

hypothesis of cause. If the causes are validated with the help of simulation, care should be 586

taken to ensure that the simulation is true in the casually -relevant respects. 587

During the analysis there may be several alternative hypothesis of how the event could have 588

happened, at the completion of the analysis the causes should be validated and only a single 589

hypothesis should remain. 590

This step may require further data collection to seek direct evidence to support or refute the 591

causes identified. Evidence may not always be available to fully validate all potential causes. 592

5.6 Presentation of results

593

The results of the analysis will depend on the purpose of the analysis. For example, if the 594

purpose of the analysis is to identify actions that, taken together, prevent further occurrences 595

of similar events, the analysis results should identify corrective actions which break the causal 596

network and prevent the focus event occurring again. If the purpose of the analysis is to 597

repeat successes, then actions that enhance the likelihood or the consequences of the focus 598

event should be proposed. The effectiveness of the analysis results is dependent on the 599

quality of the analysis. 600

An agreed format for presenting the results of the RCA should be developed that summarises 601

the analysis and captures the required outcomes from the analysis e.g. recommended 602

actions. If recommended actions are the required outcome from the RCA, t he summary should 603

include the following as a minimum: 604

 a general description of each cause and contributory environmental conditions requiring 605

action along with sufficient background information and detail to allow those who will make 606

recommendations and implement them to be able to understand the need to address each 607

cause and justify actions to be taken; 608

 a set of options for treatment actions, and where practicable and within scope a summary 609

of the benefits and costs of each; 610

 recommended actions to address each of the causes identified. 611

Recommended corrective actions should be evaluated for effectiveness and realism. In 612

general corrective actions aim to achieve the following: 613

 change the likelihood of the focus event and/or its consequences (i.e. reduce the 614

likelihood or consequence of undesirable events or increase the likelihood or consequence 615

of successful events); 616

 not introduce new unacceptable risks e.g. the safety of other systems must not be 617

degraded by the proposed corrective action. 618

Where actions are identified they should be reviewed prior to implementation to determine 619

whether they have not only addressed the root causes, but also not introduced new 620

unexpected consequences and will therefore function as intended. Also reoccurrence of the 621

same or similar event should be monitored. If an unexpected occurrence reoccurs, the original 622

focus event should be re-evaluated to determine why actions were not effective. 623

6 Selection of techniques for analysing causes

624

6.1 General

625

Formal techniques have been devised to help analysts identify causes and eventually root 626

causes. Analysis techniques may perform one or more of the following functions: 627

 organise data and provide structure to the analysis and identify where further evidence is 628

needed; 629

(19)

 provide a visual display of the evidence relating to the focus event for example the time 630

sequence of events or causal chains; 631

 conduct statistical analysis of the data, particularly from multiple similar ev ents, to identify 632

common causes; 633

 provide guidance to identify possible caus es for further investigation and comparison with 634

data (such methods include check lists and methods based on models of causation ); 635

 guide the analysts through multiple levels of cause to a set of root causes. 636

6.2 Selection of analysis techniques

637

RCA is undertaken in varying degrees of depth and may use one or several analysis 638

techniques ranging from simple to complex. The depth of the analysis and technique(s) used 639

should exhibit the following characteristics: 640

 be justifiable and appropriate to the focus event under analysis and the scope and 641

purpose of the analysis; 642

 provide results that enhance the understanding of the root causes of the focus event; 643

 be capable of use in a manner that is traceable, repeatable and verifiable. 644

The analysis techniques to be used are selected based on the applicable factors such as: 645

 characteristics of the analysis technique; 646

 characteristics of the focus event e.g. severity or potential severity or complexity; 647

 characteristics of the organisation e.g. industry/sector ap proved techniques or cost benefit 648

evaluation; 649

 purpose of the analysis e.g. outputs required or stakeholder expectations ; 650

 the causation model or models most appropriate to the objectives of the analysis . 651

The attributes of the most commonly used analysis techniques are described at Annex A. The 652

criteria used to characterise the techniques, described in Annex A, are as follows: 653  expertise required; 654  tool support; 655  scalability; 656  graphical representation; 657  modularity; 658  reproducibility; 659  plausibility checks; 660  intellectual rigour; 661  time sequence; 662  specificity. 663

The analysis techniques are described in Annex C, which includes the methods and process 664

used for each technique along with their strengths and weaknesses. 665

6.3 Useful tools to assist RCA

666

Modern data mining techniques enable a search for specific properties and conditions. 667

Clustering analysis selects data that are closely related, and thereby identify deviating data 668

(outliers). Modern cluster analysis can detect data that are closely related in one, two or more 669

dimensions and thereby analyse products or processes that are closely related and identify 670

deviating data points (outliers). An overview of these techniques is provided in Annex D. 671

(20)

Many focus events and analysis techniques involve human factors and several taxonomies 672

have been developed to assist in finding root causes where human behaviour is involved. Two 673

examples are given in Annex E. 674

(21)

Annex A

675

(informative)

676

677

Summary and criteria of commonly used RCA techniques

678

A.1 General

679

This Annex lists the most commonly used RCA techniques, with a brief description, and 680

provides a reference list of criteria which can be used to compare different RCA techniques. 681

The list is not comprehensive but covers examples of the different types of techniques used. 682

A.2 RCA techniques

683

Table A.1 provides a list and brief description of the most commonly used RCA techniques. 684

Table A.1 – Brief description of RCA techniques

685

Technique Description

Events and Causal Factors (ECF) Charting

ECF analysis identifies the time sequence of a series of tasks and/or actions and the surrounding conditions leading to a focus event. These are displayed in a cause -effects diagram.

Multilinear Events Sequencing (MES) and Sequentially Timed Events Plotting (STEP)

MES and STEP are methods of data-gathering and tracking for the anal ysis of complex focus events. The results are displayed as a Time-Actor Matrix of events.

The ‘Why’ Method The ‘Why’ Method is a simple series of questions that guides the analysis to the root

causes. Causes Tree Method

(CTM)

CTM is a systematic technique for analysing and graphically depicting the events and conditions that contributed to a focus event. CTM is similar to the why method in concept but builds a more complex tree and explicitly considers technical,

organisational, human and environmental causes. Why-Because Analysis

(WBA)

WBA establishes the network of causal factors responsible for a focus event using a two-factor comparison, the Counterfactual Test. The network of factors is displayed in a Why-Because Graph.

Fault Tree and Success Tree Method

Fault or Success Tree is a graphic display of information to aid the user in conducting a deductive analysis to determine critical paths to success or failure, which are displayed graphically in a logic tree diagram.

Fishbone or Ishikawa Diagram

The Fishbone or Ishikawa Diagram is a technique that helps identify, analyse and present the possible causes of a focus event. The technique illustrates the relationship between the focus event and all the factors that may influence it. Safety through

Organisational Learning (SOL)

SOL is a checklist-driven analysis tool, oriented towards focus events in nuclear power stations. Results in the visual form of a Time -Actor Diagram, derived from the MES/STEP method.

Management Oversight and Risk Tree (MORT)

The MORT chart is a pre-populated fault tree with events, usually faults or

oversights, expressed in generic terms. The MORT tree contains two main branches and many sub-branches giving a high level of detail. One main branch identifies about 130 specific control factors while the other main branch identifies over 100 management system factors. The chart also contains a further 30 information system factors common to both main branches of the tree.

AcciMaps AcciMaps is primarily a technique for displaying the results of a causal analysis. It

requires an organisational model to separate factors into layers and to elicit factors in the layers; applies a version of the Counterfactual Test (see WBA) to determine the causal relations amongst the factors.

Tripod Tripod is a tree diagram representation of the causal network, focusing on human

factors and looking for failures in the organisation that can cause human errors. Causal Analysis for

Systems Theoretic Accident Model and Process (STAMP) (CAST)

CAST is a technique that examines the entire socio -technical process involved in a focus event. CAST documents the dynamic process leading to the focus event including the socio-technical control structure as well as the constraints that were violated at each level of the control structure.

(22)

A.3 Criteria

686

Table A.2 provides a list and describes the criteria used to characterise the RCA techniques 687

listed in Table A.1. Each criterion has three levels indicated by a (+), (o) or a ( -), where the 688

different levels indicate the range. 689

The attributes for each RCA technique using the criteria in Table A.2 are shown in Table A.3. 690

Table A.2 – Summary of RCA technique criteria

691

Criteria Description Levels

Expertise required

Is the method targeted towards the "sophisticated user" (does it require use of techniques such as theorem proving which requires specific expertise)? Is it suitable for use by domain experts only?

 Intuitive, little training necessary (+).

 Limited training required e.g. one day (o).

 Considerable training effort necessary, e.g. one week (-).

Tool Support Is tool support necessary?  Can be well applied without

dedicated tool support, e.g. Office type tools (+).

 Tool support not required but usually needed for effective application (o).

 Tool support necessary, can be

applied only with dedicated tools support (-).

Scalability Is the method scalable? Can the method be used

cost-effectively for simple as well as complex focus events? Can a subset of the method be applied to small, or to less-significant focus events and the full capability applied to large, or to significant focus events? So the question of scalability asks whether the complexity of analysis using the method scales with the complexity of the focus event.

 Scales well with complexity (+).

 Limited scalability, considerable overhead with every application (o).

 Not scalable, the full method has to be applied (-).

Graphical Representation

What is the nature of the method's graphical representation?

The motivating principle is that a picture is better than a thousand words. It is often more

comprehensible to display results of an analysis method as an image, a graph, or other form of illustration, than as purely written text. The desirable properties of a graphical representation are:

 to display clearly the semantics of causality (including denotation of causal factors, and taxonomic classification of factors);

 to be cognitively (relatively) easily evaluated by a single person;

 ideally, a graphical representation could also display the history of the analysis.

 Graphical representation with clearly defined semantics and cognitively easy to understand (+).

 Graphical representation, but without semantics (o).

 No graphical representation defined

(-).

Reproducibility Are the results of the method reproducible? Would different analysts obtain similar results for the same focus event?

 The results can be reproduced,

differences are only observed on the representation of the results, wording etc. (+).

 A significant amount of the results can be reproduced, but some differences will be observed (o).

 The results will depend on the analyst and their expertise (-).

(23)

Criteria Description Levels

Plausibility Checks

Are there reasonable, quick plausibility checks on the results obtained which are independent of the tool? What ways are there of checking the "correctness" of the results? One example would be checklists.

 There are plausibility checks for almost all aspects (+).

 There are plausibility checks, e.g. checklists, but they do not necessarily cover all aspects (o).

 There exist only limited means

supporting plausibility checks (-). Intellectual

Rigour

How rigorous is the method? Rigor has two relevant aspects:

 Does the method have a rigorous meaning,

formal semantics, for the key notions of cause, causal factor and root cause? Is the semantics easy to apply?

 Are the results of the method amenable to formal (mathematical) verification? To what extent is an application of the method so amenable?

 Formally defined and can be formally verified (+).

 Semi-formal definition (o).

 Informal definition (-).

Time Sequence Does the method contain a representation of time

sequence of events?

 Yes (+).

 Only indirectly (o).

 No (-).

Specificity The extent to which the method limits analysis to

necessary causal factors of the focus event rather than exploring a range of general problems with the system that existed at the time of the focus event and may have contributed.

 Method analyses specific necessary causes of the focus event (+).

 Method can be used to analyse

generic problems as well as the necessary causes of the focus event (o).

 Method seeks problems in general

whether or not they were necessary causes of the focus event (-).

(24)

Table A.3 – Attributes of the generic RCA techniques 693 Expertise Required Tool Support Scalability Graphical Representation Reproducibility Plausibility checks Intellectual Rigour Time Sequence Specificity ECF _o _o _o ₊ _o _o _o _- ₊ MES and STEP - o o + + o o + + The ‘Why’ Method ₊ ₊ _- _o _- _- _- _- ₊ CTM _o _o _o ₊ _o _o _o _- ₊ WBA _o ₊ _o ₊ ₊ ₊ ₊ _o ₊ Fault Tree and Success Tree Method _o _o _o ₊ _o _o _o _- _o Fishbone or Ishikawa Diagram + + - o - o - - o SOL _o _- ₊ _o ₊ ₊ _o ₊ _o MORT ₊ _- _- _o ₊ _o _o _- _- AcciMaps _o _o _o ₊ _- _o _- _- _o Tripod Beta _- ₊ _o ₊ _o _o _o _o _o CAST ₊ ₊ ₊ _o _o _o _o ₊ ₊

The criteria for each attribute is described in Table A.2.

BS en 62740. Root Cause Analysis (RCA). (Draft)

Date: 12 February 2014

Origin: European

DPC: 14 / 30267079 DC

EXAMPLE ONLY

56/1542/CDV

CONTENTS

INTERNATIONAL ELECTROTECHNICAL COMMISSION

ROOT CAUSE ANALYSIS (RCA)

FOREWORD

INTRODUCTION

ROOT CAUSE ANALYSIS

1

Scope

2

Normative references

3

Terms and definitions

4

Introduction to RCA

5

The RCA process

6

Selection of techniques for analysing causes

Annex A

(informative)

Summary and criteria of commonly used RCA techniques

A.1

General

A.2

RCA techniques

A.3

Criteria