Sprechen wir über agile Projektmanagementmethoden in SAP Projekten

(Last Updated On: 3. Juli 2017)

„Agile“ ist seit Anfang 2000 das neue Buzzword im Projektmanagement. Vor allem in Software-Entwicklungsprojekten finden agile Vorgehensmodelle bevorzugt Anwendung. Dabei gibt es schon beinahe eine Unsumme an vorpaketierten Konzepten, derer man sich bedienen kann. Darunter wären beispielsweise Scrum, Extreme Programming, Kanban und viele mehr. Dabei bleibt das Einsatzspektrum einiger dieser Vorgehensmodelle nicht auf die Software-Entwicklung beschränkt.

So gibt es auch Modelle speziell für die Produktentwicklung in der New Economy, das Gründen eines Startups usw. Im SAP-Umfeld haben sich einige Denkansätze und Vorgehensmodelle durchgesetzt, nicht zuletzt da SAP auch ihre eigenen Frameworks anbietet. Wir beleuchten die wichtigsten Ideengeber im Projekt- und Produktmanagement und zeigen auf, wo sie eingesetzt werden.

Design Thinking

Design-Thinking ist eine Methodik zur Weiterentwicklung von Unternehmen in den Bereichen Innovation & Disruption. Dadurch soll die Zukunftsfähigkeit eines Unternehmens gewährleistet werden. Design Thinking ist also kein Framework für das klassische Projektmanagement per se. Viel mehr wird es im Rahmen eines Projektes zur Neugestaltung eines Unternehmens genutzt. In aller Regel wird Design Thinking genutzt um

  • Produkte
  • Dienstleistungen
  • Geschäftsprozesse
  • Vertriebsmodelle und Marketing
  • Management-Techniken

usw. zu verbessern. Das heißt Design Thinking bezeichnet kurz gesagt einen Ansatz, der einen kontinuierlichen Verbesserungsprozess in Bereichen eines Unternehmens etabliert, die einem ständigen Wandel unterliegen.

Design Thinking lebt davon, sich mit den Bedürfnissen der Kunden auseinander zu setzen. Das klingt zuerst nicht nach einer wirklich neuen Erkenntnis. Der Teufel steckt hier im Detail. Viele Unternehmen versuchen heutzutage, Ihr Produkt nach dem „höher, schneller, weiter“-Prinzip weiter zu entwickeln. Das heißt beispielsweise im Fahrzeugmarkt, dass immer mehr versucht wird, die Leistung eines Fahrzeugs zu steigern oder dessen Spritverbrauch weiter nach unten zu drücken.

Im Endeffekt ist das mitunter aber nicht unbedingt das, was der Kunde möchte. Natürlich kann es sein, dass ein Kunde einen starken Wert auf einen geringen Spritverbrauch oder eine enorme Leistung legt. Jedoch hat der Kunde in aller Regel einen ganzen Topf aus Bedürfnissen. Einige Bedürfnisse, wie etwa geringer Spritverbrauch oder hohe Leistung, stehen zunächst hierbei zunächst im Vordergrund. Ab einem gewissen Erfüllungsgrad dieser Bedürfnisse jedoch treten diese in den Hintergrund.

So macht es für einen Sportwagenfahrer beispielsweise gar nicht mehr so einen großen Unterschied, ob er ein Fahrzeug mit 200 oder 300 PS fährt. Dafür treten bei diesem Erfüllungsgrad neue Bedürfnisse plötzlich in den Vordergrund. So kann es etwa sein, dass bei dieser Leistungsklasse der Fahrer mehr Wert auf den Komfort während des Fahrens unter Höchstgeschwindigkeiten legt. Es ist ihm also nicht mehr so wichtig, ob er nun dank 100 PS mehr noch wesentlich schneller von 0 auf Tempo 250 km/h kommt als bisher. Stattdessen ist ihm wichtig, dass er bei Tempo 250 km/h nun bequemer fahren kann, als zuvor.

Design Thinking lebt stark von der Analyse der Kundenbedürfnisse

Design Thinking lebt stark von der Analyse der Kundenbedürfnisse

Auch Einfachheit ist  häufig ein wichtiges Bedürfnis, welches beim Kunden ab einem bestimmten Erfüllungsgrad seiner Primärbedürfnisse an Wichtigkeit zu nimmt.  So greifen viele Kunden bewusst lieber zu einem Produkt, welches ein schlechteres Preis-/Leistungs-Verhältnis bietet, dafür aber einfacher zu bedienen ist oder weniger oft gewartet werden muss. Hierbei steht der Spaß am Produkt im Vordergrund.

Ein aktuelles Beispiel des Trends zum Design Thinking ist das Buzzword des „Smart Livings“ oder des „Smart Furniture“. Obwohl man eigentlich der Meinung sein könnte, dass es an einem klassischen Möbelstück wie einem Tisch oder einem Stuhl nicht mehr viel zu verbessern gibt, tut sich in diesem Markt aktuell recht viel. Jahrelang haben Unternehmen versucht, lediglich das Design und den Preis der Möbelstücke zu optimieren.

Was lange Zeit außer Acht gelassen wurde war die Frage „Wie nutzen unsere Kunden überhaupt ihre Möbel“. So kam häufig auch heraus, dass Stühle des öfteren als Ersatz für Tische und Leitern genutzt werden. Aus dieser Erkenntnis wurden dann Stühle entwickelt, die sich entsprechend transformieren lassen. Eine weitere, sehr einleuchtende Erkenntnis ist die, dass in den meisten Haushalten ein Bett am Tag gar nicht genutzt wird – oder höchstens als Ablage für verschiedene Dinge. Daraus entstanden Betten, die sich an der Wand montieren und ausklappen lassen. Solange sich das Bett an der Wand befindet, können daran Kleidungsstücke aufgehangen und an ausklappbaren Tischen Alltagsgegenstände abgelegt werden.

Design Thinking ist also ein Denkansatz, der sehr stark auf die Innovation oder Disruption eines bestehenden Produktes ausgelegt ist, und dazu sehr stark auf Nebenbedürfnisse eingeht.

Beim Design Thinking unterteilt sich in die folgenden Phasen

  • Eintauchen
  • Fokussieren
  • Ideen kreieren
  • Prototypen produzieren
  • Testen

Dabei muss man nicht immer alle Prozesse durchlaufen. Grundsätzlich handelt es sich aber, wie weiter oben schon angeschnitten, um einen kontinuierlichen Prozess. In der Praxis kann das Ganze so aussehen, dass man zunächst in den Markt für ein Produkt eintaucht und sich an sieht, wie die Kunden ein bestimmtes Produkt nutzen. Es werden Erkenntnisse gesammelt.

Man fokussiert sich dann auf eine zentrale Erkenntnis, wie etwa, dass ein Bett den Großteil ungenutzt in einem Zimmer rum steht und es doch ganz praktisch wäre, wenn man das Bett in dieser Zeit „aus dem Weg räumen“ könnte, um Platz für andere Dinge oder Aktivitäten zu haben. Aus diesem Fokus heraus kreiert man nun Ideen, wie etwa die Idee, das Bett an die Wand zu schrauben und hoch zu klappen. In der nächsten Phase stellt man sich die Frage „Wie schaffen wir das?“ und erstellt erste Prototypen, die im Anschluss in der Folgephase getestet werden – und zwar von der Zielgruppe.

Man macht in der Testphase den Prototypen als Produkt für den Kunden erlebbar und entnimmt hier wichtige Erkenntnisse für die nächste Iteration des Design Thinking Zyklus. Man kann nun eine neue Iteration anfangen und sich beispielsweise in dieser Iteration entweder einen neuen Fokus suchen (also etwa die Tatsache, dass ein Bett häufig passiv als Gepäckablage oder Kleiderständer genutzt wird) oder den bestehenden Fokus (aus dem Weg räumen des Betts) intensivieren. Nach einer bestimmten Anzahl von Iterationen entsteht ein neues Produkt.

Design Thinking ist im SAP-Umfeld deswegen so wichtig, weil mit der Einführung von SAP S/4HANA ein großer Wert auf die Predictive Analysis gelegt wird. Damit soll dem Unternehmen das notwendige Werkzeug an die Hand gegeben werden, um „Design Thinking“ effizient umsetzen zu können.

Lean Startup

Lean Startup ist ein Framework, welches nicht ausschließlich auf Unternehmensgründungsprojekte abzielt. Vielmehr geht es hier, ähnlich wie beim Design Thinking, um die stetige Weiterentwicklung der Produkte und Dienstleistungen eines Unternehmens. Das Framework hat sich aus dem Trend heraus entwickelt, dass Startups heutzutage mit sehr wenig Overhead an Vorplanung und Organisation an den Markt gehen.

Das heißt im Gegensatz zu früher sind Startups heutzutage dazu bereit, mehr Risiken auf sich zu nehmen, um im Gegenzug schneller auf dem Markt zu sein. Der Lean Startup Ansatz adressiert diesen Umstand und gibt Unternehmen ein Vorgehensmodell an die Hand. Dieses Modell hilft Unternehmen dabei, mit einem minimalen Planungs- und Verwaltungsaufwand überlebensfähig, effektiv und effizient am Markt vorzugehen. Lean Startup ist auf keinen Fall ein Framework für eine Branche mit geringer Risikotoleranz. Ein Elon Musk hätte beispielsweise das „Lean Startup“-Framework auf keinen Fall für sein Raumschifffahrtsunternehmen SpaceX einsetzen können.

Ähnlich wie das Design Thinking lebt Lean Startup davon, die Bedürfnisse der Kunden genauer zu untersuchen und auf dessen Basis in Form von iterativen Zyklen Prototypen zu entwickeln, die das Produkt für den Endkunden erlebbar machen. Kunden sollen explizit dieses Prototypen testen und ihr Feedback abgeben. Auf Basis der Erkenntnisse wird das Produkt im nächsten Zyklus, dem nächsten „Sprint“ sozusagen, weiterentwickelt.

Desweiteren propagiert Lean Startup die Idee, dass zunächst ein sogenanntes „Minimal Viable Product“ (MVP) auf den Markt gebracht werden soll. Anstatt also beispielsweise erst auf den Markt zu gehen, wenn das vor-visionierte Endprodukt mit all seinen Features fertig ist, soll stattdessen bereits ein Produkt mit minimalem Feature-Set an den Markt gehen, um frühzeitig Erfahrungen zu sammeln.

Dabei nimmt man bewusst in Kauf, dass es für das MVP evtl. schon Konkurrenzprodukte mit weitreichender Akzeptanz gibt und daher die Konkurrenz in diesem Segment sehr hart sein wird. Lean Startup schätzt den Wert von „Markterfahrung“ sehr hoch ein und zielt daher, ähnlich wie Scrum, darauf ab, nach jedem Sprint ein „potentially shippable product“ zu produzieren, welches bereits auf dem Markt Überlebenschancen hat.

Warum ist Lean Startup im SAP-Umfeld so wichtig? Nun, das Framework ist vor allem für Startups interessant, welche darüber nachdenken, SAP S/4HANA einführen zu wollen. Denn viele der Denkansätze aus Lean Startup werden durch die User Experience und die expliziten Features von SAP S/4HANA unterstützt.

SCRUM

Scrum ist ein Management Framework, welches speziell für das agile Entwickeln von Softwarelösungen entwickelt wurde, an sich jedoch auch auf andere Projektumgebungen adaptiert werden kann. Scrum als agiles Entwicklungs-Framework steht dem klassischen Wasserfallmodell gegenüber.

Im Wasserfallmodell gibt es fest definierte Phasen, die eine nach dem anderen durchlaufen werden. Am Anfang steht die Planung eines Entwicklungs-Projektes.  In der nächsten Phase, der Build-Phase, wird das Produkt im Wasserfallmodell entwickelt. In der darauf folgenden Testphase wird das Produkt getestet und in der nächsten Phase, der Review-Phase, auf Basis der Testergebnisse noch einmal überarbeitet. Zu guter letzt, in der Deployment-Phase, wird das Produkt in den Markt gebracht.

Agile Vorgehensmodelle wie SCRUM haben häufig eine geringe Risikotolleranz

Agile Vorgehensmodelle wie SCRUM haben häufig eine geringe Risikotolleranz

Das Problem beim Wasserfall-Modell ist zum einen, dass nur ganz am Anfang des Projektes initial einmal eine Planung durchgeführt wurde. Nur in der Planungsphase achtet man auf wichtige Rahmenbedingungen wie die aktuelle Marktlage und die Bedürfnisse der Zielgruppe, der aktuellen technischen Entwicklung, die Konkurrenz, das Budget und das Risiko des Projektes. Nun kann aber, vor allen Dingen bei großen Entwicklungsprojekten, zwischen der initialen Planung eines Produktes und dem abschließendem Deployment eine lange Zeitspanne liegen, mitunter sogar Jahre.

Es ist durchaus einleuchtend, dass sich die Rahmenbedingungen, die man zu Beginn des Projektes in der Planung bewertet hat, im Laufe der Monate und Jahre immer wieder einmal ändern. Auf diese Veränderungen muss man reagieren, um zu verhindern, dass man am Ende des Projektes das falsche Produkt auf den Markt bringt oder das Projekt gänzlich scheitert. Ein weiteres Problem hierbei ist, dass die Planung am Anfang häufig das Projekt häufig noch nicht gänzlich bewerten kann, so dass die Anfangsplanung meistens diverse Mängel aufweist.

Im SCRUM-Framework wiederholt man die einzelnen Phasen des Wasserfallmodells und hält die einzelnen Phasen dafür kürzer. So plant man am Anfang eines SCRUM-Projekts nur in so weit vor, dass man mit dem Projekt beginnen kann. Man entscheidet sich also für das Produkt, welches man entwickeln möchte, entscheidet sich für technische Parameter wie etwa die Entwicklungsumgebung und das zu verwendende Framework und legt dann sofort mit der Build-Phase los.

In dieser ersten Build-Phase baut man ein minimales Feature-Set. Das könnte im Beispiel einer Redakteurs-Website etwa die Möglichkeit sein, dass man sich als User registrieren und einfache Text-Beitrage verfassen kann. Im Vergleich: Im Wasserfall-Modell hätte man an dieser Stelle das komplette Projekt durchgeplant und würde auf Basis dieser Planung versuchen, die komplette Webanwendung, also etwa das Redakteurs-System einer Online-Zeitung, auf einen Schlag zu erstellen. Nachdem wir aber in Scrum unser minimal Feature Set entwickelt haben, testen wir dieses Feature Set und reviewen es.

Nun beginnen wir einen neuen Zyklus. Auf Basis der Erkenntnisse des ersten sogenannten Sprints (einem kompletten Zyklus aus Plan, Build, Test und Review) planen wir nun den nächsten Sprint, in welchem wir ein weiteres wichtiges Feature Set entwickeln, etwa die Einbindung von Multimedia-Inhalten wie Bildern und Videos in unsere Artikel. So wiederholen wir diesen Prozess in mehreren Sprints.

Der Vorteil an diesem Vorgehen ist, dass wir unsere Arbeit am Endprodukt in kleinere Häppchen zerlegt haben. Nach jedem wichtigen Arbeitspaket erfolgt eine erneute Planung und somit eine Neubewertung des Projektes. Dies ermöglicht es uns, auf Veränderungen im Markt, in der Projektumgebung usw. zu reagieren. Nach jedem unserer Sprint erfolgt jeweils ein inkrementelles Deployment unseres Produktes.

Das muss nicht heißen, dass nach jedem Sprint ein Produkt heraus kommen muss, welches wir bereits auf dem Markt verkaufen können. Aber nach jedem Sprint sollte ein „Produkt“ heraus kommen, welches ein gewisses Feature Set beinhaltet, welches den Wert unseres Produktes steigert. Ein einzelner Sprint dauert im Scrum typischerweise zwischen 1-3 Wochen.

In Scrum gibt es 3 Schlüsselrollen, welche ausgefüllt werden müssen.

  • Der Product Owner ist dafür zuständig, das Feature Set des Produktes zu definieren. Der Product Owner hat die Ideen, die das End-Produkt ausmachen.
  • Der Scrum Master ist hauptsächlich dafür zuständig, das Team und den Scrum-Prozess zu schützen. Er soll also das Projektumfeld so agil wie möglich erhalten und Störfelder beseitigen. Er organisiert und betreut die Meetings und sorgt dafür, dass die dinge laufen.
  • Das Team arbeitet am Produkt, ganz gleich ob als Tester, UI-Designer oder Entwickler.

In SCRUM gibt es drei Artefakte, die geführt werden.

  • das Product Backlog ist das Dokument in welchem Product Owners eine priorisierte Liste mit Produkt-Features aufschreiben. Nach jedem Schritt wird das Product Backlog aktualisiert. Dabei kann es vor kommen, dass Features hinzu kommen, entfernt werden oder sich die Priorität einzelner Features noch einmal ändert
  • User Stories sind ein Weg  Produkt Features zu beschreiben. Sie haben das Format „Aus diesem Grund brauche ich das und das, damit ich dieses und jenes machen kann“. Sie sind aus der Sicht des Endkunden geschrieben.
  • Das Sprint Backlog enthält die User Stories mit der höchsten Priorität
  • Das Burndown Chart zeigt den Fortschritt eines Sprints anhand des Erfüllungsgrades der User Stories aus dem Sprint Backlog. Am Ende eines Sprintes solltenalle User Stories abgearbeitet sein.

In SCRUM gibt es drei wichtige Zeremonien, meistens in Form von Meetings.

  • Beim Sprint Planning werden die User Stories und deren relative Gewichtung im Projektverlauf diskutiert. Als Ergebnis des Sprint Planning wird häufig das Sprint Backlog produziert.
  • Der Daily Scrum ist ein sehr kurzes Steh-Meeting in welchem jedes Mitglied kurz berichtet, was es aktuell abgeschlossen hat. Desweiteren berichten die Mitglieder, wo sie gerade hängen oder evtl. Hilfe benötigen.
  • Der Sprint Review geschieht am Ende eines Sprints und hier wird die geleistete Arbeit dem Product Owner vorgestellt.

Diese Elemente zusammen geführt ergeben den SCRUM-Workflow. SCRUM ist im SAP-Umfeld vor allem bei Software-Entwicklungsprojekten beliebt, sowohl für externe als auch für interne Entwicklungsprojekte.

ASAP

ASAP steht für Accelerated SAP. Damit wird bereits von vornherein klar, dass ASAP auf die projektbezogene Einführung von SAP-Softwarelösungen spezialisiert ist. daher ist ASAP kein Ersatz für klassische Projektmanagement-Frameworks wie etwa PRINCE2 oder PMBOK.

ASPs besteht aus 6 Phasen.

  • Project Preparation
  • Business Blueprint
  • Realization Phase
  • Final Preparation
  • Go-Live
  • Operate

Project Preparation

In dieser Phase gilt es herauszufinden, was das Ziel und der Scope des Projektes ist. Welche Annahmen wurden damals bei der Initiierung des Projektes getroffen, und sind diese korrekt? Wer ist der Sponsor des Projektes und welchen Profit erhofft er sich aus dem Projekt? Welche Risiken begegnen uns in diesem Projekt, und wie müssen wir diese bewerten? In dieser Phase geht es also vor allen Dingen um die richtige Einordnung des Projektes im SAP-Kontext. In diesem Projekt wird auch das Projektteam zusammen gestellt. Das wichtigste Ergebnis dieser Phase ist der Erstentwurf des Projektplans mit seinen Anhängen.

Business Blueprint

In dieser Phase soll verstanden werden, wie der Prozess aktuell abgewickelt wird. Das heißt: Auch wenn ein Unternehmen sich von dem Projekt einen verbesserten Geschäftsprozess erhofft, so wird dieser Prozess meistens heute bereits abgebildet. Wie wird dieser Prozess derzeit vom Unternehmen realisiert? Welche Tools, Aufwände und Ressourcen stecken dahinter? Wie muss der Soll-Zustand aussehen, damit die in der Project Preparation-Phase ausgemachten Ziele erreicht werden können?

Wie stark ist der Unterschied zur Ist-Situation und welchen Aufwand bedeutet das. In dieser Phase wird unter anderem ausgemacht, was man selbst noch tun muss, um Prozesse zu halten, welche die SAP-Lösung noch nicht abdeckt. Als Ergebnis werden hier meistens Eigenentwicklungen oder der Bedarf nach Drittanbieter-Software ausgemacht. Logischerweise haben die hier identifizierten Aufwände noch einmal einen Einfluss auf den Projektplan. Das Ergebnis dieser Phase ist die Business Blueprint.

Hier wird der Prozess definiert, der mit der einzuführenden Lösung realisiert werden soll. Damit dieser Prozess einwandfrei funktioniert, müssen bestimmte Business Requirements erfüllt werden. Damit wiederum diese Business Requirements erfüllt werden können, müssen bestimmte IT-Requirements erfüllt werden.

Die IT-Requirements sind dann wiederum die Überleitung zu den dazu benötigten Software-, Hardware- und Management-Lösungen, die zur Erfüllung dieser Requirements beitragen sollen. Ebenfalls wird hier ein sogenannter Realization Estimate getroffen. Das heißt hier wird geschätzt, wie hoch der Scope des Projektes wirklich sein wird. Die Methodik ASAP hat in der Vergangenheit mehr und mehr an Bedeutung verloren, weil viele ihrer Grundsätze in die Nachfolger-Methodik „SAP Activate“ übergegangen ist.

Realization

In der Realization-Phase werden die Lösungen gebaut. Functional Consultants konfigurieren und customizen hier die Systeme, Es werden Sandboxing-Systeme aufgesetzt und Probeläufe für den Go-Live gestartet, User Acceptance Tests gefahren u. v. m. Es werden Eigenentwicklungen geschaffen, die entwickelt werden müssen, um die Gaps zu den Business Requirements schließen. In den Tests muss der Erfüllungsgrad dieser Requirements bestimmt werden. Das Ergebnis der Realization-Phase muss sein: Auf technischer und organisatorischer Seite ist alles so weit vorbereitet, dass man produktiv gehen könnte.

Final Preparation

Hier nimmt man die Ergebnisse der Realization-Phase und bereitet diese auf den Produktiv-Gang, den Go-Live, vor. Man bereitet das System für eine Migration vor, man bereitet die Anwender über Schulungen auf ihre neue Aufgabe vor, man automatisiert die Tests für den Go-Live usw.

Go-Live

Hier werden  die in der letzten Phase vorbereiteten Assets in den Produktivstatus überführt. Häufig führt man in dieser Phase beispielsweise eine Migration des Produktivsystems durch oder migriert die Daten eines veralteten Systems auf ein System mit neuerem Release. Nach dem eigentlichen Wechsel auf die neue Produktionsumgebung wird diese über (möglichst automatisierte) Tests verifiziert.
Erst wenn durch diese Tests verifiziert ist, dass alles so funktioniert wie gedacht, wird das System für den Produktivbetrieb frei gegeben.

Operate

In dieser Phase wird nun produktiv mit der neuen Umgebung gearbeitet und die Key User verwenden diese bereits in der täglichen Arbeit. In der Operate-Phase wird vermehrt Wert auf typische Anfangsschwierigkeiten nach einem Go-Live eingegangen. Beispielsweise wird der interne IT-Support durch externes Consulting in der Anfangsphase aufgestockt.

SAP Activate

Gleich vorweg: auch SAP Activate ist sehr stark auf SAP-Implementierungsszenarien zugeschnitten und ersetzt daher noch lange nicht die Tools und Methoden eines Technologie unabhängigen Standards wie PRINCE2 oder PMBOK.

SAP Activate ist vielmehr eine Kombination aus Brainware und technischen Tools, die das Deployment von SAP-Lösungen, insbesondere von S/4HANA, beschleunigen sollen. SAP Activate ist ein Innovation Adoption Framework.

Die Grundelemente von SAP Activate

Die Grundelemente von SAP Activate

Dabei ist SAP Activate insbesondere zugeschnitten auf die Adoption von neuen SAP-Innovationen. SAP Activate ist also ein agiles Vorgehen, welches sich vor allen Dingen dadurch auszeichnet, dass es sehr stark von Tools abhängig ist, wie beispielsweise vom SAP Business Explorer und dem SAP Solution Manager. Sie können kein effektives SAP Activate betreiben, wenn Sie die entsprechenden dafür vorgesehenen Tools nicht einsetzen.

SAP Activate befasst sich allerdings hingegen weniger mit klassichen Projektmanagementthemen wie Organisation, Risikomanagement, Fortschritt usw. Das heißt SAP Activate ersetzt keine dedizierte Projektmanagement-Methode, sondern ergänzt diese lediglich.

SAP Activate besteht aus drei Kernkomponenten

  • SAP Best Practices. Der Best Practices Content besteht in der Regel aus Dummy-Daten, einspielbarem Customizing in ein SAP S/4HANA-System, einer Geschäftsprozessdokumentation für die im Content geschilderten Praktiken und Testskripte zum Testen der Funktionalität des Best Practices Konzeptes. Kurz gesagt handelt es sich also um vorkonfigurierte Geschäftsprozesse.

    Dies sind häufige Prozesse, die SAP-Kunden bei der Adaption der neuen Technologie abbilden wollen. Dabei wurde die Konfiguration und Dokumentation dieser Prozesse an die Erfahrungen von SAP und einigen Kunden angepasst. Die Best Practices liefern also einen Mehrwert, weil hier schon Erfahrung von anderen Anwendern eingeflossen sind.

  • Guided Configuration. Hierbei handelt es sich um eine geführte Konfiguration von SAP S/4HANA mit Hilfe des Solution Builders, um das Produkt sehr einfach an die Bedürfnisse des Kunden anpassen zu können. Mit dem Solution Builder können die SAP Best Practices aktiviert werden, die wir weiter oben schon einmal besprochen haben.

    In der Guided Configuration wird dieser Best Practices Content nun genommen und beispielsweise abhängig von der Deployment Option angepasst. So macht es etwa einen Unterschied, ob Sie SAP S/4HANA on-premise oder in der Cloud deployen wollen.  Die Guided Configuration wird entweder in Form von SAPUI5-Fiori-Apps oder über die klassische SAP Implementation Guideline (IMG, Transaktion SPRO) bereitgestellt.

  • Methodology. Hierbei handelt es sich um eine von SAP definierte Methodik zur Adaption von neuen SAP-Innvoationen, insbesondere in Form von SAP S/4HANA. Diese Methodik teilt die Einführung von SAP S/4HANA in Phasen ein. Discover, Prepare, Explore, Realize, Deploy und Run. Nach dieser Methodik werden beispielsweise zunächst Business Requirements definiert, die später in IT-Requirements übersetzt werden. Diese Requirements müssen dann im Laufe der Innovation Adoption erfüllt werden, um einen Go-Live unter der neuen Technologie zu rechtfertigen.

    So wird in der Explore-Phase beispielsweise festgestellt, inwieweit die Lösung diese Requirements bereits von Haus aus erfüllen kann, und in wie weit nicht. Die sogenannten „Gaps“, die durch Eigenentwicklungen oder Drittanbieter-Lösungen geschlossen werden müssen, werden festgehalten und mit in die Realisierungsphase eingeplant. In der Deploy Phase bereiten Sie ihr Business auf die neue Veränderung vor, beispielsweise durch Anwenderschulungen. Die Deploy-Phase endet schlussendlich mit dem Go-Live

PRINCE2 Agile

PRINCE2 Agile ist eine Erweiterung zu PRINCE2. Als Erweiterung ist es also weiterhin nötig, sich zunächst für PRINCE2 zertifzieren zu lassen, bevor man Zugriff auf eine Agile-Zertifizierung hat. Das klassische PRINCE2 alleinstehend wird in agilen Projektumgebungen oft als sehr dokumentatorisch und langsam empfunden. PRINCE2 Agile besteht einfach ausgedrückt zu 10% aus den Governance-Richtlinien von PRINCe2 und zu 90% aus Agile-Richtlinien. Hierbei bedient scih PRINCE2 Agile der praktiken aus anderen Agile Approaches wie Scrum, Time Boxing, Kanban, Lean Startup, Extreme Programming (XP) etc.

In agilen Softwareprojekten muss man sich auch mal abkapseln können

In agilen Softwareprojekten muss man sich auch mal abkapseln können

PRINCE2 Agile besteht im wesentlichen aus dem Management des sogenannten „Hexagons“. Dies bezeichnet sechs Kriterien für den Erfolg eines Projektes:

  • Zeit
  • Kosten
  • Vorteile
  • risiken
  • Qualität
  • Scope (Funktionsumfang)

In einem agilen Proejktumfeld ist man nie zu spät und nie über dem Budget. Deswegen sind die beiden ersten Kriterien (Zeit und Kosten) immer die Kriterien, die man durch biegen der anderen vier Kriterien „fixen“ muss.

Allein schon aus dieser Aussage heraus kann man schon ableiten, dass sich PRINCE2 Agile nicht an Industrien richtet, die eine sehr geringe Toleranz gegenüber Risiken haben, also etwa Aerospace, Nuclear,  Pharmaceuticals, Military etc. PRINCE2 Agile eignet sich für Industrien, in denen die Risikotoleranz höher ist und in denen die Time-to-Value bzw. Time-to-Market häufig auch eine wesentlich höhere Rolle spielt als in den gerade genannten Industrien (Die Pharmaindustrie ist vielleicht noch eine Ausnahme wenn es um den Stellenwert von Time-to-Market geht).

PRINCE2 Agile besteht aus 5 Zielen

  • Sie wollen rechtzeitig mit Ihren Deadlines sein
  • Sie schützen das Qualitätsniveau
  • Sie begrüßen Veränderungen in Ihrem Projekt
  • Sie halten Teams stabil
  • sie akzeptieren dass der Kunde nicht alles braucht, was Sie ihm liefern könnten.

Aus der Aussage „Begrüßen Sie Veränderungen (Embrace Change“) lässt sich auch ableiten, dass sich PRINCE2 Agile nicht für Projekte eignet, in denen eine harte Change Control statt findet, etwa beim Berliner Flughafen, wo es schon ein No-Go ist, über die Veränderung der Deckenhöhe eines Stockwerkes nachzudenken, weil dann beispielsweise die bestellten Rolltreppen nicht mehr die richtige Größe haben usw. Für Projekte mit „in Stein gemeiselten Configuration Items“ eignet sich das klassische PRINCE2 viel besser.

PRINCE2 Agile ist gerade deswegen so beliebt, weil es von vielen als das „Best Practices of Best Practices“-Paket angesehen wird. Denn es fasst die besten Praktiken aus mehreren agilen Frameworks mit der Compliance-Struktur des klassischen PRINCE2 zusammen. Daher erfreut sich dieses Vorgehensmodell seit geraumer Zeit enormer Beliebtheit. Im SAP-Umfeld hat PRINCE2 Agile noch keine so große Bedeutung, ist jedoch im Kommen und verdrängt dabei häufig bestehende Vorgehensmodelle wie SCRUM.

Wenn dir dieser Post gefallen hat, teile ihn doch auf Social Media, abonniere und verfolge mich per E-Mail, RSS-Feed, Social Media oder registriere dich auf meiner Seite. Wenn du registriert bist, like den Post bitte, wenn er dir gefallen hat!

Das könnte Dich auch interessieren...

2 Antworten

  1. 7. Juli 2017

    […] Sie meinen Beitrag über agile Projekt-Management Methoden in SAP Projekten gelesen haben, sind Sie für alles, was agile ist, wahrscheinlich schon Feuer und Flamme. Oder eben […]

  2. 11. Juli 2017

    […] er die technische Basis schon Gewehr bei Fuß hat. Zentraler gedanklicher Treiber hierfür ist der Design Thinking Prozess. SAP als Hersteller bietet hierbei mit seinen SAP Digital Business Services einen extra […]

Kommentar verfassen