Toen ik ergens in de vorige eeuw nog lid was van een studentenvereniging, kreeg ik voor het eerst te maken met planningsvraagstukken. Er moest elke maand een barrooster gemaakt worden voor de vereniging en dit was een tijdrovend en frustrerend handwerkje. Ambitieus en naïef als ik was, beloofde ik onze planner het probleem bij de horens te vatten door het maken van een zelf geschreven programma.

Als snel werd duidelijk dat planningsproblemen niet de meest eenvoudige problemen zijn. Met een beperkt aantal parameters gaat het nog wel. De eerste versie verdeelde de beschikbare barmensen feilloos over de beschikbare dagen. Trots liet ik de eerste resultaten zien aan de planner van onze vereniging. Een schamper lachje volgde. Hij vond het leuk, maar de planning sloeg natuurlijk nergens op. Ik moest er nog wel even rekening mee houden dat niet iedereen elke avond beschikbaar was, junior barmensen konden niet alleen staan en op drukke dagen moest er ook een reservelijst zijn.

De tweede versie liet al wat langer op zich wachten. Ik moest verschillende algortimes uitproberen en hield lange gesprekken met medestudenten over depth-first algortimen, search tree pruning en NP volledige problemen. Uiteindelijk kwam er een nieuwe versie. De berekening duurde soms 10 minuten, maar dan was er ook een planning die ‘overal’ rekening mee hield. Dat ‘overal’ bleek relatief te zijn. Nog steeds kreeg ik niet meer dan een: “ja leuk hoor, maar....”, uit onze planner. Het bleek dat er wat mensen niet met elkaar samen achter de bar wilden staan. Er waren minstens zoveel mensen die juist wel samen wilden draaien. Iedereen moest minstens 2 keer per maand zijn ingepland, maar niet meer dan 4 keer. En hoe ging het systeem om met een zieke barman?

Licht gefrustreerd en al behoorlijk minder naïef toog ik weer aan het werk. Mijn studie lijdde er inmiddels onder en mijn nachtrust helemaal. Ik heb ooit nog een laatste versie opgeleverd. Soms kreeg je al na een uur een geschikte planning, maar vaker moest het programma een nacht draaien om vervolgens met een teleurstellend: “geen mogelijke planning gevonden” te eindigen. De planner vertelde me tactvol dat het: “af en toe nog best wel handig was”.

Lang heb ik me afgevraagd waarom die menselijke planner uiteindelijk toch altijd weer een kloppende planning kon fabriceren, waar mijn programma welbeschouwd hopeloos faalde. Het antwoord is natuurlijk dat een planner zich helemaal niet aan zijn eigen regeltjes hoeft te houden. Hij kan mensen vragen toch eens een keertje extra te draaien, hij kan nieuwe barmensen werven, hij kan uitzonderingen scheppen en tegelijkertijd ook nog heel flexibel omgaan met veranderende omstandigheden.

Voor mij was dat een wijze les. Vaak heb ik aan bovenstaande problematiek gedacht toen ik met Exact software werkte. Planning van mensen is veel meer dan het proberen om alles met één magische druk op de knop goed in te plannen. De ideale planning bestaat niet. Hoe meer regeltjes, hoe moeilijker het probleem en hoe minder flexibel de resulterende planning wordt. Een goed planningssysteem gaat daarom juist niet op de stoel van de planner zitten, maar assisteert de planner door een goede visualisatie van de planning en een set van gereedschappen om de planning aan te passen. Een goed planningssysteem signaleert de fouten in de planning in plaats van dat het probeert zelf alles goed te doen. 

Qics levert software - voor het plannen, registreren, factureren, journaliseren en analyseren van uren - aan professionele dienstverleners zoals accountantskantoren, ICT bedrijven en adviesbureaus. Onze klanten willen snel en correct factureren en rapporteren en real-time inzicht hebben in hun bezettingsgraad en voortgang van projecten. Anders dan generieke pakketten zoals Exact en MultiVers, of urenregistratiepakketten zoals Sumatra, biedt Qics een volwaardige oplossing voor uren gedreven organisaties.

Mark Velthuijsen