Nieuws

Dagelijks worden 100 miljoen rijen over en weer gestuurd

Bernd Evers & Sven Huijsmans

  Collega’s Bernd Evers (SAP BW BO HANA Consultan) en Sven Huijsmans (Teammanager IT MI & Datalogistiek) werden geïnterviewd door Computerworld.nl over de data-achritectuur bij Interpolis. In dit artikel vertellen zij welke uitdagingen Interpolis heeft op het gebied van data-logistiek en welke oplossingen hiervoor gevonden zijn!  

Bij Achmea moet datalogistiek verstand hebben van zowel techniek als de business. Voor het opzetten en gebruiken van een datalogistiek systeem moet je twee talen spreken: die van de business (wat is er functioneel nodig) en de techniek (hoe leveren we dit technisch)? Wat zijn de uitdagingen waar ontwerpers mee te maken krijgen?

Het inrichten van een data-architectuur is geen sinecure, omdat de ontwikkelaars die het data uitwisselende systeem bouwen rekening moeten houden met meerdere designkeuzes die van invloed zijn op bijvoorbeeld de prestaties van het systeem en de beschikbaarheid van gegevens. Dat maakt het ontwerpen van een soepele datalogistiek een uitdaging en in dit artikel staan we stil bij enkele van de overwegingen waar specialisten rekening mee houden aan de hand van een praktijkvoorbeeld van het datateam bij Interpolis. We spreken met SAP-specialist van Achmea Bernd Evers en teamleider datalogistiek Sven Huijsmans, die vertellen wat hierin de uitdagingen zijn en hoe ze het bij Interpolis hebben opgelost.

Twee partijen hebben inzicht

Een van de projecten waar het team zich momenteel op richt, is bijvoorbeeld de provisiestroom die de Rabobank wil ontsluiten. Als een klant een Interpolis-verzekering afsluit bij die bank, ontvangt de Rabobank daar commissie op. Beide partijen moeten inzicht hebben in hoeveel verzekeringen er zijn verkocht en hoeveel commissie daar precies mee is gemoeid; hoeveel is er berekend en hoeveel is er uitbetaald? Die gegevens moeten soepel worden uitgewisseld en dat vereist een data-architectuur die kijkt naar de beste combinatie van bijvoorbeeld prestaties, beschikbaarheid en actualiteit.

Het gaat bij de uitwisseling tussen Interpolis en de Rabobank om enorme aantallen gegevens. Interpolis wisselt informatie uit van zo’n 8 miljoen verzekeringen met de Rabobank die de daadwerkelijke verkoop uitvoert. Er worden dagelijks honderd miljoen rijen polisdata over en weer gestuurd tussen de verzekeraar en de verkoper (de bank). Hoe sneller deze gegevens worden geactualiseerd, hoe beter het is voor alle betrokken partijen.

Combinatie van pakketten

Voor het creëren van soepele datalogistiek moet men dan ook weten wat de gevolgen zijn van specifieke ontwerpen, bijvoorbeeld als het gaat om de gegevensfilters. In een situatie zonder filter trekt de gebruiker, wanneer hij of zij data aanspreekt, erg veel gegevens binnen in een view. Soms is het nou eenmaal beter om een fysiek model te maken in BW en soms werken filters beter. Dat HANA alles in het geheugen uitvoert, betekent bijvoorbeeld dat je moet wachten op de resultaten en dat is niet altijd wenselijk. De engineers zoeken naar een systeem dat praktisch is voor het doel van de datawisseling en dat kan verschillen.

Het kan een behoorlijke uitdaging zijn voor een specialist om te beoordelen welke methode in welke situatie het beste zal werken, zo geeft Bernd Evers aan. “Waar liggen de sterke punten van een bepaald pakket? Wat kun je wel en niet virtueel doen, en wat kun je wel en niet fysiek doen?”, zegt de SAP-specialist.

Bij deze beoordeling kijken specialisten naar factoren als beheersbaarheid, onderhoudbaarheid en performance. Voor de provisieberekening waar de Rabobank om vraagt wordt er een stuk zelf berekend, vertelt Evers. “In termen van onderhoud en beheer kun je dit veel beter in BW doen. Op het moment dat je allerlei berekeningen in HANA gaat doen kost het extra tijd voordat je antwoorden hebt en dat gaat dus ten koste van de performance”, licht hij toe.

Meerdere bronsystemen

Kortom, als je een gelaagd fysiek datamodel bouwt in SAP BW om de data te verkrijgen op de manier waarop de gewenste gegevens gepresenteerd dienen te worden, levert dat extra verwerkingstijd op en moeten systemen ‘s nachts berekeningen uitvoeren. Maar met SAP HANA-views zijn deze gegevens zonder die extra verwerking in te zien met een query. Daar kleven dus wel nadelen aan zoals de lagere resultaatsnelheid.

Omdat er meerdere bronsystemen worden gebruikt, kijken de makers voor hun designkeuzes naar de doelen waar de gegevens voor worden gebruikt. “BW gebruiken we voor de dingen waar dat goed in is. Berekeningen van een provisiestroom voeren we uit in BW. Dan ben je daar bezig met specifieke dingen en daar kan nog een stukje ABAP bijkomen. In HANA zit je weer met allerlei kengetallen die je uit moet gaan rekenen.” Voor de verwerking worden SAP ICM (Incentive Commission Management) en FS-CD (Collections & Disbursements) gebruikt en de BI-tools die worden gebruikt zijn HANA en BW.

Hoe databronnen in elkaar grijpen

Het combineren van de verschillende IT-systemen is zeker geen zaak van eenmalig ontwerpen om het dan te kunnen vergeten. Dat houdt het werk juist interessant, vindt Evers, want als je de architectuur juist inricht, krijg je de beste performance én de meest actuele gegevens. “Je moet je nieuwe stof hier erg snel eigen kunnen maken”, voegt Sven Huijsmans daaraan toe.

“Het maken van formules vereist dat je analytisch sterk bent: één is één en nul is nul, maar de mensen die de relatie daarvan snappen met de ‘a’ ernaast maken het verschil.” In dit geval is er gewerkt met provisie-data, maar in een ander traject gaat het om claimsdata. Om de gegevens juist te combineren, moet je het goed begrijpen hoe de databronnen in elkaar grijpen, licht Huijsmans toe.

Begrip voor alle betrokken partijen

“In het combineren van al die databronnen zit veel uitdaging, omdat je verschillende bronsystemen moet aansluiten, je hebt uitdagingen van BW, uitdagingen van HANA, je hebt een stukje business-analyse, je moet dus praten met alle betrokken partijen, je moet begrijpen waar bijvoorbeeld die provisie vandaan komt, hoe het wordt berekend en wat de definities van die begrippen zijn”, legt Evers uit.

Er zijn veel partijen die bij dit proces betrokken zijn: van de uiteindelijke eindgebruikers van de applicatie, zoals de klanten via de Rabobank-app, tot de data-analisten bij de Rabobank, tot de ontwikkelaars bij de databron en de functionele gebruikers bij de business van Interpolis en Rabobank. Kortom, het vereist van de bouwers van het systeem dat ze met veel mensen overleggen. “We spreken met de mensen die ermee gaan werken, met de ontwikkelaars van het ICM-systeem en van het CD-systeem.”

Verandering is de enige constante 

Bovendien maken de ontwikkelaars van de data-keten aan de lopende band inschattingen over de architectuur, want het is een proces dat constant verandert en opnieuw moet worden beoordeeld. Qua datalogistiek krijgen ze te maken met verschillende domeinen: data van polissen, provisies, claims, afdeling zorg, leven – er verandert veel. “Je hebt afdelingen die zich uitsluitend bezighouden met zakelijke verzekeringen. Voor ons is dat slechts één van de aspecten”, zo sluit Evers af.

Jouw droombaan
in je inbox

Stel een job alert in met jouw persoonlijke instellingen. Zodra er een nieuwe relevante vacature is, dan sturen we je een e-mail!