Die Leerzeiten schieben den Break Even Point hinaus

02.09.1977

Mit Jürgen Dube, Geschäftsführer der BIK GmbH, Frankfurt, sprachen die CW-Redakteure Dieter Eckbauer und Elmar Elmauer

- Mit mehr als der üblichen Verspätung ist jetzt das internationale SWIFT-Netz auch für den Anschluß der deutschen SWIFT-Mitgliedsbanken bereit, die sich am 29. August angeschlossen haben. Woraus resultiert die Verzögerung von vierzehn Monaten?

Die ersten Banken wurden von SWIFT nicht wie ursprünglich geplant am 15. Juni 1976, sondern am 8. Mai 1977 angeschlossen. Die Gründe dafür sind bei der Entwicklung der Systeme durch die Hersteller zu sehen, die verschiedentlich ihre zeitlichen Vorstellungen nicht realisieren konnten. Die Banken sind dagegen mit den organisatorischen Vorbereitungen, soweit sie die ohne Hardware und ohne Kenntnis der Software und der Anwendungspakete durchführen konnten, früher fertig gewesen.

- Hat es bei der Zusammenarbeit zwischen den Banken, den Herstellern und dem SWIFT-Entwicklungsteam Schwierigkeiten gegeben?

Das muß man in zwei Bereichen sehen. Einmal gibt es eine Gruppe von Banken, die die von SWIFT bei den Herstellern in Auftrag gegebene Hard- und Software (in den sogenannten SWIFT Interface Devices [SID] realisiert) einsetzen. Die haben eigentlich nicht direkt mit den Herstellern zu tun gehabt. Das hat SWIFT gemacht. SWIFT hat auch die Software geprüft und freigegeben, wozu man sagen muß, daß es für mindestens einen, Hersteller immer noch keine endgültig akzeptierte SID-Software gibt.

- Demnach wird auch über den Starttermin hinaus noch getestet?

Das ist gar nicht verwunderlich bei einem so umfangreichen System. Was wir gebraucht hätten und noch brauchen, bevor wir mit der vollen Last von unserer Seite auf das System gehen, ist ein Test unter echten Bedingungen, mit langsam steigender realistischen Mengen. Das werden wir jetzt erst im echten Betrieb machen können.

- Nun gibt es Banken, die sich - wie das BIK - entschlossen haben, die empfohlenen SIDs nicht einzusetzen. Ist das im Sinne der "SWIFT-Erfinder"?

Die SWIFT-Projektgruppe hatte sich auf die Entwicklung des zentralen Message-Switching-Systems zu konzentrieren und aus dieser Entwicklung den Banken Richtlinien vorzugeben, die auch in SWIFT-Standards festgelegt worden sind. Es mußte jedoch jeder Mitgliedbank freigestellt sein, sich unter Einhaltung dieser Normen in irgendeiner Weise an das Netz anzuschließen.

- Zugegeben. Doch schließlich sind die SWIFT-Experten bei der Auswahl der SIDs davon ausgegangen, daß diese Geräte den Anforderungen am besten entsprechen.

SWIFT hat nur gesagt, wir empfehlen den Anschluß mit einem SID, hat aber nicht von vornherein gesagt, ihr dürft keine andere Lösung wählen, weil das eine Verzögerung des Systems bedeutet. Die Tatsache, daß verschiedene Banken eine andere als die SWIFT-Lösung gefunden haben, hat in keiner Weise zur Verzögerung der Entwicklung des SWIFT-Projektes beigetragen. Denn diese Banken haben auf ihrer Seite der Schnittstelle entwickelt und SWIFT auf seiner Seite. Das hätte allenfalls dazu führen können, daß das eine oder andere Anschlußsystem nicht fertig geworden wäre, aber nicht das Message-Switching-System.

- Hat es dazu geführt?

Es scheint so, daß sich nicht in allen Fällen die gesteckten Ziele realisieren ließen. Das trifft sowohl für die Konzentratorseite als auch für die Bankseite zu.

- Worin bestanden die Schwierigkeiten?

Ich will keinem zu nahe treten. Aber ganz offensichtlich ist es so, daß die SIDs - zumindest in der Form, wie sie heute mit der Software geliefert werden - die Bindegliedfunktion zwischen Banksystem und SWIFT nicht in einer für alle geeigneten Weise erfüllen.

- Was paßt Ihnen an der SID-Philosophie nicht?

Ich glaube, wir müssen da ein bißchen zurückgehen. 1972 hat man gesagt, es müsse eine exakte Schnittstelle geschaffen werden, an die dieses und jenes angeschlossen werden kann. Da gab's noch keine SIDs. Dann zeigten sich die Probleme bei der Entwicklung einer entsprechenden Anschluß-Prozedur. Und um es den Banken einfacher zu machen wurde uns gesagt, man versuche hierfür eine Hardware-Einheit zu schaffen. Da waren wir immer noch voll dabei, als das gemacht wurde. Dann wurde die Auswahl für das Gerät getroffen, da begannen Probleme.

- Welche?

Die SIDs waren einfach Kleincomputer, mit denen man alles mögliche machen wollte, und das war eben nicht drin. Das hat jetzt gar nichts mit genereller Kritik zu tun. Die SIDs können durchaus als "intelligente Fernschreiber" eingesetzt werden, für das was rausgeht zu SWIFT und was reinkommt. Wir hätten jedoch einen Netzwerkrechner gebraucht, der die genossenschaftlichen Rechenzentren und die von ihnen betreuten Banken in einem internen Netz verbindet und gleichzeitig die Kommunikation mit SWIFT kontrolliert.

- Was bringt das Dazwischenschalten einer derartigen Steuereinheit?

Wir wollten eine Verbindung unserer Computersysteme, die den Auslandszahlungsverkehr mit SWIFT unterstützen, auf technisch einfache und organisatorisch befriedigende Weise herstellen; dabei mußte es völlig egal sein, welche Computer dahinterstehen. Wir haben immerhin elf Rechenzentren an dem System, und die haben nicht alle ihre Computer bei einem Hersteller bezogen. Wir wollen erreichen, daß bei den genossenschaftlichen Rechenzentren nicht jeweils ein System dauernd mit SWIFT verbunden sein muß. Das übernimmt für diese "genossenschaftlichen" Computer ein ständig mit SWIFT verbundenes IBM-System/7, das sich gegenüber den Großsystemen der genossenschaftlichen Rechenzentren wie ein Terminal verhält, an das sie die für SWIFT bestimmten Nachrichten absetzen oder von dem sie diese abholen.

- Welche Vorteile werden die angeschlossenen Banken durch die Verwirklichung von SWIFT haben?

Vorteil Nummer eins ist die Beschleunigung der Nachrichtenübermittlung im Auslandszahlungsverkehr: Der Kunde wird schneller das Geld zu seinem Geschäftspartner bringen oder von seinem Geschäftspartner bekommen - die normale Nachricht soll innerhalb von 20 Minuten vom SWIFT-Konzentrator des sendenden Landes zum SWIFT-Konzentrator des empfangenden Landes geleitet werden, erheblich schneller also, als sie heute im allgemeinen ist. Das setzt allerdings voraus, daß die Korrespondenz-Banken, die senden und empfangen, eine entsprechende Organisation haben.

Der Rationalisierungsvorteil für die Banken entsteht dadurch, daß bei vollständiger Verarbeitung des Auslandszahlungs-Auftrages mit automatischer Erzeugung einer SWIFT-Nachricht erheblicher Arbeitsaufwand gespart wird.

- Bedeutet das auch, daß Kosteneinsparungen realisierbar sind?

Das rechnen wir uns jedenfalls aus trotz der nicht sehr automationsfreundlichen Tarifpolitik der Postverwaltungen.

- Apropos Wirtschaftlichkeit. Die SWIFT-Planer prognostizierten, erst bei 300 000 Nachrichten pro Tag werde das System optimal ausgelastet sein. Welche Nachrichtenmenge wird zur Zeit täglich von den Mitgliedsbanken abgesetzt?

Zur Zeit werden etwa 3000 Nachrichten pro Tag durchgesetzt, also etwa ein Prozent der projektierten Einheiten. Das ist aber eigentlich ganz natürlich, da noch nicht alle Banken angeschlossen sind und SWIFT sich - wie bereits erwähnt - in einer Anlaufphase befindet, die nach Meinung vieler Banken eben noch als Life-Test angesehen wird. Es ist den Beteiligten aber klar, daß hier, wie bei jedem Automationsverfahren, eine längere Anlaufphase erforderlich ist, bis die Kapazität voll ausgelastet. Die Banken haben deshalb auch beschlossen, SWIFT-Gebühren zu zahlen, als wäre die Kapazität bereits erreicht, um die Kostendeckung bei SWIFT sicherzustellen. Sie müssen nun selbst interessiert sein, möglichst schnell die volle Kapazität in Anspruch zu nehmen, die sie ja bereits bezahlen.

- Wann wird der Break-Even-Point erreicht sein?

Das ist schwer zu schätzen. Bei automatisierter Auslandsabwicklung kann die einzelne Bank ab 400 Nachrichten pro Tag auf annehmbare Kosten kommen. Wann das sein wird, ist sehr schwer vorauszusagen, weil das auch vom technischen Verhalten des Systems abhängt. SWIFT schätzt für das Gesamtsystem, daß Ende 1979 rund 90 Prozent der ehemals projektierten Nachrichtenmenge pro Tag erreicht sein wird. Diese Schätzung kann man heute nicht widerlegen. Die Banken sollten vielmehr alles tun, um diese Schätzung zu dem Zeitpunkt auch zu realisieren.

- Wie stellt sich eigentlich die neue Organisation dem Sachbearbeiter in der Auslandsabteilung einer Bank dar. Hat er Akzeptanzprobleme?

Das kommt darauf an, mit welchem Organisationsstand die Bank mit SWIFT beginnt. Bei den genossenschaftlichen Banken gibt es überhaupt keine Probleme, der Sachbearbeiter in der Auslandsabteilung merkt überhaupt nichts von SWIFT. Denn unsere Banken haben bereits vor SWIFT das Auslandszahlungsgeschäft computerunterstützt bearbeitet. Das ist sicherlich anders bei Banken, deren Auslandsabteilung jetzt zum erstenmal mit dem Computer in Verbindung kommt. Da durfte es - wie bei der Umstellung jedes Arbeitsablaufes auf Terminals üblich - Schwierigkeiten geben.

- Kann das zu einer Verzögerung des Nachrichtenverkehrs führen?

Derartige Eingewöhnungsprobleme werden nur bei relativ kleinen Banken auftreten, und da ist wiederum die Nachrichtenmenge nicht so groß, daß es wirklich Staus geben könnte.

- Wenn Sie jetzt unterm Strich zusammenzählen, was Sie bisher in dieses Projekt gesteckt haben und was herausgekommen ist, sind Sie da nicht versucht, zu sagen: "Hätten wir uns doch lieber gar nicht darauf eingelassen?"

Nein. Wir haben dieses Projekt vorkalkuliert, wir haben auch die Projektkosten sehr wohl verfolgt und wir haben diese Kosten nicht überschritten: Der Rationalisierungseffekt für die Banken wird also von dieser Seite durchaus erreicht werden.

- Obwohl die meisten das erforderliche Nachrichtenaufkommen auch nicht annähernd erreichen und folglich Leerkosten haben?

Diese Leerkosten werden nur den Break-Even-Point nach hinten verschieben. Aber an der generellen Tendenz, daß SWIFT bei angemessener Entwicklungspolitik zu einem erfolgreichen Service- und Rationalisierungs-Instrument der internationalen Bankenwelt werden wird, ändert das nichts.