Operations metrics dashboard

You give the owner a small set of operational measures they can trust and read correctly. Trust comes from precise definitions and data pulled from the system of record. Reading correctly comes from showing each measure over time with its natural range, so that a normal wobble is not mistaken for a crisis and a real shift is not dismissed as noise. Every weekly read-out ends with what changed and what to do about it.

When to use

• "I want a weekly dashboard for operations."
• "On-time delivery dropped to 92% this week. Is that bad?"
• "What should we be measuring in the warehouse / support team / service delivery?"
• "Did the new process actually improve anything?"
• Weekly, with cronjob, before the owner's operations review.

What you need

• The outcome the owner cares about (on-time delivery, customer wait time, cost per order, error rate) and the decisions they make weekly.
• Data from the systems of record: order, ticketing, booking, inventory or job systems connected on the Connections page (for example HubSpot, Jira, Intercom, ClickUp, Google Sheets), the owner's order or ticketing system in your own browser where they signed you in, or exports. Raw records with timestamps are better than summaries.
• At least 12 to 20 past periods of history to set natural limits.
• Targets the owner has set, if any.

Method

1. Build the metric tree. Start from the outcome and break it into the drivers that produce it: on-time delivery depends on orders picked on the day, carrier collection on time, stock availability, address accuracy. Choose 5 to 8 measures: the outcome, 3 to 5 drivers the team can act on, and one or two measures of cost or effort so that improving one thing does not quietly break another.
2. Define each measure precisely (template in references/metrics-and-charts.md): formula, unit, what counts and what is excluded, data source and field, period (week ending which day, time zone), owner, direction, target if any. Example: "On-time %: orders delivered on or before the promised date / orders with a delivery event in the week (Mon to Sun, UK time); excludes cancelled orders; source: carrier tracking export."
3. Pull the data with execute_code from raw records, compute each measure per week, and check it against a total from the source (order count in the system for the same week). Never compare a partial week with full weeks; label the current week "to date" until it closes.
4. Chart each measure as a process behaviour (XmR) chart: the values over time with a centre line (mean) and natural process limits at the mean plus and minus 2.66 times the average moving range (the average absolute week-to-week difference). Use a stable baseline period (12 to 20 points) for the limits and keep them fixed until a real, explained shift happens; then recalculate from the new level.
5. Apply the signal rules, and only call something a change when one fires:
   • A point outside the natural limits.
   • 8 or more points in a row on the same side of the centre line.
   • 3 out of 4 points closer to a limit than to the centre line. No signal means the week's movement is routine variation: do not hunt for a cause in it.
6. Compare with targets separately. A process can be stable and still not meet the target; that calls for changing the process (see process-improvement), not for reacting to individual weeks.
7. Build the workbook (tested code in the reference): Data, Measures, one chart per measure with centre and limits, Definitions, Signals. Recompute every measure in Python and compare with the sheet.
8. Write the weekly read-out (5 to 10 lines): for each measure, value, routine or signal; for each signal, what it is, the likely driver from the metric tree, and the action or investigation (see operational-root-cause-analysis); then anything off target but stable, with the improvement project addressing it.

Worked example: on-time delivery

Twenty weeks of on-time percentages, with the first twelve as the baseline. Mean 94.7%; average moving range 1.15 points; natural limits 94.7 plus or minus 2.66 x 1.15, so 91.7% to 97.8%. Weeks 13 to 20 all sit below the centre line, and week 20 (91.6%) crosses the lower limit: rule 2 (8 in a row) and rule 1 (outside the limits) both fire. That is a real shift, not a wobble. The read-out names the change that coincided (a new carrier from the week of 24 Aug) and hands it to operational-root-cause-analysis with the data. A single week at 93.0% inside the limits, by contrast, is routine: say "routine" and do not hunt for a cause. The code that produced these figures is in references/metrics-and-charts.md.

Building the metric tree

Outcome: on-time delivery %. Drivers the team controls: same-day pick %, carrier collection on time %, stock-outs %, address errors %. Guard measures so improvement does not break something else: cost per order, overtime hours. Five to eight measures in total, and each driver must point to something a named person can change this week. If a driver has no owner, it is a diagnostic, not a dashboard measure.

The weekly read-out, line by line

• The value, with the count behind it ("97.8% of 1,240 orders").
• Routine or signal, naming the rule that fired.
• For a signal: the likely driver from the tree, and the action with an owner and a date.
• For a stable measure that is off target: the improvement project working on it, or the decision needed to start one. Five to ten lines. The owner reads it in a minute and knows what to do; everything else lives in the workbook.

Output

• ops-dashboard-<week>.xlsx: Dashboard (latest value, centre, limits, status: routine, signal, off target), charts, Data, Definitions, Signals.
• A show_card with each measure's latest value and status.
• The weekly read-out, for example:

Operations, week ending 18 Oct

On-time delivery 91.6%: SIGNAL. Below the centre line (94.7%) for 8 weeks and now below the
  lower limit (91.7%). Started the week of 24 Aug, when the new carrier began.
  Action: root-cause review with the carrier data (Ops lead, by 23 Oct).
Orders picked same day 97.8%: routine (limits 95.2% to 99.9%).
Cost per order 4.12: routine; above target 3.80 for 12 weeks: improvement project running.

Checks before you finish

• Every measure has a written definition with source and exclusions.
• Weekly figures reconcile to totals in the source system.
• No partial period is compared with full periods.
• Limits come from a stated baseline period and the formula above; recalculated only after an explained shift.
• Every "signal" in the read-out meets one of the rules; nothing else is called a change.
• Python recompute matches the workbook.

Pitfalls

• Reacting to every wobble. Week-to-week variation is mostly noise; the limits show how much.
• Comparing with last week only. Two points are not a trend. Show the series.
• Using targets as limits. Targets are wishes; limits describe what the process actually does.
• Averages without counts. 100% on time from 3 orders is not 100% from 3,000.
• Measures the team cannot act on. Each measure should point to something someone can change.
• Too many measures. Five to eight, read every week, beat thirty nobody reads.
• Changing definitions silently. Restate history or mark the break on the chart.

See also

• process-improvement, operational-root-cause-analysis, finance-kpi-dashboard (finance).