Die Bedeutung einer unternehmensweiten Datenarchitektur zeigte sich bei Colonia Versicherungen AG, ORT: Inkonsistenzen und Qualitätsmängel der Datenarchltekturen operativer Systeme wurden bei der Umsetzung aktueller Anforderungen wie

funktionsübergreifender Analysen deutlich. Norbert Rohrig, Abteilungsleiter EDV-Systemarchltektur, machte Erfahrungen mit dem Aufbau einer zweiten Datenbasis unter DB2.*

In den Jahren 1984 und 1985 kristallisierten sich bei der Colonia Versicherung immer mehr Anforderungen heraus, die kurzfristig realisiert werden sollten und die alle im Bereich der Analyse von Daten lagen. Beispiele hierfür sind:

- sparten- bzw.

funktionsübergreifende Analysen und Kunden-Analysen,

- dezentrale Datenextrakte, zum Beispiel PC-Download für Agentursysteme ,

Systeme für alle Sparten sukzessive vorangetrieben. 1983 wurde ein Agentur-System entwickelt, in dem die

wesentlichen Daten der operativen Systeme redundant und in vertriebsspezifischer Ausprägung gespeichert wurden. Mit der Einführung einer Sprache der vierten Generation (FOCUS) bekam der Endbenutzer die Möglichkeit, direkt auf Entladebestände der operativen Datenbanken zu

selektieren.

Mit dem Breiteneinsatz von FOCUS, sowohl im Fachbereich als auch in der professionellen Anwendungsentwicklung, wurden folgende Probleme bei der Umsetzung der Anforderungen deutlich:

- Konsistenz, Qualität und Verständlichkeit der Datenstrukturen und der Datenelemente waren insbesondere bei Nutzung durch den Fachbereich und übergreifender Stellen im Hause bei weitem nicht ausreichend.

- Die funktionale Trennung

zwischen operativen und Statistiksystemen etc. erlaubte keine integrativen Analysen.

- Neue Benutzergruppen wie Endbenutzer und Agenturen führten zu einem höheren Anforderungsniveau an die Einheitlichkeit und Verständlichkeit der Daten.

- Die vielfältigen Wünsche der

Endbenutzer ließen sich mit den

Möglichkeiten eines hierarchischen

Datenbank-Management-Systems unter Performance-aspekten nicht vernünftig organisieren.

Als Hauptproblem wurde die heterogene Architektur des Colonia-Datenbanksystems erkannt. Es setzt sich aus den verschiedensten

Datenbanksystemen der einzelnen versicherungstechnischen Sparten zusammen, die im integrierten Verbund mit den Kunden-, Inkasso-, Schaden- und Vertriebsdatenbanken zusammengeschlossen sind.

Um die kurzfristigen Anforderungen dennoch realisieren zu können, wurde entschieden, eine zweite Datenbasis für rein dispositive Zwecke aufzubauen und gleichzeitig eine spartenübergreifende Unternehmensdatenarchitektur zu entwikkeln, in der Sparten-und Vertriebsbelange gleichermaßen gut abgedeckt sein sollten.

Strategische Aspekte, die die Entwicklungen der 90er Jahre einbezogen, standen bei dieser Entscheidung mit im Vordergrund. Die Reorganisation der verschiedenen Systeme wurde aus Aufwandsgründen verworfen.

Im ersten Schritt wurde unter Berücksichtigung der analysierten Anforderungen ein Konzept erarbeitet und EDV-Ressort-intern verabschiedet (Februar 1986).

In einem zweiten Schritt wurde die Entwicklung eines Prototypen im Rahmen eines Pilotprojektes und mit einem Teilanwendungssystem des Bereiches Sach/Unfall/Haftpflicht aufgesetzt. Die Datenanalyse wurde hierbei nur mit ausgewählten Daten durchgeführt (Februar 1987).

Nach positiven Erfahrungen wurde eine Gesamtvorstandsentscheidung herbeigeführt (Mai 1987) und der Ausbau des Prototypen für alle Sparten und alle Felder vorgeschlagen. Nach Freigabe durch den Vorstand wurde die neue Gruppe Datenmanagement gegründet (September 1987) und die Realisierung der ersten Stufe für Dezember 1988 geplant.

Dabei haben wir uns gegen eine Kommunikationssystemstudie (KSS) oder ähnlich umfangreiche Informationssystemstudien entschieden und als Basis der Entwicklung die Daten des operativen Datenbanksystems benutzt. Die wesentlichen Gründe hierfür waren:

- ein guter Entwicklungsstand der

operativen Systeme,

- das klare Ziel, zuerst die Datenarchitektur zu entwickeln, um die Analyse-Anforderungen abdecken zu können,

- die Ergebnisse einer KSS unmittelbar nicht umsetzen zu können,

- durch eine KSS das wesentliche Ziel aus den Augen zu verlieren.

Die Schwerpunkte der Aufgaben des Datenmanagements liegen auf:

- Datenarchitektur,

- Datenanalyse,

- Datenbankdesign,

- Log -und Update-Verfahren.

Datenarchitektur. In einer abgestuften Vorgehensweise wurden über ausgewählte Daten eines Spartenbereiches die Objekte und deren Beziehung gefunden und in einem zweiten Schritt durch die Analyse aller Daten des jeweiligen Bereiches verifiziert. Dabei wurden die Restriktionen der operativen Datenbasis berücksichtigt.

In einem dritten Schritt wurden die verschiedenen Spartenmodelle zu einem Unternehmensdatenmodell verbunden. Dabei wurden statistische und dezentrale Daten ebenso integriert, wie laufende operative Projektentwicklungen.

Das Ergebnis der Datenarchitektur war ein Unternehmensdaterimodell, das für alle Benutzerkategorien Verwendung finden soll.

Datenanalyse. In der Datenanalyse wird die eigentliche Detailarbeit durchgeführt. Im einzelnen ist dies: - Zuordnung von Attributen (Datenfeldern) zu Entities

(Datenobjekten),

- Analyse aller Datenfelder im

Hinblick auf Darstellungsform,

Verschlüsselungsprinzipien, Mehrfachbedeutungen etc.,

- Normalisierung bis zur dritten Normalform,

- Festlegung von Transformations und Restrukturierungsregeln,

- Dokumentation in einem DDS,

- Verifikation über

Anwendungsbeispiele.

Da jedes Datenfeld verifiziert werden muß, ist dies ein sehr aufwendiger Prozeß.

Datenbankdesign. Hier findet die Implementierung des vorgefundenen Datenmodells statt. Dabei wird:

- die Umsetzung des Modells in DB2-Tabellen vorgenommen,

- das Modell nochmals verifiziert,

- die Implementierungsform unter Performance-Aspekten festgelegt.

Durch den Ansatz, die Datenfelder

der operativen Datenbanken zu benutzen, konnte von vorneherein keine Ideal-Datenbank entstehen, da die Restriktionen des operativen Systems teilweise durchschlugen.

Log- und Update-Verfahren. Die Veränderungen aus der operativen Datenbank werden täglich gelogged, die relevanten Daten nachts selektiert, abgeglichen und der Update durchgeführt. Neben der tagesaktuellen Version der zweiten Datenbasis gibt es noch eine Quartals- und Jahresendversion.

Der erste Implementierungsversuch des Datenmodells unter Focus scheiterte aufgrund von Mengenrestriktionen des FOCUS. Die zweite Implementierung unter DB2 war erfolgreich und gab im Vergleich zur Focus-Implementierung auch Aufschluß über Performance- und Laufzeitverhalten. Bei komplexen Abfragen über mehrere Objekte war das CPU- und Laufzeitverhalten bis zu Faktor 14 besser gegenüber FOCUS.

Die Entwicklungskosten für die zweite Datenbasis werden rund 2,2 Millionen Mark betragen bei etwa 110

Mannmonaten Aufwand. Nach Einführung des Systems und vollständiger Nutzung rechnen wir damit, daß etwa sechs Mitarbeiter die Betreuung und Weiterentwicklung vornehmen und wir eine Steigerung der CPU-Last um 20 Prozent und des Plattenbedarfs um rund 15 Prozent haben werden. Insgesamt gehen wir von einer jährlichen Belastung von 2,8 Millionen Mark nach Einführung des Systems aus. Dies entspricht etwa 4,5 Prozent des jährlichen EDV-Budgets.

Schwerpunkt bei der Entwicklung des Colonia-Unternehmensdatenmodells war die Entscheidung, eine

unternehmensweite Datenkonzeption durchzuführen, mit dem Ziel, den Nutzen für alle Benutzerkategorien

zu erschließen. Dazu gehören:

- die EDV-Benutzer (Fachbereich)

- die Sparten

- Vertrieb

- professionelle

Anwendungsentwicklung (PAE)

- Sachbearbeiter in Verbindung zum operativen System.

Ein Pilotprojekt verringert die Komplexität

Das Vorschalten eines Pilotprojektes und die stufenweise Entwicklung und releaseweise Einführung verringert die Komplexität und läßt frühzeitige Revisionspunkte zu.

Dabei ist es wichtig, die Entwicklung zwischen den verschiedensten Bereichen wie Fachbereich, Datenmanagement, Datenbanken und PAE gemeinsam zu betreiben.

Durch die Vorgehensweise, mit einem methodischen Ansatz Daten zu analysieren und zu modellieren, findet auch ein Wechsel der Denkweise von der Anwendungslogik hin zur Datenlogik statt. Dort, wo man beispielsweise bisher klassisch von Statistiksystemen gesprochen hat, wird es eine Integration von Stamm- und Statistikdaten auf der Basis eines einheitlichen Datenmodells geben.

Die Entwicklung einer zweiten Datenbasis ist dabei ein solch gravierender Schritt, daß man bei der Überlegung, die

Datenanalysemöglichkeiten zu verbessern, nicht stehen bleiben, sondern die Anforderungen und strategischen Aspekte der 90er Jahre mit einbeziehen und berücksichtigen sollte. Diese Anforderungen an den Versicherungsbetrieb der 90er Jahre, die durch IS-Systeme entscheidend unterstützt werden können, lassen sich in drei Kategorien beschreiben.

- Verbesserter Kundenservice

Durch Rundum-Sachbearbeitung, Dezentralisierung von Funktionen und Kompetenz vom Sachbearbeiter zur Agentur (zum Beispiel Schadensregulierung) und Bürokommunikation.

- Größere Produkflexibilität

Durch verstärkte Datenanalysen und DV-Know-how in den Sparten können neue Produkte schneller gefunden und durch flexiblere IS-Verfahren auch umgesetzt werden.

- Verbesserte Kostensituation

Durch die Reorganisation der Systeme ist mit einer Verbesserung der Kostensituation kaum zu rechnen. Die klassische Argumentation über Rationalisierungsnutzen wird sich verschieben auf nicht quantifizierbaren Nutzen wie Durchlaufzeiten, Qualität der Produkte, Reaktionszeit aber auch Einsparung von Kosten, die durch Fehlentscheidungen beim Sachbearbeiter entstehen, durch den nicht ausreichenden IS-Unterstützungsgrad beziehungsweise unzeitgemäße Prozeß- und Datenarchitekturen.

Alle diese Anforderungen lassen sich mit Daten- und Prozeßarchitekturen der 70er Jahre nicht mehr abdecken.

Diese strategischen Überlegungen führen dazu, daß man nach Möglichkeiten sucht, die bestehenden Systeme zu reorganisieren. Erfahrungsgemäß dauert dies zwischen sechs und acht Jahre.

Weicher Übergang in die Reorganisation

Die Entwicklung einer dispositiven Datenbank und die Reorganisation der Daten nach Unternehmensaspekten ist die erste Stufe in einem Stufenkonzept, mit dem die kurzfristigen Anforderungen erfüllt werden können und das einen technisch weichen Übergang in die Reorganisation der operativen Systeme ermöglicht.

Der organisatorische Übergang muß dann mittels KSS oder Informations-System-Studien vorbereitet werden. Die Investitionen dafür liegen mit rund fünf Prozent Steigerung der EDV-Kosten im Rahmen. Wesentlich dabei ist die Erkenntnis, daß der erste Schritt die Reorganisation der Daten und nicht der Prozesse ist und daß sich operative und Statistikdaten in einem Modell vereinigen. Bei der Entscheidung, eine zweite Datenbasis zu entwickeln, ist zu berücksichtigen, daß die unterschiedlichen Datenarchitekturen der operativen und der dispositiven Datenbanken sich auf Dauer nicht integer halten lassen. Die Überführung in eine endgültige Lösung ist daher erforderlich.