SAP Activate
Die Einführung von SAP Produkten mithilfe der SAP Activate Methode

Betrachtet man die Kundenseite, so gibt es drei übliche Ausgangslagen:

• Eine Neueinführung, sprich es gibt noch keine entsprechende Software (hier bietet sich der sogenannte Greenfield Approach an)
• Eine System Conversion, meint der Kunde verwendet bereits eine SAP Software (Brownfield Approach oder Selective Data Transition)
• Eine Landscape Transformation, was bedeutet, dass der Kunde ein System hat, dieses aber nicht von der SAP ist.

Für alle drei Ausgangslagen bietet SAP Activate ein Framework aus Content, Tools und dem methodischen Vorgehen, um die zukünftige SAP Landschaft entweder On Premise, also beim Kunden zu installieren, oder um das System in der Cloud zu betreiben, oder ggf. auch in einem hybriden Modell, also einer Mischung aus Cloud und On Premise Installationen. Beim Greenfield Approach wird das System neu aufgesetzt, man startet sozusagen auf der grünen Wiese und versucht dabei möglichst nah am Standard der Software zu bleiben. Beim Brownfield Approach hingegen geht man davon aus, dass Prozesse und Daten des bisher existierenden Systems weitgehend auch in der neuen Umgebung zur Verfügung gestellt werden müssen. Den Ansatz Selective Data Transition wählt man üblicherweise immer dann, wenn eine intensive Auseinandersetzung mit den Datenbeständen unverzichtbar ist. Dies könnte zum Beispiel zutreffen, wenn ein Carve Out, also eine Abspaltung eines Unternehmensteils vorgenommen werden soll.

Das verflixte Projektdreieck

Alle Projekte, egal nach welcher Methode sie gelenkt werden, unterliegen einem Dreigespann von Zielen, die regelmäßig zu Konflikten führen: Zeit, Geld und Qualität. In der Literatur wir in diesem Zusammenhang oft vom magischen Zielkonfliktdreieck gesprochen, das es aufzulösen gelte. In vielen Projekten versucht man daher diese drei Ziele im Rahmen eines Konzeptes aufzuschreiben, um sicherzustellen, dass die Projektpartner ein einheitliches Zielverständnis haben. Diese Konzepte wurden häufig als Fachkonzept, Sollkonzept oder Business Blueprint bezeichnet aber auch Begriffe, wie Pflichtenheft oder Lastenheft finden dafür Verwendung.

Da im Grunde kein Projekt zu 100 % genau planbar ist, kommt es regelmäßig zu Abweichungen. Stellt also das Dreieck die Summe aller Tätigkeiten dar, so wird schnell deutlich, dass jedes unvorhergesehene Ereignis zu einer Ausdehnung der Grundfläche führen wird. Kommen also unvorhergesehene Tätigkeiten auf das Projekt zu (= Veränderung der Qualität), so hat das  automatisch Auswirkungen auf den Zeitbedarf und die Kosten. Man spricht hier von einem sogenannten Change Request. Ein Change Request beschreibt in Ergänzung zum bisherigen Konzept die neuen Anforderungen (ebenfalls hinsichtlich der Qualität und des Geld- und Zeitbedarfes). Dies ist in vielen Projekten der Vergangenheit ein Auslöser für Auseinandersetzungen der Projektpartner gewesen. Oft wurde gestritten, ob es sich überhaupt um einen Change Request handelte und ob der dafür ermittelte Aufwand korrekt ist und wer die dadurch entstehenden Kosten zu tragen hat.

Neu an SAP Activate – und einem agilen Vorgehensmodell ganz allgemein – ist nun im Grundsatz, dass man versucht das Budget und die Zeit nicht zu verändern. Stattdessen wir die Qualität angepasst, das heißt der Kunde kann und darf jederzeit die Qualität des Projektes anpassen, muss dann aber darüber nachdenken, welche bisher gewünschten Anforderungen zugunsten der neuen Anforderung aus dem Projektumfang herausgenommen werden. Es wird also über die Priorität entschieden, was ins jeweilige Release gelangt und was nicht. Dies kann entscheidend dazu beitragen, die Anzahl der atmosphärischen Störungen, die Change Requests in der Vergangenheit häufig ausgelöst haben, zu vermindern. Das Unternehmen selbst aber auch Produkte, Märkte und Technizität können sich im Projektverlauf ändern und somit zu angepassten Projektanforderungen führen. Der Kunde kann damit auf sich ändernde Rahmenbedingungen auch im Projektverlauf flexibel (agil) reagieren.

Agile Implementierung von Software, geht das überhaupt?

SAP Implementierungsprojekte dienen stets der Einführung von Software. Mithilfe der Software sollen reale Prozesse der Wertschöpfungsketten im Rahmen der Aufbau- und Ablauforganisation des Kunden geplant, erfasst und reportet werden.

Das links in der Grafik dargestellte Unternehmen soll in eine digitale Datenbank „gepresst“ werden, die vom Hersteller als Standardsoftware ausgeliefert wird. Regelmäßig kann die Standardsoftware das Unternehmen und dessen Prozesse nicht „out-of-the-box“ abbilden. Daher geht es im Projekt darum, die erforderlichen Anpassungen vorzunehmen. Dazu sind zwei Wege denkbar:

Das Unternehmen bewegt sich auf die Standardprozesse der Software zu, passt also seine Aufbauorganisation und die Ablauforganisation an die Standards der Software an. Man nennt diese organisatorischen Anpassung auch Organisation Change Management (OCM). Die zweite Möglichkeit besteht darin die Standardsoftware an das Unternehmen anzupassen. Dies geschieht besipielsweise über:

• Customizing (vom Softwarehersteller vorgesehene Anpassungsmöglichkeiten)
• User Exits (Anpassungen an bestimmten vom Hersteller der Softwarevorgesehenen Schnittstellen durch kleine Programme)
• Programmierung (z. B. in ABAP)
• Anbindung von Software anderer Hersteller (Interfaces).

Diese Projektherausforderungen begleitet SAP Activate in vier Kernphasen des Projektes, denen eine Discoverphase vorangestellt werden kann. Die Discoverphase dient dazu, die Möglichkeiten der Standsoftware auszuloten, ohne gleich ein komplettes Projekt starten zu müssen. Das Motto ist quasi: Entdecke die Möglichkeiten, welche die Standardsoftware bietet.

Die Kernphasen sind:

• Preparephase: Alle für das Projekt erforderlichen Vorbereitungen werden getroffen, die Rahmenbedingungen des Zielkonfliktdreiecks werden gesetzt: Zeit – bis wann wollen wir ein erstes Release fertig haben, mit wem und mit welchen Mitteln (interne und externe Resourcen, Projekträume, usw. = Geld) und was sind die Zielstellungen des Projektes (Qualität).
• Explorephase: Basierend auf einer vorbereiteten Standardsoftwareumgebung findet ein Abgleich der Unternehmensrealität und der Standards der Software statt. Dies wird häufig als Fit-Gap-Analyse oder auch als Fit-to-Standard-Analyse bezeichnet. Am Ende dieser Phase steht ein sogenannter Backlog zur Verfügung, der alle Projektanforderungen in einer Liste erfasst und priorisiert.
• Realizephase: hier geht es darum die in der Explorephase beschriebenen Anforderungen umzusetzen. Dies erfolgt in fixen Zeitrastern, sogenannten Sprints. Innerhalb eines Sprints werden also Anforderungen aus dem Backlog umgesetzt und im Idealfall auch sofort an die zukünftigen Benutzer übergeben, mindestens aber zeigt man ihnen die Ergebnisse des Sprints in einer Demo (Review).
• Deployphase: Bereitstellung der Software mit Abschaltung des bisherigen Systems. Dazu gehört auch die Vorbereitung der Endbenutzer, des Systembetriebs, kurzum alle Tätigkeiten die für die produktive Nutzung des Systems erforderlich sind.

Danach wird die Software produktiv genutzt. SAP spricht hier noch von einer den eigentlichen Kernphasen des Projektes nachgelagerten Runphase.

Insbesondere die Explore- und Realize-Phase bieten den Kunden agile Vorgehensweisen an. Und ja, das kann ausgezeichnet funktionieren, wenn man sich auf die neue Methodik einlässt.

Fit-to-Standard-Analysen dienen dazu, darüber nachzudenken, ob nicht auch durch kleine Anpassungen im Prozess oder der Aufbauorganisation so gearbeitet werden kann, wie der Standard der Software es vorsieht. Und ich kenne kaum eine Unternehmung in der SAP verwendet wird und wo es in der Vergangenheit nicht geheißen hätte: „Wir wollen zurück zum SAP Standard!“ Allein, wenn es dann um das dadurch erforderliche werdende Changemanagement geht, ist dafür keine Zeit und die Software wird dann doch wieder so „verbogen“, dass man nach dem Standard suchen muss.

In der Realize-Phase wird in Sprints vorgegangen. Und wenn es dann darum geht ein tägliches! 15-minütiges Meeting am Morgen zu ermöglichen, wird darauf verzichtet. Wir haben Gleit- oder auch keine Zeit dafür, es gibt zu viele davon, … Diese Liste der „Ausreden“ ist beliebig erweiterbar. Wen wundert es dann, dass die Abstimmung in den Teams nicht funktioniert und dann wird vom Management eingegriffen und Teamleads ersetzen den bisherigen Moderator und Organisator (SCRUM-Master), so dass den Teams wieder die Eigenverantwortung genommen wird, die Ihnen die Methode eigentlich zuschreibt.

Findet dieses tägliche Meeting jedoch regelmäßig statt, so führt der SCRUM-Master diese an einem sogenannten SCRUM-Bord durch. Aufgaben werden auf Haftnotizen notiert und somit die Verantwortung jeder Aufgabe für jeden Projektmitarbeiter ersichtlich von einem Tag zum nächsten besprochen.

Welche Aufgabe habe ich gestern erledigt, welche werde ich heute erledigen, und von wem und wofür benötige ich dazu Unterstützung. Das hilft bei der Zusammenarbeit und es bleibt nichts aus Versehen liegen.

Genau dies passiert aber häufig, wenn die Methode und dieses Meeting nicht konsequent zur Anwendung gelangen. An dieser Stelle könnte ich jetzt noch viele weitere Beispiele liefern, welche die Methode aushebeln. Doch wenn Ihr Unternehmen noch gar nicht „Fit for Agile“ ist, dann lassen Sie es doch! Sie haben doch auch in der Vergangenheit erfolgreich Projekte abgeschlossen! Oder etwa nicht?

SAP Activate jedenfalls hat alle Tools und Methoden eines herkömmlichen Vorgehens (wasserfallbasiert), sofern beim Kunden (On Premise) installiert wird im Framework. Für Deployments in die Cloud (z.B. HANA Enterprise Cloud, EC), bevorzugt man in Walldorf jedoch inzwischen das agile Vorgehensmodell.

Mit SAP Activate durchgeführte Projekte können sehr erfolgreich sein. Sollten Projekte dennoch scheitern, so liegt dies – wie auch in der Vergangenheit – jedoch nicht am Vorgehen, sondern meistens an einem der folgenden Gründe:

• Das Projekt war zu groß angelegt à Komplexität zu groß
• Das Projekt war für einen zu langen Zeitraum angelegt à Veränderung der Projektrahmenbedingungen im Zeitverlauf zu vielvältig
• Es gab zu viele Projektbeteiligte à Kommunikation schwierig

Derzeit ist die größte Hürde, dass die Sau »AGILE« zwar ordentlich durchs Dorf getrieben wird, aber sowohl auf der Seite der Implementierungspartner, als auch auf der Seite der Kunden nur wenige nachgeschaut haben, wie diese Sau den wirklich läuft. Es fehlt an Methodenkenntnis und es mangelt an Bereitschaft zu ernsthaften Veränderungen im Projekt.

So sieht man bedauerlicherweise auch Projekte, in denen zwar zunächst ein Konzept (teilweise herunterdefiniert bis auf Feldebene der Software) geschrieben wird, um dann zu „Sprinten“. Auch das erweist sich regelmäßig als Irrweg. Der beliebige Mix der Methoden funktioniert am Ende auch nicht. Wer sich für SAP Activate entscheidet, sollte sich die Zeit nehmen, diese Methode zu verstehen (SAP Activate Seminar). Anderenfalls wurde gerade der erste Stolperdraht im Projekt ausgelegt.

Agile Projekte leben von einer sehr hohen Eigenverantwortlichkeit der Projektteams. Diese lange Leine zu lassen, ist nicht jedem gestandenen „Projekthaudegen“ des vergangenen Jahrtausends gegeben. Manchmal muss man dafür auch Mitarbeiter, die bisher in der zweiten oder dritten Reihe standen, im agilen Projekt nach vorne holen. Oft haben diese dann sogar mehr Zeit als die erfahrenen, häufig mehrfachen Belastungen ausgesetzten, Spieler der ersten Reihe. Das fördert die Motivation und ist dem Projekt zuträglich.

Es erfordert aber Mut in der Unternehmensleitung. Haben Sie den Mut? Dann sprechen Sie doch mal mit uns, gerne helfen wir Ihnen dabei den Weg in diese Methode zu beschreiten.