Zusammen mit unseren Freunden in der SAP-Branche haben wir im vergangenen Jahr zu viel Zeit mit der Debatte über die Vorzüge eines "Greenfield"-Ansatzes gegenüber einem "Brownfield"-Ansatz für Kunden, die auf die neueste ERP-Plattform von SAP umsteigen, verbracht. Greenfield" basiert auf der Prämisse, dass es für Kunden besser ist, mit einer weißen Weste zu beginnen und neu zu implementieren, während "Brownfield" auf der Prämisse basiert, dass Kunden ihre aktuellen Systemfunktionen auf S/4HANA migrieren sollten. Unserer Meinung nach lenkt diese anhaltende "philosophische Debatte" die Aufmerksamkeit und Energie von den Hauptanliegen der Kunden ab, nämlich Zeit, Geld und Risiko, um den größtmöglichen Nutzen aus SAP S/4HANA als ihrem digitalen Kern zu ziehen. Die tatsächliche Debatte sollte auf der Frage "Wie schnell können wir gehen?" basieren und diese beantworten. In diesem Whitepaper werden die Vision und der Ansatz von smartShift zur Lösung dieses Problems dargelegt.

Die Geschäftsvisionen, Strategien und Pläne unserer Kunden sind stark auf die Digitalisierung ausgerichtet. Das bedeutet, dass in jeder Branche, in der wir arbeiten, die Auswirkungen und Einflüsse des Silicon Valley zu spüren sind. Tesla, GE Digital und Amazon verändern das Spiel in ihren Sektoren und die Wettbewerber müssen sofort reagieren. Beim digitalen Spiel geht es vor allem um Geschwindigkeit. Wenn wir uns bei smartShift mit der Frage beschäftigen, wie wir ERP-Technologien am besten verwalten, beginnen wir mit der Frage, die wir WWSVD" nennen - What Would Silicon Valley Do? Wären 3-5 Jahre bis zur Produktion akzeptabel? Wären Implementierungsbudgets im 8- bis 9-stelligen Bereich akzeptabel? Wie wäre es mit Projektteams mit Hunderten von Mitarbeitern? Wären diese Zeitrahmen und Preise akzeptabel, während wichtige Markt- und Geschäftsprioritäten auf Eis liegen? Wir glauben nicht. Wie gehen also erstklassige digitale Unternehmen an diese Art von Problemen heran und wie können wir diese Denkweise auf ERP anwenden?

Wir sind der Meinung, dass es 3 Schlüsselkonzepte im "Digital Playbook" gibt, die direkt relevant sind und große Vorteile für Ihre Strategie der digitalen Transformation haben. Wir werden jedes dieser Konzepte erörtern und sie dann in einer Fallstudie zusammenfassen.

1. Minimales lebensfähiges Produkt
2. Agiler/DevOps-Ansatz
3. Automatisierung und Werkzeugbau

SAP S/4HANA MVP

Minimales lebensfähiges Produkt (MVP) bedeutet im Technologiebereich das Mindestprodukt, das für Early-Adopter- oder Beta-Kunden von Nutzen sein kann. In einem Umfeld, in dem es auf Geschwindigkeit ankommt, ist die Definition des MVP ein entscheidender Schritt, um den schnellsten Weg zur Marktreife zu finden. Das MVP stellt nicht das Ende der Reise dar - es ist nur die Basis, um auf den Markt zu kommen und ein reales Feedback von Kunden zu erhalten, damit das Produkt weiterentwickelt und optimiert werden kann.

Wenn Kunden zunächst an MVP für ein Produktions-ERP-System denken, scheint sich das nicht gut zu übertragen. Fabrikbetriebe, Lieferketten und globale Finanzteams, die über Jahrzehnte hinweg optimiert wurden, können nicht einfach zu einem einfachen, minimalistischen Ansatz zurückkehren. Daher muss der "Greenfield"-Ansatz zwangsläufig mit einer massiven Umgestaltung beginnen, um ein sehr komplexes MVP zu dokumentieren, das vom Unternehmen akzeptiert wird. Die MVP im "Brownfield"-Lager ist ähnlich entmutigend, da die MVP die gesamte Funktionalität, die Sie heute haben, auf genau dieselbe Art und Weise, aber auf einer völlig anderen Technologie, neu aufbauen muss. Brownfield"-Kunden sehen sich also mit einem massiven Aufwand für das Technologiedesign anstelle eines funktionalen Designs konfrontiert.

Wir denken, dass es hilfreich ist, an dieser Stelle innezuhalten und den Wechsel zu SAP S/4HANA als zwei logisch getrennte Bemühungen zu betrachten. Die eine ist eine Änderung des Technologie-Stacks, die andere eine Änderung des funktionalen Paradigmas. Die Kombination und Verschmelzung dieser beiden unterschiedlichen Veränderungen führt zu einer komplexen Definition des S/4HANA-MVP. Es ist erwähnenswert, dass digitale Unternehmen zwar häufig beides in Angriff nehmen, es aber nur selten zu einer einzigen Anstrengung kombinieren und nur bei Bedarf auf diesen Ansatz zurückgreifen.

Basierend auf diesem Konzept und der Arbeit mit unseren Kunden haben wir das SAP S/4HANA MVP als eine Lösung definiert, die:

1. Keine Unterbrechung der wichtigsten Geschäftsprozesse, sofern nicht erforderlich
2. Nutzung aller "kostenlosen" oder offensichtlichen Prozess- oder Funktionsverbesserungen, die mit dem Upgrade verfügbar sind
3. die Technologieplattform so schnell wie möglich aufzurüsten
4. Legt die Grundlage für iterative/agile Verbesserungen in der Zukunft

Das Schwierigste bei der Identifizierung des S/4HANA-MVP ist, dass das Wissen, das erforderlich ist, um die wahren Kosten hinter diesen Entscheidungen zu verstehen, über viele Parteien in Ihrem Unternehmen verstreut ist, was uns zum nächsten Grundsatz bringt.

Agiler/DevOps-Ansatz

Als sich in den 1990er Jahren ERP-Pakete durchsetzten, war der Implementierungsansatz durchgängig die Wasserfall-Methode. Heute gehen digitale Unternehmen bei Technologieprojekten anders vor, nämlich mit der agilen Entwicklung. Agile wurde als Reaktion auf die Unzulänglichkeiten der Wasserfall-Entwicklung entwickelt, insbesondere:

• Wasserfall ist nicht reaktionsfähig oder anpassungsfähig an sich ändernde Anforderungen oder Bedingungen
• Sie erfordert ein erhebliches Maß an Aufsicht und Mikromanagement, das in großem Umfang zunimmt.
• Sie hängt von hochspezialisierten und aufgegliederten Ressourcen ab

Der agile Ansatz hingegen nutzt selbstorganisierende, funktionsübergreifende, schlanke Teams mit kurzen Sprints und inkrementellen Releases, die auf evolutionärem Designdenken basieren. Wenn man sich die heutigen Geschäftszyklen vor Augen führt, ist es schwer, mehrjährige Wasserfallprojekte für irgendetwas zu rationalisieren, wenn Agile eine praktikable Alternative ist. Die Herausforderung besteht darin, dass praktisch alle qualifizierten und sachkundigen Ressourcen auf dem ERP-Markt im Wasserfallverfahren geschult wurden, so dass das vorherrschende Planungsparadigma das Wasserfallverfahren ist. Die Kennzeichen eines wasserfallbasierten Ansatzes sind:

• Die erste Phase eines jeden Projekts ist eine langwierige Planungs- und Entwurfsphase
• Es gibt klar abgegrenzte Geschäfts-, Funktions-, Anwendungs-, Infrastruktur- und Testteams und -ressourcen, in der Regel mit gegensätzlichen Ansichten und Zielen
• Die wichtigsten Fragen, die aufgeworfen werden, sind "was könnte schief gehen" und "wie könnte ich beschuldigt werden".

Im Gegensatz dazu sehen wir bei der Einführung eines agilen Ansatzes:

• Die ersten Schritte sind handlungsorientiert, zum Beispiel ein Pilotprojekt auf der Grundlage eines definierten MVP
• Es gibt ein einziges Team mit Vertretern aus allen Disziplinen, aber einem gemeinsamen Ziel
• Dabei geht es in erster Linie um die Frage, wie wir mit weniger Mitteln schneller und besser werden können.

Der Grund, warum wir die Herangehensweise an ein S/4HANA-Projekt unbedingt ändern müssen, hat mit der Optimierung der Entscheidungsfindung zu tun. Bei den grundlegenden Abwägungen zwischen "Greenfield" und "Brownfield" geht es um die Gesamtkosten und den Nutzen der Migration gegenüber einer Neuimplementierung. Diese Entscheidungen sind sowohl komplex als auch granular. Das heißt, dass es für jeden Teil der Systemfunktionalität unterschiedliche Kosten und Vorteile gibt, die aus vielen Blickwinkeln betrachtet werden müssen. Die einzige Möglichkeit, dies zu bewältigen, ist ein funktionsübergreifendes Team, das diese Kosten/Nutzen-Entscheidungen gemeinsam trifft. Das Problem bei "Greenfield" versus "Brownfield" ist, dass Sie effektiv eine einseitige und übergreifende Entscheidung über den Ansatz für alle Funktionen getroffen haben und den traditionellen wasserfallbasierten Ansatz fortbestehen lassen.

Auf der Führungsebene liegt der Reiz der agilen Ansätze in der Größe und den Kosten der Teams. Eines der Markenzeichen digitaler Unternehmen ist die Hebelwirkung, die von relativ kleinen Gruppen von Ressourcen ausgeht, die sich nicht an die traditionellen "Silos" oder Hierarchien halten, an die wir alle so gewöhnt sind. Die Praxis, dass alle Fachbereiche in einem einzigen Team vertreten sind, wird als DevOps bezeichnet, wobei ein einziges Team ein Produkt entwirft, entwickelt, testet und bereitstellt. Dieser Ansatz erobert den Technologiemarkt in rasantem Tempo und bringt ein wichtiges Unterscheidungsmerkmal mit sich, das für ERP eine entscheidende Rolle spielen kann. Eine Kerndisziplin von DevOps ist die Maximierung des Einsatzes von Automatisierung und Tools während des gesamten Prozesses, so dass sich die Mitarbeiter auf die hochwertigen und komplexen Entscheidungen und Arbeiten konzentrieren können, während die weniger wertvollen Arbeiten an Maschinen delegiert werden. Und das bringt uns zum letzten entscheidenden Schritt...

Automatisierung und Werkzeugbau

Wenn wir über die Kosten der Migration oder Neuimplementierung eines ERP-Systems nachdenken, gibt es einen Faktor der Größenordnung, den wir einfach nicht vermeiden können. Diese Systeme haben einen enormen Umfang in Bezug auf Funktionalität, Daten und Schnittstellen. Das offensichtlichste Beispiel, mit dem jeder Kunde etwas anfangen kann, sind die Kosten und die Komplexität eines einzigen vollständigen Regressionstests bei einem größeren ERP-Release, der in der Regel der begrenzende Faktor für die Häufigkeit von SAP-Releases ist (es ist mathematisch unmöglich, monatliche Releases durchzuführen, wenn man ein dreimonatiges Testfenster hat). Ein weiteres Beispiel, mit dem wir uns bei smartShift täglich auseinandersetzen, ist die Komplexität der Änderung und Verwaltung der umfangreichen Anpassungen, die Kunden an ihrem System vorgenommen haben, um sicherzustellen, dass sie auch bei Änderungen des Systems weiterhin funktionieren und funktionieren. Das Ausmaß dieser Probleme stellt sicher, dass sie, wenn sie mit teuren und unvorhersehbaren Personalressourcen angegangen werden, viel Zeit in Anspruch nehmen, viel Geld kosten und unvorhergesehene Probleme auf dem Weg dorthin auftreten.

Wenn diese Probleme jedoch durch die Entwicklung von Prozessen angegangen werden, bei denen Maschinen den Großteil der Arbeit übernehmen, können wir einmal planen und immer wieder ausführen. Während die Einrichtung eines automatisierten Testsystems für eine einzige Version nicht kosteneffizient ist, zahlt sich die Investition in die Testautomatisierung in einer Welt mit monatlichen Versionen enorm aus. In ähnlicher Weise ist die Implementierung von Automatisierung zur Verwaltung Ihrer Anpassungen, um 1000 Code-Änderungen einmalig vorzunehmen, vielleicht nicht billiger als die Verlagerung des Codes ins Ausland für ein bestimmtes Projekt, aber über mehrere technische und geschäftliche Releases hinweg wird die einmalig installierte Automatisierung erhebliche Einsparungen bringen. Die Unternehmen im Silicon Valley verstehen diesen Ansatz sehr gut, da sie ihn in vollem Umfang nutzen. Es gibt keine andere Möglichkeit, Produkte in Milliardenhöhe zu entwickeln und zu verwalten, wenn die täglichen Releases von Teams verwaltet werden, die mit zwei Pizzas satt werden können.

Im Hinblick auf die Umstellung auf S/4HANA spielt die Automatisierung eine absolute Schlüsselrolle, indem sie die Kosten-Nutzen-Entscheidung bei der Definition des MVP grundlegend ändert. In der klassischen "Greenfield"- versus "Brownfield"-Perspektive hat ein großer Teil (wenn nicht das gesamte) Ihres Systems Probleme, die manuelle Arbeit erfordern, entweder durch technisches Re-Design und Implementierung oder durch Prozess-Re-Engineering und Neuimplementierung. Egal, was Sie tun, die Kosten sind in diesem Paradigma hoch. Die Automatisierung kann zwar keine Geschäftsprozesse neu gestalten, aber sie kann die Kosten für die Weiterentwicklung bestehender Funktionen ohne manuellen Aufwand drastisch senken. Für die Technikfreaks: Denken Sie daran, was Docker für Legacy-Anwendungen leistet, die in eine Cloud-Infrastruktur verlagert werden. In Zusammenarbeit mit smartShift setzen unsere Kunden Automation ein, um Funktionen zu identifizieren und in vier große S/4HANA-Eimer" zu kategorisieren.

1. Wird nicht mehr ausreichend genutzt, um die Beibehaltung zu rechtfertigen - Stilllegung
2. Wird ohne Eingreifen migriert - keine Änderung erforderlich
3. Kann mit Hilfe von Automated Transformation migriert werden - keine Änderung erforderlich
4. Erfordert erhebliche Nacharbeit - sollte für eine Neuimplementierung evaluiert oder durch Standard-S/4-Funktionalität ersetzt werden, indem die Geschäftsprozesse umgestaltet werden.

Im Gegensatz zu einem reinen "Greenfield"-Ansatz schränken wir den Umfang der Neugestaltung erheblich ein, und im Vergleich zu einem "Brownfield"-Ansatz reduzieren wir die Kosten für viele der technischen Änderungen mit Automation erheblich, während wir die besonders problematischen Änderungen herausfiltern, die neu implementiert werden müssen. So nutzen wir den optimalen Rahmen für die besten Kosten-Nutzen-Entscheidungen, die zum optimalen MVP führen. Natürlich funktioniert dieser Ansatz nur, wenn wir ein funktionsübergreifendes Team haben, das voll befähigt, informiert und von diesem Ansatz überzeugt ist.

Für die Kunden muss der Gedanke verlockend sein, einen neuen Ansatz zu wählen, der weder ein reiner "Greenfield"- noch ein "Brownfield"-Ansatz ist, um viel schneller, billiger und mit weniger Risiko zu S/4HANA zu gelangen. Die eigentliche Frage ist, ob dies in der Praxis funktioniert. Schauen wir uns eine Fallstudie an.

Das Döhler-Beispiel

Döhler ist ein weltweit tätiger Hersteller, Vermarkter und Anbieter von natürlichen Ingredients, Ingredient Systems und integrierten Lösungen für die Lebensmittel- und Getränkeindustrie. Das Unternehmen arbeitet seit 1993 mit SAP ERP und verfügt über ein hochgradig angepasstes und spezialisiertes System mit über 33.000 kundenspezifischen Objekten. Mit S/4H will Döhler ein digitales Kernsystem bereitstellen, das neue Geschäftsprozesse und sogar neue Geschäftsmodelle ermöglicht.

Um den Anforderungen des Umstiegs auf S/4HANA gerecht zu werden, stellte Döhler ein Kernteam zusammen, das alle Disziplinen innerhalb von SAP repräsentierte und dabei die agilen Prinzipien berücksichtigte. Das Team nutzte smartShift und die Automatisierungsfunktionen des SAP Solution Managers, um eine gründliche Analyse aller Funktionen in ihrem System durchzuführen. Anhand dieser Informationen konnten zwei aufeinander folgende MVP-Releases identifiziert werden, die innerhalb eines für das Management akzeptablen Zeit- und Budgetfensters durchgeführt werden konnten.

Das erste Release war ein "Lift and Shift" zu Suite on HANA (SoH), bei dem die Datenbankschicht ausgetauscht wurde, ohne funktionale Änderungen am System vorzunehmen. Dieses Projekt wurde in einer Gesamtzeit von 3 Monaten durchgängig abgeschlossen. Der technische Umfang wurde durch eine Risikobewertung und die Maximierung der vorhersehbaren, automatisierten Transformation optimiert, was zu etwa 210.000 technischen Änderungen führte, die entweder für die HANA-Kompatibilität erforderlich waren oder die zur Verbesserung der Leistung oder zur Vereinfachung der Konfiguration erforderlich waren. Da das Kernteam die Abhängigkeiten und Risiken genau kannte, war die Qualität mit insgesamt 15 Fehlern beim Testen extrem hoch - ein klares Beispiel für die Leistungsfähigkeit des Dev-Ops-Ansatzes.

Unmittelbar nach dem SoH-Release startete Döhler den Sprint zu S/4HANA. Dieses Release enthält eine komplexere Kombination aus funktionalen und technischen Änderungen. Als Grundlage für diese Entscheidung führte Döhler die SAP Simplification Database durch, die über 5500 funktionale Lücken identifizierte, die bei der Umstellung auf S/4HANA behoben werden mussten. Mit diesem Ansatz reduzierten sie die funktionalen Änderungen, die ein Prozess-Engineering erforderten, auf die 100 wichtigsten mit geeigneten Migrationen für die restlichen 98%+. Bei einem Zeitfenster von vier Monaten für das MVP S/4HANA-Release stand Döhler so ein Arbeitstag pro Prozessbereich zur Verfügung. Das erste S/4HANA-Release von Döhler bewahrt alle kritischen Funktionen und beschränkt die S/4HANA-Optimierung auf die kritischsten Bereiche. Döhler geht nun zu einem iterativen Ansatz über, um eine schrittweise S/4HANA-Optimierung durchzuführen, wenn die Anwender mit der Fiori-Benutzeroberfläche vertrauter werden, die SAP-Release-Zyklen für S/4HANA eintreten oder sich durch natürliche Geschäftsveränderungen neue Möglichkeiten ergeben.

Kunden, die glauben, dass ihr System komplexer ist als das von Döhler, würden wir entgegnen, dass Döhler mit seinem Anpassungsgrad zu den Top 5% der Enterprise-SAP-Systeme gehört und dass die größten globalen Systeme nie mehr als das 4-fache des Anpassungsgrades von Döhler haben. Dieser bemerkenswerte Fall ist die Folge eines grundlegend anderen Ansatzes, der zu einem deutlich anderen und schnelleren Ergebnis führt.

Bitte kontaktieren Sie uns, wenn Sie den nächsten Schritt zu S/4HANA erwägen, wertvolle Einblicke von unserem erfahrenen Team wünschen oder mehr über die S/4-Automatisierungsplattform von smartShift erfahren möchten!