An end-to-end business analysis of the “Proactive Fill List” at a national automotive & hardware retailer — from requirements and process modelling through root cause analysis, data analysis, and a sustained operational fix that I co-led on the floor.
Every morning, a system-generated proactive fill list told the Auto Parts floor team which items to move from the warehouse to their floor locations (“homes”). It was meant to be a trusted daily work queue.
In practice, of ~250 items flagged daily, ~200 (~80%) were false positives — the home had no physical room, was already stocked, or the item belonged to a different department entirely. Staff picked everything, filled the ~50 that fit, and hauled ~200 items back upstairs. Nothing was diagnosed, so the same items returned the next day — for over a year, consuming 4–12 person-hours daily.
The dashboard logic worked exactly as designed. The failure was in the data feeding it — bin capacities, on-hand counts, and department classifications — and in the absence of anyone who owned keeping that data right.
Cross-functional swimlane models built from observed behaviour — the broken loop, the sprint that broke it, and the sustained steady state. (Interactive recreations of the original BPMN-style PowerPoint models.)
AS-IS · ran for 1+ year. Pick everything, fill the few that fit, haul the rest back, repeat forever — and the noise eventually hides the real flags too.
REMEDIATION · ~2 weeks, daily. Same picking effort, but every failure is diagnosed and routed to its owner — the bad data gets cleaned out instead of recycling.
TO-BE · ongoing. A short, accurate list staff trust — kept clean by a trained diagnose-and-route habit, with preventive controls recommended (dashed) to stop errors at the source.
| As-Is | Remediation | To-Be | |
|---|---|---|---|
| Daily list | ~250 | ~250 → shrinking | ~50 (range 20–50) |
| False positives | ~80% | being corrected | minimal |
| What happens to a miss | hauled back, ignored | diagnosed & routed | rare, fixed on the spot |
| Data errors | never fixed | actively burned down | corrected on sight; prevention recommended |
| Staff trust | eroded; true flags ignored | rebuilding | restored; every flag actioned |
| Duration | 1+ year | ~2 weeks | ongoing |
A fishbone (Ishikawa) analysis with five-whys drill-downs. Data holds the three proximate causes; Method, People and Measurement explain why they persisted for a year; System is deliberately thin — the dashboard worked as designed. ° = analytical inference; all other causes confirmed from lived experience.
Four views of the same story: what the list was made of, why no single fix could work, and the two-week burndown that proved the remediation.
Six business requirements, each expressed as a user story with testable acceptance criteria and traced end-to-end in a Requirements Traceability Matrix. Nothing in the solution exists without a requirement; no requirement exists without a diagnosed cause.
| BR | Requirement | Priority | Story | Status |
|---|---|---|---|---|
| BR-01 | Flag items only when the home can physically take more stock | Must | US-01 | Implemented |
| BR-02 | System on-hand reconciles with physical on-hand | Must | US-02 | Implemented |
| BR-03 | Items appear only on their correct department’s list | Must | US-03 | Implemented |
| BR-04 | Defined diagnose-and-route method for every failed fill | Must | US-04 | Implemented — sustained by training |
| BR-05 | Named accountable owner for each error type | Should | US-05 | Implemented |
| BR-06 | Master data validated at setup + periodically audited | Should | US-06 | Recommended — not implemented |
As a floor staff member, I want to correct a home’s bin cap the moment I find it exceeds physical capacity, so the item stops being falsely flagged.
As the Store Manager, I want every suspected on-hand discrepancy routed to me on a daily handoff list, so I can correct counts staff cannot change themselves.
As a floor staff member, I want misclassified items escalated for corporate re-tagging, so my list contains only my department’s items.
As a floor staff member, I want a single defined procedure for diagnosing any failed fill and routing it, so no error type is left uncorrected.
As the Store Manager, I want each error type to have a named accountable owner, so corrections happen and escalation is unambiguous.
As the Store Manager, I want master data validated at setup and audited periodically, so errors are prevented rather than corrected after they surface.
| Root cause | BR | Solution / control | Owner | Status |
|---|---|---|---|---|
| Bin cap > physical capacity | BR-01 | On-the-spot correction, embedded in trained SOP | Floor staff | Implemented |
| System ≠ physical on-hand | BR-02 | Daily paper handoff → Manager corrects counts | Store Manager | Implemented |
| Department misclassification | BR-03 | Escalation → corporate re-tags to correct department | Corporate master-data | Implemented |
| No diagnosis step existed | BR-04 | Diagnose-and-route SOP; all-staff training | Floor staff / Manager | Implemented |
| No ownership of data errors | BR-05 | Ownership matrix embedded in the SOP | Store Manager | Implemented |
| No validation at setup, no audits | BR-06 | Proposed: setup validation + cycle counts / audits | Manager + Corporate | Recommended |
The sprint was an operational fix, not a controlled study. Where a KPI wasn’t formally re-measured, it is labeled as observed rather than claimed — credibility over polish.
| Metric | Baseline (real) | Target | Achieved (observed) |
|---|---|---|---|
| Daily list volume | ~250 items | ~50 (range 20–50) | ~50 items/day ✓ |
| False-positive rate | ~80% (≈200/250) | < 15% | Predominantly actionable (not formally re-measured) |
| Recurring “repeat offenders” | Chronic, daily | Near zero | Near zero observed ✓ |
| Daily labor on the list | 4–12 person-hrs | < 2 person-hrs | Reduced proportionally to volume (not formally re-measured) |
| Staff trust / actioned flags | Eroded; true flags ignored | Every flag actioned | Restored — sustained by trained SOP ✓ |
Validate bin caps and classifications at setup; run periodic cycle counts and bin-cap audits. Today’s model is detect-and-correct — without prevention, data drift (risk rated High/High) will eventually rebuild the noise.
Track list volume, false-positive rate, and empty-home incidents weekly. The problem survived a year because nobody measured it — the cheapest control is a number someone looks at.
The fix lives in people, not systems: keep diagnose-and-route in onboarding and refreshers so staff turnover doesn’t erode it.
The diagnose → route → own → prevent pattern applies to adjacent processes; next candidate: the battery inventory ordering process.