Leermoment 1: waterstanden en sluisdata zijn zelden machine-leesbaar
De eerste reflex bij het automatiseren van charterplanning in de binnenvaart is: koppel de reistijden aan actuele waterstanden en sluisgegevens. Logisch. Alleen is die data in de praktijk zelden in een formaat dat een planningsalgoritme direct kan gebruiken. Rijkswaterstaat publiceert waterstanden via meerdere kanalen, maar de formaten, meetpunten en tijdstempels verschilt per waterweg. Sluisplanningen komen soms als PDF, soms als e-mail, soms via een portaal met een eigen exportstructuur. Voordat je een berekening kunt maken, moet je normaliseren: één datamodel, één tijdzone, één eenheid. Dat is geen glamoureuze klus, maar het is de helft van het werk. Wie die stap overslaat, bouwt een systeem dat mooie routes berekent op basis van verouderde of onjuiste invoer. In de binnenvaart, waar een paar centimeter waterdiepte het verschil maakt tussen vol laden en deels laden, is dat geen theoretisch risico.
Leermoment 2: de zachte planningsregels staan nergens opgeschreven
Charterplanners werken met regels die niet in een systeem staan. Vaste klant A wil altijd schipper B op zijn lading, omdat die de ligplaats kent en de klant hem vertrouwt. Klant C heeft een mondeling afgesproken vertrekvenster dat formeel nergens is vastgelegd. Bepaalde ladingsoorten gaan altijd met een specifiek vaartuig, niet omdat het technisch moet maar omdat het ooit zo gegroeid is. Dit soort zachte regels bepaalt een groot deel van de daadwerkelijke planning. Een algoritme dat er geen weet van heeft, genereert een planning die op papier optimaal is maar in de praktijk direct wordt overschreven door de planner. De oplossing is niet technisch: je moet die regels eerst expliciet maken. Dat betekent gesprekken voeren, schaduwdraaien naast de planner, en elke uitzondering documenteren. Pas als die regels in het systeem zitten als configureerbare parameters, heeft automatisering grip op de werkelijkheid. Dit kost tijd voor de bouw, maar het is de investering die het verschil maakt tussen een systeem dat gebruikt wordt en een systeem dat naast de spreadsheet blijft staan.
Leermoment 3: een systeem zonder escalatieroute verliest draagvlak
Planners in de binnenvaart werken met onzekerheid. Een schip vertrekt te laat, een sluis staat langer stil dan gepland, een klant belt met een spoedwijziging. Een geautomatiseerd planningssysteem dat daar geen raad mee weet en gewoon doorrekent, neemt verkeerde beslissingen. Erger: planners verliezen het vertrouwen in het systeem en beginnen het te omzeilen. Wat werkt is een duidelijke escalatiestructuur: het systeem signaleert de uitzondering, legt de relevante informatie klaar, en legt de beslissing bij de mens. Niet elke afwijking hoeft handmatig, maar de planner moet weten welke beslissingen het systeem zelf neemt en welke hij geaccordeerd krijgt. Die grens moet vooraf worden afgesproken en in het systeem worden ingebakken. Human in the loop is hier geen mooie term, het is de voorwaarde voor adoptie. Zodra planners ervaren dat ze controle houden over de uitzonderingen, groeit het vertrouwen in de geautomatiseerde basisbeslissingen.
Wanneer past automatisering van charterplanning wel, en wanneer niet?
Automatisering van charterplanning in de binnenvaart past goed als je een herhaalbaar patroon hebt: vaste routes, vaste klanten, meerdere vaartuigen die je wekelijks moet verdelen over de vraag. Hoe meer structuur er in de vraagkant zit, hoe meer een systeem kan overnemen. Het past minder goed als elke charter een eenmalige puzzel is met steeds andere variabelen, klanten en vaartuigen. Dan is de overhead van het bijhouden van de configuratie groter dan de tijdwinst. Een eerlijke vraag om vooraf te stellen: hoeveel procent van je huidige planningen heeft dezelfde basisstructuur? Als dat antwoord boven de helft ligt, is automatisering de moeite waard om serieus te verkennen. Als dat antwoord laag is, begin dan met het gestructureerder vastleggen van je planningsdata. Dat is de voorbereiding die automatisering later mogelijk maakt, ook als je er nu nog niet aan toe bent. Bij Bonsai bouwen we dit soort planningssystemen als maatwerk, ofwel als onderdeel van een nieuw kernsysteem via de Bonsai AI Digital Twin, ofwel als een AI Worker die op een bestaand systeem draait.