Zusammenfassung: Der Blog analysiert, warum „RISE with SAP“-Projekte oft scheitern, wenn „SAP Activate“ ohne projektspezifische Anpassung eingesetzt wird – insbesondere in der Private Cloud. Er zeigt auf, wie individuelle Vertragsmodelle, starke Kundenführung und ein partnerschaftlicher Ansatz den Projekterfolg sichern können.
Erkenntnisse aus dem EPILOG in BLOG34
Kann „SAP Activate“ in allen S/4HANA Cloud-Projekten eingesetzt werden?
Ich habe in den letzten Jahren mehrere Kundenmandate übernommen, in denen ich in extreme Schwierigkeiten geratene „RISE with SAP“-Projekte retten sollte. Die Projekte waren sämtlich unter Zugrundelegung der Methode/Framework „SAP Activate“ beauftragt und sollten dieser folgend implementiert werden. Leider ist dies in keinem Fall gelungen. Den systemimmanenten Grund dafür werden Sie am Ende dieses Artikels verstanden haben.
Alle diese Projekte wurden letztlich gestoppt und kosteten nicht zuletzt den CIOs und anderen Verantwortlichen ihren Job. Ich habe übrigens im dem Zusammenhang auch kein einziges „RISE mit SAP“ erlebt, bei dem der Implementierungspartner konsequent das entsprechende „SAP Activate“-Framework eingesetzt hat, und dies, obwohl das Projekt entsprechend beauftragt wurde; andererseits ist das ist dies nach meiner bisherigen Erfahrung und Einschätzung nach in „RISE with SAP“-Projekten auch gar nicht so wie eigentlich vorgesehen möglich. Weshalb dem so ist, wird hoffentlich auch am Ende des Artikels klarer sein.
Es geht auch anders – die Lösung macht den Unterschied.
Seit fast einem Jahr bin ich nun der direkt vom Kunden beauftragte Gesamtprojektleiter für ein „GROW with SAP“ (d.h. Public Cloud)-Projekt, das ebenfalls auf Basis von „SAP Activate“ beauftragt wurde und unter Einsatz des „SAP Activate“-Frameworks nach dieser Methode abgewickelt wird. Und ich bin zuversichtlich, dass dieses Projekt erfolgreich abgeschlossen wird. Wesentlich ist dabei, dass die dem Kunden nach „SAP Activate“ zugewiesenen und weitgehend von diesem selbstständig durchzuführenden Aufgaben konsequent gemanagt werden. Dies kann in einem solchen Public-Cloud-Projekt durchaus erreicht werden, da die von der SAP in der „SAP Activate“-Framework in einem Public Cloud Projekt uneingeschränkt nutzbar sind. Außerdem hat mein Kunde in dem Projekt zum Glück nicht den Fehler gemacht, die Einführung bei dem Implementierungspartner in einem Festpreisvertrag zu beauftragen (s. unten) – sodass die anfallenden Aufgaben mit bestmöglicher Effektivität partnerschaftlich bewältigt werden können.
Was ist das Problem?
In meinem „BLOG34 – https://sapxp.ch/erfolgreiche-s-4hana-projekte/“ habe ich bereits ausführlich über die offensichtliche Inkompatibilität von RISE mit SAP (Private Cloud) und den Einsatz der „SAP Activate“-Methode/des „SAP Activate“-Frameworks geschrieben. Nachdem ich nun auch einen detaillierten Einblick in die „GROW with SAP“ (Public Cloud)-Lösung und den Einsatz der „SAP Activate“-Methode/des „SAP Activate“-Frameworks in dieser Umgebung erhalten habe, ist mir umso klarer geworden, warum der Einsatz in „RISE with SAP“ (Private Cloud)-Projekten zum Scheitern verurteilt ist:
- Bei „SAP Activate“ ist das so genannte „Self-Enabling“ der Key-User eine Grundvoraussetzung. D.h. die Key-User werden nicht mehr wie bei „AcceleratedSAP“ von den Beratern an die Hand genommen und bekommen alles im Detail gezeigt und erklärt, sondern sie müssen sich das notwendige Wissen und Verständnis für die zukünftigen Prozesse im sogenannten Startersystem (vergleichbar mit dem ehemaligen IDES) anhand der von SAP zur Verfügung gestellten Dokumentation (im Wesentlichen Prozessdiagramme und Testskripte) aneignen.
- Dies kann auch in der Public Cloud relativ reibungslos funktionieren, da die im Startersystem vorgefundenen Prozesse auch denen in der zur Verfügung gestellten Dokumentation entsprechen, da in der Public Cloud keine wirklich prozessverändernden Anpassungen erlaubt sind.
- Und genau aus dem genannten Grund ist dieser Ansatz in der Private Cloud zum Scheitern verurteilt, da man sich in der Regel dafür entschieden hat, entsprechende Anpassungen vorzunehmen, d.h. die Gültigkeit der vorhandenen Dokumente wird außer Kraft gesetzt. Dies wird dann manchmal auf die Spitze getrieben durch die zusätzliche Implementierung von add-on-basierten Speziallösungen von Drittanbietern, insbesondere wenn diese in integrierte Prozesse und Funktionen eingreifen. Key-User sind dann auf verlorenem Posten, wenn es um das „Self-Enabling“ geht.
- Bei „SAP Activate“ wird die in jedem SAP-Projekt kritische Aufgabe der Datenmigration fast vollständig auf den Kunden übertragen. Die einzige Unterstützung durch den Implementierungspartner ist eine Einführung in die Nutzung des SAP Data Migration Cockpits. Ein kollaboratives Mapping der Daten und die Definition notwendiger und sinnvoller Konvertierungsregeln – unterstützt und vielleicht sogar angeleitet durch die Berater des Implementierungspartners – ist nicht vorgesehen.
- Da die Datenstrukturen/Tabellenfelder in der Regel unverändert in der Public Cloud verwendet werden, sind die verfügbaren Migrationsvorlagen gültig und auch die Feldverwendungen entsprechen der im Standard vorgesehenen und dokumentierten Funktionalität. Das heißt, der Kunde kann sich das Wissen aneignen, das er benötigt, um vorhandene Quellen zu identifizieren und Konvertierungsregeln zu definieren – wenn auch mühsam.
- Auch für diese Aufgabe dürfte klar sein, dass die in der Private Cloud skizzierte Vorgehensweise, bei der die Verwendung von Zusatzfeldern in den Stammdatenobjekten (ergänzt durch Erweiterungen in den Tabellen) nicht funktionieren kann. Dies ist insbesondere im Zusammenhang mit der Implementierung von Add-On-basierten Speziallösungen von Drittanbietern ja der Standard – und führt dann oft zu nicht enden wollenden Fehlerkorrekturen in den Mock-Load-Zyklen.
- Anders als bei der bisherigen „AcceleratedSAP“-Methode müssen bei „SAP Activate“ nicht mehr ALLE Prozesse und Funktionen vollständig und gemeinsam von Key-Usern und Beratern im Rahmen des Integrationstests durchlaufen und getestet werden. Stattdessen ist vorgesehen, dass die Berater (ohne Zutun der Key-User) im Rahmen des Integrationstests lediglich die Korrektheit und erfolgreiche „Integration“ von Zusatzentwicklungen, den sogenannten WRIFEF, testen und validieren. Die Anpassungen an der Konfiguration der Standardprozesse sind nicht Teil des geplanten Integrationstestumfangs.„SAP Activate“ ist darauf ausgelegt, dass die Key-User im Rahmen des Akzeptanztests die Prozesse und Funktionen erstmals vollständig testen und die Lösung dann selbstständig – ohne definierte Unterstützung durch die Berater – im Idealfall auch gleich „abnehmen“.
- Die Annahme, dass die im SAP-Standard ausgelieferten Prozesse und Funktionen keinem Integrationstest unterzogen werden müssen, sondern dieser nur für Zusatzentwicklungen, insbesondere Formularanpassungen und Schnittstellen, relevant ist, mag für die Public Cloud nachvollziehbar sein, da in der Public Cloud keine wesentlichen Änderungen an den Standardprozessen möglich sind. Dennoch ist es generell äußerst fraglich, ob es sinnvoll sein kann, diesen Test einzuschränken. Denn er ist erfahrungsgemäß so wichtig, um das Verständnis der Key-User für die zukünftige Lösung zu vertiefen. Da diese aber laut SAP Activate ohnehin komplett von diesem Integrationstest ausgeschlossen sind, spielt es vor diesem Hintergrund keine Rolle.
Auch bei GROW mit SAP-Projekten sollte daher auch darauf geachtet werden, dass die Standardvereinbarung so angepasst wird, dass im Integrationstest ALLES GEMEINSAM GETESTET wird. - Als geradezu sträflich ist der Ansatz zu bezeichnen, in der Private Cloud beim Integrationstest sich nur auf die Zusatzentwicklungen einzuschränken und die Anpassungen der Konfiguration zu ignorieren, die oft erheblich sind und häufig von den Entwicklungen zur Funktionserweiterung oder -änderung betroffen sind.Völlig unverständlich ist auch, dass den Key-Usern die Möglichkeit verwehrt wird, in einem gemeinsamen Integrationstest die Gesamtfunktionalität im Zusammenspiel von neu entwickelter Funktionalität und angepasster Konfiguration unter Anleitung der Berater zu entwickeln.Dies muss zwangsläufig zu großer Frustration bei den Key-Usern und Prozessverantwortlichen führen, da sie die Gesamtlösung im nachgelagerten Abnahmetest abnehmen sollen, ohne darauf durch einen gemeinsamen und vollständigen Integrationstest vorbereitet worden zu sein.Darüber hinaus ist es wohl auch eine Zumutung, dass die Prozesseigner im anschließenden Akzeptanztest mehr oder weniger gezwungen werden, alles abzunehmen, da der Akzeptanztest naturgemäß als letzter Test sehr kurz vor dem geplanten Go-Live stattfindet und im Test festgestellte Defizite nicht mehr behoben werden können, ohne den Go-Live-Termin unmittelbar zu gefährden.Diese Konstellation führt häufig dazu, dass das RISE-Projekt gestoppt, bestenfalls auf Eis gelegt und neu gestartet oder schlimmstenfalls ganz abgebrochen wird, was in diesem Projektstadium bedeutet, dass sowohl die bis dahin meist sehr hohen Investitionen komplett abgeschrieben werden müssen als auch die Beziehung zum Implementierungspartner in den meisten Fällen vollständig zerrüttet ist.
- Die Annahme, dass die im SAP-Standard ausgelieferten Prozesse und Funktionen keinem Integrationstest unterzogen werden müssen, sondern dieser nur für Zusatzentwicklungen, insbesondere Formularanpassungen und Schnittstellen, relevant ist, mag für die Public Cloud nachvollziehbar sein, da in der Public Cloud keine wesentlichen Änderungen an den Standardprozessen möglich sind. Dennoch ist es generell äußerst fraglich, ob es sinnvoll sein kann, diesen Test einzuschränken. Denn er ist erfahrungsgemäß so wichtig, um das Verständnis der Key-User für die zukünftige Lösung zu vertiefen. Da diese aber laut SAP Activate ohnehin komplett von diesem Integrationstest ausgeschlossen sind, spielt es vor diesem Hintergrund keine Rolle.
Die gegenseitige Geißelung im Vertrag komplettiert das Dilemma.
Die oben genannten Aufgaben sind bekanntlich die kritischsten Aufgaben für den Gesamterfolg eines SAP-Projekts (Aufbau von Know-how im Unternehmen (OCM) und Datenmigration) und liegen mit „SAP Activate“ / „RISE with SAP“ vollständig in der Verantwortung des Kunden, obwohl sie so nicht gelöst werden können.
Diese Effekte werden aber dadurch massiv verstärkt, dass sich die beiden Vertragspartner, also der Kunde und der Implementierungspartner, im Rahmen des Vertrages, der in der Regel auf RACI mit der Arbeitsteilung nach „SAP Activate“ basiert, auf das Verfahren einigen, auf das die Kunden bestehen, weil sie von SAP so stark propagiert werden und es nicht besser wissen können.
Zudem ist der potentielle Kunde meist der Meinung, dass er mit einem Festpreisvertrag am besten dran ist, obwohl bekannt sein sollte, dass dies selten zufriedenstellend funktioniert.
Beides zusammen ist eine wahrlich unsägliche Mischung, denn die Kunden legen in der Regel größten Wert auf die angebotenen Gesamtkosten und entscheiden sich daher oft für einen der günstigsten Anbieter. Dieser kann wiederum nur deshalb so günstig anbieten, weil er kompromisslos auf die vom Kunden geforderte Aufgabenteilung nach der SAP-Activate-Methode und der dazugehörigen RACI-Matrix sowie die dafür vorgesehenen Vertragsvorlagen setzt.
Wenn sich dann im Zuge der „SAP Activate“/„RISE with SAP“ herausstellt, dass dies nicht wirklich funktioniert, können sich beide Unternehmen in der Regel nicht mehr partnerschaftlich aufeinander zubewegen, weil sie sich in dieses vertragliche Festpreiskorsett eingeschnürt haben.
Mögliche Auswege aus dem „SAP Activate“/„RISE with SAP“ Dilemma
Machen Sie sich als Kunde klar, dass es nicht sinnvoll ist, bei einem „RISE with SAP“-Projekt auf die strikte Anwendung von SAP Activate zu bestehen. Fordern Sie bei der Erstellung einer Ausschreibung gezielt konkrete und quantifizierte Vorschläge für eine plausible partnerschaftliche Lösung der oben genannten Herausforderungen. Lehnen Sie sich ruhig an die frühere „AcceleratedSAP“-Methode an, bei der die Zusammenarbeit wesentlich sinnvoller geregelt war. Beschreiben Sie sehr genau, was von Ihnen erwartet wird, und stellen Sie sicher, dass Sie über die notwendigen Ressourcen verfügen, um all dies zu erreichen. Und stellen Sie sicher, dass Sie genügend zusätzliche Reserven für Eventualitäten einplanen, falls dies nicht gesichert der Fall ist.
Wenn Sie sich für einen Umsetzungspartner entschieden haben, sprechen Sie offen mit ihm darüber, welche Vertragsform für eine partnerschaftliche Zusammenarbeit und eine schnelle gemeinsame Reaktion auf unvorhersehbare Situationen am besten geeignet ist (siehe auch BLOG5 – https://sapxp.ch/partnering-modelle/ ).
Ein umfassendes Projektmanagement auf Kundenseite kann sowohl bei „RISE with SAP“ als auch bei „GROW with SAP“ den Unterschied ausmachen.
Sowohl für Kunden, die sich für „RISE with SAP“ (Private Cloud) entscheiden, als auch für diejenigen, die den Weg „GROW with SAP“ (Public Cloud) wählen: Seien Sie sich bewusst, dass Ihr eigener Projektleiter in einem SAP Activate-Projekt eine nachgewiesene Erfolgsbilanz haben muss, insbesondere in den folgenden projektkritischen Bereichen:
- Datenmigration (einschließlich Verfahren, Methoden und Werkzeuge) (siehe auch BLOG22 –https://sapxp.ch/datenbereinigung/ )
- Organizational Change Management (OCM) einschließlich von Train-the-Trainer-Konzepten und der Erstellung einer zielgerichteten und nachhaltigen Prozess- und Anwendungsdokumentation (siehe auch https://sapxp.ch/anwenderdokumentation/ )
- Testmanagement inkl. Vorbereitung durch Erstellung einer BPML mit e2e-Szenarien und Ableitung der zu testenden Business Cases in allen relevanten Prozessbereichen mit Bezug auf die zu implementierenden Scope Items (ehemals S4HANA Best-Practise ID) und natürlich die Planung und Steuerung der durchzuführenden Tests in Kundenverantwortung (siehe auch BLOG11 – https://sapxp.ch/mapping-best-practice-bpml/ & BLOG19 – https://sapxp.ch/anwenderdokumentation/ & BLOG24 – https://sapxp.ch/integrationstests/ ).