Das Problem: EDI-Anbindungen herstellen dauert lange.
Die Ansage der Geschäftsleitung ist klar: die Effizienz der Beschaffungsprozesse muss erhöht werden! Konkret bedeutet das unter anderem, dass die Prozesse mit den Lieferanten über EDI und/oder API automatisiert werden müssen. Hinweis: Zum Thema API im EDI-Kontext finden Sie am Ende des Artikels weiterführende Informationen. Da Ihre Kunden ebenfalls an der Effizienzsteigerung der Beschaffungsprozesse arbeiten, kommt auch vom Vertrieb der Druck möglichst viele Kunden über EDI anzubinden.
Was führt zu langen Durchlaufzeiten?
Problem 1: Das ‚Aushandeln‘ von Formaten und Transportprotokollen
Dieses Problem tritt vor allem dann auf, wenn das Thema EDI für eine Organisation neu ist. Aber auch bei Unternehmen die schon lange EDI einsetzen kommt es immer wieder vor, dass bei jeder Kunden- / Lieferantenanbindung jedes Mal aufs Neue zunächst das Format (EDIFACT, xCBL, OpenTrans, UGL, etc.) festgelegt bzw. manchmal sogar richtiggehend ‚ausgehandelt‘ werden muss. Als Lieferant kann es sein, dass man sich an dieser Stelle dem Wunsch des Kunden fügen muss und beim Format wenig Einfluss nehmen kann.
Problem 2: Missverständnisse bei der Belegung von Feldern im EDI-Dokument
Wenn Problem 1 besteht, dann besteht oft auch Problem 2: Es gibt keine genaue Beschreibung wie die Felder im EDI-Format verwendet werden sollen. Mit den EDI-Standards ist es ja leider nicht so wie mit Schrauben die laut DIN (Deutsches Institut für Normung) genormt sind: Eine Schraube M8 passt immer zur Schraubenmutter M8. Bei EDIFACT und allen anderen ‚Standards‘ für den Austausch von Geschäftsdokumenten ist das leider nicht so. Viele Felder sind mehrdeutig oder werden vom Kommunikationspartner ‚am anderen Ende‘ einfach falsch verstanden, falsch verwendet oder zweckentfremdet. Wenn also jedes Feld einzeln zwischen den Partnern abgestimmt werden muss, ist es mit der Effizienz beim Anbinden nicht weit her.
Eine Anmerkung zu den Problemen 1 und 2: Wenn Ihre Organisation schon definiert, hat welche Formate unterstützt werden und entsprechende Implementierungsleitfaden vorhanden sind – dann haben Sie schon einen großen Schritt gemacht. Vermutlich haben Sie aber trotzdem schon das Problem gehabt, dass Sie von Ihrem Kommunikationspartner in eine mühsame Abstimmung jedes einzelnen Feldes gedrängt werden.
Problem 3: Mangelnde Verfügbarkeit von EDI-Entwicklern
Sind die ersten Hürden genommen, Format und Feldbelegung stehen fest, dann kann es ja los gehen! Sofern der EDI-Entwickler gerade Zeit hat, dann geht es zumindest bei diesem Schritt wirklich flott. Aber es kann auch anders kommen: Der Entwickler, egal ob intern oder extern, hat eine lange Liste an offenen Mappings die zu machen sind und das Anbindungsprojekt geht in die Warteschleife.
Problem 4: Der Aufwand für das Testen und Mangel an Testdaten
Und dann die Sache mit den Testdaten – oder besser gesagt, dem Mangel daran. Brauchbare Testdaten zu bekommen, ist oft ein Kampf für sich. Ohne diese läuft man Gefahr, eine Anbindung unter Druck und ohne ausreichende Tests live zu setzen – mit dem Ergebnis, dass das SAP-System mit falschen Daten geflutet wird. Und das haben Sie vielleicht auch schon erlebt: wenn das Mapping fertig ist, findet der anzubindende Partner plötzlich keine Zeit zum Testen.
Welche Folgeprobleme können auftreten?
Wenn Sie mit den vier oben beschriebenen Problemstellungen immer wieder konfrontiert sind, dann könnte es sein, dass Sie mir auch bei der folgenden Aussage zustimmen können: Die EDI-Abdeckung von Geschäftsbeziehungen mit Nachdruck auszubauen, ohne an den grundlegenden Problemen zu arbeiten wird nicht zu nachhaltigen Lösungen führen. Das wäre wie in der alten Geschichte wo versucht wird ein totes Pferd zu reiten, weder eine stärkere Peitsche noch ein extern zugekaufter Reiter werden das tote Pferd wiederbeleben können. Jede EDI-Anbindung wird wieder hohe Aufwände verursachen und das Gesamtsystem wird mit jedem zusätzlichen ‚maßgeschneiderten Mapping‘ wartungsintensiver. Durch die langen Durchlaufzeiten entstehen Opportunitätskosten, weil ja die Bestellungen manuell erfasst werden müssen und die Unzufriedenheit bei den Kunden steigt mit jedem Tag, wo die Anbindung nicht läuft. Noch größer wird das Problem, wenn die Herstellung einer EDI-Anbindung Vertragsgegenstand mit dem Kunden oder Lieferanten ist.
Viele Unternehmen stecken aber in der ‚Zwickmühle‘, dass möglichst rasch EDI-Anbindungen gebaut werden müssen, andererseits ist auch das Bewusstsein dafür vorhanden, dass der ‚alte Weg‘ nicht besonders gut skalierbar ist. Was können Sie nun unternehmen?
Die Lösungsbausteine
Vermutlich haben Sie schon einen oder mehrere der folgenden Lösungsbausteine umgesetzt oder zumindest überlegt das zu tun. Werfen wir also einen näheren Blick auf diese Bausteine:
Lösungsbaustein 1: ‚Weniger ist mehr‘
Statt immer mehr verschiedene Formate zu unterstützen und damit den Wartungs- und Entwicklungsaufwand stetig zu erhöhen, wäre es eine Überlegung wert, sich auf einige wenige Formate zu konzentrieren. Das könnten zum Beispiel Branchenstandards sein oder das Format, welches von der am häufigsten bei Ihren Kunden eingesetzten Software unterstützt wird. Solche Formate können ein echter Hebel sein um das Volumen der Aufträge, die über EDI abgewickelt werden, deutlich zu erhöhen. Aber auch die Konzentration auf maximal 2-3 generell gängige Formate wie z.B. EDIFACT, OpenTrans und SAP-Idoc kann das tägliche Leben schon vereinfachen.
Lösungsbaustein 2: Der ‚Implementierungsleitfaden‘
Wenn Sie Ihren Kunden und Lieferanten einen fix fertigen Implementierungsleitfaden zur Verfügung stellen können, dann reduziert das die Abstimmungsaufwände enorm und verkürzt somit erheblich die Durchlaufzeit für eine EDI-Anbindung. Ein ‚Sahnehäubchen‘ wäre jetzt noch, wenn Sie Ihrem Kommunikationspartner zusätzlich zum Implementierungsleitfaden noch Beispiel- und Testdaten zur Verfügung stellen.
Lösungsbaustein 3: Das ‚Standardmapping‘
Aufbauend auf die ersten beiden Bausteine können nun ‚Standardmappings‘ implementiert werden. Für jedes Format/Dokumententyp (EDIFACT-Rechnung, EDIFACT-Lieferschein, etc.) ein Mapping. Jetzt können alle EDI-Dokumente, die sich an Ihren Implementierungsleitfaden halten über dieses Mapping verarbeitet werden. Problem gelöst! Neue Anbindungen müssen nur noch konfiguriert werden. Ich sehe förmlich, wie Sie den Kopf schütteln. Leider schaut die EDI-Welt in der Realität anders aus. Der Haken ist, dass selten ein Dokument exakt so aussieht wie Sie das definiert haben. Oft sind Datumsformate, Mengeneinheiten, oder andere ‚Kleinigkeiten‘ anders als Sie das definiert haben. Und leider lässt sich das beim ‚Absender‘ nicht immer anpassen, auch dort versucht man möglichst wenig Varianten von Mappings zu haben und wenn die ‚Standards‘ wieder einmal nicht zusammenpassen, müssen Sie eine Lösung finden: Schon wieder ein individuelles Mapping für eingehende Bestellungen!?
Und auch bei den ausgehenden Dokumenten haben Sie ein ähnliches Problem: Hier wünscht sich Ihr Kunde, der oft den längeren Hebel hat, dass Sie seine Konventionen einhalten. So kann es schon einmal vorkommen, dass ein Feld komplett zweckentfremdet, verwendet werden muss, weil der Empfänger das so möchte. Wie schaffen wir es nun unser Standard-Mapping zu verwenden und trotzdem mit den Abweichungen von unserem Implementierungsleitfaden zurecht zu kommen? Hier kommt Lösungsbaustein 4: Die ‚Rules Engine‘ ins Spiel.
Lösungsbaustein 4: Die ‚Rules Engine‘.
Die Rules Engine ist bei eingehenden Nachrichten zwischen dem ERP-System und den Standard Mappings dazwischengeschaltet. Bei den ausgehenden Nachrichten ist die Rules Engine zwischen Mapping und dem Adapter/Connector der die Nachricht zum Partner sendet dazwischengeschaltet. Um das zu verdeutlichen ein kleines Bild:
Die Rules Engine hat die Aufgabe mit Hilfe von Regeln, für eine bestimmte EDI-Anbindung, noch Änderungen am Inhalt der EDI-Nachricht zu machen. So können zum Beispiel Datumsformate oder Mengeneinheiten noch angepasst werden. Oder in dem Fall, dass Felder zweckentfremdet, verwendet werden, können Feldinhalte verschoben oder sogar eingefügt werden. (Anmerkung: Funktionalität und Aufbau von Rules Engines würde den Rahmen dieses Artikels sprengen und wird hier daher nicht näher behandelt.) Die Rules Engine ermöglicht es mit einem Standard-Mapping zu arbeiten und trotzdem für eine konkrete Anbindung individuelle Feldbelegungen und -inhalte abhandeln zu können.
Fazit
Bei der Optimierung der Durchlaufzeiten von EDI-Implementierungen gibt es durchaus signifikante Herausforderungen. Durch die Reduzierung der Formatvielfalt, die Bereitstellung von Implementierungsleitfäden, die Anwendung von Standardmappings und die Implementierung einer Rules Engine lässt sich die Effizienz im EDI-Bereich steigern und in weiterer Folge auch die Wartbarkeit des Systems nachhaltig verbessern.
Für den Aufbau eines EDI-Systems, das diese Komponenten integriert, empfiehlt sich eine modulare und skalierbare Architektur, die Anpassungen und Erweiterungen ermöglicht. Wenn Ihr System am Stand der Technik ist, dann ist es sicher eine gute Option auf Basis der vorhanden EDI-Software die oben beschriebene Architektur aufzubauen.
Gibt es Alternativen?
Wenn Sie sich ohnehin planen das aktuelle EDI-System durch ein Neues zu ersetzen, weil es ‚in die Jahre gekommen ist‘ oder Sie nicht den Aufwand treiben wollen eine Architektur wie die oben beschriebene selbst aufzubauen, bieten wir mit unserer Lösung ‚RELATIQ‘ eine Option für SAP-Anwender. Freilich können auch wir die grundlegenden Probleme nicht aus der EDI-Welt schaffen, aber mit unserer Lösung, können wir in vielen Bereichen Abhilfe schaffen und zur Steigerung der Effizienz in Ihren EDI-Projekten beitragen.