LITMIR.BIZ

      Abbildung 2.2: Phasen des SAP-Activate-Vorgehensmodells

      Falls Sie jetzt bereits neugierig sind, können Sie schon mal im Abschnitt 5.1 lesen, welche Unterschiede zwischen agilem Projektvorgehen und den bisher für Implementierungsprojekte üblichen wasserfallbasierten Methoden bestehen.

      Diejenigen Leser, die bisher beispielsweise schon mit Accelerated SAP (kurz ASAP) bzw. daran angelehnten Vorgehensmodellen vertraut waren (Wasserfall), werden in der Abbildung 2.2 die sehr wichtige Blueprint-Phase vermissen. Immerhin wurden während dieser Phase die wichtigen Fachkonzepte, Pflichtenhefte oder Sollkonzepte geschrieben, die insbesondere für das gemeinsame Verständnis der zu erbringenden Projektleistungen von erheblicher Bedeutung waren. Gelegentlich – und so etwas soll ja vorgekommen sein – wurden dann sogenannte Change Requests (CR) erforderlich, weil die Realität den verfassten Plan »überholt« hatte.

      Für SAP Activate gilt: Es gibt nach wie vor einen wasserfallbasierten Ansatz – wenigstens für On-Premise-Installationen. Ansonsten bevorzugt SAP eindeutig das agile Vorgehen.

      2. Workstream:

      Ein Workstream umfasst einen Bereich des Projekts, der einer eigenständigen Steuerung bedarf. Häufig wird ein Workstream durch ein Team besetzt, das die Aufgaben übernimmt.

      3. Deliverables and Tasks:

      Deliverables sind die erwarteten Ergebnisse, die man in Tasks, also dedizierte Aufgaben, gliedert, um das Projekt möglichst effizient zu gestalten.

      4. Artifacts:

      Die meisten Projekttätigkeiten basieren auf als Artifacts bezeichneten Dokumenten oder Informationen, bzw. generieren solche.

2.2 Die kritischen Erfolgsfaktoren in Projekten

      Wie bereits in der Einleitung erwähnt, unterliegen Projekte regelmäßig einigen Zielkonflikten. Die grundlegenden Zielkonflikte ergeben sich aus dem magischen Projektdreieck (siehe Abbildung 2.3).

      Qualität, Zeit und Budget, die drei kritischen Erfolgsfaktoren in Projekten, müssen seitens des Projektmanagements so kombiniert werden, dass der Projekterfolg sichergestellt wird. Es geht also fast immer darum, ein Projekt »on time, on budget and on quality« zu liefern. Dabei stellt sich schnell heraus:

      Abbildung 2.3: Zielkonflikte im magischen Projektdreieck

      Im Vergleich traditioneller Vorgehensmodelle mit dem magischen Projektdreieck in SAP Activate zeigt sich, dass es zwar in beiden Fällen darum geht, diese Zielkonflikte möglichst optimal aufzulösen. Worin sie sich allerdings konkret unterscheiden, möchte ich anhand des jeweiligen Projektdreiecks kurz darstellen.

      In Abbildung 2.3 beschreibt die Grundfläche des Dreiecks den Projektumfang, wobei jedes kleine Dreieck symbolisch für eine gewünschte Teilleistung des Projekts steht. Die Summe der Teilleistungen ergibt den Umfang des Gesamtprojekts, und dieser wird im traditionellen Ansatz im Lasten- oder Pflichtenheft beschrieben. Im Zusammenhang mit SAP-Implementierungen wurde hierbei gemäß dem älteren Vorgehensmodell accelerated SAP (ASAP) gerne vom Business Blueprint gesprochen. Wird nun eine zusätzliche Leistung gewünscht oder ist sie aufgrund neuer Gegebenheiten erforderlich, so wird schnell deutlich, dass diese nicht mehr in die bereits komplett beschriebene Grundfläche passt. Damit muss die Fläche zwangsläufig angepasst werden. Dies wirkt sich dann auf mindestens zwei, manchmal auf alle drei Ziele aus (siehe Abbildung 2.4).

      Abbildung 2.4: Change im traditionellen Projektvorgehensmodell

      Im Ergebnis bedeutet dies, dass der Change-Request-Prozess die Frage nach dem neuen Umfang des Gesamtprojekts mit Blick auf Zeit, Geld und Qualität beantworten muss.

      Change Requests haben typische Ursachen wie etwa:

       Der Kunde lernt im Verlauf des Projekts die Möglichkeiten der Standardsoftware immer besser kennen und verstehen und möchte die gewonnenen Erkenntnisse dann auch in seinem System nutzen.

       Die Berater und Programmierer verstehen das Geschäftsmodell im Laufe der Zeit immer besser und versuchen, ihre Erkenntnisse entsprechend im System umzusetzen.

       Das Projekt wurde ausgeschrieben. Der Implementierungspartner hat das Projekt mit dem Ziel eines Zuschlags jedoch sehr knapp kalkuliert, sodass es keine Reserven gibt.

       Missverständnisse im Lasten- oder Pflichtenheft werden erst spät im Projektverlauf erkannt.

       Unstimmigkeiten zwischen Implementierungspartner und Kunde schwelen lange unter der Oberfläche und eskalieren mit zunehmendem Termindruck.

       Der Fachbereich wird zu spät mit den

Скачать книгу