Praktijkcase: van systeem naar implementatie

Beeld: Pixabay.com/blickpixel

In de afgelopen jaren is bij het COA op een vernieuwende manier inzicht ontwikkeld op de benodigde informatie om vluchtelingen humaan en sober op te vangen en te begeleiden. Dit inzicht is verkregen door de informatiebehoefte proefondervindelijk te verkennen met behulp van een prototype. Dit prototype bleek in de praktijk zo goed te voldoen, dat alle opvanglocaties van het COA dit systeem als tijdelijke applicatie zijn gaan gebruiken, ondanks de gebreken die vastzitten aan het gebruik ervan. Meer informatie over hoe dit prototype tot stand gekomen is en welke do’s en don’ts daarbij zijn komen bovendrijven, staan in het eerste artikel over de informatievoorziening bij het COA .

Vervolgens is er een herbouwtraject in gang gezet om deze tijdelijke applicatie te vervangen. Meer informatie over hoe dit traject, uitgevoerd middels Agile/Scrum, is verlopen en welke uitdagingen daarbij aan het licht kwamen, staat in het tweede artikel over de informatievoorziening bij het COA.

Doelstellingen

Bij de start van het hierboven beschreven traject had het COA een aantal doelstellingen. Na een eerste verkenning was gebleken dat er een groot gat bestond tussen de functionele behoefte die de eindgebruikers hadden om hun werk goed te kunnen doen enerzijds en de door de ICT-voorzieningen geboden functionaliteiten anderzijds. Bovendien zat er, als eindgebruikers een bepaalde wens wilden doorgeven aan ICT, een grote doorlooptijd tussen het moment van doorgeven van die wens en het moment van realiseren van die wens, áls de wens al gerealiseerd werd. Tenslotte was er een grote afstand tussen de business en de ICT-organisatie. De doelstellingen van het ingezette traject bestonden eruit om deze ongewenste situaties te adresseren.

Na afloop van het deel van het traject waarin de tijdelijke applicatie werd gerealiseerd, waren bovenstaande doelstellingen al grotendeels behaald. De tijdelijke applicatie voorzag in eerder ontbrekende functionaliteiten, kon snel aangepast worden aan gebruikerswensen en op maat gemaakt worden voor specifieke gebruikersgroepen. Doordat de applicatie op locatie in nauwe samenwerking met de eindgebruikers werd gerealiseerd, was de kloof tussen business en ICT bovendien nagenoeg verdwenen.

De tijdelijke applicatie had echter wel nog problemen, vandaar dat een herbouwtraject in gang is gezet (zie voor verdere detaillering het eerder genoemde tweede artikel). Na afronding van het herbouwtraject kon de tijdelijke applicatie daadwerkelijk vervangen gaan worden en de nieuwe applicatie in beheer genomen gaan worden. De belangrijkste doelstellingen bij die implementatie en inbeheername waren om de nieuwe applicatie beheersbaar te houden en om een beheerorganisatie neer te zetten met inachtneming van de oorspronkelijke doelstellingen van het gehele traject. Met andere woorden, de voorlopige resultaten die behaald waren middels het realiseren van de tijdelijke applicatie (en de wijze waarop dat gebeurd was), mochten niet verloren gaan.

Beschouwing: waar zijn we tegenaan gelopen?

De overgang van een bestaand naar een nieuw systeem is nooit eenvoudig, zelfs als het bestaande systeem eigenlijk niet meer voldoet. In dit geval waren de gebruikers over het algemeen tevreden met het bestaande systeem. Het systeem was niet ideaal, maar omdat het in nauwe samenhang met de gebruikers was gerealiseerd werden zelfs relatief grote onvolkomenheden geaccepteerd. De lat voor de implementatie van de nieuwe applicatie werd daarom vanaf het begin door de gebruikers hoog gelegd.

Daarentegen bestonden bij de beheerders van het bestaande systeem veel vraagtekens over de mogelijkheid om een degelijk systeem goed te kunnen beheren tegen acceptabele kosten. De documentatie van het systeem was niet op peil, de architectuur van het systeem sloot niet aan, de software die gebruikt was paste niet bij de gekozen standaarden. Het opnieuw bouwen van het systeem zou betekenen dat de implementatie een stuk eenvoudiger zou worden. De betrokken ICT’ers stonden dan ook positief tegenover de implementatie.
Tegen deze achtergrond is bij de herbouw getracht om een goed evenwicht te kiezen tussen de behoefte van de gebruikers en de standaarden vanuit ICT. Dit evenwicht is gevonden maar bij de implementatie is duidelijk geworden dat op een aantal punten dit tot spanningen heeft geleid. De volgende punten zijn hierbij zichtbaar geworden:

• Het bestaande systeem bestond uit een verzameling kleine systemen. Elk team kon daardoor beschikken over een eigen min of meer op maat gemaakt systeem. Als gevolg hiervan konden eenvoudig en snel nieuwe wensen worden gerealiseerd. Het nieuwe systeem kent deze opbouw niet. Het is in principe een systeem dat door elk team wordt gebruikt. Binnen dit generieke concept is het in beperkte mate mogelijk om specifieke wensen van een team te ondersteunen. Om dit concept te kunnen realiseren is het van belang dat op voorhand alle wensen goed in beeld zijn gebracht. Dit bleek lastig omdat gebruikers niet in staat waren om voorafgaande aan de implementatie alle uitzonderingssituaties goed in beeld te kunnen brengen. Dit heeft ertoe geleid dat de implementatie bij enkele teams maanden heeft geduurd.

• Voorafgaande aan de bouw van het nieuwe systeem is getracht om een allesomvattende architectuur voor het nieuwe systeem te maken. Dit heeft bij de bouw geleid tot vertraging (zie hiervoor het tweede artikel) maar ook bij de implementatie heeft de gekozen architectuur tot knelpunten geleid. De werkzaamheden van het COA zijn sterk afhankelijk van maatschappelijke ontwikkelingen. De maatschappelijke veranderingen tijdens de bouw van het nieuwe systeem maakten het moeilijk om bij de implementatie goed aan te sluiten op de actuele behoefte. De architectuur was zodanig gekozen dat goed kon worden beheerd, maar het liet onvoldoende speelruimte voor maatschappelijke veranderingen. De implementatie aan de kant van de gebruikers is daardoor moeilijker geweest.

• Het bestaande systeem is ontwikkeld op locatie. De ontwikkelploeg op locatie heeft bij deze ontwikkeling kennis en relaties opgebouwd. De werkzaamheden van de ontwikkelploeg m.b.t. het beheer zijn overgedragen aan een beheerploeg. De ontwikkelploeg is daarna vertrokken waarbij de kennis en de relaties onvolledig zijn overgedragen.

• Het gat dat hierdoor is ontstaan tussen de gebruikers en de beheerders is getracht te overbruggen door het instellen van een serviceteam. Dit team werkt in het land en verzamelt op locatie de wensen van gebruikers. Anders dan voorheen kan het serviceteam geen aanpassingen aanbrengen in de software. Hierdoor is de afstand tussen de gebruikers en de ontwikkelploeg groter geworden, met potentieel nadelige gevolgen voor de bruikbaarheid van de gebouwde software.

• Het effect van het verloren gaan van kennis en relaties bij de implementatie werd vergroot door het feit dat er verschil zit in houding en gedrag tussen een ontwikkelploeg en een beheerploeg. De beheerploeg richt zich meer op procedures en minder op resultaat; bovendien is de emotionele binding anders. Ontwikkelaars zien het meer als ‘mijn kindje’ terwijl de beheerders het meer zien als dagelijks werk om te onderhouden (stiefkindje)

• Als laatste en zeker niet als minste is bij de implementatie duidelijk geworden dat de emotionele binding van gebruikers met het systeem anders is. Bij het bestaande systeem werd meer eigenaarschap ervaren terwijl het nieuwe systeem meer ‘van het hoofdkantoor’ is. Aan de kant van ICT was juist het tegenovergestelde te zien. Eindelijk kon vanuit beheer worden beschikt over een professioneel systeem dat goed te beheren was.

Evaluatie

Implementatie wordt vaak beschouwd als sluitstuk van een systeemontwikkelingstraject. Bij de ontwikkeling van het bestaande systeem is de implementatie juist als startpunt genomen. Implementatie heeft echter niet alleen betrekking op de ingebruikname van een systeem door de gebruikers. Ook is het van belang dat een systeem goed in beheer kan worden genomen. Dit betekent acceptatie bij zowel de gebruikers als de ICT’ers. De waardering van het nieuwe systeem in vergelijking met het bestaande systeem geeft een verschillend beeld vanuit het perspectief van gebruikers en ICT’ers.

In de volgende tabel worden het bestaande en het nieuwe systeem aan de hand van enkele eigenschappen vergeleken om wat meer inzicht te krijgen in de overeenkomsten en verschillen in waardering.

[1] Hier is de uptime genomen van het ‘standalone’ systeem. De koppeling met andere systemen is minder stabiel, maar aangezien die ontbrak in het oude systeem, is het voor een eerlijke vergelijking incorrect om dat mee te nemen in deze statistiek.

Te zien is dat hoewel het nieuwe systeem enkele voor ICT én gebruikers interessante voordelen heeft (minder administratieve last, minder maatwerk, passend in architectuur, beter beheerproces, betere beveiliging), dat dit niet heeft geleid tot betere – voor ICT én gebruikers belangrijke – prestaties in termen van kosten (beheer, doorontwikkeling, implementatie en exploitatie), performance en snelheid waarmee beheer kan worden uitgevoerd.

Dit betekent dat alhoewel bij het nieuwe systeem veel meer rekening is gehouden met het beheer, het beheer nog steeds niet optimaal is. Dat blijkt uit:

• Gebruikers moeten langer wachten op aanpassingen aan het systeem dan dat ze dit wenselijk vinden. De doorlooptijd voor de realisatie van wensen is langer geworden omdat bij aanpassingen de OTAP-straat doorlopen moet worden als gevolg van de eisen vanuit ICT.

• Als gevolg van de lange doorlooptijd en de toegenomen complexiteit van het systeem is het lastig om voldoende aanpassingen aan het systeem te kunnen realiseren. Als gevolg hiervan neemt de wensenlijst van gebruikers toe. Weliswaar is het mogelijk om meer releases in een jaar te realiseren, echter het is niet mogelijk om meer functionaliteit aan te bieden. Laag geprioriteerde wensen worden daarom niet gerealiseerd.

• Bij de bouw van het nieuwe systeem is een nieuwe architectuur ontwikkeld. Dit heeft als gevolg gehad dat de nieuwe applicatie minder flexibel is dan het oude systeem. Vanuit ICT is er tevredenheid omdat onder architectuur is gebouwd. Gebruikers merken dit vooral omdat minder goed geanticipeerd kan worden op hun wensen.

De overall conclusie kan getrokken worden dat behoefte van gebruikers en standaarden vanuit ICT dichter bij elkaar zijn gebracht, echter omdat beiden een beetje water in de wijn hebben gedaan is de vraag of niet een suboptimale oplossing is gerealiseerd.

Lars Wortel is consultant bij Capgemini. Johan van Wamelen is beleidsadviseur bj het COA en richt zich in zijn werkzaamheden op het slaan van een brug tussen gebruikers en aanbieders van ICT voorzieningen. Zijn interesse ligt bij vraagstukken op het gebied van de organisatie van de informatievoorziening in grote publieke organisaties.