Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

09.12.1998 - 

IT in Versicherungen/Unterstützung dynamischer Geschäftsfelder des Finanzmarkts

Alte Denkmuster blockieren Weiterentwicklung von Skills

Die Sicherung absoluter Reaktionsfähigkeit auf den Finanzmärkten setzt die Fähigkeit voraus, Software in Eigenregie zu entwickeln und zu integrieren. Trotzdem scheuen auch große Unternehmen davor zurück. Warum das so ist und wie dem zu begegnen wäre, skizziert Johannes Hermann*.

Die Liberalisierung der Finanzmärkte, sinkende Transaktionskosten und die Ertragsorientierung als dominanter Maßstab der nachrückenden Generationen haben auf dem Finanzmarkt weltweit einen rasanten Umbruch ausgelöst. Zu den entscheidenden Erfolgsfaktoren gehören deshalb:

- Trefferquote und Präzision beim Erkennen von Marktchancen,

- Kreativität bei der Entwicklung neuer Produkte, Dienstleistungen und Vertriebsformen,

- Schnelligkeit, Sicherheit und Kosteneffektivität bei der Gestaltung der Geschäftsprozesse und

- Geschäftssteuerung nach konsistenten Risiko-Ertrags-Kriterien.

Eine stärkere Fokussierung auf diese Faktoren erzeugt den nötigen Druck für qualitative und quantitative Wachstumsimpulse. Qualitatives Wachstum - Impulsgeber der quantitativen Komponente - ist das Thema. Zu verstehen ist darunter der Strom neuartiger Produkte, Dienstleistungen und maßgeschneiderter Lösungen.

Qualitatives Wachstum stellt extreme Anforderungen an die Systemunterstützung der Geschäftsprozesse: Denn es kommt darauf an, gleichzeitig in zwei Disziplinen, die unterschiedliche Fertigkeiten verlangen, Höchstleistungen zu erbringen. Erstens muß das Produktionssystem zu jedem Zeitpunkt schnell und sicher sein. Und zweitens muß die Systemfunktionalität in kurzen Abständen Marktneuheiten aufnehmen. Das zwingt die Firmen dazu, ständig Investitionen für Spitzenleistungen in der Systemunterstützung aufzubringen, wenn die Präsenz in dynamischen Geschäftsfeldern nicht erodieren soll. Die Sicherung absoluter Reaktionsfähigkeit auf den Finanzmärkten setzt die Möglichkeit voraus, Software in Eigenregie zu entwickeln und zu integrieren. Trotzdem scheuen davor auch große Unternehmen zurück.

Softwareprojekte zur Unterstützung dynamischer Geschäftsfelder gaben häufig Anlaß zu Ernüchterung. Zeit- und Budgetpläne wurden überschritten, und der Markt hatte die Systeme schon überholt, bevor sie einsatzbereit waren. Sind die Enttäuschungen Zeichen objektiver Grenzen des Wissens, der Methoden und der Technologie, oder hatte die Projektdurchführung Schwächen? Eine Antwort auf diese Frage ist für rationale Entscheidungen im IT-Management wichtig.

Die dominanten Vorgehensmodelle der kommerziellen Systementwicklung beruhen auf Erfahrungen aus der Automatisierung ständig wiederkehrender, ablauflogisch fest verdrahteter Arbeiten. In diesem Umfeld sind die funktionalen Anforderungen klar definiert und zeitlich stabil.

Sind Klarheit und Stabilität der funktionalen Anforderungen gegeben, liefern die traditionellen Vorgehensmodelle (siehe Grafik) gute Ergebnisse. Auch in den nächsten Jahren werden Klarheit und Stabilität in vielen Bereichen die Norm sein. Dazu gehören Wertpapierabwicklung, Daueraufträge und integrierte Systeme vom Prämieneinzug bis zur Schadensbearbeitung bei Versicherungen.

Das tradierte Projekt-Management verliert, wenn Wissens-Management wichtig wird, in dynamischen Geschäftsfeldern an Bodenhaftung. Zur Illustration zwei Beispiele:

- Ein Handelssystem für Zins-Swaps und Zinsoptionen sollte um ein Modul erweitert werden, das automatisch Hedging-Deals generiert, die bestimmte Dimensionen des Marktrisikos neutra- lisieren. Das Entwicklungsteam erhielt die Beschreibung eines mathematischen Algorithmus und den Pseudocode für die kriti- schen Prozeduren. Obwohl Algorithmus und Pseudocode mathematisch korrekt waren und der Programmcode den Pseudocode richtig umsetzte, war das daraus entwickelte Programm-Modul unbrauchbar, weil das Verfahren bei manchen Startwerten aus numerischen Gründen nicht konvergierte. Das "Fehlverhalten" der Software traf das Projektteam völlig unvorbereitet.

- Eine Bank wollte alle verfügbaren Daten über bestimmte Privatkunden in einem Datamart sammeln und strukturieren, um den Zyklus vom automatisierten Erstellen von Angeboten auf der Basis von Kundencharakteristika über die Response-Messung bis hin zur Verbesserung des Angebotsgenerators zu realisieren. Das Entwicklungsteam entschied sich für die objektorientierte Modellierung von Kunden, Finanzprodukten und Vertriebswegen. Im Laufe des Projekts stellte sich heraus, daß das OO-Paradigma zwar zu der Aufgabenstellung paßte, daß man sich aber zu früh auf ein spezifisches Datenmodell festgelegt hatte. Richtig wäre gewesen, im Kern des Modells die Nutzendimensionen der Produkte und Vertriebswege den typisierten Entscheidungssequenzen gegenüberzustellen und die konkreten Kunden, Produkte und Vertriebswege darauf abzubilden.

IT-Projektleiter neigen dazu, die Projektkontrolle durch frühzeitige und umfassende Stabilisierung der Anforderungen zu sichern. Dabei verlieren sie die notwendige Flexibilität für Kursanpassungen.

Wie schwierig und riskant Banken Eigenentwicklungen in Zeiten des Wandels einschätzen, zeigen die "Make-or-buy"-Entscheidungen im Risiko-Management (siehe Kasten).

Auf der Liste des Bank-Managements steht immer noch die Frage, wie man die Umklammerung durch Legacy-Systeme öffnet, die den Weg zum technologischen Fortschritt versperrt. Was Legacy-Systeme für Hardware und Software sind, das sind überkommene Denkmuster für das Wissens-Management. Deshalb nennen werden sie auch als Legacy Skill Grids bezeichnet.

Ob es um die Formulierung einer Stellenanzeige oder um das "Staffing" eines Projekts mit internen Ressourcen geht, Legacy Skill Grids spielen stets eine wichtige Rolle. Ihre Felder sind Labels (Skill-Bezeichnungen), die sich historisch herausgebildet haben.

Legacy Skill Grids sind User-Interfaces für das Wissens-Management mit erstaunlichen Leistungsmerkmalen. User sind IT-Ma- nagement und Personalabteilungen. Beide befreit das User-Interface von der Notwendigkeit, sich inhaltliches Wissen anzueignen. Es reicht, wenn sie das leicht erlernbare User-Interface kennen.

Beim Staffing muß der Projekt-Manager in der Lage sein, die Projektanforderungen mit den richtigen Labels zu assoziieren. Die Labels sind Schlüssel, durch die er in firmeninternen oder -externen Skillpools die richtigen Skills identifiziert. Wenn es zum Beispiel um eine unternehmenskritische Anwendung unter Windows geht, fallen dem IT-Manager die Labels C++ und MFC ein, denn diese Assoziationen haben Fachzeitschriften und Seminare geschaffen. Inhaltliches Wissen über C++ und MFC braucht er aber nicht.

Grundlegende Konzepte und Algorithmen zum Erkennen interessanter Muster in großen Datenmengen wurden schon in den 70er Jahren entwickelt. Über einen Zeitraum von mehr als zehn Jahren war das Thema für Praktiker exotisch. Als es dann vom Markt schließlich das Label Data-Mining bekam, entwickelte sich ein Boom.

Die mentale Fixierung auf Legacy Skill Grids verhindert auch die Weiterentwicklung und das Zusammenwachsen von Skills. Zuschneiden und Zuordnen von Aufgaben auf jeweils ein Label führen zu ausgeprägter Sequenzialisierung der Aufgaben und unterbinden fachübergreifende Feedback-Zyklen.

Die Suche nach lösungsrelevantem Wissen im gesamten Skill-Universum geht von den Inhalten aus und experimentiert mit proprietären Skill Grids "exotischer" Disziplinen. Ziel ist es, Wissenskonstellationen zu finden, die einen direkten Projektbeitrag liefern und mittelbar die Produktivität steigern, indem sie das Zusammenwirken der Labels fördern. Sie verlaufen quer zu den etablierten Labels und tragen zum unternehmensweiten Verständnis fachspezifischen Jargons bei. Umfassendes Wissens-Management in der Systementwicklung kann nur funktionieren, wenn im Unternehmen ein einflußreicher Sponsor dahintersteht. Wissensorientierte Systementwicklung ist ein lohnendes Wagnis. Berufseinsteiger und Mitarbeiter der DV/ ORG-Abteilungen mit intellektueller Spannkraft und Motiva- tion können sich in einer anregenden und anspruchsvollen Atmosphäre umfassend entwickeln. Karrierebewußte IT-Manager haben die Chance, die traditionelle Hürde vom IT-Management zum allgemeinen Management leichter zu überspringen. IT-Manager, die an tradierten Vorgehensweisen festhalten und auf dynamischen Geschäftsfeldern den Wettbewerb suchen, begeben sich in Gefahr.

Risikomanagement

Die Mindestanforderungen an das Betreiben von Handelsgeschäften des Bundesaufsichtsamts für das Kreditwesen verlangen von den Banken, potentielle Wertverluste zeitnah zu schätzen. Dazu müssen die Handelssysteme neu abgeschlossene Geschäfte an einen Datenpool liefern. Die Risikoanalyse stützt sich auf statistische Modelle, Monte-Carlo-Simulationen und Szenarien.

Nur wenige Banken entschieden sich für Eigenentwicklungen mit fachunabhängigen Tools. Die Mehrzahl schloß Eigenentwicklung schon im Vorfeld aus. Statt dessen setzte sie auf die Implementierung von Risiko-Management-Standardpaketen. Wie rational ist diese Entscheidung?

Wir gehen davon aus, daß das Standardpaket aus einer C++-Klassenbibliothek und einer SQL-Datenbank besteht, in der die Objekte in relationaler Form gespeichert werden. Der Einsatz solcher Standardpakete für das Risiko-Management ist sinnvoll, wenn sie schon zum Zeitpunkt des Kaufs einen soliden Mechanismus bieten, um neue Finanzprodukte mit überschaubarem Zeit- und Kostenaufwand zu integrieren. Andernfalls sind sie problematisch:

- Die kontinuierliche Erweiterung eines relationalen Modells zur Speicherung neuer, komplexer Derivate bei fest vorgegebenem Modellkern ist aufwendig, führt tendenziell zur Einführung vieler neuer Tabellen und zu sinkender Performance. Ein Gegenwert für die relationale Modellierung ist nicht erkennbar.

- Die Erweiterungen des Standardpakets durch Hersteller und Käufer sind inkompatibel. Wenn der Kunde Support haben will, muß er seine Darstellung umformatieren. Die eigenen Erweiterungen werden wertlos.

- Das Standardpaket kann sich zum Mittelpunkt einer Insellösung entwickeln, auf deren Bewirtschaftung eine kleine Gruppe hochbezahlter Spezialisten das Monopol hat.

Rapid Prototyping im Rahmen einer Feasibility-Studie zeigte, daß für PCs verfügbare Standardsoftware eine flexible und preiswerte Basis für Eigenentwicklungen im Risiko-Management ist. Sie läßt Deals beliebiger Komplexität zu. Solange die Deal-Anzahl und die Anforderungen an die Reponse-Zeiten moderat bleiben, eignet sich die Konfiguration sogar als Produktionssystem. Über den Einsatz leistungsstärkerer Datenbanken ist die Lösung skalierbar.

Für die Portfolios mancher kleinerer und mittlerer Institute dürfte eine Lösung dieser Art durchaus ausreichen. Handelshäuser könnten die Methode nutzen, um neuartige Deals schnell im Risiko-Management zu berücksichtigen. Es ist erstaunlich, wie wenig verbreitet die systematische Beobachtung preiswerter Softwaretechnologie außerhalb einer kleinen Gruppe internationaler Großbanken ist.

Angeklickt

Komplexität, Geschwindigkeit und Wandel sind charakteristisch für viele profitable Geschäftsfelder des Finanzmarkts. Die dazugehörigen Geschäftsprozesse stellen extreme Anforderungen an die Systemunterstützung; traditionelles Vorgehen stößt an Barrieren. Budget- und Zeitüberschreitungen oder Projektabbruch sind oftmals die direkte Folge, Grundsatzentscheidungen gegen Eigenentwicklungen ohne gründliche betriebswirtschaftliche Analyse sind das indirekte Ergebnis. Dieser Artikel geht auf die ökonomischen Ursachen der schwer zu meisternden Anforderungen ein, identifiziert Defizite des traditionellen Projekt-Managements und zeigt einen Ansatz für Leistungssteigerungen.

*Dr. Johannes Hermann ist Mitarbeiter der BIV GmbH in Bonn. Er ist mit Modellbildung und Prototyping zur schnelleren Entwicklung, Abstimmung und Umsetzung von Fachkonzepten befaßt.