A warehouse audit before ERP: investigate goods, data and waiting time

1. Define the question and the boundaries

Start with a question you can investigate, not a WMS feature list. “Orders take too long to pick” is broad. A more useful question is where waiting occurs between confirmation and readiness for packing, and what triggers it. Why physical stock differs from recorded stock is another question. They may concern the same warehouse but require different evidence.

Choose a flow: online orders, store replenishment or transfers from your own production. State its start, end, locations, shifts and product types. Do not combine simple orders with multi-line orders or sale-ready products with goods awaiting quality inspection without distinguishing them. These differences can explain timing and availability without implying a process failure.

Agree that the first stage will deliver a flow map, an evidence-backed issue log and a bounded pilot proposal. Redesigning storage, changing accounting records and buying equipment should not automatically follow from the opening conversation. Refer safety and mandatory-control questions to the appropriate specialists; do not remove those controls merely by labelling them waste.

2. Assemble a minimal evidence pack

Request a zone map, role list, sample movement documents, item master and a description of exchanges between the shop, CRM and ERP. For each dataset, record its system, period, timezone and field definitions. A “date” column could mean order creation, document posting or physical movement. Comparing timestamps without understanding them produces misleading conclusions.

Do not export the whole customer database to investigate warehouse work. Technical identifiers, items, quantities, statuses and timestamps are usually more relevant than personal contact information. Agree access, storage and retention. Working copies should be available only to the people involved in the investigation.

Identify events the system does not record. If picking start time is based only on someone’s recollection, do not present it as an exact system timestamp. Add temporary observation or document the limitation. Missing data does not by itself demonstrate poor team performance. It tells you which questions cannot yet be answered reliably.

• Orders: identifier, lines, status events and cancellations.
• Movements: item, unit, quantity, source, destination, time and supporting record.
• Stock: physical, reserved and available quantities, with a definition for each.
• Exchange: which system emits an event, where it goes and where errors appear.

3. Follow the goods with the people doing the work

The Lean Enterprise Institute describes a gemba walk as understanding the situation through direct observation and inquiry before making changes. Here that means following a selected flow end to end, not only looking at shelves with a manager. The investigation sequence below is Routio’s practical proposal.

Trace a particular order: how it becomes visible to the warehouse, who takes ownership, where they look for goods, what happens when an item is absent and when packing starts. Separately follow the corresponding system records. Goods may already be moving while the status remains unchanged, or a document may be posted before the physical action.

Record searching, movement, waiting, repeated entry and returns to earlier steps. Ask what problem each check prevents. Do not rearrange shelving or alter routes during the walk; those changes need separate assessment and approval. Finish by checking your observations with the operator so an exceptional workaround is not mistaken for the normal process.

4. Select cases that expose different conditions

Include completed and open orders, simple and multi-line orders, normal and urgent work, and cases with and without exceptions. Include different shifts or time windows where the operating pattern differs. Selecting only the worst cases is useful for investigating failures but cannot establish typical warehouse speed.

Build an observation log with one order reference and its individual events. Capture the start of waiting, start of work, interruptions, restarts and completion. Label the time source: system log, direct observation or participant explanation. If something happened before the investigation and no reliable record exists, leave the time unknown rather than estimating false precision.

Choose the number of cases according to the purpose and diversity of the flow. A small purposive sample helps generate hypotheses; it is not statistical evidence of how often problems occur. Performance standards or conclusions about the entire warehouse need a separate measurement plan and enough comparable observations. Keep that limitation visible in the report and any presentation.

5. Separate activity intervals from waiting

Illustrative numbers, not a customer result: an order is confirmed at 10:00, picking begins at 10:35 and ends at 10:47, and packing starts at 11:10. Seventy minutes pass before packing begins: thirty-five before picking, twelve during the picking interval and twenty-three between picking and packing.

Those twelve minutes are not necessarily pure hands-on work. Searching or an interruption might be included. Without closer observation, call the measure a picking interval. Likewise, thirty-five minutes of waiting does not prove understaffing. A wave-release rule, an invisible task or incomplete information could explain the delay.

Form a hypothesis that evidence could disprove. For example: some confirmed orders do not enter the work list until a manual refresh. Check when they appear and compare integration events. Do not multiply one slow example by all monthly orders and call the result guaranteed savings. First establish how often the condition occurs and whether removing it would actually release usable capacity.

6. Compare stock using matching coordinates

Before comparing quantities, align item, variant, unit, location, condition and time. For clothing, different sizes of one style are not interchangeable units. A carton containing ten garments and ten individual garments can represent the same quantity, but only with a confirmed packaging conversion. Do not casually edit the item master while reconciling observations.

Establish a reference point in time. A count taken before a shipment and a report generated afterward may differ because of that movement. Agree how movements in the counting area will be controlled with the warehouse manager; do not stop operations on your own initiative. Reconcile known receipts, transfers and departures between the two moments.

ERPNext documents Stock Reconciliation as an operation for reconciling recorded and actual stock. Adjusting a quantity, however, does not explain its discrepancy. Preserve evidence and inspect movement history first. Agree corrections with warehouse and accounting owners. This guide is not an instruction to bulk-edit production records, and a successful quantity adjustment should not be treated as proof that the underlying cause has been resolved.

7. Investigate reservations, returns and unavailable goods

Physical stock and stock available to a new order answer different questions. Goods can be physically present but reserved, awaiting inspection or pending a returns decision. Ask the team to explain the availability formula in each system. Do not assume that a field labelled “stock” means the same thing in the CRM, ERP and storefront.

Trace one reservation from creation to release: confirmation, partial shipment, cancellation and item replacement. Who releases the quantity? Can the integration handle a repeated event without generating a duplicate movement? What does a sales operator see when exchange is delayed? Test approved scenarios in a test environment rather than randomly cancelling real customer orders.

For in-house production, completion, warehouse receipt, inspection and release into available stock may be separate events. For returns, identification, condition and disposition matter. The mere physical presence of a garment does not justify automatically making it available for resale. Check whether temporary physical areas have corresponding system states and a named owner for clearing outstanding decisions.

8. Turn observations into an issue log

Each issue needs a symptom, evidence reference, observation scope, consequence, hypothesis and next check. “We need a WMS” is not a problem statement; it is a possible solution. Write instead that operators searched for actual locations in the selected orders because the directory showed only a broad zone.

Separate confirmed observations from untested explanations. Seeing three search episodes establishes that the issue occurred in those episodes. Estimating its prevalence requires more evidence. Test “incorrect location data” against the recorded address, actual position and last movement time. The address may be correct but the latest movement may not yet have been entered.

Prioritize using customer impact, quality and safety, demonstrated recurrence and the effort needed to test a remedy. Do not conceal uncertainty behind a precise-looking score or savings total. A high-risk issue may require immediate, agreed containment before the root-cause investigation is complete. Record who approved that containment and what conditions allow it to end.

9. Choose between a rule, configuration, integration and WMS

If people disagree about when reservations should happen, start with a common rule and ownership. If the rule exists but the necessary field or status is not configured, investigate the current system. If a required event disappears between applications, examine integration identifiers, retries, errors and recovery. None of these automatically requires replacing the platform.

Evaluate a dedicated WMS or an ERP extension against demonstrated requirements: location detail, scanning, picking rules, batch handling or other needs of your flow. Ask for your own demonstration scenario, including an exception, rather than relying only on a standard presentation. Establish who will maintain master data, equipment and exchanges after launch.

The decision includes data preparation, configuration, training, a pilot, support and transition planning, not just a subscription. If a requirement comes from neither observed work nor an agreed business development plan, label it an assumption. This keeps the project from accumulating attractive features with no clear operational outcome or acceptance test.

10. Test the change in a bounded pilot

Choose one zone, product group or agreed order flow. Record the hypothesis, participants, duration, required data and stopping conditions. Checking a location before releasing a task might reduce searching while adding work upstream. Measure both sides rather than only the part you hope to improve. Include the person receiving the new workload when agreeing the experiment.

Before starting, agree acceptance criteria: orders are not lost, quantities and locations remain traceable, exceptions have owners and quality does not deteriorate. Set numerical thresholds with the business after baseline measurements. A universal promise of thirty percent less time without your data is not an acceptance criterion.

Compare similar orders, line counts and shift workloads. Look at long waits and unfinished cases as well as averages. Recovery must account for transactions already completed during the pilot; restoring an old copy can lose new movements. Verify the technical recovery procedure with its owners before launch and define who can authorize a stop.

11. Hand over evidence and schedule a follow-up

A finished audit is more than a presentation. Deliver an agreed flow map, metric definitions, an issue log with evidence and a decision list with owners. Distinguish confirmed findings from hypotheses that remain untested. Every next action needs an outcome, responsible person and review date rather than a vague instruction to improve the warehouse.

Update procedures if the pilot is accepted. Train the regular operators and their cover, demonstrating both the normal path and an exception. Explain where failures appear and who receives them. After an agreed interval, check that the new method is actually used and has not created hidden manual work for another team.

Use the structure below for a first independent review. It is an investigation plan, not a promise to audit any warehouse in one day. Where data or access is missing, document the limitation and the next safe check. A clear unresolved question is more useful than a confident recommendation built on an assumption.

• Before the walk: one question, flow boundaries, participants and permitted data.
• During observation: goods, records, handovers, waiting and exceptions.
• After the walk: validate observations with operators and maintain a hypothesis log.
• Before change: owner, acceptance criteria, risks and recovery procedure.
• After the pilot: evidence-based decision, revised SOP and follow-up date.