ABZ is een Nederlands bedrijf dat een reeks van werkprocessen heeft overgenomen van verzekeringsmaatschappijen. De informatiesystemen die nodig zijn voor het ondersteunen van deze processen heeft de onderneming zelf echter ook weer uitbesteed. Hoe houdt het bedrijf grip op zowel de ict als de aan klanten aangeboden diensten? Een gesprek met chief information officer (CIO) Corné Paalvast.
ABZ, sinds enige tijd onderdeel van het Amerikaanse ADP-concern, houdt zich bezig met wat wel genoemd wordt: ‘business service provisioning’. Een nieuwe kreet in de wereld van de management-goeroes? “Nee hoor”, zegt Corné Paalvast. Hij is chief information officer van ABZ. “Wij werken al een aantal jaren volgens dit principe.”
Het bedrijf is voortgekomen uit een reeks van initiatieven in de wereld van de verzekeraars. Deze hadden alle ten doel om door middel van samenwerking te komen tot lagere kosten. Een van die initiatieven is het aloude Assurantie Data Netwerk dat jaren geleden werd opgericht om de communicatie tussen allerlei partijen in de assurantiebranche te regelen. Business service provisioning gaat verder waar dit soort initiatieven ophouden.
“De Nederlandse verzekeringssector telt circa driehonderd bedrijven”, vertelt Paalvast. “Deze bieden allemaal min of meer dezelfde producten aan. Als we de werkprocessen bekijken die nodig zijn om deze producten te realiseren, dan zien wij dat de basisstappen die iedere verzekeraar bij het afhandelen van bijvoorbeeld een schadegeval moet zetten, bij vrijwel alle verzekeraars dezelfde zijn. Met deze basisprocessen kunnen de bedrijven zich dan ook niet onderscheiden. Dat gebeurt op een ander niveau, bijvoorbeeld met de snelheid waarmee een schademelding wordt afgehandeld of de kosten die men voor een verzekering in rekening brengt.”
“Waarom zou iedere verzekeraar dan zelf een informatiesysteem voor zo’n basisproces ontwikkelen? Daarom is men gaan samenwerken in de Stichting Standaardisatie Instituut voor Verzekeringen in de Intermediairbranche. (SIVI). Deze stichting heeft een reeks van gegevensmodellen voor basisprocessen gedefinieerd die vervolgens door ABZ mogelijk worden gemaakt met informatiesystemen. Doordat wij technologisch gezien uitsluitend met standaarden werken, kunnen alle betrokken partijen deze basisprocessen via webservices bij ons afnemen. De eigen ict-afdelingen kunnen zich hierdoor concentreren op die functionaliteit die zij nodig hebben om te kunnen concurreren – bijvoorbeeld op prijs of juist met service.”
De voordelen van deze manier van werken zijn financieel zeer interessant, meent Paalvast. “Neem een voorstel dat wij aan Duitse verzekeraars hebben gedaan voor het afhandelen van autoschadegevallen. Zij kunnen dankzij deze manier van werken een besparing realiseren van 250 tot 300 euro per geval. Het gaat dus om grote bedragen.”
Werkprocessen uiteenrafelen
Opvallend aan de manier van werken van ABZ is dat het bedrijf niet over een eigen rekencentrum beschikt. “In principe besteden wij alles uit. Wij zijn de schakel tussen de werkprocessen enerzijds en de ingekochte techniek anderzijds. Of misschien moet ik wel zeggen: wij zijn de architecten van dit schakelmechanisme.”
Hoe werkt dit nu precies in de praktijk? Hoe slaagt ABZ er in om grip te houden op enerzijds de in opdracht van derden aangeboden werkprocessen en anderzijds de ict-systemen die aan een reeks van bedrijven zijn uitbesteed? Kernwoord van de aanpak die het bedrijf sinds 2000 hanteert is wat Paalvast betreft: ‘services’.
“Wij rafelen de werkprocessen die wij onze klanten aanbieden uiteen in een aantal standaardcomponenten. ‘Service-elementen’ noemen wij dat. Wij kennen zeven groepen service-elementen. Het gaat om provisioning, billing, service management, security management, informatiemanagement, hosting- en infrastructuurservices en ten slotte een reeks van core applicaties. Onder provisioning services valt bijvoorbeeld contract management, user management en provisioning. Onder security management kennen wij policies & procedures, authentication method, authorization en encryption. Bij information management moeten we denken aan data- en meta-models, process models en bijvoorbeeld standaard messages. Een service-element is dus een duidelijk afgebakend stukje functionaliteit dat in meerdere werkprocessen een rol kan spelen. Verder is het belangrijk om te weten dat ieder service-element wordt opgebouwd uit een aantal technische componenten. Dit zijn de applicaties en systemen die nodig zijn om een service-element te kunnen realiseren, zoals een ‘certificate authority’.”
“Het werkproces dat wij een klant aanbieden, noemen wij een ‘business service’. Zo’n business service wordt opgebouwd – samengesteld is misschien een beter woord – uit een reeks van service-elementen. Daar koppelen wij vervolgens een prijs aan en stellen samen met de afnemer een service level agreement (SLA) voor deze business service op.”
Negen ict-architecten
Op deze manier heeft ABZ een reeks van bouwblokken gecreëerd op basis waarvan het een werkproces aan een klant kan aanbieden. Maar wie zorgt nu voor de technische realisatie van de componenten op basis waarvan service-elementen worden samengesteld? ABZ doet dat namelijk niet zelf. Het bedrijf beschikt niet over een eigen rekencentrum, maar kent alleen maar een kleine ict-afdeling die zorgt voor de kantoorautomatisering, e-mail, telefonie en dergelijke voor de kleine tweehonderd medewerkers van het bedrijf.
“Ten aanzien van de technische realisatie van de componenten wil ik een onderscheid maken tussen de creatie en de operatie. In principe besteden wij de operatie van ieder component geheel uit. Ten aanzien van de creatie van component geldt dat dit soms door eigen project managers en soms door externe partijen wordt gerealiseerd. Bij voorkeur werken we met op open standaarden gebaseerde componenten, maar soms bestaan die niet en moeten wij zelf iets bouwen. Dat gebeurt dan onder leiding van een van onze eigen project managers. Het feitelijke programmeren besteden wij echter altijd uit.”
Om te kunnen werken met een zo ver mogelijk gestandaardiseerde reeks van services, heeft ABZ negen ict-architecten in dienst. “Al onze business services zijn gebaseerd op de reeks van standaard service-elementen die wij in het leven hebben geroepen. Dit vereist natuurlijk wel dat de definitie van ieder service-element zorgvuldig wordt opgesteld. Wat bieden wij nu precies aan als wij het over een service-element als ’ticketing’ hebben? Wat valt daar functioneel onder? Maar ook: hoe doen wij dat technisch? De architecten houden zich met dit soort vraagstukken bezig. Bovendien is het belangrijk dat de service-elementen onderling goed kunnen samenwerken. Er is dus een overkoepelende architectuur opgesteld waarin alle service-elementen een plaats hebben gekregen. Wij gebruiken hierbij bovendien interne SLA’s. Iedere verandering die in een service-element moet worden aangebracht, zal eerst grondig onderzocht moeten worden op de impact op andere service-elementen en uiteraard op de business services die wij aanbieden.” Jaarlijks gaat het om circa 140 wijzigingen, licht Paalvast toe.
Service element managers
Ieder service-element kent een eigen service element manager. “Zie die persoon maar als een kleine ondernemer die verantwoordelijk is voor een eigen winkeltje. De feitelijke inkoop van de componenten die hij gebruikt voor het samenstellen van zijn service-element gebeurt door een afdeling ‘inkoop’. Maar verder is hij degene die er verantwoordelijk voor is dat zijn service-element optimaal functioneert, dat zijn service-element naar andere service-elementen de afgesproken SLA haalt en dergelijke.”
“Het technische beheer is uitbesteed aan de toeleveranciers van de diverse onderliggende componenten. Met die partijen is eveneens een SLA afgesproken. De service element manager moet er voor zorgen dat de toeleverancier zich aan die afspraken houdt. Dat kan hij volgen met behulp van management dashboards die door Mercury Interactive zijn geleverd. Die zijn bedoeld om een beeld te krijgen van de technische status van de diverse componenten. Daarnaast kunnen zich natuurlijk incidenten en problemen voordoen. Om de service element manager verder conform ITIL een goed beeld te geven van incidenten en problemen, hebben wij MotiSuite van Remedy geïmplementeerd.”
Service element managers praten daarnaast veelvuldig met de business service managers die verantwoordelijk zijn voor de werkprocessen die aan klanten worden geleverd, bijvoorbeeld over de kosten die voor een service-element aan de klant doorberekend kunnen worden. Is de eerste een puur intern gerichte functionaris, de business service manager heeft veelvuldig contact met de klant. Het is deze functionaris die prijsafspraken met de afnemer maakt, SLA’s afspreekt en met regelmaat overleg voert over operationele en tactische onderwerpen. Het is dan ook van belang dat ook de business service manager inzicht heeft in de status van de diverse service-elementen. Daarom zijn ook voor deze medewerkers de management dashboards van Mercury Interactive geïmplementeerd, al gaat het hier vooral om naar een hoger niveau geaggregeerde informatie, terwijl de service element manager in zijn dashboard veel gedetailleerde gegevens kan vinden.
Nieuwe service-elementen
Wat is nu precies de relatie tussen de eerder genoemde architecten en de service element managers? Wie heeft bijvoorbeeld het laatste woord over het al of niet doorvoeren van een wijziging in een service-element? Paalvast is daar heel duidelijk over: “De ‘principals’ zijn leidend. Met andere woorden: de architectuur. Dit betekent dus ook dat de architecten het laatste woord hebben. Daar staat tegenover dat de service element managers verantwoordelijk zijn voor het beheer van een service-element. Hun doel is immers om tot een exploitabele service te komen. Vanuit die rol dragen zij ook argumenten aan. Het is de bedoeling dat zij in onderling overleg beslissingen nemen over wijzigingen, waarbij de architect dus in principe de leidende partij is. In de meeste gevallen komt men er onderling wel uit. Lukt dat niet, dan wordt de situatie voorgelegd aan de CIO.”
“Ons doel”, zo stelt Paalvast, “is om het service-element ‘core applications’ zo leeg mogelijk te krijgen. Onder deze groep vallen namelijk specifieke informatiesystemen die wij nog niet uiteen hebben kunnen rafelen in individuele brokken waarvoor wij reeds standaardservice-elementen kennen. Wij werken er hard aan om het aantal applicaties in deze groep zo klein mogelijk te maken.”
Hoe zit het met nieuwe service-elementen? “Op een gegeven moment kan blijken dat er een stukje functionaliteit bestaat die wij in de vorm van een nieuw service-element zouden kunnen hergebruiken voor een grotere groep klanten. In het architectuuroverleg zal hierover de knoop worden doorgehakt, maar pas nadat er uitgebreid onderzocht is of het inderdaad technisch maar ook commercieel mogelijk is. Wat is de technische impact van een nieuw service-element op de andere service-elementen? Maar ook: verwachten wij het nieuwe service-element in voldoende mate aan klanten te kunnen leveren om het creëren ervan financieel aantrekkelijk te maken?”
Service element management uitbesteden
Over dit laatste punt zegt Paalvast verder: “Wij weten in principe wat de inkoop van een service-element kost. De afspraken die wij met klanten maken over een business service die gebruik maakt van dit service-element is een commercieel proces. Terwijl de inkoopprijs dus een vast gegeven is, is de verkoopwaarde van een service-element onderhevig aan het spel van vraag en aanbod.”
De kosten voor het vervaardigen van een nieuw service-element neemt Paalvast echter direct op het eerste project waarin dit element wordt gebruikt. “Dit wil vaak zeggen dat dit service-element bij zo’n eerste project fors verliesgevend is. Dat is op zich geen probleem, want als wij het van strategisch belang vinden om dit service-element in het leven te roepen, dan kunnen wij daarvoor een speciaal budget aanspreken. Het is uiteraard wel de bedoeling dat wij het service-element financieel zo snel mogelijk ‘boven water’ hebben. Maar dat is dus de taak van de verantwoordelijke service element manager. Die moet zijn nieuwe service-element zo goed mogelijk zien te verkopen.”
De manier waarop de rol van service element manager wordt ingevuld, is overigens aan het veranderen. “Eigenlijk vinden wij dat onze kernactiviteiten zich met name richten op de business services die wij aanbieden. In eerste instantie hebben wij het beheer van de componenten reeds uitbesteed, nu kijken wij ook naar de rol van de service element managers. Wij hebben met succes een proef gedaan met het uitbesteden van het beheer van twee service-elementen. Een aantal op SAP gebaseerde service-elementen hebben wij uitbesteed aan Ciber in Eindhoven, terwijl wij ook het beheer van de elektronische postkamer (Edi) bij wijze van proef hebben overgedragen aan InterCommit uit Amersfoort. Twee medewerkers van deze bedrijven werken gewoon hier op kantoor. Die aanpak werkt uitstekend en past ook helemaal in ons beleid dat wij alleen die taken op ons nemen die echt tot onze kernactiviteiten behoren.”
