DE102006009430B3

DE102006009430B3 - Verfahren und Kommunikationsanordnung zur Datenübermittlung zwischen mindestens zwei Teilnehmern eines Transportgut- oder Personen-Tranportprozesses

Info

Publication number: DE102006009430B3
Application number: DE200610009430
Authority: DE
Inventors: Stefan Alexander Ganskow
Original assignee: ACT AVIAT CT OF TECHNOLOGY GMB; ACT AVIATION CENTRE OF TECHNOLOGY GmbH
Current assignee: ACT AVIAT CT OF TECHNOLOGY GMB; ACT AVIATION CENTRE OF TECHNOLOGY GmbH
Priority date: 2006-02-24
Filing date: 2006-02-24
Publication date: 2007-08-02
Anticipated expiration: 2026-02-25
Also published as: WO2007098930A1

Abstract

Die Erfindung betrifft ein Verfahren zur Datenübermittlung zwischen mindestens zwei Teilnehmern (10; 11; 13; 14; 20; 21; 23; 24; 30; 33; 34) eines Transportgut- oder Personen-Transportprozesses unter Verwendung mindestens eines Zentralrechners (Z, 50), wobei jedem Teilnehmer (10; 11; 13; 14; 20; 21; 23; 24; 30; 33; 34) ein lokaler Rechner (L) zugeordnet ist und in mindestens einem der lokalen Rechner (L) transportprozessrelevante Daten erfasst werden und wobei jeder lokale Rechner (L) mit dem Zentralrechner (Z, 50) kommunizieren kann, wobei ferner die Datenübermittlung zwischen jedem der Teilnehmer (10; 11; 13; 14; 20; 21; 23; 24; 30; 33; 34) und dem Zentralrechner (Z, 50) direkt, automatisiert und bidirektional erfolgt, wobei die transportprozessrelevanten Daten jedes Teilnehmers (10; 11; 13; 14; 20; 21; 23; 24; 30; 33; 34) über den Zentralrechner (Z, 50) jedem anderen Teilnehmer (10; 11; 13; 14; 20; 21; 23; 24; 30; 33; 34) zugänglich gemacht werden und wobei jeder der Teilnehmer (10; 11; 13; 14; 20; 21; 23; 24; 30; 33; 34) über die transportprozessrelevanten Daten jedes jeweils anderen Teilnehmers (10; 11; 13; 14; 20; 21; 23; 24; 30; 33; 34) während des Transportprozesses aktiv durch den Zentralrechner informiert wird. Die Erfindung betrifft ferner eine Kommunikationsanordnung zur Durchführung eines solchen Verfahrens.

Description

Die Erfindung betrifft ein Verfahren zur Datenübermittlung zwischen mindestens zwei Teilnehmern eines Transportgut- oder Personen-Transportprozesses gemäß dem Oberbegriff des Anspruchs 1 und eine Kommunikationsanordnung zur Durchführung eines solchen Verfahrens gemäß dem Oberbegriff des Anspruchs 9.

In der Logistikbranche sind seit langem verschiedene Kommunikationssysteme bekannt, die dazu eingesetzt werden, einen Transport eines Transportguts abzustimmen und zu verfolgen. Die bislang eingesetzten Kommunikationssysteme verwenden dazu unterschiedliche Kommunikationswege. So findet eine Übermittlung von Daten, die zum Transport eines Transportguts notwendig sind, beispielsweise per Telefon, Telefax oder durch direkte Übergabe entsprechender Schriftstücke mit der Sendung von einem Teilnehmer des Transportprozesses zu einem anderen Teilnehmer des Transportprozesses statt.

Die Verwendung unterschiedlicher Kommunikationsmittel hat den Nachteil, dass Daten, die das Transportgut betreffen, oft mehrfach während des gesamten Transportprozesses erfasst werden müssen. Damit geht sowohl ein hoher Arbeitsaufwand als auch eine Fehleranfälligkeit bei der Datenübermittlung einher.

Insbesondere im Luftfrachtbereich hat es sich als nachteilig erwiesen, dass eine Vielzahl von Papierformularen für einen Transportvorgang ausgefüllt werden müssen – im Durchschnitt sind 38 Dokumente pro Transportvorgang erforderlich.

Die IATA (International Air Transport Association) hat es sich daher unter dem Projektnamen „IATA e-freight" zur Aufgabe gemacht, bis zum Jahr 2010 eine papierlose Abwicklung des Lufttransports zu entwickeln. Bis dahin ist das klassische System aber noch weiterhin im Einsatz.

Aus der US 2005/0119926 A1 sind ein proaktives Logistik-Management-Verfahren und ein entsprechendes System bekannt. Dieses Verfahren und dieses System eignen sich zum Management automatisierten Gütertransports über internationale Grenzen hinweg.

Aus der WO 02/35382 A1 sind ein Verfahren, ein System und eine Software für internationalen elektronischen Handel bekannt, die jeweils Daten der zu handelnden bzw. zu transportierenden Waren verwalten und übertragen.

Die WO 01/75700 A2 beschreibt ein System und ein Verfahren zur Nachverfolgung von Containern sowie ein entsprechendes Logistik-Verfahren und -System.

Der vorliegenden Erfindung liegt die Aufgabe zugrunde, auf der Grundlage bestehender Transportguttransportsysteme ein Kommunikationssystem zu entwickeln, das die für einen Transport eines Transportguts oder einer Person notwendigen Vorgänge automatisiert abwickelt.

Diese Aufgabe wird durch ein Verfahren zur Datenübermittlung zwischen mindestens zwei Teilnehmern eines Transportgut- oder Personen-Transportprozesses gemäß Anspruch 1 und eine Kommunikationsanordnung zur Durchführung eines solchen Verfahrens gemäß Anspruch 9 gelöst.

In dem erfindungsgemäßen Transportprozess wird mindestens ein Zentralrechner eingesetzt und jedem Teilnehmer ein lokaler Rechner zugeordnet. In mindestens einem der lokalen Rechner werden transportprozessrelevante Daten erfasst. Die lokalen Rechner sind mit dem Zentralrechner derart verbunden, dass ein Datenaustausch zwischen den lokalen Rechnern und dem Zentralrechner stattfinden kann. Dieser Datenaustausch erfolgt erfindungsgemäß zwischen jedem Teilnehmer des Transportprozesses und dem Zentralrechner direkt, automatisiert und bidirektional, also sowohl von den lokalen Rechnern zum Zentralrechner hin als auch in umgekehrter Richtung. Dabei werden die transportprozessrelevanten Daten jedes Teilnehmers über den Zentralrechner jedem anderen Teilnehmer zugänglich gemacht und aktiv an jeden anderen Teilnehmer übermittelt, so dass allen Teilnehmern stets die gleichen Daten eines Transportprozesses auf ihren jeweiligen lokalen Rechnern zur Verfügung stehen.

Wenn die transportprozessrelevanten Daten im lokalen Rechner erfasst werden, erfolgt ein Abgleich dieser Daten mit Angaben, die über den Zentralrechner zur Verfügung gestellt werden, wobei der Zentralrechner zu diesem Zweck auf eine oder mehrere Datenbanken zugreifen kann. Dabei ist es nicht notwendig, während der Datenerfassung direkt auf den Zentralrechner zuzugreifen, da die Angaben, die im Zentralrechner gespeichert sind, regelmäßig auf die lokalen Rechner übermittelt werden. Durch eine solche Synchronisierung der lokalen Rechner mit dem Zentralrechner erfolgt der tatsächliche Abgleich zwischen den erfassten Daten und den gespeicherten Angaben also vorzugsweise direkt auf dem lokalen Rechner.

Um nur für den Transportprozess relevante Daten zu erfassen, erfolgt in Abhängigkeit der über den Zentralrechner zur Verfügung gestellten Angaben eine rechnergesteuerte Auswahl der zu erfassenden Daten. Somit können die Daten, die für einen Transportprozess vom lokalen Rechner „erfragt" werden, von Fall zu Fall je nach Art des Transportguts oder der Länder, in denen der Empfänger oder der Versender ansässig sind, variieren.

Statt die Daten an jeden anderen Teilnehmer zu senden, können die Daten alternativ auch nur an diejenigen Teilnehmer gesendet werden, die tatsächlich in der Transportkette stehen. Dadurch kann vermieden werden, dass Daten, die für einen bestimmten Teilnehmer keine besondere Bedeutung haben, seine Ressourcen belasten. Es kann dabei vorzugsweise für jeden Transportprozess bestimmt werden, welche Teilnehmer welche Informationen erhalten sollen, wobei zu dieser Bestimmung auf gespeicherte Vorzugswerte zurückgegriffen werden kann und die Bestimmung somit automatisch erfolgen kann.

Die Teilnehmer bzw. Beteiligten des Transportprozesses sind vorzugsweise Handlingsagenten, Export- oder Import-Spediteure, Versender einer zu transportierenden Sendung, Empfänger einer solchen Sendung, Zollbedienstete und/oder Transporteure. Dabei kommen als Transporteure insbesondere Fluggesellschaften in Betracht.

Das zu befördernde Transportgut sind vorzugsweise Waren und/oder Güter, so dass es sich bei dem betrachteten Transportprozess vorzugsweise um einen Frachttransportprozess handelt.

Um eine möglichst frühzeitige Information aller Beteiligten des Transportprozesses zu gewährleisten, die die Grundlage einer möglichst reibungsfreien Abwicklung des gesamten Prozesses ist, werden alle relevanten Beteiligten bevorzugt vor dem physikalischen Kontakt mit dem Transportgut bzw. der zu befördernden Person (Passagier) mittels des Zentralrechners über das abzufertigende Transportgut bzw. die abzufertigende Person informiert. Diese Information erfolgt am besten, sobald die Daten über das Transportgut bzw. den Passagier zum ersten Mal dem Zentralrechner übermittelt wurde, was in der Regel durch den Versender des Transportguts oder den Passagier bzw. einen Reisebüro-Angestellten beim Buchen eines Flugs erfolgt.

Zu einem Abgleich zwischen den erfassten Daten und den gespeicherten Angaben sind beispielsweise Angaben in Form von Informationen über den oder die Transportprozessteilnehmer (Adresse etc.), die Flug- oder Fahrpläne der Transporteure, gesetzliche und/oder zollamtliche Bestimmungen, internationale Abkommen (z. B. das GATT-Abkommen), Informationen über die zur Verfügung stehenden Transportmittel (z. B. Ladekapazität, Dimensionen des Laderaums etc.) und/oder Bestimmungen der Transporteure, welche mitunter einschränkend von den sonstigen Bestimmungen abweichen können, geeignet.

Durch den Angabenabgleich bei der Datenerfassung erfolgt vorteilhafterweise eine Überprüfung der eingegebenen Daten hinsichtlich ihrer Plausibilität. Werden falsche Daten bei der Erfassung in den lokalen Rechner eingegeben, wird der Teilnehmer, der die Daten eingibt, solange aufgefordert, die Fehler zu korrigieren, bis eine fehlerfreie Dateneingabe erfolgt ist. Erst nach Beseitigung aller Fehler gelten die Daten als erfolgreich erfasst und werden dem Zentralrechner übermittelt.

Um eine Dateneingabe und Datendarstellung in verschiedenen Sprachen zu ermöglichen, ist das Verfahren vorzugsweise so ausgestaltet, dass auf jedem lokalen Rechner eine Sprache aus einer Gruppe von mehreren Sprachen ausgewählt werden kann, in der die Dateneingabe und Datendarstellung erfolgt. Die Datenübermittlung selbst wird sprachunabhängig durch Referenzcodes ausgeführt. Somit kann beispielsweise der Versender transportprozessrelevante Daten auf Deutsch in seinen lokalen Rechner eingeben, diese werden dann sprachunabhängig codiert erst an den Zentralrechner und von dort unter anderem an den Empfänger übertragen, welcher die Daten auf seinem lokalen Rechner beispielsweise auf Französisch dargestellt bekommt.

Alternativ ist es auch möglich, dass das Verfahren mit nur einer möglichen Sprache durchgeführt wird.

Eine Kommunikationsanordnung zur Durchführung eines erfindungsgemäßen Verfahrens weist mehrere lokale Rechner und mindestens einen Zentralrechner auf. Jedem Teilnehmer des Transportprozesses ist dabei ein lokaler Rechner zugeordnet, wobei die lokalen Rechner und der Zentralrechner so in einem datenübermittelnden Netzwerk angeordnet sind, dass zwischen den lokalen Rechnern und dem Zentralrechner Daten übermittelt werden können.

Die lokalen Rechner sind als lokale Server ausgelegt und weisen nur einen beschränkten Funktionsumfang auf. Das heißt, sie können nur zur Durchführung eines erfindungsgemäßen Verfahrens notwendige Anwendungen ausführen. Dadurch werden unter anderem Kapazitäten geschont und Fehler, die durch die parallele Ausführung verschiedener Anwendungen infolge von Inkompatibilitäten auftreten können, vermieden.

Als datenübermittelndes Netzwerk kommt dabei vorzugsweise das Internet zur Anwendung. Aber auch andere Netzwerke wie beispielsweise das SITA-System eignen sich zur Datenübermittlung.

Für eine Anbindung der Teilnehmer an die lokalen Server werden letztere bevorzugt in ein bestehendes Serversystem eingebunden oder direkt mit einem gewöhnlichen Personalcomputer verbunden, der als Client fungiert. Der Client dient dann als Schnittstelle zwischen dem lokalen Server und dem Teilnehmer.

Sofern beispielsweise aus datenschutzrechtlichen Gründen eine physikalische Trennung von datenspeichernden Zentralrechnern erwünscht ist, wird die Kommunikationsanordnung bevorzugt so ausgestaltet, dass sich die Anzahl der Zentralrechner an der Anzahl der Transporteure, die in die Kommunikationsanordnung eingebunden sind, bemisst. Somit kann für jeden Transporteur ein eigener Zentralrechner bereitgestellt werden. Die jeweiligen Datenbanken, auf die die einzelnen Zentralrechner in einem solchen Fall zugreifen, werden untereinander synchronisiert, um für alle Zentralrechner eine gleiche Grunddatenbasis bereitzustellen.

Weitere Vorteile und Einzelheiten der Erfindung sollen anhand nachstehender Figuren erläutert werden. Es zeigen:
1 eine schematische Darstellung eines ersten im Stand der Technik bekannten Kommunikationssystems zwischen den Teilnehmern eines Transportprozesses;
2 eine schematische Darstellung eines zweiten im Stand der Technik bekannten Kommunikationssystems zwischen den Teilnehmern eines Transportprozesses, wobei das Kommunikationssystem einen Integrator aufweist;
3 eine schematische Darstellung eines dritten im Stand der Technik bekannten Kommunikationssystems zwischen den Teilnehmern eines Transportprozesses;
4 eine schematische Darstellung eines Kommunikationssystems gemäß der vorliegenden Erfindung; und
5 eine schematische Darstellung einer erfindungsgemäßen Kommunikationsanordnung.
Die 1 stellt als Stand der Technik ein schematisches Modell bekannter Kommunikationsabläufe im Luftfrachtbereich und in anderen Transportbranchen zur Übertragung von Daten dar. Zur Vereinfachung sind nur die wichtigsten Beteiligten an einer Logistikkette bzw. Teilnehmer eines Transportprozesses dargestellt.
Manuelle Kommunikationsschritte (m) sind mittels durchgezogener Linien dargestellt. Als „manuell" sollen dabei solche Kommunikationsschritte beschrieben werden, die nicht automatisiert zwischen den Teilnehmern an dem Transportprozess ablaufen, sondern jeweils eine Interaktion des Teilnehmers erfordern, der die Daten empfängt, um die übertragenen Daten in ein (zentrales) Datenaustauschsystem einzuspeisen. Dabei ist es unerheblich, ob zu diesem Kommunikationszweck Computer oder andere Kommunikationsgeräte, wie beispielsweise Telefone oder Faxgeräte, verwendet werden. Beispiele für solche manuellen Kommunikationsschritte sind Telefonanrufe, Faxübertragungen oder der Versand bzw. Empfang von E-Mails.
Online-Kommunikationsschritte (o) werden durch gestrichelte Linien repräsentiert. Als „online" sollen solche Kommunikationsschritte verstanden werden, die automatisiert zwischen den Teilnehmern an dem Transportprozess ablaufen, also keine Interaktion des datenempfangenden Teilnehmers erfordern, um die übertragenen Daten in ein (zentrales) Datenaustauschsystem einzuspeisen. Hierbei erfolgen die Kommunikation und die damit verbundene Datenübertragung vorzugsweise direkt mithilfe von Computern.
Kommunikationsschritte, die alternativ manuell oder online (m/o) erfolgen können, sind durch gepunktete Linien dargestellt. Die Pfeilspitze zeigen in allen Kommunikationsschritten die Richtung der Kommunikation an. Pfeilspitzen an beiden Enden von Verbindungslinien zeigen, dass die entsprechende Kommunikation bidirektional erfolgt.
Ein Transportprozess nach dem in der 1 dargestellten bekannten Kommunikationsablauf erfolgt gemäß den nachfolgenden Schritten, die anhand eines Beispiels dargelegt werden sollen. Dabei wird unterstellt, dass die größte Strecke des Transportwegs von einem Flugzeug bewältigt wird, eine zu transportierende Sendung also als Luftfrachtgut befördert wird. Alternativ könnte auch jedes andersartige Transportmittel (beispielsweise Eisenbahn oder Schiff) zum Einsatz kommen; die grundsätzlichen Transportabläufe ähneln sich.
Als erster Schritt in einem Transportprozess erteilt ein Versender 10 einem Exportspediteur 11 beispielsweise telefonisch einen Auftrag, eine Sendung vom Firmensitz in A abzuholen und einen Transport der Sendung zu einem Empfänger 20 in B zu organisieren.
Der Exportspediteur 11 ermittelt nun den von A nächstgelegenen bzw. am günstigsten zu erreichenden Startflughafen 12 und den von B nächstgelegenen bzw. am günstigsten zu erreichenden Zielflughafen 22. Anschließend ermittelt er eine Fluggesellschaft 30, die die gewünschte Transportleistung erbringen kann und bucht beispielsweise telefonisch oder per Fax einen entsprechenden Transport für die Sendung. Dabei ist es häufig der Fall, dass der Exportspediteur 11 nicht direkt mit der Fluggesellschaft 30, sondern mit einem Vertreter bzw. einem General Sales Agent (GSA) vor Ort kommuniziert (in 1 nicht dargestellt). Alternativ könnte der Exportspediteur 11 einen Transport für die Sendung auch über ein Internetportal der Fluggesellschaft 30 online buchen.
Nach erfolgreicher Buchung bei der Fluggesellschaft 30 übermittelt der Exportspediteur 11 dem Versender 10 per Fax, Telefon oder E-Mail eine Buchungsbestätigung.
Der Exportspediteur 11 füllt in der Regel einen Frachtbrief (air waybill, AWB) mit allen ihm zur Verfügung stehenden Daten über die zu transportierende Sendung aus, wobei er dazu meist einen Computer verwendet. Da nur sehr wenige Spediteure an das Telextransmission-System SITA (Societe Internationale de Telecommunications Aéronautiques) angeschlossen sind, mittels dessen die Daten des Frachtbriefes direkt an alle beteiligten Fluggesellschaften übertragen werden können, händigt der Exportspediteur 11 einen Ausdruck des Frachtbriefs einem Vertreter der Fluggesellschaft 30 auf dem Startflughafen 12 aus. Ein solcher Vertreter ist zumeist ein sog. Handlingsagent 13.
Eine Exportabfertigung des Frachtbriefes und der Sendung durch den Zoll 14 erfolgt in beinahe allen Ländern nach wie vor formulargestützt und nicht elektronisch, während eine Ausfuhrbestätigung oft bereits über computergestützte Systeme erfolgt. Hierbei kann der Handlingsagent 13 (eventuell auch der Exportspediteur) oder der Zoll 14 selbst die benötigten Daten über die Sendung erfassen.
Sind sowohl der Luftfrachtbrief als auch die eigentliche Sendung bei dem Handlingsagenten 13 eingetroffen, so ist es dessen Aufgabe, die Daten des Luftfrachtbriefes mittels eines Computersystems zu erfassen. Hierzu wurde in der Vergangenheit oft auf das Computersystem der Fluggesellschaften zurückgegriffen – vorausgesetzt die Fluggesellschaft 30 war im Besitz eines solchen Systems. Aus Gründen der Kostenreduzierung erwarten die Fluggesellschaften heutzutage allerdings, dass die Handlingsagenten 13, 23 eigene Systeme für die Datenerfassung bereithalten. Diese Computersysteme kommunizieren meist über SITA/EDI (Electronic Data Interchange) mit einem Rechner der beteiligten Fluggesellschaften 30, unabhängig davon, ob es sich um Systeme, die von einer Fluggesellschaft bereitgestellt werden, oder um eigene Systeme der Handlingsagenten 13, 23 handelt.
Aufgrund der zahlreichen unterschiedlichen derzeit eingesetzten Computersysteme muss ein Handlingsagent 13, 23 heutzutage eine Vielzahl von Computersystemen parallel betreiben, um mit möglichsten vielen Fluggesellschaften 30 zusammen arbeiten zu können.
Die Daten der Buchung und des Luftfrachtbriefes sind in dem Computersystem der Fluggesellschaft 30 intern weltweit abrufbereit und bearbeitbar. So können Handlingsagenten 33; 23 an einer Transitstation 32 und/oder am Zielflughafen 22 bereits bei der Buchung informiert werden, dass die entsprechende Sendung zu erwarten ist. Die in der Grafik dargestellte Transitstation 32 ist keine zwingend benötigte Station des erläuterten Transportprozesses. Sofern ein direkter Transport vom Start- 12 zum Zielflughafen 22 möglich ist, wird dieser in der Regel bevorzugt. Umgekehrt ist es auch denkbar, dass die Sendung über mehr als eine Transitstation 32 befördert wird; dies hängt von den jeweiligen Flugplänen der Fluggesellschaften 30 ab.
Eine Sendung, die auf einer Transitstation 32 ankommt, wird überprüft und ihre Ankunft im System bestätigt. Gleichzeitig oder anschließend wird die Sendung zum weiteren Transport freigegeben. Gegebenfalls wird die Sendung einem amtlichen Vorgang durch den Zoll 34 unterzogen. Alle Aktionen, die der Handlingsagent 33 an der Transitstation 32 ausführt, können von der Fluggesellschaft 30 über ihr Telexsystem SITA verfolgt werden, wenn der Handlingsagent 33 diese Aktionen über das SITA-System mitteilt.
Gelangt eine Sendung schließlich an ihren bestimmungsgemäßen Zielflughafen 22, bestätigt der Handlingagent 23 am Zielflughafen 22 der Fluggesellschaft 30 gegenüber elektronisch die ordnungsgemäße Ankunft der Sendung. Daraufhin informiert die Fluggesellschaft 30 einen Importspediteur 21 in der Regel manuell über die Ankunft der Sendung.
Eine Abfertigung durch den Zoll 24 und eine Kommunikation mit dem Empfänger 20 laufen nun äquivalent zu den eingangs beschriebenen Vorgängen beim Versender 10 ab, wobei die Reihenfolge genau umgekehrt ist. Die Sendung wird schließlich vom Importspediteur 21 an den Empfänger 20 ausgeliefert, der in der Regel zuvor nicht über die zu erwartende Sendung informiert wurde.
Bei einem derartigen Transport besteht auch die Möglichkeit eines Transfers der Sendung von einer Fluggesellschaft 30 zu einer anderen. Ein solcher Transfer kann aber nur dann elektronisch gestützt erfolgen, wenn beide Fluggesellschaften ein SITA/EDI-gestütztes Computersystem verwenden, welches in der Lage ist, „cargoIMP Messages" (ein in der Luftfahrt übliches Protokoll) zu verarbeiten.
Die mögliche weitere Kommunikation zwischen den genannten Teilnehmern an dem Transportprozess und weiteren denkbaren Beteiligten an diesem Prozess, wie etwa einem Fuhrunternehmen des Vorlaufes, einem General Sales Agent oder Vertretern anderer Transportmittel (LKW, Bahn usw.) ist in der 1 nicht durch entsprechende Linien dargestellt, da diese Kommunikation bei den bekannten Systemen in der Regel nur auf nicht elektronischem Wege stattfindet.
In der 2 sind die ebenfalls dem Stand der Technik zugehörenden Kommunikationsabläufe eines Transportprozesses unter Einbeziehung eines sog. Integrators schematisch dargestellt. Die Kommunikationsschritte können auf die in der Beschreibung zur 1 dargelegten Arten erfolgen; die Darstellung der verschiedenen Arten erfolgt analog zur 1. Teilnehmer des Transportprozesses, die bereits in der 1 aufgetreten sind, sind mit den gleichen Bezugszeichen versehen.
Als Integrator 40 werden Transportfirmen bezeichnet, die einen Transportauftrag integriert, das heißt ohne die notwendige Beteiligung weiterer Firmen durchführen.
Unter Bezugnahme auf die 1 und deren Beschreibung integriert ein Integrator 40 also den Export- und Importspediteur 11; 21, die Handlingsagenten 13; 23; 33 am Start- 12 und Zielflughafen 22 sowie an einer optionalen Transitstation 32, den Fuhrunternehmer des Vor- und Nachlaufes sowie zumeist auch die Fluggesellschaft 30 für den Luftfrachttransport selbst. Solche Integratoren sind beispielsweise die Firmen DHL, UPS und Fedex. Konzeptionell liegt das Integratorsystem zwischen dem System der Post und dem der Luftfracht. In der 2 sind all diejenigen Aufgaben, die der Integrator 40 übernimmt, bzw. die Funktionseinheiten, die der Integrator 40 integriert, innerhalb der mittig platzierten großen Ellipse angeordnet.
Zusätzlich zu den in der 1 als Export- und Importspediteur 11; 21 bezeichneten Teilnehmer des Transportprozesses können auch noch Transporteuren des Vor- und Nachlaufs an gleicher Stelle im Kommunikationsschema angeordnet sein. In diesem Fall würde man zusammenfassend von „Service" sprechen. Der Versender 10 und der Empfänger 20 kommen in einem Integrator-basierten Transportprozess nur mit diesem Service 11; 21 des Integrators 40 in Kontakt.
Die jeweilige Kommunikation zwischen den einzelnen Funktionseinheiten des Integrators 40 -erfolgt online über eine Luftfrachttransport-Koordination 41. Dazu verwenden die Integratoren 40 Computersysteme, welche alle internen Bereiche des Frachttransportes begleitend abbildet. Demgegenüber läuft die Kommunikation zwischen dem Integrator 40 und dem Versender 10 bzw. dem Empfänger 20 sowie zwischen dem Integrator 40 und dem Zoll 14; 24; 34 manuell oder online ab. Ein direkter Zugriff des Versenders 10, des Empfängers 20 oder des Zolls 14; 24; 34 auf die transportprozessrelevanten Daten des Integrators 40 ist bei diesem System nicht möglich.
In der 3 ist als weiterer Stand der Technik ein Kommunikationsmodell der so genannten E-Logistik schematisch dargestellt. Die Kommunikationsschritte können auf die in der Beschreibung zur 1 dargelegten Arten erfolgen; die Darstellung der verschiedenen Arten erfolgt analog zur 1. Teilnehmer des Transportprozesses, die bereits in der 1 aufgetreten sind, sind mit den gleichen Bezugszeichen versehen.
Unter E-Logistik versteht man im Allgemeinen den Versuch – parallel zum so genannten E-Business – einen Logistikprozess über das Internet abzubilden. Ein solcher Logistikprozess kann, wie in der 3 gezeigt, der Transport einer Sendung von einem Startflughafen 12 zu einem Zielflughafen 22 sein.
In der Praxis bedeutet dies, dass es Internetplattformen gibt, über die man Daten austauschen und bearbeiten kann.
Da es jedoch bei den E-Logistik-Lösungen keinen direkten Zugriff auf angebundene Server der Fluggesellschaften gibt, beschränken sich die Dienstleistungen der E-Logistik zurzeit im Wesentlichen auf Online-Buchungen und so genanntes tracking & tracing. Unter diesem Begriff versteht man die Abfrage des Status einer Sendung, also beispielsweise, an welchem Ort der Logistikkette sich eine Sendung gerade befindet. Dabei wird immer der letzte Ort, an der die Sendung erfasst wurde, angegeben.
Wie die 3 zeigt, können sowohl der Versender 10 und/oder der Empfänger 20 als auch der Export- und/oder der Importspediteur 11; 21 eine Statusabfrage zum Zwecke des tracking & tracing oder eine Buchungsanfrage an einen Web-Server 35 senden, der diese Anfrage dann weiter an die Fluggesellschaft 30 leitet. In seltenen Fällen können die zuvor genannten Teilnehmer des Transportprozesses weiterführende Arbeiten wie etwa das Ausfüllen eines Frachtbriefes vornehmen. Die Kommunikation geht nur in eine Richtung: Vom jeweiligen Teilnehmer 10; 11; 20; 21 zum Web-Server 35. Die Teilnehmer 10; 11; 20; 21 sind nicht aktiv in ein Netzwerk mit eingebunden, sondern können nur auf dem Web-Server 35 hinterlegte Daten einsehen.
In der 4 ist ein Kommunikationssystem gemäß der vorliegenden Erfindung schematisch dargestellt. Die Kommunikationsschritte können auf die in der Beschreibung zur 1 dargelegten Arten erfolgen; die Darstellung der verschiedenen Arten erfolgt analog zur 1. Teilnehmer des Transportprozesses, die bereits in der 1 aufgetreten sind, sind mit den gleichen Bezugszeichen versehen.
Kernstück dieses Systems ist ein so genanntes BATCH-System, das aus einem zentralen Rechner 50 und mehreren lokalen Rechnern besteht, wobei jeder Teilnehmer des Transportprozesses mindestens einen lokalen Rechner besitzt. Das System ist für alle Teilnehmer eines Luftfrachtmarktes bestimmt. Die Konzeption basiert auf einer Komplettlösung in Bezug auf die informationstechnische Bearbeitung der Sendungen für die Versender 10, Empfänger 20, Export- und Importspediteure 11; 21, Handlingsagenten 13; 23, Fluggesellschaften 30 und alle weiteren damit zusammenhängenden Transportträger wie Frachtführer des Vor- und Nachlaufs etc. Darüber hinaus ist die Übertragung von Informationen an die relevanten Behörden – wie etwa den Zoll 14; 24; 34 – ein wichtiges Element der Funktionalität.
Im Unterschied zu den zuvor in den 1 bis 3 aufgezeigten Lösungen, welche heutzutage im Einsatz sind, ermöglicht das BATCH-System es, alle relevanten Teilnehmer 10; 11; 13; 14; 20; 21; 23; 24; 30; 33; 34 eines Transportprozesses in einem Netzwerk zu vereinen, wobei eine aktive Kommunikation zwischen den einzelnen Teilnehmern 10; 11; 13; 14; 20; 21; 23; 24; 30; 33; 34 über einen zentralen Server 50 abläuft. Somit bietet das BATCH-System den Fluggesellschaften die Möglichkeit, eine Antwort auf das in der 2 dargestellte Logistikkonzept der Integratoren zu geben, indem alle Arbeitsprozesse über das BATCH-System vollständig integriert werden können. Darüber hinaus schließt das BATCH-System auch den Versender 10 und den Empfänger 20 mit in das Netzwerk ein.
In der 4 sind wiederum nur die relevanten Teilnehmer 10; 11; 13; 14; 20; 21; 23; 24; 30; 33; 34 an dem Transportprozesses wiedergegeben. Weitere denkbare Teilnehmer, wie etwa Fuhrunternehmen oder General Sales Agents wurden der Übersichtlichkeit halber ebenso wenig dargestellt wie der Einsatz anderer Transportmittel (Bahn, Schiff etc.), obwohl ihre Teilnahme an dem Prozess bzw. ihr Einsatz grundsätzlich möglich ist.
Hat ein Versender 10 einen Transportauftrag zu vergeben, dann übermittelt er diesen mit allen relevanten Daten zu der zu transportierenden Sendung elektronisch an den zentralen Rechner 50 des BATCH-Systems. Von dort aus wird er an den zuständigen Exportspediteur 11 weitergeleitet. Der Empfänger 20 kann bereits bei der Buchungsanfrage mit in den neuen Transportprozess einbezogen werden.
Mit dem Transportauftrag wird eine Buchungsanfrage an eine geeignete Fluggesellschaft 30 übermittelt. Nachdem die Buchung erfolgreich abgeschlossen wurde, werden alle Teilnehmer des Transportprozesses, also jeder Teilnehmer, der mit der physischen Sendung zu tun haben wird – wie beispielsweise die Handlingsagenten 13; 33; 23 des Startflughafens 12, der optionalen Transitstation 32 und des Zielflughafens 22, die Fluggesellschaften 30 im Transfer und der Importspediteur 21 – vorab über die zu transportierende Sendung informiert so genanntes „preadvise".
Der Exportspediteur 11 ergänzt den Luftfrachtbrief zu dessen Vervollständigung um seine Daten zu der zu transportierenden Sendung. Die so geänderten Daten werden über den Server 50 des BATCH-Systems allen Beteiligten mitgeteilt. Der Handlingsagent 11 des Startflughafens 12 erwartet nun die physische Sendung. Erhält er diese, wird er in seinem Warehouse System einen Check-In der Sendung durchführen, woraufhin das BATCH-System die Daten der Buchung mit denen des Frachtbriefes und dem Lagerbestand vergleicht. Bei eindeutiger Datenlage gibt das BATCH-System die Fracht zum Transport frei. Durch die somit jederzeit intern bekannte Datenlage kann auf den optionalen Transitstationen 32 und auf dem Zielflughafen 22 die Sendung unmittelbar nach der physischen Ankunft zur Auslieferung freigegeben („released") werden.
In Ländern, in denen der Zoll 14; 24; 34 eine Vorverzollung aufgrund der Datenlage zulässt, kann das BATCH-System auch diesen Service ermöglichen. „BATCH" im Sinne des Wortes bedeutet eine elektronische Umsetzung einer Stapelverarbeitung. Das heißt, dass alle Dokumente eines Transportauftrages elektronisch im BATCH-System abgebildet werden. So sind auch Lieferscheine und Rechnungen des Versenders 10 sowie Dokumente zur Zollabfertigung Teil dieser Stapelverarbeitung und des BATCH-Systems.
Dokumente, die für einen speziellen Transportprozess benötigt werden, wie etwa für den Transport von Gefahrengut oder von lebendigen Tieren, werden im BATCH-System über einzelne Module bereitgestellt und elektronisch dem entsprechenden Transportprozess zugewiesen.
Wie aus 4 zu sehen ist, findet die Kommunikation zwischen allen Teilnehmern 10; 11; 13; 14; 20; 21; 23; 24; 30; 33; 34 und dem zentralen Server 50 bidirektional statt. Anders als bei der E-Logistik-Lösung, die in 3 dargestellt wurde, wird beim BATCH-System dem Benutzer aktiv der Status einer bestimmten – ihn betreffenden – Sendung mitgeteilt. Der Benutzer muss somit nicht selbst tätig werden, um beispielsweise ein tracking & tracing auszuführen. Er ist vielmehr während der Dauer eines Transportprozesses Teil des Netzwerkes.
Die 5 zeigt eine schematische Darstellung einer erfindungsgemäßen Kommunikationsanordnung. Eine Übermittlung von Daten bzw. Angaben AÜ, welche in einer Datenbank gespeichert sind und von dort abgerufen werden können, ist durch durchgezogene Linien gekennzeichnet. Eine Übermittlung von Daten bzw. Informationen IÜ, welche einen Transport einer Sendung betreffen, ist durch gestrichelte Linien gekennzeichnet.
Grundsätzlich weist eine solche Kommunikationsanordnung mindestens eine anwenderseitige oder lokale Substruktur L, die die Funktion eines lokalen Rechners hat, und mindestens eine serverseitige oder zentrale Substruktur Z, die die Funktion eines Zentralrechners hat, auf. Der lokalen Substruktur L sind ein oder mehrere lokale Clients 60 zugeordnet.
Ausgehend von den lokalen Clients 60, auf denen lokale Applikationen ausgeführt werden, findet eine Angabenübermittlung AÜ bei einer solchen Kommunikationsanordnung von und zu einer lokalen Datenbank 62 und einer Konfigurationsdatenbank 63 über einen Applikationsserver 61 statt. Auf die lokale Datenbank 62 und die Konfigurationsdatenbank 63 hat darüber hinaus ein lokales Kommunikationsmanagement 64 direkten Zugriff, das eine Angaben- und Informationsübermittlung AÜ; IÜ von und zu einem datenübermittelnden Netzwerk 65 handhabt. Ein solches Netzwerk kann beispielsweise das Internet oder ein aus Telekommunikationsverbindungen im Rahmen des SITA-Systems oder des PSTN (Public Switched Telephony Network) aufgebautes Netzwerk sein.
Für eine direkte Informationsübermittlung IÜ zwischen dem Applikationsserver 61 und dem lokalen Kommunikationsmanagement 64 sorgen Kommunikationsschnittstellen 66a, 66b, die dem Applikationsserver 61 bzw. dem lokalen Kommunikationsmanagement 64 zugeordnet sind.
Daten bzw. Informationen oder Angaben, die nicht direkt vom lokalen Kommunikationsmanagement an das datenübermittelnde Netzwerk 65 bzw. die lokalen Clients 60, die lokale Datenbank 62 oder die Konfigurationsdatenbank 63 übermittelt werden können, werden in einer dem lokalen Kommunikationsmanagement 64 zugeordneten Warteschlange 641 zwischengespeichert.
In der zentralen Substruktur regelt ein dem lokalen Kommunikationsmanagement 64 äquivalentes zentrales Kommunikationsmanagement 67 den Datenfluss von und zum datenübermittelnden Netzwerk 65. Daten, die vom zentralen Kommunikationsmanagement 67 nicht direkt weitergeleitet werden können, werden in einer Warteschleife 671 des zentralen Kommunikationsmanagements 67 zwischengespeichert. Vom zentralen Kommunikationsmanagement 67 können Angaben direkt an eine Authentifizierungsdatenbank 68 übermittelt werden. In dieser Authentifizierungsdatenbank 68 sind unter anderem Daten hinterlegt, die es ermöglichen, vom datenübermittelnden Netzwerk 65 eintreffende Angaben oder Informationen dahingehend zu überprüfen, ob sie von einem berechtigten Anwender stammen und ob somit eine Weiterleitung solcher Angaben oder Informationen vom zentralen Kommunikationsmanagement 67 an eine Server-Applikation 69 erfolgen soll.
Wie in der lokalen Substruktur L findet eine Kommunikation zwischen dem zentralen Kommunikationsmanagement 67 und der Server-Applikation 69 über Kommunikationsschnittstellen 66c, 66d statt, die dem zentralen Kommunikationsmanagement 67 bzw. der Server-Applikation 69 zugeordnet sind.
Von der Server-Applikation 69 können Angaben von und zu einer zentralen Datenbankschnittstelle 70 übermittelt werden. Diese Datenbankschnittstelle 70 sorgt für Ansteuerung mindestens einer zentralen Datenbank 71, auf der transportprozessrelevante Daten wie beispielsweise Flugpläne oder Informationen über internationale Vorschriften hinterlegt sind.
Mittels einer derart ausgestalteten Kommunikationsanordnung können also Daten von den lokalen Clients 60 an die zentrale Server-Applikation 69 gesandt, über die zentralen Datenbanken 71 abgeglichen und ergänzt um weitere Daten aus den zentralen Datenbanken 71 wieder zurück an die lokalen Rechner 60 übermittelt werden. Mithin erfolgt eine Datenübermittlung zwischen einem lokalen Rechner L und einem zentralen Rechner Z. Dabei ist es im Rahmen der vorliegenden Erfindung zweckmäßig, dass die Kommunikationsanordnung nicht nur eine, sondern mehrere lokale Substrukturen bzw. Rechner L aufweist, beispielsweise für jeden Teilnehmer des Transportprozesses eine. Auch können mehrere zentrale Substrukturen bzw. Zentralrechner Z – beispielsweise für jeden Transporteur eine – eingesetzt werden. Die Anzahl der lokalen Rechner L wird die Anzahl der zentralen Rechner Z in der Regel weit übertreffen.
Weitere vorteilhafte Ausgestaltungen des erfindungsgemäßen Verfahrens und der erfindungsgemäßen Kommunikationsanordnung sollen anhand von Anwendungsbeispielen des in der 4 erläuterten BATCH-Systems dargestellt werden:
Beispiel 1
In diesem Beispiel soll die im Vergleich mit dem Stand der Technik effektivere und kostengünstige Konzeption des BATCH-Systems hinsichtlich einer vereinfachten Abbildung des Arbeitsablaufs beschrieben werden.
Das BATCH-System reduziert komplexe Prozesse an den jeweils möglichen Stellen auf wenige, dem Arbeitsablauf entsprechende Schlüsselformate. Zudem wird das BATCH-System in Modulen bereitgestellt, wobei jeder Anwender des BATCH-Systems nur diejenigen Programmteile erhält, die von ihm zu seinen Arbeitsablauf notwendig sind.
So wird im BATCH-System beispielsweise ein Luftfrachtbrief (AWB), der von der IATA (International Air Transport Association) und der ICAO (International Civil Aviation Authorities) hinsichtlich des Informationsgehalts bezüglich der Sendung an sich, ihres Transports und der Haftungsregularien entwickelt worden ist, integriert und informationstechnisch dargestellt.
Aber auch andere, in der Luftfrachtindustrie bereits verwendete und etablierte Formulare werden durch das BATCH-System elektronisch dargestellt sowie zur elektronischen Datenerfassung und papierlosen Bearbeitung bereitgestellt, so dass nennenswerte Einarbeitungszeiten für die Einführung des BATCH-Systems nicht erforderlich sind.
Ein Mitarbeiter eines Logistikunternehmens (Spedition, Handlingsgesellschaft, Exportabteilung eines Versenders) findet als Anwender des BATCH-Systems bei der ersten Benutzung des BATCH-Systems die gleichen Formulare vor, die er bislang manuell bearbeitet hat. So wird einem Versender beispielsweise ein so genannter Shippers Letter of Instruction (SLI), einem der Mitarbeiter einer Spedition beispielsweise der Luftfrachtbrief (AWB) und einem Mitarbeiter eines Luftfrachthandlungsunternehmen beispielsweise ein so genanntes Manifest durch das BATCH-System angezeigt. Das jeweilige Formular liegt nicht verschlüsselt vor, sondern kann unmittelbar in elektronischer Fassung ausgefüllt werden.
Der jeweilige Anwender sieht das entsprechende elektronische Formular in originalgetreuer Wiedergabe vor sich, so wie er das Papierformular von der manuellen Bearbeitung her kennt. In späteren Arbeitsstufen kann der Anwender in einer Vielzahl von Fällen das BATCH-System für sich arbeiten lassen und wird beim Ausfüllen der Formulare von einer oder von mehreren systeminternen Datenbanken) unterstützt, wie im nächsten Beispiel dargelegt wird.
Beispiel 2
Ein Großteil der Daten, die für die Vervollständigung der Transportdokumente (beispielsweise des Luftfrachtbriefs) benötigt werden, ist im BATCH-System bereits integriert. Der Anwender kann diese Daten dann ausschließlich von der oder den BATCH-internen Datenbanken) abfragen, aber nicht beliebig ergänzen. Dadurch wird eine sehr hohe Reproduzierbarkeit hinsichtlich der Daten, die in die entsprechenden Formulare eingetragen werden, erreicht.
Möchte beispielsweise ein Berliner Versender eine Sendung mit einem Gewicht von 1000 kg, wobei der Inhalt dieser Sendung Insekten sind, nach Mexiko verschicken, so öffnet er auf seinem Modul des BATCH-Systems einen SLI (Shippers Letter of Instruction). Das Feld „Versender" ist bereits mit seinen Daten ausgefüllt, da das BATCH-System ihn als Benutzer erkennt.
Das Feld „Empfänger" kann er nun von Hand oder unter Zugriff auf die entsprechenden Empfängerdaten aus der Datenbank ausfüllen. In der Datenbank sind dabei all diejenigen Empfänger, welche mit dem jeweiligen Versender zusammenarbeiten, hinterlegt.
Der Versuch, die Sendung vom Empfänger bezahlen zu lassen, scheitert, da in der Datenbank Informationen hinterlegt sind, dass lebendige Tiere ebenso wenig wie Waren allgemein nach Mexiko auf der Basis „Charges Collect" (Empfänger bezahlt) versendet werden dürfen. Somit zwingt das BATCH-System den Versender, diesen Fehler zu korrigieren. Bevor der Fehler nicht korrigiert wurde, kann der SLI nicht vollständig ausgefüllt werden, so dass ein entsprechender Transportauftrag nicht vom BATCH-System angenommen wird.
Weiterhin werden vom BATCH-System nur Buchungsanfragen zu solchen Flügen akzeptiert, bei denen Flugzeuge zum Einsatz kommen, welche in der Lage sind, lebende Tiere zu transportieren und dabei einer Belastung des Bodens mit Gewichten von mindestens 1000 kg standhalten.
Das BATCH-System wird nun dem Anwender Informationen bereitstellen, die er dokumentarisch berücksichtigen muss, etwa Quarantänevorschriften in einem etwaigen Transitland oder in Mexiko selbst. Ferner erhält der Anwender Informationen darüber, ob die beteiligten Handlingsagenten spezielle Räumlichkeiten und Lagermöglichkeiten für Tiere besitzen. Zudem wird eine Vorabmitteilung („preadvise") über den durchzuführenden Transport automatisch an die gewünschte Fluggesellschaft gesandt.
Das BATCH-System prüft auch noch zahlreiche weitere Daten, so dass der eigentliche Transportvorgang schließlich schnell und ohne vermeidbare Komplikationen abgewickelt werden kann.
Die gute Datenlage hilft zudem, aus der Datenbank des BATCH-Systems den optimalen Tarif für die Sendung herauszusuchen. Darüber hinaus werden die für den Transport lebendiger Tiere (AVI) notwendigen und die den Bestimmungen des Allgemeinen Zoll- und Handelsabkommens (GATT) entsprechenden Formulare sowie die für den Export und Import benötigten Zolldokumente bereitgestellt und vorgefertigt, so dass diese später nur noch mit wenigen Handgriffen ergänzt werden müssen.
Beispiel 3
Neben der zuvor dargestellten Minimierung der Eingabefehler bei Verwendung des BATCH-Systems soll im Folgenden die Sprachunabhängigkeit an einem Beispiel erläutert werden.
Die Verkehrssprache der Luftfracht ist Englisch. Allerdings ist bereits jetzt der Trend zu beobachten, dass viele Mitarbeiter im Handling nicht ausreichend gut Englisch sprechen, um beispielsweise Manuals lesen zu können. Die Manuals sind jedoch Teil des Datenbankbestandes des BATCH-Systems. Um Sprachbarrieren abzubauen, erlaubt das BATCH-System daher die Dateneingabe in verschiedenen Sprachen. Gibt ein Anwender als Inhalt seiner Sendung beispielsweise „Benzin" an, gleicht das BATCH-System dieses Wort mit den in der Datenbank hinterlegten Angaben ab, wobei die Datenbanken über einen Schlüssel referenziert werden (übliches Vorgehen für Datenbanken). Der Schlüssel kann mit Begriffen in jeder beliebigen Sprache verbunden sein.
Der Schlüssel 12 00 0036 ist beispielsweise im Englischen mit dem Begriff „gas" referenziert (verknüpft), im Deutschen hingegen mit „Benzin" und im Chinesischen mit „shen liu". Bei der Datenübertragung selbst ist dabei nur der Schlüssel relevant. Die Angabe des Sendungsinhalts „Benzin" im Deutschen, den der Anwender in ein Formular des BATCH-Systems eingegeben hat, erscheint bei einem Empfänger in Mexiko mit der sprachlich gewünschten (spanischen) Wortwahl im gleichen Formular auf dessen lokalem Rechner. Somit kann jeder Anwender des BATCH-Systems die ihm vertraute Sprache benutzen. Dies vermindert den Lernaufwand für den einzelnen Anwender erheblich und hilft, Fehler beim Ausfüllen der benötigten Formulare zu vermeiden.
Gibt der Anwender den Sendungsinhalt mit „Benzin" an, erkennt das BATCH-System darüber hinaus, dass es sich bei der zu transportierenden Sendung um ein Gefahrgut handelt. Der Benutzer kann die Sendung nur dann abschicken, wenn er die notwendigen DGR-Formulare (Dangerous Goods – Gefahrgut) ausfüllt und dem Vorgang (elektronisch) anhängt. Hierbei unterstützt das BATCH-System den Anwender, da es die meisten Daten, die zum Ausfüllen des Formulars benötigt werden, aus der Datenbank heraussucht und bereits in die entsprechenden Formularfelder einträgt.
Beispiel 4
Das folgende Beispiel soll eine Optimierung des Personalbedarfs, die durch den Einsatz des BATCH-Systems erreicht werden kann, erläutern.
Bedingt durch die Tatsache, dass das BATCH-System in einem (globalen) Netzwerk angeordnet ist, welches alle Anwender informationstechnisch miteinander verbindet, steht die Gesamtdatenlage allen Beteiligten jederzeit zur Verfügung. Dabei gibt es lediglich individuell einstellbare Restriktionen bezügliche des erlaubten Datenzugriffs durch den jeweiligen Anwender seitens des BATCH-Systems, um persönliche oder firmeninterne Daten der jeweiligen Anwender zu schützen und einen unberechtigten Zugriff anderer Anwender auf diese Daten zu verhindern (vgl. Beispiel 9).
Das BATCH-System ermöglicht seinen Kunden, auf bereits in das globale Netzwerk eingegebene Daten wiederholt zuzugreifen. Während nach den Kommunikationssystemlösungen aus dem Stand der Technik Daten häufig mehrfach in lokale, voneinander isolierte Computersysteme eingegeben werden, kann beim BATCH-System die mehrfache Bearbeitung gleicher Daten ausgeschlossen werden. Gemäß dem Stand der Technik übermittelt ein Versender die für einen Luftfrachttransport notwendigen Daten beispielsweise per Fax zu seinem Spediteur, dieser übernimmt die Daten manuell in sein Speditionssystem, druckt den Luftfrachtbrief aus und übergibt diesen dem Handlingsagenten, welcher die Daten sodann erneut in sein internes Computersystem überträgt.
So hat ein Versender beispielsweise folgende Daten in den SLI (Shippers Letter of Instruction) eingetragen: einen Versender, einen Empfänger, einen Startflughafen, einen Zielflughafen, eventuelle Transitstationen, einen gewünschten Spediteur, eine gewünschte Fluggesellschaft, einen Abflugtag, einen Buchungsvorschlag, die Maße der Sendung, das Volumen der Sendung, das Gewicht der Sendung, den Inhalt der Sendung, Angaben über die Art der Zahlung, Angaben über den Wert der Sendung, Angaben über den Zollstatus, Angaben über die Notwendigkeiten des Handlings und des Accountings.
Das sind bereits mehr als 85 % der Angaben, die der beauftragte Spediteur in den Luftfrachtbrief übertragen muss. Da die Daten nun bereits im BATCH-System vorhanden sind, muss der Spediteur lediglich seine Angaben ergänzen und den Gesamtvorgang noch einmal überprüfen.
Der Spediteur versendet dann über das Netzwerk nur noch die geänderten Daten. Der Handlingsagent kann bei Verwendung des BATCH-Systems sogar – ohne die bei ihm eintreffenden Formulare zu öffnen oder zu bearbeiten – mit Drag & Drop arbeiten, solange die Daten des Transportprozesses in sich konsistent sind (das heißt, wenn die Angaben des eingegangenen Luftfrachtbriefs mit der gewünschten Buchung und seinem Lagerbestand übereinstimmen).
Gleiches gilt für die Teilnehmer des Transportprozesses, die an den Transitstationen und dem Zielflughafen arbeiten. Alle weiteren Formulare, die eventuell benötigt werden, können auf der Grundlage der vorhanden Daten stark vereinfacht und daher schnell und effizient ausgefüllt bzw. um die fehlenden Daten ergänzt werden.
Das BATCH-System garantiert somit eine Optimierung des Einsatzes der Mitarbeiter.
Beispiel 5
Das folgende Beispiel soll die automatische Fehlerprävention durch das BATCH-System näher beschreiben.
Das BATCH-System enthält Datenbanken mit fluggesellschaftspezifischen Informationen wie Flugplänen (schedules) und internen Regelungen (Embargos, Inkassoregelungen etc.), mittels derer ein Anwender des BATCH-Systems durch das System über die Anforderungen der jeweiligen Fluggesellschaft und auch über internationale Vorschriften informiert wird. Ferner erfolgt ein Abgleich der von dem Anwender in das System eingegeben Daten mit den hinterlegten Angaben bzw. eine Kontrolle auf der Grundlage dieser Angaben.
Auch können die eingegebenen Daten gegebenenfalls auf der Grundlage der hinterlegten Angaben korrigiert werden. Ferner ist eine gezielte Steuerung des Eingabeprozesses auf der Grundlage der hinterlegten Daten denkbar und dazu vorgesehen, tatsächlich alle für einen individuellen Transportprozess relevanten und benötigten Daten zu erfassen. Es ist dabei sehr wichtig, dass Fehler weitgehend ausgeschlossen werden, um die Effizienz der Bearbeitung zu steigern und auch Schäden – wie beispielsweise Zollschäden, Planungsfehler, Konventionalstrafen etc. – zu vermeiden.
Wenn eine Fluggesellschaft beispielsweise einen Flughafen außerplanmäßig nicht mehr anfliegt (zum Beispiel wegen der dort vorherrschenden politischen Lage), dann würde die Fluggesellschaft nach einem Kommunikationssystem des Stands der Technik alle Flughäfen weltweit über diese Flugplanänderung per Telex informieren. Nun ist es denkbar, dass ein Mitarbeiter an einem beliebigen Flughafen dieses Telex achtlos beiseite legte oder aufgrund von Sprachschwierigkeiten dessen Inhalt nicht vollständig korrekt erfasste. Dadurch würden weiterhin Sendungen, die den nun nicht mehr angeflogenen Flughafen als Zielflughafen haben, angenommen und zum Transithub (dem Hauptsitz der Fluggesellschaft) transportiert. Dort würde ein Lager schnell an seine Kapazitätsgrenzen stoßen, da die Sendungen nicht mehr weiter transportiert werden könnten.
Bei Verwendung des BATCH-Systems werden solche Probleme umgangen, da die systemeigenen Datenbanken stets zentral auf dem aktuellen Stand gehalten werden (vgl. Beispiel 8)
Beispiel 6
Das folgende Beispiel soll eine Optimierung des Arbeitsablaufes bei Verwendung des BATCH-Systems erläutern.
In den Datenbanken des BATCH-Systems sind vorzugsweise sämtliche relevanten Daten der Fluggesellschaften wie beispielsweise Buchungsinformationen, Kapazitätsmöglichkeiten der Flugzeuge und auch Planungsvorschläge zur bestgeeigneten Kapazitätsauslastung hinterlegt. Somit versetzt das BATCH-System den Anwender in die Lage, immer an der Grenze des Bestmöglichen zu arbeiten. Das Resultat dieser Optimierung ist eine bessere Ausnutzung der Kapazitäten (also beispielsweise der Kapazitäten des Frachtraumes eines Flugzeuges oder des Lagerraums an einer von mehreren möglichen Transitstationen) sowie eine schnellere Bearbeitung der Vorgänge (die Mitarbeiter müssen nicht mehr in Manuals nachlesen).
Das BATCH-System überprüft alle eingegeben Daten durch einen Abgleich mit den hinterlegten Angaben und nimmt notwendige Umrechnungen (etwa zwischen verschiedenen Währungen oder Maßeinheiten) sowie die Berechnung des Volumens einer Sendung auf der Grundlage der eingegeben Daten hinsichtlich der Maße der Sendung unmittelbar bei oder nach der Eingabe automatisch vor. Somit ist stets eine sichere Datenlage über die zu transportierenden Sendungen vorhanden. Damit ist das BATCH-System in der Lage, den jeweiligen beteiligte Fluggesellschaften eine optimierte Ausnutzung der Frachträume der Flugzeuge zu ermöglichen, wodurch die Fluggesellschaften den so genannten Loadfaktor optimieren können.
Das BATCH-System berücksichtigt auch die Maße der zu transportierenden Sendung bei der Auswahl der möglichen Flugverbindungen, um so zu gewährleisten, dass dem Anwender nur solche Flugzeuge für den Transport der Sendung angeboten werden, die eine den Maßen der Sendung entsprechend ausreichend große Tür bzw. Laderaumluke aufweisen, um die Sendung aufnehmen zu können.
Bei Kommunikationssystemen nach dem Stand der Technik sind die Angaben beispielsweise des Volumens einer Sendung oft abgeschätzt und werden in der Regel nicht mehr kontrolliert, so dass sich starke Abweichungen zwischen der Buchung und der tatsächlich zu befördernden Sendungen ergeben können.
Bedingt durch die Tatsache, dass über das Volumen auch abgerechnet wird, kann einer Fluggesellschaft über einen großen Zeitraum (beispielsweise ein Jahr) ein erheblicher Verlust durch die Angabe zu geringer Volumina der zu transportierenden Sendungen entstehen. Andererseits sind Frachträume oft fälschlicherweise ausgebucht, weil aufgrund falscher (zu hoher) Volumenangaben das maximal mögliche Volumen eines Flugs bereits erreicht ist, obwohl noch Kapazitäten vorhanden wären. Und schließlich kann eine falsche Datenlage zur Folge haben, dass Sendungen nicht transportiert werden können, da die Transportkapazität bereits frühzeitig erschöpft ist, was nicht rechtzeitig erkannt werden konnte, da die Kommunikationssysteme des Stands der Technik keine Kontrolle über die korrekten Kapazitäten zulassen.
Beispiel 7
Das folgende Beispiel soll verschiedene mögliche Kommunikationswege des BATCH-Systems näher beschreiben.
Ein großer Vorteil des BATCH-Systems ist es, dass ein Anwender das von ihm bevorzugte Medium für die Datenübertragung frei wählen kann. Das BATCH-System vermag praktisch mittels sämtlicher bekannter Übertragungsmedien zu kommunizieren. Um die Kommunikationskosten niedrig zu halten, ist das BATCH-System vorzugsweise mit einem internen Kommunikationsmanagement, welches die Daten über das Internet versendet, ausgerüstet. Bei der Datenübertragung über das Internet werden die marktüblichen Standards der höchsten Datensicherheit gewahrt.
Hat ein Handlingsagent eine zu transportierende Sendung bereits verladen, müssen die Daten spätestens unmittelbar nach dem Abflug des Flugzeuges dem Zentralrechner übermittelt werden. Ist der Startflughafen beispielsweise Berlin und soll eine Sendung nach Mexiko transportiert werden, so muss diese Sendung auf einem europäischen Flughafen umgeladen werden, wenn eine Fluggesellschaft gewählt wurde, die nicht direkt von Berlin nach Mexiko fliegt. In diesem Fall bleiben nur ca. 2 bis 3 Stunden, bis das Frachtgut in der Transitstation angekommen ist. Spätestens zu diesem Zeitpunkt müssen die Daten ebenfalls vor Ort sein.
Daher vertraut das BATCH-System nicht auf einen Kommunikationsweg, sondern gestattet Alternativen.
So kann der Handlingsagent in dem vorstehenden Beispielfall beim Ausfall des Internets seine Daten auch über ein Faxmodem oder einen Telfonkoppler etc. versenden. Ein Einsatz des SITA-Systems wäre ebenso denkbar. Allein der guten Verfügbarkeit und der günstigen Kosten-Nutzen Relation wegen wird das Internet als bevorzugtes Kommunikationsmedium für das BATCH-System betrachtet.
Beispiel 8
Das nachfolgende Beispiel erläutert den so genannten Software Service des BATCH-Systems.
Unter Software Service wird hier die Bereitstellung von Programmaktualisierungen (updates) verstanden. Um einen permanent reibungslosen Ablauf des weltweit einsetzbaren BATCH-Systems zu gewährleisten, kann mittels einer Fernwartung auf einen lokalen Rechner jedes Anwenders zugegriffen werden (remote trouble shooting). Darüber hinaus werden den Anwendern Aktualisierungen der systeminternen Datenbanken über das BATCH-System übermittelt und in das lokale System integriert, so dass alle Anwender des BATCH-Systems stets auf dem neuesten Systemstand sind.
Wie im vorherigen Beispiel 7 dargelegt, bleibt für die Datenübertragung oft nur wenig Zeit. Deshalb ist es insbesondere wichtig, dass einem Anwender sofort geholfen werden kann, wenn das BATCH-System nicht erwartungsgemäß funktionieren sollte.
Die neueste Datenlage ist dabei ein wichtiger Faktor im BATCH-System und ist vor allem für die Vermeidung von Fehlern relevant (vgl. hierzu das Beispiel 2).
Beispiel 9
Das nachfolgende Beispiel soll die strukturellen Komponenten einer erfindungsgemäßen Kommunikationsanordnung am Beispiel des BATCH-Systems näher erläutern.
Zur Anwendung des BATCH-Systems werden ein Zentralrechner und ein oder bevorzugt mehrere lokale Rechner eingesetzt. Die Aufgabe des Zentralrechners wird dabei von einem Netzwerkserver mit entsprechender Kommunikationsmanagement-Anbindung übernommen. Die Kommunikationsmanagement-Anbindung kann dabei vielschichtig ausgestaltet sein, um den Anwendern eine breite Auswahl von Kommunikationswegen zur Verfügung zu stellen (z. B. Datenübertragung über das Internet, über das Telexsystem SITA etc.).
Die Aufgabe des lokalen Rechners wird von einer Hardwarekomponente übernommen, welche als lokaler Server eingesetzt wird. Diese als „black box" bezeichnete Hardwarekomponente kann ein Anwender einfach an sein bestehendes Serversystem anschließen. Verfügt ein Anwender über kein eigenes Serversystem, kann er auch bestehende Client-PCs direkt an die black box anschließen. Die black box stellt ein reduziertes Serversystem dar, welches neben Anwendungen des BATCH-Systems keine weiteren Dienste ausführen kann. Aus diesem eingeschränkten Funktionsumfang resultieren mehrere Vorteile:

1. Es besteht die Möglichkeit, eine Fernwartung (remote trouble shooting, s. Beispiel 8) anzubieten, ohne dass die Gefahr eines unberechtigten Eingriffs auf weitere Server eines Anwenders befürchtet werden muss.
2. Kein Anwender kann über die black box artfremde Anwendungen wie etwa Surfen im Internet, Spiele etc. durchführen.
3. Höchste Sicherheitskonzepte auch physischer Natur können an dem Server (der black box) umgesetzt werden.
4. Durch ein einheitliches Rechnersystem ist auch eine einfache Kommunikation mit allen Anwendern möglich, um beispielsweise Aktualisierungen (updates) zu laden.
5. Die black box kann sich selbst bei Schwierigkeiten mit dem Zentralrechner verbinden (z. B. über cron-Tabellen) und aufgetretene Fehler melden (beispielsweise, dass die Festplattenkapazität bzw. die Kapazität eines anderen verwendeten Speichers wie beispielsweise eines Flashspeichers der black box zu 70 % aufgelastet ist, was ein Anzeichen für eine Fehlfunktion der Speicherung wäre).

Da die black box vorkonfiguriert werden kann, können Installationsprobleme vermieden und auch ein einfacher Austausch der black box ermöglicht werden.
Mehrere lokale Server (black boxes) kommunizieren mit dem Zentralrechner (zentraler Server), dem Herzstück des BATCH-Systems. Das bevorzugte Kommunikationsmedium zwischen den lokalen und dem zentralen Server ist das Internet.
Für jede Fluggesellschaft, die das BATCH-System einsetzt, wird aus datenschutzrechtlichen Gründen ein eigener zentraler Server eingerichtet. So kann die Möglichkeit der Einsichtnahme in die Daten einer konkurrierenden Fluggesellschaft ausgeschlossen werden. Sofern mehrere Fluggesellschaften zu einem Kooperationsnetzwerk wie beispielsweise der Star Alliance zusammen geschlossen sind, ist es auch denkbar, dass lediglich ein Server für alle Fluggesellschaften, die Partner in solch einem Netzwerk sind, zum Einsatz kommt. Dies hängt von den jeweiligen Datenschutzanforderungen der beteiligten Fluggesellschaften ab und hat keinen Einfluss auf die Funktionalität des BATCH-Systems.
Ein derartiges datenschutzrechtliches Trennungsprinzip gilt auch für den Einsatz der black box. Dabei findet bevorzugt allerdings keine physische Trennung zwischen unterschiedlichen Fluggesellschaften statt, wie sie bei der Organisation über mehrere Server vorliegt. Vielmehr wird für jede Fluggesellschaft ein eigener, passwortgeschützter Desktop auf Seiten des oder der mit der black box verbundenen Client-PCs zur Verfügung gestellt (Multiple Desktop System).
Für einen Anwender des BATCH-Systems wäre es allerdings am vorteilhaftesten, wenn er ausgehend von einem Desktop auf einem PC mit den Servern verschiedener Fluggesellschaften kommunizieren könnte. Eine solchermaßen vereinfachte Kommunikation ist mit dem BATCH-System ohne weiteres möglich. Ob sie auch tatsächlich angewendet wird, hängt von den Wünschen und Anforderungen der jeweiligen Fluggesellschaften ab.
Bei besonders rigiden Datenschutzanforderungen ist es darüber hinaus auch denkbar, dass ein Anwender (z. B. ein Handlingsagent) mehrere black boxes – beispielsweise eine für jeden individuellen zentralen Server einer Fluggesellschaft – verwendet. Diese Lösung wird aber eher als unvorteilhaft angesehen, da sie mit deutlich höherem Installations- und Wartungsaufwand auf Seiten der lokalen Server verbunden ist.
Das BATCH-System ist plattformunabhängig und somit unter allen gängigen Betriebssystemen einsetzbar. Zum Einsatz kommen aktuelle Softwarestandards, wie z. B. ein Datenaustausch im XML-Format mittels Applicationservices. Im Datenbankbereich werden sowohl etablierte Systeme marktführender Firmen als auch Softwaresysteme aus dem so genannten Open-Source-Bereich verwendet.

Claims

Verfahren zur Datenübermittlung zwischen mindestens zwei Teilnehmern eines Transportgut- oder Personen-Transportprozesses unter Verwendung mindestens eines Zentralrechners, wobei jedem Teilnehmer ein lokaler Rechner zugeordnet ist und in mindestens einem der lokalen Rechner transportprozessrelevante Daten erfasst werden, wobei jeder lokale Rechner mit dem Zentralrechner kommunizieren kann, wobei die Datenübermittlung zwischen jedem der Teilnehmer (10; 11; 13; 14; 20; 21; 23; 24; 30; 33; 34) und dem Zentralrechner (Z, 50) direkt, automatisiert und bidirektional erfolgt, wobei die transportprozessrelevanten Daten jedes Teilnehmers (10; 11; 13; 14; 20; 21; 23; 24; 30; 33; 34) über den Zentralrechner (Z, 50) jedem anderen Teilnehmer (10; 11; 13; 14; 20; 21; 23; 24; 30; 33; 34) zugänglich gemacht werden und wobei jeder der Teilnehmer (10; 11; 13; 14; 20; 21; 23; 24; 30; 33; 34) über die transportprozessrelevanten Daten jedes jeweils anderen Teilnehmers (10; 11; 13; 14; 20; 21; 23; 24; 30; 33; 34) während des Transportprozesses aktiv durch den Zentralrechner informiert wird, dadurch gekennzeichnet, dass bei der Erfassung der Daten im lokalen Rechner (L) jeweils ein Abgleich dieser Daten mit über den Zentralrechner (Z, 50) zur Verfügung gestellten Angaben erfolgt und in Abhängigkeit der über den Zentralrechner (Z, 50) zur Verfügung gestellten Angaben nur die Daten erfasst werden, die für den jeweiligen Transportprozess benötigt werden.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Teilnehmer Handlingsagenten (13; 33; 23), Spediteure (11; 21), Versender (10), Zollbedienstete (14; 24; 34), Transporteure (30) und/oder Empfänger (20) sind.
Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass der Transporteur (30) eine Fluggesellschaft ist.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass in dem Transportprozess befördertes Transportgut Waren bzw. Güter sind.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass eine Mehrzahl von Teilnehmern (10; 11; 13; 14; 20; 21; 23; 24; 30; 33; 34) bereits vor dem physikalischen Kontakt mit dem Transportgut durch den Zentralrechner (Z, 50) über das zu bearbeitende Transportgut informiert wird, sobald die Daten über das Transportgut zum ersten Mal dem Zentralrechner (Z, 50) übermittelt werden, wobei diese erste Übermittlung insbesondere durch den Versender (10) des Transportguts erfolgt.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Angaben Informationen über den oder die Teilnehmer (10; 11; 13; 14; 20; 21; 23; 24; 30; 33; 34), die Flug- oder Fahrpläne der Transporteure (30), gesetzliche und/oder zollamtliche Bestimmungen, internationale Abkommen, Informationen über die zur Verfügung stehenden Transportmittel und/oder Bestimmungen der Transporteure (30) umfassen.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass bei der Datenerfassung durch den Angabenabgleich eine logische Überprüfung der Daten erfolgt und der Teilnehmer (10; 11; 13; 14; 20; 21; 23; 24; 30; 33; 34) aufgefordert wird, zu einem erfolgreichen Abschluss der Datenerfassung ggf. aufgetretene Fehler zu korrigieren.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Datenerfassung bei jedem Teilnehmer (10; 11; 13; 14; 20; 21; 23; 24; 30; 33; 34) in mindestens einer von mehreren Sprachen erfolgen kann, die Datenübermittlung unabhängig von der mindestens einen bei der Datenerfassung ausgewählten Sprache erfolgt und die Daten bei jedem der anderen Teilnehmer (10; 11; 13; 14; 20; 21; 23; 24; 30; 33; 34) in mindestens einer von mehreren Sprachen dargestellt werden, wobei die jeweils verwendete Sprache für jeden Teilnehmer (10; 11; 13; 14; 20; 21; 23; 24; 30; 33; 34) individuell auswählbar ist.
Kommunikationsanordnung zur Durchführung eines Verfahrens nach einem der vorhergehenden Ansprüche, wobei die Kommunikationsanordnung eine Mehrzahl von lokalen Rechnern (L) und mindestens einen Zentralrechner (Z, 50) aufweist, wobei jedem Teilnehmer (10; 11; 13; 14; 20; 21; 23; 24; 30; 33; 34) des Transportprozesses ein lokaler Rechner (L) zugeordnet ist und wobei der Zentralrechner (Z, 50) und die lokalen Rechner (L) derart miteinander in einem datenübermittelnden Netzwerk (65) angeordnet sind, dass Daten zwischen den einzelnen lokalen Rechnern (L) und dem Zentralrechner (Z, 50) übermittelt werden können, dadurch gekennzeichnet, dass die lokalen Rechner (L) als lokale Server ausgestaltet sind, die einen eingeschränkten Funktionsumfang aufweisen und die im Wesentlichen nur solche Anwendungen ausführen, die zur Durchführung eines Verfahrens nach einem der Ansprüche 1 bis 8 notwendig sind.
Kommunikationsanordnung nach Anspruch 9, dadurch gekennzeichnet, dass die Kommunikationsanordnung derart ausgestaltet ist, dass sie das Internet als datenübermittelndes Netzwerk (65) verwendet.
Kommunikationsanordnung nach Anspruch 9 oder 10, dadurch gekennzeichnet, dass die lokalen Server (L) in ein bestehendes Serversystem eingebunden sind oder direkt mit mindestens einem Personalcomputer (60), welcher die Funktion eines Clients ausübt, verbunden sind.
Kommunikationsanordnung nach einem der Ansprüche 9 bis 11, dadurch gekennzeichnet, dass die Anzahl der eingesetzten Zentralrechner (Z, 50) der Anzahl der Transporteure (30), die die Kommunikationsanordnung verwenden, entspricht.