ERP-Vertragsverhandlung: MENA-CFO spart 850.000 US-Dollar

Ein ERP-Einführungsvertrag schützt das Budget nur dann, wenn seine Struktur es tut: konkrete Liefergegenstände, namentlich benannte Ressourcen, Meilensteine, die an abgenommene Ergebnisse geknüpft sind, begrenztes Hypercare und kontrollierte Change Orders. Diese Fallstudie zeigt, wie ein CFO eines mittelgroßen Fertigungsunternehmens in der MENA-Region 850.000 US-Dollar vor dem Kick-off vermied. Er ließ die Leistungsbeschreibung (Statement of Work, SOW) zerlegen und den Vertrag vor der Unterschrift neu fassen, ohne den Umfang zu kürzen. Sie richtet sich an CFOs, Finanzleiter und Einkaufsverantwortliche, die kurz davorstehen, einen ERP- oder SAP-Einführungsvertrag zu unterzeichnen. Wenden Sie die Checkliste vor der Unterzeichnung gegen Ende auf Ihr eigenes Angebot an.

Der CFO überreichte mir einen Vorschlag mit 120 Seiten. Er sagte, es sehe solide aus, aber irgendetwas stimme nicht. Er hatte recht.

Die Zahlen waren nicht das Problem. Die Struktur war es. Allgemeine Begriffe wie „Standardkonfiguration“ und „Testunterstützung“, ohne Erklärung, welche Arbeit dahintersteckt. Dieselbe Arbeit, die in verschiedenen Abschnitten unter verschiedenen Namen auftauchte. Eine Sprache, vage genug, um später fast jede Überschreitung zu rechtfertigen. So geraten Projekte aus der Spur, bevor sie beginnen.

Ich sah, was er gespürt, aber nicht benennen konnte. Er kannte Budget und Ziele. Sein Team war kompetent, hatte aber noch nie ein SOW für die Projektumsetzung in dieser Größenordnung geprüft, und der Anbieter bewegte sich bereits auf die Unterschrift zu.

Nach drei Wochen Arbeit war der Vertrag ein grundlegend anderer, und das Projekt war vor dem Kick-off um 850.000 US-Dollar leichter.

$850Kvor dem Kick-off vermieden

1. Bereinigung des UmfangsAufgeblähte Stunden gekürzt, doppelte Schulungen und Tests entfernt, Testzyklen von vier auf zwei plus Reserve reduziert$340K
2. Umverteilung von Rollen und TagessätzenVerhältnis von Senior zu Junior gesteuert, interne Mitarbeitende übernehmen Dokumentation und einfache Tests$310K
3. VertragsänderungenZahlungen nach Liefergegenständen, Spesenobergrenzen, begrenztes Hypercare, CFO-Freigabe für Change Orders$200K

Ein mittelgroßer Industriehersteller und -händler mit grenzüberschreitendem Geschäft und zentraler Finanzfunktion: diskrete Fertigung, Ersatzteilvertrieb, Finanz-Shared-Services und Konzerneinkauf. Die Gruppe war in fünf Jahren schnell gewachsen und hatte sich bereits für SAP entschieden. Es war der Moment zwischen Anbieterauswahl und Einführung, in dem die großen Verpflichtungen festgeschrieben werden.

Ich zerlegte das SOW in sechs Kategorien: Konfiguration, Datenmigration, Integrationen, Tests, Schulung und PMO. Sobald es so aufgeteilt war, ließen sich die Lücken leicht erkennen.

1. Vage Liefergegenstände. „Standardintegrationen“ ohne Systemnamen, Datenvolumen oder Komplexität. Konfiguration in Stunden beschrieben, ohne Bezug zu Geschäftsprozessen. „In Workshops zu klären“ zieht sich durch das Dokument, und jede dieser Stellen ist eine künftige Change Order.
2. Resource Pyramiding. Senior-Berater, die im Angebot zu Senior-Tagessätzen namentlich genannt sind. Nach der Vertragsunterzeichnung verschwinden die erfahrenen Leute erfahrungsgemäß, und Junior-Berater erbringen die Arbeit zum selben Satz. Ich habe das in fast jedem Programm gesehen. Ohne Klausel zu namentlich benannten Ressourcen gibt es keinen Schutz.
3. Doppelte Abrechnung. Schulung im UAT und noch einmal im Hypercare. Datenprüfungen im Test und noch einmal beim Cutover. Wissenstransfer, der auf Funktions- und PMO-Stream aufgeteilt und doppelt abgerechnet wird. Einzeln sind es kleine Überschneidungen, zusammen sind sie ernste Treiber für Überschreitungen.
4. Die Festpreis-Illusion. Als Festpreis dargestellt, aber „fest“ gilt nur, wenn jede Annahme festgeschrieben ist. Diese Formulierungen halten die ausgewiesene Gesamtsumme stabil und öffnen später die Tür für Nachberechnungen.
5. Schwache Meilensteine. Zahlungen sind an Kalendertermine geknüpft, etwa „Design bis September abgeschlossen“, ohne Definition von „abgeschlossen“, ohne Abnahmekriterien und ohne Möglichkeit, eine Rechnung für halbfertige Arbeit zurückzuhalten.
6. Platzhalterstunden. Pufferzeilen „nach Bedarf zu verwenden“ ohne Begründung. Sie sind bei Routineaufgaben schnell verbraucht und kommen als Change Requests zurück.

Zwei Details beim Umfang fielen ebenfalls auf. Die Datenmigration war vollständig dem Anbieter zugerechnet, obwohl der Kunde bereits eigene Werkzeuge hatte. Und die Tests waren auf vier volle Zyklen angesetzt, ohne dass Annahmen zu Fehlerzahlen dahinterstanden.

Die Einsparungen kamen aus drei Bereichen:

Bereich	Einsparung	Wie
Bereinigung des Umfangs	340.000 $	Aufgeblähte Konfigurationsstunden gekürzt; doppelte Schulungen und Tests entfernt; Tests von vier Zyklen auf zwei plus Reserve reduziert
Umverteilung von Rollen und Tagessätzen	310.000 $	Verhältnis von Senior zu Junior gesteuert; interne Mitarbeitende übernahmen Dokumentation und einfache Tests, abgesichert durch Klauseln zu benannten Ressourcen
Vertragsänderungen	200.000 $	Zahlungen an Liefergegenstände geknüpft; Reise- und Spesenobergrenzen mit Vorabgenehmigung; Hypercare befristet, mit KPI-basiertem Ausstieg; Change Orders mit CFO-Freigabe gesteuert

Der Migrationsaufwand des Anbieters sank um rund ein Drittel, weil die eigenen Werkzeuge und Standards des Kunden genutzt wurden, und die externen Schulungsstunden sanken durch ein intern geführtes Modell um etwa die Hälfte. Nichts davon verringerte Umfang oder Funktionen. Das Projekt startete zum geplanten Termin, und im ersten Quartal gab es keine Change Orders. Normalerweise wären bis dahin eine Handvoll auf dem Schreibtisch des CFO gelandet.

Sechs Klauseln machten den praktischen Unterschied:

1. Benannte Ressourcen. Jeder Schlüsselberater wird namentlich genannt. Ersetzungen bedürfen der Zustimmung des Kunden und einer Anpassung des Satzes. Ohne das sind die Leute im Angebot nicht die Leute vor Ort.
2. Meilensteine nach Liefergegenständen. Jeder Meilenstein wird über Ergebnisse definiert: unterzeichnete Prozesslandkarten, abgestimmte Daten, abgeschlossene Abnahmetests. Die Zahlung wird freigegeben, wenn die Kriterien erfüllt sind, nicht wenn der Termin eintrifft.
3. Steuerung von Change Orders. Jede Umfangsänderung braucht eine Auswirkungsbeschreibung zu Umfang, Termin und Kosten. Die Sätze für neue Arbeiten sind gedeckelt. Die Freigabe durch den CFO ist verpflichtend. Change Orders werden zu kontrollierten Ausnahmen statt zu einem Erlösmodell.
4. Hypercare-Obergrenze mit Ausstiegskriterien. Auf sechs Wochen befristet, der Ausstieg richtet sich nach Transaktionsstabilität und SLA-Einhaltung, nicht nach dem Urteil des Anbieters. Verlängerungen brauchen eine neue Genehmigung.
5. Obergrenzen für Reise- und Nebenkosten. Vorabgenehmigung oberhalb festgelegter Schwellen. Sonst werden Reisen nach dem Go-live zu einer offenen Position.
6. Prüfrechte. Das Recht, Abrechnungsunterlagen einzusehen, auch wenn es nie genutzt wird. Es verändert das Verhalten, denn Aufpolstern ist weniger wahrscheinlich, wenn sich nachprüfen lässt.

Für die breitere Verhandlung behandeln meine Beiträge zu SAP-Verhandlungsberatern und zur SAP-Lizenzverhandlung die Softwareseite des Deals.

Finanzteams behandeln die ERP-Einführung oft als IT-Projekt und ziehen sich zurück, sobald das Budget genehmigt ist. Genau dadurch können sich Überschreitungen aufbauen.

Der Vertrag ist ein Finanzinstrument. Meilensteine bestimmen den Cashflow. Ressourcenklauseln bestimmen die Kosten. Der Change-Order-Prozess bestimmt das finanzielle Risiko. Wenn die Finanzabteilung diese Punkte nicht vor der Unterzeichnung prüft, tut es niemand mit kaufmännischer Erfahrung.

Drei Lücken tauchen immer wieder auf:

1. Der Festpreis-Mythos. CFOs genehmigen eine Zahl, die gedeckelt aussieht, doch der Umfang ist nicht fix, wenn die Annahmen vage blieben. In den Workshops des Anbieters wächst der Umfang, und er wird berechnet.
2. Kein Modell dafür, was Verzögerung kostet. Ein Verzug kostet mehr als die zusätzlichen Beratungswochen: Er bindet interne Zeit und verschiebt den Nutzen. Die meisten Budgets planen die Projektkosten und modellieren nie, was jede Woche Überschreitung kostet.
3. Ein internes PMO ohne kaufmännische Kompetenz. Terminplanung und Reporting sind vorhanden, kaufmännische Gegenwehr nicht. Die Projektmanager des Anbieters wissen, wie man mit Vertragsbedingungen arbeitet, und ohne eine ebenso versierte Person auf Kundenseite gibt der Kunde Boden preis. Mein Leitfaden zu den Gründen, warum SAP-Budgets überschritten werden, zeigt, wo dieses Risiko meist zu Kosten wird.

Gehört RISE with SAP zum Deal, sind zwei Verträge zu lesen: das Subscription-Modell von SAP mit seiner eigenen Servicebeschreibung und das SOW des Implementierungspartners. Wenden Sie auf beide dieselbe Disziplin an und modellieren Sie, wie die Subscription mit den Anwenderzahlen über die gesamte Laufzeit wächst, nicht nur im ersten Jahr.

Prüfen Sie jedes ERP-Einführungsangebot vor der Unterschrift anhand dieser Punkte:

1. Ist das SOW nach Workstreams (Konfiguration, Daten, Integrationen, Tests, Schulung, PMO) gegliedert, mit Aufwand für jeden?
2. Nennt jede Integration die Systeme, die Datenvolumen und die Komplexität?
3. Wurde jede Annahme „in Workshops zu klären“ geschlossen oder ausdrücklich ausgeschlossen?
4. Sind die Schlüsselberater namentlich benannt, mit Zustimmung zur Ersetzung und Anpassung des Satzes?
5. Ist jeder Zahlungsmeilenstein an einen Liefergegenstand mit Abnahmekriterien und Freigabe durch den Kunden geknüpft?
6. Gibt es einen Change-Order-Prozess mit Auswirkungsbeschreibungen, gedeckelten Sätzen und CFO-Freigabe?
7. Ist Hypercare befristet, mit objektiven Ausstiegskriterien?
8. Sind Reise- und Nebenkosten gedeckelt, und haben Sie Prüfrechte für abgerechnete Stunden?
9. Ist Arbeit, die Ihr eigenes Team leisten kann (Datenmigration mit internen Werkzeugen, Dokumentation, einfache Tests, Schulung), aus dem Leistungsumfang des Anbieters herausgenommen?

Der CFO formulierte es später so: „Als ich das Angebot zum ersten Mal prüfte, fand ich die Zahlen angemessen. Was ich übersah, war, wie vage der Umfang tatsächlich war. Nachdem wir es aufgeschlüsselt hatten, wurde mir klar, dass der größte Teil des Risikos im Kleingedruckten steckte. Der finanzielle Blick auf den Vertrag gab mir eine Kontrolle, von der ich nicht wusste, dass sie mir fehlte. Die Einsparungen waren wichtig, aber der größere Gewinn war, mit Klarheit und ohne Überraschungen in die Einführung zu gehen.“

Er teilte das Ergebnis mit seinem Vorstand. Die Einsparungen waren die Schlagzeile. Das wichtigere Ergebnis war ein Vertrag und ein Projekt, die das Unternehmen von Anfang an im Griff hatte.

Was ist Resource Pyramiding in ERP-Verträgen, und wie lässt es sich verhindern?

Gemeint ist, dass im Angebot Senior-Berater zu Senior-Tagessätzen angeboten werden und nach der Unterschrift weniger erfahrenes Personal die Arbeit erledigt. Der Abrechnungssatz bleibt gleich. Die Qualität nicht.

Die Lösung ist eine Klausel zu namentlich benannten Ressourcen. Jede Schlüsselrolle wird benannt, Ersetzungen bedürfen der Zustimmung des Kunden, und liegt der Satz einer Ersatzperson niedriger, wird die Abrechnung angepasst.

Wie sollten ERP-Abrechnungsmeilensteine aufgebaut sein?

Knüpfen Sie sie an Liefergegenstände, nicht an Termine. „Design abgeschlossen“ ist kein Meilenstein. „Unterzeichnete Prozesslandkarten und geprüfte Konfiguration für Finanzen und Einkauf“ ist einer.

Geben Sie jedem Meilenstein Abnahmekriterien, die der Kunde vor der Zahlung freigibt. Das verschafft Ihnen Verhandlungsmacht bei unvollständiger Lieferung und verhindert Rechnungen für Teilleistungen.

Was ist die Festpreisfalle bei ERP-Einführungsverträgen?

Ein Festpreis ist nur dann fest, wenn vor der Unterzeichnung jede Annahme festgeschrieben ist. Formulierungen wie „in Workshops zu klären“, „Standardintegrationen“ oder „auf Basis des aktuellen Umfangs“ halten die ausgewiesene Gesamtsumme stabil und schaffen zugleich spätere Einfallstore für Change Orders.

Schließen Sie Annahmen vor der Unterzeichnung, führen Sie Ausschlüsse ausdrücklich auf, deckeln Sie die Sätze für Change Orders und prüfen Sie jede Festpreisaussage Zeile für Zeile.

Wie sollte Hypercare in einem ERP-Vertrag definiert werden?

Offenes Hypercare wird für den Anbieter zur Einnahmequelle. Begrenzen Sie es auf einen festgelegten Zeitraum, meist sechs bis acht Wochen, mit objektiven Ausstiegskriterien wie Transaktionsstabilität, SLA-Einhaltung und Ticketvolumen. Jede Verlängerung braucht eine formelle Genehmigung.

So wird Hypercare zu einem befristeten Sicherheitsnetz mit klaren Bedingungen für die Übergabe.

Was sollte ein CFO vor der Unterzeichnung eines ERP-Einführungsvertrags prüfen?

Mindestens: wie Meilensteine definiert sind, den Schutz vor dem Austausch von Ressourcen, die Regeln für Change Orders, Umfang und Ende des Hypercare, Obergrenzen für Reise- und Nebenkosten sowie die Ausschlussliste.

Lassen Sie über die Klauseln hinaus das SOW Workstream für Workstream zerlegen und die Aufwandsschätzungen an Ihrer internen Kapazität messen. Wo Ihre eigenen Mitarbeiter Dokumentation, einfache Tests oder Schulungen übernehmen können, sollte der Vertrag das abbilden.

Warum tauchen Change Orders selbst bei Festpreisverträgen für ERP immer wieder auf?

Weil Festpreisverträge selten jede Annahme festschreiben. Angebote werden auf hoher Ebene geschrieben, Lücken zeigen sich in Workshops, und jede Lücke wird zu einem Change Request, der formal außerhalb des Umfangs liegt.

Das Muster ist vorhersehbar: vager Umfang, Workshops, die ihn erweitern, Change Orders, die die Lücke zu Geld machen. Verlangen Sie vor der Unterzeichnung einen konkreten Umfang und fordern Sie eine Auswirkungsanalyse und eine Freigabe auf Führungsebene, bevor neue Arbeit beginnt.