T17: Pareto Analysis

Step 1 — The chart that changes what people do#

A Pareto ranks categories by contribution and draws a cumulative curve. It answers the only question that matters when deciding what to fix: which few causes account for most of the loss?

The typical result on a bottling line is that two or three causes out of twenty account for two thirds of the downtime. That is a fundamentally different conclusion from "we have twenty downtime reasons", and it is what turns a report into an improvement plan.

Step 2 — Upgrade the reason list to a hierarchy#

Your T07 enumeration is flat — nine reasons in one list. That works up to about ten. Beyond it, people cannot find the right option and pick whichever appears first.

Create two enumerations in the Toolbox:

Stoppage Category — five options, with colours:

Stoppage Reason — the specific causes:

Then create an enumeration group combining them, so selecting Mechanical offers only mechanical reasons.

Step 3 — Wire it into the event scheme#

Change the Stoppage scheme's attributes:

The group constrains valid combinations, so nobody can record Mechanical with No demand.

Planned as a separate attribute matters — see step 8.

Step 4 — Create the ranking measures#

Build both, because they answer different questions:

Rank by duration to find where the time goes — what an availability programme needs.

Rank by count to find what happens most often. Frequent short stoppages may total less time than one long breakdown, but they disrupt flow, cause quality variation, and wear people down.

A cause that is first by count and fifth by duration is a nuisance. One that is first by duration and tenth by count is a reliability problem. They need different responses, and a single chart cannot tell you which you are looking at.

Step 5 — Build the Pareto chart#

Create a Pareto Chart with the Daily constructor — or Monthly for an improvement programme view.

Drop the Stoppage event scheme and Downtime Minutes Daily onto it, and set Reason as the ranking dimension.

The colours come from the enumeration automatically, which is why assigning them deliberately in step 2 pays off — the chart is readable without a legend.

Step 6 — Build the category-level view#

Create a second Pareto ranking by Category instead of Reason.

Five bars, immediately interpretable, suitable for a management review. The reason-level chart drills into whichever category dominates, for the maintenance team.

That is the payoff of the hierarchy: one data set, two audiences, no extra data capture.

Step 7 — Measure whether the data is any good#

Here is the step that separates a Pareto people act on from one they ignore.

Your Reason attribute is manually entered, so it will be blank until somebody fills it in. A chart whose biggest bar is Unspecified is a statement about data capture, not about the plant — and the true ranking is hidden inside that bar.

Build a completion measure:

Count stoppages with a reason recorded, divided by total stoppages, times 100. Then put it on the same dashboard as the Pareto, with a limit at, say, 80%.

Step 8 — Separate planned from unplanned#

Add a third Pareto, filtered to unplanned stoppages only, using the Planned attribute.

This matters more than it sounds. Planned maintenance and cleaning are necessary, scheduled, and already optimised — and on an unfiltered Pareto they frequently appear as the plant's largest "loss".

Presenting that to a management team produces an argument about whether to cut maintenance, which is the opposite of a useful outcome. Ranking only what is actually addressable produces an improvement plan.

Step 9 — Make the entry easy#

Completion rate is a design problem, not a discipline problem. Improve it by configuration:

• Put the form where the people are. A reason-entry form on the shift dashboard gets completed; one three clicks away does not.
• Keep the list short enough to choose from. The hierarchy helps — five categories, then a handful of reasons each.
• Use dropdowns, not typing. That is what the enumeration is for.
• Show them the Pareto next to the form. People fill in a field far more reliably when they can see what it produces.
• Watch Other. If it grows, the list is missing something real. Add it.

Step 10 — Read it honestly#

Two cautions worth stating in the meeting where this is presented.

A long tail is not necessarily a problem. Some processes genuinely have many small unrelated causes. Forcing a Pareto interpretation onto flat data produces an improvement plan targeting something that accounts for 6% of the loss.

Ranking is not opportunity. The largest addressable bar may still be something you cannot economically fix. Rank by contribution, then filter by what is actually actionable.

What you have learned#

A Pareto turns events into an improvement plan — but only if the events are good.

Enumerate categorical attributes. Free text ranks spelling variants, and nothing downstream recovers from it.

Build a two-level hierarchy from the start. Retrofitting means remapping history.

Rank by duration and by count. They answer different questions and their disagreement is informative.

Use Active Duration. Any other duration anchor produces impossible numbers.

Measure the capture rate and set a threshold below which you do not act on the ranking.

Separate planned from unplanned, or maintenance appears as the biggest problem.

Colours belong on the enumeration, so every chart of that attribute agrees.

Try this before moving on#

Add a duration band attribute — micro-stop (under 5 minutes), short (5–30), long (over 30) — calculated from Period.Duration.TotalMinutes.

Then Pareto by band. Many plants discover that micro-stops, individually trivial and never investigated, collectively cost more than the breakdowns everybody talks about. That finding is usually invisible without the band, because each micro-stop is too small to notice.

Next: T18: Equipment Utilisation — states, durations, and utilisation that adds up.

See also#

• T16: Multi-Source Integration
• T18: Equipment Utilisation
• Pareto Analysis
• Event Attributes and Enumerations