Mit Ing.-grad. Arnfrid Teichmann, EDV-Koordinator der Flughafen Frankfurt/Main AG, sprach Elmar Elmauer
- Nach Vorstellungen der Flughafen AG Frankfurt will die Airport Data Processing Commission, ADC, in der International Civil Airport Association (ICAA) den Frachtumschlag im Luftverkehr weltweit beschleunigen. Herr Teichmann, Sie sind EDV-Koordinator der FAG und Chairman der ADC: Wo gibt's die Umschlag-Probleme und wie kann die EDV sie lösen?
Eine sehr umfangreiche Studie der IATA Anfang der Siebziger hat ergeben, daß Luftfracht in der Regel sechs Tage und sechs Stunden zwischen Absender und Empfänger unterwegs ist. Während dieser Spanne wird die Luftfracht nur zu 22 Prozent dieser Zeit bewegt - der Rest, also 78 Prozent, ist Verweilzeit. Diese hohe Verweilzeit entsteht aus verschiedenen Gründen. Teilweise sind Ressourcen nicht verfügbar, ist Equipment nicht verfügbar und so entsteht Verweilzeit aufgrund unterschiedlicher Dienstpläne, die es wegen der unterschiedlichen Zeitregion gibt. Der dritte Grund für die hohe Verweilzeit ist: Es gibt keine oder nur mangelhafte oder falsche Information. Und mangelhafte und falsche Information verursachen etwa 46 Prozent der Gesamttransportzeit von sechs Tagen und sechs Stunden. Diese 46 Prozent wollen wir angehen, um eine Beschleunigung zu erreichen.
- Und nie wollen Sie das anpacken?
Wir haben hier in Frankfurt zunächst eine Studie durchgeführt, die uns in Zusammenarbeit mit der CSID, einem auf solche Aufgaben spezialisierten und erfahrenen Unternehmen, drei Zeitmonate mit etwa anderthalb Mann gekostet hat. Ziel der Studie war, den Istzustand der EDV-Erschließung bei den einzelnen Luftfrachtpartnern der FAG festzustellen; dann wurde ermittelt, was beabsichtigen die einzelnen Partner in nächster Zeit, und die dritte Aufgabe beinhaltet schon eine gewisse Zielsetzung, in dem wir die Partner gefragt haben, wie stehen sie zur Frage einer gemeinsamen Lösung?
- Und wie stehen sie?
Wir haben bei allen Partnern offene Türen eingerannt. Keiner hat sein Veto eingelegt und gesagt, es geht nicht, oder, wir wollen nicht. Obgleich gemeinsame Lösung ja heißt: EDV dort gemeinsam treiben, wo ein einzelner die Aufgaben nicht bewältigen kann. Dies ist vor allem die Frage des Übergangs der Frachtdaten von einem Partner zum anderen.
- Dies scheint eine kernige Aufgabe zu sein, die Sie da bewältigen wollen: Denn bei allen Ihren Partnern besteht EDV - Sie müssen, also quasi integrierte Systeme weltweit im Distributed Processing verbinden?
Ich bin hundertprozentig mit der Formulierung einverstanden, die Sie für diese Aufgabe geprägt haben. Denn tatsächlich ist diese Integration nicht mehr auf der Hardware-Ebene abzubilden, sondern sie bewegt sich von und ganz im organisatorischen Bereich. Wir haben also ein System zu entwickeln, das aus dem analytischen Bereich und nicht aus dem Hardware-Bereich kommt. Und vonwegen weltweit: Wir brauchen nicht ein weltweites Distributed Processing, sondern viele Frankfurter-Lösungen als weltweiten Standard. Dabei ist für uns die Hardware-Lösung heute eigentlich eine sekundäre Frage geworden.
- Umdenken auf der ganzen Front?
Wenn ich an die 60er und 70er Jahre zurückdenke, und daran, was man damals unter integrierten Systemen verstand, dann war das automatisch eine Hardware-integrierte Lösung oder der Versuch einer Hardware-Integration, die eigentlich kaum irgendwo gelungen ist.
- Ist das besser geworden? Findet heute Integration, so wie Sie sich die vorstellen, statt?
Ich meine ja. Hardware und die ganze, Informatiktechnologie haben sich so weit entwickelt, daß wir diese Integration von verschiedenen Abläufen her tatsächlich bewältigen können. Etwa, indem wir dezentrale Hardware oder eben Distributed Processing mit all den Netzwerk-Problemen und Hierarchien tatsächlich bewältigen. Dies ist eine ganz entscheidende Entwicklung.
- Aber auch die EDV-Koordinatoren der PAG mußten den Umgang mit verteilter Intelligenz erst lernen?
Wir haben Anfang der 70er Jahre hier am Flughafen ein EDV-System in Betrieb genommen, das eigentlich schon eine Vorphase des Distributed Processing war. Nehmen Sie unser Flughafeninformations-System. Das besteht zwar aus einem Hauptrechner, der verschiedene Aufgaben zentral bearbeitet, doch für eine Reihe anderer Aufgaben sind Untersysteme eingesetzt, etwa beim Autophonsystem mit den Anzeigentafeln zur Fluggastführung, die über einen Krantz-Rechner eingestellt werden, wobei dieser Rechner in direkter Verbindung mit dem Siemens 4.451 in der Zentrale steht.
- Aber Priorität haben die Aufgaben im Zentralrechner?
Es wird langsam problematisch, zu unterscheiden, welche Aufgabe jetzt Priorität hat. Der Siemens-Rechner hat im Realtime-Bereich dreiviertel Megabyte, die Standby-Anlage, die nur im Crashfall eingesetzt wird und sonst mit Verwaltungsaufgaben belastet ist, hat ein Megabyte. Die Realtime-Anlage wird noch im BS1000 gefahren, die Standby-Anlage im BS2000. Und durch die Vielzahl der Sichtgeräte, die an der Standby-Anlage hängen und in den Verwaltungsfachbereichen stehen, würde ein Ausfall ebenfalls schlimme Folgen haben. Aber natürlich ist nach wie vor die Priorität so geregelt, daß der Flughafenbetrieb Vorrang hat.
- Okay, Ihr Beispiel mag für ein handgestricktes Distributed Processing stehen. Aber können Sie denn heute diese Anforderungen der verteilten Intelligenz umsetzen, wenn zugleich bei den Partnern der EDV-Einsatz im Fließen ist?
Es wird bestimmt erhebliche Anstrengungen kosten. Und das Schlimme ist, daß wir hier nicht nur gelöste Probleme von alter in neue Technologie umsetzen müssen, sondern gleichzeitig neue Anforderungen zu erfüllen haben. Wir müssen mit dem Frachtthema einen ganz neuen Komplex aufreißen, den wir aber im Bereich des Flugplanes wieder koppeln müssen. Es darf auf einem Flughafen nur einen Flugplan geben, denn wenn unterschiedliche Flugpläne in unterschiedlichen Hardwaresystemen erzeugt werden, entstehen automatisch
Abweichungen. Sei es durch Fehler des Systems oder bei der Eingabe.
- Lassen Sie mich eine hypothetische Frage stellen: Sie setzen nun alles daran, bestehende Systeme zu koppeln, von denen sicherlich einige nicht mehr auf aktuellem Stand sind. Und zumeist bestimmt das schwächste Glied die Stärke einer Kette. Wäre es nicht einfacher, alles einzureisen und das ganze Problemfeld mit einem völlig neuen System zu überziehen?
Ich behaupte, es ist nicht möglich, ein bestehendes System rauszuwerfen. Das geht nicht und das ging nicht und das wird nie gehen. Ich meine, wir sind ein Paradebeispiel dafür, wie man mit unterschiedlichen Systemen leben muß. Wir können gar nicht anders, weil die Vielfalt von Problemen, die es auf einem Flughafen zu bewältigen gibt, nicht innerhalb eines einzigen Systems abgewickelt werden können. Dies wäre auch völlig unwirtschaftlich.
- Aber nun werden Sie ja doch vieles zusammenfassen müssen, neue Hierarchien und Zuordnungen schaffen.
Ja, wir werden bestehende Aufgaben zusammenfassen. Und ich bin überzeugt, daß wir verschiedene Aufgaben innerhalb eines Systems abwickeln können, wenn wir dies nur vernünftig aufbauen.
Dies heißt: Wir müssen die Systeme modular aufbauen, sodaß wir Teile, die nicht direkt miteinander zu tun haben, völlig losgelöst voneinander herausnehmen und hineinnehmen können. Die : Koppelung dürfte es lediglich durch das Betriebssystem geben.
- Doch hier stoßen Sie leicht an die Grenzen des Betriebssystems?
Ja, und deshalb ist so ein Gedanke unterschiedliche Probleme in einem System abzuarbeiten, auch wenn er als die bessere Lösung erscheint, in unserem Fall nicht machbar. Denn wir können unmöglich die Autophontafel direkt im Hauptrechner einstellen lassen und dazu das Gepäcktransportsystem vom Zentralrechner aus steuern. Das muß ein separates System sein. Dies haben wir auch von Anfang an so realisiert. Sicher haben wir auch einige Aufgaben im Hauptrechner liegen, nicht so modular wie nötig, eben handgestrickt: Da gibt es natürlich aus heutiger Sicht fehlerhafte Entwicklungen, die aber damals vielleicht nicht anders machbar waren.
- Nun wollen Sie nicht nur die unmittelbaren Flughafen-Belange koppeln. Sie wollen ja alle Luftfrachtpartner zusammenfuhren. Und keiner von denen hat seine EDV nur für die Franchtbelange konzipiert.
Wir müssen dies tun, weil wir eine Beschleunigung im Luftfracht-System nur noch erreichen, wenn wir über die einzeln entwickelten Lösungen hinausgehen. Denn innerhalb der individuellen Lösung gibt es, wenn jeder seine Abläufe mit EDV realisiert hat, keine Verbesserung mehr. Also müssen wir den Übergang der Daten von einem System ins andere zuwege bringen.
- Welche Systeme meinen Sie da?
Nehmen Sie einen normalen Frachtablauf, etwa bei den Farbwerken Hoechst. Die geben den Auftrag an ihren Spediteur nicht standardisiert, sondern nach den eigenen Vorstellungen. Also kommt der Hoechst-EDV-Output zum Spediteur, der setzt sich an seine EDV und macht einen hundertprozentigen Input und schreibt, wenn's gut geht, einen Luftfrachtbrief per EDV. Der geht zur Luftverkehrsgesellschaft, und was macht die: Die nimmt den Output des Spediteurs und macht einen neuen manuellen Input für sich und dann gibt sie ein Frachtmanifest oder einen Loadplan an den nächsten Beteiligten, zum Beispiel die FAG für die Beladung der Flugzeuge. Wieder als Papier-Output und als Input bei der FAG. Das ist doch ein unmöglicher Zustand. Ein Luftfrachtbrief wird bis zu neunzigmal benötigt - und Jedesmal werden die Daten neu eingegeben, das ist doch ein Irrsinn, ganz abgesehen von den Fehlermöglichkeiten, die
dabei entstehen.
- Haben Sie schon Vorstellungen, wie diese Übergänge zu bewältigen wären?
Hier gibt es gewisse Modellvorstellungen, für die die Begriffe switch und bureau verwendet werden. Switch meint dabei eindeutig den Übergang wie ich es eben beschrieben habe, also Übergabe der Daten von einem Partner zum anderen, und dazu kommt dann die Bürofunktion. Es gibt so kleine Airlinere für die rentiert sich hier in Frankfurt keine eigene EDV. Also übernehmen wir zur Switch-Funktion hier in Frankfurt auch das Abarbeiten von Verwaltungsaufgaben.
- Denken Sie an Hardware-Untersysteme für die "Bureau-Funktion"?
Da fragen Sie mich im Moment zuviel. Wir haben bisher nur die Grundkonzeption, aus der Hardware-Frage haben wir uns noch ganz herausgehalten.
- Herr Teichmann, nun gilt immer noch die Grundsatzaussage, der Hersteller, volle Kompatibilität zwischen Systemen verschiedener Mainframer werde es nie geben. Sie werden also immer Schnittstellenprobleme zwischen Subsystemen und Zentrale und den fremden Systemen der Partner haben. Was lassen Sie sich hier einfallen?
Schnittstellenprobleme sind wenn man an die V.24 denkt, eigentlich gelöst Was für uns noch nicht gelöst ist, ist das Protokollproblem. Hier gibt es Ansätze, die aber noch nicht über alle Bereiche anwendbar wären. Aber diesen Punkt möchte ich mal aus einem anderen Aspekt anschneiden Wir sind natürlich bemüht, für eine solche Gemeinschaftsaufgabe im Fernverarbeitungsbereich Bundesmittel zu beantragen. Und obwohl das dritte DV-Förderprogramm der Bundesregierung ausläuft gibt es berechtigte Hoffnungen hier etwas Unterstützung zu erhalten. Diese Forderung erhalten wir nur, wenn wir herstellerneutrale Lösungen anvisieren Nun ist die Aussage der Hersteller, Kompatibilität wird nicht kommen. aus deren Sicht allzu verständlich. Die Frage ist nur ob wir Anwender uns länger diesem Diktat unterwerfen müssen und dürfen Ich bin der Ansicht, es ist allerhöchste Zeit, daß wir Anwender uns zusammentun und von diesem Diktat freimachen. Es ist doch einfach nicht hinzunehmen, daß Anwender ihre Software umschreiben müssen, nur weil ein Hersteller oder verschiedene Hersteller neue Hardware produzieren. Dies ist nicht akzeptabel, Ich muß doch eine organisatorische Lösung so lange in meinem Haus laufen lassen, wie diese Anforderung aus dem Fachbereich besteht. Ich kann nicht, weil ein Hersteller neue Hardware entwickelt und neue Software-Auflagen macht, meine bisherige Software gleich auf Null abschreiben. Gerade heute, da die Hardware-Kosten Nebensache werden und die Software- Kosten immer gewichtiger werden, müssen wir aus diesem Teufelskreis ausbrechen.
- Nur ändert dieser Zorn nichts daran, daß Sie doch erstmal Ihre Partner auf technisch gleichen Level bringen müssen. Wissen Sie schon, wo bestehende Elemente rausfliegen?
Ich möchte gerade dieses Risiko minimieren. Aber sicherlich sind heute einige noch in Betrieb befindliche Systeme in vier Jahren nicht mehr in Betrieb. Die Lufthansa sagt beispielsweise selbst zu ihrem jetzigen System "Zwischenlösung" und man hört, daß die Lufthansa-Großlösung eine Univac-Lösung sein wird Wenn wir den Spediteurbereich nehmen, dann gibt es zum Beispiel bei der Impex ein Datasaab-System, das sehr früh entwickelt wurde und zu der Zeit, als es inszeniert wurde, hervorragend gearbeitet hat. Doch heute ist das hoffnungslos veraltet. Das wird mit Sicherheit aus dem Verkehr genommen. Oder wenn Sie das Alphasystem des Zolls nehmen. Hier hat das Bundesfinanzministerium auf die erhebliche Kritik grundlegende Änderungen zugesagt Da ist also einiges im Fluß.
- Und bis wann wollen Sie all das realisiert haben?
Das "Partner-auf-den-gleichen-Nenner-bringen" und die Entwicklung weltweiter Standards, das sind zwei Funktionen, die völlig parallel laufen können. Ich glaube. man kann in zwei Jahren weltweite Standards realisieren und für die lokale Lösung wurde ich drei, wahrscheinlich vier Jahre ansetzen.
- Herr Teichmann, drei, vier Jahre technologischer Fortschritt: Wird Ihre Lösung dann noch so aussehen, wie Sie sie heute planen?
Wir gehen von den Anforderungen der Anwender aus. Wir haben die Frage der Technologie bewußt offengelassen. Ich hielte es für falsch, erst diese Frage und dann die Anwenderprobleme zu klären. Wir wissen nur eines: Wir werden jede Künstlerlösung verbieten und ganz systematisch Software-Engineering betreiben.
- Und was wird das alles kosten?
Die Frage mußte ja kommen, doch sie ist sehr schwer zu beantworten. Wenn wir uns nur die Switch-Funktion vorstellen und davon ausgehen, daß wir einen Doppelrechner vielleicht im Multiprozessor-Mode fahren, dann deckt das ja nur die Hardwareseite ab, die sich im unteren Bereich einer Großanlage bewegt. Die Software-Aufwendungen dürften sich im Bereich zwischen 50 und 100 Mann-Jahren bewegen, Diese Schätzung wurde ich mal ganz vorsichtig in den Raum stellen.