What to do after a poor ERP or WMS implementation

By Warren Stout · September 2026 · 19 years of operating leadership

When an ERP or WMS goes live and performance deteriorates, the first question I want answered is: where is the business losing control of the work?

In my operating roles, I have led through ERP conversions and sponsored warehouse management system change. That experience shapes how I approach recovery: begin with the customer, inventory, and financial consequences, then follow the evidence through the process and the system.

A missed shipment can look like a software problem while the cause sits in data, a workflow decision, an interface, a permission, or a team that was never prepared for the exception. A long issue list tells you there is friction. It does not yet tell you where to intervene.

1. Protect the flows the business cannot afford to lose.

Start with critical orders, inventory integrity, financial reconciliation, and the customer commitments at risk. Agree on who can make containment decisions and when an issue must escalate. If a temporary workaround is necessary, give it an owner, a reconciliation control, and an expiry review.

Containment buys the team room to diagnose. It should not quietly become the permanent operating model.

2. Trace representative failures from beginning to end.

Choose a small set of failed transactions that represent the largest operational consequences. Follow an order from entry through allocation, picking, shipping, and the financial handoff. At each step, compare what should have happened with the actual record and the work performed.

For example, a “short shipment” might start with an incorrect unit of measure, an allocation rule, a failed interface message, a missed shipment acknowledgment, or inventory that was never where the system said it was. Those are different problems with different owners and fixes.

3. Separate the causes before assigning the work.

I want the recovery team to distinguish at least six categories:

• Process: the future workflow or exception path is incomplete.
• Data: items, locations, units, balances, or ownership are unreliable.
• Configuration: system rules do not match the approved business requirements.
• Integration: messages fail, duplicate, arrive late, or lose necessary context.
• Adoption: people lack the training, access, or practice required for the work.
• Governance: decisions, controls, and escalation responsibilities are unclear.

More than one category can contribute to the same failure. The point is to make the explanation testable.

4. Create one recovery backlog that the business can use.

Every priority issue needs an observed symptom, supporting evidence, business impact, accountable owner, dependencies, and acceptance criteria. “Fix inventory” is not a work item. “Reconcile a defined transaction population, explain the variance, and demonstrate the corrected flow” can be.

Review the backlog with operating leadership, IT, finance, and the implementation partner. Decide what must happen next and what can wait. Parallel lists and conflicting priorities consume the capacity needed for recovery.

5. Prove a fix with the exception, not only the happy path.

A normal order passing a test is useful. It does not establish that the process can handle a partial shipment, cancellation, return, damaged unit, or another important exception. Use representative business scenarios and check downstream inventory and financial effects before scaling a change.

The acceptance test should connect to the original failure. Close the issue when the evidence supports closure, rather than when someone has finished a task.

6. Put operating leaders into the recovery cadence.

A system recovery is also a leadership task. The team needs visible decisions, realistic priorities, and a way to tell the truth about readiness. Short daily reviews can handle containment and blockers; a separate leadership review can resolve scope, resources, and cross-functional decisions.

Protect time for training and observation in the actual workflow. A technically correct process that the team cannot execute consistently is still an operating problem.

7. Define the exit from recovery.

Agree on the operating measures and control conditions that must hold before leaving intensive support. Depending on the scope, these may include service performance, reconciliation quality, exception rates, backlog age, workaround retirement, and demonstrated process ownership.

A new dashboard or a shorter issue list is not sufficient evidence by itself. I want to know whether the operation can sustain the result, who owns the next exception, and whether leadership will see deterioration early.

What I would ask for in the first review

• The original business objectives and critical workflow requirements
• Performance before and after go-live, with definitions and time periods
• A current issue register and several representative failed transactions
• Data, integration, testing, and cutover decisions that explain the current state
• The people who own the work, the system, and the downstream reconciliations

Those inputs help distinguish a bounded recovery from a deeper operating redesign. They also make any decision to repair, reconfigure, or replace the system more defensible.