Die Umstellung der SAP-Systeme auf das neue S/4Hana beschäftigt Schweizer CIOs. Bis 2025 muss die Migration über die Bühne gebracht sein, sagt der deutsche ERP-Hersteller. Im Zuge des Updates bietet es sich an, die Infrastruktur grundlegend zu erneuern und Altsysteme abzuschalten, sagt Thomas Failer. Seine Firma Data Migration Services ist spezialisiert auf Systemstill­legungen – im SAP-/Non-SAP-Umfeld und auch für M&A-Szenarien, wie er im Interview mit Computerworld sagt.

Thomas Failer: (seufzt) Ja, der Knackpunkt. Ich sehe zwei: Erstens ist das Stilllegen von Altsystemen nicht gerade ein Projekt mit hoher Priorität bei den CIOs. Von 100 Unternehmen haben vielleicht fünf Firmen eine Massnahme für die Legacy in der Umsetzung. Das ist in den USA übrigens ganz anders. Dort ist klar: Es gibt kein S/4Hana-Projekt, ohne vorher die Systemlandschaft aufzuräumen. Dort erkennt man den Mehrwert des Stilllegens viel eher als etwa in der Schweiz. Ein Hauptgrund ist, dass der Return für ein solches Vorhaben in vielen Fällen unter einem halben Jahr liegt und dabei Einsparungen zwischen 1 und 100 Millionen Franken realisiert werden können. Zweitens ist das Thema auch im S/4-Umfeld noch nicht so heiss. Die SAP-Migrationen sind vielerorts noch in der Planung, mit dem tatsächlichen Projektstart ist meist erst 2021 zu rechnen. Diese Verzögerung oder Zurückhaltung sind für uns allerdings kein Problem. Wir wachsen seit drei Jahren mit um die 50 Prozent und gehen aufgrund der wachsenden Pipeline sogar von Wachstumsraten deutlich höher als 50 Prozent aus. Mit der steigenden Aufmerk­samkeit für potenzielle Kosteneinsparungen durch Still­legung – insbesondere im Zusammenhang mit den bevorstehenden SAP-Projekten – bin ich sehr zuversichtlich, dass wir unsere Ziele wieder erreichen werden.

Failer: Die rund 12'700 Kunden von SAP im deutschsprachigen Raum müssen alle bis 2025 umgestiegen sein. In den letzten fünf Jahren vor dem Termin werden noch 10'000 Firmen umstellen. Im Idealfall sind es 2000 pro Jahr. Für die reine Datenmigration – die erfahrungsgemäss 25 Prozent des Projekts ausmacht – gibt es viel zu wenig Experten. Meine Schätzung wäre, etwa die fünffache Anzahl Personen ist erforderlich, um den Bedarf in Zukunft zu decken. Heute gibt es im deutschsprachigen Raum ca. 3000 Spezia­listen für diese Themen. Bei den Migrationen wird Software helfen müssen. Aufgrund unserer Projekterfahrung lässt sich etwa 50 Prozent des Aufwandes reduzieren. So liesse sich dann auch der Engpass beim Personal verringern.

Failer: Traditionell bedeutet eine Migration, dass man probiert, sämtliche Daten aus den Altsystemen auf die neue Plattform zu transformieren – wie sinnvoll das auch immer ist. Dabei entstehen Silos mit historischen Daten, die aus Gründen der Compliance in ihrem ursprünglichen Format abgelegt werden müssen. Diese Datenhaltung durch Weiterbetrieb der Altsysteme verursacht enorme Kosten. Nur selten wird die Möglichkeit erwogen, die Informationen getrennt von den Altsystemen zu verwahren. Gemäss Schätzungen des Beratungsunternehmens Cap­gemini könnten bis zu 50 Prozent der Altsysteme ab­geschaltet werden, wenn es eine einfache Exportmöglichkeit und Plattformen gäbe, mit denen man die Daten wie zuvor anzeigen kann. Wir haben mit Jivs eine Lösung entwickelt, die auf Knopfdruck zum Beispiel die Daten aus einem SAP-System vollständig extrahiert und sie in einem maschinenlesbaren Format speichert. Der Zugriff kann dann qualitativ gleich wie bisher erfolgen.

Failer: Ein klares Jein. Zwischen 80 und 90 Prozent der Transaktions­daten haben eine Durchlaufzeit von maximal zwei Jahren. Dann sind die Waren angeliefert, bezahlt, verschickt. Anschliessend haben die Informationen für die Buchprüfer oder das Business wie zum Beispiel After-Sales einen Wert. Diese Altdaten haben aber keinen direkten Nutzen mehr für die operative Abwicklung auf dem Neusystem. Ergo müssen nur zwischen 10 und 20 Prozent der Daten noch ins neue System übernommen werden. Wenn doch ein Prüfer oder jemand aus dem Fachbereich die historischen Daten sehen möchte, kann er dies auf der Datenhistorienplattform machen. Dieser bimodale Ansatz – wie wir ihn nennen – hilft den Kunden, bis zu 50 Prozent der Migrationskosten zu sparen. Weiter müssen sie nur noch einen Bruchteil der Systeme betreiben, weil die Legacy abgeschaltet und die Daten separat gespeichert sind. Die neuen Anwendungen sind drittens nicht mehr mit den Altdaten belastet, womit die Betriebskosten sinken. Unter dem Strich betragen die mög­lichen Einsparungen bis zu 80 Prozent.

Failer: Ja, im Gegensatz zu den meisten Legacy-Systemen schon. Viele der Altsysteme erlauben einen ausschliesslich lesenden Zugriff. Wer dort Informationen endgültig löschen muss, steht vor einem Problem. Bei Jivs haben wir eine entsprechende Funktion vor Inkrafttreten der Datenschutz-Grundverordnung implementiert. Wer nun einen Lösch­antrag erhält, kann die fraglichen Informationen gesetzeskonform löschen. Alle Modifikationen der Originaldaten werden dabei protokolliert.

Failer: Ein sehr bemerkenswerter Kunde ist die Eidgenössische Finanzverwaltung. Sie setzt auf eine SaaS-Lösung (Software as a Service), bei der wir eine Verfügbarkeit von 25 Jahren garantieren mussten. Denn die Verwaltungs­einheit ist auch zuständig für Bauprojekte, bei denen so lange Aufbewahrungsfristen vorgeschrieben sind. Der erste Kunde mit einer S/4-Migration ist die Zur Rose Gruppe. Die Versandapotheke hat mehrere Systeme konsolidiert, die Geschäftspartnerstammdaten harmonisiert und bereinigt. Ebenfalls auf Basis von Jivs werden die Daten migriert und man hat sich entschieden, dass man die Altsysteme mit Jivs stilllegen wird. International interessant ist auch LafargeHolcim mit einem Projekt, das weltweit aus der Schweiz getrieben wird und auch Nicht-SAP-Systeme miteinbezieht.

Failer: Wir beobachten nicht zwei, sondern drei Strategien: die Konvertierung von einem Standardsystem in ein neues Standardsystem. Dann die Transformation, wenn viele Eigenentwicklungen vorhanden sind, die auch in der neuen Umgebung weiterverwendet werden sollen. Schliesslich der Greenfield-Ansatz, bei dem die Altsysteme abgeschaltet und die Lösung von Grund auf neu aufgebaut wird. Meine Einschätzung wäre, dass vermutlich nicht einmal 10 Prozent der Kunden in der Lage sind, die Standardsysteme zu konvertieren. Denn so gut wie niemand arbeitet mit dem Standard. Die Transformationsprojekte sind sehr komplex. Dabei sollen Applikationen mit 100'000 Tabellen in Systeme mit nur noch 10'000 Tabellen migriert werden. Hier müssen sehr leistungsfähige Werkzeuge und viel Know-how aufgeboten werden, um die Umstellung zu schaffen. Auch bei dieser Gruppe an Unternehmen dürfte es sich um eine Minderheit handeln. Die Mehrheit wird einen Greenfield-Ansatz wählen oder eine Kombination mit der Transformation und SAP-Konversions-Tools. Dann werden die Grundsysteme neu aufgebaut sowie Prozesse neu definiert und implementiert. Und gewisse Funktionen werden aus den Altsystemen migriert.

Failer: Da bin ich relativ gelassen. Erstens sind wir aktuell nicht auf der Suche nach einem Käufer. Zweitens besetzen wir ein Thema, das den Kunden und auch SAP selbst helfen kann, Migrationen möglichst schmerzfrei zu bewältigen. Das Potenzial ist gross, sprechen wir doch von 50'000 Kunden weltweit und mehreren 100'000 Systemen. Aber das Thema ist weit weg vom heutigen und zukünftigen Geschäft der SAP. Denn Walldorf fokussiert auf Analytik, Big Data und künstliche Intelligenz. Und auch wir wollen uns weiterentwickeln. Beispielsweise, indem wir Funktionen mit künstlicher Intelligenz in unsere Lösungen einbauen.

Failer: Wir entwickeln uns in Phasen. Heute sind wir stark im automatisierten Implementieren und Betreiben von Umgebungen für Legacy-Daten. Diese Installationen sind kostengünstig und wartungsarm. Bereits heute können unsere Kunden, ob globale oder lokale Player, unsere Software aus der Cloud für Big-Data-Szenarien nutzen. Unsere nächste Entwicklungsphase wird sein, Tools für intelligentere Migrationen zu bauen. Wir nennen es «Identify» und «Design»: Heute bieten wir den Kunden einen Service an, der zum Beispiel eine SAP-Installation prüft und die für den operativen Betrieb notwendigen Daten iden­tifiziert. Diesen Service wollen wir mithilfe künstlicher Intelligenz und dem Fachwissen der besten Spezialisten auf unserem Gebiet in ein eigenes Produkt bündeln. Dafür müssen wir noch einige Migrationen abschliessen, damit die Maschine aus unserer Tätigkeit lernt und bestimmte Muster in den Vorgehensweisen erkennen kann. Das wäre «Identify». Bei «Design» geht es darum, Algorithmen zu entwerfen, die automatisch Daten klassifizieren nach ihrer Relevanz für das operative Geschäft. Anschliessend können die Algorithmen in Migrationswerkzeuge implementiert werden, sodass die Sortierung der Geschäftsdaten automatisch geschehen kann. Produkte für «Identify» und «Design» stehen in diesem Jahr auf der Agenda.

Failer: Eine weitere Phase für die Weiterentwicklung ist die universelle Anwendbarkeit unserer Lösung. Neben Still­legungen und der S/4-Migration gibt es noch weitere Cases, in denen Jivs nützlich sein kann. Ein Beispiel sind Firmenübernahmen: Mit einem zugekauften Unternehmen kommt auch eine ganze Menge neuer IT in den Konzern. Die Systeme werden heute meist manuell in die bestehende Applikationslandschaft integriert. Während wir Lösungen für das Stilllegen von Systemen liefern können, haben wir keine Anwendungen, die Systeme respektive Daten mit gleichen oder zumindest ähnlichen Funktionen zusammenbringen. Wir arbeiten deshalb an Lösungen, die Datenbestände und Business-Logiken ermitteln sowie dann mit vorhandenen Systemen zusammenbringen können. Wir haben Hilfe von Data Scientists, die auch jenseits der von SAP bekannten Tabellen und Hierarchien Zusammenhänge ermitteln können. Wir bieten dies zwar heute als eine Servicedienstleistung an. Diese analytischen Fähigkeiten sollen aber nach und nach in unser Produkt integriert werden. So wollen wir mit Produkten skalieren. Heute arbeiten schon viele global tätige und auch hochspezialisierte Implementierungspartner mit uns im Verkauf und im Rahmen von Projekten zusammen. Über die Partner sind wir schon jetzt auch ausserhalb des DACH-Raums in Regionen wie Asien, Nordamerika und Südafrika vertreten. Ebenso können wir über diese Community weltweit auf mehr als 100 Spezialisten zugreifen.

Failer: Wir haben im vergangenen Jahr mehr als 50 Prozent des Umsatzes in den USA erwirtschaftet. Dabei waren wir weder physisch dort präsent noch hatten wir einen Partner. Vielmehr haben wir die Lizenzen alle am Telefon verkauft. Ein Grosskunde hat sich beispielsweise für eine Enterprise-Lizenz entschieden. Mit Jivs wurden dort nicht nur SAP-Systeme stillgelegt, sondern auch verschiedene Business-Anwendungen, insbesondere PLM-Applikationen (Product Lifecycle Management). In dem Jivs-Archiv sind mittlerweile alle Daten sämtlicher Produkte gespeichert – bis hin zu Geräten aus dem Jahr 1905. Für die Implementierung waren wir aber nie vor Ort. Vielmehr haben wir alle Anwendungen remote aufgesetzt. Weitere Verkäufe an Grosskunden liefen über Partner, die auf der Basis von Projekten mit uns zusammengearbeitet haben. Über weltweit tätige Beratungsunternehmen konnten wir Kunden zum Beispiel in Südafrika und den USA gewinnen. Auch hier waren wir teilweise an der Implementierung beteiligt, was aber in 95 Prozent aus der Schweiz heraus geschah. Und erst kürzlich haben wir in den USA über ein anderes globales Beratungsunternehmen einen grossen Energiekonzern als Kunden gewinnen können.

Failer: Ja, DXC ist ein neuer Partner. Weiter arbeiten wir neu mit mehreren SAP-Beratungshäusern zusammen: Sie verwenden unsere Lösung manchmal als USP (Unique Selling Proposition). Teilweise reduzieren die Partner aber auch heute schon ihren Arbeitsaufwand, wohl wissend, dass sie ab 2021 noch genug zu tun bekommen, wenn dann die Zahl der Migrationen auf S/4Hana massiv ansteigen.

Failer: Für das Application Retirement kenne ich sechs Anbieter. Drei von ihnen setzen auf Virtualisierung. Sie betreiben Altsysteme inklusive Betriebssystem und Datenbanken unverändert in einer virtuellen Maschine weiter. Dieser Ansatz ist nicht nachhaltig, denn die Altsysteme müssen weiterhin gewartet werden, was mit viel Aufwand verbunden ist. Ausserdem ist die Lösung weder compliant noch sicher. Oft stehen Unternehmen innert kurzer Zeit erneut vor dem Problem: abschalten oder nochmals migrieren. Drei weitere Anbieter, von denen wir einer sind, übernehmen sämtliche Daten aus den Altsystemen und gewährleisten anschliessend den Zugriff darauf. Wir unterscheiden uns hier einerseits durch die hohe Automatisierbarkeit beim Transfer der Daten aus den Legacy-Systemen. Andererseits sind wir vorn bei den Business-Systemen. Von Haus aus liefern wir Merkmale von rund 2000 strukturierten Business-Objekten mit, von denen die Hälfte für SAP-Systeme passen und die auf Knopfdruck einen qualitativ gleichartigen Zugriff auf die Daten erlauben wie die Altsysteme. Damit sind die Grundbedürfnisse bei der Mehrheit der SAP-Installationen schon per Default abgedeckt.