Controlling und Test in der Migration: Ist doch alles das Gleiche – oder nicht?

In diesem Artikel möchten wir die Abgrenzung zwischen Controlling und Test bei einer Migration analysieren und dafür sensibilisieren, beide Themenfelder in einem Migrationsprojekt ausreichend zu berücksichtigen.

Betrachtung des Themenfelds Test in der Migration

Im Allgemeinen wird als Test in der Softwareentwicklung der Prozess bezeichnet, bei dem geprüft und sichergestellt wird, dass diese funktioniert, fehlerfrei ist, die Anforderungen erfüllt werden und die Qualität sichergestellt wird.

Die Anforderungen an einen Test sind insbesondere, dass …

• die spezifizierten Vorgaben erfüllt sind,
• das Ergebnis korrekt ist und der Erwartung entspricht,
• die Ergebnisse zuverlässig erzeugt werden und
• keine unerwünschten Nebeneffekte auftreten.

Hier kommt schon die erste Herausforderung: Die Beschreibung der fachlichen Anforderung, d. h. das Fachkonzept aus der Fachabteilung, muss die Anforderung so beschreiben, dass der Softwareentwickler das gleiche Verständnis dafür hat. Häufig entsteht das Problem, dass die Anforderung nicht klar kommuniziert wurde, und am Ende das Ergebnis der Umsetzung durch den Softwareentwickler nicht der Erwartung der Fachabteilung entspricht. Wenn beide Parteien in einem Haus sind, kann man darüber noch auf dem „kleinen Dienstweg“ diskutieren. Wenn sich aber die beiden Partner aus verschiedenen Häusern gegenüberstehen, hat man meist einen Auslöser für einen Change Request, der in der Regel zusätzliche ungeplante Ressourcen kostet.

Bei Erweiterungen im Kernsystem ist es ein allgemeines Ziel, das Risiko von Defects in der Produktion zu vermeiden, und ein noch höheres Ziel ist es, die Stabilität und Wartbarkeit beizubehalten oder zu erhöhen. Die letzten beiden Punkte kann man zwar als Ziele formulieren, die aber in der Realität nicht erreichbar sind. Alle neuen Anforderungen werden in ein bestehendes System als Erweiterung eingebaut. Wenn es aber eigentlich neue Funktionalitäten sind, müssten sie auch strukturell neu eingebaut werden.

Neue Strukturen und somit vielleicht auch Architektur-Diskussionen werden in der Migrationszeit nicht geführt. Meistens geht man hier einen schmalen Grat zwischen Abbildung alter Verfahren des Quellsystems und Verunstaltungen dadurch im neuen Zielsystem. Im Einzelfall kann es auch passieren, dass im Rahmen einer Migration so viele Regeln des Quellsystems eingebaut werden, dass sich die Wartbarkeit des neuen Systems gravierend verschlechtert. In der Migration hat man das Potenzial, Regeln auf den Prüfstand zu stellen und sie auf fachlicher Ebene zu bewerten und nicht im Zielsystem abbilden zu lassen. Aber dies ist dem Migrationsprojekt zur Entscheidung zu überlassen.

Fehlerklassen im Test

Nach erfolgreichem Abschluss des Tests sollte das Testergebnis sein, dass alle Fehler laut der Fachvorgabe behoben sind. Die Fachvorgabe war und ist die unterstellte Wahrheit auch zum Quellsystem. Im Quellsystem findet man oft Fehler und somit hat man Abweichungen zwischen der Umsetzung in der Quelle und im Ziel. Hier muss man zwischen verschiedenen Arten von Fehlern unterscheiden:

a) Es gibt Abweichungen, die tolerabel sind. Zum Beispiel sind bei einem Geschäftsvorfall Regeln definiert, die nicht eindeutig waren bzw. sind. Hier hat man heute bei modernen Zielsystemen neue und flexiblere Möglichkeiten, die weder Nachteile noch Vorteile für den Kunden haben.

b) Man findet Fehler, die sich aufgrund von gewollten Änderungen eingestellt haben: Man hat Rundungsregeln abgeschafft oder vielleicht den Rechenalgorithmus von Barwerten, die auf Kommutationswerten basieren, auf einen Markov-Ansatz umgestellt. Es entstehen Fehler, die man in gewisse Klassen und deren Größenordnungen einteilen kann und die tolerabel sind.

c) Es finden sich auch manchmal Fehler, die eine veränderte Abbildung im Zielsystem induzieren: Man hat einem Kunden z. B. Schlussüberschussanwartschaften garantiert. Dies führ dazu, dass man vielleicht zwei Schlussüberschussanwartschaften zu einem Vertrag oder Vertragsteil führt. Dies ist eine Besonderheit, die aber erklärbar und ausfinanziert ist und in einem Abschlussbericht festgehalten werden sollte.

d) Schwieriger ist es, wenn man Tarife im Altsystem findet, die man lt. Geschäftsplan überhaupt nicht haben dürfte. Je nach Grad der Plausibilitätsmöglichkeiten in einem Quellsystem findet man z. B. Tarife, die es beitragsfrei eigentlich nicht gibt, im Bestand aber zu finden sind. Diese Konstellationen sollten mit dem Verantwortlichen Aktuar geklärt und mit der BaFin abgestimmt werden. Sie sind somit ebenfalls im Abschlussbericht aufzuführen.

Fehlerklassen im Abschlussbericht

Im Abschlussbericht kann man sogenannte Fehlerklassen verwenden, um eine übersichtliche Clusterung der Ergebnisse zu erreichen. Wenn man Fehler für eine bestimmte Konstellation gefunden hat, sollte man hierfür eine eigene Fehlerklasse definieren und beschreiben. Meist hat solch eine Fehlerklasse auch einen Zusammenhang mit der Toleranzklasse im Controlling.

Der Abschlussbericht ist Basis für eine Abnahme der Softwareentwicklung.

Betrachtung des Themenfelds Controlling in der Migration

Die Betrachtung beginnt am Anfang des Projektes mit dem Ziel der Migration: Der einfachste und ordinärste Grund für eine Bestandsmigration sind Kosteneinsparungen. Um ein solches Sparziel zu erreichen, ist es empfehlenswert und betriebswirtschaftlich sinnvoll, dies in der Migration zu steuern. Diese Steuerung erfolgt über das Controlling, das grundsätzlich die Aufgabe hat Daten zu sammeln, aufzubereiten und zu analysieren. Dies entspricht dem Unternehmenscontrolling und unterscheidet sich nur in dem Tätigkeitsfeld. Dabei ist es wichtig, im Projektauftrag einer Migration ein konkretes Ziel festzulegen: Das ist das Budget, das im Projekt verwendet werden darf, um fachliche Sachverhalte umzusetzen. Dieses ergibt sich u. a. auch aus einer möglichen IT-Kostenersparnis, die durch einen Systemwechsel unter Betrachtung der heutigen Kosten vor vs. der für die Zukunft prognostizierten Systemaufwendungen nach Migration erzielt wird.

Die relevanteste Größe im Migrationscontrolling ist das Budget für die Migrationskosten. Diese enthalten auch die grundsätzlichen Migrationskosten für Systemverwaltungen, Personaleinsatz usw. Die hier betrachteten Migrationskosten im engeren Sinne beleuchten die Kosten in den Verträgen, d. h. die Abschluss- und Verwaltungskosten, die durch Abweichungen in den Verträgen zwischen Quell- und Zielsystem entstehen. Alle auftretenden Fehler, wie sie beispielhaft im Abschnitt zum Test schon mal genannt wurden, haben auch Auswirkungen auf das Controlling und beeinflussen die Migrationskosten.

Das Controlling ist eine Steuereinheit in der Migration. Es sind Kosten – einmalige und auch teilweise laufende Kosten – über die in der Projektlaufzeit berichtet werden sollte. Die erste zu beantwortende Frage ist, anhand welcher Werte man die Kosten definieren möchte. Für Aktuare ist es selbstverständlich, dass man dies an einer Differenz der Deckungsrückstellung festmachen kann. Je nach Migrationsalgorithmus kann es weitere wichtige Größen geben: z. B. Ansammlungsguthaben, Schlussüberschussstand mit und ohne Garantie, zukünftige Abschluss kosten etc. Hier können sich Werte ergeben, die durch den Migrationsalgorithmus besonders im Fokus stehen. Grund legend sind aber immer alle bilanzrelevanten Werte wichtig.

Toleranzklassen im Controlling

Unter der Prämisse, dass der Test korrekt ist und die Software korrekt funktioniert, wird durch das Controlling ein Kostenbericht erstellt und im Projekt fortlaufend aktualisiert. Ein Fortschrittsbericht offeriert die Möglichkeit, die Kosten der Migration zu überwachen und Optimierungen durch Tarifvereinfachungen etc. nochmals zu überdenken und neu zu entscheiden. Weitere Anpassungen können untersucht werden, um zukünftige Wartungskosten des Zielsystems zu reduzieren.

Um den Effekt von größeren Wertveränderungen zu erklären, kann man hierzu Toleranzklassen definieren und die Verträge entsprechend schlüsseln. Eine Toleranzklasse kann im Rahmen der Migration globale Anpassungen (z. B. für abgeschaffte Rundungen) wiedergeben oder für einzelne Maßnahmen (z. B. abgeschaffte Abschlusskosten bei einer Tarifzusammenlegung) definiert werden.

Toleranzklassen im Abschlussbericht

Im Controlling-Abschlussbericht kann man für Besonderheiten, aber auch nach Größenordnung Toleranzklassen festlegen. Bei einer Differenzierung nach der Größenordnung ist dies meist nicht einfach, da sich Toleranzen in absoluter wie relativer Abweichung positiv und negativ definieren können. Der Abschlussbericht ist ebenfalls die Basis für eine Abnahme der Migration. Insgesamt trägt das Controlling zur Transparenz, Koordination und Optimierung der Unternehmensaktivitäten bei. Das Controlling ist ein betriebswirtschaftlicher Prozess. Eine Korrektheit der Tarifabbildung im Zielsystem ist nicht originärer Bestandteil des Controllings und wird hierdurch nur implizit nachgewiesen. Für das Controlling werden betriebswirtschaftlich sinnvolle Grenzen festgelegt, die der zu migrierende Bestand und/oder die einzelnen Verträge einzuhalten haben.

Abschließend möchten wir Punkte in einer Migration aufzeigen, die unterschiedliche Auswirkungen und Beurteilungen in Test und Controlling haben.

Rundungen in der Migration

In vielen Migrationen kommt es zu einer Umstellung der Berechnungslogik. Beispielsweise rechnet das Quellsystem in klassischer Art und Weise mit Kommutationswerten. Häufig sind die Kommutationswerte tabellarisch hinterlegt und gerundet (z. B. auf 4 Nachkommastellen). Das Zielsystem hat einen Markov-Ansatz realisiert. Hier wird mit Zahlungsströmen sowie Zustands- und Übergangswahrscheinlichkeiten gerechnet und mit einem veranschlagten Zins bewertet. Der gesamte Rechenalgorithmus wird auf die systemseitige maximale Anzahl von Nachkommastellen abgestellt.

Nun kann man rein mathematisch beweisen, dass die reine Umstellung des Berechnungsalgorithmus keine Auswirkungen auf die Berechnung von Beitrag, Leistung und Deckungskapitalien hat. Die Auswirkungen von Abweichungen zwischen Ziel- und Quellsystem ergeben sich durch die Verwendung von Rundungsregeln. Die Rundungsregeln in den Quellsystemen sind sehr unterschiedlich. Wenn sich die Rundungen in der Umstellung gutartig verhalten, gehen sie über den gesamten Bestand gerechnet plus/minus null auf. Wenn man Rundungsregeln findet, die nur zum Aufrunden definiert sind, wird es schwieriger. Dies kann bei einem Vertrag zu substanziellen Abweichungen zwischen Quell- und Zielsystem führen. Hier sollte man sich die Mühe machen, dies vorab mathematisch zu bewerten und entsprechende Abweichungen und Toleranzen zu definieren. Mit der mathematischen Bewertung können auch die Abweichungen und Toleranzen erklärt und in der Migration akzeptiert werden. Es kann aber auch dazu führen, dass eventuell eine Nachfinanzierung für einen Teilbestand notwendig wird. In der Summe darf kein Kunde schlechter gestellt werden.

Fazit: Rundungen im Quellsystem sind vielfältig und deren Auswirkungen im Rahmen einer Migration in ein modernes System können für das Controlling und auch den Test abgeschätzt werden. Die Rundungsabweichungen fallen sowohl im Test als auch im Controlling auf.

Nachreservierungen in der Migration

Des Weiteren sollte man immer das Thema Nachreservierung, die auch außerhalb des Quellsystems ermittelt werden kann, intensiv betrachten. Es kann vorkommen, dass man bei älteren Quellsystemen die Nachreservierungen regelrecht suchen muss. Wenn eine Nachreservierung für einen Teilbestand vorliegt, kann es vorteilhaft sein, die Ausfinanzierung für die einzelnen Verträge zu prüfen. Wenn man zu dem Schluss kommt, dass die Verträge hinreichend ausfinanziert sind, könnten die Nachreservierungsbeträge den Verträgen zugewiesen werden, indem man die Rechnungsgrundlagen in der Migration entsprechend auf die Rechnungsgrundlagen der Nachreservierung umstellt. Wenn man dies über eine Zuführung ins Deckungskapital macht, führt dies zu einer Fehlerklasse, die vertragsindividuell erklärt werden muss, aber dann zur korrekten Bewertung eines Vertrages führt. Im Testbericht werden die Verträge als korrekt migrierbar ausgewiesen.

Im Controlling sieht die Auswirkung etwas anders aus: Man vergleicht den Auflösungsbetrag der Nachreservierung aus dem Quellsystem mit der Summe der zugewiesenen Aufstockungen durch den Wechsel der Rechnungsgrundlagen im Zielsystem. Wenn die Aufstockung im Zielsystem größer als die Auflösung im Quellsystem ist, sind die zusätzlich erforderlichen Mittel aus dem Eigenkapital zu finanzieren. Umgekehrt werden freiwerdende Mittel an den Versichertenbestand ausgeschüttet. Dies kann geeignet durch eine Überschusszuteilung erfolgen oder auch über eine extra Aufstockung ins Deckungskapital und sollte davon abhängig gemacht werden, ob die Verträge rückkaufsfähig sind oder nicht. Im Controllingbericht erfolgt nun die betriebswirtschaftliche Interpretation: Die Auflösung wird beschrieben und beziffert sowie auch die Aufstockung im Zielsystem. Je nach Ausgestaltung des Verfahrens muss die bilanzielle Auswirkung beschrieben und bewertet werden.

Fazit: Die Umstellung der Nachreservierung wird im Test und Controlling unterschiedlich bewertet, was entsprechende Auswirkungen auf die jeweiligen Abschlussberichte hat.

Zinszusatzreserve in der Migration

Die Zinszusatzreserve (ZZR) wird häufig nicht im alten Quellsystem ermittelt, da dieses z. B. den Wechsel des Rechnungszinses nicht umsetzen konnte. Bei einer Migration wird die ZZR dann im Zielsystem umgesetzt. Die Verfahrensweise der Berechnungen zwischen altem Neben- und neuem Zielsystem unterscheidet sich dabei i. d. R. Dies kann aus einer Bestandsclusterung herrühren oder aus einer abweichenden Umsetzung der Quelltarife im alten Nebensystem. Durch die Migration kann es somit zu Abweichungen in der Höhe der ermittelten ZZR kommen. Die Auswirkung ist nicht einzelvertraglich relevant, sondern nur über den gesamten Bestand in Bilanz und GuV. Hier findet dann eine Zuführung oder ein Freiwerden von Deckungskapital statt. Das Ergebnis des Geschäftsjahres nimmt diese Schwankung bei Migration und Wechsel der Systeme auf.

Im Test fällt diese Verfahrensumstellung in der ZZR häufig nicht auf, da diese Größe häufig nicht getestet wird, weil die ZZR ein rein bilanzieller und kein kundenrelevanter Wert ist. Aus Sicht der Bilanzstetigkeit sind die Schwankungen der ZZR über den migrierten Bestand aber durchaus relevant. Im Controlling lassen sich diese feststellen, wenn die Daten für die ZZR aus den alten Nebensystemen oder der Quelle und die Ergebnisse der Berechnung im Zielsystem miteinander abgeglichen werden. Die Schwankungen im Deckungskapital bzw. in der ZZR als Davon-Position können analysiert und bewertet werden.

Alle Änderungen führen zu einer Veränderung in der Bilanz, die im Sinne einer Bilanzstetigkeit nicht gewünscht ist. Gleichwohl kann eine solche Veränderung zu einer Änderung im Geschäftsjahres-Ergebnis führen, die frühzeitig berücksichtigt werden sollte.

Fazit: Das Thema Zinszusatzreserve kann im Quellsystem vielfältig abgebildet sein, was zu Schwierigkeiten in der Datenbereitstellung für einen eventuellen Test und im Controlling sorgen kann. Die Auswirkungen auf Test und Controlling können sich zwischen einzelnen Verfahren unterscheiden. Die Bewertung der Bilanzauswirkung bzw. der Auswirkung auf das Geschäftsjahres-Ergebnis können im Controlling erfolgen.