Ein Datenkonvertierungsprozess in sechs Schritten
Wenn ein Projekt zum Austausch des Schadenbearbeitungssystems, das mehrere Mio. Euro schwer ist, abgeschlossen ist, gehen Sie vielleicht davon aus, dass sich alle offenen und abgeschlossenen Schadenfälle des alten Systems auch im neuen System befinden (insbesondere, wenn Sie zu den Anwendern aus den Fachbereichen gehören). Dies geschieht aber nicht durch Zauberei, denn eine Datenkonvertierung ist in der Praxis viel komplexer, als man zunächst vermuten mag. Eine wichtige Entscheidung im Rahmen aller Projekte zum Altsystemaustausch ist die Auswahl der Datenkonvertierungsmethode. Sie kann erhebliche Folgen für das Risikoprofil, die Dauer, die Kosten und den Wirkungsgrad des Projekts haben.
Wenn Sie nicht gerade ein sehr großer Versicherungsträger mit einem sehr großen Budget sind, ist es unter Umständen wirtschaftlich gar nicht machbar, die entsprechende Software für eine automatisierte Datenkonvertierung zu entwickeln und zu testen. Vielleicht überrascht es Sie auch zu erfahren, dass eine maßgeschneiderte „Einmal-Konvertierungssoftware“ unter Umständen mehr als Ihr neues Schadenbearbeitungssystem kostet.
Ich habe in der Zusammenarbeit mit unseren Kunden die Erfahrung gemacht, dass ein gelungener Datenkonvertierungsprozess aus sechs Schritten besteht. Sie vereinfachen den Prozess und steigern die Erfolgswahrscheinlichkeit.
1. Stufe: Auswahl der Schadenfälle für die Konvertierung – Eine automatisierte Konvertierung kann in ein oder mehreren Schritten erfolgen. Am attraktivsten erscheint der aus nur einem Schritt bestehende „Urknall”-Ansatz, weil alle (offenen oder abgeschlossenen) Schadenfälle gleichzeitig konvertiert werden und im neuen System sofort verfügbar sind. Dies ist aber auch die Methode mit dem höchsten Risiko, weil es nicht nur um große Datenmengen geht, sondern weil auch unzählige verschiedene Datenbedingungen existieren, was auf die Unterschiede in den einzelnen Sparten und Regionen zurückzuführen ist. Vorsichtigere Konvertierungsmodelle trennen die Schadendaten nach Sparte, Region oder sogar Sachbearbeitergruppe. Um das Konvertierungsrisiko zusätzlich zu reduzieren, haben sich einige Versicherungsträger dazu entschlossen, ausschließlich offene Schadenfälle zu konvertieren und abgeschlossene Fälle im Altsystem ruhen zu lassen.
Die Auswahl der Datenkonvertierungs-methode kann erhebliche Folgen für das Risikoprofil,
die Dauer, die Kosten und
den Wirkungsgrad des
Projekts haben.
2. Stufe: Vorbereitung der Daten – Altsysteme verfügen in der Regel nicht über geeignete Prüffunktionen in Bezug auf die Eingabe, Validierung und Datenintegrität, was zu unvollständigen und ungenauen Angaben führt. Die Systeme wurden typischerweise geschrieben, als Speicherplatz der wichtigste Kostenfaktor war. Dies führte dazu, dass man aussagekräftige Angaben so reduzierte, dass nach Möglichkeit nur noch Nummernschlüssel verwendet wurden. Alphanumerische Daten speicherte man in der Regel in frei zu formatierenden Bereichen, in denen alles abgelegt werden konnte. Durch eine solche Konstellation kommt es häufig zu Datenbeständen, die einer gründlichen Bereinigung, Aufbereitung und Verbesserung bedürfen, bevor sie für das neue System von Nutzen sind.
3. Stufe: Data Mapping – Das feldweise Mapping vorhandener Daten vom alten in das neue System klingt solange einfach, bis man es tatsächlich einmal gemacht hat. Häufig werden dabei folgende Erfahrungen gemacht: Für Feld A im Altsystem gibt es im neuen System keine Entsprechung; das neue System verfügt über ein bzw. mehrere Felder, für die wiederum keine Übereinstimmung im alten System besteht; in einem Feld des alten Systems werden die Ergebnisse einer Berechnung gespeichert, während hingegen im neuen System die Komponentenfelder benötigt werden…um nur einige zu nennen. Neben dem einfachen Kopieren von Daten müssen für das Mapping auch Regeln für die Datentransformation aufgestellt werden, um zu prüfen, ob die Daten in Bezug auf das neue System auch zulässig und sinnvoll sind.
4. Stufe: Das Abbild der Schadenfälle generieren – Der nächste Schritt besteht darin, einen Transportmechanismus festzulegen, um die Daten aus einem temporären Zwischenspeicherbereich (staging area) zu extrahieren und dem neuen System zur Verfügung zu stellen. Je nach Fähigkeit des neuen Systems, die Daten zu verarbeiten, ist zu diesem Zweck u. U. ein mehrstufiges Verfahren erforderlich. Einige neue Systeme können per Batch-Verfahren eingespeiste Daten verarbeiten und Daten ohne Einbußen bei der Datenintegrität einspielen. Bei anderen erfolgt die Dateneingabe ausschließlich über Eingabemasken, die den Anwender beim korrekten Editieren und Prüfen unterstützen. Im letzteren Fall ist ein zusätzliches Dateneingabe-Skript zu schreiben und testen, um die manuelle Dateneingabe zu simulieren und die Eingabemasken des Systems anzusteuern.
5. Stufe: Abgleich der Schadenbestände – Um einen Konvertierungszyklus abschließen zu können, muss geprüft werden, ob jeder zu übertragende Schadenfall auch tatsächlich übertragen wurde. Zu diesem Zeck sind zwei Fehlerbedingungen zu überwachen und zu verwalten: 1. Schadenfälle, die übertragen werden sollten, wurden nicht übertragen; 2. Schadenfälle, die nicht übertragen werden sollten, wurden übertragen. Das Vorliegen dieser Bedingungen kann durch Abgleichroutinen zur Nachverfolgung der Schadenübertragung festgestellt werden. Zu diesem Zweck werden die tatsächlich übertragenen Daten mit den erwarteten Daten verglichen und Abweichungen angezeigt.
6. Stufe: Berichtigung von Übertragungsfehlern – Abschließend muss die Möglichkeit bestehen, solche Schadenfälle zu erkennen, zu erfassen, zu berichtigen und erneut bereitzustellen, die den Konvertierungsprozess nicht erfolgreich abgeschlossen haben. Hierzu bedarf es einer Software zur Speicherung und Anzeige nicht übertragener Datensätze. Sie ermöglicht es, die betreffenden Daten manuell zu verändern und die Schadenfälle erneut für den Konvertierungsprozess bereitzustellen.
In dieser vereinfachten Darstellung wurden sechs Schritte festgelegt, die zu spezifizieren, konzipieren, programmieren und testen sind, damit eine automatisierte Konvertierung stattfinden kann. Daher überrascht es wenig, dass sich viele Versicherungsträger dafür entscheiden, ihr Implementierungsbudget für neue Funktionen und Leistungsmerkmale auszugeben statt für eine automatisierte Konvertierung ihrer Schadendaten. Schließlich bleibt zu berücksichtigen, dass die Entscheidung zur Automatisierung oder sogar manuellen Durchführung der Datenkonvertierung nicht nur von der Größe eines Versicherungsträgers, sondern auch von der Dauer, dem Volumen und der Komplexität der Schadenfälle abhängt. Eine Versicherung für Personensparten kann 90 % ihrer offenen Schadenfälle innerhalb eines Jahres abschließen, weshalb sich für sie Konvertierungsoptionen ergeben, die den im Langzeitgeschäft tätigen Gewerbe- und Industrieversicherern nicht zur Verfügung stehen.
George Grieve ist CEO von CastleBay Consulting. In den letzten 25 Jahren verbrachte er – zunächst als CIO und dann als ein bis heute aktiver Berater – einen großen Teil seiner Zeit mit Schaden- und Unfallversicherern und unterstützte sie bei der Suche, der Auswahl, dem Einkauf und der Implementierung geschäftskritischer Kernapplikationen für die Versicherungswirtschaft. Sie erreichen ihn telefonisch unter +1 512 329 2619.