Karen, in unserem letzten Gespräch haben wir über die Bedeutung von professionellem Datenqualitäts-Management und über die erforderliche organisatorische Einbettung gesprochen. Jetzt möchte ich etwas konkreter werden. Beschreibe doch mal, worauf es bei der Umsetzung ankommt? Wie sollte sich ein solcher Data Governance Prozess gestalten?

Für einen effizienten Data-Governance-Prozess ist ein Zusammenspiel vieler Komponenten erforderlich: ein Glossar, um sich auf einheitliche Begriffsdeutungen zu einigen, ein leistungsstarkes Profiling, eine effiziente Regelpflege, Workflows für den Fehlerfall, Monitoring und eine übergreifende Data Lineage. Lass uns mit dem Glossar beginnen.

Mit einem Glossar können Versicherer zunächst ein einheitliches Verständnis von allen Begrifflichkeiten herstellen. Gar nicht so leicht, denn jeder Bereich arbeitet ja mit bewährten Definitionen, nur sie passen halt manchmal nicht zusammen.

Gehen die Vorstellungen denn so weit auseinander?

Wie immer steckt der Teufel im Detail. Nimm zum Beispiel den Begriff Schadenvolumen. Das können sein: a) die im aktuellen Jahr gemeldeten Schäden (regulierte Schäden und Reserven). Oder b) nur die im aktuellen Jahr tatsächlich regulierten Schäden. Und die umfassen dann eventuell auch Schäden aus den Vorjahren. Die Beträge können sich je nach Schadenjahr deutlich unterscheiden und, falsch verwendet, daraus genierte KPIs verfälschen.

Verstehe. Will man daraus zum Beispiel aussagekräftige Benchmark-Zahlen generieren, muss man natürlich auch wissen, welcher Wert zur betrachteten Periode oder Bezugsgröße passt.

Du sagst es: Nur so lassen sich daraus die richtigen Maßnahmen ableiten. Führungskräfte müssen sich darauf verlassen können, dass KPI-Trends richtig sind.

Vermutlich ist das im internationalen Umfeld noch wichtiger?

Das stimmt, in internationalen Konzernen gibt es viele begriffliche Missverständnisse. Ein und dasselbe Wort kann mit unterschiedlichen Bedeutungen besetzt sein, zum Beispiel der Begriff Reserve. Das klingt zunächst einmal nicht nach einer großen Sache, aber die Folgen können gravierend sein.

Warum fallen solche Missverständnisse denn im Projektverlauf nicht auf?

Alle gehen davon aus, das Richtige zu liefern bzw. zu erhalten. Unterscheiden sich die Zahlen in der Größenordnung nicht gravierend, fällt das bei den ersten Lieferungen und Testläufen kaum auf.

Du meinst, wenn keiner kritisch hinterfragt, wird der Fehler zu spät oder gar nicht erkannt?

Genau. Ich erinnere mich an einen Fall im Rahmen der Euroumstellung. Da wurde versehentlich auch die Anzahl Verträge um den DM/Euro Faktor reduziert. Im Geschäftsbericht sah das konsistent aus, aber im Vergleich mit dem Vorjahres-Geschäftsbericht waren es plötzlich nur noch halb so viele Verträge. Aufgefallen ist das einen Tag vor der Hauptversammlung.

Das heißt, der Bericht war bereits gedruckt und verteilt?

So war es. Natürlich wird dann schnell ein Korrekturblatt erstellt, aber ein bisschen unangenehm und peinlich ist das schon, schließlich müssen sich Vorstände an solchen Tagen vor ihren Aktionären rechtfertigen. Und so etwas fördert nicht gerade das Vertrauen.

Manchmal führt es auch zu erheblichen Projektverzögerungen oder, schlimmer noch, ungeplanten Zusatzkosten, um den Fehler zu beheben. Jede Führungskraft kennt so einen Fall aus ihrem Alltag.

Welche Rolle spielen hier die Fachbereiche?

Ihre Einbeziehung ist elementar. Sie sind die Meister der Zahlen und kennen die wahre Bedeutung der gelieferten Daten. Daher legen sie die Definitionen fest und liefern auch gleich die erforderlichen Qualitätsregeln mit. Das muss direkt im System erfolgen, nicht wie bisher in einem Fachkonzept.

Und jetzt betritt das Glossar endlich die Bühne!

Ja, weil das die Fachbereiche und die IT bei der Herstellung eines gemeinsamen Begriffsverständnisses unterstützt. Dabei ist es für die Akzeptanz wichtig, dass Fachbereiche ihre bekannten Begriffe in ihrer Sprache wiederfinden, diese aber gleichzeitig eindeutig einer zentralen Definition zuordnen.

Ist die Bedeutung der Begriffe klar definiert, können Fachbereiche und IT sinnvolle Regeln aufstellen, die dann von der IT mit Daten verknüpft und überall einheitlich verwendet werden. Ein ganz ähnliches Konzept übrigens wie beim Business Rules Management.

Um diese Prozesse optimal zu unterstützen, wird eine leistungsfähige Softwarelösung benötigt.

Verstehe, das macht die Fachbereiche flexibel, und sie sind durch sauber hinterlegte Übergabeprozesse abgesichert. Ich habe noch eine andere Frage: Du betonst die einheitliche Verwendung der Regeln. Ist das heute nicht so?

Leider nein. Prüfregeln sind meist mehrfach und nicht deckungsgleich in diversen Programmen hinterlegt. Ändert sich eine Regel aus fachlicher Sicht, muss sie oft in zehn oder mehr Programmen angepasst werden. Das bedeutet erhöhte Wartungsaufwände, und wenn etwas vergessen wird, sind Inkonsistenzen in den Daten möglich. Ändern kann heute nur die IT, die einer Maßnahmenplanung unterliegt.

Ich kann mir gut vorstellen, wie „flexibel“ das ist … Das hört sich nicht gerade effizient an – ist vermutlich aber historisch gewachsen. Werden deshalb in modernen Lösungen die Regeln von den Programmen getrennt und zentral definiert?

Ja, genau, das gilt für Qualitätsregeln genauso wie für Business-Regeln ganz allgemein. Gerade jetzt, wo agile Ansätze zählen, ist diese Aufgabenteilung eine wichtige Voraussetzung für den Erfolg. Unternehmen müssen ihre Prozesse ändern, um Agilität auch praktisch leben zu können.

Eine leistungsfähige Data-Lineage-Analyse ergänzt das Ganze. Sie zeigt grafisch die Verknüpfungen zwischen Beschreibung, Regeln und Daten auf. So wird bei Änderungen auch nichts übersehen.

Was passiert, wenn Fehler bei der Überprüfung auftreten? Wer legt fest, was dann passiert?

Das wird im Rahmen des Projektes festgelegt. Die Ergebnisse der Überprüfungen werden zunächst in einem Repository abgelegt. Das ist übrigens auch wichtig, um sie für ein Monitoring für Solvency II oder IFRS zu dokumentieren. Dieses Monitoring wird von den Regulatoren sogar verpflichtend gefordert.

Für jeden Fehlerfall legen Workflows den Umgang mit den Daten fest. Wird eine Datenlieferung beispielsweise komplett abgelehnt oder reicht es, die fehlerhaften Sätze auszusteuern? Wer muss automatisch informiert werden? Wer bereinigt die fehlerhaften Daten? Auch hier ist wieder Teamarbeit zwischen IT und Fachbereichen gefragt.

Welche Rolle spielt in diesem Zusammenhang das sogenannte Profiling der Daten?

Gute Frage, Christian. Profiling zeigt, was in den Daten steckt und was bei der Überprüfung berücksichtigt werden muss. Welche Muster oder Formate sind in einem Feld vorhanden? Gibt es Ausreißer und sind die Schlüsselfelder eindeutig? Eine wichtige Basis bei der Definition von Regeln, die für alle Projekte wichtig ist, selbst wenn noch kein Governance-Prozess aufgesetzt wurde.

Treten dabei auch manchmal überraschende Dinge zutage?

Allerdings, ich erinnere mich an einen Fall, bei dem die Überprüfung ergeben hatte, dass es Vertragskonstellationen gab, in denen keine Prämienrechnung gestellt wurde. Unvorstellbar, aber tatsächlich passiert!

Unglaublich. Sag mal, können aus den Profiling-Erkenntnissen nicht auch direkt Regeln für die spätere Überprüfung abgeleitet werden?

Genau, deshalb ist es so wichtig, Profiling von Anfang an einzubeziehen, damit nichts übersehen wird.

Wer und wann sollte ein Profiling im Projekt anwenden?

Profiling ist eigentlich immer sinnvoll, weil es schnell geht und dabei hilft, Zeit und Geld zu sparen. Wird es rechtzeitig in einer Voruntersuchung angewendet, schützt es unter anderem vor überzogenen Ergebniserwartungen. Bereits die Voruntersuchung zeigt nämlich, was mit den vorhandenen Daten überhaupt möglich ist.

Da zerplatzt sicher so mancher Traum …

Ja, aber das ist besser als ein böses Erwachen nach einem millionenschweren Investment und einem Jahr verlorener Zeit. Letzteres ist in der Praxis leider kein Einzelfall.

Daran habe ich noch gar nicht gedacht. Gilt das für alle Arten von Daten?

Ganz besonders gilt das für unbekannte Daten, etwa aus alten Bestandssystemen oder aus neuen Datenquellen wie Social Media. Es gibt aber auch ganz triviale Fälle, zum Beispiel, wenn Tochtergesellschaften Daten liefern, insbesondere bei internationalen Konzernen.

Das heißt, Profiling wird vor allem zu Beginn eines Projektes benötigt?

Nicht nur, auch im laufenden Betrieb ist Profiling eine große Hilfe. Zum Beispiel, wenn sich im Liefersystem etwas ändert. Plötzlich stürzen Programme ab oder die Qualitätsregeln schlagen vermehrt Alarm. Profiling bietet sich perfekt zur schnellen Hilfe bei der Ursachenanalyse an.

Danke, Karen, für diesen Ausflug in den Alltag von Data Governance. Ich würde sagen, der Teufel steckt tatsächlich im Detail. Und nur das Zusammenspiel aller Komponenten führt tatsächlich zum Erfolg. Neben den organisatorischen Anpassungen wird dafür sicher auch eine leistungsfähige Software benötigt.

Absolut, ein buntes Technologie-Sammelsurium erschwert einen effizienten Prozess. Die Kunst ist es, einen schlanken und robusten Prozess zu schaffen. Das geht nur mit guter Software.

Danke für deine Zeit!