ERP Rescue Consultant, USA

Signs a US project needs rescue, not more time

Every ERP project has bad weeks. A rescue is warranted when the pattern no longer improves with effort and the business is paying for it in cash or in operational risk. The signals tend to look like this:

• A time-and-materials engagement has passed its not-to-exceed figure and each status report asks for another extension.
• Go-live keeps slipping, and each new target arrives without a list of what has to be true to hit it.
• User acceptance testing keeps uncovering missing processes rather than ordinary defects.
• The system is live, but month-end takes far longer than before, sales tax returns are prepared outside it and the warehouse ships from printed pick lists.
• Staff have drifted back to QuickBooks, the old system or spreadsheets because the new one cannot be trusted.
• The partner's senior consultants have rotated off and the remaining team is learning your business from scratch.

Any one of these can be fixed inside a normal project. Several together mean the plan, the scope or the relationship has broken, and adding more hours will not repair it. At that point an independent view is cheaper than another quarter of drift. My page on how to fix a failed ERP implementation describes the problem side in more depth, and the ERP recovery service page explains the general method.

Establishing the facts without assigning blame

Troubled projects generate competing stories. The business says the partner never understood its processes. The partner says decisions arrived late, data was delivered dirty and scope kept growing. Both accounts usually contain some truth, and arguing about them wastes the time the project needs.

I build a fact base instead. Sponsors, process owners, key users, your internal project lead and the partner's team are interviewed separately, so each can speak openly. I read whatever paperwork exists, from requirements and designs to the plan, change requests, UAT results and open defects. Then I test the system directly: which end-to-end processes actually run, how far data migration has progressed and which integrations work under real volumes.

Everything is laid out in three columns: what was contracted, what was built and what the business needs to operate. Gaps between the columns are classified as missing requirements, build defects, data problems, training issues or genuine platform limits. That classification decides who should fix each item and how.

The readout is written in plain English and shared with both your leadership and the partner. It describes what happened without naming villains, which is what makes a reset possible. If you only need an outside view before deciding anything, an independent ERP second opinion is the lighter version of this step.

Reading the SOW, change orders and invoices

US implementation agreements are often split across a master services agreement, a statement of work and a stack of change orders, with software subscriptions on a separate contract. When a project goes wrong, the gaps between those documents become the argument. I am not a lawyer and this is not legal advice; the aim is to give your attorney an organized, factual picture to work from.

I prepare a schedule that sets each deliverable in the SOW against its status, the change orders that altered it and the invoices that billed for it. Alongside it sit the questions your attorney will want answered:

• Is the engagement fixed fee, time and materials, or a mix, and what happens at the cap?
• What were the stated assumptions and client responsibilities, and were they met on both sides?
• How is acceptance defined, and has anything been formally accepted?
• What warranty or defect-fix period applies after go-live?
• Who owns custom scripts, reports and integrations, and can you get the source and documentation?
• What transition assistance must the partner provide if the engagement ends?

The goal is a commercial settlement of the issues, not a lawsuit. A clear schedule usually makes the commercial conversation shorter and calmer, because both sides are looking at the same facts.

Keeping month-end, sales tax and payroll running

While the recovery is planned, the business still has to close the books, file sales tax returns, pay people and report to lenders. A struggling system puts all of that at risk, so stabilization comes before any redesign.

The interim arrangements are agreed with your controller and CPA and written down, so nobody improvises under pressure:

• A temporary close checklist that lists every manual step, workaround spreadsheet and reconciliation needed until the system is fixed.
• A method for preparing sales tax returns from the data you trust, reviewed by your tax advisor, with a note of any filings they may want to revisit later.
• A check that journals from your payroll provider still post to the right accounts and departments.
• A view of which lender or investor reports depend on the troubled system, so your CFO can decide whether anyone needs to be told about delays.

Data repair runs alongside. Duplicate customers and items, wrong opening balances, inventory costed at zero and transactions posted to the wrong entity are fixed in a planned order, each followed by a reconciliation. Fixing data in random order tends to move errors around rather than remove them. The ERP data migration page covers the reload side when a clean restart of some data is the better option.

Continue, re-scope or re-platform

Once the facts are clear, the decision becomes a structured comparison rather than a mood. I set out the realistic options with their risks, dependencies and cost drivers:

• Continue with today's partner under a revised baseline, provided the product suits you and their team can and will deliver it.
• Re-scope to a smaller first release covering the processes the business cannot run without, with the rest moved to later phases.
• Change partner, when the product is sound but the working relationship or the team's skills are not.
• Re-platform, when the system genuinely cannot support core requirements and further spending would only deepen the sunk cost.

Leadership makes the call. I stay on to run the recovery governance if you want: a single plan, a weekly risk and issue review, change control and go/no-go criteria agreed before the next release date is announced. If a new partner or product is needed, the requirements and evidence from the rescue feed straight into a fresh ERP selection in the USA.

All of this runs remotely, with working sessions scheduled across Eastern to Pacific time and on-site days only by arrangement. For a live system that works but underperforms, the US ERP audit is the better starting point. For advisory work beyond recovery, start from my ERP consultant services in the USA or the US market overview.