Wie schön wäre es, wenn die klassische Wasserfallmethode in IT-Implementierungsprojekten funktionieren würde. Fast, wie in einem Traum: Vogelgezwitscher, ein Wasserfall aus dem bereits an der Quelle eine exakte bottom-up aufsummierte Aufwandsschätzung und ein realistischer Terminplan entspringt. Im weiteren Verlauf am ersten Meilenstein im glasklaren Wasser kommt ein Blueprint an die Oberfläche, der das perfekte Lösungsdesign für alle denkbaren Anforderungen detailliert enthält, und dann weiter flussabwärts eine Implementierung ohne Strudel, Untiefen und Change Requests. Das war ein schöner Traum und nun ab in die Realität…Nach Jahrzehnten der unermüdlichen, aber vergeblichen Versuche ist es Zeit, die Methoden anzupassen. Hybrid-agil ist der Stand der Technik.
Agil – ernsthaft? Das wo jeder macht, was er will und niemand weiß, wann und zu welchem Preis das Implementierungsprojekt abgeschlossen sein wird, soll der Schlüssel zum Erfolg sein? Diese oder ähnliche Vorbehalte höre ich oft.
SAP Activate Methode – Eine Lizenz zum Geld drucken!
Lassen Sie es mich Ihnen anhand der SAP Activate Methode und einem einfachen Vergleichsbeispiel, wie dem Bau eines Eigenheims, erklären: Die SAP Activate Methode ist eine strukturierte Herangehensweise zur Planung und Umsetzung komplexer SAP-Lösungen während Projektimplementierungen. Sie besteht aus fünf Phasen: Discover, Prepare, Explore, Realize und Deploy, auf die ich im Folgenden näher eingehen werde:
Discover Phase
In der Discover Phase geht es um das Scoping. Welche Themen stehen an, welche Software und Module kommen in Betracht? Greenfield, Brownfield, Conversion? Soll es ein Einfamilienhaus im Grünen oder ein Mehrfamilienhaus in City-Lage werden? Schlüsselfertig oder mit Eigenleistung?
Oft ist diese Phase eine Vorphase, die Bauunternehmen und Beratungshäuser als Pre-Sales verbuchen. Es geht dabei noch nicht um die Entwicklung von konkreten Lösungsideen, sondern darum, eine möglichst fundierte Basis für die nachfolgenden Überlegungen und Schritte zu erarbeiten.
Sie haben ein Bauunternehmen bzw. Beratungshaus gefunden, das jetzt schon eine finale Aufwandsangabe macht und einen detaillierten Terminplan abgibt? Das ist unprofessionelle Wahrsagerei. Ohne Lösungsdesign, ohne konkrete Definition der Aufgabenteilung, ohne Bodengutachten, etc. ist das unplausibel. Beraten hat nichts mit raten zu tun! Werfen Sie die Kollegen raus und geben Sie den Nächsten auf Ihrer Shortlist eine Chance!
Was Sie erwarten können, ist eine auf dem Scoping basierende Aufwandschätzung anhand von gewichteten Erfahrungswerten. Ein Bauunternehmer überschlägt die Baukosten grob aus der Anzahl Kubikmeter umbauten Raumes multipliziert mit einer Konstante, die das von Bauherren gewünschte Ausstattungsniveau repräsentiert. Genauso machen es auch professionell arbeitende IT-Berater. Sie gewichten die üblichen Implementierungsaufwände für das ermittelte Scope mit Komplexitätsfaktoren, die sie in den Discover-Workshops ermittelt haben.
Prepare Phase
Wenn diese initiale Schätzung grob ins Budget passt und die in der Discover-Phase in Augenschein genommenen Musterhäuser – pardon – Demosysteme die Anforderungen potenziell abzudecken scheinen, erfolgt nun in der Prepare Phase die organisatorische Projektvorbereitung. Diese beinhaltet Teamdefinition, Projektnormen, Projektinfrastruktur und solche Dinge… Am Ende beauftragt man die Architekten mit der Erstellung des Lösungsdesigns.
Explore Phase
In der Explore Phase nimmt man zunächst die Standard-Funktionen in Augenschein. So wie der Bauunternehmer durch Musterhäuser führt, führt der Berater durch die Best Practices der relevanten Systeme und Module. Dabei werden Fragen, Änderungswünsche und Ideen als User-Stories aufgenommen und in Aufwandskategorien unterteilt.
Für jeden dieser Punkte machen die Solution Architekten Lösungsvorschläge und bepreisen diese. Zum Listenpreis für das Musterhaus kommen somit die Kosten für die Anpassungswünsche hinzu.
Auch wenn die Best Practices nicht zwingend schon die endgültige Lösung darstellen, sind sie als Startpunkt sehr sinnvoll. Die Projektteams erhalten sehr früh eine konkrete Vorstellung vom Lösungsraum und der Fokus wandert automatisch auf die prominentesten Gaps.
Früher entstand ein von Standards mehr oder weniger entferntes Lösungsdesign (vulgo „Blueprint“) oft ausgehend von einem weißen Blatt oder gar auf Basis einer ausufernden Ist-Analyse, die obendrein den Fokus auf das Altsystem nochmals zementierte. Berater, die die Geschäftsprozesse der Kunden nur vom Hörensagen kannten, redeten mit Process Ownern, die SAP noch nie gesehen hatten – wie Blinde, die sich über die Farben des Regenbogens austauschen. Das war Papierverschwendung – nicht nur des weißen Blattes, sondern auch von tausenden bunt bedruckter Zettel, die aus der Kasse der Kunden flattern. Die Lernkurve hat sich zum Glück aber auch in der Wasserfallmethode durchgesetzt. Wer hat einen Blueprint jemals 1:1 umgesetzt, oder nach dessen Fertigstellung auch nur jemals wieder gelesen? Nachdem Gaps und Lösungsdesign priorisiert, genehmigt und in Bauabschnitte (Sprints) eingeteilt wurden, beginnt die Bauphase. Im besten Fall passt die Aufwandssumme noch in die initiale Schätzung. Falls nicht, muss Scope gestrichen oder Geld und Zeit nachgelegt werden. Das kann man jetzt aber an konkreten Themen festmachen. Spätestens jetzt ist klar, dass man diese „Be-Rater“ seinerzeit mit Recht vom Hof gejagt hat.
Realize Phase
Erst hier wird es richtig agil. In der Realize Phase werden die Inhalte der Sprints abgearbeitet. Die Sprints sind von Anfang an fest terminiert und in den Sprint Reviews wird Bauabschnitt für Bauabschnitt in Augenschein genommen.
Was nicht fertig wurde oder nicht passt, wandert in den nächsten Sprint und verdrängt dort gemäß seiner Priorität andere Dinge in nachfolgende Sprints. Einzugstermin und Budget bleiben stabil, solange alle Sprints des ersten geplanten Implementierungs-Releases noch alle Muss-Anforderungen abdecken. Abweichungen vom geplanten Sprint-Fortschritt werden früh sichtbar und zwingen das Projekt zu entscheiden, was zur Kompensation herhalten muss. Inhalt oder Zeit und Geld in Form eines weiteren Sprints oder erweiterter Ressourcen?
Diese Vorgehensweise stellt ebenfalls sicher, dass alle Teams an denselben Bauabschnitten arbeiten und nicht ein Team bereits kundenspezifische Funktionserweiterungen ausprogrammiert, während alle anderen Teams noch an den Standardprozessen arbeiten. Was hat der Gärtner beim Rohbau zu suchen? Seine Pflänzchen würden noch x-mal von den Bauarbeitern zertrampelt.
Deploy Phase
Nach erfolgreichem Abschluss der Integrationstests werden die Daten in den Möbelwagen gepackt und ins neue Heim gefahren. Das ist eine intensive und schwere Arbeit mit langen Tagen, aber eben auch einem gemeinsamen Abendessen auf dem Küchenboden und dem guten Gefühl, dass das gemeinsame Werk bald abgeschlossen sein wird. In den ersten Tagen nach dem Einzug gibt es noch jede Menge Fehler abzustellen und Optimierungspotentiale zeichnen sich auch schon deutlich ab. Es ist wichtig, dass alle Handwerker und Berater in Rufweite bleiben. Diese Hypercare-Phase des Deploys kühlt naturgemäß immer weiter ab und mündet mit fließendem Übergang in den dauernden Support des Tagesgeschäfts. Entweder übernehmen das die internen Kräfte, oder es gibt eine Run-Phase mit externem Support.
Vergleich zur hybrid-agilen Methode
Hybrid-agile Methoden respektieren die unvermeidliche Erkenntniskurve der Process Owner und Berater genauso, wie sich ändernde Anforderungen und Gegebenheiten. Wenn die Methode mit adäquaten Tools unterstützt wird, ist sie jederzeit transparent, nachprüfbar und kommt zum optimalen Ergebnis. Gerade in der Wasserfall-Ära war Blindflug angesagt, bis die Spatzen von den Dächern pfiffen, dass es nicht planmäßig gelaufen ist. In der Regel waren die Change-Requests teurer als die auf Basis des „Blueprints der Blinden“ initial geschätzten Aufwände. In der agilen Methodik sind Termine und Budgets sogar sicherer als in der Wasserfall-Welt. Wenn es knapp wird, müssen aber auch hier Zugeständnisse gemacht werden. Das trifft dann aber nur Themen, die im Backlog niedrig priorisiert sind.
Agile Projektmethoden als entscheidende Komponenten für den Implementierungserfolg
Wie Sie sehen, ist die agile Projektmethodik ein Erfolgsfaktor für eine gelungene SAP-Implementierung in einem Unternehmen. Sie könnte der Schlüssel zu Ihrem Erfolg und Ihre Lizenz zum Geld drucken sein.
