Mit zeitlich gestreckten Milestones wollen Unternehmen laut DSAG-Vorstand Otto Schell Zahlungsziele verschieben. Die wichtigste Vorarbeit für eine erfolgreiche Migration ist die Definition des zu erreichenden Ziels.
Exklusiv-Interview
Welche Themen bewegen derzeit die DSAG-Mitglieder, und wie werden die auf dem DSAG-Kongress diskutiert?
Die Themen, die wir im vergangenen Jahr aufgegriffen haben, sind nach wie vor aktuell, nämlich Migration, Integration und hybride ERP-Landschaften. Wegen Corona findet der DSAG-Jahreskongress in diesem Jahr nicht statt und wir bieten stattdessen ein virtuelles Alternativprogramm an, die DSAGLIVE. In den Vordergrund stellen wir die Diskussion mit der SAP. SAP-CEO Christian Klein wird einen strategischen Ausblick geben, während Chief Technology Officer Jürgen Müller und der Leiter von SAP Product Engineering, Thomas Saueressig, im Gespräch mit den Fachvorständen der DSAG auf spezifische Themen eingehen.
Wir geht es mit der Migration auf S/4HANA weiter? In welchem Umfang haben Unternehmen Projekte verzögert oder gestoppt?
In den vergangenen sechs Monaten haben viele Unternehmen ihre SAP-Strategie überarbeitet. In den meisten Fällen laufen die Projekte weiter, denn dahinter steht ja ein Business Case. Oft verschieben Unternehmen aber bestimmte Milestones, um damit letztlich die Zahlungsziele zu verschieben. Das eine oder andere Projekt wird auch gestoppt. Wir hören aber nicht, dass nun Unternehmen im großen Stil ihre Migrationspläne einstampfen. Aus vielen Projekten wird Tempo rausgenommen, und das kommt auch daher, dass die beteiligten Mitarbeiter in Kurzarbeit sind. Dann müssen beispielsweise sämtliche Testpläne umgestellt werden.
Die konzeptionelle Arbeit muss bei S/4HANA früher beginnen
Greenfield, Brownfield und Bluefield: Für wen eignet sich typischerweise welcher Migrationsansatz?
Wichtig ist es zunächst, dass ein Unternehmen festlegt, welches Ziel mit der Migration erreicht werden soll. Bei den früheren Release-Wechseln gab es drei Varianten: der operationelle Weg, ohne große Veränderungen auf das neue Release zu wechseln, oft eine rein technische Migration, bei der die alten Prozesse im neuen System nachgebildet wurden. Die zweite Variante war die taktische Migration. Dabei hat man das Customizing des Altsystems soweit möglich zurückgefahren und durch standardisierte Abläufe des neuen Systems ersetzt. Die dritte Möglichkeit war die strategische Variante, neue Geschäftsprozesse einzuführen und damit die Basis für ein späteres neues Geschäftsmodell zu legen. Diese drei Varianten gibt es nach wie vor. Bei S/4HANA ist allerdings die konzeptionelle Arbeit umfangreicher, und sie muss zudem früher beginnen.
Was sind die größten Unterschiede?
S/4HANA nutzt neue Datenmodelle. So entfällt beispielsweise im Finance-Modul die bisherige Trennung zwischen Accounting und Controlling. Das neue Datenmodell ist offen, und die Unternehmen können auf dieser Basis ihre Geschäftsprozesse neugestalten. Das reicht bis hin zum sogenannten Predictive Closing, wo ein Unternehmen seine Bücher bereits einen Monat früher schließt. Solche Möglichkeiten sind insbesondere für Service-Organisationen interessant. Die Kehrseite dabei: Will ein Unternehmen derartige Kapazitäten von S/4HANA nutzen, muss sich das Management vorher Gedanken machen, in welchem Umfang beim Release-Wechsel die Organisation angepasst werden soll. Das wiederum beeinflusst die Entscheidung für einen der oben beschriebenen Migrationsansätze.
Die Organisation lässt sich nicht so schnell verändern wie die Technologie
Ist Organisation demnach wichtiger als Technologie?
Nicht unbedingt. Viele Unternehmen nutzen SAP bereits 20 Jahre oder länger. Die Systeme sind dann Legacy geworden, also technisch veraltet. Es ist ein valider Business Case, die Plattform im Rahmen der Migration zu konsolidieren und Realtime-fähig zu machen. Generell gibt es keinen Migrationsansatz, der überall gleich gut passt. Die Unternehmen müssen daher entscheiden, was genau sie mit der Migration erreichen wollen, und wie stark sie dabei ihre Abläufe verändern wollen. Beim Brownfield-Ansatz werden die bisherigen Abläufe weitgehend übernommen, während in der Greenfield-Variante neue Abläufe entstehen. Die Bluefield-Variante ist eine Mischung der genannten Ansätze. Man übernimmt Prozesse, die gut laufen und ersetzt Teile des bisherigen Customizings durch Standardprozesse. Da sich die Organisation eines Unternehmens nicht so schnell verändern lässt wie die Technologie, werden Unternehmen immer einen Teil ihrer bisherigen Prozesse weiterführen.
Wie stellen Unternehmen mit stark angepassten SAP-Systemen sicher, dass die Migration möglichst reibungslos läuft?
Das Customizing eines älteren ERP-Systems in den Griff zu bekommen, ist keine allzu große Hürde. Es gibt Tools von der SAP und von Drittherstellern, mit denen man im Altsystem prüft, ob sich eine bestimmte individuelle Funktion in einem neueren Release im Standard abbilden lässt. Diese Werkzeuge sind bereits aus früheren Release-Wechseln gut bekannt und etabliert. Eine Hürde sind allerdings die neuen Datenmodelle von S/4HANA, die dazu führen, dass das neue System nicht ohne weiteres mit den noch laufenden Altsystemen kommuniziert. Hinzu kommen in vielen Unternehmen externe und proprietäre Systeme. Um sicherzustellen, dass die neuen SAP-Datenmodelle dazu passen, müssen die Systemarchitekten die Schnittstellenlisten durchgehen und bei Bedarf Adapter erstellen.
Anzeige | kostenloses Webinar der Trovarit Academy
SAP S/4HANA®-Migration erfolgreich bewältigen
- SAP S/4HANA® vs. SAP Suite®
- Migrationspartner wählen
- Budget-, Zeit- und Ergebniskontrolle im Projekt
- Cloud
Referenten: Peter Treutlein, Dr. Jens Biermann | Trovarit AG
Termine & Anmeldung
Wie lässt sich der Aufwand dafür gering halten?
Wichtig ist hier die vorbereitende Migrationsstrategie. Administratoren können nicht die Testskripts der früheren Jahre nutzen, sondern müssen diese zum großen Teil neu erstellen. Auch personelle Veränderungen stehen an. Unternehmen können nicht alleine mit dem Team arbeiten, das ihr SAP seit Jahren betreut. Vielmehr müssen sie die Veränderungen der Prozesse mit den Experten aus den jeweiligen Fachbereichen abstimmen. Aber auch die beste Vorbereitung schützt nicht vor Überraschungen. Teilweise merkt man erst kurz vor dem Go-Live, dass man seine Teststrategie schärfen muss. Erst wenn man die Stammdaten und Bewegungsdaten migriert, dann zeigt sich nämlich, wie die anderen Systeme wirklich darauf reagieren.
Erst wenn Manager in Netzwerken denken, entstehen Plattformlösungen
Wie sieht aktuell die Akzeptanz der Cloud aus?
Wirklich neu ist das Prinzip der Cloud nicht. Hosting und Outsourcing betreiben Unternehmen seit Jahren. Das war der Cloud schon sehr ähnlich. Nur dass die IT-Manager beim Hosting-Partner den Server anfassen konnten, in dem angeblich ihre Daten lagerten. Auch bei der Cloud geht es im ersten Schritt um das Verlagern von Daten. Inzwischen hat sich das etabliert. Wenn Unternehmen die Daten in der Cloud lagern und auch Systeme dort betreiben, heißt das aber noch lange nicht, dass sie in Netzwerken denken. Der Zusammenbruch einiger Lieferketten durch Corona hat gezeigt, dass die Unternehmen noch lange nicht in der Lage sind, gemeinsam mit anderen Unternehmen im Netzwerk nach Lösungen zu suchen.
Woran hakt es konkret?
Eine Umfrage, welche die DSAG zusammen mit der amerikanischen SAP-Anwendervereinigung ASUG gemacht hat, zeigt auf, dass viele Unternehmen mit S/4HANA weiterhin eine klassische Systemwelt aufbauen. Die wenigsten sind schon so weit, dass sie sich austauschen und bestimmte Prozesse gemeinsam fahren, um sich gegenseitig in einer solchen Krise abzusichern. Aktuell ist die Angst viel zu stark, sich von Partnern oder gar von einem OEM-Lieferanten abhängig zu machen. Es dauert noch, bis CEOs erkennen, dass die bisherige Arbeitsweise, nämlich die hausinterne Optimierung, ohne sich mit Partnern und Lieferanten abzustimmen, langfristig nicht mehr ausreicht. Das hat wenig mit SAP zu tun, sondern mehr damit, dass die Manager noch nicht in Netzwerken denken. Erst wenn das passiert, haben wir eine Chance für tatsächliche Plattformlösungen.
Das Teilen von Daten erfordert Incentives und Sicherheit
Wenn wir davon ausgehen, dass sich Geschäftsmodelle künftig öfter ändern müssen: welchen Einfluss hat das auf die künftige Architektur von IT-Systemen und auf die darin abgebildeten Arbeitsweisen?
Die IT-Architektur geht längst in Richtung Cloud, und die Arbeitsweisen müssen sich daran anpassen. Corona beschleunigt solche Änderungen. Vor dieser Pandemie wäre es undenkbar gewesen, dass Millionen Deutsche sich die COVID-19-App auf ihr Handy laden und darin ihre Bewegungsdaten freigeben. Der erwartete Nutzen lässt alle Bedenken in den Hintergrund treten. Einige Business-Modelle zeigen den Nutzen des Teilens von Daten auf. Bei einem intelligenten Fahrzeugreifen, der weiß, wo das Auto wie gut fährt, werden die Fahrzeughersteller die Daten für sich beanspruchen. Aber diese Informationen sind auch für Verkehrsämter oder für Straßenbauer interessant. Die Weitergabe könnte durch ein Incentive belohnt werden. Um eine Kultur des Teilens von Daten zu etablieren, müssten wir herausarbeiten, wer davon welchen Nutzen hat und sicherstellen, dass niemand diese Informationen missbrauchen kann.
Integration war früher die große Stärke der SAP. Beim Wandel hin zur Cloud haben die Walldorfer Systeme zugekauft, die unterschiedliche Datenmodelle aufweisen. In der Initiative One Master Data Service sollen diese Modelle über die Cloud harmonisiert werden. Wie kommt diese Initiative voran?
Das Thema Integration haben wir in der DSAG ganz hoch angesiedelt, und wir sehen auch, dass sich hier etwas bewegt. Die One Master Data Services sind riesige Konvertierungstabellen, welche die Daten aus verschiedenen Systemen harmonisieren. Einen ähnlichen Ansatz nutzen die Unternehmen bereits für Master Data Governance. Hier setzen sie eine Box zwischen SAP-Systeme und Anwendungen von Drittherstellern, um die Daten zu harmonisieren. Das kann gut gehen, setzt aber voraus, dass die Unternehmen bereit sind, bei der Datenharmonisierung nicht mehr auf eine hausinterne Lösung, sondern auf einen Cloud-Service zu vertrauen. Ein ähnliches Prinzip plant SAP auch für andere Bereiche.
SAP sollte Produktänderungen vorab mit den Anwendern besprechen
Wo zum Beispiel?
Bei Steueränderungen muss SAP für die Systeme in den Unternehmen Patches anbieten. Unternehmen setzen aktuell viele Releases ein, und die pflegt SAP bislang mit einem sehr hohen Aufwand individuell. Die Idee ist es nun, die Steueränderungen nur einmal einzupflegen, und zwar in einen Cloud-Service, mit dem die Unternehmen ihre ERP-Systeme verbinden. Das senkt den Aufwand der SAP, aber Unternehmen müssen dafür ihre Architektur verändern. Das wollen und können nicht alle. Es ist deshalb aus unserer Sicht wichtig, solche Änderungen vorab zu besprechen. SAP muss in ihrer Strategie weit vorausblicken. Es hat aber keinen Sinn, Lösungen zu entwickeln, die Bestandskunden nicht oder nur sehr schwer nutzen können. Unternehmenskunden verlieren schließlich Geschäfte, wenn sie ihre ERP-Systeme nicht mehr gut genug adaptieren.
Der Gesprächspartner
Otto Schell
ist stellvertretender Vorstandsvorsitzender der DSAG. Hauptberuflich agiert er als Global Enterprise SAP Business Architect and Head of SAP CCoE bei der Opel Automobile GmbH (PSA Group). Von 2002 bis 2009 war er bei General Motors SAP Program Manager für die europäischen Powertrain Units. Außerdem ist er als Business Integration Manager im Rahmen eines globalen SAP-Projekts aktiv. In der DSAG ist er seit 1996 aktiv, zunächst als Sprecher der Arbeitsgruppe Security, ab 2005 als Sprecher des Arbeitskreises Globalization, ab 2008 als Vorstand IoT/Business Transformation und seit 2018 als stellvertretender Vorstandsvorsitzender.
Der Autor
Jürgen Frisch ist seit mehr als als 20 Jahren als Journalist in der IT-Branche unterwegs. Für die IT-Matchmaker®.news verfasst er aktuelle Nachrichten und Interviews.
