KPI Trees.

What a KPI tree is

A KPI tree, sometimes called a driver tree, breaks one business result down into the measurable drivers that cause it, level by level, until it reaches numbers a shift can influence before lunch. At the top sits a result the business would recognize: on-time delivery, cost per unit, customer escapes. Beneath it, two to four drivers that explain most of that result's movement. Beneath those, the shop-floor metrics that move each driver: changeover minutes, downtime hours, first pass yield, stockouts.

The word doing the work is cause. A KPI tree is not a reporting hierarchy showing who sends which number to whom. It is a causal argument written as a diagram: improve these leaf metrics and the driver above must move; move the drivers and the business result must follow. Every connecting line is a claim about how the plant actually behaves, and every claim can be wrong. That is not a flaw, it is the function. The tree makes the plant's theory of performance explicit, so the theory can be tested against data and corrected, instead of living as private assumptions in a dozen heads.

Two disciplines separate a working tree from wall decoration. First, every KPI on the tree carries one owner and one decision it informs. A number nobody owns is trivia, and a number that never changes a decision is reporting for its own sake. Second, every branch must be able to explain its causal link in one sentence. If it cannot, prune it, no matter how available the data is or how long the metric has lived in the monthly pack.

When trees go wrong

Most failed KPI trees fail before the first review, in one of three ways:

• The finance mirror. The tree reproduces the P&L or the org chart: plant cost splits into department costs, which split into cost centers. Every line is an arithmetic identity and none is a causal claim, so the tree can never tell anyone what to do differently. Decomposing a number is not the same as explaining it.
• The 60-node forest. Every metric the plant already collects gets a branch so nobody feels left out. The tree stops being an argument and becomes an inventory; reviews visit twelve branches and act on none of them.
• Metrics without owners. The tree is drawn, admired and laminated, but no node has a name attached. Six weeks later nobody can say who was supposed to react when supermarket stockouts doubled.

All three have the same root: the tree was built as a reporting exercise instead of an argument. The build method below is designed to force the argument.

How to build one

Build the tree in one half-day workshop, not in a spreadsheet over three weeks. The room needs the plant manager, the value stream or production manager, the supervisors who will own the leaves, a controller to pin down the result's definition, and a facilitator. The raw material is the diagnosis the plant already has: the value stream map points at the flow drivers, and the KPI baseline says which numbers can currently be trusted. The workshop runs six steps, in order:

1. 1 Fix the result and its definition. One result per tree. Write the exact formula on the wall: whose on-time delivery, measured against which date, requested or confirmed. Half of all KPI arguments are definition arguments in disguise.
2. 2 Ask what would have to be true. For the result to hit its target, what must be true operationally? Collect candidates, then keep the two to four drivers that explain most of the movement, and say the mechanism out loud for each: we believe adherence drives OTD because most misses start as schedule breaks.
3. 3 Repeat one level down. For each driver, name the shop-floor numbers that move it and that a shift can influence within days. If a candidate leaf can only be moved by a capital project, it is an initiative, not a leaf.
4. 4 Test the links. Where history exists, plot leaf against branch over the past year and check that they move together. Where it does not, mark the link as a hypothesis, in writing, on the tree. A marked guess is honest; an unmarked one becomes folklore.
5. 5 Attach owner, rhythm and decision. Every node gets one named owner, the review where it is read, and the decision it informs. If the room cannot name a decision a metric informs, the metric comes off.
6. 6 Set targets down, check arithmetic up. Deploy the result target down the branches, then check upward: do the leaf targets plausibly deliver the branch target? If 18-minute changeovers and 10 downtime hours still do not add up to 96 percent adherence, the tree is missing a driver, and it is better to find out now.

Tree-building rules

Six rules keep the workshop, and every later revision, honest:

• Start from one business result. One tree per result, and no more than three trees per plant. A tree for everything is a tree for nothing.
• Build each level by asking what would have to be true for the level above to move, and name the mechanism. Correlation folklore does not survive contact with a bad quarter.
• Three levels is enough for a plant: result, drivers, shop-floor leaves. A fourth level usually means you are drawing the org chart again.
• Every leaf must be ownable at shift level: readable at the process without a report, and movable by the people who see it within days, not quarters.
• Leading indicators at the bottom, lagging at the top. The root confirms what the leaves predicted; if the leaves cannot predict, they are the wrong leaves.
• Prune yearly. A branch that cannot explain its causal link, or a node that informed no decision all year, comes off. The tree earns its size.

Running with the tree

A tree nobody reads is a diagram. What makes it a management instrument is giving every level a home in the meeting cadence. The leaves live on the tier 1 and tier 2 boards and get read every shift or every day; changeover minutes, downtime hours and first pass yield are exactly what the SQDIP letters track. The drivers belong to the weekly value stream review. The root belongs to the monthly management review. Same tree, same numbers, three altitudes. When the monthly review asks why OTD slipped, the answer is two levels down on a board that was discussed on Tuesday, not in a fresh analysis commissioned for the meeting.

The most useful moments in the tree's life are the ones where it turns out to be wrong. Machining cuts changeovers from 47 to 18 minutes and lead time barely moves: that is not a failed project, that is the tree learning. In this case the missing middle was batch size. The changeover time fell, but planning kept releasing three-day batches, so the queues stayed. The tree gains a node, batch size, between changeover and lead time, and planning gains a decision to own. A tree that has not changed in a year is not a stable tree; it is an unread one.

This is also why every node carries the decision it informs. Downtime hours inform the weekly fight for the maintenance window. Stockouts inform supermarket sizing. Changeover minutes inform batch size and sequence. When a review reads a number and no decision could possibly follow from it, that number is a candidate for the next yearly pruning.

What happens next

Two connections carry the tree forward. Upward, the root and drivers are the raw material of strategy deployment: the targets on the tree get negotiated through Hoshin Kanri, not announced, and the conditions attached to each target get written down with it. Downward, the leaves have to physically land on the boards of the daily management system, because a leaf that lives only in the tree diagram is not managed by anyone. On the roadmap, that next practice is daily management.

The failure point between those two connections is mechanical: the tree lives in a drawing, the boards live on the floor, the reviews live in spreadsheets, and within a quarter three versions of every number exist. This is the problem TeamGuru's KPI management use case removes: the tree's metrics, owners and targets live in one system, the boards and reviews read the same live numbers, and when the tree learns, every level sees the change the same week.

Frequently asked questions