Ob AS/400 Eigenentwicklungen oder proprietäre MS SQL-Server Lösungen mit .NET Active Server Pages; ob Urgesteine der Unternehmens-IT wie Infor Baan oder zu klein gewordene Lexoffice Lösungen: Die Bandbreite der Ausgangssysteme ist groß, ihr technischer Stand oft veraltet. Keine modernen Schnittstellen, keine einfachen Erweiterungsmöglichkeiten, keine selbstsprechende Datenbankabstrahierung. Wie migriert man angesichts dieser Ausgangslage seine Niederlassungen, Schwesterwerke, Unternehmenszukäufe in ein oder mehrere moderne Cloud-ERP-Systeme – und das risikoarm ohne Betriebsunterbrechung? Sehen wir uns einen konkreten Fall an.

Wir wollen stellvertretend für ein Legacy-ERP-System Infor Baan heranziehen. Baan bietet das in die Jahre gekommene und aufwendig zu nutzende EDIfact-Format für den Datenaustausch an. Statt Baan könnte auch jedes andere Alt-ERP-System stehen, dessen Lebenszeit sich dem Ende zuneigt. 

Shutterstock

Ob AS/400 Eigenentwicklungen oder proprietäre MS SQL-Server Lösungen mit .NET Active Server Pages; ob Urgesteine der Unternehmens-IT wie Infor Baan oder zu klein gewordene Lexoffice Lösungen: Die Bandbreite der Ausgangssysteme ist groß, ihr technischer Stand oft veraltet. Keine modernen Schnittstellen, keine einfachen Erweiterungsmöglichkeiten, keine selbstsprechende Datenbankabstrahierung. Wie migriert man angesichts dieser Ausgangslage seine Niederlassungen, Schwesterwerke, Unternehmenszukäufe in ein oder mehrere moderne Cloud-ERP-Systeme – und das risikoarm ohne Betriebsunterbrechung? Sehen wir uns einen konkreten Fall an.

Wir wollen stellvertretend für ein Legacy-ERP-System Infor Baan heranziehen. Baan bietet das in die Jahre gekommene und aufwendig zu nutzende EDIfact-Format für den Datenaustausch an. Statt Baan könnte auch jedes andere Alt-ERP-System stehen, dessen Lebenszeit sich dem Ende zuneigt. 

Baan Distribution Website

 Ziel- bzw. Neusystem soll MS Dynamics365 F&O sei, welches im Kern offenbar auf MS Dynamics AX (Axapta) zurückgeht.

Zuerst sollte entschieden werden, ob die Umstellung von Baan auf MS Dynamics365 F&O überall auf einen Schlag (Big Bang) oder in mehreren Schritten (inkrementell) erfolgen soll. Diese Entscheidung legt fest, ob eine einmalige (automatisierte) Datenmigration stattfinden soll oder ob zwischen MS Dynamics und Baan ein permanenter Datenaustausch etabliert werden muss.

EDIfact in MS Dynamics365 F&O (Example)

Im ersten Fall wird eine Automatisierung von Baan (Altsystem) nach MS Dynamcis (Neusystem) implementiert, sodass alle Aufträge (ORDERS) samt Stammdaten usw. einmalig in das neue System fließen. Das Altsystem kann anschließend stillgelegt werden. Die Automatisierung kann schlicht gehalten werden.

Im zweiten Fall wird eine bilaterale Automatisierung umgesetzt, sodass Aufträge sowohl von Baan nach MS Dynamics als auch von MS Dynamics nach Baan übertragen werden können. Die Automatisierung muss zahlreiche Ausnahmefälle (Exceptions) bewältigen, skalieren und stabil sein. Zudem muss sie ein Logging sowie Monitoring bieten, um für den Fehlerfall gerüstet zu sein.

In der Regel entscheiden sich Unternehmen für den zweiten Ansatz, um Niederlassungen oder Werke nach einander in die Neuwelt zu migrieren. Die Umstellungsrisiken sind dabei geringer; zudem kann der Umstellungsablauf stetig verbessert werden, sodass spätere Umstellungskandidaten von diesen Optimierungen profitieren (Lessons Learned).

Microsoft Dynamics365 F&O – Purchase Order

In beiden Fälle werden wir jedoch mit inkompatiblen Datenformaten konfrontiert. Baan kann nur über EDIfact mit der Außenwelt kommunizieren, während MS Dynamics365 F&O sehr gut auf RESTful Services oder SOAP Services zu sprechen ist. Hier gilt es, “sprachlich zu vermitteln”.

Sobald z.B. eine Bestellung (Purchase Order) in MS Dynamics angelegt und genehmigt wird, steht diese über API für Drittsysteme zur Verfügung. Wir greifen folglich die Purchase Order über die MS Dynamics365 OData Schnittstelle ab und konvertieren diese in das EDIfact D95B ORDERS Format. D95B steht für die exakte Version des ORDERS Dokument Typs – hier also der im Jahr 1995 verabschiedete Standard in der Variante B. Dies kann aber jede beliebige Version dieses Dokumenten Typs sein; sie ähneln sich stark.

Bei der näheren Betrachtung der ausgehenden Bestellungen (Purchase Orders) sehen wir, dass diese aus zahlreichen Feldern mit Detailinformationen zu den bestellten Leistungen bzw. Produkten bestehen. So finden sich die Lieferinformationen neben den Abrechnungsinformationen, Fristen für die Bezahlung neben steuerlichen Angaben und natürlich die bestellten Positionen. All das muss korrekt in das Zieldokument ORDERS übertragen werden.

Microsoft Dynamics365 F&O – API

In der Felderstruktur des EDIfact Formats ORDERS finden sich zwar im Großen und Ganzen dieselben Felder wie in der JSON-formatierten Ausgangsdatei von MS Dynamics, jedoch in einer anderen Struktur. Entscheidend ist folglich das korrekte Mapping der Ausgangsfelder zu den Zielfeldern. Nur dann kann Baan die Bestelldetails inhaltlich richtig aus der MS Dynamics Quelle übernehmen. Oftmals wird nur ein Subset der Informationen benötigt oder die Information muss in einer anderen Reihenfolge dargestellt werden, was einerseits das Mapping vereinfacht, andererseits eine Fehlerquelle darstellt, wenn man die Bedeutung der Felder nicht genau kennt.

Eine sofort evidente Herausforderung beim Mapping ist das Fehlen der Verschachtelungsmöglichkeit (nesting) in EDIfact, was in JSON problemlos möglich ist. Folglich muss bei der Konvertierung eine Logik eingeführt werden, welche diese Verschachtelung einerseits aufnimmt, sie dann aber wieder “flachklopft”.

Des Weiteren muss festgelegt werden, wie bereits übertragene Bestellungen in MS Dynamics so markiert werden, dass sie nicht erneut in Baan angelegt werden – und folglich keine unnötigen Korrekturen sowie Mehrkosten erzeugen.

All dies mag mühsam klingen – muss es aber nicht sein. Gefragt sind Kompetenz in den vielfältigen Datenformaten, Kreativität bei der Beseitigung von vermeintlichen Inkompatibilitäten der Systeme sowie die kluge Auswahl der Hilfsmittel. Auch wenn die Zukunft der Technologien “modern” und “rosarot” sein mag, müssen wir im Hier und Jetzt uns auf den Weg dorthin machen. Alles einzureissen und neu aufzubauen wird aufgrund der hohen Risiken für die “Business Continuity” und die Kosten selten eine tragfähig Mehrheit finden, sodass moderne Technologien gepaart mit Methodenkompetenz den Weg zum Erfolg weisen.

Da die Unternehmen der Zukunft voraussichtlich auf modular kombinierbare Systeme setzen (Composable Enterprise), d.h. Saleforce, Oracle, Microsoft, IBM, Servicenow, Hubspot, Freshdesk, DATEV, SAP usw. in verschiedensten funktionalen Kombinationen gleichzeitig verwenden, ist eine umsichtige und effektive Integrationsstrategie unerlässlich.

Gartner

Damit dies nicht bei Powerpoint-Konzepten bleibt und in verzweifelte Nachtschichten in Fernost mündet, führt der Weg zum Erfolg über gute IT-Beratung und Implementierung. Genau dort setzen wir an: Business Automatica GmbH erfasst mit Ihnen die funktionalen sowie technischen Anforderungen, entwickelt die konkret passende Systemarchitektur und implementiert in kürzester Zeit die Lösung mit modernsten Tools führender sowie innovativer Hersteller, bis Sie und wir zufrieden sind.

Business Automatica senkt Prozesskosten durch Automatisierung manueller Tätigkeiten, hebt die Qualität beim Datenaustausch in komplexen Systemarchitekturen und verbindet On-premise Systeme mit modernen Cloud- und SaaS-Architekturen.