KPI vóór en na
Zeevaart op tijd
—
Vertraagde reizen
—
Totale delayuren
—
Gem. delay per vertraagde reis
—
De brief vraagt om drie assen: minder wachttijd, betere voorspelbaarheid en slimmer gebruik van capaciteit. Op deze pagina vertaalt dat zich naar drie definities van "beter", en de slimste knop verandert mee.
Een interventie die twintig kleine vertragingen voorkomt levert veel meer op voor 95% op tijd dan één van tien uur. Voor delayuren is het precies andersom.
Voorkomen haalt een aandeel van de incidenten wég: de interventie zorgde dat ze niet gebeurden. Dat raakt vooral het aantal vertraagde reizen, en dus het percentage op tijd.
Verkorten maakt elk incident van die oorzaak korter. Dat raakt vooral de minuten; het aantal daalt alleen waar een incident onder de KPI-grens zakt.
Bij "voorkomen" worden de weggehaalde incidenten gelijkmatig over de verdeling gekozen, niet de langste of de kortste. Anders zou elke interventie er briljant uitzien op de as die je toevallig bekijkt.
De haven registreert vertraging vanaf 30 minuten (KPI Delay werkinstructie). Dat is de norm en die verandert hier niet.
Deze knop herleest de al geregistreerde vertragingen alsof de grens hoger lag: een business-rule-experiment, geen modelwijziging. Daarom kan hij ook niet onder 30 — daar heeft de haven niets geregistreerd, dus is er niets te lezen.
"Op tijd" is niet aan ons om te definiëren. Deze knop verandert de aflezing, niet de meting.
Eén schuif per oorzaak die in deze run daadwerkelijk vertraging registreerde, op volgorde van delayuren. Dit is een what-if op de registratie, geen mechanisme: hij zegt wat een oorzaak wáárd is, niet hoe je hem oplost.
Daarom staat onder elke schuif de gemeten knop die er wél op werkt, met zijn eigenaar. Zo blijft "stel dat we 25% voorkomen" zichtbaar iets anders dan "zet er een sleepboot bij".
Hydro-meteo, sluisstoring en stremming hebben geen schuif met een mechanisme: die zijn exogeen. Een scenario kan ze injecteren, geen enkele knop voorkomt ze.
De ranglijst rechts rekent élke oorzaak door op hetzelfde percentage, los van de schuiven links. Anders vergelijk je oorzaken die verschillend hard zijn aangezet.
"Vóór" is de nulmeting van dezelfde run: dezelfde seed, dezelfde horizon, dezelfde knoppen op de simulator. Met alle schuiven op nul en de grens op 30 zijn beide kolommen per definitie gelijk.
De vier cijfers zijn die van de haven zelf: percentage op tijd, aantal vertraagde reizen, totale delayuren en gemiddelde delay per vertraagde reis.
Delayuren per geregistreerde oorzaak, vóór en na. De taxonomie is die van de werkinstructie: acht hoofdoorzaken, met de NDV-subcategorieën apart zoals de monitor ze rapporteert.
Eén rij per oorzaak. De rij leest als: stel dat we van déze oorzaak 25% van de vertraging wegnemen en verder niets veranderen — wat gebeurt er dan met de drie doelen?
De drie Δ-kolommen zijn het verschil met de nulmeting: procentpunten op tijd, uren vertraging en minuten spreiding. De lijst sorteert op het doel dat je links kiest; de andere twee kolommen laten zien wat diezelfde oorzaak daar doet.
Dit is een eerste-orde-berekening: de vertraging wordt uit de registratie gehaald, de keten wordt niet opnieuw doorgerekend. De gemeten Δ van de bijbehorende knob komt wél uit een volledige simulatie over 60 dagen op drie gepaarde seeds.