Den modernen Anforderungen des Speditionsgewerbes versucht die Nedlloyd Unitrans Deutschland GmbH, die bundesweit 16 Niederlassungen hat, mit einem strategisch orientierten EDI- Konzept zu begegnen, das konsequent den Einsatz normierter Verfahren und standardisierter Datenstrukturen verfolgt. Seit zwei Monaten laeuft die erste EDI-Anbindung mit einem Kunden und der verantwortlichen Unitrans-Niederlassung, weitere werden folgen. Klaus Reichwein* schildert den konzeptionellen Ansatz und die Erfahrungen des Pilotprojektes.

Die logistische Leistungsfaehigkeit ist gerade in der Speditionsbranche das entscheidende Kriterium fuer die Wettbewerbsfaehigkeit. Die gestiegenen Anforderungen an den physischen Guetertransport, die Uebernahme neuer Funktionen und Dienstleistungen zwingen jedes Transportunternehmen, eine moderne, unterstuetzende und umfassende Informationslogistik aufzubauen.

Zwingend notwendig ist heute im Wettbewerb die Faehigkeit, Geschaeftsprozesse mit externen Partnern auf elektronischem Weg mit Hilfe neuer Techniken und Methoden zu organisieren. Damit sollen die seit Jahren bestehenden individuellen DFUe-Loesungen abgeloest werden. Das folgende Szenario beschreibt die traditionelle Abwicklung des Vorgangs "Speditionsauftrag":

- Jede Niederlassung war remote mit dem zentralen Siemens-Rechner in Duesseldorf verbunden.

- Die Erfassung und Bearbeitung des Speditionsauftrages erfolgte mittels der zentralen Anwendung Mistral, die Daten wurden physisch in Duesseldorf gehalten.

- Die Auftraege des Kunden wurden per Fax, Brief etc. uebermittelt.

- Auftraege wurden teilweise auch per DFUe uebertragen unter Nutzung eines Unitranc-eigenen Datenformates; Daten-Carrier war General Electric (GE) mit dem Service Quickcom.

- Ueber das Netzwerk der GSI waren Unitrans-Partnerspediteure angebunden, die

als rechtlich unabhaengige Transporteure fuer Unitrans fahren.

Das Unitrans-EDI-Konzept definiert fuer die naechsten vier bis fuenf Jahre folgende Strategie:

1. Kommunikation ueber Mailbox-Verfahren: Fuer den Transfer von Edifact-Nachrichten wird das Mailbox-Verfahren EDI-Express im General-Electric-Netzwerk eingesetzt. Parallel bleibt der Service Quickcom fuer den Transfer nicht standardisierter Strukturen erhalten.

2. Edifact: Statt des eigenen Unitrans-Formates kommt der Nachrichtentyp Iftmin (; Speditionsauftrag) zum Einsatz. Weitere IFTxxx-Nachrichten sind geplant.

3. Kommunikations-Schnittstelle: Zukuenftig wird es nur eine zentrale Schnittstelle zu den externen Partnern beziehungsweise den internen Niederlassungen geben. Alle Sende- und Empfangsprozesse werden ueber einen Kommunikationsrechner IBM AS/400 laufen. Die automatisierte Steuerung der Kommunikation uebernimmt ein individuell erstelltes Modul namens "Mailbox Manager", als Konverter wird die IBM Software "EDI/400" eingesetzt.

4. Internes Daten-Routing: Der Datentransfer von Duesseldorf zu den Niederlassungen erfolgt innerhalb eines Unifis-Netzwerks ueber Meganet-Standleitungen.

5. Dezentrale Rechner und standardisierte Anwendung: Die alte Anwendung Mistral wird durch die neue Anwendung Unifis ersetzt. Diese wird je Niederlassung dezentral auf einer AS/400 implementiert, der Siemens-Rechner wird abgeloest.

6. Anwendungsintegration: Die Durchgaengigkeit des EDI-Prozesses "Empfangen Speditionsauftrag" wird durch das automatische Generieren eines Speditionsauftrages in der entsprechenden Niederlassung erreicht. Zukuenftig wird vice versa das Senden einer Edifact-Nachricht durchgefuehrt. Die Realisierung dieses Szenarios konnte im Fruehjahr abgeschlossen werden, inklusive der erstmaligen EDI-Anbindung eines Kunden der Niederlassung Frankfurt. Heute gilt folgender Ablauf (vgl. Abbildung):

Der Kunde sendet seinen Speditionsauftrag als Edifact-Iftmin an die Unitrans-Mailbox im GE-Netzwerk. Der Mailbox Manager veranlasst daraufhin das Lesen der Mailbox und uebergibt an den Konverter EDI/400. Hier erfolgt die Umsetzung von Edifact in das Inhouse- Format. Da alle Niederlassungen die gleiche Anwendung fahren, gibt es auch nur eine Inhouse-Datenstruktur. Kunden, die zur Zeit noch nicht EDI-faehig sind, nutzen den Transfer unformatierter Daten per Quickcom.

Aufgrund der Sendeadresse (UNB in Iftmin) ist bekannt, welcher Kunde den Speditionsauftrag geschickt hat und welche Niederlassung oder welcher Partnerspediteur fuer die Abwicklung zustaendig ist. Damit dieser Speditionsauftrag noch weitergeleitet werden kann, muessen die bereits konvertierten Edifact-Daten um interne Daten ergaenzt werden. Dann routet der Mailbox Manager die interne Unifis-Datenstruktur an die Niederlassung oder den Partnerspediteur ueber das Unifis- beziehungsweise GSI-Netz. Die Niederlassung empfaengt diese Daten und generiert automatisch einen Speditionsauftrag in Unifis, der dann fuer die Disposition zur Verfuegung steht.

Selbstverstaendlich kann der Uebergang zur neuen Loesung nur schrittweise vollzogen werden. Insbesondere die EDI-Anbindung der Kunden und die Nutzung weiterer Edifact-Nachrichten werden ueber einen gewissen Zeitraum parallel mit den traditionellen Medien und DFUe-Verfahren laufen.

Die Vorgehensweise lautet hier:

- Anbindung weiterer Niederlassungen,

- Empfangen von Iftmin fuer weitere Kunden je Niederlassung sowie

- Realisierung weiterer Edifact-IFTxxx-Nachrichtentypen.

Natuerlich hatten alle Beteiligten innerhalb des Pilotprojektes mit Problemen auf verschiedenen Ebenen zu kaempfen.

EDI-Projekte sind gekennzeichnet durch einen hohen Komplexitaetsgrad. Da Aktivitaeten auf vielen Ebenen notwendig sind, bedarf es eines grossen Steuerungsaufwandes der verschiedenen Beteiligten. Dazu gehoeren interne Mitarbeiter der Zentrale fuer Konzeption und Programmierung, interne Mitarbeiter der Niederlassung fuer Schulung, externe Berater und Programmierer, Hardware- und Softwarelieferanten, Netzbetreiber sowie Kunden.

Es ist die Strategie von Unitrans, das vom Bundesverband Spedition und Lagerei entwickelte Iftmin-Subset auf der Basis des Edifact-Directories 91.2 zu verwenden. Allerdings musste von diesem Grundsatz bereits abgewichen werden, da der Pilotkunde ein von ihm erstelltes Iftmin-Subset, Version 90.1, vorgab, das erheblich von dem Branchen-Subset abweicht. Auch der geplante zweite Partner hat die Vorgabe eines abweichenden Subsets angekuendigt. Hier werden sogar selbst-definierte Segmente verwendet, die zwar Edifact- konform sind, aber ausserhalb einer offiziellen Struktur liegen und damit nicht als Standard gelten koennen.

Wie ist dem zu begegnen, ohne in einem Wirrwarr der Subset- Implementierung zu enden? Die Tatsache, in welchem Edifact-Element eine Information abgebildet ist oder ob der Qualifier X oder Y verwendet wird, ist nicht entscheidend. Wesentlich ist die Moeglichkeit, unterschiedliche Subsets auf ein und dieselbe User- File-Datei (; Schnittstellen-Datei zur Anwendung) zuzuordnen (Mapping). Dies ist dank einer sauberen Analyse der Auftragsdaten im Vorfeld moeglich. Alle Daten, die die Anwendung nicht benoetigt, werden nicht in die Schnittstellen-Datei uebernommen.

Die EDI-Konverter-Software EDI/400 erlaubt, unterschiedliche Subset-Versionen parallel zu fahren, nicht offizielle Segmente zu ergaenzen und die Zuordnung in Abhaengigkeit von Qualifier-Inhalten zu steuern (Conditional Mapping). Damit sind die oben genannten Probleme zu loesen. Aufwand entsteht natuerlich in der Subset-Pflege und durch die notwendige Partnerabsprache. Die ersten

Erfahrungen zeigen, dass der Dienstleister gegenueber seinen Grosskunden kaum Chancen hat, die Subset-Struktur vorzugeben.

Aufgrund einer Verzoegerung bei der Fertigstellung der neuen Anwendung und der Zusage an den Pilotpartner, zu einem bestimmten Termin EDI-faehig zu sein, entstand die Notwendigkeit, fuer eine Uebergangszeit die EDI-Integration mit der alten Anwendung zu fahren. Dadurch wurden drei Dinge erforderlich, die entsprechenden Mehraufwand verursachten. Erstens musste das Mapping der Iftmin- Struktur auf ein User-File erfolgen, das den Konventionen des alten Datenmodells entsprach. Zweitens hatte der interne Datentransfer auf den alten Siemens-Rechner stattzufinden, und drittens war ein Uebernahmeprogramm zur alten Anwendung notwendig.

Zu diesem Zeitpunkt stand der Mailbox Manager nicht zur Verfuegung, so dass die Kommunikationssoftware direkt mit dem Konverter verknuepft wurde. Positiv zu sehen war allerdings, dass damit bereits ein Grossteil der technischen Komponenten des EDI- Prozesses getestet wurde.

Die Entscheidung, ein individuelles Steuerungsmodul fuer die Kommunikation zu programmieren, hatte folgende Gruende: Leider ist es heute noch praxisfern anzunehmen, alle Partner koennten ueber einen Netzwerkservice angeschlossen werden. Daher sind mehrere Kommunikationsverbindungen parallel zu managen. Der Mailbox Manager unterscheidet standardisierte und nicht standardisierte Datenstrukturen, erkennt Sender und Empfaenger und weiss, welcher Kommunikationsweg bedient werden muss.

Nach Fertigstellung des Moduls wurden alle vor- beziehungsweise nachgelagerten EDI-Bausteine wie X.25-Software oder Edifact- Konverter an den Manager angebunden.

Fazit: Unitrans hat erhebliche Investitionen in eine zukunftsorientierte, langfristig stabile Loesung getaetigt. Der Nutzen wird schrittweise durch sukzessive EDI-Anbindungen eingefahren und darf nicht schon von den ersten Projekten erwartet werden.

*Klaus Reichwein ist leitender Berater bei der LUW Software GmbH in Essen.

EDI-Verfahren bei Nedlloyd Unitrans