Pareto Analysis

What it shows#

Bars, ranked descending by contribution, with a cumulative percentage line rising across them. Where the curve crosses 80% tells you how many causes you need to address to remove most of the problem.

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

What it needs#

Three things, and all three are upstream of the chart.

An event scheme capturing the occurrences — stoppages, defects, deviations. See Designing an Event Scheme.

An enumerated attribute to rank by — the reason or category. This must be an Enumeration, not free text.

Event-aggregated measures bringing the events onto the interval grid, counting occurrences or summing durations.

Duration or count?#

Both are valid and they answer different questions. Build both if you can — the disagreement between them is often the insight.

Rank by duration to find where the time goes. This is what an availability improvement 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.

Building it#

1. Create the event scheme with a reason attribute bound to an enumeration.
2. Create an event-aggregated measure for the quantity you want to rank — Active Duration for time, Count (Start) for occurrences.
3. Create a Pareto Chart with the constructor for your interval — typically Daily or Monthly.
4. Drop the event scheme and the measure on it, and set the reason attribute as the ranking dimension.

The interval determines the window being ranked. A daily Pareto shows what dominated today, which is useful in a morning meeting; a monthly one shows what dominates the plant, which is what an improvement programme needs. They frequently disagree, and both are correct.

The unspecified problem#

The most common outcome of a first Pareto chart is that the largest bar is Unspecified or Other.

That is a statement about data capture, not about the plant, and it makes the rest of the chart untrustworthy — the true ranking is hidden inside the unknown bar.

Fixing it is a people problem more than a configuration one, but configuration helps:

• Keep the reason list short enough to choose from. Forty options and operators pick the first one, or nothing.
• Put the form where they already are. A reason entry form on the shift dashboard is completed; one three clicks away is not.
• Use enumerations so entry is one click, not typing.
• Measure the completion rate as a metric in its own right and show it. A visible "reasons captured: 62%" changes behaviour faster than asking.
• Watch Other. If it grows, the list is missing something real.

Hierarchical Pareto#

Where reasons are grouped into an enumeration group — a category, and within it a specific reason — you get two levels of analysis from one data set.

Rank by category for a management view: mechanical, electrical, process, operational, planned. Five or six bars, immediately interpretable.

Rank by reason within a category for the maintenance team: which specific mechanical failure dominates.

This is the shape worth designing for from the start. Retrofitting a hierarchy onto a flat sixty-item reason list means remapping every event already captured. See Event Attributes and Enumerations.

Reading it honestly#

Two cautions that come up in real meetings.

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 a cause that accounts for 6% of the loss.

Ranking is not the same as opportunity. The largest bar may be a cause you cannot economically address — a planned changeover that is already optimised, or a constraint imposed by the product mix. Rank by contribution, then filter by what is actually actionable. A Pareto chart that separates planned from unplanned, using the Planned attribute, is far more useful for this than one that mixes them.

Colour#

Enumeration options carry colours, and those colours flow through to the chart automatically. A palette assigned deliberately at the enumeration — red for unplanned failures, amber for planned interventions, grey for external causes — makes the chart readable at a glance and keeps it consistent with the timeline and table views of the same events.

Setting colours per chart instead means the same reason appears in different colours on different dashboards, which quietly undermines trust in the whole set.

Diagnosing#

See also#

• Analysing Data by Event
• Event Attributes and Enumerations
• How Infohub Charts Work
• Chart Type Catalogue