In de verzekeringsbranche is het Assurantie Data Netwerk (ADN) een belangrijk transportmedium. Verzekeraars, tussenpersonen, expertise-bureaus en schadeherstellers wisselen met elkaar gestructureerde berichten uit, zoals polisaanvragen en -mutaties, nota’s, expertiseopdrachten en expertiserapporten. De infrastructuur is eind jaren tachtig neergelegd en gebaseerd op de principes van een Edi/Edifact-netwerk. Edi en Edifact staan de laatste jaren sterk onder druk. Internet en XML vormen grote bedreigingen, want ze missen de beperkingen van Edifact.Manager Gerhard Gerritsen beschrijft de voor- en nadelen van de toepassing van XML, en de maatregelen die Abz Nederland als beheerder en intellectueel eigenaar van het netwerk genomen heeft om het aan te passen aan de eisen van de moderne tijd.
Tot nu toe vindt informatie-uitwisseling in de verzekeringsbranche nog voornamelijk plaats volgens het principe van de postbuscommunicatie: het belangrijkste medium dat voor de elektronische berichten- en documentenuitwisseling wordt gebruikt, is het Assurantie Data Netwerk. Er is een aantal ontwikkelingen aan de gang die er voor zorgen dat de communicatie in de branche snel en fundamenteel verandert. Zo gaan – onder de noemer van ‘enterprise application integration’ – verschillende spelers in de verzekeringsbranche hun informatiesystemen in toenemende mate integreren. Binnen afzienbare tijd zien we dat systemen toegang krijgen tot elkaars gegevensverzamelingen en ook gebruik gaan maken van elkaars applicaties. Gecombineerd met de toegang tot de database, bestaat nu de mogelijkheid om op basis van opgevraagde gegevens zelf transacties aan te gaan via de transactieapplicaties van de partner. Zo gaan tussenpersonen bijvoorbeeld rechtstreeks muteren in de database van de verzekeraar. Om die reden groeit de noodzaak om tot afspraken en overeenstemming tussen de verschillende partijen te komen.
Naar verwachting komen steeds meer applicaties – vanwege lagere beheerskosten – centraal in een ‘application service provider’ (asp)-omgeving ter beschikking. Distributie van bijvoorbeeld offertesoftware van een individuele verzekeraar naar zijn tussenpersonen is dan niet meer nodig en het uitvoeren van updates hoeft slechts op één plaats te gebeuren. Ook wordt het zo eenvoudig om centrale applicaties te koppelen aan informatiediensten en applicaties van maatschappijen. Dubbele opslag van gegevens over contracten en schades verdwijnt dan. De administratie van de maatschappij is leidend en de tussenpersoon voert hier zijn raadplegingen en mutaties uit.
Een andere belangrijke ontwikkeling is de overgang van batch-georiënteerde systemen naar online systemen. Financiële aanbieders willen maatwerkproducten verkopen. De ’time to market’ moet kort zijn en de transactiekosten moeten tevens omlaag. Hiertoe worden financiële producten via het Web aangeboden en wordt ook het transactiemanagement via internet geregeld (‘e-logistics’). Allerlei tussenschakels ontstaan, zoals virtuele tussenpersonen en tussenpersoon-providers. Internet wordt tegelijkertijd een kanaal om rechtstreeks producten te verkopen aan consumenten. Offreren, aanvragen en muteren van polissen verloopt nu al steeds vaker online via internet.
XML speelt bij de hierboven genoemde ontwikkelingen een belangrijke rol als syntaxis voor het uitwisselen van gegevens. Waardevolle aanvullende standaarden maken de XML-gereedschapskist uitermate geschikt voor zakendoen via internet. XML fungeert samen met andere belangrijke protocollen als Http, Soap en Uddi als lijm tussen de diverse systemen, die in toenemende mate losjes gekoppeld worden. Losjes gekoppeld wil zeggen dat ze niet via leveranciersafhankelijke standaarden met elkaar communiceren, zodat bij uitval van één van de systemen, de systemen van de andere deelnemers gewoon blijven functioneren.
Edifact en XML
Vanwege de opkomst van XML wordt vaak geroepen dat edi (‘electronic data interchange’) zijn langste tijd heeft gehad. Dat is een onterechte bewering, want XML en edi zijn niet hetzelfde. Edi staat immers voor elektronische gegevensuitwisseling. Dat kan zowel via gesloten, private netwerken als via internet. Maar de term edi is in de loop der jaren synoniem geworden met die gesloten – en dure – netwerken. Beter is het te stellen dat Edifact zijn langste tijd heeft gehad. Edifact is immers, net als XML, een standaardtaal voor gestructureerde gegevens. Edifact wordt voornamelijk als standaard gebruikt voor edi-netwerken, terwijl XML een taal is die zowel in edi-netwerken als op internet gebruikt kan worden. Omdat XML een goed alternatief is voor Edifact, investeren leveranciers wereldwijd alleen nog maar in XML-ontwikkelingen. Edifact zal ophouden te bestaan. Overigens is er theoretisch geen enkel probleem om Edifact ook via internet te gebruiken.
Edifact heeft in principe dezelfde doelstelling als XML. Alleen is deze standaardtaal meer dan tien jaar geleden ontwikkeld met de toenmalige (computer)technieken in het achterhoofd, en dus ook met de toenmalige beperkingen. Edifact is bijvoorbeeld geoptimaliseerd om zo compact mogelijk te zijn. Dat werd indertijd, met de toenmalige stand van datacommunicatie, als belangrijk ervaren. Ook is Edifact gericht op de computer-tot-computer communicatie. XML is daarentegen breder inzetbaar en richt zich ook op mens-tot-computer en computer-tot-mens communicatie. Dit biedt veel meer mogelijkheden die bovendien beter aansluiten op de praktijksituatie. De meeste informatiestromen in de verzekeringswereld zijn nu eenmaal geen zuivere computer-tot-computer communicatie. XML schenkt ook veel meer aandacht aan ‘presentatie’ voor de gebruiker. Edifact kan ook geen grafische informatie aan. Eigenlijk kun je zeggen dat Edifact zich sinds zijn ontstaan niet verder meer heeft ontwikkeld en daarom ook volledig de internet-boot heeft gemist.
XML is technisch gezien beter opgezet, vooral door het gebruik van ondersteunende standaarden, en kent brede ondersteuning vanuit de software-industrie. Bij gebruik van Edifact komt daarentegen nog heel wat ontwikkelwerk kijken, terwijl de ondersteuning van softwareleveranciers ook heel wat minder is. Een groot verschil tussen Edifact en XML is ook dat eerstgenoemde zich eveneens richt op inhoudelijke standaardisatie. Zo zijn er voor de afzonderlijke branches verschillende berichten ontwikkeld.
Voor- en nadelen XML
XML en internet bieden oplossingen voor een aantal ‘oude’ Edifact-problemen. En het moet gezegd: de ontwikkelingen zijn veelbelovend. Denk maar aan het afdrukken van plaatjes en logo’s (polisbladen) en de integratie van plaatjes in de tekst (schadeformulieren). Er wordt hard gewerkt aan deze ontwikkelingen. Op grond daarvan is de conclusie gerechtvaardigd, dat XML veel breder gedragen wordt dan Edifact, dat toch altijd een specialisme is gebleven. XML is duidelijk een hype geworden: in de XML-omgeving gebeurt van alles, terwijl rond Edifact de tijd lijkt stil te staan. En wie wil er nu werken in een omgeving waar geen vooruitgang valt te constateren?
De hype rond XML komt niet alleen maar voort uit het marketinggeweld van zijn promotoren. Ook de achterliggende techniek geeft XML een voorsprong op Edifact en uitzicht op een goede toekomst. XML biedt technisch gezien meer dan Edifact met name door goede aanvullende standaarden voor presentatie en logica. Daardoor is de syntaxis van XML eenvoudig en recht-toe-recht-aan. Dat maakt een XML-document minder ondoorgrondelijk. Concreet leidt dat tot twee voordelen: de ‘parsers’ die bij XML gebruikt worden zijn eenvoudiger dan de Edifact-vertalers, en zijn bovendien gratis beschikbaar op internet. Edifact-vertaalsoftware heeft ‘vertaaltabellen’ nodig. Die zijn specifiek per leverancier. Alle XML-‘parsers’ gebruiken daarentegen dezelfde, gestandaardiseerde schema’s.
Bij XML zijn de gegevens en de toepassing goed gescheiden. De applicatiekoppeling kan daardoor stabieler zijn, omdat toepassingen nu eenmaal sneller wijzigen dan gegevens. Voor de toepassingen zijn de aanvullende standaarden van groot belang. De onafhankelijkheid van gegevens en toepassing pleit er ook voor om XML-interfaces zo breed mogelijk op te zetten.
Het is echter niet louter rozengeur en maneschijn rond XML. Er moeten nog wat problemen worden opgelost. De aanvullende (maar zeer wezenlijke) standaarden bij XML zijn nog niet (geheel) gerijpt. Daarbij komt dat XML-software vrij nieuw is. Dit kan leiden tot opstartproblemen en kinderziektes. Bovendien zijn edi-migraties moeizaam. Het migreren van bestaande edi-oplossingen naar de nieuwe standaardtaal XML zonder dat er iets aan de functionaliteit verandert, levert de marktpartijen niets op. De kracht van XML is tevens de zwakte: flexibiliteit. Iedere gebruiker kan zijn eigen dtd’s en/of schema’s specificeren. Hierdoor ontstaan onsamenhangende, incompatibele gefragmenteerde standaarden. "XML is erg flexibel. Iedereen kan doen wat hij wil, en dat doet hij dan ook!" (Steve McVey at XML ’99).
XML biedt geen functionele standaardisatie, en een universele methodiek voor functionele standaardisatie ontbreekt! Gesteld dat bijvoorbeeld in allerlei verticale branches logische datamodellen worden ontwikkeld als basis voor functionele standaarden, dan kom je mogelijk in de problemen op het moment dat gegevens horizontaal uitgewisseld worden tussen branches. Verschillende branches kunnen immers verschillende normen hanteren, bijvoorbeeld voor persoonsgegevens. Een organisatie die in dit verband belangrijk werk verzet, is Ontology.org. Zij tracht generieke semantische superstructuren te ontwikkelen die barrières voor elektronisch zakendoen moeten wegnemen.
Scheiding functionaliteit en techniek
Het grootste nadeel van de edi-standaarden die in de loop der jaren in de verschillende branches zijn opgesteld is, dat er geen scheiding tussen functionaliteit en techniek is toegepast. Men heeft letterlijk alles gestandaardiseerd in Edifact. Hierdoor zijn de gebruikers van de standaarden overgeleverd aan de techniek van Edifact. Met de komst van XML en internet komen eerdere investeringen op de tocht te staan. De diverse edi-organisaties (zoals Ean en Vektis) zijn dan ook in paniek. Voor de deelnemers aan het Assurantie Data Netwerk zijn de risico’s van desinvesteringen minimaal, aangezien het netwerk in de jaren negentig is opgezet vanuit het idee dat de techniek en functionaliteit gescheiden behoren te zijn. Zo is de functionaliteit van de gegevens op de ‘hoogste’ semantische laag vastgelegd, namelijk in de Abz-datacatalogus. Daaronder bevinden zich de syntaxislaag, de transportlaag en de netwerklaag. Het is relatief eenvoudig om nieuwe technieken in de afzonderlijke lagen toe te passen. Desinvesteringen of grote extra uitgaven om de gegevensfunctionaliteit te handhaven, zijn daarvoor niet nodig. Zo kan een aanvraag voor een verzekering op basis van de Abz-datacatalogus bijvoorbeeld in Edifact (syntaxislaag) via X400 (transportlaag) en TCP/IP (netwerklaag) worden verstuurd. Maar ook in Edifact via Smtp en TCP/IP. Of in XML via Http en TCP/IP. Met andere woorden: de functionele standaard blijft stabiel en kan toegepast worden met meerdere technieken en protocollen.
Abz-datacatalogus
De datacatalogus is halverwege de jaren negentig ontwikkeld voor het ADN. Iedere verzekeraar selecteert per verzekeringsproduct de gewenste gegevens uit de catalogus en stelt zo zijn eigen elektronisch aanvraag- en mutatieformulier (‘view’) samen. Alle gegevens voor het aanvragen en wijzigen van polissen in de diverse branches – momenteel ongeveer 6500 – zijn opgenomen in deze catalogus. Abz levert nu nog alle ‘views’ twee keer per jaar uit aan de met Abz samenwerkende softwarebureaus die tussenpersonen voorzien van applicaties.
De assurantietussenpersoon kiest op zijn computerscherm voor een verzekeringsproduct van een bepaalde maatschappij. Hij krijgt vervolgens alleen de vragen van die verzekeraar te zien, beantwoordt die en verstuurt de aanvraag via het ADN. Alle polisaanvragen en/of -mutaties worden met één label/waarde bericht en conform een set bindende afspraken verstuurd.
Basis voor de ADN-datacatalogus is een gegevensmodel waarin alle gegevens (bouwstenen) zijn opgenomen die nodig zijn voor het aanvragen en wijzigen van polissen voor verzekeringsproducten. Inclusief label, formaat en omschrijving. Functioneel gezien wordt dus gestandaardiseerd op het niveau van een gegevensmodel voor de communicatie. Vanaf eind 1989 zijn alle gestandaardiseerde elementen in het gegevensmodel voorzien van een label. Deze labels worden ook in Edifact-berichten uitgewisseld conform de Abz label/waarde-methode. Aangezien XML in de kern ook label/waarde betreft (’tag-value-tag’) is het ADN in principe al lang klaar voor de invoering van XML.
Het belangrijkste voordeel van deze modelmatige aanpak is zekerheid, vooral met betrekking tot het kostenniveau van de investeringen om met businesspartners te communiceren. Door de opzet van het model is het ook mogelijk om de berichten die via het ADN verstuurd worden, in ieder gewenst formaat uit te wisselen. Nu is dit nog Edifact, maar de Abz label/waarde-catalogus is inmiddels aangepast aan XML. Verzekeraars, tussenpersonen en andere gebruikers kunnen wanneer zij dat willen nu al gebruikmaken van XML. Met behulp van een daartoe ontwikkelde conversietool is zonder aanpassingen van de backoffice-systemen op XML over te gaan. Door met XML te werken kan het formaat van de berichten worden verwerkt door computers, waardoor enorme kostenbesparingen mogelijk zijn.
XML in de verzekeringsbranche
XML zal vooral gebruikt worden in online toepassingen met steeds verdergaande integratie van de administraties van tussenpersoon en verzekeraar. Immers, met de komst van nieuwe technologieën als internet en XML, is het steeds minder nodig om een complete administratie bij de tussenpersoon te hebben. Hij kan met een internetbrowser rechtstreeks toegang krijgen tot de bestanden die bij de verzekeraar liggen opgeslagen en daar zijn polisadministratie bijwerken. De internetbrowser kan dan geïntegreerd worden in de tussenpersoonapplicatie. De tussenpersoon kan zich met zijn eigen geautomatiseerde systemen meer en beter richten op zijn kerntaken: financiële administratie en ‘customer relation management’ (crm).
In de nabije toekomst kan de praktijk er als volgt uitzien. De tussenpersoon vraagt met behulp van zijn browser via internet de polisinformatie aan bij de desbetreffende verzekeraar. De polisinformatie kan zonodig verder verwerkt worden in de achterliggende tussenpersoonapplicatie. Ook is het mogelijk om op eenvoudige wijze een polisblad inclusief logo en handtekening af te drukken. Na het opvragen van de polisinformatie bij de verzekeraar via internet, wijzigt de tussenpersoon polisinformatie, en stuurt deze online terug naar de verzekeraar. Bij de verzekeraar loopt een online acceptatiesysteem. Dit accepteert mutaties of geeft aan welke acties er nog moeten worden ondernomen om tot een acceptatie te komen. De consequenties van de mutatie worden in XML teruggestuurd naar de tussenpersoon via internet. De tussenpersoon ziet online de consequenties van de mutatie in zijn browser. Indien gewenst kan hij dit verder verwerken in en met zijn tussenpersoonapplicatie. Bijvoorbeeld door een rekening naar de klant te sturen en die op te nemen in zijn financiële administratie.
Met de komst van XML wordt berichtenuitwisseling in de verzekeringsbranche een stuk makkelijker. Zo kan online een polisaanvraag worden geaccordeerd of kan de verzekeraar direct aanvullende informatie voor de polisaanvraag vragen. Dit brengt grote veranderingen teweeg in de werkwijze van een tussenpersoon. Hij kan zich meer en beter richten op het leveren van diensten aan de consument, omdat veel administratieve rompslomp hem uit handen wordt genomen. De applicaties voor de markt van tussenpersonen worden eenvoudiger, want ze hoeven zich slechts te richten op hun kerntaken. En bij dit alles worden de bestaande marktverhoudingen niet aangetast. De tussenpersoon blijft een belangrijke rol vervullen in de hele verzekeringsketen.
Gerhard Gerritsen Manager Standaardisatie Abz Nederland
