Das Thema Datenmigration erweist sich für viele Unternehmen als Herausforderung, gilt es doch beim Wechsel eines ERP-Systems den „Altbestand“ an wertvollen Daten sauber mitzunehmen. Im Interview mit Midrange Mail (MM) erläutert Dieter Ackermann, Geschäftsführer der DAConsulting GmbH, Darmstadt, wie ein IT-Partner dabei unterstützen kann.
MM: Herr Ackermann, Sie helfen Unternehmen bei einem Wechsel des ERP-Systems in Sachen Datenmigration. Was ist der Hintergrund für diese Ausweitung Ihres Service-Portfolios?
Ackermann: Zum einen ist dieser „Service Datenmigration“ so neu nicht bei uns. Derartige Projekte betreiben wir schon seit langem, aber vielleicht nicht mit der Konzentration und Spezialisierung wie wir das heute tun. Zum anderen haben wir festgestellt, dass im Bereich der Ablösung von etablierten ERP-Systemen durch andere Lösungen ein erhebliches Projektaufkommen besteht.
MM: Gab es dazu einen besonderen Anlass?
Ackermann: Ja, besonders deutlich wurde uns das bei dem Marktsegment der Infor XPERT Systeme bewusst, welche – insbesondere in der Automotive-Industrie – unsere IT-Lösungen für die Purchase to Pay Prozesse nutzen. Durch eine vielleicht etwas unglückliche Produktpolitik von Infor wurde diesen Anwendern vermittelt, dass die – in der Regel langjährig und zur Zufriedenheit genutzten ERP Systeme – von der Wartung und Weiterentwicklung abgehängt werden, worin viele Nutzer ein erhebliches Risiko sehen, da in der Regel der gesamte Geschäftsbetrieb von den ERP-Systemen abhängig ist – kurz: Wer will schon mit einem Auslaufmodell arbeiten?
Quelle: DAConsulting GmbHDieter Ackermann ist Geschäftsführer der DAConsulting GmbH mit Sitz in Darmstadt.
MM: In welche Richtung migrieren diese Unternehmen ihre ERP-Systeme?
Ackermann: Zweifellos ist hier SAP mit S/4HANA ein Favorit. Der Grund dafür: Viele mittelständische Unternehmen gehören zu nationalen oder international operierenden Groups, welche bereits SAP nutzen, gerade einführen oder planen und dies dann für alle als Standard gesetzt ist. Weitere potenzielle Namen, die in XPERT-Migrationsprojekten auftauchen sind z.B. auch Infor LN, Pro Alpha, und – bei uns weniger bekannt – QAD und ORACLE. Auch hier gilt die Aussage, dass in vielen Fällen das zukünftige ERP-System als Standard durch die Muttergesellschaft vorgegeben wird.
MM: Bieten Sie auch für den Umstieg auf diese – und vielleicht auch andere ERP-Systeme – Ihre Migrations-Services an?
Ackermann: Grundsätzlich ja, wobei man unterscheiden muss zwischen Projekten, bei denen uns Quell- und Ziel-ERP-Systeme bekannt sind und Projekten bei denen uns beide oder zumindest ein System eher unbekannt ist.
MM: Welche Auswirkungen zieht diese Unterscheidung nach sich?
Ackermann: Zu Ersterem zähle ich ein Projekt der Datenmigration von Infor XPERT nach SAP, bei dem uns beide Systeme bestens bekannt sind und wir über ein erhebliches Know-how und entsprechende Projekterfahrungen verfügen. Bei einem Projekt der Datenmigration von Infor XPERT nach einem uns eher unbekannten System, z.B. QAD, kennen wir zwar das Quellensystem sehr gut, aber nicht das QAD – Zielsystem.
MM: Wie lässt sich das elegant handhaben?
Ackermann: Wir gehen ein solches Projekt in der Form an, dass wir uns mit dem Zielsystem – bzw. auch umgekehrt mit einem unbekannten Quellensystem – möglichst mit kompetenter externer Hilfe – soweit vertraut machen, um die wesentlichen Prozesse, Funktionen, Datenstrukturen und Datenformate soweit zu verstehen, um die relevanten Daten von Quellen- und Zielsystem planbar und korrekt zu migrieren.
MM: Wie läuft ein typisches Migrationsprojekt bei Ihnen ab und was gibt es dabei zu beachten?
Ackermann: Lassen Sie mich das an einem Projekt erklären welches wir kürzlich für ein Unternehmen der Automobilzulieferindustrie realisiert haben. Die Aufgabe war, die Daten eines seit langen Jahren genutzten Infor XPERT -Systems im Zuge der Einführung von SAP S/4HANA zu migrieren.
MM: Wie ist das Projekt in etwa abgelaufen?
Ackermann: Erste Aufgabe war die Implementierung des Projektteams, zu dem neben uns und der Mitarbeiter des Kunden auch der für die eigentliche SAP-Anwendungsimplementierung zuständige Service-Provider gehörte. Es wurde eine SAP-Testumgebung eingerichtet, auf welche jeder Beteiligte Zugang hatte, die universelle Datenaustauschplattform zwischen den Anwendungen und Systemen waren in diesem Falle Excel und CSV, es sind aber auch andere Methoden möglich. Als Basis der Datenkonvertierung wurden von Seiten des Kunden, bzw. dessen SAP-Partner, die geforderten SAP-Datenstrukturen, Formate und Feldinhalte etc. in Form von Excel Dateien vorgegeben, welche von DAC auf der IBM i Series – als Plattform der Infor Anwendungen – aus den zu migrierenden XPERT-Datenbeständen zu generieren waren. Dazu waren von DAC entsprechende Konvertierungsprogramme zu erstellen bzw. konnten wir auf einen hilfreichen Fundus von bereits existierenden Mapping-Tools aus ähnlichen Projekten zurückgreifen.
MM: Wo traten besondere Herausforderungen auf?
Ackermann: Neben einem relativ einfachen 1:1-Mapping von Daten waren wesentlich komplexere Mapping-Prozesse zu realisieren wie etwa die Zusammenführung von in der XPERT-Datenstruktur getrennten Daten zu einem logischen Datenelement in SAP, oder die Bereinigung redundanter Datenbestände in XPERT vor der Migration nach SAP. Eine besondere Herausforderung waren unterschiedliche Organisationformen in den SAP- und XPERT-Anwendungen, z.B. in der Material-Klassifizierung.
MM: Wo lag da genau das Problem?
Ackermann: Das bei dem Kunden zu implementierende SAP erwartete zwingend Material-Klassifizierungen, welche in XPERT nicht oder in anderer Form vorhanden sind. Dazu mussten diese SAP-Klassifizierungen korrekt definiert und uns zur Verfügung gestellt werden. Bei der Vielzahl von Materialien war das ein erheblicher Aufwand.
MM: Was passierte dann mit den migrierten Daten?
Ackermann: Sie wurden – wiederum via E-Mail/Excel/CSV Kommunikation – den zuständigen Fachbereichen beim Kunden zur Kontrolle zur Verfügung gestellt. Nach notwendigen Korrekturen erfolgte dann der Upload nach SAP, wobei SAP vor der endgültigen Akzeptanz der Daten interne Konsistenzprüfungen vornimmt, welche durchaus wieder zu Korrekturen führen können. Dieser Ablauf ist bis zur endgültigen und fehlerfreien Migration in der Regel ein erheblich komplexer und zeitaufwändiger revolvierender Prozess.
MM: Wie würden Sie die Vorgehensweise für ein solches Migrationsprojekt ganz allgemein formulieren?
Ackermann: Erste Aufgabe des Projektteams muss es sein, die personellen Ressourcen – insbesondere auch der Fachbereiche – zu benennen und gemeinsam mit der Geschäftsleitung auf das Projekt einzuschwören. Eine wesentliche Voraussetzung ist es dabei, dass die Mitarbeiter*innen bereits über ausreichende Kenntnisse des geplanten Zielsystems verfügen, um die Ergebnisse der Datenmigration im Kontext mit den Anwendungen und Prozessen qualifiziert bewerten und korrigieren zu können. Also frühzeitig die entsprechende Ausbildung starten. Nicht zu unterschätzen ist dabei die Mehrbelastung der beteiligten Kundenmitarbeiter*innen über das Tagesgeschäft hinaus.
MM: Was wäre dann der darauf folgende Schritt im Projektverlauf?
Ackermann: Die Festlegung der von allen zu nutzenden IT Systeme, Methoden und Tools ist ein weiterer wesentlicher Projektschritt in der Vorbereitungsphase. Es ist dabei sicher zu stellen, dass diese für alle Beteiligten verfügbar und zugänglich sind. Das betrifft insbesondere die Testsysteme sowie die Systeme und Methoden für Daten- und Informationsaustausch sowie die Korrekturverfahren. Tools, welche wir entwickelt haben und nutzen sind z.B. : Frei konfigurierbare Mapping-Tabellen, Datenkonverter von und nach csv, xml, text-Dateien, ein Import-Portal für den Datenimport aus externen Systemen, eine SQL Toolbox für Datenanreicherung, Massenänderungen, Datengenerierung etc.
MM: Das heißt, vor der eigentlichen Migration sind eine Menge Vorbereitungen und Entscheidungen im Sinne eines Blueprint zu treffen.
Ackermann: Das ist richtig. Ansonsten tauchen die Probleme mit unangenehmen Folgen in der Projektphase auf. Dieser Blueprint muss natürlich auch von der Geschäftsleitung des Kunden abgesegnet sein.
MM: Wie läuft nun nach allen Vorbereitungen das eigentliche Projekt-doing ab?
Ackermann: Das ist im Wesentlichen eine Fleißarbeit und orientiert sich an der geplanten Vorgehensweise und den genutzten Methoden und Tools. Stichworte und Milestones dazu sind Einzeltests, Massen- und Integrationstests in das Zielsystem, wobei die Fachbereiche der Anwendungen gefordert sind. Was in Einzeltests wunderbar funktioniert kann allerdings bei Tests mit Massendaten völlig anders ausgehen. Unerlässlich in der Projektarbeit sind auch regelmäßige Meetings. Wenn möglich via Tools – etwa MS Teams – , aber notwendiger Weise auch „face to face“ zur Klärung komplexer Sachverhalte im Hause des Kunden.
MM: Wie passt in diesen Kontext Ihr Serviceangebot?
Ackermann: Natürlich betreuen wir den Kunden bei Bedarf auch über die vollzogene Datenmigration hinaus. Es hat sich gezeigt, dass trotz aller Sorgfalt und Tests in der `Stabilisierungsphase´ Konstellationen auftreten können, welche eine Nacharbeit notwendig machen. Generell sollte man ein Datenmigrationsprojekt nicht unterschätzen und es bedarf einer großen Aufmerksamkeit, sorgfältigen Planung und erfahrener Akteure in Sachen Realisierung.
MM: Welche Rolle spielen eigentlich Ihre primär in Verbindung mit XPERT genutzten Anwendungen für Digitalisierung und Automatisierung der Purchase to Pay und der damit verbundenen kreditorischen Prozesse? Werden diese nicht mit der Einführung anderer ERP-Systeme obsolet?
Ackermann: Nein, ganz im Gegenteil. Diese Anwendungen sind natürlich weiterhin ein zentraler Bestandteil unseres Angebotes. Durch die Implementierung als universelle Lösung können diese auch bei einem Wechsel der ERP-Systeme ohne wesentliche Änderungen genutzt werden. Die an diese Anwendungen gewöhnten Anwender*innen werden das zu schätzen wissen. Anzupassen sind die Daten-Interfaces zu den Finanzsystemen sowie die Interfaces zu Bestellungen und Wareneingängen oder anderen Leistungserbringungen mit dem Ziel der Ermittlung und Darstellung von Mengen- und Preisabweichungen. Da diese Browser-basierten Anwendungen von den unterschiedlichen ERP- Systemen vollkommen unabhängige Lösungen für die vollständigen Purchase to Pay und kreditorischen Prozesse zur Verfügung stellen, bieten diese sich auch insbesondere als einheitlicher und übergelagerter Standard in einer Multi-ERP-Umgebung an.
MM: Wie darf ich das verstehen?
Ackermann: Die ERP `Umstellung´ in einem größeren, zumeist auch international operierenden Unternehmen, zieht sich in der Regel über einen längeren Zeitraum hin, was unweigerlich eine Multi ERP Umgebung mit sich bringt, da nicht alle Unternehmensteile zu einem Zeitpunkt gleichzeitig mit dem neuen ERP-System arbeiten werden. Das heißt, die bisherigen Intercompany-Prozesse auf Basis des abzulösenden ERP-Systems funktionieren nicht mehr.
MM: Was verstehen Sie unter diesen Intercompany-Prozessen?
Ackermann: Ganz allgemein das Setzen und Verfolgen von „Unified“ Standards, Regeln und Policies im Sinne von Unternehmens-Compliance und Organisation über die unterschiedlichsten Unternehmensteile, ERP-Systeme, Prozesse und Anwendungen hinweg. Die Anwender arbeiten praktisch in einer eigenen, von den unterschiedlichen ERP Systemen losgelösten Umgebung. Beispiele dafür sind insbesondere der Cross-Company Belegeingang, die Cross-Company Rechnungsbearbeitung, Cross-Mandanten Buchungen, Cross Company Reklamationsbearbeitung – in der Automotive Industrie auch als Claims Handling bekannt -, Intercompany Billing und Debiting und andere Prozesse. Dafür bieten unsere Lösungen die Grundlagen. Wie wollen Sie solche „unified“ Prozesse in einem diversifizierten Unternehmen mit den unterschiedlichsten ERP-Systemen sonst umsetzen?
Rainer Huttenloher
