SAP Activate - Agilität in SAP S/4HANA-Implementierungsprojekten. Martin Kipka
einfach nur aus Unmut über die mangelnde (rechtzeitige) Einbindung.
Das Projekt ist auf Kundenseite suboptimal besetzt. Nicht die Mitarbeiter mit den besten Prozesskenntnissen stehen dem Projekt zur Verfügung, sondern jene, die gerade Zeit hatten.
Das Projekt ist seitens des Implementierungspartners suboptimal besetzt. Nicht die Mitarbeiter mit den passenden Skills, sondern die Mitarbeiter, die gerade kein anderes Projekt haben, werden entsendet.
Der Lenkungsausschuss entscheidet träge oder verschiebt seine Zusammenkünfte immer wieder.
Innovationen führen zu einer Veränderung des Projektinhalts und damit zu Veränderungen mit Blick auf die zu liefernde Qualität.
Durch Weiterentwicklung des Geschäftsmodells gibt es kundenseitig neue Anforderungen.
Zu Beginn des Projekts lässt man gewisse Unschärfen im Zeitmanagement durchgehen, weil sich die Gesamtdauer ja noch gut »anfühlt«.
Häufig führen Change Requests auch zu einer Abkühlung des Vertrauensverhältnisses zwischen den Partnern. Am Ende geht es schließlich regelmäßig darum, wer für den veränderten Aufwand geradesteht.
Dieser in vielen Projekten immer wieder aufkeimende Konflikt von Change Requests wird nach der SAP-Activate-Methode idealerweise so gelöst, wie es in agilen Projektvorgehensmodellen üblich ist: Man verzichtet auf das aufwendige Abfassen von Sollkonzepten. In agilen Projekten geht man grundsätzlich davon aus, dass es im Projektverlauf neue Anforderungen geben wird. Technischer Fortschritt, die Weiterentwicklung des Unternehmens oder einfach nur späte Erkenntnisse sind die Ursachen für solche unvorhergesehenen Projektanforderungen. Statt nun jedes Mal darüber nachzudenken, den Projektumfang auszuweiten, wird überlegt, welche Funktionalitäten der neuen Anforderung weichen müssen. Es wird also neu priorisiert. Diese Aufgabe kommt zwingend einem Mitarbeiter des Kunden im Projekt zu. Man nennt diese Rolle »Product Owner«.
Abbildung 2.5 stellt die Herangehensweise dar. Aufgrund dieses Ansatzes bleibt die Grundfläche des Dreiecks unverändert. Ihr Inhalt hingegen, also die Teilleistungen, werden im Projektverlauf regelmäßig hinterfragt und ggf. mit anderen Prioritäten versehen. Neue wichtige Anforderungen auf der einen Seite können also weniger wichtige Anforderungen auf der anderen Seite aus dem Projektumfang verdrängen.
Abbildung 2.5: Change in SAP Activate
Diese Verfahrensweise erspart manche leidige Diskussion zwischen dem Implementierungspartner und dem Kunden hinsichtlich Klarheit, Vollständigkeit und Richtigkeit des Sollkonzepts als Maß für den Projekterfolg. Allerdings kann dieses Vorgehen interne Konflikte bei den Kunden verursachen. Da in der Praxis hinter einer verdrängten Funktionalität häufig ein anderer Verantwortlicher steht als hinter der neuen, die es nun in den Scope des Projekts geschafft hat, werden die unterschiedlichen Stakeholder jeweils um den Erhalt ihrer Funktionalitäten ringen. Deshalb ist ein starker Product Owner ein kritischer Erfolgsfaktor für dieses Vorgehen. Er sollte über einen profunden Rückhalt im Lenkungsausschuss und in der gesamten Organisation verfügen.
Neben dem ständigen Ringen um die Prioritäten führt das agile Modell noch zu weiteren Herausforderungen im Projekt. Nehmen wir einmal an, dass eine Funktion der Finanzbuchhaltung eine Funktion des Vertriebs aus dem Release verdrängt, so stellt sich unmittelbar die Frage, ob dafür überhaupt die geeigneten Ressourcen für das Projekt eingeplant sind, oder ob durch die neue Priorität Engpässe bei bestimmten Projektmitarbeitern entstehen.
Sie sehen, dass es hinsichtlich des Projektvorgehens manches zu beachten gibt. Somit ist es für Projekte, die mit SAP Activate umgesetzt werden, wichtig, die üblichen Erfolgsfaktoren Zeit, Geld und Qualität unter geänderten Vorzeichen zu betrachten.
Bevor wir dies in Kapitel 5 beginnen, möchte ich ein paar Begriffe einführen, die dem Verständnis des Modells dienen, da sie die Methode gliedern, ihr also eine überschaubare Struktur geben.
3 Unterschiedliche Ausgangsvoraussetzungen
Jeder Kunde, der SAP Activate im Rahmen einer S/4HANA-Implementierung einsetzen möchte, kommt aus einer ganz eigenen Historie. Dennoch lassen sich diese unterschiedlichen Ausgangslagen gruppieren. Die SAP spricht hier von unterschiedlichen Transitionspfaden (Transition Paths).
Ganz grob lassen sich zunächst einmal drei Transitionspfade unterscheiden:
System Conversion: Hierbei handelt es sich um eine mehr oder minder technische Überführung eines vorhandenen SAP-ERP-Systems in ein S/4HANA-System. Technische Neuerungen werden dabei ggf. eine Zeit lang ausgeblendet, bzw. nur in zwingend erforderlichem Umfang berücksichtigt. Der Kunde möchte im Grunde sein bisheriges System weiterbetreiben und zieht auf S/4HANA um, damit er nicht aus der Wartung läuft und seine bisher in das System gesteckten Investitionen erhalten bleiben. Dieser Umzug wird häufig als Brownfield Approach bezeichnet. Für die System Conversion stellt die SAP den Software Update Manager bereit. Dieser Transitionspfad führt regelmäßig zu einer S/4HANA-Installation auf kundeneigenen Systemen (On-Premise).
New Implementation: Die Ausgangsbasis kann zum Projektbeginn ein SAP- oder ein Non-SAP-System sein. Der Kunde entscheidet sich ungeachtet des vorhandenen Systems dazu, auf der grünen Wiese zu beginnen. Bei der Übernahme der Daten aus dem Altsystem unterstützt das S/4HANA Migration Cockpit. Mitunter wird dieser Ansatz Greenfield Approach genannt. Dieser Transitionspfad ist auch für Unternehmen geeignet, die bisher noch kein ERP-System einsetzen. Dabei kann das angestrebte S/4HANA-System sowohl in der Cloud als auch On-Premise liegen.
Selective Data Transition: Bei diesem Transitionspfad geht es um den Investitionsschutz des bisherigen Bestands. In bestimmten Unternehmensbereichen oder Prozessen soll ein Prozess-Redesign vermieden werden, wohingegen andere Prozesse oder Unternehmensbereiche aktiv neu zu gestalten sind. Die SAP stellt hierfür das Tool Landscape Transformation bereit. Das Zielsystem ist entweder ein On-Premise-System oder die S/4HANA Cloud Single Tenant Edition (Kunde hat ein eigenes, physikalisch von anderen Kundensystemen getrenntes SAP-System). Dieses Vorgehen wird mitunter als Bluefield Approach bezeichnet.
In Abhängigkeit vom gewählten Transitionspfad und dem Zielsystem (Cloud oder On-Premise) ändern sich die Aufgaben in den unterschiedlichen Phasen des Projekts leicht. Daher ist es wichtig, dass diesbezüglich schnell Einigkeit und Klarheit hergestellt wird. Beachten Sie bitte, dass im Roadmap Viewer jeweils angepasste Versionen der Unterstützung existieren. Ebenso sind für den einen oder den anderen Transitionspfad spezifische Beschleuniger vorhanden.
4 Struktur der Methode
Im ausklingenden letzten Jahrtausend bin ich noch in nahezu jedem SAP-Projekt auf ein anderes Vorgehensmodell gestoßen. Im Grunde folgte jedes Beratungsunternehmen seiner eigenen Methodik. Zwar ähnelten sich alle Projekte dahingehend, dass sie wasserfallbasiert und in Phasen gegliedert waren, aber sowohl die Anzahl der Phasen als auch die Begrifflichkeiten waren stets ein wenig anders. Heute stellt die SAP all ihren Kunden und Partnern die Activate-Methode inkl. Beschleuniger und jeder Menge Informationsmaterial zur freien Verfügung. Daher lohnt es sich, einen genaueren Blick auf die Struktur der Methode und ihre Begrifflichkeiten zu werfen. Anders als bei ASAP scheint sich dieses Vorgehensmodell am Markt zunehmend durchzusetzen.
Die strukturierenden Elemente der Methode werden wie folgt bezeichnet:
Phase – Eine Phase beschreibt einen bestimmten Fortschritt im Projekt. Jede Phase endet mit einem sogenannten Quality Gate, also mit einer Prüfung, ob die für die Phase geplanten Aktivitäten erfolgreich abgeschlossen wurden. Abbildung 4.1 zeigt z.B. die Deploy-Phase.
Workstream – Workstreams (linke Spalte in Abbildung 4.1) beschreiben Bündel zusammenhängender Aufgaben. Ein Workstream, z.B. das Projektmanagement in der Abbildung, kann mehrere Phasen überspannen.