Bonsai
PoV Dynamisch Plannen · pull-concept

Dynamisch Plannen: waar we staan

Wie wij zijn, wat Dynamisch Plannen doet, wat we tot nu toe deden en wat er nog komt.

Werkgroep Dynamisch Plannen · september 2026 Bonsai Software B.V.
Agenda

Waar we het over hebben

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

IngechecktETAHandelingenModuleHistorie
1Jan09:50 · haalt het2 (combi)rustiggoed
2Fatima09:55 · haalt het1rustiggoed
Piet10:20 · te laat1druk

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

RichtingWaarom niet
DP neemt de hele planning overVeel bouwwerk; raakt ook wie niet meedoet
Vast deel van de capaciteit voor DPZelfde bouwwerk als volledige overname, te weinig kansen om te pullen
Voormeldingen parkeren bij PortbaseVertraagt niet-deelnemers en geen garantie op plek
Placeholder-voormeldingBotst met de Vertrouwensketen
Annulering even vasthouden bij PortbaseDekt alleen de vervoerder-triggers, geen garantie op plek
Apart DP-tijdslot met lange grace periodComplexe 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 overNette 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

PartijBouwtStand 17 september
Port AlertCheck-in en ETA naar DP · aanbod in de app · planner-voorstel en historie in MCA Road · capaciteitsscherm in TruckFlowBouwplan en interface-specificatie gereed; ontwerp van de schermen looptver uitgewerkt
PortbaseDeelnemersvlag en datafilter · DP-kenmerk op de voormelding · machtiging om namens deelnemers te boekenBouwplan bij duidelijkheid richtingkern staat
TerminalsKenmerk herkennen en alleen daarvoor de capaciteitscheck overslaanAPMT toetst bij Kaleris (TOS-leverancier)toets loopt
BonsaiKandidatenpool, ranking, quotumbewaking, verificatie en metingKern en simulatie staan; ontwerp wordt afgerond na de terminalkeuzekern 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.
Navigeer met ← → of spatie
Voice-over · toets N