Dashboard & analytics

Purpose

The Overview menu group — the "Overview" section (/, a customizable dashboard of widgets) — opens by default right after sign-in: it is a single entry point from which the operator sees the current state of their area of responsibility and can jump into the needed section with one click.

The Analytics menu group — the "Analytics" section (/analytics) — consolidated production analytics for an arbitrary period: planned/actual output, work in progress, defects, plus the "Efficiency and quality" block (OEE, TPM, SPC tabs) and a WIP-limits tab. If the dashboard answers "what needs to be done right now," "Analytics" answers "how did a place or production overall perform over a period."

Who uses it (roles)

• Overview (/) is visible to any signed-in operator — no permission is required for the section itself. But the dashboard has no data of its own: every widget is a separate request to the API of the section it displays, and is subject to that section's permissions. If the operator lacks permission for a given widget (for example, "Defects in last 7 days" requires qc.write), that widget simply does not appear in the "Add widget" list — the rest of the dashboard is not broken and shows no error.
• Analytics (/analytics) requires the production-board.view permission — held by the Area foreman and Dispatcher (see the roles table in Getting started). This permission is checked once, at the /api/analytics/* router level; there are no further per-tab checks inside the section, except one: only someone with scheduler.manage can manage WIP limits (change the number, open/close place-state intervals) — without it, the WIP and TPM tabs show read-only data, with no editing form.

Key concepts

Overview — the customizable dashboard (/)

What you see

The "Overview" title and an "Add widget" button on the right. Below is a free-form grid (react-grid-layout, 12 columns) of widget cards. Each card's header has a "handle" for dragging (the GripVertical icon, the whole header is the grab zone) and a "Remove widget" cross on the right; the card itself is resized by dragging its bottom-right corner. Clicking "Add widget" opens a dropdown list of widgets that are not yet on the dashboard and for which the operator has permission ("All available widgets are already added" if there is nothing left to add).

Widget catalog (widgetRegistry.ts) — three card types:

• Tiles (a number + a label, often with a subline and an alert color mark) — the whole card is clickable and leads to the corresponding section:
  • "Orders in production" (orders.view) — orders not in the draft/done/canceled statuses; in red, how many of them are overdue.
  • "To be submitted at places" (work-records.view) — the number of items in the work list awaiting submission.
  • "Arrivals not yet received" (arrivals.view) — unprocessed arrival documents.
  • "Limit cards running out" (limit-cards.view) — open limit cards whose validity period expires within 7 days.
  • "Customer orders: deadline risk" (customer-orders.view) — customer order lines at risk of missing their deadline; already-overdue ones are highlighted separately.
  • "Defects in last 7 days" (qc.write) — QC records rejected over the last 7 days, out of the total number of inspections in the same period.
  • "Material shortage" (scheduler.view) — the number of items with a supply shortage (from the Flow management summary).
  • "Overdue operations" (work-assignments.view) — shift assignments from past dates that are not yet done and not canceled; separately, how many of them are already "in progress."
  • "Bottleneck" (scheduler.view) — the place that is the candidate flow constraint (the longest queue), hours in queue, and load percentage.
  • "Equipment downtime today" (scheduler.view) — total idle + repair time across all places today, and the number of repairs.
  • "Open nonconformities" (qc.write) — open nonconformity records and the total quantity awaiting resolution.
  • "Purchasing needs attention" (provision.view) — purchase requests in "draft"/"approved" status + overdue deliveries on open supplier orders.
  • "Plan / actual output today" (production-board.view) — actual output today, % plan completion, and the planned quantity.
  • "My tasks" (work-records.view) — assignments from the work list that are personally assigned to the employee linked to the current operator (if the operator is not linked to an employee, the widget shows 0 with an explanatory hint).
• Charts (recharts, bar charts):
  • "Orders by status" (orders.view) — the number of orders in each status, using the same colors as in the kanban/Gantt chart.
  • "QC over 7 days" (qc.write) — accepted/rejected over the last 7 days.
  • "Place load" (scheduler.view) — the top 8 places by load (load_ratio), overloaded ones (≥100%) highlighted in red.
• List: "Recent events" (parts.view) — the last 8 activity log entries (date/time, action, details, who did it); clicking the list opens the full log.

The first sign-in (no saved layout) shows a fixed set of 6 tiles — "Orders in production," "To be submitted at places," "Arrivals not yet received," "Limit cards running out," "Customer orders: deadline risk," "Defects in last 7 days" — the same set the earlier, non-editable dashboard used to show; the rest of the widgets are optional, added via "Add widget."

Typical scenarios

1. Daily overview. The operator opens "Overview" — sees the 6 default tiles, clicks the tile with an alert color (for example, "Overdue: N" under "Orders in production"), and lands in the "Orders" section already showing the right view.
2. Tailoring the dashboard to a role. A dispatcher adds "Bottleneck," "Place load," "Material shortage," removes tiles that are not relevant to them ("Limit cards running out"), drags the "Orders by status" chart to the top — the layout is saved automatically (with a ~300 ms delay after the last change) and is restored the next time they sign in under the same login.
3. A shared terminal, different operators. On a shared PC, the Area foreman and Dispatcher sign in one after another under their own logins — each has their own layout (the localStorage key includes operator.id), and they do not overwrite each other.

Notes and limitations

• The layout is stored only in the browser (localStorage), not on the server — switching to another computer or clearing browser data resets the dashboard settings to defaults.
• If the saved layout references a widget that is no longer in the catalog (removed during development), or a widget the operator no longer has permission for (the role changed), that entry is silently dropped on load — the card is not shown empty or broken.
• Every widget makes its own independent API request; a failure in one widget (network, 403, etc.) shows "—" only in that tile, and the rest of the dashboard keeps working.
• Some widgets make several sequential requests (for example, "Equipment downtime today" queries metrics for each place separately) — with many places, this makes them correspondingly slower than a simple tile.

Analytics — "Production" tab (/analytics)

What you see

Filters at the top: a "From" / "To" period (last 14 days by default) and a place selector (or "All places"). Below:

• 4 KPI cards: Actual output (with the planned number underneath), Plan completion (%), Overdue orders (among active ones), Defect rate (% of QC-inspected quantity over the period) — overdue orders and a defect rate >0 are highlighted with an alert color.
• Plan / actual output — a bar chart by day over the period (planned and actual quantity overlaid).
• WIP by stage — horizontal bars: how many routing steps are currently "Awaiting start" / "In progress" / "Done" (active orders only — not done/canceled/draft).
• Defect Pareto — defect types in descending order of quantity over the period.
• Needs attention — a table of orders with a deadline problem: columns Order, Product, Deadline, Readiness (%), Reason ("Deadline passed" — red, "Deadline within the selected period" — yellow, if readiness <100%). Clicking the order number opens the order's card. The list is capped at 50 rows, sorted overdue-first, then by ascending deadline.

Typical scenarios

1. Shift/weekly report for the area foreman. Pick your place and the period → check the % plan completion and the "Needs attention" list to understand which orders need to be pushed first.
2. A dispatcher looking for the reason a plan slipped. Looks at "Plan / actual" to see exactly where actual output dipped, switches to "WIP by stage" to see whether WIP piled up in a particular status (for example, a lot of "Awaiting start" — a bottleneck at the entrance to the place).
3. Quality tracking. The monthly defect Pareto shows the dominant defect type — a reason to start a conversation with the place or reconsider the routing.

Notes and limitations

• The period is capped at 366 days per request — the backend rejects a wider range with a 422 error.
• "Needs attention" and "Overdue orders" are computed only for active orders (not draft, not done, not canceled); drafts (not yet launched into production) do not appear in production analytics — by definition they are not in production, see Production & planning for the order lifecycle.
• When a specific place is selected, all counters (WIP, "Needs attention," the place list in the filter) are recomputed relative to routing steps at that place specifically — the summary changes meaning rather than simply filtering the table.
• "Defect rate" is computed from the quantity QC-inspected over the period (quantity in QcRecord), not from the quantity submitted at the place — if QC is lagging behind submissions, the figure for recent days will be understated.

Analytics — OEE / TPM / SPC tabs ("Efficiency and quality")

Shared filter block: a place selector (required — without it the OEE and TPM tabs show a prompt to pick a place) and a "From"/"To" period (30 days by default), a "Refresh" button. SPC uses the same period but does not require a place — it has its own filter (the control parameter).

OEE — what you see

• A circular gauge (OeeGauge) with the overall OEE % — the color depends on the value (green ≥85%, yellow ≥60%, red below); a label next to it spells out the formula: "OEE = availability × performance × quality."
• KPI cards: Availability (%, with a subline "X of Y min accounted for"), Performance (%, "standard time / running time"), Quality (%), MTBF / MTTR (hours, number of repairs) — the MTBF/MTTR card is highlighted with a warning if there were repairs during the period.
• Accounted-for time — a horizontal bar split into "Running" / "Idle" / "Changeover" / "Repair" segments with a legend (minutes and %).
• Losses (Pareto) — the same non-"Running" intervals, sorted by duration, marked "80% of losses above the line" (the classic ABC cut of losses).
• If OEE could not be computed (no state intervals or work records for the period), a hint is shown instead of numbers, explaining what data is still needed (state intervals on the TPM tab and work records for the period).

TPM — what you see

• KPI cards: MTBF, MTTR (with the number of repairs), Downtime (minutes over the period), Changeovers (minutes over the period), Active issues — how many state intervals are currently not "Running" (highlighted red if greater than 0).
• Current place state (ResourceStatePanel) — a list of currently open intervals (state, comment, start time); each one has a "Close" button — if the operator has scheduler.manage. Below is a form for opening a new interval: pick a state (Running / Idle / Changeover / Repair) + a text comment + an "Open interval" button. Without scheduler.manage, the form and "Close" buttons are not shown — view-only.
• Interval history (IntervalTimeline) — row by row for each day of the period: colored segments on a 24-hour timeline showing what state the place was in at what time (hovering shows a tooltip with the state/comment).

SPC — what you see

• A control parameter selector — an autocomplete combobox over the QualityMeasurement.parameter_name values entered during QC.
• After picking a parameter — KPI cards: Mean, UCL / LCL (upper/ lower control limit), Cp / Cpk (process capability indices — computed only if the parameter has tolerance_min/tolerance_max set), Out of control — the number of points outside UCL/LCL out of the total number of points (highlighted red when nonzero).
• Two charts: Individual values (I) — a line of values with dashed mean/UCL/LCL lines, points outside the limits are enlarged and highlighted; Moving range (MR) — a line of |difference between neighboring values| with a dashed mean-MR line.
• An expandable table of all points: date, QC record ID, value, moving range — rows outside the control limits are highlighted.

Typical scenarios

1. Monthly review of a place's efficiency. The foreman picks a place and a month on the OEE tab, looks at the overall % and the breakdown into the three components to understand what is pulling the figure down — downtime (availability), slow work (performance), or defects (quality); switches to "Losses (Pareto)" to see the main cause of downtime.
2. Real-time downtime logging. A dispatcher/foreman with scheduler.manage opens a "Repair" interval on the TPM tab with a comment on the cause when equipment goes down, and closes it when work resumes — this is the primary data OEE/TPM is computed from.
3. Process stability control. A process engineer/QC picks a numeric measurement parameter (for example, a part's diameter) on the SPC tab for the period of interest, looks at points outside UCL/LCL and Cpk — a signal that the process has drifted and it's time to investigate the cause before mass defects appear.

Notes and limitations

• OEE/TPM depend entirely on the discipline of manually logging place-state intervals (ResourceStateEvent) — if the foreman doesn't open and close intervals, "Availability" and the metrics derived from it will be unreliable.
• "Performance" can exceed 100% — this is not a bug: it is computed as the ratio of the standard time (Tman of submitted work) to actual time in the "Running" state, and if the place worked faster than the norm, the figure exceeds 100% (the dashboard's OeeGauge widget handles this case separately, but on the OEE tab the value is simply shown as-is).
• MTBF/MTTR are not computed (left blank) if there was no "Repair" interval during the period — this is expected behavior, not a data error.
• SPC uses a simplified I-MR chart for individual values (not an X̄-R chart for subgroups) — control limits are computed from the moving range using fixed constants (d2=1.128, a 3σ multiplier of 2.66 for n=2), not for subgroups of arbitrary size. Cp/Cpk are computed only if at least one measurement record has tolerance_min and tolerance_max.
• Permissions are split by only one operation within the OEE/TPM/SPC block — scheduler.manage for opening/closing state intervals and editing WIP limits; viewing the tabs themselves is gated by one shared section permission (production-board.view), with no separate permission for viewing OEE/SPC/TPM specifically.

Analytics — "WIP" tab (/analytics, WIP tab)

What you see

A list of places, and for each, the current WIP / the set limit (current_wip / limit) and a fill bar (red if the limit is reached or exceeded); if no limit is set, a "not set" mark is shown. With scheduler.manage, a "Change" button appears next to each place, opening a field to enter a new limit value and "Save"/"Cancel" buttons.

Typical scenarios

1. A dispatcher setting up buffer-based flow planning (see Production & planning, "Flow management"/"Dispatch") opens the WIP tab to check which places already have a limit set and which still have no value (meaning the constraint is not actually in effect).
2. A foreman sees a place is "up against" its limit (the bar is red, current_wip == limit) — a hint as to why the dispatcher is not letting new work onto the place until the current work moves along.

Notes and limitations

• This tab is only a display of existing WIP limits; the mechanism by which the limit affects scheduling and further flow dispatch is covered in Production & planning ("Flow management," "Dispatch"/POLCA). Only what is visible and editable from the "Analytics" page itself is described here.

Related sections

• Getting started — roles and permissions, windows and navigation; used here without re-explaining them.
• Production & planning — "Flow management" and "Dispatch" — the data source for the "Bottleneck," "Material shortage," "Place load" widgets and the WIP tab (WIP limits, POLCA, and the flow bottleneck are covered there in detail); "Production schedule" — the source of the order statuses shown by "Overview" and the "Production" tab.
• Work & quality — "Work intake," QC, and defects — the primary data behind the "Defects in last 7 days" widget, the "Defect rate" KPI, the defect Pareto, and the SPC tab.
• Warehouse & supply — arrival of materials, limit cards, supply availability — the source of the "Arrivals not yet received," "Limit cards running out," "Purchasing needs attention" widgets.