Uitfasering van legacy systeem: de datamigratie

DE VRAAG

Verouderde legacy systemen zijn een grote kostenpost voor verzekeraars, zeker wanneer deze draaien op een verouderde IT infrastructuur. Een grote verzekeraar koos daarom voor de uitfasering van één van hun legacy applicaties, de polis- en claimsadministratie. Een deel van de geadministreerde producten in deze applicatie was niet meer in lijn met de huidige productstrategie van de opdrachtgever. Daarom is besloten om het beheer en de uitvoering van deze portefeuille uit te besteden aan een serviceprovider in plaats van te migreren naar interne applicatie. Wij ondersteunden de verzekeraar met de data migratie naar deze serviceprovider: van opstellen van de strategie tot de daadwerkelijke migratie.

ONZE AANPAK

Hoe je dit aanpakt? Met onze gestandaardiseerde en gecontroleerde migratie-aanpak hebben wij ondersteund in de rollen van Product Owner, Business Analist, IT manager en Projectleider. Het migratietraject werd opgedeeld in de volgende vier stappen.

 

1.     Keuze serviceprovider en aanvraag DNB

Eerst werd gekozen naar welke serviceprovider de portefeuille gemigreerd zou worden. Vanwege de complexe producten, vele werkzaamheden en strakke deadline voor de migratie van de portefeuille, was er behoefte aan een ervaren en inhoudelijke partij. Na de keuze werd de samenwerking tussen de verzekeraar en serviceprovider aangemeld bij de DNB. Een belangrijke stap, want zonder toestemming van DNB voor de samenwerking kan de migratie niet plaatsvinden.

 

2.     Voorbereiding migratie

Ten tweede werden de volgende onderdelen geanalyseerd en in kaart gebracht:

• De implementatie van de interfaces met externe systemen. Denk aan de koppeling met:
  • een verloningspakket t.b.v. het uitkeren van claims;de ADN berichtenservice om te communiceren met verzekeringsadviseurs;
  • de belastingdienst om zo de jaarlijkse premierenseignering mogelijk te maken.
• De managementinformatie die de serviceprovider, na conversie, moet leveren aan de verzekeraar. Denk hierbij aan:
  • de aanlevering van polis- en claim gegevens aan het actuariaat en Pricing & Underwriting;
  • de aanlevering van journaalposten aan het grootboek van de verzekeraar.
• De processen en stakeholders die onderdeel zijn van de portefeuille. De serviceprovider moet deze processen, na conversie, voorzetten en moet voor sommige processen samenwerken met de verzekeraar. Denk bijvoorbeeld aan:
  • de jaarlijkse premieberekening en de communicatie naar eindklanten.
• Welke producten en contracten onderdeel zijn van de portefeuille.
• Welke data de service provider nodig heeft om de portefeuille te kunnen administreren.
• De prioritering van de conversie onderwerpen om zo te bepalen welke activiteiten als eerst uitgevoerd moeten worden.

 

3.     De migratie

Als derde vond de data migratie plaats. Deze bestond uit: 1) het mappen van data, 2) schoning van de data en 3) de daadwerkelijke overgang.

Mappen van data
Na deze analyse was het duidelijk hoe de administratie van de serviceprovider ingericht moest worden en welke data hiervoor nodig is. Aan de hand hiervan kon de bestaande data gemapd worden naar de serviceprovider. Het afstemmen van de mapping is van groot belang, om ervoor te zorgen dat iedereen ‘dezelfde taal spreekt’. Niet elke organisatie gebruikt dezelfde terminologie en het komt voor dat identieke attribuutnamen een andere betekenis hebben bij verschillende stakeholders. Dit vraagt in sommige gevallen om transformatie van data voordat de migratie kan plaatsvinden.

Schoning data
Na de mapping werd de data conform een specifiek template aangeleverd. De oplevering van deze gevulde templates werden opgeleverd vanuit Scrum teams. Om er zeker van te zijn dat de juiste data werd gemigreerd is eerst, waar nodig, de data geschoond en verrijkt door inhoudelijke specialisten vanuit de verzekeraar.

Overgang
Na het inlezen van deze geschoonde en door business ge-akkoordeerde data op een acceptatie omgeving zijn vervolgens meerdere checks uitgevoerd op financiële boekingen, output & data koppelingen door alle stakeholders die betrokken zijn in dit traject om ervoor te zorgen dat deze gegevens ook inhoudelijk juist zijn. Toen alle stakeholders akkoord waren zijn dezelfde acties uitgevoerd op productie en was daarmee de keten operationeel en klaar voor overdracht.

 

4.     Controle en validatie

Tot slot werd de kwaliteit van de gemigreerde data gevalideerd en gewaarborgd via een conversie framework.

Validatie
Omdat de migratie binnen een kort tijdsbestek is uitgevoerd, is besloten om de volledige data overdracht achteraf te valideren. De validatie heeft plaatsgevonden door voor alle gemigreerde claims een volledige dossieroverdracht uit te voeren vanuit de verzekeraar naar de serviceprovider. Per dossier is gecontroleerd of de migratie correct is uitgevoerd en heeft er aanvulling/correctie plaatsgevonden waar nodig.

Conversie framework
Om de kwaliteit van de migratie te waarborgen is gebruik gemaakt van het conversie framework. Dit framework vormt – samen met de onderliggende bewijslast – een volledig conversiedossier dat dient als audit trail voor het project, de business owner, risk management en externe stakeholders zoals de accountant en de DNB. Het conversie framework biedt structuur aan het project en draagt bij aan een goede project organisatie, voorbereiding, uitvoering en nazorg van de conversie.

 

HET RESULTAAT

ITDS heeft bijgedragen aan een soepele en flexibele migratie naar de serviceprovider. Dankzij de vlekkeloze migratie kon de legacy applicatie op de afgesproken deadline uitgezet worden. De portefeuille is succesvol in beheer genomen bij de serviceprovider en zijn de eindklanten tevreden over de huidige dienstverlening. Daarnaast levert dit de verzekeraar een flinke maandelijkse kostenbesparing op.

Meer weten over onze Implementatie diensten? Klik hier.