Globales Business-Intelligence-System

Der Rückversicherer Munich Re setzt bereits seit 2006 erfolgreich die SAP-Reinsurance-Management-Lösung, bestehend aus den Modulen FS-RI, FS-CD und Business Partner, ein. Sie wurde zunächst für die Unternehmenszentrale in München und die Munich Re of America (vormals American Re) eingeführt.

Aus dem Reinsurance-Management-System werden die Daten zur Berichterstattung an ein Global Data Warehouse (GDWH) übergeben. Dies erfolgt täglich nach Zeitzonen getrennt. Zusätzliche Schnittstellen ermöglichen die Weitergabe der Daten vom GDWH an weitere Systeme, etwa an ein Global Planning System (GPS).

Damit wichtige Unternehmensdaten weltweit aktuell und konsistent zur Verfügung stehen, sollten die asiatischen Tochtergesellschaften vollständig in die SAP-Anwendungslandschaft von Munich Re integriert werden. Deshalb sollte die Reinsurance-Management-Lösung auch in Asien ausgerollt werden.

Rollout in Asien

Für die Realisierung des Projekts wurde ein Team aus Vertretern von Munich Re, MSG Systems sowie weiteren Partnern gebildet. Munich Re stellte neben der zentralen Projektleitung technische und fachliche Architekten sowie entsprechende Ansprechpartner vor Ort und in der Zentrale. Berater von MSG Systems erarbeiteten das fachliche Konzept für die Migration und unterstützten Planung, Entwicklung, Test und Produktivsetzung ihrer jeweiligen Teilbereiche bei Themen wie Datenkonvertierung und - übernahme, FS-RI, FS-CD, Business Intelligence (BI) oder Software- und Anwendungs- Management.

Anforderungen bei der Migration

Beim Rollout sollten auch die Daten aus den Vorsystemen migriert und in das bestehende Berichtswesen im GDWH integriert werden. Neben der bis dahin im Konzern verwendeten Konzernrechnungslegung nach HGB und IFRS mussten jeweils auch die lokale Rechnungslegung (LOCAL GAAP) sowie Besonderheiten der Tochtergesellschaften berücksichtigt werden. Ein typisches Beispiel war das versetzte Geschäftsjahr in Asien, das gerade im Abschlussreporting sehr komplexe Anforderungen mit sich bringt.

Zusätzlich gab es BI-spezifische Anforderungen: Die bisher auf Konzernebene gebuchten Daten und die zugehörigen Details, die im Rahmen der Migration eingespielt wurden, sollten auch die migrierten Altdaten (= Sicht „Historical Detail“) zeigen. (Konzern-)Altdaten und migrierte Daten waren aufgrund ihrer unterschiedlichen Genauigkeit allerdings nur teilweise vergleichbar.

Zu Projektstart arbeitete der Rückversicherer mit zwei getrennten Zeitzonen: Europa und Amerika. Die Daten der asiatischen Tochtergesellschaften waren in der europäischen Zeitzone integriert. Parallel zur Migration wurde eine eigene Zeitzone für die asiatischen Gesellschaften eingeführt. Die Datenversorgung in den drei Zeitzonen wurde optimiert und sorgfältig getrennt. Entsprechend dieser Zeitzonen wurden spezifische Stamm- und Bewegungsdatenprozesse geschaffen; die täglichen Ladeprozesse wurden nach Performance-Gesichtspunkten neu strukturiert und zu benutzergerechten Zeitpunkten eingeplant. Diese Änderungen hatten auch Auswirkungen auf die Prozesse während des Asia Rollouts.

Die Migration wurde in Teilschritte unterteilt. Bei der Einführung der neuen Zeitzone mussten Zeiträume, in denen sich alte und neue Zeitzone überlappen, gesondert ausgesteuert werden. Aufgrund des Datenvolumens, der Komplexität und der spezifischen lokalen Anforderungen wurde entschieden, den Rollout in drei Schritte zu gliedern.

Datenmigration in drei Schritten

Die Umstellung der Bestandführung auf FS-RI erfolgte in mehreren Schritten: Migration der Stamm- und Bewegungsdaten, inhaltliche Prüfung sowie Übergabe an das Reporting. Zuerst wurden die Stände für die sogenannten Bulk-Verträge zum Migrationszeitpunkt (HGB, IFRS) ausgebucht. Anschließend wurden die detaillierten Verträge aus den Vorverfahren initialisiert (HGB, IFRS, Local GAAP). Voraussetzung dafür war die Übernahme der entsprechenden Stammdaten aus den Vorsystemen; zusätzlich wurden auch die Buchungen zu diesen Verträgen vom Conversion Team in FS-RI und FS-CD übernommen.

Vermeidung doppelter Datenhaltung

Im GDWH sollten sowohl die über FS-RI und FS-CD gebuchten Altdaten als auch die Altdaten der gleichen Zeiträume aus den bisherigen asiatischen Vorsystemen vorgehalten werden. Zugleich sollten die Daten im Reporting so gesteuert werden, dass keine Dopplungen gezeigt werden. Die Daten aus der Migration und den Migrationsspeichern wurden daher in spezifische Provider geladen, um sie physisch zu trennen. So enthalten die produktiven Provider weiterhin ausschließlich die historischen und aktuellen Daten des Konzernabschlusses.

Die Konzernsicht zeigt nur die gebuchten Altdaten der Konzernabschlüsse aus der bestehenden Landschaft sowie alle weiteren Buchungen seit der Migration. Die Sicht „Historical Detail“ ist komplexer: Sie zeigt für den Zeitraum vor der Migration die Daten aus dem „Migrationsspeicher“ im BI-System, für den Zeitraum danach aber die gebuchten Daten der bestehenden Landschaft. Um hier die Darstellung doppelter Daten zu verhindern, wurde ein Mechanismus zum Ausbuchen solcher Daten (Counter Booking) geschaffen.

Berücksichtigung des „Time Zone Concept“

Das parallel zum Asia Rollout durchgeführte Projekt „Time Zone Concept“ beinhaltete unter anderem das Redesign und die Optimierung aller Ladeprozesse in das GDWH. Änderungen, die im Rahmen des Time Zone Concept umgesetzt wurden, mussten auch beim Asia Rollout berücksichtigt werden. Die Buchungen der asiatischen Tochtergesellschaften waren früher der europäischen Zeitzone zugeordnet. Im Rahmen des Asia Rollout musste diese Zuordnung zum Zeitpunkt der Migration auf die Zeitzone Asien umgestellt werden. Die Prozesse zur Migration und Einbeziehung neuer Daten in die Schnittstelle zum BI-System berücksichtigten aber automatisch die komplette Historie einer neuen Zeitzone.

Um die Übertragung zu vieler Daten zu verhindern, musste die Initialbeladung so umgestellt werden, dass das Laden der Zeitzone Asien exakt in dem Moment startet, in dem der letzte Ladezeitraum für die Zeitzone Europa endet. Damit konnte eine überschneidungsfreie, verkürzte erste Tagesscheibe erzeugt werden.

Projektablauf des Rollouts

Innerhalb der mehrstufigen Systemumgebung und der vorgegebenen Prozessumgebung mit ihren Release-Zyklen wurden im ersten Schritt alle Grundprozesse sowie die spezifischen Anforderungen des ersten Rollout-Blocks entwickelt. Für jeden der drei Teilschritte der Migration gab es mehrere Testzyklen auf speziell angelegten Kopien der produktiven Systemlandschaft. Hier wurden die einzelnen Schritte der Migration getestet: Migration von Stamm- und Bewegungsdaten, inhaltliche Prüfung sowie Übergabe an Reporting.

Für die produktive Durchführung der Migration war es notwendig, Beeinträchtigungen der Systeme während der Migration weitestgehend zu vermeiden. Allerdings stand im GDWH durch das tägliche Laden in drei Zeitzonen an normalen Tagen kein ausreichendes Zeitfenster für die umfangreichen Loads der Migration zur Verfügung. Daher musste die Migration an Wochenenden durchgeführt werden, währenddessen wurde das System für alle anderen Anwender gesperrt. Mit einem Rehearsal nach jedem Entwicklungsblock wurde der produktive Ablauf getestet. Die eigentliche Produktivsetzung und die Übergabe an Munich Re fanden an einem weiteren Wochenende statt.

Erfolgreiche Umsetzung nach anderthalb Jahren

Aufgrund der umfangreichen Entwicklungen, der Tests, Rehearsals und Produktivsetzungen dauerte das Projekt insgesamt anderthalb Jahre. Das Datenvolumen betrug je Teilschritt zwischen 3 und 20 Millionen Datensätze an der Schnittstelle zum Vorsystem. Durch die notwendigen Counter Bookings innerhalb des BI wurden weitere 5 Millionen Datensätze innerhalb des GDWH bewegt. „Trotz des großen Datenvolumens und der verschiedenen Aspekte, die bei der Migration berücksichtigt werden mussten, wurde das Projekt sehr erfolgreich umgesetzt“, sagt Peter Graup, Projektleiter bei Munich Re. „Ohne die hohe Kompetenz des gesamten Teams wäre dies nicht möglich gewesen“.

www.munichre.com/de

www.msg-systems.com

Bildquelle: Thinkstock / Comstock