Published July 19, 2026
1. Agree the question and boundary
Write one sentence describing the operational problem without naming a preferred solution. For example: orders repeatedly reach packing with missing portions, or received stock takes too long to become usable. Identify the facility, shifts, product groups, and period in scope. Name the business owner and the people who can explain the work. Agree what information may be collected and avoid unnecessary customer or employee data. Output: a short assessment brief that states the question, scope, participants, and intended decision.
2. Establish a baseline with known limitations
Choose a small set of measures that reflect the problem: elapsed time, incomplete work, recurring exceptions, rework, or a relevant accuracy measure. Define the source events, units, included population, and timing. Capture representative examples rather than relying only on totals. Record gaps in the data instead of disguising estimates as exact observations. The assessment should be useful even when the current reporting is imperfect. Output: a baseline table with definitions, values or observations, source references, and confidence notes.
3. Observe normal work and one difficult case
Follow the transaction through physical and system handoffs. Record who makes each decision, what information they use, and what confirms completion. Include devices, labels, staging, waiting, and informal coordination. Then observe or safely reconstruct a common exception. Ask the operator what makes recovery difficult and what they do when the expected procedure does not fit. Do not replace qualified safety procedures with an assessment shortcut. Output: a process map with the normal flow, exception path, and points where state becomes uncertain.
4. Separate symptoms from possible causes
For each issue, list plausible explanations across process, data, configuration, integration, equipment, and ownership. Identify what evidence supports or contradicts each explanation. A queue at packing might originate in release timing or missing replenishment, not packing speed. Avoid choosing the most familiar technical explanation too early. Select a representative transaction and trace it far enough to test the hypothesis. Output: an evidence log that distinguishes observed facts, working hypotheses, unanswered questions, and confirmed causes.
5. Prioritize by consequence and feasibility
Compare candidate improvements using operational exposure, recurrence, expected benefit, dependencies, effort, and the capacity of the team to absorb change. Separate immediate containment from structural correction. A small intervention may relieve pressure while a larger issue is being designed, but it needs an owner and an expiry or review point. Do not label every request urgent. Output: a prioritized backlog explaining why each item comes before or after another and what must be true before work starts.
6. Define a bounded first improvement
Choose a scope that can be tested and reviewed without pretending to solve every connected problem at once. State the intended change in behavior, acceptance evidence, responsible roles, and recovery plan. Include the affected data, devices, interfaces, and instructions. Agree what would cause the team to stop or revise the approach. Output: a first-step plan that operations and technology can both understand, with explicit assumptions and a practical verification method.
7. Review whether life on the floor improved
After the change, compare the same definitions and representative conditions used in the baseline. Ask operators and supervisors whether the difficult work is genuinely easier or merely moved elsewhere. Record remaining exceptions and unintended effects. Update the process map and ownership documentation so the improvement survives staff changes. Decide whether to extend, adjust, or stop the intervention based on the evidence. Output: a concise review linking the original problem, the action taken, observed results, and the next decision.
Use with your team
Working checklist
Checks are temporary and are not saved or submitted. Use Print / save PDF for your working copy.
Educational guidance. Apply it to your product, version, operating conditions, and agreed controls; it is not a project-specific solution design.
Explore wms consulting