OPEXSTUDIO
← All lessons and training aids OPEX learning notes / Frontline problem solving

From broad complaint to a testable problem

Define event and denominator. Follow the visual, practise a decision, then check your thinking.

Fictional teaching examples and AI-generated illustrations. Proposed changes and goals are not achieved results. Use the written instructions and check local conditions before applying a method.

Download this exact reviewed edition ↗

Teaching view 1 of 2

From broad complaint to a testable problem

Method exhibit: Team A, Team B, Before interpreting.
Original OPEX teaching diagram. Follow the steps below, then try the practice question. View full size ↗

A broad complaint rarely gives a team enough direction to test a cause. Define what counts as the problem, over what period and out of how many opportunities. Break comparable observations down by useful factors such as request class, location or shift. Distinguish large counts from high rates. Then observe where the concentrated gap occurs and choose an analysis method suited to its mechanism. A ranking can guide attention but cannot establish causation. Keep reopened work and exceptions within the declared boundary so that an apparent improvement does not simply move the problem out of the measure.

Follow the method

  1. Team A
  2. Team B
  3. Before interpreting

Read the example carefully

Largest count need not mean highest rate.

Pareto ranking does not prove cause.

Precedes 5 Whys or experiment; Measurement definitions carry into control.

Teaching view 2 of 2

Keep volume, error rate and next question together

A comparison record shows A at 2%, B at 10% and the weighted combined rate at 2.73%, then calls for a case-type breakdown without assigning a cause.
Original OPEX teaching diagram. Follow the steps below, then try the practice question. View full size ↗

Fictional request-processing review: team A reports 20 errors in 1,000 cases; team B reports 10 in 100. Manager Elif initially assigns all improvement attention to A because its error count is larger. The shared error definition and case mix still need checking.

Follow the method

  1. A error-containing cases
  2. B error-containing cases
  3. Combined
  4. Next breakdown

Read the example carefully

Do not rank team capability from the pooled rates. Obtain comparable within-type counts and examine the work conditions.

Case mix can change aggregate rates even when a named team is not the cause.

Apply the method

The smaller error count hides the larger rate

Convert counts into comparable rates, define a focused problem and choose the next breakdown without treating a difference as proof of cause.

Fictional request-processing review: team A reports 20 errors in 1,000 cases; team B reports 10 in 100. Manager Elif initially assigns all improvement attention to A because its error count is larger. The shared error definition and case mix still need checking.

Role: Process analyst with both team representatives.

Normal condition

Counts and denominators refer to the same period and definition; comparisons state their scope.

The gap

Raw counts suggest one priority while rates suggest another.

  • Treat each count as cases with at least one defined error for this exercise, not unrestricted defects per case.
  • Different case mix, detection or periods can invalidate a direct team comparison.
Supplied case inputs
TeamCases with errorTotal cases
A201,000
B10100
PeriodSame fictional weekDefinition pending confirmation
Case mixRoutine and exception requestsBreakdown not yet supplied
  1. Define what is being counted

    Elif confirms that numerator and denominator refer to completed cases in the same week and asks whether both teams apply the same error rule.

    Why: Twenty defects and ten defective cases are not comparable numerators.

    Evidence: A written definition and period are attached before interpreting.

  2. Normalize the comparison

    Calculate A as 20 / 1,000 × 100 = 2% and B as 10 / 100 × 100 = 10%. Keep counts alongside rates.

    Why: The denominator exposes different opportunity volume, while the counts show the size of the observed burden.

    Evidence: Rate bars use one percent scale and retain both sample sizes.

  3. Break down toward the actual work

    Request routine/exception case counts and error counts for each team, then examine where and when the specific error occurs. Avoid collecting every available category without a question.

    Why: A useful stratum narrows the gap or tests a comparability concern; it does not simply make another chart.

    Evidence: The next collection plan names case type, event definition and handoff point.

  4. Write a focused, provisional problem

    State that B has 10 error-containing cases among 100 in the supplied week, with case mix and detection comparability unresolved. Assign the next observation before choosing a cause.

    Why: A higher observed rate does not establish worse effort or a causal mechanism.

    Evidence: Problem statement includes denominator, time, uncertainty and next owner.

Completed denominator-aware comparison
Team / measureCalculationInterpretation
A error-containing cases20 / 1,000 = 2%Higher count; lower observed rate
B error-containing cases10 / 100 = 10%Higher observed rate; smaller volume
Combined30 / 1,100 = 2.73%Weighted total, not mean of rates
Next breakdownCase type and occurrence pointNo cause assigned

The apparent team effect is mixed with case type

Further fictional records show B handles mainly exceptions and A mainly routine cases, but type-specific denominators have not yet been reconciled.

Do not rank team capability from the pooled rates. Obtain comparable within-type counts and examine the work conditions.

Case mix can change aggregate rates even when a named team is not the cause.

Retain original totals and reconcile each stratum back to them before interpretation.

Same percentage, different burden

New fictional comparison: team C has 12 error-containing cases among 240 and D has 8 among 160 in one week under a shared definition.

Changed practice inputs
TeamError casesAll cases
C12240
D8160

Your task

  1. Calculate each rate and the combined rate.
  2. Explain whether the counts alone justify claiming C performs worse.
  3. Specify one useful next breakdown and its required fields.

Prepare your worksheet

  • Numerator definition / period
  • Rate calculation with denominator
  • Comparison and limitation
  • Next stratum / fields
  • Focused observation owner
Reveal the answer and reasoning

C is 5% and D is 5%; together 20 / 400 = 5%. C has more errors because it also has more cases in this sample.

Equal observed rates do not prove identical processes or future performance. Case mix, detection and variability remain relevant.

A defensible next step might separate request type and occurrence handoff, with errors and all cases counted consistently in each group.

Worked answer record
MeasureCalculation / interpretation
C12 / 240 = 5%
D8 / 160 = 5%
Combined20 / 400 = 5%
ConclusionNo worse-rate claim from raw counts

Check these interpretations

  • Do not average 2% and 10% to obtain the combined rate when volumes differ.
  • A stratum associated with an error is not automatically its cause.

Check your work

  • Use matching numerator/denominator definitions.
  • Reconcile totals and rates.
  • Choose a breakdown that answers a specific question.

Run a practice session

Materials

  • Count/denominator cards
  • Blank comparison sheet
  • Calculator
  1. Show counts before denominators · 4 minutes

    What changes when volume is revealed?

  2. Calculate and reconcile · 7 minutes

    Why is the combined rate not 6%?

  3. Practice equal-rate case · 8 minutes

    What claim can you support?

  4. Choose next breakdown · 5 minutes

    Which question will the new category answer?

Debrief

  • Check definitions before correcting arithmetic.
  • Ask what would make a comparison unfair.

Calculate the combined rate from summed counts, then write one cautious problem statement.

Transfer into the work

Owner: Process analyst and representatives who apply the event definition

Record: Stratified counts/rates with data definitions

Review: After collection and before causal analysis or prioritization

Evidence: Reconciled denominators, comparable scope and point-of-occurrence observations

Repair definitions or collect missing denominators rather than rank people from incomplete counts.

Build on reliable methods

Sources and further reading

  • LEI LeanTech: Prompting for Problem Solving ↗

    Analysis method must fit problem; model must not default blindly to 5 Whys

    Method reference; original OPEX scenario and diagram are synthetic teaching content, not source case results.
  • ASQ: Stratification ↗

    Plan source/category fields before collection and examine relevant groups separately to reveal patterns hidden by aggregation.

    Method principle only; OPEX team counts and calculations are original fictional examples. No source diagram or template is reproduced.
Free learning resources

Take the lesson into your team.

Read the lessons online or use these PDFs to prepare, practise and review with your team. No sign-in needed.

Facilitators and team leads

Facilitator guide

Case objectives, demonstration plans, debriefs, common mistakes and application checks across all 81 workplace cases and method lessons.

Download Facilitator guide PDF · 166 pages · 65.1 MB
Learners and improvement teams

Learner workbook

Printable case worksheets, blank observation records and five calculation exercises; answers are separate.

Download Learner workbook PDF · 169 pages · 10.7 MB
Learners after practice and facilitators

Answer key and coaching notes

Reasoned sample responses, worked calculations and coaching guidance; fictional examples are clearly labelled.

Download Answer key and coaching notes PDF · 105 pages · 8.5 MB
Practitioners and facilitators seeking detailed worked methods

Method and application reference

The native method mechanisms and worked applications for all 68 detailed lessons, in a separate bookmarked portrait reference.

Download Method and application reference PDF · 141 pages · 10.2 MB
Self-study learners and workshop groups

Illustrated systems atlas

Five illustrated system chapters: 15 Flare concept maps and 26 original workplace teaching cards, with links to all 81 supporting cases and method lessons.

Download Illustrated systems atlas PDF · 69 pages · 55.8 MB
Connect the methods

Use the next tool for the next question.

  • Operational definition
  • Comparable populations
Explore all chapters and detailed lessons →