EDI

EDI
Während EAI die Kommunikation der IT-Systeme innerhalb eines Unternehmens behandelt, betrifft EDI den Datenaustausch zwischen mehreren Unternehmen. Auch hier „sprechen“ die IT-Systeme direkt miteinander, der Mensch sollte nur Kontrollfunktion haben.

Wenn schon innerhalb einer Firma oftmals Software unterschiedlicher Hersteller im Einsatz ist, so wird die Welt noch wesentlich bunter, wenn verschiedene Unternehmen miteinander zu tun haben. Nicht nur gibt es verschiedene Standard-Softwaresysteme, oft geistern komplette Eigenentwicklungen durch die Prozessoren, die geschrieben wurden, als die IT noch in den Kinderschuhen steckte. Sie wissen ja: Nichts hält länger als ein Provisorium.

Wie bringt man nun die Software verschiedener Unternehmen, die bunter zusammengewürfelt ist als jedes Osternest, zur Zusammenarbeit? Jedes Programm hat sein eigenes Datenformat. Als „Kommunikationsschnittstelle“ kann man oft bestenfalls die Textdateien bezeichnen, die ausgeworfen und eingelesen werden können. Das artet in babylonische Sprachenverwirrung aus.

Dafür gibt es zum einen gewisse Datenformate, die von großen Organisationen (bis hin zu UNO-Abteilungen) als Standards entwickelt wurden, zum anderen Software, die in der Lage ist, Daten von einem ins andere Format umzusetzen. Man könnte hier von Dolmetschern sprechen, die zwischen all den vielen Sprachen und Dialekten übersetzen können. Und wie bei den Dolmetschern der UNO wird meist nicht direkt von Afrikaans in Thai übersetzt, sondern in eine der Standard-Sprachen (bspw. Englisch oder Französisch) und von der in die Zielsprache. In der Welt des EDI heißen die Standards EDIFACT, Fortras oder BMEcat. Die Äquivalente zu den regionalen Sprachen sind meist CSV-Dateien oder Texte im „Feste Länge“- Format (alias FixRecord), die gerne unter dem Begriff „inhouse“ laufen. Also das Format, das im eigenen Hause genutzt wird und sonst womöglich nirgends auf der Welt.

Haben beide an der Kommunikation beteiligten Unternehmen solche „Dolmetscher“-Software im Hause, können sie Daten vom eigenen Format in eines der Standard-Formate umsetzen und auf beliebigem – elektronischem – Wege an den Partner schicken. Der setzt den Standard wiederum in sein Format um und füttert damit seine Systeme. Die Kommunikation ist somit der Dritte im Bunde, der EDI erst komplett macht.

Beispiel 1 - Kurze Frage:

Im komplexeren Beispiel zu EAI mussten wir einen Lieferanten fragen, wie lange es denn dauert, bis er uns einen bestimmten Artikel liefern kann, da wir den in einer Kundenbestellung gefunden haben und unser Lager leider keinen mehr vorrätig hat. Für so etwas ist die EDI-Software zuständig (wobei wir schon festgestellt haben, dass es ziemlich unpraktisch ist, EAI und EDI so strikt zu trennen. Ist doch nur eine kurze Frage nach draußen, mitten im EAI-Prozess.).

Die EDI-Software bekommt also, z.B. als SOAP-Anfrage (hier über einen WebService), den Auftrag, beim Lieferanten „Hardwarequelle“ nachzufragen, wie schnell er uns zwei Artikel mit der Artikelnummer „A08/15“ liefern kann. Die Artikelnummer ist bereits die, die der Lieferant benutzt, in unserem System hat derselbe Artikel die Nummer „4711“. Für solche kurzen Anfragen ist ein WebService die optimale Lösung. WebServices werden via HTTP angesprochen, in einer festgelegten Art und Weise. Das Wichtigste daran ist: Man schickt dem WebService die Anfrage als XML-Datei, und er antwortet auch in diesem Format. Um die reine Anfrage bzw. die Antwort wird noch ein sogenannter SOAP-Envelope gepackt, der ein paar Zusatzinfos enthält, das war’s auch schon. Die Antwort kommt auf jeden Fall sehr schnell, und darauf kommt es hier ja an.

Hier das Beispiel, wie unsere EDI-Software vom EAI-System die Anfrage bekommt:
<?xml version=“1.0“ encoding=“UTF-8“?>
<soapenv:Envelope
xmlns:soapenv=“http://www.w3.org/2003/05/soap-envelope“
xmlns:xsd=“http://www.w3.org/2001/XMLSchema“
xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance“>
<soapenv:Header />
<soapenv:Body>
<AnfrageLieferzeit>
<Lieferant>Hardwarequelle</Lieferant>
<ArtNr>A08/15</ArtNr>
</AnfrageLieferzeit>
</soapenv:Body>
</soapenv:Envelope>

Das EDI-System muss jetzt in Erfahrung bringen, wie es denn die Firma „Hardwarequelle“ kontaktieren kann. Diese Informationen können aus einer Datenbank kommen, aus einem SAP-System (ja, das wären eigentlich schon wieder EAI-Themen) oder auch in irgendeiner Weise direkt im EDI-System hinterlegt sein. Egal wie, es kommt raus, dass wir den Lieferanten auch wieder über WebService ansprechen können.

Wie gesagt, für solche Anfragen ist das optimal, da es einfach schnell geht.
Sparen wir uns ein anderes XML-Beispiel, sagen wir einfach, der Lieferant sichert uns Lieferung in drei Tagen zu. Genauer gesagt, seine IT-Systeme sichern uns das zu. Denn eine Antwort innerhalb einer HTTP-Verbindung stammt sicher nicht von einem Sachbearbeiter, sondern wird vollautomatisch in dessen IT-Landschaft generiert. Auch auf seiner Seite sind da EDI- und EAI-Prozesse beteiligt. Diese drei Tage meldet unser EDI-System nun an unsere EAI-Software, damit diese die Bestellung weiter bearbeiten kann.

Beispiel 2 - Kundenbestellung

Beispiel 2 – Kundenbestellung
So eine Kundenbestellung, wie wir sie im EAI-Beispiel angesprochen haben, sollte heute nicht mehr wirklich von einem Sachbearbeiter eingegeben werden. Das ist – nun ja – etwas mittelalterlich. Bestellungen sollten heute elektronisch eintreffen, z.B. als Mail oder über das Bestellformular einer Website. Oder, wenn wir im B2B-Bereich bleiben, per EDIfact-Datei direkt aus dem EDI-System unserer Kunden.

Da trudelt nun also eine Mail ein, an der eine Bestellung im EDIfact-Format hängt. Die Nachrichtenart heißt – raten Sie! – ORDERS. Wie so etwas aussehen kann, ist im Artikel zu EDIfact genauer beschrieben.

Die EDI-Software nimmt sich die Mail vor und holt den Anhang mit der Bestellung heraus. Anhand des Dateinamens oder vielleicht des Betreffs erkennt sie, um was es geht. Zur Not muss sie in den Inhalt schauen, falls die anderen Merkmale nicht ausreichen. Dann liest sie die Daten ein und speist sie ins Auftragserfassungssystem (kurz AES). Ab hier übernimmt unsere EAI-Software, da wir hier bei den Begriffserklärungen ja strikt zwischen beiden trennen. Diese ist irgendwann mit der Bearbeitung fertig, der Auftrag mit allen Lieferzeiten, voraussichtlichem Liefertermin für den Kunden, evtl. Sonderkonditionen usw. steht im AES, und es kann nun eine Auftragsbestätigung mit allem Drum und Dran an den Besteller rausgehen. Da übernimmt dann wieder EDI.

Eine Möglichkeit wäre, dass die EAI-Software aus dem AES alle Daten für die Auftragsbestätigung zieht und als kleine CSV-Datei in ein Verzeichnis legt, aus dem das EDI-System sie wieder ausliest und in ein EDIfact-Dokument einbaut. Der entsprechende Nachrichtentyp heißt in diesem Fall ORDRSP (Die Namen aller Nachrichtentypen haben sechs Buchstaben, dieser Name hier steht für Order Response.).
Ist das ORDRSP erst mal erstellt, bekommt der Kunde eine Mail von uns, die als Anhang diese EDIfact-Nachricht enthält und wahrscheinlich sofort wieder von seinem EDI-System verarbeitet wird. Es lebe die moderne Technik!

Sehen wir uns kurz mal den B2C-Bereich an, also die Kommunikation und den Handel zwischen Unternehmen und Endkunden, wie z.B. Privatleuten.

In diesem Fall gingen sicher keine EDIfact-Dateien hin und her. Wahrscheinlicher ist, dass der Kunde über ein Webformular seine Bestellung macht, z.B. in einem Webshop mit Warenkorb und allem Schnickschnack. Auch er wird zwar eine Auftragsbestätigung erhalten, diese dürfte dann aber eher folgende Form haben:

Sehr geehrte Frau Musterfrau,

wir bedanken uns sehr für Ihren Auftrag und bestätigen hiermit ihre Bestellung.

Artikelnummer Bezeichnung Menge Einzelpreis Gesamtpreis
4711 Nette Überraschung 2 € 9.99 € 19.98

Gesamtsumme: € 19.98
enth. MwSt: € 2.76
Voraussichtlicher Liefertermin: 30.02.2099

Mit freundlichen Grüßen,
Ihr Kramerladen-Team

Die Kommunikation nach außen läuft ganz anders, im Eingang haben wir womöglich eine CSV-Datei, die uns ein PHP-Script des Webshops per FTP liefert, und die Antwortmail enthält keinen EDIfact-Anhang, sondern einen Fließtext. Der Prozess dazwischen allerdings ist derselbe. Deshalb ist es nur sinnvoll, wenn die verschiedenen Aspekte eines solchen Vorgangs möglichst modular aufgebaut sind:

  • Kommunikation über verschiedene Kanäle
  • Einlesen der Daten aus unterschiedlichen Formaten
  • Verarbeitung im Zusammenspiel mit internen Systemen
  • Ausgabe der Antwortdaten in diverse Formate
  • Kommunikation der Ergebnisse nach draußen auf verschiedenen Wegen

Hier der ganze Ablauf noch mal schematisch dargestellt:

EDI-Schema

Einerseits ist eine Trennung der Abläufe des EDI- und des EAI-Bereichs so gesehen ganz sinnvoll, da es das EAI-System nicht im Mindesten interessiert, wie die Aufträge ins AES kamen und wie die Bestätigungen rausgehen, andererseits hat man oft die selben technischen Vorgänge auf beiden Seiten, wie hier zum Beispiel die Kommunikation mit dem AES oder auch mit Datenbanken. Zu allem Überfluss schicken wir eine WebService-Anfrage vom EAI- zum EDI-System, das diese wiederum nach außen zu unserem Lieferanten weiterleitet, nur, um alles zwanghaft getrennt zu halten. Besser ist es da doch, ein System zu haben, das alles kann, und die Modularität eher innerhalb der Abläufe dieses Systems aufzubauen.

Zusammenfassung

EDI steht für alle Vorgänge der automatisierten Kommunikation zwischen den eigenen IT-Systemen und der Außenwelt. Dazu gehört nicht nur die reine Übertragung der Daten (Mail, FTP, WebService, AS2, …), sondern auch die Umsetzung zwischen verschiedenen Datenformaten (oft über Standardformate als Zwischenschritt), die Anreicherung mit zusätzlichen Informationen, der Datenabgleich und das Einpflegen in bzw. Auslesen aus den internen Systemen. Der Mensch sollte hier nur noch eine überwachende Funktion haben, um bei Fehlern (z.B. durch unsaubere Daten oder Netzprobleme) eingreifen und nach den entsprechenden Korrekturen die Nachbearbeitung anstoßen zu können. EDI- wie EAI-Systeme sollten daher ein übersichtliches Monitoring bieten sowie umfassende Möglichkeiten, auf Fehler schnell und effizient zu reagieren.

Varianten im Betrieb
Während EAI oder ETL praktisch nur als Installation im eigenen Hause sinnvoll sind, ist das bei EDI längst nicht so klar. Immerhin wird hier sehr viel mit der Außenwelt kommuniziert. Und im Gegensatz zu EAI müssen bei EDI auch nicht zwingend eigene Systeme direkt zugreifbar sein. Es reicht reicht oft, wenn Dateien ex- und importiert werden können (Datenmanagement). Daher haben wir hier eine ganze Bandbreite von Möglichkeiten, wie EDI realisiert werden kann:

Inhouse

Hier gibt es wiederum zwei Möglichkeiten, wie die Realisierung von statten gehen kann. Unterschieden wird zwischen Inhouse in Eigenregie und Inhouse mit Dienstleistung.

SaaS – Software as a Service

SaaS wird neumodisch auch Cloud Computing genannt. Hier wird die Installation selbst aus-
gelagert. Ein Anbieter stellt also Hardware und Infrastruktur zur Verfügung und kümmert sich um die Pflege, wie z.B. das Einspielen von Updates. Alles bedienen und die Prozesse aufsetzen können Sie selbst über das Internet.

EDIaaS

Nicht nur der Betrieb des Systems und die Administration, sondern im Prinzip die gesamte Arbeit wird ausgelagert. Ein Dienstleister betreibt die SW in seinem Rechenzentrum, bindet Ihre Geschäftspartner an und setzt Konvertierungen und weitere Prozesse auf. Sie schicken ihm nur noch Daten für Ihre Partner ins System und bekommen von ihm deren Daten zugesandt.

Freies Internet oder VAN?

Zu EDI gehört auch die Kommunikation – hier haben wir zwei Varianten. Sie können Daten über das ganz normale Internet schicken oder über ein sogenanntes VAN, ein Value Added Network, das neben der reinen Datenübertragung noch ein paar zusätzliche Leistungsmerkmale hat, wie zum Beispiel sichere Übertragungen.

Inhouse
Das schöne Wörtchen inhouse sagt einfach nur, dass das EDI-System bei Ihnen im Hause, in Ihrem Netzwerk, auf von Ihnen bereitgestellter Hardware (real oder virtuell) läuft.  Das alleine hat schon seine Vor- und Nachteile:

Vorteile & Nachteile

Vorteile:

  • Alle Ihre Systeme, z.B. Datenbanken, SAP oder was auch immer, sind direkt im Zugriff und das EDI-System kann seine volle Leistung ausspielen.
  • Wenn das Programm dazu fähig ist, kann es auch gleich die EAI-Aufgaben mit erledigen, denn dafür ist der vorgenannte Punkt natürlich unverzichtbar.
  • Sie haben alles komplett unter Ihrer Kontrolle, es verlassen nur die Daten Ihr Netz, die auch für die Außenwelt bestimmt sind.
  • Sie haben einmalig in den Kauf des Systems zu investieren und dann meist eine überschaubare, aber immer gleichbleibende Supportgebühr zu entrichten. Das ändert sich nicht mehr, auch wenn Ihr Datenvolumen massiv steigt.

Nachteile:

  • Sie müssen Hardware und Infrastruktur bereitstellen und haben natürlich auch einen gewissen Administrationsaufwand. Letzteres hängt allerdings davon ab, welche Dienstleistung Sie sich evtl. noch dazukaufen.
  • Die erste Investition ist ein etwas größerer Batzen.

Wo die Software installiert ist, ist aber nur die eine Seite der Medaille. Die andere ist, wer dann mit dem System arbeitet und Ihre Prozesse umsetzt. Daher kann man grob zwei Varianten unterscheiden, wobei die Übergänge natürlich fließend sind.

1. Inhouse in Eigenregie

Hier haben Sie alles in der Hand. Die Installation macht wahrscheinlich noch der Hersteller oder ein Dienstleister, aber die tägliche Arbeit erledigen Ihre Mitarbeiter. Das heißt, Ihre IT-Truppe (in etwas größeren Unternehmen gibt es meist auch ein eigenes EDI-Team) konfiguriert die Kommunikation mit den Partnern, baut sämtliche Arbeitsprozesse, Konvertierungen, Workflows usw. auf und bindet natürlich auch die internen Systeme an. Der Support des Herstellers sollte hier natürlich Gewehr bei Fuß stehen, aber primär ist das Ihr Job.

Das klingt erst mal nach viel Arbeit (ist es auch), zahlt sich aber andererseits aus. Denn was Sie selbst machen, kennen und verstehen Sie hinterher auch. Wenn dann irgendwelche Änderungen zu machen sind, können Sie diese schnell umsetzen, anstatt erst einem Dienstleister umständlich zu erklären, was Sie brauchen, und dann zu warten, bis er Zeit dafür hat.

Änderungen in Verfahren (zum Beispiel der Umstieg auf eine neuere Version einer EDIFACT-Nachricht) haben ja eine gewisse Vorlaufzeit, da ist das vielleicht nicht so schlimm. Aber was ist, wenn Freitagnachmittag Ihr Lieferant anruft und Ihnen sagt, dass sich in zwei Stunden IP und Name seines FTP-Servers ändern, auf den Sie immer Ihre Bestellungen schicken? Irgendjemand aus Ihrer IT-Truppe wird noch im Hause sein und die Änderungen machen können, ein Dienstleister macht vielleicht Freitag früher Schluss oder ist so eingedeckt, dass er erst Mitte nächster Woche dazu kommt.

Auch Erweiterungen der Software – soweit diese das zulässt – können Sie in Eigenregie vornehmen. Vorausgesetzt, Sie haben die passenden Leute dafür. Aber Vorsicht an diesem Punkt: Jeder Hersteller wird, auch, wenn er Ihnen die Schnittstellen (alias API) zur Verfügung stellt, jegliche Verantwortung für Codes ablehnen, den Sie selbst geschrieben oder zumindest ins System eingebracht haben. Aber hätten Sie ganz ohne Standardsoftware alles selbst geschrieben, wäre es ja auch nicht anders.

Was in diesem Szenario auf jeden Fall nötig ist, ist eine ausführliche Schulung Ihrer Mitarbeiter. Das fängt bei Administration, Datensicherung und Logging an, geht natürlich über die tägliche Bedienung, Aufsetzen von Prozessen und Kommunikation, bis hin eben zur API für eigene Erweiterungen (falls vorhanden und für Sie interessant). Und da eine Schulung meist nur die grundlegendsten Dinge und einen kleinen Teil der unzähligen Funktionen eines so komplexen Systems vermitteln kann (und davon wiederum nur ein Teil hängen bleibt), ist gerade in einem solchen Fall ein zuverlässiger, schneller und hilfsbereiter Support auf Herstellerseite unabdingbar. Erkundigen Sie sich also im Vorfeld über das Unternehmen und den Ruf, den sein Support genießt. Nebenbei sollte auch eine ausführliche Dokumentation verfügbar sein, denn ein Blick ins Handbuch geht meist schneller als die Mail an den Support.

Achten Sie übrigens darauf, dass Sie das Rad nicht jedes Mal neu erfinden. Sowohl Anbindungen von Standard-Kommunikationswegen (von AS2 bis X.400) wie auch die Handhabung der üblichen Datenformate (EDIFACT, Fortras, VDA, …) sollten vom System durch einfache Masken und bereits fertige Strukturdefinitionen unterstützt werden.

Vorteile dieser Lösung (zusätzlich zum allgemeinen „inhouse“-Teil):

  • Sie wissen genau, was in Ihrem System abläuft, da Sie selbst alles aufgesetzt haben.
  • Entsprechend schnell können Sie Änderungen vornehmen.
    Auf Fehler und Probleme kann sofort reagiert werden.
  • Updates können Sie auch mal am Wochenende einspielen, wenn das System kurz ausfallen darf (und ein Dienstleister höchstens gegen Extra-Gebühr verfügbar wäre).
  • Ihre internen Daten kommen nie in fremde Hände. Besonders wichtig ist das z.B. im Gesundheitswesen (streng vertrauliche Patientendaten) oder auch bei Banken und Versicherungen.
  • Erweiterungen, falls vom System erlaubt, sind schnell möglich.
  • Ihre Mitarbeiter wissen, wie der Hase läuft. Sie kennen die Prozesse in
  • Ihrem Unternehmen und müssen so nicht alles erst umständlich einem Dienstleister erklären.


Nachteile:

  • Um das System wirklich bedienen und administrieren zu können, brauchen Ihre Mitarbeiter eine ausführliche Schulung. Und danach einige Zeit, bis sie genug Erfahrungen gesammelt haben, um wirklich sattelfest zu sein.
  • Sie sind dementsprechend auf guten und schnellen Support angewiesen.
  • Sie benötigen die personellen Ressourcen, um das System zu administrieren und zu bedienen.

2. Inhouse mit Dienstleistung

Alles läuft bei Ihnen vor Ort, aber der SW-Hersteller (oder ein unabhängiger Dienstleister) setzt für Sie die verschiedenen Anbindungen auf. Sie monitoren das Ganze, und bei Problemen oder Änderungswünschen kommt wieder der Dienstleister ins Spiel.
Was kann man denn so alles von einem Dienstleister machen lassen?

  • Administration mit Einspielen von Updates und Bugfixes
  • Einrichten der Kommunikation mit den Partnern
  • Anbinden der anderen Systeme (ERP, DB, …) im Haus
  • Aufsetzen von Konvertierungen zwischen Datenformaten
  • Abbilden der gesamten EDI-Prozesse
  • Monitoring des laufenden Betriebs und Reaktion auf Fehler

Wie viel Dienstleistung Sie in Anspruch nehmen und was Sie doch lieber selbst in der Hand behalten, können Sie natürlich im Einzelnen entscheiden. Hier schildern wir mal das Extrem, dass alles ausgelagert wird. Wobei das spätestens beim Monitoring an eine kritische Grenze stößt, denn zumindest das sollte bei einem Inhouse-System in Ihrer Hand bleiben. Auch für einen Dienstleister dürfte es schwierig werden, X Kundensysteme ständig zu überwachen, die womöglich über die halbe Welt verstreut sind.
Was Sie sich hier ganz klar sparen können, ist eine ausführliche Schulung. Sie sollten zwar trotz Allem über die grundsätzliche Funktionsweise Ihres Systems Bescheid wissen, da man seine geschäftskritischen Daten wohl nur sehr ungern einer Black Box anvertraut, aber detailliertes Wissen über Konfiguration, Administration und Abbildung der Prozesse ist in diesem Fall nicht nötig. Wenn Sie etwas brauchen, einen neuen Partner anbinden wollen, mit einem neuen Datenformat konfrontiert werden oder ähnliches, dann beauftragen Sie den Dienstleister damit. Der hat Spezialisten, die den ganzen Tag nichts anderes machen und sich in allen Ecken der Software bestens auskennen.

Womit er sich allerdings nicht auskennt, ist exakt Ihr Betrieb. EDI ist kein Feld für 08/15-Lösungen, selbst zwei oberflächlich betrachtet identische Prozesse können bei verschiedenen Unternehmen vollkommen unterschiedlich aussehen. Als Beispiel nehmen wir eine simple Datenkonvertierung von Lieferabruf-Daten aus dem Format VDA 4905 in ein EDIFACT DELFOR. Schon das VDA-Datenformat bietet so einige Freiheitsgrade, da nicht alle im Format möglichen Angaben auch tatsächlich verpflichtend gemacht werden müssen. Das EDIFACT-Format ist da noch „einen Tick“ umfangreicher.

Sie sehen auf Seite 30 rechts zum Beispiel in der Segmentgruppe 2 (SG2) ein NAD-Segment, NAD steht für „Name and address“. Ein weiteres solches Segment sehen Sie in der SG7, die unterhalb der SG6 liegt, in der es um Vorgehensanweisungen (Processing instructions) geht. Und was man hier nicht sieht: Noch weiter in den Tiefen der Struktur kommt das
NAD noch einmal vor, auf Ebene der einzelnen Positionen. Es gibt also nicht die Umsetzung schlechthin von VDA4905 in DELFOR, sondern eine ganze Palette von Möglichkeiten.

Genau hier haben Sie dem Dienstleister gegenüber einen gewaltigen Wissensvorsprung: Sie wissen, welches der vielen, im DELFOR vorkommenden, NAD-Segmente in Ihrem speziellen Fall genutzt werden soll. Oder Sie können diese Information zumindest direkt bei Ihrem Partner, für den die Daten bestimmt sind, erfragen. Hinzu kommt: Im VDA-Format gibt es gerade einmal die Kundennummern von Lieferant und Kunde, detaillierte Adressinformationen kommen hier gar nicht vor. Sie wissen aber, ob es reicht, einfach ebenfalls Kunden- und Lieferantennummer einzutragen, wie sie im VDA stehen, ob man sie von einem Nummernkreis auf einen anderen (ILN) umsetzen muss oder ob auch die gesamten Adressangaben benötigt werden. Und noch viel wichtiger: Sie wissen, aus welchem Ihrer Systeme Sie diese Informationen bekommen können und auf welchem Wege.

Das alles können Sie natürlich dem Dienstleister, der für Sie die Konvertierung aufsetzt, mitteilen. Es verursacht aber zusätzlichen Kommunikationsaufwand, der erfahrungsgemäß in ein ausgiebiges Frage-Antwort-Spiel ausartet. Bei komplexen Prozessen, die die Gegebenheiten in Ihrem Unternehmen berücksichtigen müssen, wird das Ganze noch viel spaßiger.

Was Administration, Anbindung von Systemen und Kommunikation angeht, sieht es ähnlich zweigeteilt aus. Einerseits hat natürlich der Hersteller der Software oder ein spezialisierter Dienstleister die größte Erfahrung nicht nur mit seinem System, sondern auch bezüglich des Zusammenspiels bestimmter Fremdsysteme (z.B. Datenbanken). Andererseits sind doch wieder Sie es, die erst die nötigen Informationen zusammenstellen und ihm weiterreichen müssen, damit er das Ganze dann umsetzt. Mal salopp gesagt: Bis dahin haben Sie’s auch schon selbst erledigt.

Vorteile:

  • Sie müssen nicht im eigenen Hause tiefergehendes Wissen über die
  • Funktionsweise des Systems aufbauen.
  • Konvertierungen und andere Prozesse profitieren von der Erfahrung des
  • Dienstleisters im Umgang mit der Software.
  • Sie sparen sich personellen Aufwand.


Nachteile:

  • Hoher Kommunikationsaufwand für jede neue Anbindung, jeden neuen Prozess und jede Änderung
  • Sie müssen immer noch einen Teil der Arbeit machen, um den Dienstleister mit den nötigen Informationen zu versorgen.
  • Der Dienstleister kann nicht immer sofort reagieren, Sie sind auf seine Resourcen angewiesen.
  • Evtl. müssen Sie dem Dienstleister Informationen geben, die Sie eigentlich lieber im Hause behalten möchten.

Zusammenfassung:
Wenn das System schon bei Ihnen im Hause steht, sollten Sie es nutzen, indem Sie volle Kontrolle über alles behalten. Sicher können Sie einige Arbeiten an einen Dienstleister auslagern, was den anfänglichen Schulungsaufwand reduziert und schneller zu guten Ergebnissen führen kann. Erwarten Sie aber nicht, dem Dienstleister nur ein paar Stichworte zu geben und dann entspannt auf das Ergebnis warten zu können. Sie können Arbeitszeit Ihrer Mitarbeiter einsparen, aber ganz ohne geht es nicht.

SaaS
SaaS steht für „Software as a Service“, will heißen, jemand bietet Ihnen die Dienstleistung an, Software zu nutzen, die gar nicht bei Ihnen (sondern bei ihm) installiert ist. Heutzutage muss dann immer auch das aktuelle Über-Buzzword „Cloud“ fallen, auch wenn das eigentlich vollkommen bedeutungslos ist, denn der Sinn ist immer noch derselbe.

Wie also sieht das in der Realität aus?

Irgendwo in einem Rechenzentrum (RZ), theoretisch am anderen Ende der Welt, ist das EDI-System installiert. Der Rechenzentrums-Betreiber sorgt dafür, dass das System hochverfügbar ist, erledigt Datensicherungen, spielt Updates und Bugfixes ein und stellt natürlich die gesamte Kommunikations-Infrastruktur bereit. Sie nutzen das Ganze von Ihrem Betrieb aus über das Internet, den Browser oder einen speziellen Client. Sie können Kommunikationskanäle einrichten, sowohl vom RZ zu Ihren Partnern als auch zu Ihnen selbst, denn die Daten müssen ja auch von Ihren Systemen in das EDI-System im RZ und zurückkommen. Auch Datenkonvertierungen und Prozessketten bilden Sie so ab, wie Sie es eben brauchen, das liegt alles in Ihrer Hand. Und natürlich überwachen Sie auch selbst, ob alles sauber läuft. So weit, so gut. Sie sparen sich also eigene Hardware und Infrastruktur, und auch die ganze Systemadministration ist Sache des Betreibers.

Da nicht bei Ihnen installiert wird, bezahlen Sie auch nicht gleich ein ganzes System, sondern nur die Nutzung. Es gibt verschiedene Modelle, pro aktiver Schnittstelle, pro Anzahl der Nachrichten/Konvertierungen oder Datenvolumen oder oder oder. Das spart natürlich hohe Anfangsinvestitionen.

Allerdings stößt das Konzept schnell an seine Grenzen, wenn die Anforderungen über reine Formatkonvertierung und Kommunikation hinausgehen. Wenn Sie z.B. auch Daten anreichern müssen, vielleicht zu einer Kundennummer auch Namen und Adressdaten beschaffen, wird die Sache kompliziert. Denn solche Daten liegen nun mal auf den Datenbanken und anderen Systemen in Ihrem eigenen Netz und nicht beim RZ-Betreiber. Hier kann man natürlich eine VPN-Strecke aufbauen, über die vom Rechenzentrum aus auf Ihr Netz zugegriffen werden kann, aber abgesehen von Sicherheitsbedenken kostet so etwas doch ganz schön Performance. Außerdem ist es eine zusätzliche Schwachstelle, denn während das RZ vielleicht Hochverfügbarkeit garantiert, kann die VPN-Strecke schnell mal z.B. wegen DSL-Problemen o.ä. zusammenbrechen.

Wenn Sie reine EDI-Prozesse einfachen Aufbaus haben, nur Datentransport und -Konvertierung, ist SaaS durchaus eine Option. Einfache Anreicherungen und Umsetzungen (z.B. von Länderkürzeln) lassen sich eventuell noch über kleine Dateien etc. abfackeln. Wird aber eine engere Anbindung an Ihre restliche IT-Landschaft benötigt, stellen Sie sich mit dieser Variante schnell selbst ein Bein. Soll dasselbe System auch Aufgaben aus dem EAI oder ETL-Bereich erledigen, kommt sowieso nur eine Inhouse-Lösung in Frage.

Vor & Nachteile

Vorteile:

  • Sie benötigen weder Hardware noch Infrastruktur (außer Internet-Anbindung).
  • Ein Rechenzentrum kann eine ganz andere Verfügbarkeit gewährleisten.
  • Die rein administrativen Aufgaben wie z.B. Updates kümmern Sie nicht.
  • Es fallen keine hohen Anfangsinvestitionen an.

 

Nachteile:

  • Sie sind von der Zuverlässigkeit des Betreibers abhängig.
    Der Rest Ihrer IT-Landschaft ist gar nicht oder nur mit „Klimmzügen“ zu erreichen.
  • Dadurch besteht keine Chance, mit demselben System auch EAI- oder ETL-Themen abzudecken.
  • Unternehmenswichtige Daten und Prozesse befinden sich in fremder Hand.
  • Je nach Intensität der Nutzung und Abrechnungsmodell können die laufenden Kosten schnell teurer werden, als es eine Inhouse-Lösung gewesen wäre.

Tipp

m Moment nur auf Druck Ihrer Geschäftspartner überhaupt das Thema EDI angehen und nicht mehr als eine Handvoll einfache Anbindungen zu erledigen sind, ist SaaS eine verlockende Sache. Wenn aber abzusehen ist, dass sich das ganze Thema in den nächsten Jahren ausweiten wird (und da werden Sie wahrscheinlich kaum drum herumkommen), dann suchen Sie doch nach einem Anbieter, der Ihnen beides ermöglicht!
Sie fangen mit SaaS (oder gar EDIaaS) an, und wenn die Zeit für eine Inhouse-Installation gekommen ist, ziehen die Schnittstellen einfach zu Ihnen um. Wenn es dieselbe Software ist, sollte sich so ein Umzug nicht wirklich schwierig gestalten.

EDIaaS
Mit Hilfe von EDIaaS haben Sie mit dem ganzen EDI-Vorgang nur sehr, sehr wenig zu tun, denn EDI as a Service bedeutet, dass alles, vom Betrieb der Hardware bis zur Konfiguration der Kommunikationswege und Datenkonvertierungen und sogar das Monitoring von einem Dienstleister erledigt wird.

Das klingt natürlich erst mal unglaublich bequem, denn Ihre Arbeit besteht im Wesentlichen daraus, dem Dienstleister Daten für Ihre Partner in die Hand zu drücken, der sie den Empfängern im richtigen Format zustellen wird, und die fertig aufbereiteten Daten Ihrer Partner wieder in Empfang zu nehmen. Ihre Systeme brauchen nur noch die passenden Dateien auszuspucken bzw. einzulesen, das war’s.

Doch zum einen beschränkt sich Ihre Arbeit nicht wirklich nur darauf. Ihr Dienstleister mag Ihnen auch noch die Abstimmung der Kommunikation mit Ihren Partnern abnehmen, und vielleicht kümmert er sich auch darum, herauszubekommen, wie genau denn deren Daten aussehen müssen. Sie werden ihm aber zumindest noch erklären müssen, wie Ihre eigenen Daten aufgebaut sind bzw. wie genau Sie von ihm die Partnerdaten aufbereitet haben wollen. Aber gut, im Vergleich zu allen anderen Lösungen ist diese sicher die mit dem wenigsten Aufwand für Sie.

Zum anderen haben Sie aber praktisch keine Kontrolle mehr über das, was da mit Ihren geschäftskritischen Daten passiert. Sie bekommen bestenfalls noch zu sehen, ob nach Meinung des Dienstleisters alles glatt läuft oder ob irgendwelche Prozesse auf die Nase gefallen sind. Im schlimmsten Fall bemerken Sie Probleme erst, wenn sich Ihre Partner
beschweren, weil Daten nicht oder unsauber ankommen oder Sie selbst auf fehlende Daten stoßen.

Außerdem müssen Sie bei jeder neuen Anbindung oder auch nur kleinen Änderung einen Auftrag an den Dienstleister stellen, diese Leistung natürlich extra bezahlen und vor allem abwarten, bis er die Manpower freistellt, um den Auftrag zu erledigen.

Und zu guter Letzt haben Sie natürlich noch, wie bei SaaS, den Nachteil, dass keine oder nur sehr eingeschränkte Zugriffe auf Ihre eigenen Systeme möglich sind. Mal schnell die Adressdaten zu einer Kundennummer aus Ihrer Datenbank ziehen? Fehlanzeige.

Vorteile & Nachteile

Vorteile:

  • Keine eigene Hardware und Infrastruktur erforderlich, stattdessen Ausfallsicherheit eines Rechenzentrums
  • Der Dienstleister bietet meist eine große Palette von möglichen Kommunikationswegen an.
  • Erfahrung und Routine des Dienstleisters im Umgang mit Software und Datenformaten
  • Es fallen keine hohen Anfangsinvestitionen an.
  • Vergleichsweise wenig eigener Arbeitsaufwand

Nachteile:

  • Keinerlei Kontrolle über geschäftskritische Daten und Vorgänge
  • Vollständige Abhängigkeit vom Dienstleister (Vertrauenswürdigkeit, personelle Resourcen etc.)
  • Der Rest Ihrer IT-Landschaft ist gar nicht oder nur mit „Klimmzügen“ zu erreichen.
  • Dadurch keine Chance, mit dem selben System auch EAI- oder ETL-Themen abzudecken.
  • Je nach Intensität der Nutzung und Abrechnungsmodelle können die laufenden Kosten schnell teurer werden, als es eine Inhouse-Lösung gewesen wäre.

Fazit

Noch mehr als bei SaaS gilt hier also, dass sich EDIaaS nur für wenige, sehr einfache EDI-Szenarien eignet. Wenn es nennenswert komplexer wird, taugt diese Lösung nicht mehr. Und hier noch stärker als bei SaaS sind Sie nicht mehr Herr über Ihre eigenen Daten und für Ihr Geschäft lebenswichtigen Vorgänge. Auch hier der Tip: Wenn Sie auf diesem Wege in das Thema EDI einsteigen wollen, halten Sie sich durch kluge Wahl des Anbieters die Möglichkeit offen, später auf eine Variante mit mehr Möglichkeiten (und mehr Kontrolle) umzusteigen, ohne wieder alles komplett neu aufsetzen zu müssen.

Freies Internet vs. VAN
EDI-Kommunikation ist das A und O – das können Sie wörtlich nehmen. Denn Anfang und Ende, Alpha und Omega, eines EDI-Prozesses ist die Kommunikation. Irgendwie müssen ja Ihre Daten und die des Kunden in das EDI-System kommen und von dort auch wieder zu ihm oder Ihnen. Während so etwas früher per Fax, Post oder auch Telefon erledigt wurde, bietet das Internet heute eine Fülle von Kommunikations- und DFÜ-Protokollen. Und es kommen ständig neue hinzu. Hier eine kleine Auflistung der gängigsten:

  • FTP(S): File Transfer Protocol (optional mit SSL-Verschlüsselung)
  • SMTP/POP3/IMAP: klassische EMails
  • SFTP und SCP: Secure FTP und Secure Copy, beides SSH-getunnelte Übertragungsarten
  • HTTP(S): Das altbekannte Hypertext Transfer Protocol (optional mit
  • SSL-Verschlüsselung)
  • OFTP: Odette File Transfer Protocol; hat nur dem Namen nach was mit dem allgemein gebräuchlichen FTP zu tun und war eigentlich ein Provisorium, das es inzwischen immer noch, und zwar schon in Version 2 gibt.
  • AS2: Applicability Statement 2; die eigentliche Datenübertragung läuft über HTTP(S), allerdings sind diverse Sicherheitsschichten eingezogen, vor allem mehrere Möglichkeiten, die Daten zu verschlüsseln und zu signieren. Außerdem bekommt der Absender immer sofort eine Information, ob seine Daten sauber empfangen wurden.
  • WebDAV: Web-based Distributed Authoring and Versioning; eine Erweiterung von HTTP, die mehr Möglichkeiten der Dateiübertragung bietet (ganze Verzeichnisse), außerdem Benutzerrechte und Versionierung.

All diese Kommunikationswege werden später noch ausführlicher beschrieben.
Neben dem allgemeinen Internet mit diesen (und noch ein paar weiteren) EDI-Kommunikationsmöglichkeiten gibt es noch andere Wege, mit seinen Partnern Daten auszutauschen. So funktionierte zum Beispiel OFTP anfangs nur über ISDN-Verbindungen direkt zwischen den Kommunikationspartnern, was natürlich sicherer ist als eine normale FTP-Übertragung oder gar einfache Mail über’s Internet. Eine Dienstleistungsform, die sich mit der Bereitstellung von (meist) gesicherter Übertragung, oft gepaart mit ein paar zusätzlichen Dienstleistungen, beschäftigt, ist das sogenannte Value Added Network, kurz VAN. Dieses Konzept stammt noch aus der Zeit vor dem Internet, und damals war es gut, um vor allem zwei Punkte zu erschlagen:

  • Kunden des VAN mussten nicht mit jedem Geschäftspartner eigens die Kommunikation aushandeln. War dieser an dasselbe VAN angeschlossen, drückte man dem VAN die Daten in die Hand und sagte ihm, wohin sie sollen. Im Idealfall (alle Partner im selben VAN) war so nur eine Anbindung nötig, um alle zu erreichen.
  • Da nicht jeder in so ein VAN hineinkam (wie heute ins Internet), konnte der Betreiber auch dafür sorgen, dass niemand heimlich mitlauschte oder den Verkehr störte. Er konnte also die sichere Übertragung gewährleisten.

In gewisser Hinsicht gelten diese Punkte auch heute noch, wobei die „Values“ (zu Deutsch nennt man die VANs „Mehrwertnetze“) heute gerne z.B. durch Datenkonvertierung und ähnliches erweitert werden, sodass VANs ein wenig in Richtung EDIaaS tendieren. Die Frage ist nun: Was setzt man ein, wenn man selbst EDI betreiben will? Soll man sich an ein VAN ankoppeln oder einfach das Internet nutzen, das man eh schon hat? Natürlich stellt sich diese Frage nur, wenn man eben nicht nur EDIaaS nutzen will, sondern ein eigenes, wenn auch vielleicht gehostetes (SaaS) EDI-System betreibt.
Sehen wir uns noch mal die beiden Hauptvorteile des VAN an:

Eine Anbindung für alle

Das klingt im ersten Moment wunderbar, ist aber eben nur der Idealfall. Dazu müssen wirklich alle Kommunikationspartner an dasselbe VAN angebunden sein. In der Praxis eher unwahrscheinlich. Natürlich kann es sein, dass das VAN auch die Kommunikation nach „draußen“ anbietet, aber in dem Moment ist man dann schon wieder im normalen Internet, wo zumindest Vorteil 2 nicht mehr gegeben ist. Das Konfigurieren der diversen Kommunikationskanäle sollte sich mit anständiger EDI-Software nicht als besonders schwer erweisen, da sind wir inzwischen weiter als noch vor ein paar Jahren.

Geschlossene Nutzergruppe & gesicherte Übertragung

Abgesehen davon, dass es kein Netz gibt, das nicht gehackt werden kann, sind inzwischen gerade für die gesicherte Übertragung von Daten reichlich allgemein verfügbare Standards entwickelt worden. Ob HTTPS, FTPS, SFTP/SCP oder AS2, überall wird verschlüsselt. Bei AS2 gibt es gleich mehrere Ecken, an denen mit Verschlüsselung und Signatur der Daten gearbeitet werden kann. Und eine Empfangsbestätigung ist da auch Pflicht. Dieser Pluspunkt hat sich, wenn man aktuelle Übertragungstechniken verwendet, längst erledigt.

Die Vorteile, die solche VANs früher also unbestreitbar hatten, haben sich mit der Entwicklung des Internet inzwischen weitgehend erledigt. Der Nachteil aber ist geblieben:
Es kostet zusätzliches Geld. Ob nun monatliche/jährliche Gebühr oder (womöglich obendrauf) Kosten pro versendeter oder empfangener Datei, Sie zahlen noch mal extra für eine Leistung, die Sie eigentlich auch anders abdecken können.

Wie gesagt, wir sprechen hier von dem Fall, dass die zusätzlich bei EDI anfallenden Arbeiten wie Konvertierung, Abgleich, Anreicherung etc. bereits von einem speziellen System abgedeckt werden. Wenn Sie nur einfaches EDIaaS benötigen, mag das Angebot eines  entsprechenden VANs ausreichen (wobei eine Beschränkung nur auf angebundene
Kommunikationspartner heute wohl kaum noch hinnehmbar wäre …).

Wenn man das so genau sagen könnte …
Tja, was ist denn nun so ein ESB? Die einen bezeichnen ihre Software als ESB, andere eine bestimmte Infrastruktur, die sie in ihrem Unternehmen (oder ihrer Abteilung) aufgebaut haben, wieder andere sehen darin ein Architekturkonzept oder eine bestimmte Technologie. Alles ausgesprochen schwammig. Erfunden wurde der Begriff wohl, um diverse, bereits bestehende Softwareprodukte und ihre Arbeitsweise mit einem (mehr oder minder) griffigen Ausdruck zu fassen. Aber das hilft uns nicht weiter. Was also tut so ein ESB?

Alles Kommunikation
Der ESB dient der Kommunikation zwischen verschiedenen Systemen, ohne dabei großartig Logik abzubilden. Das unterscheidet ihn von EAI und EDI. Er beherrscht zwar die Sprachen (also Datenformate und Schnittstellen) aller angebundenen Systeme, und kann Informationen von einem System zum anderen leiten, aber das war’s auch schon, wenn man sich wirklich auf die Aufgaben eines „echten“ ESB beschränkt.

Ein System kann ihm also eine CSV-Datei in die Hand drücken, die er an ein anderes System weiterreicht und nebenbei auch noch in – beispielsweise – ein XML-Format umsetzt, das dieses Zielsystem versteht. Jegliche Business-Logik ist ihm aber fremd. Sinnvoll ist das, um die Kommunikation zwischen verschiedenen Systemen zu vereinfachen. Man muss nicht jedem System einzeln beibringen, wie es mit n anderen Systemen zu kommunizieren hat
(inklusive Umbau der Datenformate), sondern regelt das zentral über Adapter am ESB. So braucht der ESB nur einmal zu wissen, wie er ein CSV- in ein bestimmtes XML-Format umsetzt, ganz egal, wie viele Systeme dann über diese Formate kommunizieren wollen.

Das klingt alles sehr nach dem, was auch schon bei EAI beschrieben wurde. Und tatsächlich kann man die Arbeit eines ESB als Teil der Aufgaben der EAI betrachten. Nur, dass EAI eben auch Logik und Zusammenhänge in den Geschäftsprozessen abbildet und umsetzt, während der ESB eigentlich nur die Übersetzung und den Transport übernimmt. Da das ganze Thema wirklich ausgesprochen schwammig ist – und einige Experten sogar bezweifeln, dass dieser Begriff überhaupt seine Daseinsberechtigung hat, halten wir uns einfach nicht länger damit auf.