Implementierungspartner prüfen: ERP-Projekt absichern

Serie „ERP-Entscheidungssicherheit“, Artikel 3 von 3

Was passiert, wenn der ERP-Vertrag unterschrieben ist?

Mit der Unterschrift endet die Auswahlphase und beginnt die Umsetzung. In diesem Moment gibt der Käufer seine stärkste Verhandlungsposition ab. Vor der Unterschrift konkurrierten mehrere Anbieter um den Auftrag. Nach der Unterschrift gibt es nur noch einen Partner, und ein Wechsel würde bereits investierte Zeit und Budget entwerten. Die Machtverhältnisse drehen sich innerhalb eines Tages.

Warum das Umsetzungsteam selten das Vertriebsteam ist

Implementierungspartner setzen in der Angebotsphase ihre erfahrensten Köpfe ein. Diese Personen überzeugen im Pitch, klären kritische Fachfragen und schaffen Vertrauen. Nach Vertragsabschluss werden dieselben Personen für den nächsten Vertriebsprozess benötigt. In das Projekt rückt ein anderes Team nach, oft mit geringerer Erfahrung und mit Parallelauslastung in weiteren Projekten.

Dieser Wechsel ist branchenüblich und nicht per se unredlich. Problematisch wird der Wechsel dann, wenn er nicht angekündigt wird und wenn niemand auf Kundenseite ihn bemerkt. Die Zusagen aus der Angebotsphase bleiben im Vertrag stehen. Die Menschen, die sie einlösen sollten, sind nicht mehr im Raum.

Warum die eigene Projektorganisation den Wechsel oft nicht bemerkt

Ein mittelständisches Unternehmen führt ein ERP-System alle zehn bis fünfzehn Jahre ein. Der interne Projektleiter hat in der Regel keinen Vergleichsmaßstab. Er kann nicht einschätzen, ob ein Rückstand von drei Wochen im vierten Projektmonat normal oder alarmierend ist. Der Implementierungspartner hat diesen Vergleichsmaßstab, teilt ihn aber nicht.

Warum laufen ERP-Projekte nach der Unterschrift aus dem Ruder?

ERP-Projekte geraten nach Vertragsabschluss selten aus technischen Gründen in Schieflage. Die häufigere Ursache ist eine strukturelle Anreizasymmetrie: Der Implementierungspartner wird für erbrachte Leistung vergütet, nicht für die Genauigkeit seiner ursprünglichen Prognose. Eine zu niedrige Aufwandsschätzung schadet ihm in der Angebotsphase nicht, sondern hilft ihm.

Change Requests als zweites Ertragsmodell

Ein Change Request ist eine nachträgliche Beauftragung von Leistungen, die im ursprünglichen Angebot nicht enthalten waren. Viele Implementierungspartner kalkulieren das Erstangebot knapp, um den Zuschlag zu erhalten. Die Marge entsteht anschließend über Nachträge, die zu Tagessätzen ohne Wettbewerbsdruck abgerechnet werden. Der Kunde kann zu diesem Zeitpunkt nicht mehr wechseln.

Auch hier gilt: Der Mechanismus ist strukturell, nicht persönlich. Ein integrer Partner gerät in dieselbe Anreizlage. Wer Nachträge nicht misst, wird sie nicht steuern.

Warum die Anreizasymmetrie nach der Unterschrift nicht verschwindet

Vor der Unterschrift erstellt der Anbieter die Unterlagen, auf die der Käufer seine Entscheidung stützt. Nach der Unterschrift erstellt derselbe Anbieter die Statusberichte, auf die der Käufer seine Steuerung stützt. Die Informationsquelle bleibt dieselbe Partei, deren wirtschaftliches Interesse von einer optimistischen Darstellung profitiert. Eine unabhängige Zweitsicht auf denselben Sachverhalt schließt diese Lücke.

Wie wir diese Herausforderung gelöst haben

Dreher Consulting begleitet ERP-Projekte in der Umsetzungsphase als unabhängige Instanz neben Kunde und Implementierungspartner. Zwei Projektbeispiele zeigen, worauf es dabei praktisch ankommt und wo wir selbst zunächst falsch lagen. Beide Beispiele sind anonymisiert.

Beide Praxisfälle folgen demselben Muster

Praxisfall 1: Ein Großhändler bemerkte den Teamwechsel erst nach vier Monaten

Ein technischer Großhändler stellte fest, dass sein ERP-Projekt im vierten Monat spürbar hinter dem Plan lag. Die Ursache war nicht die, die alle Beteiligten vermuteten. Der folgende Ablauf zeigt, was wir vorgefunden, getan und dabei zunächst falsch eingeschätzt haben.

1. Ausgangslage. Technischer Großhandel, rund 350 Mitarbeiter, vier Standorte in Deutschland und Österreich. ERP-Einführung mit einem regionalen Systemhaus. Im vierten Projektmonat lag der Zeitplan rund drei Wochen zurück, und das Umsetzungsbudget wurde schneller verbraucht, als es der Plan für diese Projektphase vorsah.

2. Was wir vorgefunden haben. Der Lösungsarchitekt aus der Angebotsphase tauchte in den Protokollen seit Woche sechs nicht mehr auf. Sein Nachfolger war fachlich qualifiziert, arbeitete jedoch parallel in zwei weiteren Projekten. Die Zeitbuchungen wiesen deutlich weniger Wochenstunden aus als die im Angebot zugesagte Kapazität.

3. Was wir konkret getan haben. Abgleich der namentlichen Teambesetzung aus dem Angebot mit den tatsächlichen Zeitbuchungen der ersten sechzehn Wochen. Auswertung sämtlicher Change Requests nach Auslöser. Einführung eines monatlichen Steuerungstermins mit sieben festen Kennzahlen. Nachverhandlung der Teambesetzung auf Grundlage der vertraglich zugesagten Kapazität.

4. Was dabei herausgekommen ist. Der Kunde erhielt eine Faktenlage, auf der er steuern konnte. Die Teambesetzung wurde gegen die vertraglich zugesagte Kapazität nachverhandelt. Jeder bisherige Nachtrag wurde einer Ursache zugeordnet. Von diesem Zeitpunkt an wurde das Projekt monatlich an sieben festen Kennzahlen gemessen, unabhängig vom Statusbericht des Partners — die nächste Abweichung war damit für den Kunden sichtbar, bevor sie in einem Statustermin auftauchte.

5. Was wir zunächst falsch eingeschätzt haben. Wir hielten den Rückstand anfangs für ein reines Kapazitätsproblem des Implementierungspartners. Die Auswertung der Change Requests nach Auslöser zeigte ein anderes Bild. Ein erheblicher Teil der Nachträge entstand, weil auf Kundenseite Entscheidungen über Prozessvarianten offen geblieben waren. Der Partner hatte den Rückstand nicht allein verursacht.

6. Was wir daraus geändert haben. Seitdem trennen wir Change Requests in der Projektbegleitung konsequent nach Auslöser: Anbieterseite, Kundenseite, gemeinsame Unklarheit. Diese Trennung verändert das Gespräch mit dem Partner. Sie nimmt der Diskussion die Schuldfrage und macht sie steuerbar.

Praxisfall 2: Ein Medizintechnikhersteller wollte den Nutzen nach dem Go-live belegen

Ein Medizintechnikhersteller sollte dem Beirat sechs Monate nach dem Go-live nachweisen, ob der Business Case eingetreten war. Die Aufgabe erwies sich als schwieriger als erwartet, allerdings aus einem anderen Grund als angenommen.

1. Ausgangslage. Hersteller von Medizintechnik, rund 400 Mitarbeiter, überwiegend Exportgeschäft. Das ERP-System war sechs Monate zuvor produktiv gegangen. Der Beirat forderte einen belastbaren Nachweis über die im Business Case zugesagten Effekte.

2. Was wir vorgefunden haben. Der Business Case nannte drei Nutzenversprechen. Für keines dieser drei Versprechen existierten dokumentierte Ausgangswerte aus der Zeit vor dem Go-live. Die entsprechenden Kennzahlen wurden erst nach der Produktivsetzung erstmals erhoben. Ein Vorher-Nachher-Vergleich war auf dieser Grundlage nicht möglich.

3. Was wir konkret getan haben. Rekonstruktion der Ausgangswerte aus dem Altsystem und aus Buchhaltungsdaten der zwölf Monate vor dem Go-live. Definition von fünf messbaren Kennzahlen mit eindeutiger Berechnungslogik. Aufbau einer Nutzenbilanz im Quartalsrhythmus. Trennung der Effekte nach Ursache.

4. Was dabei herausgekommen ist. Der Beirat erhielt eine Nutzenbilanz, die kritischen Nachfragen standhielt. Die Ausgangswerte wurden aus dem Altsystem und der Buchhaltung der zwölf Monate vor dem Go-live rekonstruiert. Fünf Kennzahlen wurden mit eindeutiger Berechnungslogik definiert, im Quartalsrhythmus gemessen und die Effekte nach Ursache getrennt. Zwei der drei ursprünglichen Nutzenversprechen ließen sich auf dieser Grundlage belegen; das dritte nicht — es wurde als unbelegt berichtet und nicht stillschweigend fallen gelassen.

5. Was wir zunächst falsch eingeschätzt haben. Wir hielten die Rekonstruktion der Ausgangswerte für den schwierigen Teil der Aufgabe. Schwieriger war die Zurechnung. Zwei der drei Verbesserungen ließen sich teilweise auf eine parallele Personalaufstockung im Innendienst zurückführen. Ohne diese Trennung wäre die Nutzenbilanz zu positiv ausgefallen und beim ersten kritischen Nachfragen im Beirat auseinandergefallen.

6. Was wir daraus geändert haben. Ausgangswerte erheben wir heute vor dem Go-live, als festen Bestandteil der Projektbegleitung. Eine Nutzenbewertung, die erst nach der Produktivsetzung beginnt, ist keine Messung, sondern eine Schätzung.

Wie prüfen wir die Lieferfähigkeit eines Implementierungspartners?

Die Prüfung der Lieferfähigkeit folgt bei Dreher Consulting einem wiederholbaren Ablauf aus sechs Schritten. Der Ablauf setzt nach Vertragsabschluss ein und endet mit der Nutzenbilanz nach dem Go-live. Alle sechs Schritte erzeugen schriftliche Ergebnisse, die beim Kunden verbleiben.

Die Schritte 3 bis 6 gehören zu den Bausteinen Projektbegleitung und Nutzenbewertung des Modells ERP-Entscheidungssicherheit.

Sieben Prüffragen: Läuft Ihr ERP-Projekt noch im Plan?

Die folgenden sieben Fragen lassen sich ohne externe Unterstützung beantworten. Wenn Sie drei oder mehr Fragen nicht eindeutig beantworten können, fehlt Ihnen die Informationsbasis für eine belastbare Projektsteuerung. Die Fragen zielen auf Frühindikatoren, die typischerweise mehrere Monate vor einer Eskalation sichtbar werden.

1. Sind die im Angebot namentlich genannten Berater tatsächlich im Projekt tätig, und mit welchem wöchentlichen Zeitanteil?
2. Wie hoch ist der Anteil aller bisherigen Change Requests am ursprünglichen Auftragsvolumen?
3. Verschieben sich Ihre Meilensteine, oder bleibt das Datum stehen und der zugehörige Leistungsumfang schrumpft?
4. Wie lange bleiben offene Fachfragen im Status „in Klärung“, bevor eine Entscheidung fällt?
5. Beantwortet der Implementierungspartner Fachfragen zum Prozess, oder beantwortet Ihr eigenes Team sie für den Partner?
6. Liegen die Testfälle schriftlich vor, bevor der Test beginnt, oder entstehen die Testfälle während des Tests?
7. Existieren dokumentierte Ausgangswerte für jedes Nutzenversprechen aus Ihrem Business Case, gemessen vor dem Go-live?

Frage sieben ist die folgenreichste. Wer die Ausgangswerte nicht vor dem Go-live erhebt, kann den Projektnutzen später nicht belegen, sondern nur behaupten.

Was leisten Software und KI in der Projektkontrolle, und was nicht?

Auswertbare Projektdaten liegen in der Umsetzungsphase reichlich vor: Zeitbuchungen, Ticketverläufe, Change-Request-Historien, Testprotokolle. Software erkennt darin Muster schneller und vollständiger als jeder Mensch. Dreher Consulting nutzt dafür unter anderem das eigene Modell SCOReX®. Die Auswertung liefert Hinweise, keine Entscheidungen.

Nicht automatisierbar bleibt die Einschätzung, ob ein Projektleiter überlastet oder überfordert ist. Nicht automatisierbar bleibt die Gewichtung widersprüchlicher Ziele, etwa zwischen Termintreue und Prozessqualität. Nicht automatisierbar bleibt die Verantwortung für die Empfehlung, ein Projekt anzuhalten.

Wir automatisieren nicht das Urteil des Beraters. Wir verbessern die Informationsbasis, auf der belastbare Managemententscheidungen getroffen werden.

Wo dieses Vorgehen an Grenzen stößt

Projektbegleitung und Nutzenbewertung wirken nicht in jeder Konstellation gleich gut. Vier Einschränkungen benennen wir vor Projektbeginn, weil sie den erreichbaren Effekt begrenzen. Wer diese Grenzen kennt, kann realistisch entscheiden, ob externe Begleitung sich lohnt.

• Ohne vertragliche Handhabe bleibt Kontrolle folgenlos. Enthält der Vertrag keine Stage-Gates, keine Abnahmekriterien und keine Ausstiegsoptionen, lässt sich ein Fehlverlauf zwar messen, aber kaum korrigieren. Projektkontrolle ersetzt keine Vertragsgestaltung.
• Fehlende Ausgangswerte lassen sich nur teilweise rekonstruieren. Je länger der Go-live zurückliegt, desto ungenauer wird die Rekonstruktion aus Altdaten.
• Fehlende interne Kapazität lässt sich nicht extern ersetzen. Wenn die eigene Fachabteilung keine Zeit für Mitwirkung hat, verschiebt externe Begleitung das Problem, statt es zu lösen.
• Unterhalb einer bestimmten Projektgröße steht der Aufwand nicht im Verhältnis. Der praktische Schwellenwert ist keine Budgetgröße, sondern eine Personalfrage: Wo das Unternehmen keinen eigenen Projektleiter benennen kann, hat externe Begleitung niemanden, dem sie ihre Befunde übergeben kann. In dieser Lage empfehlen wir begleitende Projektleitung statt Projektkontrolle.

Wie wir vergütet werden

Dreher Consulting wird ausschließlich vom Auftraggeber vergütet, auf Basis vereinbarter Beratungsleistung. Wir erhalten keine Provisionen von ERP-Anbietern, Systemhäusern oder Implementierungspartnern. Wir erzielen keine Umsätze aus der Implementierung der Systeme, die wir bewerten.

Diese Konstruktion ist der Grund, warum wir einem Kunden empfehlen können, ein Projekt anzuhalten. Ein Beratungshaus, das an der Fortsetzung mitverdient, gerät bei dieser Empfehlung in einen Interessenkonflikt.

Nächste Schritte

Steht Ihr ERP-Projekt in der Umsetzung, lohnt sich eine unabhängige Zweitsicht, bevor aus einem Rückstand eine Eskalation wird. Weitere Informationen zu unserem Ansatz finden Sie in unserer Übersicht über unsere ERP-Beratungsleistungen.

Die Serie „ERP-Entscheidungssicherheit“:
Teil 1 – Warum ERP-Projekte scheitern, bevor die erste Zeile Code geschrieben ist
Teil 2 – Auf welcher Grundlage unterschreiben Sie einen ERP-Vertrag über zehn Jahre?

Die hier beschriebenen Muster begegnen uns besonders häufig im Großhandel und in der Medizintechnik.

Quellen: „Gründe für das Scheitern von ERP-Projekten“, Springer Gabler, 2025 · „Woran ERP-Projekte scheitern“, Computerwoche, 2025.

Dr. Harald Dreher

Geschäftsführer, Dreher Consulting · Über 33 Jahre Beratungserfahrung im DACH-Mittelstand · Über 1.200 begleitete ERP- und Digitalisierungsprojekte · 100 % herstellerunabhängig · Steht der Unternehmensleitung persönlich für ein erstes Gespräch zur Verfügung.

Vereinbaren Sie direkt einen Termin mit Dr. Dreher →