Veranderende wetten uitdaging voor it’ers
In een recent artikel in Trouw (4 juni) valt te lezen hoe de overheid zou smijten met geld voor gebrekkige software. Prof. dr. H. A. Proper vraagt zich af hoe groot het probleem is en zoekt eventuele oorzaken.
Veel informaticaonderzoekers, mezelf incluis, vergeten nogal eens dat het meeste geld dat aan automatisering wordt besteed gaat zitten in het operationele beheer van bestaande systemen. Als de overheid dus miljarden steekt in softwaresystemen, is het belangrijk ons te bezinnen op de vraag welk deel van dit bedrag besteed wordt aan de ontwikkeling van nieuwe systemen en welk deel aan het operationeel houden van bestaande systemen.Ik heb geen inzicht in de cijfers waarop het artikel in Trouw is gebaseerd, maar men doet het voorkomen alsof het hele budget dat door de overheid wordt besteed aan automatisering weggegooid geld is. Dat lijkt me vooralsnog iets te kort door de bocht. Desondanks is het, zoals gezegd, geen geheim dat veel it-projecten falen. Hoe komt dit? Daar zou zeker meer onderzoek naar gedaan moeten worden. Maar wat zouden mogelijke oorzaken kunnen zijn?
Een eerste observatie is dat de gemiddelde it’er geen vakopleiding heeft genoten. Als je geluk hebt, heeft de gemiddelde it’er een academische opleiding genoten. Als je erg veel geluk hebt, dan tref je er een aan die daadwerkelijk een informaticaopleiding heeft gehad. Informatica is een vak. Om het uit te kunnen oefenen is een degelijke opleiding nodig.
In het artikel in Trouw wordt een vergelijking gemaakt met de Betuwelijn. De hoeveelheid geld die jaarlijks als gevolg van mislukte it-projecten over de balk wordt gesmeten, zou groter zijn dan het bedrag dat is/wordt uitgegeven aan de Betuwelijn. Even los van de vraag of de cijfers kloppen, zit hier nog een mogelijke oorzaak van het falen van it-projecten. Voor het maken van software moet er eerst een helder programma van eisen opgesteld worden. Maar omdat software nogal abstract van aard is, is het vaak moeilijk voor mensen om hun behoeften onder woorden te brengen of te toetsen of deze goed op papier zijn gezet. Gevolg is dan vaak dat systemen worden gemaakt die niet voldoen aan de (impliciet gebleven) wensen. Bij projecten zoals de Betuwelijn is dit anders. Iedereen kan zich voorstellen wat het is om een spoorlijn door je achtertuin te hebben lopen. We kunnen allemaal aanschouwen hoe er een litteken door de Betuwe is getrokken, terwijl we op de A1 en de A12 nog steeds struikelen over vrachtwagens. Bij it is dat minder tastbaar. Hoewel het met het nieuwe toeslagensysteem van de Belastingdienst nu politiek gezien ineens wel tastbaar wordt.
De software die gebruikt wordt in onze vele ”formulierverwerkende fabrieken” (zoals de Belastingdienst) is vaak een directe afspiegeling van de wetgeving. Wetgeving heeft twee eigenschappen die vanuit de wereld van de software nogal vervelend zijn.
Ten eerste breken de bewust of onbewust aanwezige vaagheden en inconsistenties die nodig waren om tot een politiek compromis te komen, hard op bij het automatiseren van dergelijke wetgeving. Een computer heeft eenduidigheid en consistentie nodig. Een computer is eigenlijk continu met een ”stiptheidsactie” bezig, en doet alles precies volgens de regels. Het zou wellicht goed zijn om wetten, die terechtkomen in geautomatiseerde systemen, te toetsen op implementeerbaarheid voordat ze door de Kamer(s) worden goedgekeurd.
Een tweede probleem is het feit dat wetten nogal eens veranderen. Dit is overigens in eerste instantie geen probleem, maar een uitdaging. Er zijn technieken om, mits de wet consistent en eenduidig is, deze redelijk makkelijk in systemen in te bouwen. Wat het wel lastiger maakt, is dat veel wetswijzigingen geen wijzigingen zijn maar uitbreidingen en/of verfijningen van bestaande wetten. Dit leidt al snel tot inconsistenties in de regels, en dus weer tot problemen bij de implementatie in systemen.
Ten slotte denk ik dat wij als informaticawetenschappers ook de hand in eigen boezem moeten steken. Veel onderzoek in Nederland richt zich op de vraag: hoe moeten we goede software maken? Hierbij gaat men er vaak (impliciet) van uit dat het eerdergenoemde programma van eisen als het ware ”uit de boerenkool” komt. Uit onderzoek van onder andere The Standish Group blijkt dat veel projecten falen omdat men de verkeerde software maakt.
De auteur is hoogleraar informatiekunde aan de Radboud Universiteit Nijmegen.