Process Improvement and Operational Excellence

Chapter 5
Root-Cause Analysis and Structured Problem Solving

Post Graduate Program in Total Quality Management
Process Improvement and Operational Excellence   •   Post Graduate

5. Root-Cause Analysis and Structured Problem Solving

Introduction: From Symptoms to System Understanding

Operational excellence depends not merely on detecting problems but on understanding why they occur and preventing their recurrence. A defective product, delayed service, customer complaint, equipment failure, or safety incident is usually an observable symptom of a less visible process condition. If an organization responds only by correcting the immediate symptom, the problem may disappear temporarily and then return. Root-cause analysis provides a disciplined way to move from observation to explanation, while structured problem solving converts that explanation into verified corrective and preventive action.

Root-cause analysis is not a single tool. It is a family of methods used to define a problem, establish facts, identify possible causes, test causal explanations, implement solutions, and confirm sustained improvement. The methods discussed in this chapter—including PDCA, A3, 8D, DMAIC, Pareto analysis, cause-and-effect diagrams, 5 Whys, hypothesis testing, and causal reasoning—are complementary rather than interchangeable. Their value depends on selecting an approach suited to the problem’s complexity, urgency, risk, and available evidence.

A central principle is that a cause should not be accepted merely because it appears plausible. A credible root cause must be linked logically and empirically to the problem. It should explain the pattern of occurrence, be supported by data or direct observation, and identify a point at which intervention can prevent recurrence. This distinction separates disciplined problem solving from opinion, blame, and trial-and-error management.

Learning Objectives

After completing this chapter, the reader should be able to:

1. Distinguish symptoms, contributing causes, root causes, and escape points.

2. Select and apply PDCA, A3, 8D, and DMAIC according to problem context.

3. Use Pareto analysis, cause-and-effect diagrams, 5 Whys, process mapping, and stratification effectively.

4. Formulate testable causal hypotheses and use evidence to validate or reject them.

5. Design corrective, preventive, and containment actions that address the system rather than merely the individual error.

6. Evaluate the effectiveness and sustainability of implemented solutions.

7. Recognize analytical, managerial, ethical, and organizational risks in root-cause investigations.

The Logic of Root-Cause Analysis

A problem is a gap between actual and expected performance. The gap must be expressed in observable terms. “Poor quality” is too broad for analysis; “the first-pass yield of the final inspection process fell from 96 percent to 88 percent during the last six weeks” is more useful. A well-defined problem identifies what happened, where and when it occurred, its magnitude, and its impact.

Several levels of causation should be distinguished. The symptom is the visible undesirable effect. A direct cause is an immediate condition associated with the event, such as an incorrect machine setting. A contributing cause increases the likelihood or severity of the event, such as inadequate training or variation in material hardness. A root cause is a fundamental condition whose removal or control prevents recurrence of the problem within the relevant system. An escape point is the control failure that allowed the problem to reach the customer or next process. A single event may therefore have more than one important cause.

The expression “the root cause” can be misleading. Complex failures often arise from interacting technical, human, organizational, and environmental conditions. A useful investigation seeks a sufficient set of causes rather than forcing every failure into one explanation. For example, a medication error may involve ambiguous labeling, workload pressure, inadequate system alerts, and a weak verification process. Blaming the final operator ignores the conditions that made the error likely.

Causal reasoning requires a distinction between correlation and causation. Two variables may move together because one causes the other, because both are influenced by a third factor, or because their apparent relationship is accidental. A cause-and-effect relationship becomes more credible when the proposed cause precedes the effect, a mechanism is plausible, the relationship is repeated, alternative explanations are considered, and changing the cause changes the outcome.

Choosing a Structured Problem-Solving Framework

PDCA: A Learning Cycle for Improvement

The Plan–Do–Check–Act cycle is a general improvement logic. In the planning stage, the team defines the problem, studies the current condition, identifies possible causes, and designs an intervention. In “Do,” the intervention is tested, preferably on a controlled or limited scale. “Check” compares results with the objective and examines unintended effects. “Act” means standardizing a successful change or revising the plan and beginning another cycle.

PDCA is especially useful for incremental improvement, daily management, and situations in which learning must occur through repeated experimentation. It should not be treated as a casual sequence of activities. The planning stage must be evidence-based, and the checking stage must use meaningful measures rather than subjective impressions.

A3: Concise, Visual, and Evidence-Based Reasoning

A3 problem solving is named after the internationally standardized paper size traditionally used to communicate the analysis. Its purpose is not merely to fit information on one page but to make thinking visible. A typical A3 includes the background, current condition, problem statement, target condition, analysis of causes, countermeasures, implementation plan, and follow-up results.

A3 is valuable because it encourages management dialogue and prevents teams from jumping directly to solutions. The document should evolve as knowledge improves; it is not a form to be completed after decisions have already been made. Strong A3 reports show the relationship between facts, hypotheses, actions, and results.

8D: Cross-Functional Response to Significant Nonconformance

The Eight Disciplines method is commonly used for customer complaints, serious defects, and recurring failures requiring coordinated action. Its stages are generally described as:

  • D1: establish a competent team;
  • D2: describe the problem precisely;
  • D3: implement and verify interim containment;
  • D4: identify and verify root and escape causes;
  • D5: select and verify permanent corrective actions;
  • D6: implement and validate those actions;
  • D7: prevent recurrence through system changes;
  • D8: recognize the team and close the problem formally.

The distinction between containment and corrective action is fundamental. Sorting defective products, adding inspection, or temporarily stopping shipment may protect the customer, but these actions do not necessarily remove the cause. A complete 8D process addresses both immediate protection and long-term prevention.

DMAIC: Data-Intensive Improvement

DMAIC—Define, Measure, Analyze, Improve, and Control—is widely associated with Six Sigma. In Define, the project purpose, customers, scope, and critical requirements are clarified. Measure establishes operational definitions, baseline performance, measurement-system adequacy, and process capability where appropriate. Analyze identifies patterns and tests potential causes. Improve develops and evaluates solutions. Control sustains performance using standardized work, monitoring, response plans, and ownership.

DMAIC is particularly appropriate when the problem is chronic, performance is measurable, and variation must be reduced. It requires more analytical discipline than a rapid PDCA cycle. However, sophisticated statistical analysis cannot compensate for an ambiguous problem definition or unreliable data.

These frameworks may be combined. An organization might use 8D for customer communication and containment, DMAIC for the analytical investigation, and PDCA for subsequent implementation and learning. The framework should serve the problem, not become an administrative ritual.

Establishing a Reliable Problem Definition

Investigation quality is often determined before the first analytical tool is used. A useful problem statement contains a measurable defect or performance gap, a defined population, a location or process step, a time period, and the business or customer consequence. The “is/is not” technique is helpful: What products, shifts, sites, machines, or transactions are affected, and which comparable ones are not? Differences between “is” and “is not” conditions can reveal useful clues.

Teams should distinguish facts from assumptions. “The seal failed at 2.4 bar during testing” is a fact if supported by a valid test. “The operator did not tighten it correctly” is a hypothesis unless directly verified. Operational definitions are equally important. Terms such as “late,” “defective,” “rework,” or “customer complaint” must be defined consistently before data are collected.

A process map or value-stream representation can identify where the defect is created, detected, and passed onward. The point of creation may differ from the point of detection. This distinction is essential: the inspection station that discovers a defect is not necessarily the process step that generated it.

Prioritizing the Investigation with Pareto Analysis

Pareto analysis helps teams focus on the categories contributing most to a defined problem. A Pareto chart orders categories from largest to smallest and often displays a cumulative percentage. It is based on prioritization, not on a universal requirement that exactly 80 percent of effects must arise from 20 percent of causes.

The quality of a Pareto analysis depends on classification. Categories must be mutually meaningful, sufficiently specific, and based on comparable units. A chart of complaint counts may identify frequency, whereas a chart weighted by financial loss, patient risk, or downtime may produce a different priority. Teams should also stratify data by product, location, shift, supplier, failure mode, or time period because aggregation can hide important patterns.

Pareto analysis identifies where to investigate; it does not prove why the problem occurs. A high-frequency category may be easy to count but less important than a rare, severe safety failure. Prioritization should therefore consider frequency, severity, detectability, regulatory exposure, and strategic importance.

Generating and Testing Causes

Cause-and-Effect Diagrams

The cause-and-effect, or fishbone, diagram organizes possible causes around an effect. Manufacturing teams often use categories such as man or people, machine, method, material, measurement, and environment. Service and administrative processes may require categories such as policy, information, technology, workload, supplier, and customer interface.

The diagram is a method for disciplined idea generation, not evidence of causation. A productive session begins with a precise effect and uses observed facts to refine broad categories. Causes should be stated concretely—for example, “torque tool calibration overdue by 14 months”—rather than vaguely as “people” or “poor quality.” Each proposed cause must later be tested.

The 5 Whys

The 5 Whys technique repeatedly asks why an event occurred in order to move from an immediate condition toward systemic causes. Five is not a fixed number; the questioning stops when the team reaches a controllable condition supported by evidence and sufficiently deep for prevention. Different branches may emerge, so the method is often more accurately viewed as a causal tree than a single vertical chain.

A weak sequence is: “The part was wrong because the operator was careless; the operator was careless because of poor attitude.” This explanation is judgmental, difficult to verify, and unlikely to guide system improvement. A stronger sequence may identify unclear work instructions, an inaccessible specification, inadequate error-proofing, and an approval process that failed to detect the weakness.

Hypothesis Testing and Data Analysis

A causal hypothesis states a proposed relationship in testable form: “The increased seal failure rate is associated with curing temperature below the specified range, after accounting for product type.” Data should be collected using a sampling plan and measurement system appropriate to the question. If the measurement process is unstable or biased, conclusions about the process may be invalid.

Depending on the situation, teams may use stratified comparisons, run charts, control charts, scatter plots, regression, analysis of variance, designed experiments, or proportion and mean tests. Statistical significance should not be confused with practical significance. A very small effect may be statistically detectable in a large sample but operationally unimportant; a consequential effect may require better data to detect.

Hypothesis testing typically begins with a null hypothesis representing no difference or no association. The p-value indicates how surprising the observed data would be if the null hypothesis were true under the stated assumptions; it does not represent the probability that the hypothesis is true. Confidence intervals provide information about the range and precision of an estimated effect. Managers should also consider effect size, cost, risk, and process knowledge.

Controlled experiments provide stronger causal evidence than simple observation when they are feasible and ethical. Randomization helps balance unknown factors, while blocking or stratification controls known sources of variation. In operational settings, designed experiments may evaluate factors such as temperature, pressure, speed, material grade, or software configuration. Where experimentation is not possible, teams should use temporal evidence, natural comparisons, mechanism analysis, and multiple data sources while acknowledging residual uncertainty.

From Validated Causes to Corrective and Preventive Action

A corrective action removes or controls the verified cause of an existing problem. Preventive action changes the system so that a similar problem does not arise elsewhere or in the future. Containment protects stakeholders while the investigation continues. Detection controls, such as inspection, may reduce escape but are generally weaker than prevention controls that make the error impossible or less likely.

Solutions should be evaluated against several criteria: effectiveness, risk reduction, feasibility, cost, speed, impact on other processes, and sustainability. The hierarchy of controls is useful: eliminate the failure opportunity where possible; substitute safer or more reliable conditions; introduce engineering controls and error-proofing; improve procedures and training; and use warnings or personal vigilance only as less reliable safeguards.

A solution is not validated merely because the defect rate falls immediately after implementation. The team should define an outcome measure, a time horizon, process owners, and decision rules. It should verify that improvement is not caused by reduced production, selective reporting, or temporary attention. Control charts, audits, layered process reviews, capability measures, complaint monitoring, and recurrence checks may all be appropriate.

Standardization is part of problem solving. Changes may require revised specifications, software controls, training, supplier requirements, maintenance plans, risk analyses, control plans, and document control. Lessons should be transferred to similar products and processes. A local fix that leaves a common systemic weakness unchanged is incomplete.

Illustrative Case: Repeated Medication-Labeling Errors

Background

The following is an illustrative case designed to demonstrate structured analysis in a healthcare service. A hospital pharmacy reported an increase in outpatient medication-labeling errors. No patient harm had occurred, but three patients received labels with incorrect dosage instructions over a two-month period.

Situation and Problem Definition

A preliminary statement—“pharmacy staff are making more mistakes”—was rejected as insufficiently precise. The team defined the problem as follows: during the previous eight weeks, the rate of dosage-label discrepancies increased from 0.4 to 1.8 per 1,000 prescriptions, concentrated in prescriptions requiring manual modification of standard instructions. The errors were detected by pharmacists before or shortly after dispensing.

Analysis

An initial Pareto analysis showed that 72 percent of discrepancies involved pediatric liquid medicines. Stratification revealed that the problem was concentrated on evening shifts and in prescriptions requiring conversion between milligrams and milliliters. A process map showed that information was transcribed from the electronic prescription to a label template and then manually edited.

The team developed a fishbone diagram. Possible causes included confusing concentration formats, interruptions, inadequate template design, unfamiliarity with a recently introduced product, and insufficient independent verification. Through record review and direct observation, the team found that two concentrations of the same medicine were stored next to each other and that the electronic system displayed milligrams while the label template required milliliters. The conversion field did not automatically flag implausible values. Evening workload was higher, and the second-person check was inconsistently applied during peak periods.

The team used 5 Whys on one verified error. The wrong dosage appeared because the label was manually edited with an incorrect conversion. The conversion was incorrect because the system did not automatically calculate the volume. Manual calculation occurred because the product concentration was not integrated into the dispensing workflow. The concentration was not integrated because the new product had been added without completing the standard configuration review. The configuration review was incomplete because responsibility for new-product master-data validation was undefined.

The analysis therefore identified more than operator error. The causal system included poor interface design, weak master-data governance, storage similarity, workload pressure, and an unreliable verification control.

Approach and Solution

Containment included separating the two concentrations, requiring pharmacist verification for all pediatric liquid labels, and reviewing recent prescriptions. For permanent corrective action, the hospital configured automated dose-to-volume calculation, introduced a hard stop when concentration data were missing, and redesigned the label to display both dose and volume clearly. The pharmacy also established a documented master-data approval process for new products.

A short pilot was conducted on one evening shift. The team monitored discrepancies per 1,000 prescriptions, verification compliance, dispensing time, and staff-reported usability. After the pilot showed no discrepancy and only a small increase in average processing time, the changes were extended to all shifts. A monthly audit and a control chart were established, with a defined escalation rule if the rate exceeded the baseline threshold.

Outcome and Learning Points

The case demonstrates why containment, corrective action, and preventive action must be separated. Increased checking could have reduced the immediate risk, but it would have preserved dependence on human vigilance. The more durable solution changed the information system, product governance, physical arrangement, and verification process. It also illustrates the value of stratification: the overall error count alone would not have revealed the connection with pediatric liquids, evening workload, and manual conversion.

Common Failure Modes in Root-Cause Investigations

One frequent error is beginning with a preferred solution. If a manager believes training is needed, the investigation may be shaped to confirm that belief. Another is confusing proximity with causality: the person nearest the failure is blamed even when the system created the conditions. Teams also commonly use “human error” as a final cause rather than asking why the system depended on error-free performance.

Other weaknesses include poor problem definitions, unvalidated data, mixing different failure modes, ignoring problems that did not escape to the customer, and treating brainstorming outputs as proven causes. A further risk is stopping at the first plausible explanation. Investigators should ask what evidence would disconfirm a proposed cause and actively seek contrary cases.

Statistical misuse is also common. Small samples may support only cautious conclusions; p-values may be overinterpreted; multiple comparisons may produce false positives; and averages may conceal subgroups. A process can show an acceptable average while remaining unstable. Conversely, a statistically detectable change may have no meaningful operational benefit.

Corrective actions can create new risks. An additional inspection may increase queue time, a software alert may generate alert fatigue, and a change in one process may transfer defects to another. Risk assessment, stakeholder consultation, pilot testing, and post-implementation review are therefore essential.

Governance, Ethics, and Professional Responsibility

Root-cause investigations affect employees, customers, patients, suppliers, and regulators. Investigators must protect confidentiality, preserve records, and distinguish learning from disciplinary inquiry. When safety or legal compliance is involved, evidence must be documented accurately and reported through appropriate channels. Altering data, suppressing unfavorable findings, or presenting an unverified explanation as fact violates professional responsibility.

A just and responsible approach recognizes accountability without assuming that blame produces reliability. Deliberate misconduct and reckless disregard may require management action, but ordinary human error should prompt examination of design, workload, training, supervision, and controls. Investigations should also consider equity: language, accessibility, staffing patterns, and organizational power may influence who is exposed to failure and who is blamed for it.

Digital Tools, Analytics, and Emerging Practice

Digital quality systems increasingly connect nonconformance records, process data, maintenance information, customer complaints, and corrective-action workflows. Automated dashboards can support Pareto analysis, trend detection, and escalation. Process mining can reconstruct the actual sequence of digital transactions and reveal deviations from intended workflows. Sensor data and anomaly detection can identify changing conditions before a defect becomes visible.

Artificial intelligence can assist with clustering complaints, extracting themes from narratives, identifying unusual combinations of variables, and proposing candidate relationships. However, AI-generated patterns are hypotheses, not validated causes. Bias in historical records, incomplete context, data leakage, and spurious correlation can mislead investigators. Human experts must examine mechanisms, verify evidence, protect sensitive information, and retain accountability for decisions.

A developing practice is the integration of causal models with operational data. Rather than asking only which variables predict failure, teams increasingly ask what would happen if a variable were changed. This supports intervention design, but causal conclusions still require appropriate assumptions, experimental evidence, or carefully justified quasi-experimental methods.

Best-Practice Principles

Effective root-cause analysis is characterized by the following principles:

  • define the problem in measurable, observable terms;
  • protect customers and stakeholders through immediate containment when necessary;
  • separate facts, hypotheses, causes, and solutions;
  • involve people who understand the process, including those who perform the work;
  • stratify data before drawing conclusions;
  • test causes rather than accepting plausible stories;
  • address creation points and escape points;
  • prefer prevention and error-proofing over reliance on inspection and memory;
  • evaluate unintended consequences and practical significance;
  • assign ownership, deadlines, and evidence of effectiveness;
  • standardize successful changes and share learning across similar processes.

Chapter Summary

Root-cause analysis is a disciplined process for explaining performance gaps and preventing recurrence. It begins with a precise problem definition and distinguishes symptoms, direct causes, contributing conditions, root causes, and escape points. PDCA provides a flexible improvement cycle; A3 makes reasoning visible; 8D supports cross-functional response to significant failures; and DMAIC offers a data-intensive structure for reducing chronic variation. Pareto analysis prioritizes investigation, while cause-and-effect diagrams and 5 Whys generate structured causal hypotheses. Hypothesis testing, process observation, stratification, and experimental or quasi-experimental reasoning help validate those hypotheses.

Effective action separates containment from corrective and preventive action. Durable solutions change processes, systems, controls, or designs rather than relying solely on training or inspection. Implementation must be followed by effectiveness verification, standardization, governance, and learning transfer. Ethical investigation requires evidence integrity, confidentiality, fair treatment, and appropriate accountability. Digital systems, process mining, analytics, and AI can expand analytical capability, but they do not replace causal reasoning or professional judgment.

Key Terms

Root-cause analysis: A systematic method for identifying and validating fundamental conditions responsible for an undesirable outcome.

Symptom: The visible or measurable manifestation of a problem.

Direct cause: The immediate condition or event associated with the occurrence of a problem.

Contributing cause: A condition that increases the likelihood or severity of a failure.

Escape point: A failed control that allows a defect or problem to pass to a later process or customer.

Containment: Temporary action taken to protect stakeholders while the cause is investigated.

Corrective action: Action that removes or controls the verified cause of an existing problem.

Preventive action: Action that reduces the likelihood of a similar problem occurring elsewhere or later.

PDCA: Plan–Do–Check–Act cycle used for iterative learning and improvement.

A3: A concise, visual problem-solving report structured around facts, causes, actions, and follow-up.

8D: Eight Disciplines method for organized, cross-functional response to significant problems.

DMAIC: Define, Measure, Analyze, Improve, and Control methodology for data-based improvement.

Pareto analysis: Prioritization method that ranks categories by their contribution to a defined effect.

Cause-and-effect diagram: Visual framework for organizing possible causes of an identified effect.

5 Whys: Iterative questioning technique used to explore deeper causal conditions.

Hypothesis: A testable proposition about a possible relationship between variables or conditions.

Operational definition: A precise specification of how a variable, defect, or performance measure is identified and measured.

Error-proofing: Designing a process so that errors are prevented or immediately detected.

Process capability: The extent to which a stable process can meet specified performance requirements.

Causal reasoning: Logical and evidence-based evaluation of whether changing a condition produces a change in an outcome.

Review Questions

Short Answer Questions

1. Distinguish between a symptom, a root cause, and an escape point.

2. What is the purpose of containment in an 8D investigation?

3. Why does a Pareto chart identify priorities but not prove causation?

4. Explain why five is not a mandatory number in the 5 Whys method.

5. What is the difference between statistical significance and practical significance?

Long Answer Questions

1. Compare PDCA, A3, 8D, and DMAIC in terms of purpose, structure, and appropriate application.

2. Explain how a team can move from a fishbone diagram to validated causal conclusions.

3. Discuss the importance of operational definitions, measurement-system reliability, and stratification in root-cause analysis.

4. Explain how corrective, preventive, and containment actions differ, using an appropriate organizational example.

5. Critically examine the limitations of blaming human error as the final explanation for process failure.

Analytical / Application Questions

1. A factory observes a rise in late deliveries, but the monthly average hides major differences among customers and routes. Design a structured investigation using problem definition, stratification, Pareto analysis, causal hypotheses, and verification measures.

2. A software release causes intermittent transaction failures only during peak demand. Propose an A3 or DMAIC-based investigation, including the data required to distinguish capacity, coding, network, and user-behavior causes.

3. A hospital introduces an additional inspection after a recurring labeling error. Evaluate whether this is an adequate corrective action and propose a stronger prevention-oriented response using the concepts of creation point, escape point, and error-proofing.

22. Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes containment from corrective action?

A. Containment removes the root cause, whereas corrective action measures the symptom.

B. Containment protects stakeholders temporarily, whereas corrective action addresses the verified cause.

C. Containment is used only for safety incidents, whereas corrective action is used only for customer complaints.

D. Containment and corrective action are interchangeable terms.

Correct Answer: B. Containment protects stakeholders temporarily, whereas corrective action addresses the verified cause.

Question 2

A Pareto chart shows that one defect category accounts for 65 percent of recorded defects. What is the most appropriate conclusion?

A. The category is proven to be the root cause.

B. The category should be prioritized for further investigation.

C. All other categories can be ignored permanently.

D. The process must have a normal distribution.

Correct Answer: B. The category should be prioritized for further investigation.

Question 3

Which problem statement is most suitable for structured analysis?

A. The production team has a quality attitude problem.

B. The process is unreliable.

C. First-pass yield declined from 96 percent to 88 percent on Product X during the last six weeks.

D. Operators need more training.

Correct Answer: C. First-pass yield declined from 96 percent to 88 percent on Product X during the last six weeks.

Question 4

In the 5 Whys method, why should questioning not automatically stop after the fifth question?

A. The method requires at least ten questions.

B. Five is a guideline; questioning should continue until a supported, controllable systemic cause is reached.

C. The fifth answer is always the symptom.

D. The method is valid only when every answer concerns equipment.

Correct Answer: B. Five is a guideline; questioning should continue until a supported, controllable systemic cause is reached.

Question 5

Which action is most clearly an example of error-proofing?

A. Reminding employees to be more careful

B. Increasing end-of-line inspection

C. Installing a connector that can be assembled in only the correct orientation

D. Sending an email about the defect

Correct Answer: C. Installing a connector that can be assembled in only the correct orientation

Question 6

A statistically significant difference is found between two process conditions, but the average improvement is too small to affect customers or cost. This illustrates the difference between:

A. Containment and prevention

B. Correlation and measurement

C. Statistical significance and practical significance

D. A symptom and an escape point

Correct Answer: C. Statistical significance and practical significance

Question 7

Which framework is particularly associated with a formal, cross-functional response to serious customer complaints and includes interim containment?

A. 8D

B. 5S

C. SIPOC

D. Value-stream mapping

Correct Answer: A. 8D

Question 8

A team finds that defects occur mainly on one shift and with one material supplier, although the overall defect average appears stable. Which analytical practice revealed this pattern?

A. Stratification

B. Randomization failure

C. Document control

D. Benchmarking

Correct Answer: A. Stratification

Question 9

Why should an AI-generated pattern in quality data be treated as a hypothesis rather than a confirmed cause?

A. AI cannot process numerical data.

B. Patterns may reflect bias, incomplete context, or spurious correlation and require validation.

C. AI is useful only for document formatting.

D. Causal relationships never involve data.

Correct Answer: B. Patterns may reflect bias, incomplete context, or spurious correlation and require validation.

Question 10

In the illustrative medication-labeling case, which solution most directly addressed a systemic cause?

A. Blaming the pharmacist who made the error

B. Requiring staff to work faster

C. Automating dose-to-volume calculation and strengthening product master-data governance

D. Removing all pediatric medicines from the pharmacy

Correct Answer: C. Automating dose-to-volume calculation and strengthening product master-data governance

Process Improvement and Operational Excellence
Chapter 5 of 14