MV Sport — how long orders sit in each department
Reconstructed from A2000 track-code history (NKW.ORDER_TRACK_LOG). Every scan stamps an order with a track code and a timestamp; mapping codes to departments and reading the timestamps back tells us, for each order, how long it sat in a department before moving on. Plotted as a 7-day trailing average so day-to-day noise smooths into the trend.
What "dwell" means here. Consecutive scans in the same department are collapsed into one visit; the visit's dwell is the calendar time (days, with time-of-day precision) from the order's first scan in that department until its next scan in a different department — i.e. the moment it left. Each visit is dated to the day it entered the department. Same scope as the operational analysis: division V, Costco removed, BSN dropship POD held out. Stalled/reopened visits over 60 days (~1%) are dropped as outliers.
Average days in department, by year
Average is visit-weighted (mean over all department visits that started in the year), so high-volume stages dominate their own number. Art and licensing are the long poles (~7–8 days); ticketing and finishing clear in about a day. 2026 YTD runs slightly low for late-stage departments — orders still in flight haven't recorded their exit scan yet, so their final dwell isn't counted.
The trend — 7-day trailing average
Each line is the trailing-7-day mean dwell for orders that entered that department in the window. Dashed verticals mark year boundaries. Watch for regime shifts — a line that steps up and stays there is a department that got structurally slower, not just a busy week.
Every department, side by side
Same 7-day trailing series, one panel per department (ordered by 2025 average, slowest first). Panels share both axes (y clamped to 0–15 days for readability), so heights are directly comparable — art and licensing ride high, ticketing and finishing hug the floor. Source:
NKW.ORDER_TRACK_LOG × ORDER_HEADER_M (DIV_NO='V'), track→dept map from MVDev order-track.ts. Visits capped at Days of backlog
A different lens for the five production / finishing stages: instead of how long an order sat, how many days of work are queued up in front of the department right now. High and rising means demand bound for that stage is outrunning its throughput.
How it's built. An active order = a non-shipped order whose cancel date is at most
The numerator is department-specific: an order counts toward a stage's backlog only while it's active and upstream of that stage. An order leaves the queue the moment it reaches the stage, ships, is canceled, or its cancel date passes. (The series stops ~12 days short of today: very recent active orders bound for a stage may not have recorded any scan yet, which would falsely collapse the tail.)
The numerator is department-specific: an order counts toward a stage's backlog only while it's active and upstream of that stage. An order leaves the queue the moment it reaches the stage, ships, is canceled, or its cancel date passes. (The series stops ~12 days short of today: very recent active orders bound for a stage may not have recorded any scan yet, which would falsely collapse the tail.)
Throughput and backlog (latest)
Throughput is the computed denominator: order-units each stage completed per day (trailing
Average days in the stage — for comparison
The original dwell metric — how long an order actually spends in each stage — for the same five stages, so it can be read directly against the queue below.
Dwell = time from an order's first scan in the stage until it leaves for the next (the metric from the top of the page). It's how long the stage takes per order; the backlog below is how deep the queue of work bound for it runs. Same five colors as the chart below.
Days of backlog
Each line is that stage's own queue, in days, at its own throughput. Dashed verticals mark year boundaries. Read the trend: a stage whose line climbs is taking on work bound for it faster than it can clear — a building bottleneck — even if its per-order dwell looks steady. Seasonal peaks push the lines up together with total demand (below).
Total active order book over time
Context, not the numerator: total units across all non-shipped orders whose cancel date is within
ORDER_HEADER_M (ORDER_DATE / CANCEL_DATE / CANCELED_ON_DATE), first INVOICE_DATE as ship, units from ORDER_LI_M; per-stage need & throughput from ORDER_TRACK_LOG.