DEM knowledge for managers

1CONFIDENTIALShell Global Solutions International

DEFECT ELIMINATIONand Root Cause Analysis (RCA)

Operational Excellence

Shell Global Solutions International 2CONFIDENTIAL

Defect Elimination is

A structured approach to eliminate technical or process failures, defects, potential problems or incidents (individual or repetitive) with emphasis on those with high consequential impacts to the business in relation to People, Environment, Reputation and Assets.


Features of Defect Elimination

A crucial and integral part of Risk & Reliability managementDEM is more than RCA. It includes management of incidents, solutions and actionsThe DEM process includes solution development and action tracking to completionIt is a change of Mindset towards

“Not accepting Non-conformity”and addressing problem solving in a structured way.It is a Re-active approach and complements pro-active Maintenance


Why manage Defect Elimination ?

Some problems are lived withCauses may be known, but solutions not developedLost focus after patch repairEngineering driven, sequential & individual desk study approach doesn’t workPoor quality facts, or gaps in the informationPeople with the “Facts” not connected to those with the “Insights”

Can go beyond departmental & discipline boundaries Often involves many levels in the organisation

Group processes must be facilitatedMust avoid blameRequires discipline in executionNeeds external co-operation


Cost Effectiveness of MaintenanceC

OST

£££ MAINT COST OPTIMUM COST ££££££ MAINT COST

PREVENTIVE MAINTENANCE COSTS

COST OF NON-AVAILABILITYPRODUCTION LOSS AND REPAIR COST

TOTAL COST

TYPICALLYUNDER

MAINTAINED

TYPICALLYOVER MAINTAINED

FIRE FIGHTING MODE

COMFORTZONE

RISKBASED

RISK & RELIABILITY

MANAGEMENT


Why a Structured Approach?

We often don’t do it very wellProblems are often poorly understoodWe tend to concentrate on technical causesGoing far enough (or too far) is often a problemOften not enough structureOften a Silo approach used

People tend to jump to conclusionsInformation sources not always fully tappedRoot causes can go up to 5 layers deeper than manifestationsContributing/related circumstances are not always obviousPeople often want the easiest way out


“We often don’t do it very well”

The most important reasons for not solving problems:

- Incomplete Problem Definition- Unknown Causal Relationships or Facts- A Focus on Solutions

Effective defect elimination is one of the key success parameters of a reliability management process

Root cause analysis is the heart of any “defect (or bad actor) elimination” program


Team Approach

Ok, we all know what the root

cause is, right?

YOU

No procedures

The Contractor

The Operators

Cheap parts

Poor communication


“We Tend to Concentrate on Technical Causes”

We like technical solutionsPlenty of evidence that at least 50% of failures have human related causes...

…often because people are doing what they think is correct (training or operating philosophy)or…

because they are following instructions that are wrongor…

because the instructions are inaccurate or not clear


“Going Far Enough or Too Far”

pump failedbolt loose

mechanic errortired

didn’t sleepchild sick

ate bad fooddirty

restaurantcook

didn’t wash

root cause??

how far do we go?

Manageable

Outside influence area


“Often Not Enough Structure”

Simple problems => simple unstructured approach (symptom = cause)…

BUT:More complex problems (what is the problem?… sometimes we don’t know!) require a more structured and detailed approach.Often it is difficult to differentiate between cause and effect…

don’t eliminate symptoms……go after the defect that produces the

symptoms!


People Tend to Jump to Conclusions

Analyse

Solve

Implement

Observe

“Engineer’s

shortcut”“I’ve

seen that before and I know what to do to fix

it”

Defect Elimination Management


I. Incident Capture

II. Problem AnalysisIII. Root Cause Analysis

IV. Solution Development

Defect Elimination in a nutshell (4 stages)


Defect Elimination: 4 Phases (1)

The first phase of an effective Defect Elimination Program is: to capture and prioritise events that cause deviation

from the production plan (event logging)…

and to identify bad actors or equipment that fail too

frequently or has a history of expensive repairs… (This requires historic data to be analysed on an ongoing basis …)


Defect Elimination: 4 Phases (2)

The second phase is to analyse and define the problem through a gathering of facts and formulation of a problem statement

to prevent working on the wrong problem.

The third phase is an effective, structured Root Cause Analysis (RCA) process...

The fourth phase is the development and implementation of a solution that meets with set of criteria without creating new or worse problems.


Phase Description Steps Deliverable 1. Incident Reporting

Incident Report I.

Incident Capture

The capture (recording) of an incident along with relevant information AND the decision as to whether an RCA must be carried out AND if so, at what level the investigation will be conducted.

2. Incident Ranking Level of Investigation

3. Problem Identification

Problem statement II.

Problem Analysis

The breaking apart of a complex situation into manageable pieces. Answers "what is the problem?"

4. Problem Definition List of Facts 5. Possible Cause Analysis

Possible Causes

6. Data Validation Probable Causes 7. Cause Verification Root Causes

III.

Root Cause Analysis

The systematic search for cause(s) of a problem. Answers "why?”

8. Decision Statement Decision Statements 9. Criteria Selection Musts and Wants

10. Alternative Solutions Conceptual Solutions

IV.

Solution Development

A systematic technique to select best balanced choice (one that eliminates cause without creating new / worse problems).

11. Decision Analysis Best Balanced Solution


Key Success factors

Workshop format; not a 1-man desk exerciseMultidisciplinary, multi layer, multi departmentShort, sharp, focussedFacilitated by ‘outsiders’ to the problemFocus on facts and possible causal linksFollow up all the way to implementation

Phase I: Incident Capture


Incident Capture provides the base for defect elimination. Capture the information related to the problem, establish the consequences, decide whether an RCA is required and at what level.

STEP 1 The purpose of this step is to captureIncident Reporting (immediately) the circumstances

surrounding an incident by those closely involved.STEP 2 Identify the most critical incidents

with maximum Incident Ranking impact on the business. Address these first. Also decide the depth of investigation.

PHASE 1: INCIDENT CAPTURE (2 STEPS)

Tools: Incident Incident Reporting Ranking

- Incident Report - Risk Matrix


Step 1: Incident Reporting

Incident Reporting should contain the following FACTS:DESCRIPTION (factual) of the eventsWHAT is the item having the troubleWHEN did it happenWHERE on the item/was the item (location)CONSEQUENCE of the incident WHO is involved


Step 2: Incident Ranking

Collect all reported incidentsIdentify the most critical incidents with the most impact on the business to be addressed first with the limited resources that are available.Decide on the appropriate depth of investigation (incl. Expertise) and right level of management attention.Assign responsibility for solution development.Set target date for completion.


0

5

10

15

20

25

Number of Pump Failures 20**

Failures

Select the most Critical - Pareto

Bad Actors But what impact ?


Reliability RAM Example

5 Why

Defect Elimination

Phase II: Problem Analysis


PHASE II: PROBLEM ANALYSIS

Problem Analysis is essential to the success of problem elimination. This phase focuses on identifying and defining the problem.

All too many times … in our eagerness to fix problems … we march off into solving problems that are not well defined and fail to eliminate the cause.

STEP 3 Allows us to develop an agreed statement Problem Identification of the problem in terms of actual versus expected performance.

STEP 4 The more accurately the problem can be Problem Description defined in terms of what, where and when “it is” and ”is not”, the better the chance of success in finding the root cause.


Concentrate on “WHAT is the Problem”Gather and List all problems, concerns and effectsGroup and cluster into problem areasPrioritise problem areas based on impactDevelop a Problem Statement:

an object… …has an actual versus expected performance …with measurable impact

Step 3: Problem Identification


PHASE II - STEP 3: PROBLEM IDENTIFICATION

WHAT is “a Problem Statement” ?The output of the Problem Identification step . It provides a clear starting point and level of expectation

an object……has an actual versus expected performance …with measurable impact

Statement must be consistent with the ranking process results

It is usually easier to write as bullet points rather than spending time on an concise statement


Problem Statement - Example

Expected - Pump XYZ is expected to have flow rate of 1000 M3/h

Actual - Since July 7 pump XYZ has a max flow rate of 800 M3/h

Impact - This lower flow rate results in a $5,000/day loss of production

Problem

Statement

= Expected – Actual + Impact


TECHNIQUE TIP

Start with the Incident Report and/or brief summary of the problem by the problem owner.

Questions by investigation team to get perspectiveBrainstorm the issues and collect on post-its

Compile and write up problems and concernsCluster and summarise into issues


Step 4: Problem Definition (Data Gathering)

What FACTS do we have that indicate there is a problem?Make sure facts, data & evidence are captured from startIdentify information sources and verify data qualityLook for information related to the defectDevelop a timeline of events/triggers for all concernsUse tools and models to focus

Answer the question WHAT? and not WHY?.


Data & Information Quality

Data (DCS)Facts (Evidence)Inferences (Logical conclusions)AssumptionsOpinions (Experts have lots!)BeliefsHearsay (Distorted 2nd hand information)Guesses (Those who can’t say “I don’t know”)Fantasies (Saying what you ought to have done)


Quality

Data (DCS)Facts (Evidence) Inferences (Logical conclusions)AssumptionsOpinions (Experts have lots!)BeliefsHearsay (Distorted 2nd hand

information)Guesses (Those who can’t say “I

don’t know”)Fantasies (Saying what you ought to

have doneTips for Success Make a list of data needs ahead of time to help reduce rechecks Use interviewing to get an understanding of beliefs and opinions and

then verify with higher quality data. Target for FACTS.


Timeline

‘Brown’ Paper exerciseFind sequence of events => rough timelineWrite down events on ‘stickies’Stick on PaperPlenary session on refining timelineConnect facts to dates

Jan-99

Mar May Jul Sep

Events

Jan-99

Mar May Jul Sep

Events

Phase III: Root Cause Analysis


Phase III: Root cause Analysis (RCA) (4 steps)

RCA focuses on determining the causes of the problem as identified in the Problem Statement

and as defined by the Problem Description. It takes discipline and practice to adhere to the

process. An open mind has great impact on the success of

RCA. Traditional pit-falls are poor data quality and

jumping to conclusions. A wide range of tools are available RCA is not standardised (not trademarked)


Possible cause

(STEP 5)

Probable causes

(STEP 6)

Root cause(STEP 7)

STEP 5 Determines possible causes to the problemPossible Cause Analysis STEP 6 Determines which of the possible causesData Validation identified above have supporting

facts. These become probable causes.STEP 7 Identifies which of the probableCause Verification causes match the Problem Description

to become Root Causes.STEP 8 Generates a Decision Statement to

define Decision Identification what the corrective actions need to achieve to solve the root cause of the problem

Phase III: Root cause Analysis (RCA) (4 steps)


Step 5: Possible Cause Analysis

In this dynamic brainstorming step all possible causes that relate to the problem as described in the problem statement are listed looking at the chain of events and conditions (causes and effects) that resulted in the “Primary Effect”.

Here a start is made to answering the questions:What could cause that to happen?Why did it happen?


Phase III - Step 5: Possible Cause Analysis

Generate / Brainstorm possible causes:Start with the Primary EffectWHY did it happen?What could CAUSE that to happen?Tips: Keep in mind : Each Effect has been Caused by something ..continue

Questioning Build a chain of cause and effect Preferable to execute with a multi disciplinary team of experts Be open minded & think out of the box Don’t start arguing over possible cause Make use of facilitator and the proper tools More Possible causes might come after the one brainstorm session,

add - do not ignore


The Cause and Effect Diagram

The Cause and Effect Diagram developed by Apollo Associates (RCA Consultancy) is probably the most useful and frequently used RCA tool. It is a technique that is easy to learn and can be used in virtually every situation.

PrimaryEffect

Cause

CausedBy

ACTION

CONDITION

Evidence

Evidence

Evidence

Cause


1. Start from Problem definition with brainstorming2. For each Primary Effect, ask “why?”3. Look for causes 4. Connect all causes with “caused by” or “And & Or” 5. Support causes with evidence or use a “?”

Principles of Creating a Cause and Effect Diagram


Tips for Cause and Effect DiagramTips: Avoid ‘Why Not’ – positive not

defensive Be specific. Take small steps Record all discussion – even if

cause is discounted Start with the (ranked) incident Stop when you start guessing You may have to return to steps

4/5/6 to complete the tree Check back up the tree – are

causes necessary and sufficient?Techniques: The structure of the cause tree is important and can be

limiting Build expert models Alternatively ‘Brainstorm’ and then group


Step 6: Data Validation

Data Validation is used to determine which of the Possible Causes have Supporting Facts.It’s purpose is to eliminate poor logic and unverifiable data.It ensures that the Problem Solving Process remains fact based and that recommendations address cause.


Phase III - Step 6: Data Validation

Possible causes (Step 5) are reviewed in this step to check the supporting facts and decide it they are Probable CausesThis is aimed at eliminating poor logic and unverifiable dataIt ensures that the Problem Solving Process remains fact based and that recommendations address cause.

Possible cause

(STEP 5)

Probable causes

(STEP 6)

Rootcause(STEP 7)


Are there facts tosupport the cause?

Are there facts toeliminate the cause?

Is more dataavailable to support

the cause?Probable Cause Out

Remains Possible Cause

N

N

N

Y

Y

Y

SUPPORTING FACTS

yes

yes

yes

no

no

no


Step 7: Cause Verification

This final step of RCA verifies which of the probable causes match each dimension of the Problem Description: IdentityLocationTimingExtent


Phase III - Step 7: Cause Verification

Goal of Cause Verification is to ensure that Probable causes

are linked to the problem

Verify which of the probable causes match each dimension

of the Problem DescriptionIdentity / Location / Timing / Extent

Test if a cause is also the “Root Cause” proven before – knowledge not ‘expert opinion’

elimination

repeat


Known as Root Cause elsewhere

in past?

Match all 4:Identity, Location, Timing

& Extent?

Will reversingthe cause eliminate

the problem?

Will initiatingcause repeat the

problem?

Root Cause Out

Remains Probable Cause

Y

N

Y

Y

Y

N

N

N

Matching


Failure Scenarios (Optional)

Using the found Root causes an effort should be made to capture the logic of the sequence of the events from the root causes to the failure in words to describe one or more Probable Failure scenarios.


It is important to define ‘Root cause elimination Statements’ which clearly state what must be corrected for each Root Cause before trying to define possible solutionsThis should be summarised in 1-2 sentences defining the Object/Subject, Action and desired Result.

ExampleA Root Cause is: Debris in Instrument Air => plugged the positioner of the trip valve => false trip and unit shut down.Root cause elimination Statement: Prevent debris in the Instrument Air System from causing false trips which result in a unit shutdown

Step 8: Decision statements


EXAMPLE - SUBJECT, ACTION, DESIRED RESULT

Root Cause: Rust debris in the Instrument Air plugged the positioner of a trip valve which in turn shut down the unit

Subject Debris in the instrument airAction Eliminate or PreventResult False trips and unit shutdown

GOOD: Prevent debris in Instrument Air System to avoid plugging the positioner of the trip valve and so avoid a unit shutdown

BAD: There is a need to improve Instrument Air quality, especially to unit trip valves.

Address the Cause. Not too narrow; Not too broad

Phase IV: Solution Development


It is not root causes we seek,

it is effective solutions

…. but ..What is the best solution ???



STEP 9 Compile for each root cause a set of Criteria Selection “must" and “want" criteria and agree

on their importance to the solution

STEP 10 Generate alternative solutions to Solution Definition eliminate each root cause and clarify

the required resources which of the possible causes

STEP 11 Select and describe for each root cause theDecision Analysis best solution based on the

effectiveness to meet the criteria. Report and present.

Phase IV: Solution Development (3 steps)


1. Prevents recurrence• prevents this problem• prevents similar problems

2. Doesn’t create additional problems3. Within your control (manageable)4. Meets your goals and objectives

A solution must meet the following criteria:


ProblemDefine solution criteria (premises)Identify “MUSTs” and “WANTs”Propose solutions A, B, C, D… Screen based on MUSTs some solutions outRank based on WANTsCheck if Solution(s) cover the Decision StatementsBest solution



Step 9: Criteria Selection

Determine Premises for solutions: (What would make you happy .....)

“Go” or “No Go”

And determine the relative weight of the ‘Want’ criteria

Musts and WantsDecision Criteria Weight FactorMust achieve Y/NMust avoid Y/NMust maintain Y/NMust ….. Y/NMust ……. Y/N

Want to achieve 7Want to ………. 2Want to ……. 10Want to avoid 1Want to …… 4Want to …….. 4Want to …. 7Want to maintain 6Want to …… 7Want to ……… 2Want to …. 5Want to …… 3


Step 10: Alternative Solutions

Review the root causes, Failure scenarios and/or Decision statements Generate a range of alternative solutions at conceptual level (use Decision statements)Project; Process control; Design changeProcedure change; DocumentationRules; Standards; PoliciesTraining of skills; KnowledgeLeave as-isCombination of the above


Step 11: Decision Analysis

Compare benefits of each alternative solution against Musts/WantsQuantify cost and benefits of each solutionEliminate all solutions that do not fulfil all MustsEliminate solutions that are not cost effectiveIdentify and evaluate new risks introduced with implementationDetermine the weighted score for each remaining alternativeloss is balanced against the cost of implementation.Select the alternative(s) with the highest score


Management Decision

The final step in the process is to ensure the appropriate level of management support and will implement the solutionA standard report is recommended to record the investigation, analysis and decisionsPresent a summary to management of the key points of the investigation, proposed solution(s) and risks Ensure the close-out is a clear endorsement of the decision and actions


Implementation

It is not root causes we seek,

it is effective solutions BUT…Solutions are no use

without effective implementation


Thank You…

…any Questions?

64CONFIDENTIALShell Global Solutions International

Defect EliminationHeavy Diesel Colour Problem Report Out

Steering Committee


Objective of this presentation

The Objective of this presentation is to:1. Inform about the DEM workshop results

2. Have the steering committee approve the action plan


Agenda

IntroductionOutcome of the workshopProblem analysisRoot cause analysisSolution developmentProposed recommendations for approvalSummary of decisions


Introduction

The team finished the defect elimination workshop for the CDU heavy diesel colour problemFrom the DEM process a number of recommendations have followedThe ORMS Steering Committee needs to understand and approve the recommendationsThis presentation will give you the background information required to approve the recommendations


CDU was shut down because of HGO colour

HGO colour spec could not be met

This was not caused by

heat exchangers

Atmospheric column must be inspected

After start-up the colour specification of the HGO was not OK. All other quality specs were

good for HGO and the other products

A leak in a heat exchanger was expected. After tests it turned out that none of them were leaking. The cause was something else

After checking all other options, the atmospheric distillation

column internals were the only cause that remained. The unit had

to shut down again


Between tray 30-40 much damage observed

Tray 30 and 36

Tray 34-35

Tray 39

Tray 40

• Parts of the tray were missing in the north-

west section

• Parts of the tray were missing in the north-

east section

• Manholes of the tray were missing

• 80% of the tray was missing

Feed


A rapid vapour expansion occurred

FeedLarge vapour flow moving up

Tray 40Tray 39


Cause and effect tree shows the relations

Diesel colour spec

not met

Simplified version for

presentation !!

Tray damage

after vapour expansion

Liquid crude and water came into

the column

Hot surface available in

column

Furnace was cooled

down quickly

Distillation column was

still hot

Fast shutdown of

the CDU was

executed


One major root cause was identified

1

• During the fast shutdown, the furnace was switched off and cooled down. Liquid feed (including water)

then entered the column. The column was still very hot, and the liquid feed rapidly evaporated inside the

column. This damaged the trays

Fast shutdown of the CDU was

executed


Criteria for solutions were defined by team

MUST criteria• The solution must never harm people in the refinery in any way• The cost of a solution must never be larger than the benefit it

creates• The solution must never lead to new significant risk (medium or

higher) in this or other process unitsWANT criteria

• The solution should not lead to unplanned shutdowns• The solution should be proactive, meaning that it

should (contribute to) prevent the problem from occurring again

• It should be possible to apply the solution within 6 months using the resources available in the refinery

• The solution cost should be as low as possible and not exceed $100,000

Ranking32

2

2


New procedure will eliminate the root cause


Approval required for the recommendations

Revise procedure and train staff for

compliance

Solution

• Review the CDU shutdown procedure and make adjustments if required

Description

• Train the operator staff to ensure that the procedure is used for future

shutdowns

Timing

• Short term

• Medium term

For your consideration: how do other units follow operational procedures??


THANK YOU

DEM knowledge for managers

Documents

Transcript of DEM knowledge for managers