Communicatie is misschien wel een van de belangrijkste aspecten van ICT. En communicatie moet – zoals altijd van twee kanten komen – gebruikers van software (domeinspecialisten) moeten goed kunnen uitleggen wat zij van ICT verwachten. De programmeur moet niet alleen kunnen programmeren. Hij moet ook luisteren en documenteren wat hij doet. Mensen die domeinkennis en ICT echt aan elkaar kunnen knuppen hebben de toekomst.
Uiteindelijk gaat het om communicatie. Softwaremakers moeten goed luisteren naar gebruikers. Gebruikers moeten hun wensen helder verwoorden. Het klinkt zo normaal. Na 50 jaar ICT zou dat toch eigenlijk gewoon moeten zijn. Maar dat valt tegen. In gesprek met Marieke Huisman, in 2013 won zij een belangrijke Nederlandse prijs voor baanbrekend ICT-research. Zij is professor software betrouwbaarheid binnen de vakgroep FMT (Formal Methods and Tools). Plat vertaald betekent dat:
- programmeren, concurrent, dus software die meerdere dingen tegelijk kan doen;
- formele methodes, systematisch werken en goed vastleggen hoe software is opgebouwd
- program verification, doet de software wat ze moet doen?
Software-ontwikkeling gaat wel eens fout. En hoewel zij geen concrete uitspraak doet over het nu tienjarige SBR/XBRL-traject maakt zij daar wel in algemene zin een opmerking over. ‘Betrouwbaarheid van software blijft een groot probleem.’ In dit kader verwijst zij naar de grote ICT-projecten bij de overheid. Er is blijkbaar heel weinig communicatie. ‘Techneuten hebben moeite om te communiceren met eindgebruikers en eindgebruikers weten niet wat er kan en weten niet hoe ze dingen moeten vragen.’
Domeinkennis
‘Om een systeem te kunnen begrijpen heb je domeinkennis (accounting, audit, legal, enz. red.) Aan de techkant heb je mensen nodig die iets kunnen maken wat betrouwbaar is en dat ook in onverwachte situaties doet wat het moet doen. Uiteindelijk heb je ook mensen nodig die beide eigenschappen combineren.’
In het gesprek valt nu de term ‘cross-overs’. En om binnen accountancy te blijven: dat zijn dus mensen die zowel snappen hoe accounting werkt, maar die ook snappen hoe software werkt en die ook zelf code zouden moeten kunnen lezen. Marieke Huisman komt met een aantal voorbeelden. Enerzijds de al eerder door haar aangehaalde overheidsvoorbeelden waar het duidelijk in de communicatie niet goed ging. Aan de andere kant een voorbeeld waarbij het wel goed ging. ‘Bij banken is ICT en security uiterst belangrijk. Security-afdelingen bij banken zijn groot. Het zijn ook uitdagende plekken om te werken. Op het moment dat de banken gingen samenwerken en de security-afdelingen informatie met elkaar gingen uitwisselen kregen zij grip op de situatie. Toen konden ze aanvallen tegenhouden.’
Uiteindelijk is wat klanten op hun PC doen misschien wel minstens zo’n groot risico voor banken. ‘Op het moment dat banken iets tegen kunnen houden, kijken hackers naar ander mogelijkheden. Dat is niet iets wat morgen opgelost is.’
Bezin voordat je begint
‘Wat wij als wetenschappers graag zouden zien is dat er meer tijd wordt besteed om in het begin goed na te denken over: wat willen we nu eigenlijk? Denk goed na: hoe moet het eruit zien? Wat moet het doen?
Ik ben van de formele methode. Je hebt in een domein een verzameling van regels. Dan gaan we op zoek naar formules die de logica in regels kunnen vangen. Daarna gaan we kijken hoe we dat kunnen implementeren.
Maar wat is vaak een typische aanpak: we denken dat we deze specifieke verzameling van 100 regels heel goed op deze manier doen. Komt er iets bij, dan maken we wel een patch (een digitaal noodverbandje, red.) die eventuele toevoegingen er ook bij kan pakken. Dan ben je spaghetti aan het maken, waardoor je niet meer ziet dat wat je op de ene plek wijzigt, mogelijk op een andere plek gevolgen kan hebben.’
Zijn dat fouten detailniveau? ‘Vaak wel. En dan moet je wel goed testen. Maar meer zekerheid kost ook meer tijd. Heb je mogelijke “corner cases” – ongebruikelijke situaties – goed geëvalueerd.’ Zij geeft een voorbeeld dat accountants zou moeten aanspreken. ‘Twee getallen met heel veel cijfers achter de komma. Wanneer je die gaat vermenigvuldigen en vervolgens afronden, dan kan dat weleens fout gaan.’
‘Moderne software kan heel veel dingen tegelijk, concurrent wordt dat genoemd. Dat is een mogelijk bron van fouten. Als zaken niet goed beveiligd zijn dan is het mogelijk dat er twee berekeningen gelijktijdig op hetzelfde stukje geheugen plaatsvinden. Dat kan tot onverwacht gedrag leiden. Moet je wel op anticiperen.’
Domeinspecifiek
Zij ziet aan de ene kant een ontwikkeling in de richting van domeinspecifieke programmeertalen. Zij ziet dat bij banken, bij accountants. Veel domeinkennis maakt productontwikkeling veel makkelijker. De code wordt in die talen min of meer afgeschermd. Daaronder zit echter wel degelijk een vertaling naar machinecode. En voor die andere kant heb je mensen nodig die daar weer heel veel van af weten.’
‘ICT is een geweldig hulpmiddel. Je moet er echter nooit blind op varen, zeker nu nog niet! Het neemt vele taken waar herhaling in zit weg. Wat we wel zien is computers de zelf verbanden liggen.’
In administratieve software doet de software een boekingsvoorstel op basis van de ervaring met eerdere boekingen.
‘Zo lang dit binnen hetzelfde domein blijft is er niet zo veel aan de hand. Komt het ook daarbuiten dan kan het een risico worden.’
Er is volgens haar toch nog steeds veel software waarbij men niet precies weet wat het doet. Zij noemt als voorbeeld oudere software in de energiesector. ‘Men durft er eigenlijk ook niet aan te werken. Moet gewoon zo blijven, omdat als het fout gaat de consequenties te groot zijn.’
Het gaat om wat zij de ‘intent’ van software noemt. Dat betekent niet per se kijken naar hoe oud de software is maar wat het moet kunnen en hoe goed dat beschreven is? ‘Iets wat oud is kan prima werken, wanneer je maar weet wat er gebeurt. Vaak is het probleem dat de mensen die het geschreven hebben weg zijn en het systeem onvoldoende is gedocumenteerd. Nu heb je zelflerende systemen. Software die zichzelf kan aanpassen. Hoe hou je dan controle?’
Hoe zou het curriculum eruit moeten zien voor accountants die cijfers moeten controleren die versleuteld zitten in allerlei systemen?
‘… moeilijke vraag. Degene die de software gebruikt moet de software wel begrijpen. Maar het gaat ook om de mensen die de systemen hebben ontwikkeld. Die moeten competent zijn. Weten waarmee ze bezig zijn en documenteren wat ze doen. Als iets complex is moeten ze kunnen vertellen welke keuzes ze hebben gemaakt. Zodat ook een andere programmeur kan begrijpen wat die eerste programmeur heeft gebouwd.
We hebben hier een opleiding bedrijfsinformatica. De studenten doen zowel bestuurskunde als informatica. Beide moeten ze beheersen. Dat hebben ze later nodig om een programmeur te kunnen aansturen.’
Die crossovers hebben de toekomst?
‘Ja.’
Lees hier hoe contentpartner Exact omgaat met innovatie in accountancy en meer specifiek rond mobile devices
Herkenbaar, dit speelt denk ik in alle sectoren. Het zou een groot gewin zijn als de programmeurs luisteren naar de wensen van de eindgebruikers en niet voorschrijven hoe de eindgebruikers zouden moeten werken. Maar ja, het houdt mij in ieder geval wel van de straat, als “tolk” tussen de eindgebruiker en de programmeur.