Die Host-Ablösung: Ein Weg aus der Legacy-Steinzeit

Warum hatte die WWK 2019 zwei Lebensversicherungssysteme im Einsatz?

Als die WWK Versicherung im Jahr 2005 mit ihrer IT-Tochtergesellschaft, intersoft AG, das damals neue lifestream-System als Kernsystem für ihre neuen Lebensversicherungsverträge einführte, wurden die bestehenden Altverträge zunächst nicht in das neue System übernommen. Diese strategische Entscheidung nahm viel Komplexität aus dem Projekt und war damals für den Projekterfolg wesentlich. Der Preis dafür war, dass die bestehenden Verträge weiterhin auf dem BS2000-Host-System mit dem Namen IBIS (in COBOL und Assembler programmiert, siehe Abbildung 1) geblieben sind.

Somit hatte die WWK zwei Systeme, ein modernes Java-System und ein COBOL/Assembler-System mit vielen hunderttausend Verträgen, die 2005 noch bis zu 60 Jahre Laufzeit hatten.

Es war immer klar, dass später auch das alte System abgeschaltet werden muss und die dann noch aktiven Verträge in das lifestream-System migriert werden würden. Denn die Kosten für Wartung und Betrieb des alten Systems übersteigen irgendwann die Kosten einer Migration. Vor allem aber sind inzwischen die meisten COBOL-, Assembler- und Host-Experten für das alte IBIS-System im Ruhestand und das benötigte Know-how kann mit dieser Technologie nicht auf Dauer mit wirtschaftlich vertretbarem Aufwand aufrechterhalten werden. Dadurch ergeben sich relevante und steigende Risiken für den Betrieb und die Kosten.

Die Entscheidung zur Migration und der nachfolgenden Abschaltung des Host-Systems wurde 2019 getroffen und bis Ende 2023 lief das Migrationsprojekt. Für diesen Erlebnisbericht wurden Nadine Henzelmann als Agile Coach, Marc Köpcke als Product-Owner und Christoph Burmeister als Head of Architecture interviewt.

Ein Statement der Auftraggeberseite gibt Dr. Henri Siemens als Head of IT der WWK.

Was war der Auftrag, Herr Dr. Siemens?

„Die Zeit der Großrechner bei der WWK ist endgültig vorbei“, betont Dr. Henri Siemens. „Als wir gemeinsam mit den betroffenen Bereichen der WWK und der intersoft die Entscheidung trafen, Anfang 2024 den Host abzuschalten, war uns bewusst, dass wir mit der dafür nötigen Migration ein mehr als herausforderndes Projekt mit einem ambitionierten Zeitplan starteten. Immerhin galt es, etwa 300.000 Lebensversicherungsverträge des Alt-Systems mit über 100 unterschiedlichen Tarifen in unser lifestream-System zu überführen. Dazu benötigten wir neben migrationserfahrenen und verlässlichen Projektpartnern vor allem ein Projektteam, das sich im Sinne eines kontinuierlichen Verbesserungsprozesses während der Umsetzung selbst optimiert. Und das damit bei der Bereitstellung von Migrationsprodukten und der Durchführung der Migrationen ständig besser und schneller wird. Der Endtermin für die Host-Abschaltung war durch unseren Leasing-Vertrag fest vorgegeben und oberstes Ziel war es, keine neue Leasing-Periode zu benötigen. Meine Botschaft an den Gesamtvorstand war einfach: Der Mainframe ist leider kein Bordeaux – er wird nicht besser, wenn er im Keller steht.“

Steinzeit? – COBOL und BS2000 im Legacy-System

Das Betriebssystem BS2000 der Firma Siemens ist wirklich uralt. Es wurde zunächst auf Großrechnern schon 1975 auf den Markt gebracht. Es ist deshalb schwer vorstellbar, dass im Jahre 2023 diese alte Technik noch im Einsatz war, um mehrere hunderttausend Versicherungsverträge im Bestand bearbeitbar zu halten. Der Softwarearchitekt des intersoft-Migrationsteams, Christoph Burmeister, erklärt, dass heutzutage das Hosting des BS2000-Betriebssystems virtualisiert und kompakt in einem 19-Zoll-Rack im Rechenzentrum erfolgt. Die nötige Hardware kann von Fujitsu geleast werden. Das ist zwar teuer, aber möglich. Viel problematischer ist es, oft notwendige Änderungen, etwa durch regulatorische Änderungen, durchzuführen. Es gibt schlichtweg „kaum, noch Experten, die nicht schon in Rente sind“, sagt Christoph weiter. „COBOL und Host-Assembler sind fast vergessene Technologien, sie sind immerhin schon über 50 Jahre alt. Und für Fujitsu tut sich durch den Expertenmangel eine Goldgrube auf, denn der Bedarf nach COBOL- und Host-Schulungen steigt an.“

Team-Verantwortung zu dritt – ein gutes Pattern?

Normalerweise wird in Projekten eine Person verantwortlich als Projektleiter eingesetzt. Ein Pattern, das Unternehmen klassischerweise seit Jahren mit wechselndem Erfolg in Projekten anwenden. Damit lastet die gesamte Verantwortung auf zwei Schultern und die tragen das vom Auftraggeber gewünschte Single-Wringable-Neck. Für die Gesamtprojektleitung bei der WWK gab es eine Projektleitung, für das Teilprojekt der Produktentwicklung und Migration hat intersoft sich mit seiner agilen Aufstellung gegen den „typischen“ Ansatz entschieden und drei Führungskräfte eingesetzt. Das ist ein weniger bekanntes Pattern, das sich beispielsweise schon bei anderen Unternehmen als sehr erfolgswirksam gezeigt hat. So haben sich Nadine Henzelmann, Marc Köpcke und Christoph Burmeister im Führungsteam die Aufgaben fachlich geteilt. Marc als Product-Owner ist verantwortlich für die korrekte Umsetzung der Produktanforderungen, Nadine als Agile Coach für reibungsfrei laufende Prozesse im Team und zum Kunden, Christoph als Tech-Lead für alle technischen Fragen.

Nadine, Marc und Christoph sagen heute fast wortgleich: „Wir waren ein eng zusammen arbeitendes Führungsteam. So haben wir immer die gleichen Signale an das Team gegeben, auch unter Druck. Und das, obwohl wir drei echt unterschiedliche Typen sind und auch unterschiedliche Aufgaben hatten. Wir konnten uns hervorragend vertreten, sodass sogar ganz normale Urlaube in diesem anspruchsvollen Projekt möglich waren.“

Warum ist Dokumentation bei Lebensversicherungen so wichtig?

Die Konzepte (Lastenheft, Fachkonzept, Geschäftspläne) sind im Lebensversicherungsbereich als fachliche und technische Dokumentation der umgesetzten Versicherungsverträge von zentraler Bedeutung. Denn diese sind regulatorisch von der BaFin und den Wirtschaftsprüfern gefordert. So muss die Versicherung nachweisen, dass die angebotenen Tarife entsprechend den starken Regularien umgesetzt worden sind. Aber ebenso wichtig ist die detaillierte fachliche und technische Dokumentation aufgrund der langen Laufzeit der Verträge.

Ein Versicherungsvertrag kann eine Vertragslaufzeit von 60 Jahren und mehr haben, also sehr viel länger als das durchschnittliche Alter von Software. Ohne entsprechende Dokumentation ist ein Refactoring von Legacy damit unmöglich. Vergangene Paradigmen wie „the code is the documentation“ reichen hier nicht aus und sind nicht anwendbar.

Welche besonderen Herausforderungen gab es?

Marc, der Product-Owner (PO), hat während des Migrationsprojekts einen guten Teil der über 150-jährigen Geschichte der WWK Versicherung wieder erlebt. Der älteste migrierte Vertrag stammt aus dem Jahr 1930. Wie kann das sein? Marc hat das für das Interview recherchiert und von einer Kollegin im Kundenservice folgende Antwort bekommen: „Der Vertrag ist schon sehr alt, wobei ich nicht glaube, dass der ursprüngliche Versicherungsbeginn 1930 ist. Ich denke, das ist eher der technische Versicherungsbeginn, der durchaus so weit in die Vergangenheit verschoben worden sein kann. Er müsste zwischen 1934 und 1949 abgeschlossen worden sein, wenn man der Schlüsselzahl aus IBIS und meiner Tarifübersicht glaubt.“ Marc weist darauf hin, dass dieser Vertrag schon eine Migration damals in den 60er- oder 70er-Jahren von Papier in das IBIS-System hinter sich hat.

Christoph berichtet von Sterbetafeln aus dem Jahr 1924 (siehe Abbildung 3), die für eine Berechnung eines uralten Tarifs relevant waren.

„Die lagen uns als kaum lesbarer Scans vor. Das ist schon irre, dass wir fast 100 Jahre in der Firmengeschichte zurückgehen mussten. Die Herausforderungen waren also vielfältig, wir hatten es mit einem unfassbar alten Bestand zu tun, mit Tarifen, deren Eigenschaften wir aus den alten Geschäftsplänen neu herausfinden mussten, und mit einer Migrationstechnik, die wir uns eigens für das Projekt aufgebaut haben.“

Lebensversicherungsverträge laufen nun mal sehr lange, erzählt Christoph. „Wenn Eltern für ihr Kind einen Vertrag abschließen, kann der 60 bis 70 Jahre laufen. Dementsprechend alt waren die Dokumente, mit denen wir arbeiten mussten. Teilweise lagen die nur als schwer lesbare Scans vor, die wir so lesen mussten, weil OCR oft versagte.“ (siehe Abbildung 4)

Projektstart 2019 im fünfköpfigen Rumpfteam

Nadine, Agile Coach im Projekt, berichtet, dass im Jahr 2019 nur ein kleines Rumpfteam von fünf Personen unter sehr hohem Ergebnisdruck startete. Das warenn eine Business-Analystin und vier Entwickler. „Wir sind von Anfang an gegen die Zeit gerannt und haben immer das Gefühl einer Aufholjagd gehabt. Es fühlte sich in den ersten Monaten oft so an, als ob wir Zeit vertrödeln würden. Der erste Vertrag wurde am 13.7.2020 migriert, also 1,5 Jahre nach Projektstart, denn zunächst musste der passende Tarif im Zielsystem gebaut werden. Und dazu mussten die alten Geschäftspläne vollständig verstanden sein. Es war klar, dass wir es mit dem Tempo niemals schaffen können. Dann haben Marc, Christoph und ich uns die Gesamtsituation angesehen und analysiert, was alles schief hing. Als Erstes war klar, dass wir für die große Aufgabe viel zu wenig ExpertInnen an Bord hatten. Ein großer Erfolgsfaktor war es dann, gleich fünf weitere Personen auf einmal einzuarbeiten. Einarbeitung ist im Lebensversicherungsumfeld sehr aufwendig, da die in den Verträgen liegende Mathematik schwer lernbar ist und die Software ebenfalls sehr komplex ist.

Einarbeitung senkt die Performance und kostet Zeit, die wir eigentlich nicht hatten. Das gebündelte Einarbeiten in Gruppen war einer der Erfolgsfaktoren, den wir nachfolgend auch mehrfach wiederholten. Wir haben dann auch alle Teilerfolge gefeiert, die Leute aus der Corona-Diaspora zusammen geholt und das auch, als wir ca. 20 Personen im Team waren.“

Am Anfang war das Migrationsteam langsam. Aber durch beständiges Lernen und durch schrittweise Parallelisierung von Teilmigrationen wurde die Geschwindigkeit in den viereinhalb Jahren Projektverlauf immer größer. So wurde der Projektdruck auf immer mehr erfahrene Schultern verteilt. Das Team wuchs unter dem äußeren Druck und den schrittweise immer größeren Teilerfolgen richtig gut zusammen. Dieser gute Teamspirit ist auch einer der Erfolgsfaktoren.

Der Prozess mit 5 Quality-Gates als regulativer Rahmen

Bei der WWK werden Softwareprojekte grundsätzlich in einem fünfstufigen Prozess mit Quality-Gates durchgeführt. Die Stufen sind 1. Konzeption, 2. Entwicklung, 3. Tests der Komponenten, 4. Qualitätssicherung durch den Gesamt-Integrations-Test und 5. Abnahme und Freigabe gemäß regulatorischer Vorgaben (siehe Abbildung 5).

Aktuell wird dieser Prozess in sechs Iterationen pro Jahr durchgeführt. Das klingt sehr nach Wasserfall und das ist es auch in Teilen.

Jedoch läuft die Entwicklung agil, inkrementelle Softwarelieferungen erfolgen wöchentlich und die Verzahnung der Prozessteile in crossfunktionalen Teams nimmt stetig zu. Marc berichtet, dass diese kleinteiligen Agilisierungsschritte und die enge Verzahnung mit der Auftraggeberseite in München ein wesentlicher Erfolgsfaktor im Projekt waren.

Migrationsstrategie und die Priorisierung der Themen

Die richtige Priorisierung ist in agilen Vorhaben die Königsdisziplin des Produktmanagements. Wahrscheinlich antwortete Marc im Interview deshalb mit großer Begeisterung auf Fragen nach Strategie und Prioritäten: „Ca. 300.000 Verträge, 104 Tarife, die es zu migrieren galt, haben wir in 15 Produktgruppen abgearbeitet. Dahinter stand auch die Überlegung, dass wir uns Produktgruppen ausgesucht haben, die aufeinander aufbauten, um immer lernen zu können. Natürlich haben wir uns auch angesehen, welche Produktgruppen wenige Verträge enthielten, und erst einmal alles gemacht, was wir als hohes Risiko eingeschätzt haben. Also mit kleineren Dingen früh lernen, aber auch die großen Risiken zuerst angehen.

Auch die in den drei Jahren zu erwartenden Rentenabgänge haben wir versucht, möglichst geschickt zu berücksichtigen. So haben wir einige Tarife bewusst zu späteren Zeitpunkten migriert, weil die Menge der zu migrierenden Verträge dadurch sehr klein wurde.

Immer, wenn wir vom Vorstand gefragt wurden, ob wir rechtzeitig fertig werden, haben wir unser Vorgehen analysiert und geprüft, ob wir realistisch mit dem aktuellen Vorgehen am Ziel ankommen werden. Mit solchen Projektionen konnten wir frühzeitig Maßnahmen vorschlagen und Anpassungen vornehmen, um rechtzeitig das Ziel zu erreichen.“

Maximale Parallelität durch einen Phasen-überlappenden Entwicklungsprozess für die Migrationstarife

„Im Migrationsprojekt haben wir uns iterativ an den Punkt herangearbeitet, an dem unsere EntwicklerInnen mit der Umsetzung beginnen konnten. Dabei ging es uns darum, den zu migrierenden Tarif konzeptionell so gut verstanden und beschrieben zu haben, dass die Entwicklung mit ersten Teilen starten konnte. Im Projektverlauf sind wir dabei stetig besser geworden. Immer wenn das Konzept des ersten Arbeitspakets für einen Tarif fertig war, begann die Entwicklung. Sobald die ersten abgleichenden Berechnungen des Rechenkerns programmiert waren, begannen bei der WWK in München auch schon die ersten Tests mit Referenzwerten aus der Mathematik. Diese enge Verzahnung hat sich am Ende richtig cool angefühlt. „Wir haben das Projekt in allen Teilen zerlegt, um möglichst viel Agilität, Sicherheit und Lernen zu ermöglichen und Fehler möglichst früh aufzudecken. So haben wir einen stabilen und wiederverwendbaren Migrationsprozess für unsere 104 Tarife aufgebaut“, berichtet Marc.

Marc erzählt von der agilen Maxime, immer so früh wie möglich Wert zu liefern. Dazu wurden für jeden der 104 Tarife die folgenden Schritte durchgeführt und so der Erfolg des migrierten Tarifs sichergestellt:

1. Migrationszugang schaffen: Das Team stellte sicher, dass der erste Vertrag überhaupt erfolgreich migrierbar ist. Das Ergebnis konnte die WWK dann direkt prüfen und qualitätssichern.
2. Kalkulation: Der Tarif wird im Zielsystem lifestream erzeugt. Nun wird geprüft, ob der Tarif im neuen System richtig rechnet, auch bei allen denkbaren Sonderfällen. Die versicherungstechnischen Erwartungswerte wie das Deckungskapital werden zwischen Quell- und Zielsystem lifestream mithilfe von Referenzwerten abgeglichen.
3. Bestandsfortschreibung: Sobald die Migration der einzelnen Verträge erfolgt, wird nach jedem Migrationsschritt geprüft, ob die Gesamtbilanz des Tarifs über beide Systeme identisch ist. Es geht also kein Geld verloren oder kommt hinzu.
4. Planmäßige Fortschreibung für ein Jahr: Nachdem alle Verträge migriert wurden, wird überprüft, ob der Zustand der Verträge nach einem Jahr Alterung immer noch zu keinen Abweichungen zwischen dem Quell- und dem Zielsystem führt.

Die technischen Rahmenbedingungen

Architekt Christoph berichtet, wie wichtig es war, möglichst früh mit der technischen Migration zu beginnen. „Wir hatten von Anfang an EntwicklerInnen im Projekt und kümmerten uns darum, erst einmal herauszufinden, wie wir überhaupt erfolgreich Verträge migrieren können.“ Technisch erfolgte die Migration von Verträgen grob vereinfacht in fünf Schritten:

1. Daten werden im IBIS-System zur Migration aufbereitet.
2. Mit einem Werkzeug erfolgte der Export in eine XML-Struktur.
3. Die in XML bereitgestellten Daten werden in das Zielsystem lifestream importiert.
4. Über Controlling-Werte aus IBIS und lifestream wird einzelvertraglich sichergestellt und dokumentiert, dass die Migration erfolgreich durchgeführt beziehungsweise im Fehlerfall abgebrochen wurde.
5. Die erfolgreich migrierten Verträge werden im IBIS-System als migriert markiert.

„Dieses Vorgehen wurde durch Wirtschaftsprüfer geprüft und bestätigt. Im Projekt haben wir uns bemüht, für die einzelnen Schritte schon Qualitätssicherungen zu machen. Dadurch wurde unsere Migrationsmaschine im Projektverlauf immer leistungsfähiger“, erklärt Christoph.

Projekt remote – mit 20 Leuten in der Corona-Diaspora

Kurz nachdem das Projekt gestartet war, brach Corona aus und ab März 2020 lief das Projekt für drei Jahre unter Pandemie-Auflagen, die ein persönliches Treffen bestenfalls gelegentlich und nur vollständig getestet erlaubten. Die gesamte Arbeitsweise wurde auf standortübergreifendes, verteiltes Arbeiten eingerichtet.

Nadine berichtet, wie herausfordernd es war, ein Teamgefühl mit 20 verteilten Team-Mitgliedern zu schaffen. Dabei halfen die regelmäßigen Routinen, die Daily-Standups, die Struktur mit Scrum und zweiwöchigen Sprints und auch die zweimal in der Woche stattfindenden virtuellen Treffen mit dem Kunden.

Nadine: „In regelmäßigen Abständen haben wir uns vor Ort getroffen, immer wenn es mit der Corona-Inzidenzrate gerade ging, und natürlich unter Einhaltung aller Auflagen. Uns hat Corona auch geholfen, denn die Disziplin musste einfach groß sein. Außerdem konnten wir so selbstverständlich Projekt-Mitarbeitende, besonders unsere externen BeraterInnen aus ganz Deutschland, aufnehmen. Vor Corona wäre das nur mit sehr viel Reisetätigkeit möglich gewesen.“

Die Projektkrise im Herbst 2020

Marc als PO berichtet, dass es im Herbst 2020 zu einer Krisensitzung mit dem Lenkungsausschuss kam (siehe Abbildung 8).

Es wurde damals deutlich, dass bei dem aktuellen Umsetzungstempo das Projektziel der Fertigstellung im Jahr 2023 nicht haltbar wäre. „Das war eine unangenehme Situation. Aber wir bekamen für die Deutlichkeit und Transparenz von unserem Vorstand Dirk Fassott auch Dank. Immerhin hatte die WWK dadurch die Möglichkeit, noch rechtzeitig zu reagieren. In der Folge stockten wir das Projektteam deutlich auf und begannen, immer stärker unnötige Projektthemen zu identifizieren und zu de-priorisieren. So haben wir uns für Tarife, die nur sehr wenige Verträge enthielten, mit dem Fachbereich zusammengesetzt und nach manuellen Lösungen gesucht, um nicht aufwendig einen neuen Tarif implementieren zu müssen. Und seltene Geschäftsvorfälle haben wir in unseren sogenannten Rucksack für die spätere Umsetzung gepackt.“

Erfolg durch enge Verzahnung

Nadine erzählt, wie die traditionelle Arbeitsweise mit Anforderungsabstimmungen und Softwarelieferungen alle acht Wochen zwischen der Anforderungsseite in München und der Umsetzung in Hamburg durch zweimal wöchentlich stattfindende Meetings und die wöchentlichen Softwarelieferungen ergänzt wurde. So wurde die Zusammenarbeit zwischen der WWK und intersoft immer enger. Die vormals alle acht Wochen stattfindenden Anforderungsworkshops mitten in der Corona-Hochzeit wurden durch wöchentliche Meetings zu Konzeptständen ergänzt. Das führte Schritt für Schritt zu einer immer engeren Verzahnung.

„Jede Woche haben wir unsere Konzepte zur Prüfung verschickt und die Softwarelieferungen zum Test bereitgestellt. Ohne diese immer engere Verzahnung hätte es nicht funktioniert. Zu zwei Dritteln der Laufzeit schalteten wir dann von sechs Produktinkrementen pro Jahr auf monatliche Lieferung um.“

Kulturunterschiede zwischen Hamburg und München

Marc erläutert, dass die WWK in München bei Planung und Projekten eher in großen Rhythmen denkt, die intersoft AG in Hamburg dagegen in kleinen agilen Schritten arbeitet. „Es existieren große Unterschiede. Das Ganze war ein Projekt mit Risiken. Zusammengekommen sind wir darin, dass beide Parteien immer am Fertigstellungstermin Ende 2023 festgehalten haben. Die Lieblingsfrage des Vorstands Dirk Fassott war immer, werdet ihr den Termin halten? Diese Fokussierung auf Pünktlichkeit war die Brücke zwischen Agilität und dem goldenen Dreieck eines klassischen Projekts, also Budget, Inhalt und Fertigstellungszeitpunkt. Hier haben wir immer die fristgerechte Lieferung in den Vordergrund gestellt. Inhalte, die später auch kommen können, priorisierten wir in unserem Rucksack, ein Folgeprojekt. Das intersoft-Projektteam wuchs zwischenzeitlich auf 20 Personen an. Aber den Zeitpunkt haben wir gehalten und dafür konnten wir unsere agile Erfahrung mit starker Priorisierung, kleinen Iterationen und beständigem Lernen auf der Strecke einbringen.“

Was funktionierte nicht?

Nadine: „Ich würde niemals mehr ein solch großes Projekt mit so wenigen Leuten starten. Das Anfangsteam war einfach zu klein. Auch die Sichtung der alten Geschäftspläne hätten wir früher und intensiver in Vorarbeit machen sollen. Damit haben wir sehr viel Zeit verloren. Später im Projekt hatten wir externe Aktuare, die diese notwendigen Analysen für das Projekt machten. Auch das Feiern von Erfolgen hätten wir besser machen können. So hätten die unterschiedlichen Kulturen zwischen Hamburg und München besser ausgeglichen werden können. Doch das war durch Corona erheblich erschwert.“

Marc: „Wir haben auf der Strecke viel gelernt. So haben wir anfangs oft Geschäftsvorfälle umgesetzt, bei denen wir später im Projekt feststellten, die benötigen wir gar nicht oder nur dreimal im Jahr. Wir lernten, auf Basis von Fallzahlen und Workaround-Umfängen zu entscheiden und gegebenenfalls abzugrenzen. Später im Projekt wurden wir immer selektiver und haben uns den bereits erwähnten Rucksack von Themen gemacht, die wir auch ohne Zeitdruck im kommenden Jahr noch umsetzen können. Mit der Erfahrung von heute hätten wir das Ziel, pünktlich zu liefern, noch besser erreichen können. Denn für die eigentliche Migration waren diese Aufgaben nicht nötig.“ Christoph: „Die Art und Weise, wie Produkte im Rechenkern umgesetzt werden, war anfangs zu wenig standardisiert. So haben wir uns mit den ersten Produkten schwergetan. Durch gezieltes Refactoring und eine andere Strukturierung haben wir es geschafft, dass wir Produkte immer schneller bauen konnten. Auch die Fehlerquote war anfangs sehr hoch. Code-Vereinfachungen und eine Teststrategie mit frühestmöglichem Testen haben uns hier geholfen.“

Wie ist das neue System für die SachbearbeiterInnen?

Auf die Frage an Marc, was die Migration für die BenutzerInnen bedeutet, antwortet eine Vertreterin der Abteilung Kundensupport: „Kurzfristig zieht die Host-Ablösung erst einmal Mehraufwände nach sich, zum Beispiel zusätzliche Workaround-Aufwände und Change-Prozesse bei einigen KollegInnen. Langfristig sollte es mit nur noch einem Bestandssystem einfacher werden, zum Beispiel keine Erstellung/Anpassung von Arbeitsanweisungen mehr für ein zweites Bestandssystem, keine komplizierten IBIS-Ertragsausschüttungen mehr, Umsetzung von gesetzlichen Anforderungen nur noch für ein Bestandssystem. Aber natürlich gibt es auch SachbearbeiterInnen, die dem Host-System IBIS etwas nachtrauern. Sie kannten den Workaround in- und auswendig und die benötigten Befehle zum Bearbeiten von Verträgen waren im Fingergedächtnis.“

Fazit

Eine erfolgreiche Host-Migration mehr. Der letzte Lebensversicherungsvertrag der WWK wurde am 18.1.2024 vom Host migriert. Zum Erfolg hat beigetragen, dass die gesamte Organisation auf dem Weg das Projekt angepasst hat. Dazu gehört als Erstes das schnelle Erkennen von Holzwegen, dann das Sprechen darüber und schließlich das Ableiten von Maßnahmen. Dieses Lernen auf der Strecke ist nur durch Vertrauen, Transparenz, Beweglichkeit und das Festhalten an kritischen Zielen, in diesem Fall der Fertigstellungstermin, möglich.

Und, wie das Projektteam immer wieder betont hat, war das Feiern von Teilerfolgen wichtig. Wie geht es nun im Jahr 2024 weiter? Na ja, sagt Nadine. „Wir haben mit den Themen im sogenannten Rucksack mit dem verkleinerten Team noch etwas zu tun. Und dann wollen wir alles, was wir in der Produktivität und der Zusammenarbeit mit der WWK gelernt haben, auch in den Rest der Organisation zurücktragen, also die enge, standortübergreifende Zusammenarbeit, häufigere Releases, strenge Priorisierung und intensiveres Feiern von Erfolgen.“

---

Das Aufmacherbild wurde mittels KI generiert