Warum SAP CX-Projekte das Budget sprengen — und wie man das verhindert

Eine Zahl, die jeden CIO beunruhigen sollte: Branchenstudien zeigen, dass rund 60 % der SAP-Implementierungsprojekte ihr ursprüngliches Budget überschreiten. Manche um 20 %. Manche um 200 %.

Die Gründe sind selten technischer Natur. Sie sind strukturell. Und die meisten davon lassen sich vermeiden — wenn man weiss, wo man vor der Vertragsunterzeichnung hinschauen muss.

Wir haben SAP Sales Cloud V2, Service Cloud V2 und Commerce Cloud-Projekte in der Fertigung, im Handel und in der Distribution umgesetzt. Einige davon haben wir mitten in der Krise von anderen Partnern übernommen. Die Budget-Probleme folgen jedes Mal denselben Mustern.

Grund 1: Der Scope war nie wirklich definiert

Das ist die häufigste Ursache für Budgetüberschreitungen. Nicht Scope Creep — Scope-Nebel.

Viele Projekte starten mit einem 40-seitigen Anforderungsdokument, das sich wie eine Wunschliste liest. «Das System soll alle aktuellen Vertriebsprozesse unterstützen.» Was heisst das? Niemand ist sich einig. Der Partner schätzt basierend auf seiner Interpretation. Der Kunde erwartet etwas anderes. Nach drei Monaten wird die Lücke sichtbar — und teuer.

Was stattdessen funktioniert: Definieren Sie den Scope auf Prozessebene, nicht auf Feature-Ebene. «Konfiguration der Lead-zu-Opportunity-Konvertierung mit automatischer Gebietszuordnung für DACH-Märkte, inklusive Genehmigungsworkflow für Deals über CHF 50’000.» Das ist ein Scope-Element. «Vertriebsprozesse unterstützen» ist keins.

Bei Spadoom beginnt jedes Projekt mit einem Scoping-Workshop, der eine fixe Liste von Liefergegenständen produziert. Was nicht auf der Liste steht, ist nicht im Projekt. Wenn der Kunde etwas hinzufügen möchte, bepreisen wir es separat. Keine Unklarheiten.

Grund 2: Zu viele Junior-Berater

Das ist das offene Geheimnis grosser Beratungsfirmen. Sie verkaufen das Projekt mit Senior-Architekten im Raum. Dann besetzen sie es mit Beratern, die 18 Monate Erfahrung haben und SAP Sales Cloud V2 auf Ihrem Budget lernen.

Junior-Berater brauchen länger. Sie machen Architektur-Fehler, die erst beim Testen auffallen. Sie bauen Workarounds statt Standard-Konfiguration zu nutzen. Eine Aufgabe, die ein Senior-Berater in 2 Tagen erledigt, braucht bei einem Junior 5 — plus 2 weitere Tage, um die Fehler zu beheben.

Die Rechnung ist brutal. Sie zahlen CHF 1’500/Tag für jemanden, der mit 40 % der Geschwindigkeit arbeitet wie jemand, der CHF 2’200/Tag kostet. Die «günstigere» Ressource kostet Sie mehr.

Was stattdessen funktioniert: Fragen Sie Ihren Partner genau, wer an Ihrem Projekt arbeitet. Verlangen Sie Namen, CVs und SAP-Zertifizierungen. Fragen Sie, wie viele V2-Projekte diese Personen abgeschlossen haben (nicht V1 — die Architektur ist komplett anders). Wenn die Antwort vage ist, ist das Ihre Antwort.

Jedes Spadoom-Projekt wird mit Senior-Beratern besetzt, die mehrere V2-Implementierungen abgeliefert haben. Keine Juniors, die auf Ihre Kosten lernen.

Grund 3: Wasserfall-Planung in einer Cloud-Welt

SAP CX-Produkte sind cloudbasiert. Sie erhalten vierteljährliche Updates. Sie werden konfiguriert, nicht von Grund auf programmiert. Dennoch planen viele Partner Projekte in starren Wasserfall-Phasen: 3 Monate Blueprinting, 3 Monate Build, 1 Monat Testing, Big-Bang-Go-Live.

Das Problem: Bis Sie den Blueprint fertig haben, hat die Plattform zwei Updates erhalten. Anforderungen haben sich verschoben. Die Anwender haben bis Monat 6 nichts Funktionierendes gesehen. Und wenn sie es endlich tun, erzeugt die Feedback-Schleife eine Lawine von Änderungsanträgen.

Was stattdessen funktioniert: Die SAP-Activate-Methodik existiert aus gutem Grund. Iterative Lieferung. Ein funktionierendes System ab Sprint 2. Benutzer-Feedback alle zwei Wochen. Kurskorrektur, solange sie günstig ist — nicht erst, wenn alles gebaut ist.

Wir arbeiten typischerweise in 2-Wochen-Sprints mit Demo-Sessions am Ende jedes Sprints. Kunden sehen ab Woche 3 funktionierende Funktionalität. Probleme tauchen früh auf. Das Budget bleibt intakt.

Grund 4: Integrations-Komplexität wird unterschätzt

«Wir müssen es nur mit unserem ERP verbinden.» Dieser Satz hat mehr Projektbudgets zerstört als jeder andere.

SAP Sales Cloud V2 mit SAP S/4HANA zu verbinden klingt einfach. Ist es nicht. Sie müssen Datenmodelle mappen, Master-Data-Synchronisation handhaben, Konfliktlösung managen, mit unterschiedlichen Update-Frequenzen umgehen und Fehlerbehandlung bauen für den Fall, dass die Middleware am Freitagabend um 2 Uhr hängenbleibt.

Dann gibt es die Middleware selbst. SAP BTP Integration Suite, Third-Party-iPaaS oder Custom APIs — jede hat ihre eigene Komplexität. Jede braucht Monitoring. Jede braucht jemanden, der sie wirklich konfigurieren kann.

Was stattdessen funktioniert: Budgetieren Sie Integration separat. Nicht als Einzelposten — als eigenen Workstream mit eigenem Zeitplan und eigener Testphase. Wir haben Projekte gesehen, bei denen die Integration 40 % des Gesamtaufwands ausmachte. Wenn Ihr Partner sie mit 10 % schätzt, stellen Sie harte Fragen.

Wir scopen Integration als dedizierte Phase. Jede Schnittstelle erhält ein technisches Design-Dokument, bevor eine einzige Zeile Konfiguration geschrieben wird. Die Schnittstellen werden unabhängig getestet, bevor die System-Integrationstests beginnen.

Grund 5: Change Management kommt zu kurz

Sie können die perfekteste SAP Sales Cloud V2-Instanz der Welt konfigurieren. Wenn Ihr Vertriebsteam sie nicht nutzt, haben Sie jeden Franken verschwendet.

Die meisten Budgetüberschreitungen enthalten versteckte Kosten: Feuerlöschen nach Go-Live, weil Anwender das System ablehnen, umgehen oder den Helpdesk überfluten. Das Projekt war «fertig», aber die Arbeit nicht.

Was stattdessen funktioniert: Binden Sie Endanwender-Schulungen, Key-User-Workshops und Adoptions-Tracking von Tag eins in den Projektscope ein. Budgetieren Sie 10-15 % der Gesamtprojektkosten für Change Management. Es ist nicht optional.

Das Preismodell-Problem

Neben diesen fünf Ursachen gibt es ein strukturelles Problem: Time-and-Materials-Verträge.

T&M bedeutet, der Partner verdient mehr, wenn das Projekt länger dauert. Das sind falsch gesetzte Anreize. Wir unterstellen nicht, dass Partner absichtlich bremsen — aber T&M entfernt den Druck, effizient zu sein.

Festpreis-Verträge mit fixem Scope drehen die Anreize um. Der Partner ist motiviert, effizient zu liefern, weil Überschreitungen seine Marge belasten, nicht Ihr Budget.

Bei Spadoom arbeiten wir mit Festpreis-Verträgen. Der Preis im Angebot ist der Preis, den Sie zahlen. Wenn wir unterschätzen, ist das unser Problem. Das zwingt uns zu ehrlichem Scoping — genau die Disziplin, die Überschreitungen verhindert.

Eine praktische Budget-Checkliste

Bevor Sie Ihren nächsten SAP CX-Vertrag unterschreiben, prüfen Sie diese sieben Punkte:

1. Der Scope ist granular. Jeder Liefergegenstand ist auf Prozessebene mit Abnahmekriterien beschrieben.
2. Das Team steht fest. Sie wissen genau, wer an Ihrem Projekt arbeitet und welche Erfahrung diese Personen mitbringen.
3. Die Methodik ist iterativ. Sie sehen funktionierende Software innerhalb des ersten Monats.
4. Integration ist separat gescoped. Mit eigenem Zeitplan und Testplan.
5. Change Management ist budgetiert. Schulung, Dokumentation, Adoptions-Support — von Anfang an enthalten.
6. Die Preisgestaltung ist fixiert. Oder zumindest gibt es eine Obergrenze mit klaren Change-Request-Verfahren.
7. Die Referenzen sind real. Sie können mit Kunden sprechen, die ähnliche Projekte pünktlich und im Budget abgeschlossen haben.

Das Fazit

SAP CX-Projekte sprengen nicht wegen SAP ihr Budget. Sie sprengen es wegen der Art, wie sie geplant, besetzt und gemanagt werden.

Die Unternehmen, die erfolgreich sind, behandeln die Implementierung als Geschäftsprojekt, nicht als IT-Projekt. Sie investieren in klaren Scope. Sie fordern erfahrene Teams. Sie bestehen auf iterativer Lieferung. Und sie wählen Partner, deren finanzielle Anreize mit pünktlicher Fertigstellung übereinstimmen.

Wir halten eine 100%-Go-Live-Quote über alle SAP CX-Projekte, die wir umgesetzt haben. Nicht weil wir Glück haben — weil wir kein Projekt starten ohne die oben beschriebenen Disziplinen.

Wenn Sie eine SAP CX-Implementierung planen — oder eine retten müssen, die aus dem Ruder gelaufen ist — lassen Sie uns offen darüber sprechen, was es braucht.