EDI EDI-Kommunikation EDI-Konvertierung

EDI-Migration – alle Jahre wieder

Kurzfassung - EDI ist die modernste, schnellste und effizienteste Art des standardisierten Austausches geschäftlicher Informationen. Zwar laufen EDI-Lösungen – sind sie erst einmal installiert – in der Regel über lange Zeit unauffällig im Hintergrund. Doch auch sie können veralten. Dann ist eine Migration fällig, d. h. Modernisierung der bestehenden EDI-Software oder gleich ihre Ablösung durch ein modernes System. In der Regel steht ein solcher Wechsel alle 5-10 Jahre ins Haus. Die Ursachen dafür sind vielfältig.

Mittwoch, 22. April 2020
EDI Migration alle Jahre wieder

Zum einen die Kosten. Einige Lösungen beinhalten mitunter Volumenabhängigkeiten. Oft sind die in (alten) Verträgen vereinbarten Gebühren auch einfach nicht mehr zeitgemäß, denn der Preisverfall schreitet auch im EDI-Sektor voran. Vielfach sind zudem Erweiterungen bzw. Upgrades schlicht zu teuer. Wichtiger noch als die Kosten ist die Funktionalität. Natürlich entwickeln auch die EDI-Hersteller ihre Systeme weiter, fügen neue Funktionen hinzu, erweitern die Kompatibilitäten zu angeschlossenen Systemen und berücksichtigen neue technische Möglichkeiten (z. B. Wechsel von ISDN auf IP-basierende Lösungen oder OFTP2) oder Änderungen gesetzlicher Natur (Signaturgesetz oder XRechnung). Manch einer bietet hier mit der Zeit einfach mehr als der andere.

Konsolidierung mit der EDI-Plattform

Diverse toolartige Lösungen, Eigenprogrammierungen… – der zweite Hauptsatz der Thermodynamik trifft auch für die IT-Strukturen eines Unternehmens zu: In jedem geschlossenen System nimmt die Unordnung (Entropie) mit der Zeit zu. Hier ist Konsolidierung vonnöten, wie sie eine EDI-Plattform wie i‑effect® ermöglicht. Und schließlich wäre da noch der EDI-Dienstleister selbst, mit dem man nach einiger Zeit vielleicht nicht mehr zufrieden ist: Unzureichender Support, lange Reaktionszeiten und oft wechselnde Ansprechpartner können gute Gründe für eine Migration sein.

Bevor dann die Suche nach einem neuen Anbieter startet, sollte man eine Grundlagenermittlung vornehmen. Hierbei sind zentrale Fragen zu beantworten:

  • Welche EDI-Prozesse gibt es?
  • Welche Nachrichten werden übermittelt bzw. empfangen?
  • Welche Kommunikationswege werden dafür genutzt?
  • Welche Kosten laufen aktuell auf, wie sieht das Budget aus?
  • Und: Was genau stört an der aktuellen Lösung?

Sich einen Überblick über bestehende Prozesse zu verschaffen, funktioniert natürlich nur, wenn die aktuelle Lösung transparent und gut dokumentiert ist. Gibt es Fachleute im Unternehmen, die die Software bedienen und mit Sicherheit sagen können, welche Prozesse zu welchen Aktionen führen? Ist dies nicht der Fall, kann im Einzelfall allein die Grundlagenermittlung aufwändig und nervenzehrend sein – gerade bei gewachsenen Strukturen, die – siehe oben – quasi immer unübersichtlich sind. Hier kann dann aber ein EDI-Berater wie menten GmbH unabhängig von der Folgelösung weiterhelfen.

Grundlagenermittlung vor Wahl des neuen EDI-Systems bzw. -Anbieters

Ist der neue Anbieter gewählt, geht es an die konkrete Migration. Die menten GmbH nimmt in solchen Projekten zunächst die Anforderungen auf Seiten der Quelle sowie des Ziels auf. Wo befinden sich die Daten beim Versender, gibt es bereits Schnittstellen, über welche Kommunikationsmöglichkeiten verfügt er? Analog beim Empfänger: Welches Datenformat benötigt dieser, gibt es eine Richtlinie und/oder Beispieldaten, welche Kommunikationsparameter werden angegeben? Ein (typisches) Ergebnis wäre dann etwa: DB2-Daten sollen in das Edifact-Standardformat konvertiert und über das AS2- Kommunikationsprotokoll versendet werden.

In der darauffolgenden Implementierungsphase wird die Datenkonvertierung (EDIFACT) vorgenommen und der Kommunikationsweg wird definiert (AS2). Etwaige Workflows für die Automatisierung werden aufgesetzt sowie das anschließende Monitoring des EDI-Prozesses eingerichtet. Zur Migration gehören auch die Wahl und Einrichtung des definierten Kommunikationsweges inklusive Installieren der entsprechenden Server und -Clients. Neben dem inzwischen flächendeckend verbreiteten AS2-Protokoll stehen natürlich auch OFTP, FTP, HTTP, E-Mail und SOA als Alternativen zur Verfügung.

Kein Big Bang bei der Migration

Ein Big Bang bei der Migration (alles auf einmal) ist übrigens nicht zu empfehlen. Besser man schaltet fallweise um, z. B. nach Nachrichtentyp, Tradingpartner, Art der Nachricht (nur eingehend/nur ausgehend), nur bestimmte Kommunikationswege usw. Ist die Migration abgeschlossen, müssen die Ergebnisse dann zunächst einmal beobachtet werden. Gegebenenfalls muss nachgearbeitet werden, auch mit Unterstützung des neuen Anbieters, evtl. sind vertiefende Schulungen nötig. Dann läuft das System und läuft und läuft. Bis in zehn Jahren!

Zurück zur Übersicht