Paths to the SAP Roadmap

Meiner Erfahrung nach rührt die Unsicherheit daher, dass viele der Programme und Anweisungen zu technisch ausgerichtet sind. Sie orientieren sich zu stark am Produkt oder der Applikation. Das Problem ist: Auf diese Weise liefern sie kaum Antworten auf die Fragen derjenigen, die über ein Projekt dieser Größe entscheiden.

Viele IT-Verantwortliche oder CIOs stehen damit vor einer Herausforderung: Sie müssen ihren Vorstand oder die Geschäftsführung erst davon überzeugen, dass ein Umstieg notwendig ist. Die Entscheider aber beschäftigen sich in der Regel nicht mit technischen Fragen.

Green, Brown oder Blue? Die Unterschiede der Wege und Werkzeuge sind in den Führungsetagen meist nicht bekannt. Und die Unterschiede sind auch nicht sinnvoll vermittelbar oder von besonderem Interesse. Hinzu kommt: Technisch betrachtet sind ohnehin immer alle „Farben“ möglich.

Entscheidend ist, dass ein Roadmap-Programm passende Antworten liefert. Dabei geht es ausdrücklich nicht nur um technische Machbarkeit. Sechs Aspekte spielen dabei aus meiner Erfahrung eine zentrale Rolle. Jeder, der sich auf den Weg zu S/4 macht, sollte sie berücksichtigen.

Strategy

An Anfang jeder Überlegung und Analyse steht die Frage nach den strategischen Zielen eines Unternehmens – und wie diese Ziele mithilfe der IT erreicht werden können. Entscheidend ist es an dieser Stelle, mess­bare Ziele zu formulieren.

Es geht also nicht um Schlagworte wie „Digitalisierung“ oder „Cloud Readiness“. Sondern es geht um konkrete Ziele wie die „Erhöhung der Produk­tionsausbringung um x Prozent durch Nutzung optimierter Szenarien zur Feinplanung“. Je genauer die Ziele formuliert sind, desto besser.

Neben der Fixierung der Ziele ist es unabdingbar, auch die Stärken eines Unternehmens zu benennen. Eine solche Stärke könnte sein: die „Möglichkeit der Änderung eines Kundenauftrags bis x Tage vor dem Versand oder der Übergabe“. Sich über die eigenen Stärken klar zu werden und sie festzuhalten, dient dazu, Wettbewerbsvorteile aufrechtzuerhalten.

Um die messbaren Ziele und Stärken herauszufinden und zu formulieren, eignen sich Kurzinterviews „auf Augenhöhe“. Sie müssen professionell geführt werden. Diese Gespräche können Berater übernehmen, die im Umgang mit Top-Führungskräften geübt sind.

Target Landscape

Jedes Unternehmen lebt und entwickelt eigene Prozesse. Diese Prozesse gilt es zunächst zu verstehen. Hierzu reichen in der Regel vorhandene Dokumentationen aus. Weitere Informationen liefert eine Auswertung der aktuell genutzten Prozesse und Funktionen. Ebenso helfen kurze Einweisungen durch Mitarbeiter. Sie kennen die Besonderheiten des Unternehmens oft am besten.

Die Berater gleichen dieses Wissen mit den zuvor erarbeiteten Zielen ab. Auf diese Weise können sie eine Zielsystemarchitektur entwerfen. Zwei Aspekte sind dabei aus meiner Sicht besonders wichtig: Zum einen sollte die Ziellandschaft nicht nur mit Blick auf SAP entwickelt werden.

Zum anderen muss die tatsächliche Verfügbarkeit unter S/4 geprüft werden – etwa für Komponenten, die lediglich im sogenannten Kompatibilitätsmodus verfügbar sind. Im Rahmen dieser Analysen sollten die Experten den SAP Readiness Check installieren und ausführen. Anschließend können sie die Ergebnisse des Checks studieren und auswerten.

Darüber hinaus empfiehlt sich ein grober Abgleich der Ziellandschaft mit den SAP-Best-Practice-Prozessen. So lässt sich herausfinden, wie hoch der Anteil des SAP-Standards an der geplanten IT-Landschaft ist.

Perfekt wäre außerdem ein Live-Abgleich mit den Prozessexperten des Unternehmens in einem S/4-Sandbox-System. Auf diese Weise kann etwa die Frage geklärt werden, wie strategische und operative Anforderungen abgebildet werden können.

Changeover scenario and options

Grundsätzlich gilt: Es gibt immer mehr als einen Weg, der zum Ziel führt. Wer den für sein Unternehmen richtigen Weg identifizieren will, muss eine Vielzahl von Kriterien berücksichtigen.

Dazu gehören systemtechnische oder organisatorische Einflussfaktoren. Zu den Kriterien gehören aber auch die Kosten, die Komplexität der Umsetzung oder die Risikobereitschaft des Unternehmens. Zur Analyse und Bewertung eignen sich Kriterienkataloge und Checklisten.

Oft werden die Optionen auf lediglich drei Szenarien reduziert – nämlich New Implementation (Greenfield), System Conversion (Brownfield) oder eine selektive Migration (Bluefield).

Meiner Erfahrung nach ist das aber wenig hilfreich. Der Grund ist, dass die „Farben“ lediglich Unterscheidungen im technischen System-Setup und der Datenmigration reflektieren – und das auch nur von SAP ECC 6.0 nach S/4.

Folgender Fall: Von ECC auf S/4 umzustellen ist primär ein IT-Projekt. Die Ausgangs- und Zielsystemarchitektur ist zudem deckungsgleich oder nahezu identisch. In einem solchen Fall kommen vor allem technisch orientierte Verfahren wie Brownfield oder Bluefield infrage – und Greenfield scheidet wahrscheinlich aus.

In einem anderen Unternehmen hingegen ist der Bedarf nach modernen oder standardisierten Prozessen enorm groß. Hier würde die Entscheidung wohl eher für Greenfield fallen – und Brownfield und Bluefield schieden eher aus.

Auch der Zeitpunkt der Entscheidung spielt eine Rolle. Je später über einen Wechsel auf S/4 entschieden wird, desto größer werden die Unterschiede zwischen Ausgangs- und Zielarchitektur.

Das liegt vor allem am technischen Fortschritt unter S/4. In einem solchen Fall käme ebenso eher Greenfield infrage – und Brownfield und Bluefield wären eher ungeeignet. Bei dynamisch wachsenden Unternehmen kann es zudem sinnvoll sein, konkrete Zwischenziele fest­zulegen. Erreicht das Unternehmen ein solches Ziel, realisiert es bereits einen messbaren Mehrwert – unabhängig davon, wann die Reise zum Ziel fortgeführt wird.

Effort and costs

Die Kosten und Aufwendungen sollten bereits frühzeitig berechnet werden – und zwar möglichst vollumfänglich und transparent. Dies gilt jedenfalls dann, wenn es sich nicht um eine agile, prozessweise Inbetriebnahme handelt. Hauptaugenmerk sollte dabei auf den kostentreibenden Faktoren liegen.

Zu diesen Faktoren zählen die Kosten für den internen Aufwand der eigenen IT, Lizenzkosten oder auch die Betriebskosten für die Systeme während der Projektlaufzeit. Zuweilen kommen mehrere Varianten einer Zielsystemarchitektur infrage. Oft bestehen auch mehrere Möglichkeiten für den Umstieg. In solchen Fällen empfiehlt es sich, die Kalkulationen optionsspezifisch zu erstellen.

Minimization of risks

Jede S/4-Einführung birgt auch Risiken. Das gilt etwa für die damit verbundenen Kosten und Veränderungen. Die Risiken können ­unterschiedlich sein – zum Beispiel in Bezug auf die Größe eines Unternehmens oder darauf, in welchem Umfang es bereits SAP nutzt. Alle Risiken müssen erkannt und benannt ­werden.

Wichtig ist es, die Bedenken des Top-Managements zu berücksichtigen – etwa mit Blick auf die operativen Risiken, den Investitionsschutz oder die Zukunftsfähigkeit der eingesetzten Zielarchitektur.

Werden die Bedenken nicht gehört, kann es passieren, dass die erforderlichen Entscheidungen nicht oder nur unter strengen Auflagen getroffen werden. Ein überzeugendes Umstiegskonzept berücksichtigt daher die Bedenken des Managements. Mehr noch: Die Risiken müssen durch entsprechende Maßnahmen als beherrschbar ausgewiesen werden.

Unternehmen sollten mit entsprechenden Risiko-Checklisten arbeiten. Diese Listen können individuell ergänzt werden. Bei größeren Projekten kann es sich zudem als sinnvoll erweisen, ein Risiko-Management als dauerhaften Bestandteil der Projektorganisation zu etablieren.

Project organization

Die professionelle Organisation eines S/4-Projektes ist essenziell für den Projekt­erfolg. Die vorgesehenen Rollen und Verantwortlichkeiten im Projekt müssen klar beschrieben sein. Vorschlagsweise sollten sie mit möglichen Personen des jeweiligen Unternehmens besetzt werden. Bereits hier zeigen sich häufig drohende Engpässe bei den Kapazitäten.

Dies gilt ebenso für Abgrenzungen bei den Kompetenzen und die Besetzungen der Gremien. Je nach Projektart und -umfang werden die Rollen oder die Inhalte der Aufgaben variieren. Unternehmen sollten jedoch immer darauf achten, dass Vertreter von Business und IT mit ihren Experten vertreten sind.

Bei größeren Projekten empfiehlt es sich, über Sonderrollen nachzudenken. Dazu gehören zum Beispiel Change Management, Risk Management oder Vendor Contract Management.

Insbesondere bei Neueinführungen mit einem starken Fokus auf SAP-Best-Practice-Prozesse und Digitalisierungsstandards empfiehlt es sich, ein weiteres Gremium mit in die Projektorganisation ­aufzunehmen. Dieses Gremium sollte die Anforderungen außerhalb des SAP-Best-Practice-Standards prüfen und validieren.

Um die Abhängigkeit von externen Beratungsunternehmen zu vermeiden, können Unternehmen intern Wissensträger mit Know-how zu S/4 aufbauen. Dabei sollte die Ausbildung im Hinblick auf das Neue Vorrang gegenüber dem operativen Betrieb der vorhandenen SAP-Systeme haben.

Zuweilen treten auch Kapazitätsengpässe auf. In solchen Fällen können professionelle Anbieter als „Backfill“ für die zeitweise Übernahme von Application Management Services he­rangezogen werden. Sie stellen sicher, dass die eigene Organisation das neu installierte System professionell und eigenständig bedienen und unterstützen kann.