Zusammen mit unseren Freunden in der SAP-Branche haben wir im vergangenen Jahr zu viel Zeit mit der Debatte \u00fcber die Vorz\u00fcge eines \"Greenfield\"-Ansatzes gegen\u00fcber einem \"Brownfield\"-Ansatz f\u00fcr Kunden, die auf die neueste ERP-Plattform von SAP umsteigen, verbracht. Greenfield\" basiert auf der Pr\u00e4misse, dass es f\u00fcr Kunden besser ist, mit einer wei\u00dfen Weste zu beginnen und neu zu implementieren, w\u00e4hrend \"Brownfield\" auf der Pr\u00e4misse 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\u00e4mlich Zeit, Geld und Risiko, um den gr\u00f6\u00dftm\u00f6glichen Nutzen aus SAP S\/4HANA als ihrem digitalen Kern zu ziehen. Die tats\u00e4chliche Debatte sollte auf der Frage \"Wie schnell k\u00f6nnen wir gehen?\" basieren und diese beantworten. In diesem Whitepaper werden die Vision und der Ansatz von smartShift zur L\u00f6sung dieses Problems dargelegt.<\/p>\n
Die Gesch\u00e4ftsvisionen, Strategien und Pl\u00e4ne unserer Kunden sind stark auf die Digitalisierung ausgerichtet. Das bedeutet, dass in jeder Branche, in der wir arbeiten, die Auswirkungen und Einfl\u00fcsse des Silicon Valley zu sp\u00fcren sind. Tesla, GE Digital und Amazon ver\u00e4ndern das Spiel in ihren Sektoren und die Wettbewerber m\u00fcssen sofort reagieren. Beim digitalen Spiel geht es vor allem um Geschwindigkeit. Wenn wir uns bei smartShift mit der Frage besch\u00e4ftigen, wie wir ERP-Technologien am besten verwalten, beginnen wir mit der Frage, die wir WWSVD\" nennen - What Would Silicon Valley Do? W\u00e4ren 3-5 Jahre bis zur Produktion akzeptabel? W\u00e4ren Implementierungsbudgets im 8- bis 9-stelligen Bereich akzeptabel? Wie w\u00e4re es mit Projektteams mit Hunderten von Mitarbeitern? W\u00e4ren diese Zeitrahmen und Preise akzeptabel, w\u00e4hrend wichtige Markt- und Gesch\u00e4ftsfachleute in der Warteschleife sitzen? Wir glauben nicht. Wie gehen also erstklassige digitale Unternehmen an diese Art von Problemen heran und wie k\u00f6nnen wir diese Denkweise auf ERP anwenden?<\/p>\n
Wir sind der Meinung, dass es 3 Schl\u00fcsselkonzepte im \"Digital Playbook\" gibt, die direkt relevant sind und gro\u00dfe Vorteile f\u00fcr Ihre Strategie der digitalen Transformation haben. Wir werden jedes dieser Konzepte er\u00f6rtern und sie dann in einer Fallstudie zusammenfassen.<\/p>\n
SAP S\/4HANA MVP<\/strong><\/p>\n Minimales lebensf\u00e4higes Produkt (MVP)<\/strong> bedeutet im Technologiebereich das Mindestprodukt, das f\u00fcr 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.<\/p>\n Wenn Kunden zun\u00e4chst an MVP f\u00fcr ein Produktions-ERP-System denken, scheint sich das nicht gut zu \u00fcbertragen. Fabrikbetriebe, Lieferketten und globale Finanzteams, die \u00fcber Jahrzehnte hinweg optimiert wurden, k\u00f6nnen nicht einfach zu einem einfachen, minimalistischen Ansatz zur\u00fcckkehren. Daher muss der \"Greenfield\"-Ansatz zwangsl\u00e4ufig mit einer massiven Umgestaltung beginnen, um ein sehr komplexes MVP zu dokumentieren, das vom Unternehmen akzeptiert wird. Die MVP im \"Brownfield\"-Lager ist \u00e4hnlich entmutigend, da die MVP die gesamte Funktionalit\u00e4t, die Sie heute haben, auf genau dieselbe Art und Weise, aber auf einer v\u00f6llig anderen Technologie, neu aufbauen muss. Brownfield\"-Kunden sehen sich also mit einem massiven Aufwand f\u00fcr das Technologiedesign anstelle eines funktionalen Designs konfrontiert.<\/p>\n Wir denken, dass es hilfreich ist, an dieser Stelle innezuhalten und den Wechsel zu SAP S\/4HANA als zwei logisch getrennte Bem\u00fchungen zu betrachten. Die eine ist eine \u00c4nderung des Technologie-Stacks, die andere eine \u00c4nderung des funktionalen Paradigmas. Die Kombination und Verschmelzung dieser beiden unterschiedlichen Ver\u00e4nderungen f\u00fchrt zu einer komplexen Definition des S\/4HANA-MVP. Es ist erw\u00e4hnenswert, dass digitale Unternehmen zwar h\u00e4ufig beides in Angriff nehmen, es aber nur selten zu einer einzigen Anstrengung kombinieren und nur bei Bedarf auf diesen Ansatz zur\u00fcckgreifen.<\/p>\n Basierend auf diesem Konzept und der Arbeit mit unseren Kunden haben wir das SAP S\/4HANA MVP als eine L\u00f6sung definiert, die:<\/p>\n 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, \u00fcber viele Parteien in Ihrem Unternehmen verstreut ist, was uns zum n\u00e4chsten Grundsatz bringt.<\/p>\n Agiler\/DevOps-Ansatz<\/strong><\/p>\n Als sich in den 1990er Jahren ERP-Pakete durchsetzten, war der Implementierungsansatz durchg\u00e4ngig die Wasserfall-Methode. Heute gehen digitale Unternehmen bei Technologieprojekten anders vor, n\u00e4mlich mit der agilen Entwicklung. Agile wurde als Reaktion auf die Unzul\u00e4nglichkeiten der Wasserfall-Entwicklung entwickelt, insbesondere:<\/p>\n Der agile Ansatz hingegen nutzt selbstorganisierende, funktions\u00fcbergreifende, schlanke Teams mit kurzen Sprints und inkrementellen Releases, die auf evolution\u00e4rem Designdenken basieren. Wenn man sich die heutigen Gesch\u00e4ftszyklen vor Augen f\u00fchrt, ist es schwer, mehrj\u00e4hrige Wasserfallprojekte f\u00fcr 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:<\/p>\n Im Gegensatz dazu sehen wir bei der Einf\u00fchrung eines agilen Ansatzes:<\/p>\n Der Grund, warum wir die Herangehensweise an ein S\/4HANA-Projekt unbedingt \u00e4ndern m\u00fcssen, hat mit der Optimierung der Entscheidungsfindung zu tun. Bei den grundlegenden Abw\u00e4gungen zwischen \"Greenfield\" und \"Brownfield\" geht es um die Gesamtkosten und den Nutzen der Migration gegen\u00fcber einer Neuimplementierung. Diese Entscheidungen sind sowohl komplex als auch granular. Das hei\u00dft, dass es f\u00fcr jeden Teil der Systemfunktionalit\u00e4t unterschiedliche Kosten und Vorteile gibt, die aus vielen Blickwinkeln betrachtet werden m\u00fcssen. Die einzige M\u00f6glichkeit, dies zu bew\u00e4ltigen, ist ein funktions\u00fcbergreifendes Team, das diese Kosten\/Nutzen-Entscheidungen gemeinsam trifft. Das Problem mit \"Greenfield\" versus \"Brownfield\" ist, dass Sie effektiv eine einseitige und \u00fcbergreifende Entscheidung \u00fcber den Ansatz f\u00fcr alle Funktionen getroffen haben und dass der traditionelle wasserfallbasierte Ansatz fortbesteht.<\/p>\n Auf der F\u00fchrungsebene liegt der Reiz der agilen Ans\u00e4tze in der Gr\u00f6\u00dfe 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\u00f6hnt 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\u00fcr ERP eine entscheidende Rolle spielen kann. Eine Kerndisziplin von DevOps ist die Maximierung des Einsatzes von Automatisierung und Tools w\u00e4hrend des gesamten Prozesses, so dass sich die Mitarbeiter auf die hochwertigen und komplexen Entscheidungen und Arbeiten konzentrieren k\u00f6nnen, w\u00e4hrend die weniger wertvollen Arbeiten an Maschinen delegiert werden. Und das bringt uns zum letzten entscheidenden Schritt...<\/p>\n Automatisierung und Werkzeugbau<\/strong><\/p>\n Wenn wir \u00fcber die Kosten der Migration oder Neuimplementierung eines ERP-Systems nachdenken, gibt es einen Faktor der Gr\u00f6\u00dfenordnung, den wir einfach nicht vermeiden k\u00f6nnen. Diese Systeme haben einen enormen Umfang in Bezug auf Funktionalit\u00e4t, Daten und Schnittstellen. Das offensichtlichste Beispiel, mit dem jeder Kunde etwas anfangen kann, sind die Kosten und die Komplexit\u00e4t eines einzigen vollst\u00e4ndigen Regressionstests bei einem gr\u00f6\u00dferen ERP-Release, der in der Regel der begrenzende Faktor f\u00fcr die H\u00e4ufigkeit von SAP-Releases ist (es ist mathematisch unm\u00f6glich, monatliche Releases durchzuf\u00fchren, wenn man ein dreimonatiges Testfenster hat). Ein weiteres Beispiel, mit dem wir uns bei smartShift t\u00e4glich auseinandersetzen, ist die Komplexit\u00e4t der \u00c4nderung und Verwaltung der umfangreichen Anpassungen, die Kunden an ihrem System vorgenommen haben, um sicherzustellen, dass sie auch bei \u00c4nderungen des Systems weiterhin funktionieren und funktionieren. Das Ausma\u00df 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 mit sich bringen.<\/p>\n Wenn diese Probleme jedoch durch die Entwicklung von Prozessen angegangen werden, bei denen Maschinen den Gro\u00dfteil der Arbeit \u00fcbernehmen, k\u00f6nnen wir einmal planen und immer wieder ausf\u00fchren. W\u00e4hrend die Einrichtung eines automatisierten Testsystems f\u00fcr eine einzige Version nicht kosteneffizient ist, zahlt sich die Investition in die Testautomatisierung in einer Welt mit monatlichen Versionen enorm aus. In \u00e4hnlicher Weise ist die Implementierung von Automatisierung zur Verwaltung Ihrer Anpassungen, um 1000 Code-\u00c4nderungen einmalig vorzunehmen, vielleicht nicht billiger als die Verlagerung des Codes ins Ausland f\u00fcr ein bestimmtes Projekt, aber \u00fcber mehrere technische und gesch\u00e4ftliche 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\u00f6glichkeit, Produkte in Milliardenh\u00f6he zu entwickeln und zu verwalten, wenn die t\u00e4glichen Releases von Teams verwaltet werden, die mit zwei Pizzas satt werden k\u00f6nnen.<\/p>\n Im Hinblick auf die Umstellung auf S\/4HANA spielt die Automatisierung eine absolute Schl\u00fcsselrolle, indem sie die Kosten-Nutzen-Entscheidung bei der Definition des MVP grundlegend \u00e4ndert. In der klassischen \"Greenfield\"- versus \"Brownfield\"-Perspektive hat ein gro\u00dfer 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\u00e4ftsprozesse neu gestalten, aber sie kann die Kosten f\u00fcr die Weiterentwicklung bestehender Funktionen ohne manuellen Aufwand drastisch senken. F\u00fcr die Technikfreaks: Denken Sie daran, was Docker f\u00fcr Legacy-Anwendungen leistet, die in eine Cloud-Infrastruktur verlagert werden. In Zusammenarbeit mit smartShift nutzen unsere Kunden Automation, um Funktionen zu identifizieren und in vier gro\u00dfe S\/4HANA-Eimer\" zu kategorisieren.<\/p>\n Im Gegensatz zu einem reinen \"Greenfield\"-Ansatz schr\u00e4nken wir den Umfang der Neugestaltung erheblich ein, und im Vergleich zu einem \"Brownfield\"-Ansatz reduzieren wir die Kosten f\u00fcr viele der technischen \u00c4nderungen mit Automation erheblich, w\u00e4hrend wir die besonders problematischen \u00c4nderungen herausfiltern, die neu implementiert werden m\u00fcssen. So nutzen wir den optimalen Rahmen f\u00fcr die besten Kosten-Nutzen-Entscheidungen, die zum optimalen MVP f\u00fchren. Nat\u00fcrlich funktioniert dieser Ansatz nur, wenn wir ein funktions\u00fcbergreifendes Team haben, das voll bef\u00e4higt, informiert und von diesem Ansatz \u00fcberzeugt ist.<\/p>\n F\u00fcr die Kunden muss der Gedanke verlockend sein, einen neuen Ansatz zu w\u00e4hlen, 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.<\/p>\n Das D\u00f6hler-Beispiel<\/strong><\/p>\n D\u00f6hler ist ein weltweit t\u00e4tiger Hersteller, Vermarkter und Anbieter von nat\u00fcrlichen Ingredients, Ingredient Systems und integrierten L\u00f6sungen f\u00fcr die Lebensmittel- und Getr\u00e4nkeindustrie. Das Unternehmen arbeitet seit 1993 mit SAP ERP und verf\u00fcgt \u00fcber ein hochgradig angepasstes und spezialisiertes System mit \u00fcber 33.000 kundenspezifischen Objekten. Mit S\/4H will D\u00f6hler ein digitales Kernsystem bereitstellen, das neue Gesch\u00e4ftsprozesse und sogar neue Gesch\u00e4ftsmodelle erm\u00f6glicht.<\/p>\n Um den Anforderungen des Umstiegs auf S\/4HANA gerecht zu werden, stellte D\u00f6hler ein Kernteam zusammen, das alle Disziplinen innerhalb von SAP repr\u00e4sentierte und dabei die agilen Prinzipien ber\u00fccksichtigte. Das Team nutzte smartShift und die Automatisierungsfunktionen des SAP Solution Managers, um eine gr\u00fcndliche Analyse aller Funktionen in ihrem System durchzuf\u00fchren. Anhand dieser Informationen konnten zwei aufeinander folgende MVP-Releases identifiziert werden, die innerhalb eines f\u00fcr das Management akzeptablen Zeit- und Budgetfensters durchgef\u00fchrt werden konnten.<\/p>\n Das erste Release war ein \"Lift and Shift\" zu Suite on HANA (SoH), bei dem die Datenbankschicht ausgetauscht wurde, ohne funktionale \u00c4nderungen am System vorzunehmen. Dieses Projekt wurde in einer Gesamtzeit von 3 Monaten durchg\u00e4ngig abgeschlossen. Der technische Umfang wurde durch eine Risikobewertung und die Maximierung der vorhersehbaren, automatisierten Transformation optimiert, was zu etwa 210.000 technischen \u00c4nderungen f\u00fchrte, die entweder f\u00fcr die HANA-Kompatibilit\u00e4t erforderlich waren oder die zur Verbesserung der Leistung oder zur Vereinfachung der Konfiguration erforderlich waren. Da das Kernteam die Abh\u00e4ngigkeiten und Risiken genau kannte, war die Qualit\u00e4t mit insgesamt 15 Fehlern beim Testen extrem hoch - ein klares Beispiel f\u00fcr die Leistungsf\u00e4higkeit des Dev-Ops-Ansatzes.<\/p>\n Unmittelbar nach dem SoH-Release startete D\u00f6hler den Sprint zu S\/4HANA. Dieses Release enth\u00e4lt eine komplexere Kombination aus funktionalen und technischen \u00c4nderungen. Als Grundlage f\u00fcr diese Entscheidung f\u00fchrte D\u00f6hler die SAP Simplification Database durch, die \u00fcber 5500 funktionale L\u00fccken identifizierte, die bei der Umstellung auf S\/4HANA behoben werden mussten. Mit diesem Ansatz reduzierten sie die funktionalen \u00c4nderungen, die ein Prozess-Engineering erforderten, auf die 100 wichtigsten mit geeigneten Migrationen f\u00fcr die restlichen 98%+. Bei einem Zeitfenster von vier Monaten f\u00fcr das MVP S\/4HANA-Release stand D\u00f6hler so ein Arbeitstag pro Prozessbereich zur Verf\u00fcgung. Das erste S\/4HANA-Release von D\u00f6hler bewahrt alle kritischen Funktionen und beschr\u00e4nkt die S\/4HANA-Optimierung auf die kritischsten Bereiche. D\u00f6hler geht nun zu einem iterativen Ansatz \u00fcber, um eine schrittweise S\/4HANA-Optimierung durchzuf\u00fchren, wenn die Anwender mit der Fiori-Benutzeroberfl\u00e4che vertrauter werden, die SAP-Release-Zyklen f\u00fcr S\/4HANA eintreten oder sich durch nat\u00fcrliche Gesch\u00e4ftsver\u00e4nderungen neue M\u00f6glichkeiten ergeben.<\/p>\n Kunden, die glauben, dass ihr System komplexer ist als das von D\u00f6hler, w\u00fcrden wir entgegnen, dass D\u00f6hler mit seinem Anpassungsgrad zu den Top 5% der Enterprise-SAP-Systeme geh\u00f6rt und dass die gr\u00f6\u00dften globalen Systeme nie mehr als das 4-fache des Anpassungsgrades von D\u00f6hler haben. Dieser bemerkenswerte Fall ist die Folge eines grundlegend anderen Ansatzes, der zu einem deutlich anderen und schnelleren Ergebnis f\u00fchrt.<\/p>\n Bitte kontaktieren Sie uns, wenn Sie den n\u00e4chsten Schritt zu S\/4HANA erw\u00e4gen, wertvolle Einblicke von unserem erfahrenen Team w\u00fcnschen oder mehr \u00fcber die S\/4-Automatisierungsplattform von smartShift erfahren m\u00f6chten!<\/p>","protected":false},"excerpt":{"rendered":" Zusammen mit unseren Freunden in der SAP-Branche haben wir im vergangenen Jahr zu viel Zeit mit der Debatte \u00fcber die Vorz\u00fcge eines \"Greenfield\"-Ansatzes gegen\u00fcber einem \"Brownfield\"-Ansatz f\u00fcr Kunden, die auf die neueste ERP-Plattform von SAP umsteigen, verbracht. Greenfield\" basiert auf der Pr\u00e4misse, dass es f\u00fcr die Kunden besser ist, [...]<\/p>","protected":false},"author":3,"featured_media":15035,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"content-type":"","rank_math_lock_modified_date":false,"footnotes":""},"categories":[32],"tags":[47],"class_list":["post-1584","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog","tag-post"],"acf":[],"_links":{"self":[{"href":"https:\/\/smartshift.imagemakersdev.com\/de\/wp-json\/wp\/v2\/posts\/1584","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/smartshift.imagemakersdev.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/smartshift.imagemakersdev.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/smartshift.imagemakersdev.com\/de\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/smartshift.imagemakersdev.com\/de\/wp-json\/wp\/v2\/comments?post=1584"}],"version-history":[{"count":1,"href":"https:\/\/smartshift.imagemakersdev.com\/de\/wp-json\/wp\/v2\/posts\/1584\/revisions"}],"predecessor-version":[{"id":22170,"href":"https:\/\/smartshift.imagemakersdev.com\/de\/wp-json\/wp\/v2\/posts\/1584\/revisions\/22170"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/smartshift.imagemakersdev.com\/de\/wp-json\/wp\/v2\/media\/15035"}],"wp:attachment":[{"href":"https:\/\/smartshift.imagemakersdev.com\/de\/wp-json\/wp\/v2\/media?parent=1584"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/smartshift.imagemakersdev.com\/de\/wp-json\/wp\/v2\/categories?post=1584"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/smartshift.imagemakersdev.com\/de\/wp-json\/wp\/v2\/tags?post=1584"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
\n
\n
\n
\n