Ontwikkel je eigen algoritme in vier stappen

Door Mischa Masthoff, gepubliceerd op 29-06-2021

Ben je een techstartup? Dan heb je er zeker een. Ben je handig met computers en boven de twaalf? Dan ben je je er vast op zijn minst in aan het verdiepen. Ben je willekeurig welke andere organisatie dan ook? Dan zou je er een moeten hebben. Nee. We hebben het niet over een Functionaris Gegevensbescherming (al zijn die ook gaaf). We hebben het over algoritmes. ‘Dat doet ons algoritme.’ Dat klinkt niet alleen stoer, maar het voordeel is ook dat niemand precies begrijpt wat het doet. Dus als het iets doms doet, komt niemand er ooit achter. Een beetje zoals een Functionaris Gegevensbescherming. In dit artikel duiken we in de wereld van de algoritmes. Wat is het? Hoe werkt het? Maar belangrijker nog. Hoe maak je er zelf een?

Wat is een algoritme?

Heb je weleens een Rubiks Kubus proberen op te lossen? Dan ben je vast begonnen door willekeurig de vlakjes wat heen en weer te draaien, in een poging om in ieder geval een paar vlakjes van dezelfde kleur bij elkaar te krijgen. Gewoon ‘kijken wat ie doet’. Na een aanvankelijk hoopvol begin (‘Ik heb er al vier!’), verdwijnt het ding na een paar uur gepruts in een la om daar vervolgens nooit meer uit te komen. Had je nou maar het algoritme gebruikt.

Een algoritme is – simpel gezegd - een recept om een probleem op te lossen. Het maakt niet uit hoe je Rubiks Kubus door elkaar gehusseld is. Als je een bepaalde volgorde van vaste stappen doorloopt, zul je uiteindelijk de Kubus oplossen.

In het algemeen bestaat een algoritme uit een aantal stappen die zich kunnen herhalen of die gebruik maken van beslissingen (bijvoorbeeld logica of vergelijkingen) om het probleem op te lossen.

Dat klinkt ingewikkeld en je kunt je algoritme ook oneindig complex maken, maar het kan ook heel simpel. Een voorbeeld? De tafel van twee is een heel simpel algoritme. Begin met twee en tel bij iedere stap twee op bij je vorige waarde.

Er zijn twee belangrijke misverstanden over algoritmes. De eerste: een algoritme hoeft niet – zoals vaak wordt gedacht – hetzelfde te zijn als een computerprogramma. De tafel van twee is een algoritme, of je hem nou geprogrammeerd hebt of niet. Het tweede misverstand: niet alle algoritmes zijn zinnig. Daarom gaan veel techstartups failliet.

Er is een bekend grapje over algortimes. Een man zegt tegen zijn vrouw dat hij even een ommetje gaat maken. Waarop zijn vrouw zegt: ‘Als je toch buiten bent, wil je dan even langs de glasbak lopen?’ De man kwam nooit meer terug. De grap is dat zodra de man naar buiten stapt voor zijn ommetje, de eerste voorwaarde van het ‘algoritme’ in werking treedt. De man is buiten. Omdat hij buiten langs de glasbak loopt, ontstaat er een ‘loop’ (een steeds terugkerende stap in het algoritme) en blijft de man voor eeuwig buiten langs de glasbak lopen. Zinnig? Nee. Grappig? Wij vinden van wel.

Wat voor soort algoritmes zijn er?

Om alle verschillende soorten algoritmes op te noemen, gaat te ver voor dit artikel. Laten we twee varianten pakken. Varianten die kijken naar de manier waarop de algoritmes ontwikkeld worden.

De eerste variant is de rule-based variant. Daarbij bedenkt een mens (bijvoorbeeld een programmeur, maar liever een inhoudelijk deskundige) zelf de stappen die het algoritme moet doorlopen. Bijvoorbeeld een (simpele) data-analyse die we voor een van onze klanten hebben gemaakt om te controleren of de projectadministratie op orde is (in de praktijk trouwens een samenspel van veel verschillende analyses). Het algoritme begint met kijken of er uren zijn geschreven op een bepaald project. Zo ja, dan kijkt het naar de datum van de eerste geschreven uren. Die datum wordt vergeleken met de datum van vandaag. Zijn er langer dan 30 dagen geleden uren geschreven op het project, dan volgt de laatste stap. Het algoritme kijkt of er sprake is van een onderliggend contract. Zo niet, dan is er sprake van een risico.

Een tweede belangrijke variant zijn algoritmes op basis van Machine Learning. Daarbij wordt het algoritme niet ontworpen door een mens, maar ontwikkelt de computer zijn eigen algoritme op basis van eerste menselijke input en (grote hoeveelheden) data. Wij gebruiken Machine Learning bijvoorbeeld bij onze analyse die bepaalt of een boeking in juiste WKR-categorie is ingedeeld. Meer weten over hoe Machine Learning precies werkt? Lees dan ons eerdere blog hierover.

Hoe maak je een algoritme?

Enthousiast geworden en wil je zelf ook een algoritme? Dat snappen we wel. In deze paragraaf gaan we voor het gemak uit van een hele smalle definitie van een algoritme: een geautomatiseerde data-analyse om fouten en risico’s in je administratie op te sporen. Waarom die definitie? Dat zijn de algoritmes die we zelf maken bij wijcontrolerenjedata.nl. Zo kunnen we je gericht een aantal voorbeelden geven.

Oke, waar beginnen we? ‘Start with why’ zou Simon Sinek zeggen. Waar heb je het algoritme voor nodig? Een klant van ons wilde grip krijgen op de reisdeclaraties van zijn medewerkers. Hoe het tot nu toe werkte was dat een medewerker een reisdeclaratie indiende via het systeem. De reisdeclaratie kwam zo terecht bij HR. Die controleerde de declaratie en legde bij akkoord de declaratie vervolgens voor aan de leidinggevende van de medewerker. Die redeneerde dat ‘HR er al naar had gekeken’ en tekende in de praktijk blind voor akkoord. Als ook de manager akkoord was, werd de declaratie uitbetaald aan de medewerker. Dat proces kostte veel tijd en mankracht. Onze klant wilde de declaraties daarom door een algoritme laten beoordelen.

De eerste stap? We gingen om tafel om te bespreken wat het doel van de controle was en wanneer er sprake zou zijn van declaraties die niet zouden moeten worden goedgekeurd. Die gevallen vertaalden we in ‘business rules’ (in dit geval de voorwaarden waar een declaratie aan zou moeten voldoen om te worden afgekeurd). Sommige van die voorwaarden waren heel simpel. Bijvoorbeeld: de declaratie van een reis die meer dan 30 dagen geleden gemaakt is wordt afgekeurd.

Anderen waren iets complexer. Bijvoorbeeld: woon-werkverkeer dat tegen een hoge kilometervergoeding wordt gedeclareerd (in plaats van tegen de gebruikelijke lage kilometervergoeding) wordt afgekeurd. Deze business rule bestaat uit meerdere regels: het algoritme kijkt naar de postcode van vertrek, matcht deze met de postcode van het huisadres van de medewerker, vergelijkt de postcode van aankomst met de postcode van de werkgever en vergelijkt deze vervolgens met de aangevraagde kilometervergoeding.

Een ander voorbeeld van een meer complexe business rule is de controle van het aantal gedeclareerde kilometers. De business rule zelf is eenvoudig: kijk naar de postcode van vertrek en vergelijk deze met de postcode van aankomst. Bepaal het aantal kilometers daartussen en vergelijk in hoeverre die kilometers afwijken van de door de werknemer opgegeven kilometers. Wat deze regel complexer maakt is dat we een koppeling moesten bouwen tussen het systeem van onze klant en een externe database waar de afstanden tussen twee postcodes uitgehaald kunnen worden.

Toen na het ontwerpen de tweede stap klaar was (het programmeren van het algoritme) kwam de derde – en meest belangrijke – stap. We gingen ons algoritme laten draaien op de data van onze klant en op basis daarvan is het altijd nodig om het algoritme aan te passen (de vierde stap). In onze ervaring is het ontwikkelen van een goed algoritme een kwestie van ontwerpen, bouwen, draaien en aanpassen.

In de praktijk kom je in het gebruik van je algortime namelijk altijd dingen tegen waar je vooraf niet aan hebt gedacht. Een voorbeeld: bij het draaien van ons algoritme viel het op dat ruim 60% van de declaraties correspondeerde met een declaratiebedrag van onder de 5 euro. Als je een afstand tussen twee postcodes controleert op hele kleine afstanden, dan is het verschil al snel relatief heel groot. Omrijden voor een wegafzetting leidt bij kleine afstanden – als je daar niet voor corrigeert – dan altijd tot een onjuiste declaratie.

Hoe voorkom je fouten in een algoritme?

De valkuil van algoritmes is dat je vaak een algoritme gebruikt voor een probleem dat complex is. Hoe complexer het probleem, hoe complexer het algoritme vaak zal worden. Hoewel veel mensen – terecht – heel enthousiast zijn over het gebruik en de potentie van algoritmes, is het gote risico dat mensen die het algoritme gebruiken, de werking van het algoritme niet meer overzien. Dat risico is nog groter als het het om Machine Learning algortimes gaat. Wij geloven heilig in de combinatie tussen mens en machine. Zonder de menselijke toets ontstaan schandalen als de toeslagenaffaire. Daarom laten wij de uitkomsten van onze algoritmes altijd toetsen door mensen (vaak de administrateurs van onze klanten). Dezelfde mensen die met de uitkomsten van de algoritmes aan de slag gaan. Snappen zij waarom het algoritme de uitkomst geeft die het geeft? En klopt die uitkomst ook echt? Zo niet, dan gebruiken we hun feedback om het algoritme aan te passen waar nodig. Niet alleen als er een fout in het algoritme zit, maar ook als het algoritme werkt zoals het ontworpen is, maar het ontwerp ‘te streng’ of juist ‘niet streng genoeg’ blijkt te zijn.

Want alleen zo is een algoritme meer dan een modewoord, maar een hulpmiddel waar je echt wat aan hebt.