Plant and operations, concepts

Plant shows the day-to-day floor picture: what’s running, what just broke, and the record of shift-level production and events. Facility Map is its landing screen, a live, top-down view of the plant you can drill into from.

Related operational screens

Performance, Downtime, Changeover, and Energy sit in Performance. Dispatch and job records sit in Jobs. Maintenance has its own area. Logbook, Shift Handoff, and Boards sit in Plant.

Node Detail (/node/:type/:id) is the “drill in” page reached from Facility Map or Home, OEE, downtime pareto, asset breakdown, open alerts, a deep KPI switchboard, and a Notes tab (Shift Handoff/Logbook context reached from the machine itself, scoped to that node and everything beneath it) for one node. Facility Map’s own KPI lens is the plant’s OEE roll-up for every site/area/work-center/machine, colored in on the same live map rather than a separate card tree, open Plant pulse on Home or choose Plant, then Facility Map. See How to check plant status and drill in.

See how-tos for step-by-step tasks on each of these.

Domain objects

OEE and its A/P/Q factors

OEE (Overall Equipment Effectiveness) is the headline number on almost every Floor screen. It’s built from three factors, each 0-100%:

• Availability (A), actual run time vs. scheduled time (time lost to downtime).
• Performance (P), actual output rate vs. the ideal run rate for that asset (time lost to slow cycles/minor stops).
• Quality (Q), good units vs. total units produced (units lost to scrap/rework).

OEE = A × P × Q. Facility Map’s KPI lens and Node Detail roll this up per node in the hierarchy. A claimed station shows it live for a single asset.

Missing data: a node with incomplete or missing data renders a placeholder instead of a made-up percentage. If you see a blank OEE tile, that means data isn’t flowing yet for that node, not that OEE is zero. This convention is applied consistently across Facility Map, Performance, Maintenance (MTTR/MTBF), and claimed stations. See How to check plant status and drill in.

Downtime and downtime reasons

Every stop on an asset is logged as a downtime event. Once a stop is tagged with a reason code (e.g. “changeover,” “jam,” “PM”), it flows into:

• the Downtime Pareto (/downtime), sorted longest-total-minutes-first so the biggest loss is always first, see How to find the biggest downtime reasons.
• the Maintenance queue (/maintenance), which turns an unresolved stop into a one-tap repair loop.
• Shift Handoff, which folds the shift’s downtime pareto into the outgoing brief.

Reason codes are logged closest to the source, typically by the operator, inline, from a claimed station, see How to run a claimed station.

A very short stop does not need a tap, and Spall grades that on a ladder with four rungs:

• Blip, under about 5 seconds. Sensor noise, never counted as a stop at all. This floor is fixed and always on, nothing to configure.
• Ignored, shorter than your plant’s ignore floor, if you set one (Setup, Codes, Downtime Reasons tab, or a machine’s own KPIs and targets tab). It happened, but too short to matter, no downtime span is recorded at all, nothing shows up in your numbers.
• Minor stop, shorter than your plant’s minor stop threshold, if you set one, same two places. Logged automatically as a minor stop, counted in every number, visible in the Pareto and the event lists, just never added to the uncoded backlog, no tap needed.
• Real downtime, everything else. An operator or supervisor tags it with a reason code.

Both thresholds are optional and independent of the fixed blip floor below them. The ignore floor can never be set higher than the minor stop threshold, Spall tells you if you try. Only stops that happen after a threshold is set are affected, nothing already logged is rewritten.

Maintenance, MTTR, and MTBF

The Maintenance queue tracks each stop through a fixed lifecycle: new → acked → in_repair → repaired → closed, with one action button per state (Acknowledge → Start repair → End repair → Close). Two reliability metrics summarize the queue:

• MTTR (Mean Time To Repair), how long, on average, a repair takes to close once it starts.
• MTBF (Mean Time Between Failures), how long, on average, an asset runs between genuine failures, not every stop, only an actual breakdown or a stop with a repair opened against it counts, not a routine changeover, a quality check, or an ordinary jam.

Both render as an em-dash when there’s no data to compute them from, instead of a made-up number. An AI remaining-useful-life (RUL) panel supplements this with a statistical (non-LLM) next-failure risk estimate per asset, using the same failure definition as the header MTBF above, flagging assets whose recent MTBF trend is degrading.

An asset shows a stated reason instead of a guessed number until it has enough real failure history to trust, and the dollar exposure shown is priced at each asset’s own configured rate where one exists, labeled when it falls back to a default instead.

Jobs and Dispatch Board

A job is a planned/running/closed unit of production work against a product and a work center. Jobs (/work-orders) is the canonical, plant-wide record list under Improve, since it’s a record you review instead of a floor action. Dispatch Board (/dispatch) stays here on Floor: it’s where a planner sequences and reassigns queued jobs per work center before they run. See Improve, Jobs and How to plan and dispatch work.

A plant that doesn’t schedule jobs at all still gets product context: from a claimed station’s Job tile, an operator can tap What’s running? and pick the product a machine is actually making, with no scheduled job required. This opens a job labeled Logged from the floor instead of a scheduled one, and it feeds scrap/downtime/rate reporting the same way a scheduled job would. A machine that reports its own program or recipe number on a tag can have this happen automatically, once that value is mapped to a product. See How to tell Spall what a machine is running.

Changeover

Changeover loss is the capacity lost switching an asset from one product to another. The Changeover screen ranks assets by lost minutes and compares the actual median changeover against each product’s routing setup-time standard (see Setup, products, routings, and targets), on top of any SMED target configured. See How to find and reduce changeover loss.

Shift Handoff and Logbook

A shift is a named, scheduled time window (e.g. “Day,” “Night”) attached to a site. Shift Handoff assembles one end-of-shift brief (OEE, best-window comparison, quality, downtime, alerts, open jobs) so an outgoing shift can hand off cleanly to the incoming one. Logbook is the lighter-weight companion: a free-text plant/shift log of notable events over time, for anything that doesn’t need a structured Work Item. Shifts themselves are configured in Setup, not here, see Shifts and schedules, but almost every number on this page is shift-aware because of that configuration. See How to prepare a shift handoff brief.

You don’t have to come to Logbook or Shift Handoff to reach this context, either. Every machine’s own Node Detail page has a Notes tab: recent notes for that machine (or, on a site/area/line, recent notes for every machine underneath it) plus a View in Logbook link that opens the full Logbook already filtered to that same scope. It’s the same hierarchy every other rollup in Spall uses, not a separate per-machine mechanism, so a line’s Notes tab shows exactly the notes its Logbook filter would.

Notes help the plant find patterns, not score people. Spall does not build per-person rankings or operator scoreboards from them. Whoever wrote a note stays visible on that note itself, the same way a name goes on a paper logbook entry. Work Item comments reach Ask your factory with role and shift attribution. Logbook notes can still carry their recorded author into an Ask answer, so do not use Ask as a people-analytics tool.

How the pieces relate

Facility Map is the plant-wide rollup over every node, a live, top-down spatial layout by default (Status lens), or the same nodes’ OEE-family rollup colored in instead (KPI lens), reached from Home’s Plant status tile, ⌘K search, or Floor’s own landing spot. It links into Node Detail, the single assembly page for one node, it exists so an admin doesn’t have to piece together OEE + downtime + alerts + bottleneck asset by visiting four separate screens. Downtime, Changeover, Performance, Maintenance, and Shift Handoff are each a deeper, single-purpose view of one slice of that same underlying data (KPI events, production counts, maintenance queue), Shift Handoff in particular exists to assemble several of those slices into one end-of-shift artifact. Dispatch Board is the planning/execution layer over the same production data Performance and Shift Handoff summarize (its record-keeping counterpart, Jobs, lives in Improve). A claimed station is the odd one out structurally (it renders full-screen, outside the nav chrome) but feeds the same downtime/production data that Downtime and Performance summarize.