Wanneer zijn je constraints zo specifiek dat een generieke solver averechts werkt?
De meeste commerciële planning engines zijn gebouwd rond gangbare constraints: capaciteit, tijdvensters, beschikbaarheid. Dat werkt prima zolang jouw operatie daarbinnen past. Het probleem ontstaat bij bedrijven die meerdere lagen van domeinspecifieke regels hebben. Denk aan een transportbedrijf dat met vaste klantafspraken werkt over specifieke chauffeur-klant combinaties, gecombineerd met materiaalcertificaten per voertuig en tijdslotbeperkingen per terminal. Een generieke solver ziet die regels als afzonderlijke parameters. Jij weet dat ze met elkaar interfereren op manieren die de solver niet kan modelleren. Het resultaat: de engine geeft een 'optimaal' schema dat de planner meteen afschiet omdat het praktisch niet uitvoerbaar is. Je hebt dan geen planningstool, je hebt een conflictgenerator. De vraag is niet of commerciële engines goed zijn, want dat zijn ze voor het gemiddelde geval. De vraag is of jouw operatie gemiddeld is. Als het antwoord nee is, is maatwerk planningssoftware bouwen geen luxe maar een noodzaak.
Hoe zet je het datamodel op zodat je planningssoftware niet vastloopt bij groei?
Dit is het leermoment dat het minst sexy is en het vaakst wordt overgeslagen. Planningssoftware heeft altijd een statusmodel: een order is beschikbaar, ingepland, bevestigd, in uitvoering, gereed. Hoe je dat model opzet, bepaalt of het systeem over twee jaar nog uitbreidbaar is. De fout die we zien is dat status wordt opgeslagen als een losse string in een ordertabel, zonder transities, zonder tijdstempels, zonder wie-heeft-wat-gedaan. Dat werkt in een prototype. Bij honderd orders per dag en drie planners die tegelijk werken, loopt het vast. Beter is een apart statusverlooptabel met een onveranderlijk logboek van elke transitie, inclusief reden en actor. Dat klinkt als overengineering, maar het is precies het fundament waarop je later rapportage, auditing en AI-ondersteuning kunt bouwen zonder het systeem te herstructureren. Hetzelfde geldt voor het datamodel van resources: plan niet alleen de capaciteit van vandaag in, maar modelleer ook hoe resources zich kwalificeren, verlopen en combineerbaar zijn. Een datamodel dat logisch aanvoelt voor de huidige situatie is over een jaar een keurslijf als de operatie groeit.
Wanneer gebruik je toch een library of externe solver?
Maatwerk planningssoftware bouwen betekent niet dat je alles zelf schrijft. Er zijn situaties waarin je een bestaande optimalisatielibrary inzet, en situaties waarin je dat beter niet doet. Gebruik een solver of library als het wiskundige probleem generiek genoeg is. Routeoptimalisatie op basis van afstand en tijdvensters is een klassiek vehicle routing problem. Daar zijn volwassen open-source libraries voor die beter presteren dan wat je zelf in een paar weken bouwt. Gebruik geen solver als de constraints zo verweven zijn met domeinkennis dat ze niet vallen uit te drukken in de invoervorm die de library verwacht. Dat leidt tot het vertalen van jouw werkelijkheid naar een abstract model, het interpreteren van de output, en het handmatig corrigeren van de resultaten. Dan ben je verder van huis. De vuistregel: een solver is een goed idee als een wiskundige je het probleem zonder domeinkennis begrijpelijk kan beschrijven. Is de domeinkennis onlosmakelijk verbonden met de constraints, dan bouw je de logica zelf en gebruik je de solver hooguit voor een deelprobleem. Bij het bouwen van maatwerk planningssoftware zie je dit patroon in transport, maar ook in productieplanning bij maakbedrijven en in inkoopplanning bij groothandels: de wiskunde is generiek, de domeinregels zijn dat niet.
Wat kost maatwerk planningssoftware ten opzichte van een standaard pakket?
Eerlijk antwoord: maatwerk planningssoftware bouwen is op dag één duurder dan een licentie kopen. De initiële bouwkosten zijn reëel. Wat je terugkrijgt is een systeem dat jouw constraints precies uitdrukt, een datamodel dat meeschaalt, en eigenaarschap van code en data zonder lock-in. Een commercieel pakket heeft een lager instapbedrag, maar heeft configuratiekosten, trainingskosten, aanpassingskosten voor elke afwijking van de standaard, en een jaarlijkse licentie die stijgt naarmate je meer gebruikers of modules nodig hebt. De break-even ligt ergens, en die is afhankelijk van hoe sterk jouw operatie afwijkt van de standaard. Wijkt ze weinig af, koop dan een pakket. Wijkt ze structureel af op meerdere vlakken, dan is maatwerk op termijn goedkoper én beter. De vergissing die we zien is dat bedrijven een commercieel pakket kopen, er jarenlang omheen werken met Excel en handmatige correcties, en dan alsnog overstappen. Dan betaal je twee keer.