6. Vrijgeven AFD-definitie door verzekeraar voor softwareproducenten

Als de AFD-definitie is afgerond is het zaak deze uit te rollen naar de markt. In dit hoofdstuk staan we stil bij de softwareproducenten in het volgende hoofdstuk bij de volmachten. Goed inzicht in de uitrol naar softwareproducenten is belangrijk. Het bepaalt het gemak en de kwaliteit waarmee het volmachtproduct van jouw organisatie de volmachtketen bereikt en is daarmee van invloed op de distributiekracht van jouw organisatie.

6.1 Softwareproducenten

Onder softwareproducenten verstaan we twee groepen partijen:

1. Leveranciers van software en services binnen de volmachtketen
Polisadministratie-software, aanvullende software en data-diensten voor het volmachtbedrijf.

2. Software-ontwikkelteams bij volmachten
Door volmachten zelf ontwikkelde software rond de uitvoering van het volmachtbedrijf.

In het kader van deze notitie onderkennen we vier groepen softwareproducenten:

1. Systeemhuizen
2. Leveranciers aanvullende software en services
3. Volmachten die eigen ondersteunende software ontwikkelen
4. Volmachten die eigen polisadministratie-software ontwikkelen
   

In paragraaf 6.4 is een detail toelichting rond bovenstaande softwareproducenten opgenomen.

6.2 Publicatie AFD-definities

Na certificering binnen AOS door de verzekeraar is een AFD-definitie beschikbaar in het register voor AFD-definities op de SIVI-website. Er zijn binnen het register drie opties:

1. AFD-definitie is zichtbaar en te downloaden
2. AFD-definitie is zichtbaar maar niet te downloaden
3. AFD-definitie is onzichtbaar voor derden

Het uitgangspunt voor de AFD-definities in gebruik voor Uniforme Inrichting Volmachtketen is dat iedereen variant (1) volgt. Deze variant stelt o.a. softwareproducenten instaat automatisch updates te volgen en nieuwe producten op te halen voor uitrol (beschikbaarstelling aan de volmacht ). Als jouw organisatie variant (2) volgt, dan betekent dit veel extra handelingen in de keten. Zorg in dat geval dat softwareontwikkelaars en volmachten weten hoe zij een AFD-definitie kunnen verkrijgen. Bij variant (3) zie je als organisatie alleen zelf dat de AFD-definitie beschikbaar is. Je moet dan zelf alle communicatie en de distributie invullen.

Softwareproducenten kunnen zich binnen de AOS-omgeving van SIVI aanmelden voor een notificatie-service en krijgen zo automatisch een melding bij een nieuwe AFD-definitie of een update. Softwareproducenten kunnen vervolgens de AFD-definities handmatig of geheel geautomatiseerd met een webservice (API) ophalen. Op basis van de AFD-definities kan men (als dat is ontwikkeld) binnen de software geautomatiseerd productspecificaties inlezen en daarmee binnen de software de volmachtproducten (deels) automatisch configureren of bijstellen.

In de Voorbeeld Samenwerkingsovereenkomst Volmachten (VSV) is gesteld dat in beginsel de door verzekeraar verstrekte instructies met betrekking tot de wijze waarop de volmacht werkzaamheden en bevoegdheden dient uit te oefenen tenzij anders afgesproken binnen 45 dagen uitgevoerd moeten worden. Dit geldt ook voor wijzigingen van AFD-definities. Het is belangrijk oog te houden voor de (verwachte) doorlooptijd bij de systeemhuizen en belangrijke aanvullende leveranciers als AWI en Bugs Business. De volmachten tijdig informeren van een ophanden zijnde wijziging is belangrijk, dan kan hij anticiperen op de komst van de update door het systeemhuis. Merk op voldoende informatie te verstrekken zodat dat de volmacht kan inschatten of er aanpassingen in zijn aanvullende software nodig zijn. Voor nieuwe AFD-definities van nieuwe producten is er geen afspraak over termijnen. De volmacht moet eerst een keuze maken het product te voeren, hier staat geen termijn voor.

6.3 Testen implementatie AFD-definitie en/of pilot gebruik AFD-definitie

Het testen in deze fase is nadrukkelijk niet bedoeld om te testen of de AFD-definitie correct is. Het is echt essentieel dat je als verzekeraar zorgt voor een foutloze aanlevering van de AFD-definitie. Nogmaals wijzen wij er met klem op dat fouten in de AFD-definitie in deze fase leiden tot onnodige kosten bij een reeks van partijen in de keten.

Softwareproducenten hebben primair een eigen verantwoordelijk te zorgen voor een goed werkende afhandeling van de AFD-definitie. Het is niet de taak van de verzekeraar de implementatie van een AFD-definitie te testen. AFD-definities werken op basis van generieke uitgangspunten en bevatten (los van de AFD-specificaties) geen verzekeraar specifieke elementen. Een software ontwikkelaar kan zonder product inhoudelijke kennis toetsen of een AFD-definitie juist is geïmplementeerd. Merk op: Op het moment dat de verzekeraar een fout gemaakt heeft in een AFD-definitie (bijvoorbeeld een brandstofsoort vergeten in de lijst met mogelijke waarden), dan ziet een software ontwikkelaar dat vaker niet dan wel.
Voor een eenvoudige update van een AFD-definitie moet je een gezamenlijk testtraject vermijden. Een softwareproducent mag uitgaan van een correcte AFD-definitie. Er moet een bijzondere aanleiding zijn om gezamenlijk te testen, anders genereren we – als je dit optelt – een te grote overhead en onnodige kosten in de keten. Bij een geheel nieuwe AFD-definitie of een ingrijpende aanpassing kun je als organisatie afwegen met welke softwareproducenten je wilt testen. Met name gezamenlijk testen met systeemhuizen en leveranciers van aanvullende software en services voorkomt problemen bij een reeks van volmachten tegelijk.

Als een softwareproducent een AFD-definitie heeft geïmplementeerd is het een optie eerst met een volmacht een pilot uit te voeren. Voor een eenvoudige update van een AFD-definitie moet je een pilot vermijden. Voor de introductie van een geheel nieuwe AFD-definitie is wel het advies om met een beperkt aantal volmachten een pilot uit te voeren. Ook hier nadrukkelijk niet met als doel het testen te vervangen, dit levert – als je dit optelt – te veel overhead en onnodige kosten in de keten. Een pilot is bedoeld om vast te stellen of het gebruik van de AFD-definitie in de praktijk anders dan voorzien uitpakt of dat er zaken vergeten of onduidelijk zijn. Het is hierbij zaak goed te begrijpen welke combinaties softwareproducent – volmacht voor jouw organisatie belangrijk zijn. Hou er rekening mee dat redelijk wat volmachten afhankelijk zijn van meer dan één leverancier (bijvoorbeeld de combi ANVA – AWI). Overleg met de volmacht geeft snel inzicht en overzicht. Alle softwareproducenten zijn ingesteld op de werkwijze rond AFD-definities, het gaat er dus om dat zij het signaal krijgen de betreffende AFD-definitie op te pakken voor de pilot. Dit kun je ook prima overlaten aan de volmacht, je hebt dan alleen mogelijk wat minder regie rond de doorlooptijd van het pilottraject.

6.4 Afstemming softwareproducenten

6.4.1 Overzicht softwareproducenten

Om deze tekst zo concreet als mogelijk te maken is in deze paragraaf een overzicht opgenomen van de onderkende softwareproducenten. Afhankelijk van de portefeuille en de volmachten waarmee je als verzekeraar samenwerkt zijn hebben softwareproducenten meer of minder impact op de portefeuille van jouw organisatie.

Systeemhuizen
Binnen de volmachtmarkt zijn ANVA, CCS en DIAS de leidende systeemhuizen. Novulo is ook actief als systeemhuis, maar ondersteunt de uitgangspunten voor uniforme inrichting nu niet.

• ANVA
• CCS
• DIAS
• Novulo
  

Leveranciers aanvullende software en services

• Assurantie Apps
• AWI
• Bugs Business
• Building Blocks
• Comparity
• C-profile DDI
• Finconnect
• Infofolio
• Market Scan
• Postex
• Rolls
  

Volmachten die eigen ondersteunende software ontwikkelen
Alle volmachten van enige omvang ontwikkelen in meer of mindere mate in eigen beheer aanvullende software.

Volmachten die eigen polisadministratie-software ontwikkelen

• Hienfeld
• Private Insurance Assuradeuren
• Turien
• Voogd & Voogd
  

6.4.2 Digitale schappositie

In het kader van deze notitie onderkennen we vier groepen softwareproducenten:

1. Systeemhuizen.
2. Leveranciers van aanvullende software en services.
3. Volmachten die eigen ondersteunende software ontwikkelen.
4. Volmachten die eigen polisadministratie-software ontwikkelen.
   

Uitgangspunt voor het traject uniforme inrichting is dat softwareproducenten het gebruik van het AFD als uitgangspunt nemen. Het algemene beeld is dat alle softwareproducenten binnen de keten conform AFD-afspraken werken of er rekening mee houden. Een ander belangrijk vetrekpunt is dat partijen hun eigen kosten nemen. Het is niet de bedoeling dat een rekening betaald wordt voor de ondersteuning van een AFD-definitie. Wel brengt een aantal leveranciers de volmacht een vergoeding in rekening voor het gebruik van standaard ingerichte volmachtproducten conform AFD-definitie.

De meeste softwareproducenten zijn goed ingesteld op het tijdig verwerken van de doorlopende aanpassingen binnen het AFD. Toch zal het een enkele keer voorkomen dat het minder vlot verloopt. Op de volgende situaties moet je dan voorbereid zijn:

1. Het kan voorkomen dat een softwareproducenten vanuit de techniek een AFD-uitbreiding niet kan ondersteunen. Vaak moet je dan wachten op een speciale release om dit op te lossen, waarbij zo’n uitbreiding dan ook nog voldoende prioriteit moet krijgen. Het is zaak om in overleg met volmacht en softwareproducent het belang van deze uitbreiding te duiden en voor de korte termijn naar een workaround te kijken.
2. Een softwareproducent kan binnen zijn planning geen tijd of budget hebben om (binnen afzienbare termijn) een AFD-uitbreiding te implementeren. Naast dat het nodig is om voor de korte termijn met volmacht en softwareproducent naar een workaround te kijken, is het belangrijk te begrijpen hoe toch invloed te krijgen op de beschikbare tijd of de onderbouwing voor de investering door de leverancier of eventueel de volmacht.

Je hebt als organisatie de keuze in welke mate je een actieve rol wil vervullen rond de uitrol van AFD-definities en dus invloed wilt hebben op het tempo en eventueel de kwaliteit bij uitrol. Je kunt het ook geheel aan de volmacht overlaten om met zijn softwareproducenten het gebruik van AFD-definities af te stemmen. Realiseer je dat gebrek aan prioriteiten bij softwareproducenten, onjuiste afstemming met softwareproducenten en/of verschil van inzicht met softwareproducenten kunnen leiden tot verlies aan distributiekracht en verminderd fulfilment rond de volmachtproducten van jouw organisatie. De realiteit is dat je als verzekeraar een digitale schappositie moet managen bij de voor de portefeuille van jouw organisatie meest belangrijke softwareproducenten.

6.4.3 Systeemhuizen

Met systeemhuizen is de afspraak gemaakt dat zij op basis van de AFD-definities de inrichting van de volmachtproducten ondersteunen. Het uitgangspunt is dat de data is opgeslagen in AFD-formaat, dus zonder conversietabellen. Als dit niet mogelijk is, dan moet er altijd sprake zijn van 1:1 mappingen of n:1 mappingen (waarbij 1=AFD-zijde). Het systeemhuis zorgt er in dat geval voor dat de volmacht kan tonen hoe deze mappingen zijn ingericht.
De werkwijze rond de afhandeling van AFD-definities is per systeemhuis verschillend als gevolg van de verschillen in architectuur van de systemen en door het systeemhuis gehanteerde uitgangspunten. Bij nieuwe versies van AFD-definities voor producten zorgen zij voor het beschikbaar stellen richting de volmacht. Koppelingen binnen de software met o.a. het NVGA-protocol en VPI worden standaard ondersteund. Door deze werkwijze hoeft een volmacht voor het gaan gebruiken van een nieuw product of het aanpassen van een bestaand product nog maar een beperkt aantal handelingen uit te voeren. Een goed gebruik van AFD-definities door de leverancier decimeert voor de volmacht de kosten rond inrichting.

De software van systeemhuizen anticipeert op het gebruik van AFD-definities. Een verzekeraar verstrekt een geheel nieuwe AFD-definitie bij een geheel nieuw product of de opvolger van een bestaand product waarbij er echt sprake is van een substantieel andere productinrichting. In alle andere gevallen zal er sprake zijn van een nieuwe versie van een bestaande AFD-definitie als gevolg van bijvoorbeeld een aanpassing van een premiebepalende factor, marktontwikkelingen (acceptatie) of wetgeving. Bij het sluiten van een nieuwe polis moet de volmacht de actuele AFD-definitie als uitgangspunt gebruiken. Het versienummer van de AFD-definitie die is gebruikt bij het opstellen van de polis maakt standaard onderdeel uit van de gegevens voor die polis. Bij premiebepalende mutaties muteren polissen altijd tegen de actuele AFD-definitie en krijgen bij mutatie dus ook dat AFD-definitie versienummer en voldoen dus aan de vereisten zoals gedefinieerd binnen die AFD-definitie. Binnen een volmacht portefeuille is dus altijd te herleiden op basis van welke versie van een AFD-definitie een polis is opgesteld of gemuteerd. Na verloop van tijd zijn er dus verwijzingen naar meerdere versies van AFD-definities aanwezig. Het AFD-definitie versienummer is ook opgenomen in de data levering van het NVGA Protocol.

Aanvullend leveren de systeemhuizen in het verlengde van het gebruik van AFD-definities een rapportagefunctie. Met deze rapportagefunctie kan de volmacht aangeven waar zijn portefeuille afwijkt van de actuele AFD-definitie voor dat product. Tevens kan hij aangeven welke polissen conform welke AFD-definitie versie zijn opgemaakt. In hoofdstuk 8 gaan we uitgebreid in op de rapportagefunctie.

6.4.4 Leveranciers aanvullende software en services

Met de leveranciers opgenomen in het overzicht in paragraaf 6.4.1 zijn de uitgangspunten rond het traject uniforme inrichting besproken. De impact rond het gebruik van AFD-definities is per leverancier verschillend. Een aantal leveranciers onderzoekt de mogelijkheden meer in te spelen op de beschikbaarheid van AFD-definities. Binnen het Programma Uniforme Inrichting Volmachtketen heeft dit minder de aandacht gehad (de nadruk lag op de systeemhuizen), daardoor moet dit nog wat op gang komen. Voor een deel van deze leveranciers geldt dat men door het gebruik van AFD-definities de activiteiten rond de inrichting van producten deels kan automatiseren. Een goed gebruik van AFD-definities door de leverancier beperkt voor de volmacht de kosten rond inrichting en vermindert de kans op fouten.

6.4.5 Volmachten die eigen ondersteunende software ontwikkelen

Je moet er rekening mee houden dat alle volmachten van enige omvang in meer of mindere mate in eigen beheer aanvullende software ontwikkelen. Soms is het meer systeemintegratie, soms zijn het complete omgevingen.
In welke mate wijzigingen in AFD-definities impact hebben zal heel verschillend zijn. Wil je als organisatie hierop anticiperen, dan moet je dit uitvragen bij de volmachten.

6.4.6 Volmachten die eigen volmachtpolisadministratie-software ontwikkelen

Er is een beperkte groep volmachten die in eigen beheer volmacht polisadministratie-software ontwikkelen. Deze organisaties volgen in essentie dezelfde uitgangspunten als de systeemhuizen. Het volgen van reguliere updates van het AFD is geen probleem. Bij meer uitzonderlijke updates van het AFD zullen deze partijen wat nadrukkelijker naar de business case kijken, goede afstemming is dan belangrijk.