Comprehensive Notes on Step 2: Understanding the Process in Root Cause Analysis

The Necessity of Process Review in Problem Diagnosis

• Problem diagnosis often fails because organizations do not review the processes that could have failed.

• Instead of systematic analysis, decision-makers often rely on quick, intuitive, but biased decisions regarding the origin of a problem.

• Jumping directly to possible causes leads to the exclusion of many other potential causes.

• Understanding the Process: This stage involves stepping back to gain a broad view of the problem before analyzing causes. This is particularly critical if a problem was previously considered "solved" but has since recurred.

Establishing Process Boundaries for Diagnosis

• To begin Step $2$, boundaries must be established to limit the scope of analysis.

• Ending Boundary: Typically easy to identify, as it is the point where the problem was discovered.

• Beginning Boundary: More difficult to determine, but involves two primary recommendations:

  • Maintain Internal Focus: Concentrate on processes over which the organization has direct control. It is common but counterproductive to blame internal or external suppliers or to analyze the entire system immediately.

  • Narrow Scope Strategy: Keeping boundaries narrow initially ensures information is readily available and process steps are better understood.

  • Supplier Leverage: If internal analysis indicates a supplier is at fault, the internal data serves as leverage and proof for external corrective action.

Considerations for Process Timing and Boundary Flexibility

• Relative Timing Perspective: The frequency of a process should inform where to look. Some processes occur $\text{dozens, hundreds, or thousands}$ of times per day, while others are rare ($Figure \text{ } 4.1$).

• Boundaries and Scope: Boundaries exist to help scope the analysis, but specialists must remain flexible.

• Criteria for Adjustment:

  • If new information suggests the cause lies outside current boundaries, the boundaries must be expanded.

  • The goal is to continually narrow boundaries until only the cause remains between them.

  • If the cause is not found, the boundaries were likely defined too narrowly and must be broadened by definition.

Flowcharting the Process: Techniques and Standards

• Once boundaries are set, a flowchart is constructed for visual clarity. Pictures and symbols are processed better by the human mind than lists of words (Roam $2008$).

• Action Orientation: Words inside flowchart boxes must be action-oriented verbs.

• Standard Flowchart (Process Map): Uses boxes connected by arrows to show the flow of product, people, information, or money ($Figure \text{ } 4.2$). Standardized symbols from $Figure \text{ } 4.3$ can be used, though rectangular boxes are often sufficient.

• Deployment Flowchart (Swim Lanes): Places steps in specific lanes to designate the group or location associated with that step ($Figure \text{ } 4.4$).

• Step Count Recommendation: It is recommended that a flowchart have no fewer than $4$ and no more than $8$ steps.

  • Too little detail prevents understanding.

  • Too much detail wastes resources, especially if steps are later ruled out in Step $3$.

• Parallel Paths: More detail may be needed if there are parallel paths (e.g., multiple airline counter personnel) to assist in data stratification during Step $4$.

Standardized Flowchart Symbols ($Figure \text{ } 4.3$)

• Decision: Typically represented by a diamond.

• Document: Represents specific paperwork or records.

• Delay: Indicates waiting periods in the flow.

• Page Connector: Used to link sections across different pages.

• Online Storage: Indicates data saved in a digital system.

• Connector: Links discrete parts of the chart.

• Process Step: Standard rectangular box for actions.

• Begin/End: Ovals or rounded rectangles for start/stop points.

• Input/Output: Data or materials entering/leaving the process.

• Display: Represents information shown on a screen.

• Manual Operation: Actions performed by hand rather than automatically.

Primary versus Administrative/Support Processes

• Primary Process: The main sequence involved in the problem ($Figure \text{ } 4.5$). Physical causes are usually found here.

• Support Processes: Feeder processes like personnel hiring, training, equipment acquisition, and maintenance. System causes are usually found within these administrative layers.

• Diagnostic Caution: Digging into support processes before the physical cause in the primary process is found can lead to an unproductive "random search."

• Non-Standardized Processes: If no standardized documentation exists (e.g., policy implementation), a generic process flowchart can be developed to diagnose compliance issues ($Figure \text{ } 4.6$).

Defining Process and Guidelines for Flowchart Construction

• Definition of Process: The time sequence (physical or logical) in which something is carried out. This includes:

  • Information flow in a computer network.

  • Sequence of controls for an elevator.

  • Human thought processes involved in decision-making.

• Guidelines for Breaking Processes into Steps:

  • Location: If steps occur in different locations, each location should be a separate box.

  • Actor: If different people do work in the same location, each person should be a separate box.

  • Time: Strive for each step to represents a similar duration of time.

• "Should Be" vs. "Actual":

  • Repetitive Problems: Start with the "should be" (standardized) flowchart and look for deviations.

  • Incident-type Problems: Flowchart what actually happened first, then compare it to the standard (see Chapter $11$).

The SIPOC Model and Process Logic

• Everything done in an organization is a process, represented by the SIPOC diagram ($Figure \text{ } 4.7$):

  • S: Supplier

  • I: Input

  • P: Process

  • O: Output

  • C: Customer

• Failure occurs when objectives are not met because something went wrong within this timing sequence. This logic applies to entire organizations or narrow departmental tasks (see Appendix B, Figure $B.1$).

Root Causes of Process Failure

1. Lack of Defined Standards: Without standards, people act on personal perception. While creativity is good, critical and repetitive processes require procedures, work instructions, checklists, or training.

2. Incorrect Process Definition: Definitions may be too specific (preventing necessary variance) or not specific enough (creating excess variation).

3. Non-Followance of Definition: This may be intentional or unintentional, often driven by a need for workarounds due to incorrect definitions or external pressures.

System Failure vs. Individual Error: The Human Component

• Systems (equipment, info, resources) provide the environment for work. When problems occur, the question should be "Which process failed?" rather than "Who did it?"

• Often, the system is not robust enough to prevent error.

• Fitness Club Case Study: Several customers at a high-end club complained of misspelled names on cards.

  • Physical Cause: The desk clerk has dyslexia.

  • System Cause: A failure in the hiring/screening process allowed the placement of a person into a role where their condition would lead to errors.

  • Replacing the clerk only addresses the physical cause, not the system cause.

• Sydney Dekker Quote ($2006, \text{ } xi$): "Instead, find how people’s assessments and actions made sense at the time, given the circumstances that surrounded them."

Additional Value of Flowcharting in Diagnosis

• Identifying Stakeholders: Shows who needs to be involved in the diagnosis based on where the process failed.

• Culling Possible Causes: Helps identify which steps could or could not have contributed. In Step $3$, flowchart steps become the primary considerations for possible causes.

• Data Collection Points: Identifies where steps can be evaluated for efficacy.

• The Drill Down Method: As the diagnosis cycles through the $5$ steps and asks "why," the flowchart is viewed in increasing detail to narrow boundaries until the cause is found ($Figure \text{ } 4.8$).

• Cautions for Drilling Down:

  • Boundary Congruence: Ensure narrowed steps remain within the logical flow established by higher-level boundaries.

Problem diagnosis often fails because organizations do not review processes. Decision-makers may rely on quick judgments rather than thorough analysis, leaving out many potential causes. It's essential to understand the process by taking a step back before diving into cause analysis, especially for previously "solved" problems that have reappeared.

Establishing Process Boundaries for Diagnosis

• Boundaries are crucial for focused analysis.
  

  • Ending Boundary: Easy to find, at the problem discovery point.

  • Beginning Boundary: Harder to determine. Recommendations include:

  • Maintain Internal Focus: Concentrate on processes within the organization's control. Avoid blaming suppliers prematurely.

  • Narrow Scope Strategy: Start with a narrow focus to ensure clarity and availability of information.

  • Supplier Leverage: Use internal data to support actions against suppliers if necessary.

Considerations for Process Timing and Boundary Flexibility

• Frequency of processes should guide where to investigate. Some occur frequently, while others are rare.

• Boundaries should be flexible; adjust them if new information suggests a need to expand analysis.

Flowcharting the Process

• Create a flowchart for clarity. Visuals are easier to process than lists.

• Action-Oriented: Use verbs in flowchart boxes.

• Standard Flowchart: Connect boxes with arrows to show flow. Rectangular boxes are typically sufficient.

• Deployment Flowchart: Use swim lanes for clarity of roles.

• Aim for flowchart steps between 4 and 8 to balance detail and simplicity.

Standardized Flowchart Symbols

• Decision: Diamond shape.

• Document: Represents paperwork.

• Delay: Waiting periods in the flow.

• Process Step: Rectangular box for actions.

Primary vs. Administrative Processes

• Primary Process: Main sequence related to the problem.

• Support Processes: Include hiring, training, etc. Digging into these before understanding the primary cause can lead to ineffective searches.

Defining Process and Flowchart Guidelines

• Location, Actor, Time: Each box should represent different locations, people, or similar durations of time in steps.

• Start with the standardized flowchart to find deviations for repetitive issues.

The SIPOC Model

• SIPOC: Supplier, Input, Process, Output, Customer.

• Organizes understanding of processes, identifying where failures occur.

Root Causes of Process Failure

1. Lack of Standards: Without standards, actions are based on personal perceptions.

2. Incorrect Definitions: Definitions may be restrictive or too vague.

3. Non-Followance: People may not adhere to definitions, intentionally or not.

System Failure vs. Individual Error

• Focus on process failures rather than blaming individuals.

• Example: In a fitness club, misspelled names stemmed from a hiring process flaw, not just a clerical error.

Additional Value of Flowcharting

• Helps identify stakeholders for diagnosis.

• Assists in narrowing down potential causes.

• Defines data collection points for process evaluation.

• Use "Drill Down Method" to investigate further by increasing detail in flowcharts.