So wechseln Sie Ihren SAP-Implementierungspartner während des Projekts

Um Ihren SAP-Implementierungspartner während des Projekts zu wechseln, klären Sie zuerst, ob der Partner das Problem ist, und sichern dann jedes Dokument, jedes Design, jedes Stück Code und jeden Systemzugang, bevor Sie es ihm sagen. Erst danach wählen Sie den Nachfolger aus und führen eine geplante Übergabe mit Überlappung durch.

Kurz gesagt: Wechseln Sie, wenn der Partner Ihnen keine qualifizierten Leute stellen kann und das nicht beheben kann. Wechseln Sie nicht, um Problemen auf Ihrer Seite zu entkommen, denn ein neuer Partner erbt sie.

Dieser Artikel ist Teil meines Leitfadens zur Auswahl eines SAP-Implementierungspartners. Jener Leitfaden behandelt die Partnerwahl zu Beginn. Dieser behandelt, was zu tun ist, wenn der gewählte Partner nicht funktioniert.

Ich habe während eines Programms einen Partner gewechselt. Der Auslöser war die Qualität der Ressourcen: Der Partner konnte keine qualifizierten Leute stellen, als das Programm sie brauchte.

Dieses Anzeichen würde ich an die erste Stelle setzen. Ein Programm kann sich von einer schlechten Phase, einem verpassten Termin oder einem schwachen Design erholen. Schwer erholt es sich von einem Partner, der keine fähigen Leute auf die Arbeit setzen kann.

Das sind die Signale, auf die Sie reagieren sollten, ungefähr in der Reihenfolge, in der ich sie gewichten würde:

1. Schwache Qualität der Leute vor Ort. Die Berater, die die Arbeit liefern, sind nicht die Personen, die Ihnen gezeigt wurden, oder sie können grundlegende Fragen zu ihrem eigenen Bereich nicht beantworten.
2. Wiederholtes Scheitern beim Ersetzen von Leuten. Jemand geht, und der Ersatz braucht Wochen, bis er kommt, oder kommt mit weniger Erfahrung.
3. Niemand kann die Architektur und den Plan erklären. Bitten Sie den Lead des Partners, Sie durch das Zieldesign und den Weg zum Go-live zu führen. Kann er das nicht, steuert niemand die Lieferung.
4. Liefergegenstände, die einer Prüfung nicht standhalten. Designs, Testskripte und Build-Dokumente, die dünn sind, von einem anderen Kunden kopiert wurden oder fehlen.
5. Allgemeine Antworten auf konkrete Probleme. Dasselbe Warnsignal wie bei der Auswahl: Antworten, die auf jedes Unternehmen passen könnten.

Eine verspätete Phase, eine Überschreitung in Explore oder ein angespannter Lenkungsausschuss sind für sich genommen keine Gründe für einen Wechsel.

Bevor Sie jemanden ersetzen, finden Sie heraus, ob der Partner wirklich die Ursache ist. Mein Leitfaden zur Rettung von SAP-Programmen beschreibt die drei Prüfungen, die ich zuerst durchführe: den Programmstatus, das Design und das, was tatsächlich im System bereitgestellt ist.

Diese Diagnose zeigt oft, dass das Problem geteilt ist. Budgets werden in Explore getroffen, wenn die WRICEF-Liste (Workflows, Berichte, Schnittstellen, Konvertierungen, Erweiterungen und Formulare) wächst. Wenn Sie dem Partner die Steuerung des Umfangs überlassen haben oder Ihre Key-User nie für das Programm freigestellt wurden, läuft ein neuer Partner in dasselbe Loch.

Stellen Sie sich also ehrlich zwei Fragen:

1. Würde ein starkes Team bei diesem Partner das beheben? Wenn ja, und der Partner dieses Team schnell stellen kann, reicht vielleicht ein Austausch der Personen.
2. Hätte ein anderer Partner dieselben Probleme? Wenn ja, beheben Sie zuerst Umfang, Entscheidungen und Governance auf Ihrer Seite.

Lautet die Antwort auf die erste Frage nein, weil der Partner die Leute nicht findet, haben Sie Ihre Antwort. Die Verfügbarkeit qualifizierter Leute lässt sich nicht mit einer Vertragsänderung beheben.

Das ist der Teil, den die meisten Kunden falsch machen. Sie verkünden die Entscheidung, und ihre Verhandlungsmacht verschwindet damit.

Der scheidende Partner besitzt das Wissen, das Sie brauchen, um ihn zu ersetzen. Bis dieses Wissen in Ihren Händen ist, halten Sie die Entscheidung in einem kleinen Kreis: der Sponsor, der CFO, der Programmdirektor und Ihre Verantwortlichen für Recht oder Einkauf.

Beginnen Sie mit Ihrem aktuellen Vertrag. Lesen Sie die Kündigungsklausel, die Kündigungsfrist, die Eigentumsregeln für Liefergegenstände und alles zu Wissenstransfer oder Ausstiegsunterstützung. Wenn Ihre Leistungsbeschreibung (Statement of Work, SOW) zum Ausstieg schweigt, beschreibt mein Artikel dazu, was eine SAP-Leistungsbeschreibung enthalten muss, was in die nächste gehört.

Das sollten Sie sichern, und dort liegt es meistens:

Was Sie sichern sollten	Warum es zählt	Wo es liegen sollte	Wie Sie es schützen
Unterschriebene Designs und Entscheidungen	Der neue Partner baut darauf auf, statt neu anzufangen	Ihre Dokumentenablage oder SAP Cloud ALM	Kopieren Sie jetzt die neuesten genehmigten Fassungen, mit Freigabenachweisen
WRICEF-Liste und Spezifikationen	Die Ausgangsbasis für den Umfang und das Build-Backlog	SAP Cloud ALM oder Ihre eigene Ablage	Exportieren Sie die Liste mit dem Status jedes Objekts
Eigenentwicklungen und Customizing	Die bisher tatsächlich geleistete Arbeit	Ihre Entwicklungs- und Testsysteme	Bestätigen Sie, dass alles in Ihren Systemen liegt, nicht auf Rechnern des Partners
Testskripte und Testergebnisse	Belege dafür, was tatsächlich funktioniert	Ihr Testwerkzeug oder SAP Cloud ALM	Exportieren Sie Skripte, Ergebnisse und offene Fehler
Arbeit an der Datenmigration	Mappings, Bereinigungsregeln, Ladeprogramme	Gemeinsame Laufwerke und Ihre Systeme	Sammeln Sie Mapping-Dokumente und Ladeprogramme beim Datenteam ein
System- und SAP-Support-Zugang	Kontrolle über Ihre Systemlandschaft und Ihr SAP-Support-Konto	Ihre Systeme und SAP for Me	Listen Sie jeden Partnerbenutzer auf, bereit zur Entfernung am Stichtag
Offene Punkte und Risiken	Was das nächste Team zuerst aufgreifen muss	RAID-Log und Statusberichte	Erstellen Sie eine datierte Kopie des RAID-Logs

Halten Sie Projektinhalte in Ihren eigenen Werkzeugen

Der sauberste Schutz ist struktureller Art. Halten Sie Dokumente, Anforderungen und Testnachweise des Programms in Werkzeugen, die Ihnen gehören, vom ersten Tag jedes Programms an.

SAP Cloud ALM hilft hier. Kunden mit SAP Enterprise Support oder mit RISE with SAP können laut SAPs FAQ zu Cloud ALM ohne zusätzliche Gebühr einen eigenen Tenant anfordern, einen je Kundennummer. Liegt die Projektdokumentation in Ihrem Tenant, bleibt sie bei Ihnen, wenn ein Partner geht.

Planen Sie die Änderung der Zugänge für den Tag der Mitteilung

Berater des Partners haben oft S-User-IDs auf Ihrem SAP-Support-Konto sowie Benutzerkonten in Ihren Systemen. Die S-User-IDs in SAP for Me verwalten Ihre eigenen Administratoren.

SAPs Hilfe zur Benutzerverwaltung sagt, dass Kundenadministratoren dafür verantwortlich sind, die IDs von Benutzern zu löschen, die gegangen sind. Sie sagt auch, dass IDs mit Sonderfunktionen, etwa Softwareempfänger oder technischer Ansprechpartner, erst gelöscht werden können, wenn SAP diese Funktion auf jemand anderen übertragen hat. Finden Sie jetzt heraus, welche Partnerbenutzer diese Funktionen haben, und übertragen Sie sie zuerst auf Ihre eigenen Leute.

Sobald das Material gesichert und der Nachfolger gewählt ist, sagen Sie es dem scheidenden Partner. Tun Sie es schriftlich, im Einklang mit dem Vertrag, und vereinbaren Sie den Ausstiegsplan im selben Termin.

Eine Übergabe läuft am besten in dieser Reihenfolge:

SAP-Partner mitten im Programm wechseln

1. 01

   Sichern

   Dokumente, Designs, Code, Zugänge und das RAID-Log in Ihren Händen, bevor irgendjemand informiert wird.

2. 02

   Auswählen

   Referenzen aus vergleichbaren Projekten und das echte Team in den Präsentationen, mit beziffertem Aufwand.

3. 03

   Überlappen

   Scheidende und neue Leads arbeiten Seite an Seite an einem strukturierten Wissenstransfer.

4. 04

   Neu validieren

   Der neue Partner prüft Designs, Build und Tests gegen das, was bereitgestellt ist.

5. 05

   Neu planen

   Ein neuer Plan auf Basis der Belege, freigegeben, bevor die nächste Phase beginnt.

Wählen Sie den Nachfolger ordentlich aus

Die Versuchung ist, zu hetzen, weil das Programm Geld verbrennt, während Sie auswählen. Eine vollständige Auswahl dauert nach meiner Erfahrung etwa 12 Wochen, mit mindestens drei Partnern auf der Shortlist. Ein Ersatz unter Druck kann schneller gehen, aber überspringen Sie nicht die Schritte, die Sie schützen.

Wenn ich für einen Kunden einen Partner auswähle, gewichte ich Kundenreferenzen am stärksten. In Referenzgesprächen frage ich nach der Erfahrung des Partners mit Projekten wie dem des Käufers. Mitten im Programm heißt das, Referenzen nach der Übernahme von Arbeit zu fragen, die eine andere Firma begonnen hat.

Zwei Dinge bringen mich dazu, ein Angebot abzulehnen: eine schwache Qualität der vorgeschlagenen Ressourcen und ein Partner, der die Architektur und den Plan nicht erklären kann. Nach einem Wechsel wegen der Qualität der Ressourcen wenden Sie beide Tests strenger an, nicht milder.

Bitten Sie die Kandidaten um die Zertifizierungs-Badges der Personen, die sie vorschlagen. SAP vergibt seine Zertifizierungs-Badges über Credly, wie die Hilfeseite zu digitalen Badges erklärt. Ein Badge bestätigt eine bestandene Prüfung, also prüfen Sie die Erfahrung auch über Referenzen.

Meine Leitfäden zum Schreiben einer Ausschreibung für eine SAP-Einführung und zu den SAP-Implementierungspartnern nach Kategorie behandeln den Rest der Auswahl.

Gestalten Sie den Vertrag mit dem neuen Partner anders

Das kommerzielle Modell, das ich empfehle, ist eine Abrechnung nach Aufwand (Time and Materials) mit beziffertem Aufwand. Der Vertrag nennt den geschätzten Aufwand je Phase und Rolle, damit Sie den tatsächlichen Aufwand jeden Monat dagegen verfolgen können.

Die Leistungsbeschreibung braucht außerdem detaillierte Annahmen und Ausschlüsse. Kunden lassen sie oft weg, und bei einer Übernahme zählen sie noch mehr, weil der neue Partner geerbte Probleme ausschließen will.

Benennen Sie auch die Schlüsselpersonen im Vertrag. Meine Hinweise zur Verhandlung von ERP-Verträgen erklären die Klausel zu benannten Ressourcen und warum sie verhindert, dass erfahrene Leute nach der Unterschrift verschwinden.

Überlappen, dann neu validieren

Planen Sie eine Phase, in der die scheidenden und die neuen Leads zusammenarbeiten. Das scheidende Team geht jeden Designbereich, jeden offenen Fehler und jedes halb gebaute Objekt durch, und das neue Team stellt Fragen.

Lassen Sie den neuen Partner dann das Vorhandene neu validieren. Rechnen Sie damit, dass er Lücken findet, und damit, dass einige dieser Befunde eine Verhandlungsposition für mehr Aufwand sind. Genau hier lohnt sich eine unabhängige Sicht auf die Liefergegenstände des scheidenden Partners.

Ordnen Sie die Übernahme der Phase von SAP Activate zu, in der Sie sich befinden. SAP beschreibt sechs Phasen: Discover, Prepare, Explore, Realize, Deploy und Run (SAP Activate).

Ein Wechsel in Explore kostet vor allem Nacharbeit am Design. Ein Wechsel in Realize kostet zusätzlich Nacharbeit an Build und Tests, weil Code erst verstanden werden muss, bevor er fertiggestellt werden kann.

Einen kostenlosen Wechsel gibt es nicht. Ich nenne keine Zahl, weil sie von der Phase abhängt, von der Qualität des Gelieferten und davon, wie sehr der scheidende Partner mitarbeitet.

Für diese Kosten sollten Sie budgetieren:

1. Überlappung. Sie bezahlen während der Übergabe zwei Teams.
2. Neue Validierung und Nacharbeit. Der neue Partner prüft Designs, Customizing und Code, und einiges davon wird neu gemacht.
3. Vertragsausstieg. Kündigungsfristen, Kündigungsbedingungen und etwaige Zahlungen für laufende Arbeit, wie Ihr Vertrag es festlegt.
4. Aufwand für die Auswahl. Die Zeit Ihres eigenen Teams für Ausschreibung, Präsentationen und Referenzgespräche.
5. Die Zeit Ihrer Leute. Key-User wiederholen Workshops und Tests, die sie für abgeschlossen hielten.
6. Verzögerung. Jede Woche Verzögerung hält die Altsysteme und Ihr internes Team länger in Betrieb.

Wägen Sie das gegen die Kosten des Bleibens ab. Ein Partner, der das Programm nicht besetzen kann, wird nicht billiger, wenn das Programm schwieriger wird, und Realize, Tests und Cutover sind schwieriger als alles davor.

Ich rate Kunden, an drei Stellen einen unabhängigen Berater hinzuzuziehen: bei der Vertragsgestaltung, beim Design und bei der Bewertung der Dokumente und Liefergegenstände des Partners. Ein Partnerwechsel berührt alle drei auf einmal.

Ein unabhängiger Prüfer kann Ihnen sagen, was die Liefergegenstände des scheidenden Partners tatsächlich wert sind, bevor der neue Partner die Nacharbeit bepreist. Er kann auch den Vertrag des neuen Partners und dessen Sicht auf das Design prüfen. Mein Artikel SAP-Partner oder unabhängiger Berater beschreibt, wer was tut.

Finden Sie diese Woche heraus, wo Ihre unterschriebenen Designs, die WRICEF-Liste, die Testnachweise und die Eigenentwicklungen tatsächlich liegen und wer den Zugang zu jedem davon kontrolliert. Tun Sie das unabhängig davon, ob Sie einen Wechsel planen. Liegt etwas davon nur bei Ihrem Partner, legen Sie eine Kopie in Systemen ab, die Ihnen gehören.

Wenn Sie einen Partnerwechsel abwägen und eine unabhängige Sicht auf die Liefergegenstände oder den Vertrag möchten, können Sie hier mit mir sprechen.

Kann man den SAP-Implementierungspartner mitten im Projekt wechseln?

Ja. Prüfen Sie zuerst die Regelungen Ihres Vertrags zu Kündigung, Kündigungsfrist und Eigentum an Liefergegenständen. Sichern Sie Designs, Code, Testnachweise und Systemzugänge, bevor Sie die Entscheidung verkünden, und führen Sie dann eine geplante Übergabe mit einer Überlappungsphase durch.

Wann sollte man den SAP-Implementierungspartner wechseln?

Wechseln Sie, wenn der Partner keine qualifizierten Leute stellen und das nicht beheben kann oder wenn seine Leads die Architektur und den Plan nicht erklären können. Wechseln Sie nicht nur, weil sich eine Phase verspätet hat. Diagnostizieren Sie zuerst, denn Probleme bei der Umfangssteuerung oder bei Ihren eigenen Entscheidungen folgen Ihnen zu einem neuen Partner.

Was sollten Sie von Ihrem SAP-Partner erhalten, bevor Sie den Vertrag kündigen?

Unterschriebene Designs und Entscheidungsprotokolle sowie die WRICEF-Liste mit dem Status jedes Objekts. Eigenentwicklungen und Customizing in Ihren eigenen Systemen, Testskripte und Testergebnisse, Mappings der Datenmigration und das RAID-Log. Listen Sie außerdem jeden Partnerbenutzer in Ihren Systemen und auf Ihrem SAP-Support-Konto auf, damit die Zugänge am Stichtag entfernt werden können.

Was kostet ein Wechsel des SAP-Partners während des Projekts?

Es gibt keine Standardzahl. Budgetieren Sie für die Überlappung der beiden Teams, neue Validierung und Nacharbeit, die Ausstiegsbedingungen des Vertrags, Ihren eigenen Auswahlaufwand und Verzögerung. Je später die Phase, desto mehr Nacharbeit, weil Code und Tests erst verstanden werden müssen, bevor sie fertiggestellt werden können.

Wie lange dauert es, einen SAP-Implementierungspartner zu ersetzen?

Eine vollständige Partnerauswahl dauert nach meiner Erfahrung etwa 12 Wochen, mit mindestens drei Partnern auf der Shortlist. Ein Ersatz unter Druck kann schneller gehen, aber behalten Sie die Referenzgespräche und die Präsentationen mit dem echten Team bei.

Wem gehören die Dokumente und der Code aus einer SAP-Einführung?

Das entscheidet Ihr Vertrag, also prüfen Sie die Klausel zum Eigentum an Liefergegenständen. In der Praxis schützen Sie sich, indem Sie Dokumente in Ihrer eigenen Ablage oder Ihrem SAP Cloud ALM Tenant halten und Code und Customizing in Ihren eigenen SAP-Systemen statt auf Servern des Partners.