Wie wij zijn, wat Dynamisch Plannen doet, wat we tot nu toe deden en wat er nog komt.
Werkgroep Dynamisch Plannen · september 2026Bonsai Software B.V.
Agenda
Waar we het over hebben
1Wie wij zijn
2Wat is Dynamisch Plannen
3Wat we tot nu toe hebben gedaan
4Wat we nog gaan doen, en met wie
5Hoe de tijdlijn er verder uitziet
1Wie wij zijn
Bonsai: de partij in het midden
flowchart LR
HBR["HbR opdrachtgever"] --- B(("Bonsai Dynamisch Plannen"))
PB["Portbase MCA Road"] --- B
PA["Port Alert app en schermen"] --- B
B --- APM["APM Terminals MVII"]
B --- RWG["RWG"]
B --- TLN["TLN en vervoerders"]
style B fill:#1D4ED8,stroke:#1D4ED8,color:#fff
Onafhankelijk
Geen eigen belang
Geen terminal, geen hub, geen app. Wij zijn van niemand en werken voor het geheel.
Vertaler
Alle wensen in één ontwerp
Wat elke partij wil hebben we opgehaald en zo goed mogelijk verwerkt in één werkende opzet.
Bouwer
De DP-kern, plus bouwplannen
Wij bouwen het Dynamisch Plannen-systeem en schrijven uit wat Port Alert, Portbase en de terminals daarvoor nodig hebben.
2Wat is Dynamisch Plannen
Het probleem wat we willen oplossen
Knelpunt
Veel no-shows
Geboekte tijdsloten blijven leeg. Die capaciteit is weg.
Knelpunt
Volle piekuren
Overdag vol, elders op de dag ruimte.
Knelpunt
Drukte op enkele modules
Slechte spreiding over de yard: wachtrijen bij één stack, rust bij de rest.
Knelpunt
Groeiende volumes
De doorstroom op de Maasvlakte komt verder onder druk.
Vandaag: komt een plek vrij, dan gaat die terug de markt in. De snelste herboeking wint, of de plek blijft leeg.
2Wat is Dynamisch Plannen
Het doel: de plek gaat naar de beste kandidaat
flowchart TB
subgraph NU["Vandaag"]
direction LR
A1["Plek komt vrij"] --> A2["Terug de markt in"] --> A3["Snelste herboeking wint, of plek blijft leeg"]
end
subgraph DP["Met Dynamisch Plannen"]
direction LR
B1["Plek komt vrij"] --> B2["DP kiest de beste ingecheckte chauffeur"] --> B3["Chauffeur accepteert in de app"] --> B4["Boeking landt gegarandeerd op dat tijdslot"]
end
NU ~~~ DP
style B4 fill:#1D4ED8,stroke:#1D4ED8,color:#fff
Een chauffeur die al is ingecheckt in de Port Alert-app en het qua tijd haalt, wordt naar voren gehaald.
2Wat is Dynamisch Plannen
De partijen en hun rol
Chauffeur
Port Alert-app
Checkt in met zijn TAR. Krijgt het aanbod en beslist zelf.
Port Alert
Locatie en communicatie
Berekent de aankomsttijd en beheert de communicatie met de chauffeurs en planners.
Dynamisch Plannen
Kiest en bewaakt
Kiest de beste kandidaat, doet het aanbod via PA, bewaakt het maximum van de terminal.
Portbase
MCA Road
Beheert boekingen en zet het DP-kenmerk op de voormelding.
Terminal
TOS en capaciteitsbeheer
Geeft per tijdslot de ruimte voor DP op. TOS herkent het kenmerk.
2Wat is Dynamisch Plannen
Vijf momenten waarop ruimte ontstaat
1
Planner
Vervoerder annuleert
Een geboekte plek wordt opgegeven.
2
Terminal
Terminal annuleert
Boeking niet groen vóór slotstart.
3
Chauffeur
Tijdslot niet haalbaar
ETA te laat; planner geeft de plek vrij.
4
Terminal
Extra capaciteit
Terminal geeft ruimte vrij op een tijdslot.
5
Planner
Verplaatsing
Het oude tijdslot blijft leeg achter.
Bij elk van deze vijf zoekt DP direct een ingecheckte chauffeur die de plek kan vullen.
2Wat is Dynamisch Plannen
Wat de chauffeur ziet: een voorbeeld
Port Alert09:41
Eerder tijdslot beschikbaar
APM Terminals MVII · zelfde TAR
10:00 – 10:30
11:00 – 11:30
Accepteren
Weigeren
Aanbod verloopt over 4:32
09:12
Check-in
Jan checkt in voor zijn slot van 11:00. Port Alert: ETA 09:50.
09:41
Plek vrij
Een vervoerder annuleert op 10:00. Jan is de beste kandidaat.
09:41
Aanbod
Melding met aflooptijd. Jan accepteert.
09:42
Bevestigd
DP boekt 10:00 namens de vervoerder. Zelfde TAR, zelfde gate.
Chauffeur beslist
Accepteren, weigeren of laten verlopen. Weigeren verandert niets.
Alleen naar voren
Nooit later dan zijn huidige tijdslot. Eén aanbod tegelijk.
2Wat is Dynamisch Plannen
Hoe DP de beste kandidaat kiest
Ingecheckt
ETA
Handelingen
Module
Historie
1
Jan
09:50 · haalt het
2 (combi)
rustig
goed
2
Fatima
09:55 · haalt het
1
rustig
goed
–
Piet
10:20 · te laat
1
druk
–
Voorbeeld voor een plek om 10:00. Alleen wie het haalt telt mee.
Weegt mee
Nabijheid
De ETA uit Port Alert: haalt hij het, en met hoeveel marge.
Weegt mee
Handelingen
Combiritten en het aantal containers per bezoek.
Weegt mee
Drukte per module
Een stack die vastloopt weegt negatief, of is een harde stop.
Weegt mee
Gedrag vervoerder
Op tijd komen en weinig no-shows telt mee. Opgebouwd in de schaduwperiode.
3Wat we tot nu toe deden
De zomer in één lijn
Juli
Wensen opgehaald
Kickoff en kennismaking met RWG, APMT, Portbase, Port Alert en TLN.
Begin augustus
Richtingen getoetst
Toets met Alexander Verbraeck (TU Delft); werksessie RWG met zes richtingen.
Eind augustus
Werkhypothese
Dubbele tijdsloten uitgewerkt en gedeeld met de terminals.
September
Drie sessies APMT
3, 9 en 16 september. Conclusie: de zekerheid moet uit het terminalsysteem komen.
Nu
Plannen concretiseren
Voorgestelde richting DP-kenmerk wordt getoetst bij de terminals. Bouwplan Port Alert grotendeels rond.
Elke stap met dezelfde vraag: hoe zorgen we dat de DP-boeking altijd landt, zonder dat iemand die niet meedoet er iets van merkt.
3Wat we tot nu toe deden
Acht richtingen bekeken, één blijft over
Richting
Waarom niet
DP neemt de hele planning over
Veel bouwwerk; raakt ook wie niet meedoet
Vast deel van de capaciteit voor DP
Zelfde bouwwerk als volledige overname, te weinig kansen om te pullen
Voormeldingen parkeren bij Portbase
Vertraagt niet-deelnemers en geen garantie op plek
Placeholder-voormelding
Botst met de Vertrouwensketen
Annulering even vasthouden bij Portbase
Dekt alleen de vervoerder-triggers, geen garantie op plek
Apart DP-tijdslot met lange grace period
Complexe mapping nodig, chauffeurs kunnen altijd naar binnen
Dubbele tijdsloten (tweede regelset)
Mogelijk alleen configuratie, ongewenste gevolgen voor terminals intern
DP-kenmerk: terminalsysteem slaat alleen de capaciteitscheck over
Nette oplossing, wel bouwwerk in TOS
3Wat we tot nu toe deden
Voorgestelde richting: het DP-kenmerk
flowchart LR
DP["DP kiest kandidaat, chauffeur accepteert"] --> PB["Portbase zet het DP-kenmerk op de voormelding"] --> TOS{"Terminalsysteem: capaciteitscheck"}
TOS -->|"met DP-kenmerk"| OK["Check overgeslagen. Boeking landt op het bestaande tijdslot"]
TOS -->|"zonder kenmerk"| N["Normale check: vol is vol"]
Q["Terminal: DP-quotum per tijdslot"] -. "bewaakt door DP" .-> DP
style OK fill:#1D4ED8,stroke:#1D4ED8,color:#fff
Eén regel in het bericht
Alleen Portbase kan het kenmerk zetten. Een vervoerder kan zichzelf niet vlaggen.
Terminal houdt de knop
Het maximum per tijdslot is altijd bij te sturen door de terminal.
Verder verandert niets
Zelfde tijdsloten, zelfde gate, zelfde TAR. Niet-deelnemers merken niets.
3Wat we tot nu toe deden
Drie scenario's
A · waar we op inzetten
DP-kenmerk via het terminalsysteem
Alle vijf de triggers; de boeking landt gegarandeerd.
Generiek voor beide terminals, opstap naar het eindbeeld.
Vraagt een wijziging bij Kaleris en de IT-route van de terminals: doorlooptijd.
voorwaarde: Kaleris kan aanpassing doen
B · terugval
Alleen triggers vanuit vervoerders
Geen wijziging bij de terminals; snel te starten.
Terminal-annulering en extra capaciteit vallen weg.
Moeten nog steeds garantie kunnen geven dat DP-boeking landt.
als het bij de terminals vastloopt
C · terugval
Pilot met één vervoerder
Klein en beheersbaar; weinig impact op de keten.
Bewijst het principe, maar met weinig volume.
Mogelijk te weinig data om effect aan te tonen.
als A én B niet haalbaar zijn
A is waar we op inzetten. B en C liggen klaar, zodat we niet stilvallen als het bij de terminals langer duurt.
3Wat we tot nu toe deden
Wie bouwt wat, en hoe ver het is
Partij
Bouwt
Stand 17 september
Port Alert
Check-in en ETA naar DP · aanbod in de app · planner-voorstel en historie in MCA Road · capaciteitsscherm in TruckFlow
Bouwplan en interface-specificatie gereed; ontwerp van de schermen loopt
ver uitgewerkt
Portbase
Deelnemersvlag en datafilter · DP-kenmerk op de voormelding · machtiging om namens deelnemers te boeken
Bouwplan bij duidelijkheid richting
kern staat
Terminals
Kenmerk herkennen en alleen daarvoor de capaciteitscheck overslaan
APMT toetst bij Kaleris (TOS-leverancier)
toets loopt
Bonsai
Kandidatenpool, ranking, quotumbewaking, verificatie en meting
Kern en simulatie staan; ontwerp wordt afgerond na de terminalkeuze
kern staat
4Wat we nog gaan doen
Vier stappen, en met wie
1
Nu
Plan Port Alert afronden
Laatste afstemming op de interface-specificatie; Port Alert start met check-in en aanbod.
met Port Alert-team
2
Week van 21/9
Terminals: kan het, en wanneer
Kaleris toetst of het terminalsysteem het kenmerk kan verwerken. Ook: besluit over de vorm van de capaciteitsopgave.
met APMT, RWG, Kaleris
3
Daarna
Portbase-werk scherp zetten
Zodra de terminalkant vaststaat is ook duidelijk wat Portbase precies bouwt. Tickets uitzetten.
met Portbase
4
Daarna
Bouwen
Port Alert, Portbase, terminals en Bonsai bouwen parallel; eerst in de testomgeving.
met alle partijen
Stap 2 bepaalt het tempo van stap 3 en 4.
5Tijdlijn
Hoe de tijdlijn er verder uitziet
Nu
Richting voorgesteld
Bouwplannen Port Alert en Portbase liggen er.
Week van 21 sep
Antwoord terminals
Kaleris: kan het, hoe lang, wat kost het. Besluit capaciteitsopgave.
Daarna
Ontwerp afronden
Functioneel en technisch ontwerp, schermen, meetopzet met HbR Analytics.
Bouw
Port Alert · Portbase · terminals
Terminalkant: indicatie minimaal een kleine maand plus interne IT-route.
Schaduwperiode
Meten, nog niet sturen
Nulmeting en gedrag vervoerders opbouwen, 4 tot 6 weken.
Pilot
Live op twee terminals
12 weken, daarna evaluatie.
Startdatum pilot: volgt na het antwoord van de terminals.