Finance & IT Lagerhuis

Laura Kuhne, Principal Consultant van Triple A – Risk Finance, deelt haar belangrijkste take aways naar aanleiding van het Finance & IT Lagerhuis.

De wereld is niet zwart wit, de nuance blijft altijd belangrijk. Je hoeft zeker niet alles te automatiseren, houdt dus duidelijk in de gaten waarvoor je wat wilt inzetten. Dit zijn een aantal take aways naar aanleiding van het Triple A – Risk Finance Lagerhuis, waar aan de hand van vier stellingen debatten werden gevoerd op het grensvlak van finance en IT. Op zich past deze nuance ook goed bij actuarissen, omdat zij zijn gewend te denken in verschillende scenario’s.

Zo werd aan de hand van de stelling ‘Excel: Zegen of vloek’ duidelijk dat er maar weinig van de aanwezigen op Landgoed de Horst echt zonder Excel zouden kunnen leven, terwijl zij aan de andere kant ook wel de gevaren inzagen van het verkeerde gebruik ervan. Eigenlijk ligt het aan de mens dat Excel vaak verkeerd wordt gebruikt. Door een steeds groter wordend oerwoud van aan elkaar gekoppelde Excels, is het proces vaak niet goed meer te overzien. Dit vergroot het operationeel risico binnen het rapportageproces, wat resulteert in een langere doorlooptijd. Of nog erger, fouten in de rapportage. En hoewel een rapportage in een meer robuuste programmeertaal – zoals Python of C# -volgens de meeste aanwezigen minder foutgevoelig is, is deze niet altijd voor iedereen leesbaar, wat juist wel geldt voor Excel. De oplossing? Zoek de symbiose. Doe testwerk voor het creatieve proces in Excel, maar maak uiteindelijke rapportages er niet in. Zo’n schaduwmodel kan gebruikt worden als blauwdruk voor de uiteindelijke code.

Kerncompetenties
Stelling twee draaide niet om de waarom-vraag, maar ging in op de vraag waarin rapportages gemaakt zouden moeten worden: een actuarieel softwarepakket, zelfbouw of een Software-as-a-Service (SaaS)-oplossing? Actuarissen willen altijd alles nog preciezer uitwerken, dus een softwarepakket helpt om de snelheid te waarborgen. De uniformiteit zorgt voor structuur. Aan de andere kant staat zelfbouw, waarin je als verzekeraar alles volledig kunt bouwen aansluitend op de eigen processen. Maar slaat dat niet te ver door? Software bouwen zou toch niet een van de kerncompetenties van verzekeraars of pensioenfondsen moeten zijn? Een oplossing om gelijk van het beheer af te zijn, is een SaaS-oplossing. Hiermee zou je niet alleen kosten besparen, maar ben je ook flexibeler ten aanzien van de steeds veranderende wet- en regelgeving. Een nadeel dat de deelnemers signaleren, is de afhankelijkheid van de leverancier. De keuze hangt uiteindelijk af van waar je wilt staan als bedrijf, waar je heen wilt, maar ook van welke mensen en resources je hebt.

Datzelfde geldt bij de keuze om actuarissen in te zetten als modelbouwers. Want waarom zou je daar geen IT’ers voor inzetten? Actuarissen zijn veel duurder en software ontwikkelen is ook een vak apart, dus ga niet op elkaars stoel zitten. Tijdens de behandeling van deze derde stelling draaide het uiteindelijk meer om het verschil tussen domeinkennis versus IT-kennis en wat er nou eigenlijk het zwaarste telt. De conclusie was in ieder geval dat we elkaar hard nodig hebben om betere modellen te maken.

Projectaanpak
Maar welke projectaanpak is nu het meest geschikt voor het ontwikkelen van actuariële modellen? De stelling ‘Agile scrum is heilig als werkwijze’ trapte wat heilige huisjes omver. Want is een watervalplanning niet veel beter voor complexe actuariële modellen? Het MT wil toch weten waar het aan toe is. Scrum is eigenlijk maar een veredelde projectmanagementaanpak. Als actuaris is het echter heel lastig om alle specificaties vanaf het nulpunt helder te hebben. Bijsturen via sprints met bijbehorende korte reviews zorgt ervoor dat modellen tijdens het ontwikkelen continu verbeterd worden. Ga je dit pas achteraf bekijken, kom je er achter dat je een suboptimaal model hebt opgeleverd.

Tijdens dit laatste debat bleek ook weer de mens de bottleneck te vormen. Want eigenlijk interesseerde het de meeste aanwezigen niet eens zo zeer welke methode er gebruikt wordt. Juist daarom zou het belangrijk moeten zijn om mensen te motiveren om bij te dragen. Gericht ontwikkelen betekent namelijk altijd dat je continu moet blijven checken of dit wel bij de bedrijfsvisie past. Bij het ontwikkelen van modellen, is de methode min of meer van ondergeschikt belang. Belangrijker is om in het team de juiste mensen met de juiste kennis en ervaring in te zetten. Hier schuilt waarschijnlijk de meeste winst.

Bent u benieuwd naar de slides: .20240912 AT Seminar slides v3