Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Maintenance KPIs

The maintenance module computes a small set of canonical reliability KPIs, rolled per asset, per functional location, and per asset class. The numbers are surfaced in two places:

  • Dashboard (sidebar → Dashboard) for the plant-wide view, split across the Reliability, Availability, Workload, Failure analysis, and Spare parts tabs, with a date-range filter in the header. Pin any KPI you care about to the Overview tab via the Customize button.
  • Asset detail page → Health tab for the per-asset view: composite reliability score, last 5 closed work-order costs, hours since last breakdown.

Reliability metrics

  • MTBF — Mean Time Between Failures. Total uptime divided by the count of breakdown work orders in the period. The headline reliability metric.
  • MTTR — Mean Time To Repair. Sum of breakdown downtime divided by the count of breakdowns. Surfaced on the Time-to-failure dashboard card both as a headline number and as a three-bucket split, all rolled up per breakdown:
    • Diagnostic time — the gap between the asset going down (actual_start_date on the breakdown work order) and the first labour entry logged against it. Fault-finding time; long diagnostics usually mean the team is missing tooling, training, or failure history on the asset.
    • Active repair time — total labour-entry duration on breakdown work orders. The hands-on wrench-time bucket — the only one the team directly controls.
    • Wait time — the remainder: total breakdown downtime minus Diagnostic minus Active. Picks up on-hold time and gaps between labour entries (waiting on parts, approvals, vendors, free technicians). A growing wait bucket points at stock-out risk or process bottlenecks, not at the repair itself. The three buckets always add up to the headline MTTR by construction. The dashboard card pairs the three numbers with a small horizontal stacked bar so you can read the dominant bucket at a glance.
  • Failure density — count of failures per operating hour. Operating hours is an estimate from calendar time minus recorded downtime (active assets × the period length, less the downtime logged in the window) — it is not read from meter readings, so two assets that run very different daily hours contribute the same calendar time. Surfaced on the dashboard as a single org-wide number with the breakdown count and operating-hour total on the sublabel; the headline value is bounded green below 0.001 (one breakdown every 1 000 operating hours), amber up to 0.005, red above. The same metric is the inverse of MTBF — they answer the same question with different units.
  • Availability — uptime / period. Counts both planned-unavailable (PM downtime) and unplanned-unavailable (breakdown downtime) against the asset. Idle time is not subtracted from the period, so a mothballed (idle) asset still counts that time as available. When a single asset is filtered, the period is clamped to the asset’s commissioned-and-not-disposed window so a brand-new asset doesn’t read 0% across the full 90 days.
  • Planned / unplanned ratio — sum of planned downtime over sum of unplanned downtime. Should trend up over time as the PM program matures. The dashboard surfaces this two ways: org-wide on the Availability card, and broken out by asset class in the Planned share by asset class panel so a manager can see which class is driving the unplanned-firefighting share without leaving the page.
  • Repeat failure rate — share of breakdown WOs on assets that had another breakdown in the prior 30 days. Drives quality-of-repair attention.

Failure analysis (Pareto)

The Failure analysis tab on the dashboard breaks breakdown work orders that started in the window down three ways so you can see, at a glance, what to act on next:

  • Top problem codes — the symptoms (oil leak, motor overheating, conveyor jam) that show up most often. Tallest bar first.
  • Top root causes — the underlying reasons captured at close (lubrication missed, bearing fatigue, misalignment). The “why” behind the problems above.
  • Top offending assets — the third axis. A ranked list of the equipment with the highest breakdown count in the date window, labelled asset code — asset name. A handful of assets typically drive most of the unplanned downtime; this panel is where you spot the ones a refurbishment, replacement, or focused reliability sprint would pay for fastest. Read it side-by-side with Parts spend by asset to separate the “fails often but cheap to fix” assets from the cost-heavy ones — same date window, different lens.

All three panels honour the dashboard date-range filter and the asset-class / functional-location filters at the top of the Maintenance tab.

Workload metrics

  • Backlog age — average age of open requests (NEW / ACCEPTED / DEFERRED), with a per-SLA-tier breakdown.
  • Overdue count — open requests past their SLA due time. The system also tracks overdue work orders (any active work order whose due date is before today and is not yet completed, closed, or cancelled), counted separately.
  • Wrench time — sum of labor-entry durations divided by sum of scheduled shift time for assigned technicians. The 60-70% target most orgs cite as healthy.
  • PM compliance — count of preventive WOs closed on time divided by count of preventive WOs due in the period. Should trend toward 100% as planning and dispatch tighten. The dashboard surfaces it twice: the org-wide number sits on the Productivity card, and the PM compliance by plan panel breaks it out per active maintenance plan so a planner can spot which plan is dragging the headline down. The two figures count slightly different populations — the headline covers every preventive work order, while the by-plan panel covers every work order generated from a plan — so they won’t always add up. Worst-performing plan floats to the top; plans with nothing due in the window still appear (with a “Nothing due in window” sublabel) so newly activated plans never disappear.

Composite reliability score

A composite reliability score (0-100) for each asset combines:

  • 40% MTBF (normalised against asset-class target).
  • 20% repeat-failure rate (lower is better, normalised).
  • 20% planned-to-unplanned ratio (normalised, capped). An asset with zero breakdown downtime scores full marks on this component — a perfect, breakdown-free record is treated as the best case, not penalised.
  • 20% PM compliance.

Targets are org-configurable. The score lets leadership compare reliability across very different assets on a single scale.

Tuning the targets

Open Reliability Targets in the Maintenance sidebar (or /maintenance-reliability-targets). The page is a single settings form with two values:

  • MTBF target — operating hours between breakdowns you want to score 100 %. Defaults to 720 (≈ 30 days). Set higher if your equipment runs cleaner than the industry baseline.
  • Planned / unplanned ratio target — how many planned (PM / inspection / calibration) work orders you expect per breakdown. Defaults to 4×. Aspirational programs aim for 6×–8×; reactive shops sit near 1×.

Saving the form persists the row for your organization; the reliability score, asset health cards, and the dashboard tiles all recompute on the next refresh. There is one row per organization — you can keep tuning over time; the form’s notes field records why you picked the current values.

Requires maintenance-plan permissions: viewing needs Maintenance plan view, and saving needs Maintenance plan create (first save) or Maintenance plan update (later saves).

Spare-parts reports

The Spare parts tab on the dashboard surfaces four reports that read across maintenance work orders and the stock ledger:

  • Critical-spare coverage — share of active critical-spare policies whose available stock (on-hand minus reserved, excluding any repair-pool location) meets the policy minimum. Always live — the date filter is ignored, because it answers “are we ready for a breakdown right now?”. The uncovered policies are listed so a buyer can drill in.
  • Repair-pool items — count of distinct stock-quantity rows currently sitting in a repair-pool location (any location flagged metadata.is_repair_pool = true). Each item’s age is the time since the row was last touched, used as a proxy for “how long has this been waiting for repair?”. A growing pool means working capital tied up in pending repairs.
  • Parts spend by asset (90 d) — total maintenance parts spend per asset over the date window. Sum of actual_unit_cost × issued_quantity across closed-WO part lines. Top 10 are displayed; the per-asset cost story drives the asset-health card.
  • Top parts by spend (90 d) — same join, pivoted by spare-part SKU. Procurement uses this to identify SKUs worth a frame agreement with the supplier.

For assets that are also work centers, the maintenance module owns the availability component of OEE (Overall Equipment Effectiveness). The performance component (run rate / standard rate) and quality component (good output / total output) come from the production-reporting side. Beelocity joins them via assets.work_center_id for a single OEE view per asset/work center.

Where the numbers come from

  • Work-order activity — flavour, status transitions, actual dates, cost columns.
  • Downtime windows — planned/unplanned flag, started_at, ended_at, duration. These drive the operating-hours estimate (calendar time minus downtime) behind failure density.
  • Request timestamps — for diagnostic time decomposition of MTTR.
  • Asset master data — commissioning date, used to clamp the period when a single asset is filtered.

Caching

Per-asset KPIs are computed at request time — cheap on the typical fleet size. Plant-wide rollups (the org-level dashboard tile) are cached for five minutes and invalidated when a WO closes or a downtime window changes.