Was vor Jahren kaum vorstellbar war, ist heute schon vielerorts Realität: der Großeinsatz von Unix Systemen im kommerziellen Bereich. Roland Dippelreiter* schildert, wie der Creditanstalt Bankverein in Wien sein gesamtes DV-Konzept auf Unix-Systeme umgestellt hat. Zentrales Problem dabei war die Umschulung der Mitarbeiter. Hier haben die Osterreicher Phantasie bewiesen und eine "mobile Schulungsstation" aufgebaut.
Unser Institut beschäftigt insgesamt ungefähr 7200 Mitarbeiter, von denen etwa 2800 in den Außenstellen tätig sind. Wir betreiben unsere Filialen nicht nur in Osterreich, sondern auch international In den letzten Jahren entwickelte sich unsere DV-Struktur so, daß wir 1975 damit begannen, ausgehend von Rechenzentren in Wien, Graz, Innsbruck und Salzburg, in unseren Außenstellen Terminalsysteme zur DV-Unterstützung des Kassageschäftes zu installieren.
Terminalsysteme für das Kassengeschäft
Diese dedizierten Systeme waren so konzipiert, daß im Normalfall die Geschäftsabwicklung als Online-Transaktionen am jeweiligen Host erledigt wurde. In Ausnahmesituationen, bei Störung einer Komponente außerhalb der Außenstelle, ermöglichte eine vollwertige Offline-Logik die Durchführung der Geschäftsvorfälle. Je nach Verfügbarkeit der Zentrale wurden die Umsätze automatisch übersandt und nachverarbeitet.
Wir betrieben also von Anfang an ein sogenanntes "cooperative processing". Ab 1984 installierten wir dann in unseren Außenstellen Schalter- beziehungsweise Back- Office-Systeme. Es handelte sich um PCs mit gemeinsamem Datenbestand, die einerseits für Host-Applikationen als 3270-Terminals, andererseits als Textsysteme sowie außerdem für lokale Applikationen eingesetzt wurden. Im Jahr 1986 begannen wir, flächendeckend Selbstbedienungs-Kontoauszugs-Drucker zu installieren.
Im selben Jahr beschlossen wir, für unsere betagten Kassasysteme Nachfolger zu suchen. An das neue Außenstellen-System stellten wir folgende funktionalen Anforderungen:
- Es sollte in der Außenstelle - unabhängig von der Größe - ein logisches System sein.
- Wir wollten einheitliche und multifunktionale Arbeitsplätze.
- Die vorhandenen Funktionen sollten übernommen werden.
- Ein Ausbau von Kapazität und Funktionalität war nicht zwingend erforderlich.
- Steuerung und Verwaltung sollten zentral wahrgenommen werden.
Zusätzlich zu diesen funktionalen Anforderungen legten wir auch technisch-organisatorische fest:
- Standard-Betriebssystem (Unix);
- Kommunikation SNA;
- relationale Datenbank;
- Softwareprodukte in Vertrieb und Wartung des Systemlieferanten.
Im Rahmen der Ausschreibung erhielten wir 15 Angebote, von denen vier in die engere Wahl kamen. Die vorgeschlagenen Systeme mußten im Rahmen einer Teststellung ihre Funktionalität beweisen. Zur Diskussion standen schließlich nur noch die Unix-Systeme von Siemens und Philips.
Warum wollten wir Unix? Bei der Formulierung der Ausschreibung 1986 haben wir Unix nicht zwingend als Betriebssystem gefordert.
Uns lagen vor allem zwei Dinge am Herzen:
1. Das Betriebssystem mußte ein "Mainline-Produkt" des Herstellers sein. Außerdem wollten wir die Garantie einer Weiterentwicklung über zehn Jahre.
2. In jedem Falle sollte Unix als Gastsystem lauffähig sein.
1986 war die Frage, ob Unix in der kommerziellen Datenverarbeitung Zukunft haben wird, noch nicht eindeutig zu beantworten. In unserem Unternehmen wurden sogar Wetten abgeschlossen, daß Unix 1992 kein Thema mehr sein würde.
Wir suchten damals nur ein Außenstellen-System. Obwohl eine Workstation mit ihrer Rechnerleistung verlockend und sinnvoll erschien, wollten wir nicht die "persönliche Workstation", sondern Arbeitsplätze, die mitarbeiterneutral ausgelegt sind. Aus diesem Grund waren auch damals vernetzte PCs kein Thema.
In Anbetracht des nicht vorhandenen technischen Knowhous bildeten wir zur Realisierung unserer Pläne gemeinsam mit dem Hersteller ein Projektteam. Zielsetzung war von Anfang an, die vom Hersteller entwickelten Anwendungen in unsere hauseigene Wartung zu überführen. Darüber hinaus bestand unsere Strategie darin, Softwareprodukte einzusetzen, für die unser Partner die Integration, Wartung und Weiterentwicklung garantiert.
Eigener Precompiler für bessere SW-Qualität
Um die gleichmäßige Qualität der zu entwickelnden Anwendungsssoftware sicherstellen zu können, wurde ein eigener Precompiler (Epsilon) entwickelt - wie sich zeigte, eine sinnvolle Investition. Damit ließ sich Software herstellen, die qualitativ so gut war, daß wir seit dem Einsatz in unserer Pilotstelle nie auf alte Systeme zurückgreifen mußten.
Auch unsere Anforderung an den multifunktionalen Arbeitsplatz wurden erfüllt. Folgende Faktoren bestimmen dessen Funktionalität:
1. Berechtigungsprofile der Anwender;
2. hardwaremäßige Ausstattung des Arbeitsplatzes;
3.Anforderungen, die das Programm stellt.
Im Zuge der Projektentwicklung zeigte sich deutlich, daß die wichtigste Komponente beim Einsatz der neuen Systeme der Ausbildungsstand der Mitarbeiter ist. Unter der Prämisse, daß wir das neue System von einem Tag auf den anderen in den Außenstellen einsetzen wollten, mußte die Zielsetzung darin bestehen, die Mitarbeiter so kurzfristig wie möglich vor Einsatz des neuen Systems zu schulen.
Wir bilden alle Mitarbeiter in Abhängigkeit zur Aufgabenstellung aus und kommen auf durchschnittlich vier Schulungstage für die Umstellung auf Unix. Um das Raumproblem in den Griff zu bekommen, mußten wir außergewöhnliche Maßnahmen in Angriff nehmen. Gemeinsam mit dem Hersteller und der Österreichischen Bundesbahn (ÖBB) haben wir einen Zug ausgerüstet, den wir nun in den Regionen wo er benötigt wird, einsetzen. Die ÖBB stellt die notwendige technische und soziale Umgebung.
Darüber hinaus übernehmen wir etwa eine Woche vor Einsatz die Wordstar-Dateien und konvertieren sie in HIT-Dokumente. Dabei liegt das Problem nicht so sehr im technischen Bereich als vielmehr darin, von einem eindimensionalen Textsystem in ein mehrdimensionales Bürosystem zu wechseln und dies den Anwendern zu vermitteln.
Aus dem Wechsel in Richtung Unix haben wir eine Reihe von Erfahrungen gewonnen. Über Standards beziehungsweise Standardschnittstellen zum Beispiel wird zunehmend diskutiert. Mit Hilfe dieser Festschreibungen kann in der Unix-Welt hersteller- und produktunabhängig ein Funktionenmodell aufgebaut werden, das gute Chancen für eine Realisierung besitzt.
Kopfzerbrechen bereitet uns - vielleicht ist dafür auch nur unser Systemlieferant verantwortlich - , daß wir ein bestehendes, in Jahrzehnten gewachsenes DV-System haben, in das ein neues System integriert werden soll. Dies bedeutet, daß die neue Welt an bestehende Strukturen angepaßt werden muß. Faszinierend ist, welches Entwicklungspotential sich hinter dem Begriff Unix verbirgt. Es gibt wohl keine andere Entwicklung im DV-Bereich, die dem Anwender derart viele Implementationsvarianten bietet.
Unsere Creditanstalt entwickelt derzeit eine neue DV-Strategie, die, basierend auf den Erkenntnissen mit den Außenstellen-Systemen, folgendes vorsieht: ein Single System Image für den Anwender und darunter ein Drei-Ebenen-Konzept mit den Stufen Mainframe, Unix und Workstation. Ziel ist, dem Anwender eine einheitliche Oberfläche (Hard- und Software) zur Verfügung zu stellen. Für den reibungslosen, geordneten Betrieb zeichnet die "Datenverarbeitung" verantwortlich. Dieses Modell gilt nicht nur für die 3500 Arbeitsplätze im Außenstellen-Bereich, sondern auch für weitere 3000 im Bereich der Zentrale.
*Roland Dippelreiter ist Abteilungsleiter System und Datentechnik bei der Creditanstalt Bankverein in Wien.