Die Informationstechnik (IT) ändert vieles. Das Multimedia-Zeitalter hat technische Instrumente heranreifen lassen wie Multimedia-PCs, Videokioske, Call-Center, Smartphones und - vieles davon vorantreibend - das Internet.
Im Finanzdienstleistungsmarkt hat diese Entwicklung voll durchgeschlagen, das heißt alle technischen Instrumente und Zugangswege werden heute in die Vertriebsarbeit der Banken integriert. Kein ernstzunehmender Banker ignoriert mehr die Bedeutung der IT für den Geschäftserfolg der Bank. Mehr noch, die IT wird zunehmend als entscheidender Erfolgsfaktor für das Überleben einzelner Banken beziehungsweise ganzer Bankengruppen wie des Sparkassen- oder des Genossenschaftssektors angesehen. Denn die Technologie läßt Markteintrittsbarrieren sinken, vor allem durch die Überwindung der Notwendigkeit räumlicher Nähe für eine Filiale. Damit sind ganze Generationen von Erfolgsfaktoren quasi von heute auf morgen in Frage gestellt:
-die Bankfiliale klassischen Zuschnitts als alleiniger Vertriebskanal,
-die persönliche Beziehung zwischen Bankmitarbeiter und Kunde sowie
-die Zurückhaltung der Banken in Fragen der Kundenansprache.
Die Bedeutung der IT für den Geschäftserfolg wird zwar nicht mehr bestritten, dennoch hat die Kompetenz der Banken auf diesem Gebiet mit der stürmischen Entwicklung nicht Schritt gehalten. Die meisten Banken setzen sich gerade damit auseinander, daß IT nicht nur ein Hilfsmittel zur Bearbeitung großer Datenmengen ist, sondern auch ein Erfolgsfaktor im Markt. Infolgedessen steigen die Aufwendungen für IT trotz aller Effizienzbemühungen weiter spürbar an. 1997 im Durchschnitt für alle deutschen Banken um etwa 15 Prozent.
Das für die meisten Bank-Manager unbefriedigende Gefühl entsteht dabei durch die enormen Investitionsbeträge, die oftmals für einen relativ geringen Zuwachs an Komfort oder Funktionalität benötigt werden. Gleiches gilt im übrigen auch für die Erfüllung gesetzlicher Auflagen wie der Novellen des Kapitalwirtschaftsgesetzes (KWG) oder für die Anpassungen an den Euro und die Daten ab dem Jahr 2000. IT muß effizient, zeitgemäß und transparent sein.
Demgegenüber nähren die in der bankbetrieblichen Praxis festzustellenden hohen Kosten und Investitionsbeträge den Verdacht, daß es mit der Effizienz der IT nicht weit her sei. Mit den hohen Kosten geht aus Sicht der Fachbereiche meist auch eine geringe Flexibilität im Hinblick auf die Einbindung der neuesten technologischen Entwicklungen einher, und es gelingt den IT-Verantwortlichen immer seltener, die Gründe dafür transparent zu machen.
Management im Dilemma
Die zentrale Ursache für die beschriebenen Probleme ist die technische Infrastruktur der IT-Landschaft in den Banken, das heißt derjenige Teil der IT, der gewissermaßen hinter dem Bildschirm und der konkreten Anwendung beginnt. Unter technischer Infrastruktur versteht man vor allem Hardware, Betriebssysteme, Netze und Datenbanken, zunehmend aber auch Kommunikations- Groupware wie "Lotus Notes" oder auch Middleware-Konzepte. Die technische Infrastruktur ist verantwortlich für den Aufwand, Daten bereitzustellen, Verarbeitungsprozesse abzuwickeln und alternative Kommunikationsmodi (Realtime, Batch etc.) zu unterstützen.
Technische Infrastrukturen sind in den meisten Fällen historisch gewachsen. Triebfeder bei der Entstehung der IT-Architektur waren zumeist die fachlichen Anforderungen nach bestimmten Funktionalitäten beziehungsweise Anwendungen. Diese anwendungsgetriebene Architekturentwicklung ist daher in der Regel spartenorientiert aufgebaut, das heißt, es gibt beispielsweise eine Anwendungsgruppe Kredit, eine für Handelsprodukte, eine für Schalter/Spar etc.
Die Rolle der Org./IT-Verantwortlichen beschränkt sich in einer solchen Welt auf die Beschaffung und Integration der angeforderten Funktionen beziehungsweise Anwendungen oder den IT-Einkauf.
Diese Architekturentwicklung brachte es mit sich, daß neue Anwendungen teuer integriert wurden. Immerhin funktionierte das Gesamtgefüge der IT-Landschaft dabei leidlich. Die Situation war für alle Seiten einigermaßen erträglich.
Seit einiger Zeit werden jedoch deutlich schärfere Steuerungsinstrumente verlangt. Zum Beispiel fordert der Gesetzgeber über die KWG-Novellierungen die Banken auf, ihr Gesamtrisiko, das heißt Markt- und Ausfallrisiken, gemeinsam zu erfassen und zu bewerten. Dahinter steht die Erkenntnis, daß es für das Verlustrisiko einer Bank gleichgültig ist, ob ein Kredit nicht zurückgezahlt werden kann oder ob ein Aktienportefeuille deutlich an Wert verliert; die Verzinsung des eingesetzten Kapitals leidet in beiden Fällen in der gleichen Art und Weise.
Nicht nur der Druck der Aufsichtsbehörden, sondern auch der Margendruck im Markt erfordert feinere Instrumente der Steuerung, um mittels Kapitalallokation Marktpotentiale feiner aufspüren und kurzfristig ausschöpfen zu können. Hierzu müssen Limitstrukturen kurzfristig disponibel sein, und zwar unabhängig davon, ob das Kapital im Kreditgeschäft oder im Kapitalmarkt eingesetzt wird. Hinzu kommt, daß ohnehin die einstmals getrennten Welten des Kredit- und Wertpapiergeschäftes produktseitig weiter zusammenwachsen (beispielsweise Asset-Backed-Securities).
In den gewachsenen IT-Landschaften der Banken taucht nun das Problem auf, daß die spartenorientierte IT-Entwicklung weitgehend eigenständige Anwendungslandschaften und vor allem IT-Infrastrukturen hat entstehen lassen, die jetzt nicht nur zusammengeführt, sondern zum Teil noch am selben Tag bereitgestellt werden müssen. Der Aufwand zum Beispiel, ein selbstentwickeltes, Batch-orientiertes Kreditabwicklungssystem mit einem Unix-basierten Echtzeit-Handelssystem verbinden zu müssen, um taggleiche Risikoszenarien abbilden zu können, ist immens.
Diese IT-Welten beinhalten nicht nur unterschiedliche Anwendungen und Funktionen, sondern vor allem diverse Datenbanken mit entsprechenden Datenmodellen, unterschiedliche Betriebssysteme und Kommunikationmodi. Darüber hinaus haben die wenigsten Systemexperten bei den jeweiligen Einführungen miteinander gesprochen, was natürlich die Zusammenarbeit weiter erschwert.
Die historisch gewachsenen IT-Infrastrukturen stellen dabei das Hauptproblem dar, denn über sie laufen die Datenbereitstellung und die Kommunikation. Auf Basis der IT-Infrastruktur wird entschieden, welcher Aufwand für die Integration neuer Anwendungen beziehungsweise die Umgestaltung bestehender Funktionen notwendig ist. Gravierende Schwierigkeiten ergeben sich zum Beispiel gerade für die in den Banken zunehmend stattfindende Einbindung der SAP-Welten.
Das Grunddilemma des IT-Managements in den Banken liegt also in der Notwendigkeit und der gleichzeitigen Schwierigkeit, spartenorientiert gewachsene IT-Architekturen mit leistungsfähigen und flexiblen Querschnittsanforderungen verbinden zu müssen. Allerdings operieren die meisten Org./IT-Bereiche noch als reine Service-Dienstleister im Auftraggeber-Auftragnehmer-Verhältnis. Diese Struktur bietet sowohl für die Fachbereiche als auch für Org./IT viele Vorteile. Die Rollenverteilung ist klar, die Schuldfrage meist auch. Diese antiquierte Form der Zusammenarbeit wird ironischerweise noch oft als "kundenorientiert" verkauft, als hätte der Fachbereich (Kunde) ein Interesse daran, in immer komplexeren und inflexibleren IT-Architekturen, die anwendungsgetrieben entstehen beziehungsweise entstanden sind, gefangen zu werden.
Querschnittprozesse von wachsender Bedeutung
Es kann nicht die Aufgabe der Fachbereiche sein, die Verantwortung für die dauerhafte Sicherstellung der Funktionsfähigkeit der IT-Architektur zu übernehmen. Die wachsende Bedeutung leistungsfähiger Querschnittsprozesse wie des Risiko-Managements macht dies überdeutlich.
Ohne Konflikte wird der Wandel nicht abgehen, denn es mag öfter vorkommen, daß die vom Fachbereich gewünschte Anwendung im Sinne der Gesamtarchitektur nur die zweitbeste ist. Die neue Rolle von Org./IT erzwingt umfassende bankfachliche Kenntnisse. Der Org./IT-Verantwortliche, der mangels bankfachlicher Kenntnisse die Gestaltung der Anwendungslandschaft allein den Fachbereichen überläßt, ist ein Auslaufmodell.
Die Gestaltung der Anwendungslandschaften muß dem Ziel des optimalen Integrationsgrades folgen. Man mag eine möglichst hochintegrierte Anwendungslandschaft anstreben, um den Schnittstellen-Aufwand zu verringern. Der Nachteil, der in Kauf genommen werden muß, ist der enorme Aufwand für Erweiterungen und Integration von Fremdsoftware. Vielfach taucht dieses Problem bei selbstentwickelten Back-Office-Anwendungen (Finanzbuchhaltung) auf, wenn Standardsoftware (zum Beispiel SAP) integriert werden soll.
Auf der anderen Seite mag man als Ziel formulieren, eine möglichst modulare Anwendungsstruktur zu erreichen, um ein hohes Maß an Flexibilität zu gewährleisten. Nachteil ist der hohe Schnittstellen-Aufwand für die Einbindung der jeweiligen Anwendungen. Hinzu kommt meist auch, daß eingesetzte Fremdsoftware eigene Datenmodelle und Datenbankstrukturen mitbringt, die aufwendig miteinander verknüpft werden müssen.
Die Suche nach der besten Integrationstiefe ist geschäftsstrategisch. Ist die Bank in traditionellen Geschäftsfeldern mit geringer Veränderungsrate tätig, mag der Integrationsgrad sinnvollerweise höher sein als bei einer internationalen Investmentbank, die ständig neue Produkte generieren muß. Auch sollte grundsätzlich die Kunden-Schnittstelle flexibler gestaltet werden als die Back-Office-Welten. Im Back-Office spielen darüber hinaus die Faktoren Effizienz und Sicherheit eine wesentlich wichtigere Rolle als an der Kunden-Schnittstelle, wo Flexibilität und Bequemlichkeit zentrale Faktoren sind.
In allen diesen Fragen gibt es kein prinzipielles "richtig" oder "falsch". Die Fragen sind immer aus dem Gesamtzusammenhang der bankindividuellen Geschäftsstrategie und der gegebenen IT-Architektur zu beantworten. Leider wird allerdings in vielen Fällen nicht nach diesen Leitlinien verfahren.
Für die Entwicklung der Infrastruktur gilt das grundsätzlich in gleicher Form. Hinzu kommt, daß das Definieren verbindlicher technischer Standards für die Infrastruktur-Komponenten (Datenbank, Betriebssysteme, Netzwerke etc.) ein wesentlicher Baustein zielgerichteter IT-Architekturarbeit ist. Dagegen ist oft zu beobachten, daß zwar Standards definiert, dann aber bei jeder abweichenden Anforderung erweitert werden. Es ist eben kein Standard, wenn als Datenbankstandards Informix, Sybase und Oracle zugelassen werden, weil dies scheinbar zwingend von entsprechenden Anwendungen jeweils gefordert wird. Standards haben nur dann einen Wert, wenn sie aus einer Gesamtarchitektur und deren Entwicklungsstrategie abgeleitet sind und Verläßlichkeit hinsichtlich der Infrastruktur schaffen.
Die Bank der Zukunft wird dann erfolgreich sein, wenn sie die IT als zentralen Erfolgsfaktor versteht. Das mag für manchen Bank- oder IT-Manager unbequem sein, es gilt aber auch hier das alte texanische Motivationsmotto: "You can be on the train or under the train".
*Dr. Hans-Dieter Krönung ist Geschäftsführer der Context Management Condulting Unternehmensberatungsgesellschaft mbH in Bad Homburg.