ERP Rescue Consultant, Germany

Symptoms of a German ERP project in difficulty

Before go-live, the warning signs are mostly organizational. Steering committee time goes on disputed change requests rather than decisions. Test cycles with key users keep producing the same defects. The system house replaces its project lead, and the new one wants to revisit agreed designs. The go-live date is moved without a plan that explains why the new date is more realistic. Management starts asking whether to stop paying invoices, and the system house starts asking for formal acceptance of completed phases.

After a difficult go-live the symptoms move into daily operations:

• Production orders run, but actual costs do not reach the right cost centers or cost units, so margins are unclear.
• Stock values differ from the last count, and nobody can say which postings caused the gap.
• The Steuerberater rejects or heavily corrects the DATEV export, and the advance VAT return is assembled outside the system.
• Incoming e-invoices pile up because the intake process was never finished.

These situations rarely have a single culprit. Requirements that were less precise than everyone thought, a specification approved too quickly, decisions that took weeks and underestimated data work usually all contributed. That is why a rescue starts with facts rather than with fault. My ERP recovery service holds the generic method; the German specifics follow.

Lastenheft, Pflichtenheft and what was actually built

Many German ERP projects follow a familiar pattern of documents. The company describes what it needs in a Lastenheft, the system house answers with a Pflichtenheft describing how it will deliver, and the contract refers to one or both. Trouble often grows in the space between them. A requirement becomes a vaguer statement in the specification, a workaround replaces a standard process, or a feature appears in neither document but everyone assumed it was included.

I build the fact base by tracing that chain. For the processes that matter most, I set each requirement next to the corresponding passage of the specification and then check what the system does today. The result shows, item by item, whether scope was delivered, delivered differently, deferred, lost or never written down. Alongside this I speak individually with management, finance, production planning, key users and the system house's project lead, and read the plan, change requests and steering committee minutes.

The written assessment that comes out of this is shared with management and the system house together. Because it is grounded in their own documents, it is hard to dismiss as one side's opinion, and it usually shifts discussions from who is right to what should happen next. If there is no Lastenheft at all, the trace uses whatever requirements, workshop notes and emails exist, and the missing baseline becomes a finding in itself.

Steadying the advisor export and the advance VAT return

The company's obligations do not wait for the project to be repaired. Bookings have to reach the Steuerberater, the advance VAT return has to be filed, and month-end figures are still expected by management and lenders. In a rescue these come first, ahead of any discussion about scope.

I sit down, remotely, with your finance lead and the Steuerberater to agree a temporary routine. Which system holds which postings for the current period? How are documents entered twice prevented from reaching the advisor twice? How is the VAT return checked before submission while the tax key mapping is being corrected? The routine is documented, with a named person for each step and a condition for retiring it, and your procedure documentation is noted for an update once things settle.

The export itself is repaired at the cause: account mapping, tax keys, cost centers and the level of detail the advisor needs. A trial file is imported by the advisor and the differences are worked through until a period transfers without manual correction. Data repairs run in parallel, prioritized by business effect: open items needed for payment matching and dunning, item and bill of materials data needed for costing, and stock positions that must agree with the warehouse. Treatment of any correction to earlier returns is the advisor's call. My go-live support page covers the stabilization checklist used once the immediate pressure eases.

Formal acceptance, contract type and your lawyer

In German ERP projects the formal acceptance of a phase or of the whole system often carries real legal and commercial weight. It can trigger payments, start warranty periods and change who must prove what if defects appear later. In a troubled project, the system house may push for acceptance while the company is unsure what it would be accepting.

I do not advise on whether to accept. I provide what your lawyer needs to advise you: a factual status of each deliverable against the contract and specification, a list of open defects ranked by business impact, and the evidence behind each. Whether the contract is structured more as a contract for a defined result or as a contract for services also affects the position, and that classification is purely a question for your lawyer.

I also go through the contract, change requests and order confirmations and list the practical points worth raising: payment stages linked to milestones, rights of use to custom developments and source code, documentation the system house must deliver, and support in handing over to another partner if it comes to that. With those points clear, the reset discussion with the system house can be held on a realistic basis. A structured reset is usually in the system house's interest too, and the trace of requirements, specification and delivery gives both sides a shared starting point.

Works council, staff and the decision on direction

Recovery plans change things for people. A reduced scope might mean departments keep a legacy tool longer; a new rollout sequence might bring shop floor terminals or new reports forward; a change of platform might mean a new system altogether. If a Betriebsvereinbarung governs the ERP, some of these changes may need to be discussed with the Betriebsrat. I identify which elements of each option touch roles, activity logging or performance reporting, and HR and management decide with their advisors how to involve the council.

The decision itself comes down to a small set of options. Continuing with the same platform and system house under a reset plan suits projects whose product fits and whose trouble lay in specification and governance. Reducing scope suits projects that tried to do too much: finance, sales and purchasing stabilized first, with advanced planning, a second plant or deeper controlling later. Changing system house or platform is sometimes justified, but deserves its own comparison rather than a decision taken in frustration.

Every option comes with a plain account of its effect on production, finance, staff and the works council, and what will drive further spending, without inventing figures. Management decides, and I can then steer the recovery remotely with your team. Where the ERP runs reliably but under its potential, the ERP audit for Germany is the better fit. See also my implementation page for Germany, the failed implementation guide and the Germany overview.