The Inventory App That Would Not Fix the Mis-Picks
Northline 3PL operates a 220,000-square-foot distribution center where pickers work from printed pick sheets and supervisors re-key counts into a spreadsheet at each shift change. Mis-picks run at 11-14% of orders. The operations manager has asked a warehouse analyst with two days of Power Apps training to build an inventory app, and the analyst has already started a canvas app that mirrors the paper sheet field for field. IT's delivery queue is nine months deep and no premium licensing budget has been approved. In discovery interviews, pickers say the paper sheet itself works; bin labels are faded and two SKUs ship in near-identical packaging. Supervisors say the real pain is the shift-end re-keying, which delays the next morning's wave plan by about 90 minutes. The operations manager's stated success criterion is app live by Q3, and he has already told his regional director that the app will cut mis-picks in half.
1. Separate symptom from cause and rewrite the problem statement. What evidence should the analyst gather before another screen is built?
Read the worked answer
The request contains at least three different problems, and only one of them is a software problem.
- Mis-picks (11-14%): the stated causes are faded bin labels and look-alike packaging. An app that displays a pick list does not make a shelf label legible or change a carton's artwork. This is a labeling and slotting fix owned by operations, possibly with a scanning control added later.
- Shift-end re-keying: this is a data-flow problem. Paper capture followed by manual transcription adds no value and creates the 90-minute delay. This is the genuinely automatable slice.
- Paper-to-screen mirroring: copying a form field for field reproduces the current process rather than improving it, and locks in the transcription step the app was supposed to remove.
Evidence to collect before further build: a Pareto of mis-picks by SKU, bin and picker to test the labeling hypothesis; a short time study of the re-keying step to baseline the 90 minutes; observation of two or three full pick waves; and the count of orders affected per week by late wave plans. Each item should be expressed as a baseline number so any app can be judged against it. The output is a problem statement of the form: shift-end count transcription delays wave planning by 90 minutes per day for about X orders, and mis-picks are driven by labeling, not by capture method. That statement lets the sponsor fund the right work.
2. Define success measures and an MVP scope, including what you would deliberately defer.
Read the worked answer
Success measures should be tied to the two problems separately, because the app can only move one of them.
- Primary measure: median elapsed time from last pick to a released wave plan, targeted to drop from 90 minutes to under 15. Secondary: supervisor hours spent re-keying per week, and count of transcription corrections per week (a proxy for data quality).
- Do not promise a mis-pick reduction as the app's outcome. Attribute that to the labeling and slotting work, tracked with its own baseline of 11-14%. Reporting the two together will make the app look either falsely successful or falsely failed.
MVP scope: a mobile count-entry screen for supervisors, writing to an approved data store, with an exception flag for discrepancies and a simple supervisor view that confirms a wave can be released. That covers capture and removes transcription.
Defer: barcode scanning, WMS integration, picker-facing screens, inventory valuation logic, and any historical migration. These add cost and integration risk but do not move the primary measure.
Set an explicit exit criterion, for example: if the wave-plan delay has not fallen by at least half within six weeks of pilot, stop and re-scope. That protects the sponsor from a sunk-cost build and gives the analyst a defensible checkpoint.
3. The sponsor has publicly committed to Q3. How should the analyst handle that commitment without simply complying or refusing?
Read the worked answer
Treat the date as a stakeholder-management problem, not a scheduling one, and bring evidence rather than an objection.
Sequence: (1) run the time study first, because a measured baseline converts the conversation from opinion to arithmetic; (2) present a short options paper at the next sponsor meeting with three choices - labeling fix only, capture app only, or both in parallel with separate owners and dates; (3) state clearly which deliverable is achievable by Q3 and which is not, and what would have to be dropped to hit the date.
Also surface the constraints the sponsor may not know: no premium licensing has been approved, and the chosen data store has not been through IT architecture review. Building on an unapproved store is the kind of decision that gets an app shut down after launch, which is worse for the sponsor than a four-week slip. Ask IT for a targeted architecture review of the data store only, not a full project intake.
Record the outcome in a decision log: what was promised, to whom, on what evidence, and what is explicitly out of scope. Send it to the sponsor and the regional director. If the sponsor still insists on the original framing, escalate through the citizen development center of excellence rather than personally absorbing the risk - the mis-pick promise is the part that will fail publicly.