ERP Rescue Consultant, Switzerland

The first two weeks: stop the drift and gather facts

When a project is in trouble, every party is busy defending a position, and new change requests keep arriving because nobody has the authority to say stop. My first step is a short freeze on anything that is not needed to keep the business running or to understand the problem. Configuration changes, new reports and extra interfaces wait.

Then I build the fact base. I read the contract and statement of work against the requirements, the project plan against the change log, and the test results against the issue list. I talk separately with the sponsor, the finance lead, key users in sales and logistics, and the integrator's project manager, because people speak more freely one at a time. I also look at the system itself: what has been configured, which end-to-end flows work and how far data migration has really progressed.

The output is a written status in plain English: what works, what does not, which problems are causes and which are symptoms, and where the parties simply understood the scope differently. It is shared with both the company and the integrator, which tends to calm the conversation. The general approach behind this step is described under ERP recovery and in my independent second opinion offer.

Keeping invoicing, payments and the VAT period under control

If the system is already live, operations come before analysis. In a Swiss company the pressure points are predictable, so I check them in a fixed order:

1. Customer invoices leave on time, with a QR-bill and a reference that lets payments match automatically.
2. Payment files are accepted by each bank you use, and rejected runs are visible to someone who can act on them.
3. Bank statements import and match, so receivables reflect what customers have actually paid.
4. Stock movements are posted in time for the warehouse and sales teams to trust availability.
5. Foreign currency balances are revalued under the same rule each period.

Where a flow cannot be fixed within days, we agree a documented fallback with an owner and an end date, rather than letting each employee invent one.

The VAT period needs its own plan. Your fiduciary or tax advisor decides how errors from the troubled months are corrected and reported; I help prepare the evidence, show which system holds reliable figures for each period and make sure the corrections are traceable in the ledger. Payroll journals from your external provider are reconciled before the month is closed. The aim is one clean period close, because that is what restores trust in the numbers.

Working with the integrator, or preparing a handover

Most stalled projects are a joint product. Requirements were thinner than assumed, decisions on the company side came late, and the integrator accepted changes without resetting the plan. Treating the rescue as a contest makes recovery slower, so I keep it on facts.

The reset workshop works through every open item and places it in one of four groups: needed for operations, can follow later, no longer needed, or disputed. For disputed items we go back to what the contract and signed requirements actually say. The result is a revised plan with named owners on both sides, acceptance criteria per item and a weekly checkpoint.

Sometimes the evidence shows that the relationship cannot continue. Then the job is a controlled handover: documentation of the configuration, ownership of extensions and partner apps, administrator credentials, open defects and test material, all collected before the new integrator starts. Contract matters such as acceptance clauses, notice periods, rights to custom code and any withheld payments are for your lawyer; I prepare a factual timeline and a scope comparison they can use. I do not advise on Swiss contract law.

If a new integrator has to be found, the earlier requirements are reused and tightened, following the method on my Swiss ERP selection page.

Continue, re-scope or re-platform: making the call

The board eventually needs one decision, and it should not be taken while everyone is exhausted. I prepare a short paper that sets the options side by side:

Each option lists what can be reused, from cleaned master data to test scripts and process maps, and the cost drivers that matter, without invented figures. Re-platforming is the right answer less often than frustrated teams expect, but when the evidence points there I say so.

Swiss specifics feed into the paper: whether the localization covers your VAT and banking needs, whether multilingual documents are realistic on the current platform, and whether the old package can stay readable for records you must keep.

Running the recovery remotely with Swiss teams

A recovery needs a steady rhythm more than heroics. I run a weekly working session with the integrator, a steering checkpoint with the sponsor and a single log of decisions, risks and changes. Sessions sit in the Swiss morning and early afternoon, which overlap with my working day in India, and written updates carry the work between calls.

Parallel running deserves an honest discussion. Keeping the old package alive feels safe, but double entry exhausts finance staff and produces two sets of numbers. I help you decide which processes, if any, should run in both systems, for how long and who reconciles them.

Users in different language regions also need clear communication about what is changing and when; your key users or the integrator write those messages in German, French or Italian.

Before a new go-live date is set, the recovered system goes through fresh end-to-end testing with real bank files, QR-bills and VAT scenarios agreed with your fiduciary, and a go/no-go meeting based on written criteria. The detail sits under ERP go-live support. Once stable, a structured Swiss ERP audit can confirm what still needs attention. For projects not yet in trouble, see client-side implementation oversight, and for the wider picture, the Switzerland hub.