Читать книгу SAP Activate - Agilität in SAP S/4HANA-Implementierungsprojekten - Martin Kipka - Страница 16

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:

 Die Zeit ist knapp – und wird im Projektverlauf scheinbar immer knapper.

 Das Budget ist niedrig – und verbraucht sich zunehmend schnell.

 Der Qualitätsanspruch ist hoch – und steigt im Projektverlauf.

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 neuen Prozessen vertraut gemacht und blockiert kurz vor dem geplanten Produktivsetzungstermin – mal begründet und manchmal 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.