Good Practices für integrative Themen

Die Einführung von SAP S/4HANA Public Cloud bringt für kleine und mittelgroße Industriebetriebe weitreichende organisatorische und technologische Veränderungen und stellt sie damit vor einige Herausforderungen. Ein wesentlicher Vorteil der Public-Cloud-Lösung von SAP liegt in der verhältnismäßig raschen Einführung (ca. 12-24 Monate). Zudem liefert SAP stabile und end-to-end gedachte Standardprozesse sowie halbjährliche Updates mit allen verfügbaren Innovationen. Die Lösung kann auch ohne oder mit einer kleinen internen IT betrieben werden.

Häufig unterschätzt werden jedoch integrative Themen. Auch wenn die Public Cloud eine einfache Einführung ermöglicht, liegen die Herausforderungen im Detail. Die Zahnräder der Lösung müssen perfekt ineinandergreifen. Dieses Paper gibt einen Überblick über wesentliche Stolpersteine und zeigt Good Practices, wie man bessere Ergebnisse erzielt und das Projekt effizienter abwickelt. 

Eine Teamzusammensetzung beginnt häufig mit einem Organigramm. Dieses prägt maßgeblich das Denken aller Beteiligten im SAP-Projekt. Es besteht die Gefahr, dass man ausschließlich an direkt von SAP betroffene Abteilungen denkt. SAP ist zwar häufig der zentrale Baustein der Systemlandschaft, muss jedoch als E2E-Gesamtlösung gut mit den Umsystemen (bspw. CRM, MES, BDE, Logistiksoftware) integriert sein.

Wesentliche Effizienzverluste in Unternehmen entstehen aufgrund von Medienbrüchen und mangelnder Integration. Die Verantwortlichen und die User der Umsysteme sollten darum von Anfang an ins Projekt einbezogen werden. Eine Projektorganisation mit integrativem Charakter verankert die integrative Denkweise. Auch Querschnittsthemen, bspw. das Data Management, sollten im Projektorganigramm berücksichtigt werden. Abbildung 1 zeigt ein Beispiel.

SAP bietet ein sogenanntes Digital Discovery Assessment (DDA). Im Gespräch zwischen Dienstleistern und Unternehmensvertretern (bspw. Management sowie Abteilungsleiter) wird beurteilt, welche Standardprozesse von SAP benötigt bzw. benutzt werden sollen. SAP bietet mehrere hundert Standardprozesse. Diese können vom Dienstleister vorgängig aufgrund der Branche und der Unternehmensspezifika (bspw. ETO-Fokus) bereits eingegrenzt werden, sodass man in wenigen Stunden gemeinsam definieren kann, welche Prozesse relevant sind (siehe Beispiel in Abbildung 2). In einem Demosystem können die Key-User (die Abteilungsvertreter im SAP-Projekt) die Prozesse selbstständig und unter Anleitung der Berater des Dienstleisters kennenlernen. In der Zusammenarbeit mit dem SAP-Dienstleister «Cpro»¹ konnte das Format des Show-Me-Meetings (SMM) erkannt und analysiert werden: Das gesamte Projektteam (Key-User und Berater) kommt zusammen und bucht gemeinsam ein reales End-to-End-Szenario (von Kundenbestellung bis Auslieferung und Faktura) durch. Dadurch reift das integrative Verständnis über Abteilungsgrenzen hinweg schon früh im Projekt. Das Format ist in meinen Augen sehr zielführend. Es sollte mehrfach über das Projekt hinweg wiederholt werden.

SAP bietet für die Einführung von S/4HANA das Projektmanagement-Tool «CALM» bzw. «Cloud ALM» an. Dieses dient dazu, das gesamte Projekt zu orchestrieren. Damit CALM dem Projektteam zur Planung und Priorisierung optimal dient, sollten Regeln für dessen Nutzung definiert werden. Das Tool bringt nur dann echten Nutzen, wenn es von allen einheitlich genutzt wird (dies ist, wie stets, eine Frage der Stammdatenqualität). Es ist Aufgabe der Projektleitung, sicherzustellen, dass während des gesamten Projekts alle Veränderungen laufend in CALM eingepflegt werden. Das ist eine mühsame und unbeliebte, aber sehr zentrale Sache für den Projekterfolg. Einige Anwendungen von CALM werden in den folgenden Abschnitten vertieft.

Durch die kundenspezifische Konfiguration im System (bspw. Organisationsstrukturen wie Lagerorte oder Buchungskreise, Stammdatenparameter, Workflows, Berechtigungen) können mit dem SAP- Standard nahezu alle Prozesse abgebildet werden. Wenn zusätzliche Anforderungen aufkommen, die über den Standard hinausgehen, sind Erweiterungen möglich.

SAP Public Cloud lässt sogenannte «In-App-Extensibility» oder «Side-by-Side-Erweiterungen» zu.
Anpassungen direkt im Code von SAP sind nicht möglich. Für zusätzliche Anforderungen sollte das Projektteam gemeinsam mit den Beratern eine Lösung erarbeiten. In CALM können diese Anforderungen systematisch konzipiert, geprüft und genehmigt werden (siehe Abbildung 3).

In vielen SAP-Projekten wird die Datenmigration immer noch unterschätzt. Zuerst einmal muss das gesamte Projektteam verstehen, dass die Daten das wohl integrativste Thema überhaupt sind. Erst durch den Fluss der Daten über die Bereiche wird die Verkettung von einzelnen Prozessschritten zu einer Wertschöpfungskette. Bei einem Systemwechsel beginnt die Thematik des Datenmanagements mit dem Mapping. Die Key-User müssen verstehen, welche Datenfelder die SAP Public Cloud hat und wie sie die Prozesse steuern. Danach muss geprüft werden, welche Felder im Altsystem gepflegt werden, bevor man ein sogenanntes Mapping zwischen Altsystem und SAP erstellen kann. Der Dienstleister sollte für die verschiedenen Datenobjekte eine Mappingtabelle zur Verfügung stellen. Je nachdem können dies schnell mehrere hundert oder tausend Felder sein, die zu mappen sind. Beim Transfer vom Altsystem in die SAP Public Cloud können verschiedene Probleme auftreten, wie bspw. unterschiedliche Feldlängen oder Formate. Auf Basis des Mappings kann das Migrationsteam einen ersten Versuch unternehmen, um ausgewählte Daten aus dem Altsystem in das Testsystem² zu migrieren.

Damit die Migration mehrfach wiederholt werden kann, sollten Präfixe verwendet werden (bspw. ergänzt man bei allen Artikelnummern beim ersten Migrationszyklus ein «A» als Präfix, ein «B» beim zweiten Durchgang usw. – so kann die Migration mehrfach wiederholt werden). Mit diesen Daten können die Key-User anschließend die Prozesse testen. Daraus entstehen neue Erkenntnisse für das Mapping, die nachgeführt werden müssen. Dieser Zyklus wird mehrfach wiederholt. Man tastet sich damit über den Verlauf mehrerer Wochen hinweg immer besser an die Prozesse und die Daten sowie die Zusammenhänge heran. Als «Grande Finale» findet der sogenannte Integrationstest (I-Test) statt. Während man zuvor meist nur mit Teilmigrationen (bspw. 1000 Artikel mit zugehörigen Stücklisten, Arbeitsplänen, Kunden, Lieferanten, etc.) arbeitet, sollte für den I-Test eine Vollmigration durchgeführt werden. Der I-Test sollte zudem auf Daten ohne Präfix basieren, damit er die Realität möglichst gut widerspiegelt. Durch das wiederholte Migrieren bekommt man mit der Zeit eine bessere Einschätzung, wie früh man mit der Migration ins Produktivsystem im Hinblick auf den Go-Live beginnen muss.

Für das Testing – also das wiederholte Buchen von möglichst realen Prozessen – erfasst man systematisch alle Szenarien, die das Unternehmen im System abbilden muss. Dabei sind verschiedene Dimensionen zu berücksichtigen. Eine davon ist die Systemlandschaft. Eine weitere Dimension bilden die Produktionsmodi (bspw. MTS, MTO, ETO, Handel), von denen alle erfasst werden müssen. Die dritte Dimension bildet das Produktportfolio – es sollten verschiedene Artikel getestet werden. Beim Aufbau der Testfälle ist es entscheidend, dass man den Prozess end-to-end denkt. Die Strukturierung in Abbildung 4 hat sich dazu bewährt.

In einem Workshop können die Key-User alle Aktivitäten notieren, die sie im Tagesgeschäft ausführen. Daraus lassen sich die Unit-Tests (UT) ableiten. Setzt man die verschiedenen Aktivitäten zusammen, entstehen daraus Bereichsübergreifende Tests (BT). Denkt man sie end-to-end – also vom ersten Kunden-Touchpoint bis zur Auslieferung und Faktura – leiten sich die E2E-Tests (ET) davon ab. Spätestens auf der Stufe der ET müssen alle Systeme (auch CRM, VC, MES, BDE und weitere) berücksichtigt werden. Es empfiehlt sich, die Testfälle zu nummerieren. Dies vereinfacht die spätere Identifikation. Eine mögliche Gliederung ist in der Abbildung 5 dargestellt.

Hat man alle Testfälle – also alle Business Szenarien – erfasst, sollten mindestens für die BT und die ET passende Stammdaten ausgewählt werden. Die Stammdaten müssen den Testfall gut abbilden und sie sollten einen realen Case spiegeln. Es sollte darüber hinaus darauf geachtet werden, dass die Stammdaten möglichst nur genau den jeweiligen Testfall umfassen. Ein Testfall, der auf eine Kundenbestellung über einen Variantenkonfigurator zielt, sollte möglichst keine Stammdaten enthalten, die bspw. eine zusätzliche komplizierte Beschaffung bedingen. Für diese Konstellation sollte ein separater Testfall mit entsprechenden Stammdaten durchlaufen werden. Die benötigten Stammdaten aller Testfälle müssen mit dem Migrationsteam abgestimmt sein, sodass für die ersten Teilmigrationen genau diese Daten bereits berücksichtigt werden können.

Die CALM bietet umfassende Möglichkeiten, um das Testing zu managen. Alle Testfälle können erfasst, koordiniert und getrackt werden. In der Testausführung wird dokumentiert, wo noch Probleme auftreten. Diese Probleme werden automatisch als Aufgaben dargestellt, die vom Projektteam noch umgesetzt werden müssen. Jeder Testfall sollte nach derselben Struktur aufgebaut werden (vgl. Beispiel in Abbildung 6). Zuerst werden alle Prozessschritte aufgelistet – mit dem Format [Hauptwort] [Verb]. Es folgt der Name der Abteilung, die den Prozessschritt ausführt, sowie das erwartete Ergebnis, um den Erfolg des Testings zu prüfen. In der Anweisung kann optimalerweise ein UT verlinkt werden, welcher den jeweiligen Prozessschritt detailliert aufzeigt. Diese Strukturierung ermöglicht es, die Dokumentation auch zur Schulung der End User zu nutzen.

Die Einführung von SAP kann dazu verleiten, ausschließlich in ERP-Prozessen zu denken. Doch der Prozess endet nicht an der Systemgrenze. Die End-to-End-Wertschöpfungskette sollte über das gesamte Projekt hinweg auf dem Radar sein. Es hat sich etabliert, zu Beginn des Projekts eine erste Skizze der künftigen Systemarchitektur zu entwickeln. Dabei sollte abgebildet werden, welche Systeme in welchen Prozessen zum Einsatz kommen, wie die Systeme technisch miteinander verbunden werden und wo welche Daten fließen. Über das Projekt hinweg sollte ein solches Bild laufend weiterentwickelt und geschärft werden. Dazu benötigt es ein integratives Verständnis für Business und IT – eine prädestinierte Aufgabe für das Integrations-management.

Ein wesentlicher Bestandteil einer SAP-Einführung ist das Change-Management. Es geht darum, die Veränderungen sichtbar zu machen und kommunikativ zu begleiten. Change muss immer von der Linienorganisation und insbesondere vom Management getragen und getrieben werden. Das Integrationsmanagement kann jedoch ebenfalls eine wichtige Rolle einnehmen. Mit der integrativen Brille über alle Abteilungen hinweg kann das Integrationsmanagement die Veränderungen systematisch erfassen und aufzeigen. Oftmals wird Change Management als Aufgabe verstanden, die man an jemand engagiertes und kommunikativ versiertes delegieren kann. Dabei wird jedoch vergessen, dass Change nicht im luftleeren Raum stattfindet. Um ein aktives Change-Management betreiben zu können, braucht es ein tiefes Verständnis der Veränderungen in den Prozessen und den Systemen. Nur wer wirklich versteht, wieso welche Veränderung sinnvoll ist, kann diese Message auch transportieren.

All diese Themen sind und wirken stark integrativ – über Abteilungsgrenzen hinweg, zwischen Key-Usern und dem Migrationsteam, zwischen Business und IT, sowie in der Zusammenarbeit mit dem Dienstleister. Damit diese Themen gut koordiniert sind und die Qualität der Ergebnisse stimmt, sollte ein Integrationsmanagement im Projekt institutionalisiert sein. Die Person, die diese Rolle einnimmt, hat optimalerweise einen Gesamtblick auf das Unternehmen, versteht die Prozesse, kennt die Datenstrukturen des Unternehmens, hat Know-how im IT-Bereich (bspw. Schnittstellen), kommt auf allen Ebenen kommunikativ zurecht (von Management bis Shopfloor) und kann gut koordinieren.

Die Hauptaktivitäten des Integrationsmanagements sind insbesondere:

• die Business-Ziele verstehen,
• die End-to-End-Zusammenhänge der Prozesse aufzeigen,
• die Verzahnung der Systemlandschaft erkennen und aufzeigen,
• Sprache zwischen Business und IT übersetzen,
• Testfälle systematisch erfassen,
• Testing planen, koordinieren und monitoren,
• Verzahnung zwischen Migration und Testing koordinieren,
• Abhängigkeiten zwischen Themen aufzeigen,
• integrative Fragestellungen vorantreiben und zur Lösung hinwirken.

Ein gutes Integrationsmanagement hat die Fähigkeit, aus der Vogelperspektive auf das Projekt zu schauen und in den kritischen Themen tief einzutauchen, um die richtigen Stakeholder zusammenzubringen und auf die Lösungsfindung hinzuwirken. Nicht zuletzt benötigt es dafür ein starkes Vertrauen und eine hohe Akzeptanz des Projektteams.

DOI: https://doi.org/10.30844/ERP.26.4.SR

Das könnte Sie auch interessieren

Maximale Freiheit – das ist die TimeLine Maxime Im Management-Talk mit den Geschäftsführern Boris Gebauer und Christian Salihin

ERP-Anbieter TimeLine ist überzeugt, dass Wahlfreiheit bei der ERP-Bereitstellung zentral bleibt. Während sich der Markt in Richtung „Cloud only“ entwickelt, entspricht dies nicht immer den Vorstellungen der Anwender. Aus Sicht von TimeLine sind flexible Modelle gefragt: Cloud nutzen, wo gewünscht – Daten im eigenen Haus halten, wo erforderlich. Diese Haltung findet besonders im Mittelstand große Zustimmung.

Cloud-native & API-first: ein ERP mit Go-Live in Tagen Reybex Cloud ERP made in Germany: Einfach stärker im digitalen Mittelstand

Reybex ist ein Cloud-Native ERP-System „Made in Germany“ und sicher gehostet in deutschen Rechenzentren. Die Software vereint Warenwirtschaft, E-Commerce, CRM, Buchhaltung und Reporting in einer Plattform und automatisiert geschäftskritische Prozesse über alle Unternehmensbereiche hinweg. Durch offene Schnittstellen und integrierte KI bietet Reybex eine flexible, skalierbare Lösung für wachstumsorientierte Unternehmen. Ein ERP ohne Komplexität.

Best-Of ERP 2025: Cloud-native ERP ERP-System des Jahres: Reybex (Edit Systems) holt Gold

Reybex vereint alle Prozesse auf einer Plattform – automatisiert, integriert und skalierbar. Dank offener Standards, über 100 Schnittstellen und API-first-Architektur verbindet Reybex Flexibilität mit Stabilität. Vorkonfigurierte Module ermöglichen Go-Live in Tagen, nicht Wochen. Mit 80 Updates pro Jahr, Mehrmandantenfähigkeit und internationaler Ausrichtung beweist Reybex: Cloud kann effizient, souverän und zukunftssicher zugleich sein.

SAP S/4HANA: Cloud oder On-Premises? GROW oder RISE with SAP – welches Modell passt zu welchem Unternehmen und wann?

GROW oder RISE with SAP? Wer auf SAP S/4HANA umsteigen will, muss entscheiden: Public oder Private Cloud? Der Unterschied liegt in Standardisierung, Flexibilität, Geschwindigkeit und Kosten. SAP-Experte Marko Lorenz erklärt, welches Modell wann passt –und worauf es bei der Wahl ankommt. Jetzt ERP-Checkliste downloaden und den passenden Weg finden!

Cloud oder on-premise: Wie die richtige Betriebsform finden? Hochintegrierte Systeme: All-in-One-Lösung

Hochintegrierte Systeme bieten eine einheitliche Architektur mit klarer Datenbasis und geringem Wartungsaufwand. Doch sind sie flexibel genug für Ihre Anforderungen? Der Best-of-Breed-Ansatz ermöglicht maximale Individualisierung und Anpassungsfähigkeit – bringt aber höhere Integrationsaufwände mit sich. Welche Lösung bietet Ihrem Unternehmen den größten Mehrwert?