Agilität und Stabilität – Strategieinterview
Wenn es um den „Goldschatz“ Daten geht, fällt oft und schnell der Begriff MDM, Master Data Management, oder auch MDG, Master Data Governance. Aber diese Buzzwords und deren Funktionsumfang greifen viel zu kurz, wenn ein ERP-Releasewechsel ansteht.
Wenn zusätzlich auch noch die ERP-Datenbank ausgetauscht werden muss, wie das im Fall von Hana und S/4 bis 2025 der Fall sein wird müssen, dann braucht man wesentlich mehr als ein SAP’sches MDM und MDG.
Mit Thomas Failer, Gründer der Data Migration Services, führte E-3 Chefredakteur Peter M. Färbinger folgendes Strategieinterview.
Peter M. Färbinger: Herr Failer, Sie und Ihr Unternehmen haben sich seit über 20 Jahren auf die Historisierung und Migration von Altdaten und -dokumenten spezialisiert, insbesondere bei SAP-Bestandskunden. Was war in diesem Zeitraum die größte Veränderung im Markt?
Thomas Failer: Die größte Veränderung findet gerade jetzt statt. Das Grundproblem, dass es viel zu teuer und aufwändig ist, bei einem Wechsel auf neue Softwaregenerationen die Altsysteme weiterzubetreiben und sämtliche Altdaten und -dokumente zu migrieren, gab es in der IT zwar schon immer. Aber noch nie war das Problem so groß wie heute.
Färbinger: Woran liegt das?
Failer: Der Hauptgrund besteht darin, dass mehrere Entwicklungen miteinander konvergieren. Der Schutz des geistigen Eigentums und der persönlichen Daten wird immer wichtiger, sowohl wegen der Regularien, man denke nur an die europäische Datenschutzgrundverordnung, aber auch wegen der immer raffinierteren Angriffe von Cyberkriminellen und -spionen.
Gleichzeitig können die Unternehmen diese Daten nicht mehr hinter dicken und hohen Mauern abschirmen. Denn die Vernetzung ist das Gebot der Stunde, entlang ganzer Lieferketten bis hin zum Endkunden.
Färbinger: Sie spielen damit auf die Cloud an?
Failer: Das ist mehr als eine Anspielung. Denn die Cloud ändert in der Tat alles. Sie stellt nicht nur eine neue Art und Weise dar, wie und wo die IT sozusagen produziert wird, sondern auch und vor allem, wie sie konsumiert wird.
Der Grad an Flexibilität, Ressourcenverfügbarkeit, Geschwindigkeit und Einfachheit stellt für die Unternehmen einen Quantensprung dar. Gleichzeitig kommt die IT der Unternehmen dadurch unter einen gnadenlosen Zugzwang.
Denn sie muss genauso agil, flexibel und schnell werden wie die großen Cloud-Anbieter. Außerdem muss sie denselben Bedienkomfort bieten.
Färbinger: Gilt das auch für die SAP-Bestandskunden?
Failer: Das gilt für alle gleichermaßen. SAP-Bestandskunden, die nicht auf der Höhe der Cloud-Standards sind, werden die Digitalisierung nicht meistern. Die Anwender werden sich abwenden und Services von öffentlichen Cloud-Anbietern nutzen. Im Extremfall müssten die Manager dann die IT komplett auslagern.
Färbinger: Sind sich die SAP-Bestandskunden dessen bewusst?
Failer: Ja natürlich. Sie verfolgen mit Argusaugen die Cloud-Strategie der SAP. Dass viele von ihnen zögern, auf die neue Softwaregeneration aus Walldorf eher heute als morgen umzusteigen, liegt aber nicht daran, dass sie diese Strategie prinzipiell infrage stellen.
Färbinger: Sondern?
Failer: Die zögerliche Haltung ist Ausdruck tiefer Überlegung, aber auch von Verunsicherung, denn die Unternehmen wissen, wie komplex die Migration ist. In den SAP-Landschaften schlägt das Herz der Unternehmen.
Dort liegen nicht nur die Kronjuwelen, das geistige Eigentum, etwa in Form von Bauplänen, Patenten oder Rezepturen. Vielmehr ist dort auch sehr spezifisches Prozesswissen gleichsam in Software gegossen.
Dieses Wissen haben die SAP-Bestandskunden über Jahre mit viel Zeit, Mühe und natürlich Geld aufgebaut.
Färbinger: Und das wollen die Anwender auch in die S/4-Hana-Welt übernehmen?
Failer: Spontan ist man versucht, mit einem eindeutigen und ausschließlichen Ja zu antworten. Fakt ist jedoch, dass auch diese Frage zurzeit in der Community heftig diskutiert wird.
Sicher, Customizing war, ist und bleibt ein Topthema bei den SAP-Bestandskunden. Doch aus meinen Gesprächen weiß ich, dass diese zurzeit sehr genau überlegen, ob sie den Übergang zu S/4 und Hana zu einer Neugestaltung der Prozesse nutzen wollen.
Diese Bereitschaft, zum vorgegebenen Prozessstandard zurückzukehren, dürfte bei zehn bis 20 Prozent der SAP-Bestandskunden vorhanden sein. Natürlich ist das die Minderheit, es sind aber auch nicht wenige.
Färbinger: Bedeutet die Entscheidung für den Standard nicht einen Vorsprung bei der Migration?
Failer: Das lässt sich so pauschal nicht sagen. Denn unabhängig vom gewählten Ansatz – ob Rückkehr zum Standard, Implementierung von S/4 inklusive Customizing auf der grünen Wiese oder paralleler Betrieb von S/4 und Business Suite – stehen alle SAP-Bestandskunden vor ein und demselben grundlegenden Problem: Nur wenige wissen, wie sie mit den Daten und sonstigen Informationen in ihren Systemen bei der Migration umgehen sollen.
Das ist der Grund für die Verunsicherung und das Zögern. Die niedrige und deshalb beklagte Quote von bereits erfolgten S/4-Hana-Implementierungen ist die logische Folge davon.
Färbinger: Aber die IT sollte doch schon immer das Geschäft unterstützen!
Failer: Auch das ist richtig. Aber allein den Begriff Agilität führen wir erst seit wenigen Jahren im Mund. Die Unternehmen müssen immer schneller auf Marktveränderungen reagieren.
Sie kaufen ständig hinzu und verkaufen Geschäftsbereiche oder Tochterfirmen. Sie passen ihre internen Prozesse kontinuierlich an und strukturieren um. All das passiert viel häufiger und schneller als früher. Diese ständigen Veränderungen müssen am Ende immer von der IT bewältigt, abgebildet und unterstützt werden.
Unternehmen atmen. Das muss auch die IT können. Das gilt insbesondere für die historisch gewachsenen und daher komplexen SAP- Umgebungen.
Färbinger: Was gibt es hier zu tun?
Failer: Es gilt, einen Grundwiderspruch aufzulösen, der den Applikationslandschaften bisher inhärent ist. Damit die IT das Geschäft unterstützen kann, müssen sich die Applikationen und Services flexibel ändern lassen.
Doch das mögen die damit verbundenen Daten und Informationen gar nicht. Sie brauchen sowohl aus geschäftlichen als auch rechtlichen Gründen Stabilität. Datenstrukturen und Kontextinformationen dürfen nicht verändert werden. Das Grunddilemma lautet: Agilität versus Stabilität.
Färbinger: Wie lässt sich dieser Widerspruch auflösen?
Failer: Die Lösung besteht darin, die Ebene der Applikationen von derjenigen der Daten zu entkoppeln. Das ist der richtige Ansatz. Wenn sich beide Ebenen unabhängig voneinander verwalten lassen, kann die IT die beiden widerstreitenden Ziele unabhängig voneinander verfolgen. Den Gordischen Knoten löst man nicht, man durchtrennt ihn.
Färbinger: War das nicht die Idee einer serviceorientierten Architektur?
Failer: Das ist richtig und mit S/4 und Hana ist diese Entkopplung auch in der Architektur weit mehr angelegt als bisher in der Welt der Business Suite. Doch das Problem, das dem Dilemma zwischen Agilität und Stabilität zugrunde liegt, geht noch etwas tiefer. Man muss zusätzlich noch eine Unterteilung auf der Datenebene selbst machen.
Färbinger: Warum?
Failer: S/4 bringt völlig neue Datenstrukturen, die Zahl der Tabellen reduziert sich bei großen Implementierungen von über 100.000 auf vielleicht 20.000. Die in den SAP-Bestandssystemen generierten Daten und die dazugehörige Geschäftslogik müssen aber unverändert aufbewahrt werden, damit die Unternehmen ihre gesetzlichen Auflagen erfüllen können.
Folglich gelingt die Entkopplung der Applikationen und Daten auf Dauer nur dann, wenn die operativen Daten von denen getrennt werden, die im Tagesgeschäft nicht mehr benötigt werden.
Färbinger: Wie sind die SAP-Bestandskunden bisher mit diesem Problem umgegangen?
Failer: In der Regel haben sie nach der Datenübernahme und -transformation ihre Bestandssysteme gleichsam eingefroren, deren Verbindungen zur Außenwelt gekappt und den Ressourcenverbrauch unter anderem durch Virtualisierung reduziert. Die rechtliche Seite bekommen sie damit in den Griff. Doch agil werden sie dadurch noch lange nicht.
Färbinger: Warum nicht?
Failer: Stellen Sie sich eine Revision vor. Ein Steuerprüfer möchte sechs Jahre nach Einfrieren eines Systems auf darin enthaltene Rechnungsdaten und -belege zugreifen. Können Sie garantieren, dass die Maschine wie gewünscht wieder hochfährt?
Oder ein Geschäftsbereich wird verkauft. Der Käufer benötigt alle Altdaten inklusive Geschäftslogik. Können Sie diese Informationen zuverlässig im eingefrorenen System identifizieren, exakt herauslösen und dem Käufer in einem neutralen Format übergeben, sodass dieser nicht erst das Altsystem bei sich eins zu eins nachbauen muss, um die Daten überhaupt lesen zu können?
Oder aber ein Kunde verlangt die Löschung seiner Daten nach der europäischen Datenschutzgrundverordnung (EU-DSGVO).
Können Sie dann ohne viel Aufwand alle Rechnungen ermitteln, die älter als zehn Jahre sind und somit gelöscht werden dürfen? Sind Sie in der Lage zu garantieren, dass alle anderen Rechnungen zu diesem Kunden nach Ablauf ihrer Aufbewahrungsfrist automatisch gelöscht werden? In der Regel lautet die Antwort auf diese Fragen Nein.
Färbinger: Das klingt so, als ob es keinen Ausweg gäbe.
Failer: Doch – und das ist ja der Grund dafür, dass es uns überhaupt gibt. Die Idee entstand bei Migrationsprojekten von R/2 nach R/3 und hat sich bewährt. Werden alle Daten inklusive Dokumenten zusammen mit ihrer Geschäftslogik aus den Altsystemen herausgelöst und revisionssicher in einem plattformübergreifenden Format auf einer modernen Plattform abgelegt, lässt sich ihr gesamter Lebenszyklus bis zur Löschung unabhängig von den Ursprungssystemen verwalten.
Das ist die Grundlage für alles Weitere: die Transformation der Daten und ihre anschließende Migration sowie die Optimierung der Datenqualität und insbesondere die Abschaltung der Altsysteme. Denn es ist weder wirtschaftlich noch technisch sinnvoll, sämtliche Altdaten und -dokumente mit in die neue Welt zu übernehmen.
Ganz abgesehen davon, dass es gar nicht genügend Migrationsexperten gibt, um den Umstieg auf S/4 und Hana bis 2025, dem von der SAP gesteckten Zeitrahmen, zu bewältigen.
Färbinger: Worin besteht der Unterschied zu den eingefrorenen Systemen?
Failer: Eine eigenständige Plattform zur Verwaltung des Lebenszyklus von Altdaten und -dokumenten inklusive Geschäftslogik schafft zum einen Rechtssicherheit, denn Umfang und Struktur der Informationen bleiben unverändert erhalten.
Außerdem lassen sich damit die Anforderungen der EU-DSGVO erfüllen, insbesondere zur Löschung auf der Ebene des einzelnen Datensatzes. Zum anderen sorgt sie für mehr Sicherheit, denn sie ist ja ein lebendes System und kann gewartet und regelmäßig gepatcht werden.
Darüber hinaus aber ist ihr Betrieb ungleich billiger gegenüber dem Weiterbetrieb der Altsysteme, in der Regel um 80 Prozent, manchmal sogar mehr.
Färbinger: Das hat aber noch nichts mit Migration zu tun.
Failer: Die Herauslösung und Aufbewahrung der Informationen inklusive ihrer Geschäftslogik, wir nennen das übrigens Historisierung, ist die Voraussetzung für eine technisch, geschäftlich und wirtschaftlich sinnvolle Migration. Die Plattform ist sozusagen das Sprungbrett, von dem aus sich alle anderen Ziele erreichen lassen.
Färbinger: Das müssen Sie genauer erklären.
Failer: Es sind unsere Kunden, die das erkannt haben. Wenn alle Informationen rechtssicher auf der Plattform liegen, müssen ja nur noch diejenigen ins neue System übernommen werden, die dort für den laufenden Geschäftsbetrieb benötigt werden.
In der Regel bedeutet das eine Datenreduktion von 50 Prozent bis 75 Prozent. Dabei gilt: Dieser Wert ist umso größer, je höher die Qualität der zu migrierenden Daten ist.
So können wir auf der Plattform noch vor der Migration fehlerhafte Datensätze korrigieren, Dubletten löschen und die Datensätze mit Informationen aus anderen Quellen anreichern. Jeder Systemwechsel ist doch eine Chance auf mehr Datenqualität!
Färbinger: Wie machen Sie das?
Failer: Wir unterteilen den Gesamtprozess von der Planung der S/4-Hana-Migration bis zum Betrieb zusammen mit unserer Plattform in vier Schritte: Identify, Design, Execute und Operate.
Bislang haben wir Produkte für die Execute-Phase, das heißt die Historisierung der Informationen und die anschließende Migration. Zurzeit entwickeln oder bündeln wir die Tools für die anderen drei Phasen.
Färbinger: Wie muss man sich das vorstellen?
Failer: Bei Identify geht es vereinfacht gesagt darum, auf Knopfdruck Art und Menge der Informationen zu ermitteln, die nicht in S/4 übernommen werden müssen.
Das ist eine Potenzialanalyse, die den Interessenten zusätzlich visuell darstellt, wie die Informationen, die auf unserer Plattform verbleiben, aussehen werden. Das schafft Vertrauen, denn sie erkennen sehr schnell, dass alles genauso aussieht, wie sie es aus den Bestandssystemen kennen.
Potenzial und Vertrauen schaffen die Voraussetzung für die grundsätzliche Entscheidung, dass und wie sich unser Ansatz für den Weg nach S/4 lohnt.
Färbinger: Was passiert in Phase zwei?
Failer: Bei Design geht es um die Feinplanung. Hier werden die genauen Filterkriterien zur Datenselektion und -übernahmen entwickelt. Unser Ansatz lautet dabei, die exakten Filterregeln als XML-Daten bereitzustellen. Das gibt den Kunden die Wahl, zu entscheiden, mit welchem Migrations- und Konvertierungswerkzeug sie die Datenübernahme machen wollen.
Färbinger: Bleibt noch das Thema Operate.
Failer: Im Grunde ist das vor allem ein Integrationsthema. Denn um Teil der Ziellandschaft zu sein, entwickeln wir Integrationen zu den Hana-basierenden Applikationen wie S/4 und C/4 oder Oberflächen wie SAP Fiori.
Zwar muss nicht so oft auf nicht-operative Daten zugegriffen werden, doch wenn das aus geschäftlichen Gründen der Fall ist, muss das für die Anwender möglichst einfach aus ihrer gewohnten Umgebung heraus möglich sein, ohne dass sie lange nach den gewünschten Informationen suchen oder ihre Anwendungsumgebung wechseln müssen. Das ist die Art von Bedienkomfort, die Anwender heute gewohnt sind, von der Cloud und von ihrem Smartphone.
Färbinger: Bis wann werden diese Tools Marktreife erlangen?
Failer: Die Prototypen entstehen gerade. Fertige Pakete für die hochautomatisierte Migration auf S/4 oder C/4 wollen wir bis Herbst 2019 fertigstellen. Unser Ziel ist es, unsere Kunden agiler zu machen.
Das verändert auch uns. So haben wir aufgrund der erweiterten Produkt-Roadmap unsere eigene Entwicklung auf agile Methoden umgestellt, um schneller zu werden, ohne dass die Qualität leidet, im Gegenteil.