Bottlenecks bij Enterprise Integration Solutions

Om businessdoelen zoals onder meer ‘klant centraal’ en ‘efficiënte IT-ondersteuning’ mogelijk te maken, kiezen organisaties voor het integreren en/of samenvoegen van IT-systemen. Klanten en ook managers krijgen beter en sneller inzicht in de dienstverlening en de performance van de organisatie. Systeemintegratie is daarmee een niet meer te stoppen trend die zich ook al lang bewezen heeft!

Het koppelen van systemen en vervangen van onderdelen is echter als het repareren van een motor die nog loopt. Het leidt vaak tot complexe IT-projecten en niet zelden blijkt (pas) tijdens de uitvoering dat het automatisch uitwisselen van gegevens en/of het samenvoegen van gegevensverzamelingen op moeilijk oplosbare praktische problemen stuit. Omdat systeemintegratie onderdeel is van een groter geheel, kan systeemintegratie vaak alleen in haar bredere context worden aangepakt. 

Uit de projecten die we de afgelopen jaren bij klanten mochten uitvoeren, is een aantal generieke problemen naar voren gekomen waaraan beter vooraf aandacht aan had moeten worden besteed. De strategie om deze op te lossen verschilt per klant en is altijd maatwerk.

Hoe kun je systemen goed koppelen? Dat is een vraag die vaak voorbijkomt en niet eenvoudig te beantwoorden is. Over interne systemen hebben bedrijven vaak nog wel controle, maar koppelingen tussen interne en externe systemen maken integratie vaak lastiger; zowel qua timing (wanneer koppelen we) als inhoud (welk systeem beschouwen we als master-data). Het is nodig om onderscheid te maken in de informatiebehoefte en timing per systeem. Eindgebruikers, vaak de klanten, werken vaak met realtime systemen, zoals webapplicaties voor saldo-informatie, incidentregistratie of een order-(tracking-)systeem. Daarnaast zijn er echter ook tal van andere soorten applicaties, zoals een hypotheek- of salarissysteem dat vaak maar één keer per maand (of zelfs één keer per jaar) een piek-load te verwerken heeft. Voor koppelen en verwerken van mutaties is van belang dat duidelijk wordt vastgelegd op welk moment welke data wordt gedeeld en hoe wordt omgegaan met mutaties. Binnen de scope van een systeem kan informatie vaak worden geaggregeerd per tijd (dag/week/maand) en per klant, waardoor het koppelen en delen van informatie overzichtelijk blijft. Door helder te definiëren waar de details worden vastgelegd en waar de aggregaties plaatvinden, wordt het proces geoptimaliseerd. 

In omgevingen met veel behoefte aan detail-stuurinformatie (bijvoorbeeld ten behoeve van managementinformatiesystemen) kan ervoor worden gekozen om data te dupliceren naar een operational data store of data lake. Hierbij wordt een snapshot (kopie) gemaakt van de gegevens in het operationele systeem, zodat het mogelijk is om de stand van zaken op een bepaalde tijd ook later terug te kunnen zien. Bij het koppelen aan andere systemen is het belangrijk dat de timing hiervan tussen systemen gelijk is en afhankelijkheden worden gewaarborgd: een kopie van een factuursysteem is immers alleen waardevol als ook de kopie van het klantsysteem gelijk is, anders zijn er facturen zonder klant, omdat de timing asynchroon is.

Basis op orde
De aanleiding voor een project is vaak dat systemen zijn verouderd, worden uitgefaseerd en/of niet meer mee kunnen komen met de nieuwste ontwikkelingen. De samenwerking tussen systemen komt dan niet van de grond of is complex, dus wordt besloten tot een nieuw systeem, dat alle problemen die voorkomen gaat oplossen. Uiteraard moet daarbij vaak de historie die in de huidige systemen is opgeslagen worden bewaard.

Helaas blijkt de praktijk vaak weerbarstig: vrije tekstvelden in oude systemen zijn vaak niet eenduidig te vertalen. De flexibiliteit die daarmee werd bereikt gaf veel ruimte voor interpretatie door eindgebruikers, maar werkt tegen in het noodzakelijke (her)standaardiseren van de processen. De vraag erachter wordt dan ook: kunnen we dit deel van de processen standaardiseren, of blijft er noodzaak voor dit soort flexibiliteit en open eindjes?

Keten van workarounds
Ook in de bestaande situatie worden soms meerdere systemen gebruikt om een proces tot een goed einde te brengen. Dan komt het voor dat niet elk bestaand systeem (volledig) in staat is de requirements te ondersteunen. Denk hierbij bijvoorbeeld aan klanten met meerdere afleveradressen en één factuuradres, of een holding (zoals Ahold of Shell) met meerdere BV’s als klant die op holding-niveau een factuuroverzicht willen. Als dit soort requirements door één van de gebruikte systemen niet wordt ondersteund dan wordt er in de andere gebruikte systemen vaak een workaround geïmplementeerd om dit toch mogelijk te maken.

Nadeel van deze workarounds is dat deze vaak niet gedocumenteerd zijn en slechts bekend zijn bij enkele senior eindgebruikers. Bij het vervangen of integreren van één (of meer) van de bestaande systemen kan dit dan ook zorgen voor onbegrip en starheid. 

Internationale samenwerking en (juridische, culturele) verschillen
Het doel om systemen te laten samenwerken over landsgrenzen heen, is een vaak uitgesproken ambitie binnen organisaties. Een systeem dat in meerdere landen te gebruiken is, kan immers leiden tot aanzienlijke kostenbesparing. Ook hierin is de praktijk helaas vaak weerbarstig, omdat er door wetgeving of door specifieke situaties toch altijd weer aanpassingen nodig zijn. Twee voorbeelden uit de praktijk: 

• Het samenvoegen van een bancair systeem op één platform van rekeningen uit twee landen (Nederland en België) bleek na meer dan een jaar onderzoek toch niet mogelijk. Op het eerste oog lijkt een bankrekening een vrij eenvoudig product, dus – hoe moeilijk kan het zijn? – is dan de logische vraag. In Nederland is een betaalrekening altijd gekoppeld aan een of twee personen, maar nooit aan meer. In België echter is het mogelijk dat een rekening aan veel meer personen gekoppeld is met verschillende rechten. Bijvoorbeeld: de penningmeester van de voetbalclub mag betalingen uitvoeren en alle (10+) andere bestuursleden hebben leesrechten op de rekening. Dit verschil over de landgrenzen bleek, gegeven alle andere requirements, niet in één al bestaand systeem op te lossen.

• Voor een internationaal opererend containerbedrijf is een nieuw systeem geïntroduceerd voor de registratie van hun containers die over de hele wereld reizen. In de datamigratie worden verschillende processen per land onderscheiden, maar het deel wat ingewikkelder te modelleren was, bleek de regio ‘internationale wateren’ te zijn en de overgang tussen landsgrenzen. Een bestelling van 100 containers komt bijvoorbeeld aan in The Port of Santos in São Paulo. Daarvan zijn er 50 verkocht, dus die gaan de landsgrens over, 30 containers worden in internationale wateren overgezet naar een vrachtschip richting Mexico en 20 containers blijven op het haventerrein (in niemandsland) achter, in afwachting van een verwachte order later. Het overzetten van containers tussen verschillende reizen buiten landsgrenzen bleek ingewikkeld, doordat ze soms wel van vrachtschip wisselen, soms op hetzelfde vrachtschip blijven en doorvaren of in andere gevallen op het haventerrein op een volgende bestemming moesten wachten.

Standaardisatie van processen – niet alleen de happy flow
Om systemen te kunnen koppelen is het nodig eenduidige definities en afspraken te hanteren. Daarbij zijn vaak zowel interne als externe systemen betrokken, die elk op hun eigen manier een deel van het proces ondersteunen. Bij de implementatie hiervan zal een bedrijf vaak een keuze moeten maken: gaan we ons bedrijf conformeren aan het systeem, of willen we het systeem aanpassen voor ons bedrijf. Een bedrijfsproces is vaak een complex samenspel van standaardsystemen (HR-systeem, boekhoudsysteem, ordersysteem) en maatwerksystemen die niet vanzelf op elkaar passen. De ketenafhankelijkheid tussen systemen moet duidelijk in kaart zijn gebracht, voordat tot standaardisatie van onderdelen kan worden overgegaan. 

Een voorbeeld uit de praktijk is bijvoorbeeld het ‘Indiensttredingsproces’ dat elke organisatie kent. Een nieuwe medewerker aannemen raakt vele onderdelen van een organisatie: al voor de indiensttreding moeten persoonsgegevens worden opgeslagen en moet worden voldaan aan AVG-richtlijnen, zonder dat er een personeelsnummer in een HR-systeem is vastgelegd. Nadat het contract door beide partijen is getekend, kan een toekomstige employee worden toegevoegd aan het systeem. In een goed gekoppeld systeem wordt daarna ook het proces opgestart voor het bestellen van een laptop, een leaseauto en het aanvragen van licenties en rollen en rechten voor toegang tot de relevante systemen. Maar wat te doen als een medewerker achteraf besluit toch niet te komen en het contract weer op te zeggen (bijvoorbeeld omdat de huidige werkgever met een tegenbod kwam)? Is de keten van systemen ook in staat om de annulering van de laptop en auto goed af te handelen? Hoe zorgen we dat de indiensttreding geannuleerd wordt en er geen salaris wordt uitbetaald en geen pensioenreservering wordt gedaan? 

In dit soort gevallen gaan enterprise-applicatie-integratie en businessproces-(re)design vaak hand in hand. Het is vaak al complex genoeg om het standaardproces en het happy path te automatiseren. Wanneer hiervan wordt afgeweken en ook uitzonderingen in beeld komen, blijkt dat veel systemen hier niet goed mee om kunnen gaan en dat handmatige ingrepen en uitzonderingen nodig zijn. Dit leidt vervolgens tot gebroken processen en incomplete integraties waar vooraf geen rekening mee was gehouden.

Ten slotte
Met het bespreken van vier generieke problemen, of bottlenecks, bij systeemintegratie wordt zeker geen volledigheid beoogd. Er kan zoveel meer misgaan.

Het is echter niet de bedoeling om enterprise-integratie dan maar in de ijskast te plaatsen: het mogelijk maken van zaken als ‘klant centraal’ en ‘efficiënte IT-ondersteuning’ is daarvoor te belangrijk! Wel is het goed om allereerst een duidelijk beeld te hebben welke bottlenecks mogelijk ontstaan – eigenlijk al voordat systeemvervanging of -integratie aan de orde komt.

Vanuit KPMG leveren wij graag ondersteuning bij het voorkomen van problemen door deze bottlenecks. Wij doen dit met onderzoek, advies en praktische hulp. Voor meer informatie kunt u contact opnemen met Jochem van Galen en/of Joost Koedijk.

Jochem van Galen
Senior Expert, Digital Enablement
KPMG Nederland