Wie man S/4 HANA günstiger und schneller einführt

Eine S/4HANA Einführung birgt zahlreiche Risiken und Fallstricke, die man kennen und vermeiden sollte. Idealerweise sollte ein solches Projekt auch mit einer Vorstudie beginnen, in der bereits einige obligatorische Punkte, wie z.B. eine Analyse der IST-Prozesse, durchgeführt und der Migrationsansatz gewählt wurde. Details dazu können Sie dem Blog-Post „S/4HANA Vorstudie: Diese Punkte müssen geklärt werden“ entnehmen.

Sind diese Punkte bereits geklärt, können Sie mit der eigentlichen Planung der Einführung beginnen.

Realistisch an die Projekte rangehen

Es ist unerlässlich, dass SAP-Einführungsprojekte realistisch geplant werden. Das betrifft im Wesentlichen die Faktoren Budget, Dauer und die zu erwartenden Benefits. Das Budget z.B. wird häufig gerade im Mittelstand zu knapp gewählt und kann im Worst Case dazu führen, dass eine solche Einführung mitten im Projektverlauf komplett gestoppt wird. Auch die Benefits müssen klar definiert sein. Es bringt wenig, die Prämisse „Fiori only“ auszugeben, weil die Oberfläche moderner aussieht, die Gesamt-Performance der Mitarbeiter aber im Vergleich mit der bisherigen SAP GUI leidet.

Eine unrealistische Planung hat leider schon mehr als einen CIO seine Stelle gekostet. Daher empfehlen wir unbedingt von Beginn an einen erfahrenen SAP-Architekten/-Experten mit ins Steuer-Gremium hinzuzuziehen.

Am SAP Standard orientieren

Die Nähe zum SAP Standard sollte soweit wie möglich erhalten bleiben. Je mehr Individualentwicklungen ein System später hat, desto schwieriger wird es, sich wieder mehr an den Standard zu orientieren. Ein erforderlicher Rückbau von Eigenentwicklungen erfordert stets viele Ressourcen und kostet wertvolle Zeit.

Vermeiden Sie eine Kopie des bestehenden R/3 Systems aufzusetzen. Vielmehr sollten Sie die Chance nutzen, bisherige Prozesse zu evaluieren und sich ggfs. von diesen auch zu lösen. Überdenken Sie Ihre Prozesse und passen Sie sie – wo immer es geht – an den SAP Standard an.

Anforderungen priorisieren

Achten Sie immer darauf, die Anforderungen im Projekt permanent zu priorisieren. Dies ist keine einmalige Aufgabe, sondern begleitet den Projektverlauf vom Kick-off bis zum Go-Live. Nehmen Sie dabei auf persönliche Befindlichkeiten der Stakeholder nur bedingt Rücksicht und stellen Sie immer mindestens folgende Fragen:

• Welchen Mehrwert bietet mir diese Anforderung?
• Welche Anforderungen sind zum gegenwärtigen Zeitpunkt dringend und wichtig?
• Welche Anforderungen werden später wichtig werden?
• Welche Anforderungen sind für den Projekterfolg irrelevant?

Irrelevante Anforderungen dürfen – und müssen sogar – abgelehnt werden.

Auf die Beauftragung achten

Unbedingt sollte bei der Beauftragung auch darauf geachtet werden, einen unabhängigen Experten für die Qualitätssicherung von Beginn an mit ins Projekt zu nehmen. Damit kann sichergestellt werden, dass eine neutrale Projektrolle einen objektiven Blick auf den Projektverlauf hat und etwaig aufkommende Risiken frühzeitig an die Projektleitung meldet. In dieser Rolle ist ein umfangreiches Prozesswissen erforderlich, damit sauber beurteilt werden kann, ob wichtige Aspekte (un)berücksichtigt sind und die Nähe zum Standard auch tatsächlich gegeben ist.

Stakeholder kennen

In jedem Projekt muss man seine Stakeholder und deren konkrete Anforderungen kennen. Immerhin haben diese Rollen ein berechtigtes Interesse am Projekt, dem Projektverlauf sowie dem späteren Ergebnis. Nutzen Sie die Funktion und den Input der Stakeholder, um Ihr Projekt in die richtige Richtung zu lenken. Auch müssen in allen Projektterminen, in denen wichtige Entscheidungen getroffen werden, die Product Owner der jeweiligen Teilbereiche vertreten sein und sollten aktiv ihren Beitrag leisten.

Die Budgetverantwortung aufteilen

Achten Sie darauf, die Budgetverantwortung auf das gesamte Projekt-Team zu verteilen. Damit lässt sich vermeiden, dass einzelne Teams an Themen arbeiten, die nicht dem Projekterfolg dienlich sind. Wer für sein Budget selbst verantwortlich ist, achtet sehr viel genauer darauf, wofür die Ressourcen eingesetzt werden.

Der Fachbereich liefert in der Regel den nötigten Input, um in einem Projekt die Richtung vorzugeben. Keine Projektrolle kennt die Prozesse in einem Unternehmen besser. Dennoch werden auch mal Anforderungen abseits des Standards gestellt und führen damit zu „Sonderlocken“ im SAP-System. Konfrontieren Sie den Fachbereich daher stets mit den aus dieser Entscheidung entstehenden Kosten: Abstimmungen & Workshops, Entwicklungsleistungen, ggfs. erforderliche Rückbauten, Support. Das schärft den Blick auf wesentliche Projektinhalte.

Ein SAP-Einführungsprojekt richtig starten

Man sollte nicht mit Design Thinking Workshops ohne Bezug zum SAP starten und darin lediglich „Bildchen malen“. Stellen Sie von Beginn an sicher, dass die Möglichkeiten und Grenzen des SAP-Systems berücksichtigt werden. Das beinhaltet auch, dass nicht zu viel Energie in PowerPoint Folien gesteckt wird. Konkrete Ergebnisse sind dagegen abgestimmte und abgenommene Konzepte, Prozessschaubilder und prototypische Prozesse.

Achten Sie immer darauf, frühzeitig Ergebnisse auf dem Q-System zu liefern und die Prozesse dort mit echten (vor-migrierten) Daten herzeigen zu können. Diese Prozesse sollten auch vom ersten Tag an getestet werden können.

Sollte das Projekt ein internationales Template/Rollout-Projekt sein, beginnen Sie nicht mit Ländern, die keine Erfahrung in SAP haben. Der erste Input sollte immer aus einer Region kommen, die bereits mehrjährige Erfahrung in SAP mitbringt. Nur so lässt sich eine angemessene Qualität sichern und die Reibungsverluste durch Prozesserläuterungen und fehlendes SAP Know-how werden minimiert.

Beim Aufbau eines SAP Global Templates sollte man auch immer den Bezug zum (regionalen) Business und zu Kundenspezifika wahren und nicht nur „blind“ den SAP Standard umsetzen. Nehmen wir als Beispiel ein SAP EWM-Template zur Einführung in verschiedenen Ländern. Die Grundprozesse sind zwar im Wesentlichen die gleichen, jedoch unterscheidet sich ein Lager vom anderen. Auch sind hier landesspezifische Besonderheiten zu beachten.

Gehen Sie agil vor

Ein agiles Vorgehen bringt viele Vorteile mit sich. Auf geänderte Anforderungen (durch Priorisierung) kann innerhalb kürzester Zeit reagiert werden. Ein gut abgestimmtes und eingearbeitetes agiles Team arbeitet in der Regel auch produktiver als in einem klassischen Wasserfallmodell. Ihren Stakeholdern können auf diese Weise regelmäßig neue Zwischenstände vorgestellt werden, die auch bereits im Q-System nachgetestet werden können.

Aber: es ist wichtig dafür zu sorgen, dass jeden Monat Ergebnisse auf dem Q-System ausgeliefert werden. Ein agiles Vorgehen ist nicht mit einem planlosen Vorgehen zu verwechseln. Fordern Sie die Sprintergebnisse ein und versuchen Sie dauerhaft das agile Team zu optimieren. Eine erfahrener Scrum Master ist hier Gold wert.

Stellen Sie sicher, dass der Fachbereich so früh wie möglich in die Tests eingebunden wird. Häufig findet der Fachbereich immer wieder Anforderungen, welche nicht vom Product Owner / den Stakeholdern berücksichtigt wurden, aber relevant sind. Der Fachbereich muss seiner Verantwortung gerecht werden, fordern Sie die Testergebnisse daher aktiv und nachdrücklich ein. Ein Sprint wird erst abgeschlossen, wenn die Tests erfolgreich abgeschlossen und dokumentiert wurden.

Berücksichtigen Sie neue Themen frühzeitig

Eine Umstellung von SAP R/3 auf S/4HANA bringt viele Neuerung mit sich. Diese sind unter anderem folgende:

• Embedded EWM
• Embedded Transportation Management
• SAP Business Partner
• SAP Sales Cloud
• SAP Marketing
• Das neue Hauptbuch
• Die neue Anlagenbuchhaltung
• Einrichtung der Fiori Infrastruktur
• Umstellung SAP Script und Smart Forms Formulare
• Die Nachrichtensteuerung in BRF+

Diese Themen sollten Sie frühzeitig auf dem Schirm haben, damit Sie während des Einführungsprojekts keine bösen Überraschungen erleben. Einige dieser Themen lassen sich auch sehr gut in ein Vorprojekt zum eigentlichen S/4HANA Projekt auslagern, wie z.B. der SAP Business Partner oder das neue Hauptbuch. Damit reduzieren Sie die Komplexität des Hauptprojekts und steigern die Chancen auf eine erfolgreiche Einführung.

Die Ososoft unterstützt Sie gerne

Mit vielen dieser Themen haben wir bei der Ososoft uns bereits aktiv befasst. Kommen Sie jederzeit auf uns zu, sollten Sie Interesse oder auch nur eine Frage haben. Unsere Experten helfen Ihnen gerne.