Het werk van een verzekeraar en tussenpersonen vindt grotendeels plaats in de digitale omgeving van de verzekeringsmaatschappij. Deze digitale omgeving kan er bij iedere maatschappij weer anders uitzien, omdat de ene organisatie een volledige omgeving op maat heeft gebouwd en de ander gebruikt verzekeringsapplicaties of een combinatie van de twee. In deze blog beschrijven we hoe je het beste een verzekeringsapplicatie gebruikt en koppelt met de rest van je architecture framework.
Welke verzekeringsapplicaties worden veelal gebruikt?
Verzekeraars en verzekeringsagenten (tussenpersonen) gebruiken vaak ook standaardpakketten. Een viertal voorbeelden zijn: SAP Policy Management, VERMEG Solife, Aplaza en ANVA.
Dit zijn over het algemeen prima applicaties met vele functionaliteiten die het werk een stuk vergemakkelijken. Maar wat als je merkt dat je een functionaliteit liever anders zou willen zien of een functionaliteit zelf wilt toevoegen? Bij deze grotere applicatiesystemen is dat lastig en zit je gevangen in het pakket dat je aangeboden wordt.
Een verzekeringsapplicatie moet een middel zijn en niet het doel
In veel gevallen is het zelfs het zelfs zo dat volledige bedrijfsmodellen worden gebaseerd op wat een verzekeringsapplicatie te bieden heeft. Terminologie van de applicatie wordt één op één overgenomen en ook de structuur van de dienstverlening, terwijl dit misschien niet de meest efficiënte manier is voor jouw organisatie en het onderscheidende vermogen beperkt.
Dit zou eigenlijk omgedraaid moeten worden. De dienst en terminologie van het bedrijf bepalen! Vaak zijn een bedrijfsmodel, processen en data, het ideeale uitgangspunt om te beginnen. Aplicaties zijn ondergeschikt en worden uitgekozen om functies uit te voeren. Het lastige hierbij is dat je dan niet snel een verzekeringsapplicatie zult vinden die volledig op je behoeften aansluit.
Ontkoppelen van de verzekeringsapplicatie is de oplossing
De oplossing bij dit probleem is om een verzekeringsapplicatie te kiezen die de meeste functionaliteit heeft en het beste aansluit op je bedrijfsmodel, om vervolgens zelf een API te bouwen die als voorkant dient. Deze API gebruik je dan eigenlijk als je eigen op maat gemaakte verzekeringsapplicatie, zonder dat je het core systeem volledig zelf moet opbouwen. Wanneer je dan functionaliteit wilt toevoegen die de standaard verzekeringsapplicatie niet aanbiedt, dan kun je een custom pakket aan je architecture framework toevoegen en deze integreren in je API.
Zo ga je slim om met wat er al bestaat, maar heb je wel de flexibiliteit van een modulair systeem t.o.v. het gebruiken van een monoliet en vastzitten aan de functionaliteit daarvan.
Het Frank!Framework helpt om de integraties uit te voeren
Wanneer je een eigen API hebt ontworpen, moet deze natuurlijk nog geïntegreerd worden met de verzekeringsapplicatie en andere losse tools. Om dit zo makkelijk mogelijk te maken gebruik je hiervoor het Frank!Framework. Dit framework wordt al door de grootste verzekeraar in Nederland gebruikt om systemen met elkaar te integreren en ervoor te zorgen dat het gehele architecture landschap goed op elkaar aangesloten is.
Het Frank!Framework helpt je om gemakkelijk applicaties te koppelen en wanneer nodig weer te ontkoppelen en te vervangen.
Wil je weten hoe het Frank!Framework in de praktijk werkt?
Download dan onze case “Hoe WeAreFrank! de grootste verzekeraar van Nederland al meer dan 20 jaar helpt met de integratie van honderden applicaties.”
