Warum wir SAP-Projekte abschliessen, wenn andere scheitern

Eine überraschende Zahl von SAP CX-Projekten geht nie in Betrieb. Branchenschätzungen zufolge werden 20-30 % der Enterprise-CRM-Implementierungen entweder abgebrochen, «auf unbestimmte Zeit pausiert» oder gehen so spät und so weit über Budget in Produktion, dass niemand von Erfolg spricht.

Wir haben SAP Sales Cloud V2, Service Cloud V2 und Commerce Cloud-Projekte für Hersteller, Händler und Distributoren in ganz Europa umgesetzt. Jedes einzelne ging live. Nicht irgendwann. Am vereinbarten Datum.

Das ist kein Verkaufsargument. Es ist eine Bilanz, die wir mit aller Konsequenz schützen — denn sobald wir einmal nicht liefern, ist unser Ruf dahin. Wir sind keine Firma mit 5’000 Mitarbeitenden, die ein gescheitertes Projekt verkraften kann. Wir sind ein fokussiertes Team, bei dem jedes Projekt zählt.

Hier ist, was wir anders machen.

Senior-Berater von Tag eins

Wenn eine grosse Beratungsfirma einen SAP CX-Auftrag gewinnt, ist das Team, das verkauft hat, selten das Team, das liefert. Das Vertriebsteam hatte 20 Jahre Erfahrung. Das Delivery-Team hat 20 Monate.

Bei uns gibt es kein Vertriebsteam und kein Delivery-Team als getrennte Einheiten. Die Personen, die Ihr Projekt scopen, sind die Personen, die es bauen. Jeder Berater in einem Spadoom-Engagement hat mehrere SAP V2-Implementierungen abgeliefert. Sie wissen, wo die Konfigurationsmöglichkeiten der Plattform enden und wo Custom Development beginnt. Sie wissen, welche Integrationen unkompliziert sind und welche drei Wochen Ihrer Timeline verschlingen.

Als wir SAP Sales Cloud V2 für Franke in 90 Tagen umgesetzt haben, war derselbe Architekt, der den Scoping-Workshop geleitet hat, ab Tag eins in der Konfiguration. Kein Handoff. Kein Wissensverlust. Keine Einarbeitungszeit.

Wir sagen Nein

Das ist vielleicht das Wichtigste, was wir tun. Wir sagen Nein zu Projekten, die wir nicht liefern können.

Wenn ein Interessent SAP Sales Cloud V2, Service Cloud V2, Commerce Cloud, Emarsys und CDP in einem einzigen 6-Monats-Projekt mit einem Team von vier Personen implementieren will, sagen wir, dass das nicht realistisch ist. Wenn ein Unternehmen sein 15 Jahre altes On-Prem-CRM Feature-für-Feature in einem Cloud-System nachbauen will, erklären wir, warum das der falsche Ansatz ist.

Manche Partner sagen zu allem Ja, weil der Vertragswert zu attraktiv ist. Dann trifft die Realität in Monat 3.

Wir verlieren lieber einen Deal, als unsere Go-Live-Bilanz zu gefährden. Jedes Mal, wenn wir Nein sagen, schützen wir die nächsten 10 Kunden, die uns verfügbar und fokussiert brauchen.

Fixer Scope, nicht fixe Hoffnungen

Jedes Spadoom-Projekt hat ein fixes Scope-Dokument. Kein High-Level-Überblick — eine detaillierte Liste von Liefergegenständen mit Abnahmekriterien.

«Konfiguration des Opportunity-Managements mit 4 benutzerdefinierten Stufen, gewichteter Pipeline und automatisierten Benachrichtigungen» ist ein Liefergegenstand. «CRM einrichten» ist keiner.

Das schützt beide Seiten. Der Kunde weiss genau, wofür er bezahlt. Wir wissen genau, was wir liefern müssen. Wenn jemand etwas ausserhalb des Scopes möchte, sagen wir nicht Nein — wir sagen «Ja, das kostet X und hat folgenden Einfluss auf die Timeline.» Transparentes Change Management statt Scope-Nebel.

Die SAP Sales Cloud V2-Implementierung für Nussbaum dauerte 5 Monate. Nicht weil wir gehetzt haben — weil der Scope ab Woche eins klar war. Keine Überraschungen. Keine Last-Minute-Entdeckungen. Kein «Wir dachten, das wäre enthalten.»

Iterative Lieferung mit SAP Activate

Wir folgen der SAP-Activate-Methodik. Nicht weil SAP es vorgibt, sondern weil es funktioniert.

So sieht das in der Praxis aus:

• Woche 1-2: Discover-Phase — Anforderungen validieren, Integrationen bestätigen, Entwicklungsumgebung einrichten.
• Woche 3-4: Erster Sprint — Anwender sehen ein funktionierendes System mit Kernfunktionalität.
• Alle 2 Wochen danach: Demo-Session mit Key Usern. Sie testen. Sie geben Feedback. Wir passen an.
• Letzte 2-3 Wochen: Integrationstests, Validierung der Datenmigration, User Acceptance Testing, Go-Live-Vorbereitung.

Der entscheidende Unterschied: Probleme tauchen in Woche 4 auf, nicht in Monat 6. Eine Konfiguration, die nicht zum Geschäftsprozess passt, wird im nächsten Sprint behoben — nicht in einer Krisensitzung drei Tage vor Go-Live.

Direkter Zugang zu Entscheidern

In vielen Beratungsfirmen steht ein Account Manager zwischen Ihnen und den Personen, die die Arbeit machen. Sie wollen eine Priorität ändern? Sprechen Sie mit dem Account Manager. Haben Sie eine technische Frage? Der Account Manager wird «sich erkundigen und zurückmelden.» Brauchen Sie eine Architektur-Entscheidung? Warten Sie auf das nächste Steering Committee.

Bei Spadoom sprechen Sie direkt mit den Architekten und Beratern, die Ihr System bauen. Müssen Sie eskalieren? Unser CEO geht ans Telefon. Es gibt keine bürokratische Schicht zwischen einer Frage und einer Antwort.

Diese Geschwindigkeit zählt. Eine Entscheidung, die in einer grossen Firma 2 Tage dauert, braucht bei uns 2 Stunden. Über ein 5-monatiges Projekt summiert sich dieser Unterschied auf Wochen gesparter Zeit.

Ehrliches Scoping

Bevor wir ein Angebot schreiben, führen wir einen Scoping-Workshop durch. Typischerweise 2-3 Tage, je nach Komplexität. Wir mappen Geschäftsprozesse, identifizieren Integrationspunkte, bewerten die Datenqualität und evaluieren die organisatorische Bereitschaft.

Manchmal lautet das Ergebnis dieses Workshops: «Sie sind noch nicht bereit für dieses Projekt.» Vielleicht müssen zuerst die Stammdaten bereinigt werden. Vielleicht müssen die Geschäftsprozesse intern abgestimmt werden, bevor jemand ein System konfiguriert. Vielleicht ist ein Phasenansatz über 12 Monate sinnvoller als alles auf einmal zu versuchen.

Einem Interessenten zu sagen, er solle warten, kostet uns kurzfristig Umsatz. Aber es verhindert ein gescheitertes Projekt — was beide Seiten weit mehr kosten würde.

Was wir von übernommenen Projekten gelernt haben

Einige unserer besten Erkenntnisse stammen von Projekten, die wir nicht begonnen haben. Wir wurden gerufen, um SAP CX-Implementierungen zu retten, die bei anderen Partnern steckengeblieben waren. Die Muster sind konsistent:

• Vager Scope, der im Projektverlauf um 50 % wuchs, ohne entsprechende Budget-Anpassung.
• Junior-Teams, die Custom Code geschrieben haben, wo Standard-Konfiguration funktioniert hätte, und damit eine Wartungslast erzeugten.
• Keine Integrationstests bis zu den letzten Wochen, als kritische Daten-Mapping-Probleme auffielen.
• Keine Anwender-Beteiligung bis zum UAT, als das Vertriebsteam das System ablehnte, weil niemand gefragt hatte, was sie brauchten.
• Big-Bang-Go-Live ohne Fallback-Plan, ohne gestuften Rollout, ohne Pilotgruppe.

Jedes einzelne davon ist vermeidbar. Nicht mit besserer Technologie — mit besserer Projektdisziplin.

Der ANWR-Ansatz

Bei der Arbeit mit der ANWR Group ging es darum, SAP Sales Cloud V2 mit der bestehenden SAP-Landschaft zu verbinden. Komplexe Integration, mehrere Datenquellen, branchenspezifische Anforderungen.

Wir starteten mit einem fokussierten Piloten: eine Geschäftseinheit, ein Kernprozess. Wir bewiesen, dass die Architektur funktioniert. Validierten die Integrationsmuster. Dann erweiterten wir. Der Pilot-Ansatz reduzierte das Risiko. ANWR sah früh den Wert. Der breite Rollout baute auf bewährten Grundlagen auf, nicht auf Annahmen.

Unsere Bilanz

100 % Go-Live-Quote. Jedes Projekt. Jedes Mal.

Diese Zahl bleibt nur bei 100 %, weil wir selektiv sind bei dem, was wir annehmen, ehrlich bei dem, was realistisch ist, und diszipliniert bei dem, wie wir liefern.

Wir sind nicht die günstigste Option. Wir sind nicht die grösste Firma. Aber wenn Ihr SAP CX-Projekt unbedingt pünktlich und im Budget live gehen muss, zählt die Bilanz mehr als Foliensätze.

Erzählen Sie uns von Ihrem Projekt — wir sagen Ihnen ehrlich, ob wir der richtige Partner sind.