Fixed windows

d.d. 13-07-2022

In het kader van met elkaar en voor elkaar lees je in dit bericht over wat we samen kunnen doen om de prestaties rondom fixed windows op korte termijn te verbeteren. Het lezen kost je ca. 5 minuten, en is in onze ogen essentieel om samen nog betere resultaten te bereiken.

Zoals de meesten van jullie weten is er soms onvrede over de wijze waarop fixed windows worden ingepland. Er zijn planners die aangeven dat fixed windows onvoldoende in hun beoogde venster gepland worden. Uiteraard nemen we dat signaal als Nextlogic serieus, en beseffen we ook dat we niet altijd naar iedereen even duidelijk zijn over hoe we dit oppakken. In dit bericht lees je wat Nextlogic hieraan doet en minstens zo belangrijk: wat jij zelf als deelnemer eraan kan doen om de fixed windows beter te laten plannen.

Wat doet Nextlogic

Sinds mei 2022 verlagen we de penalty scores op fixed windows stap voor stap. Het doel hiervan is een betere balans te vinden in de planning, denk hierbij o.m. aan rust in de planning, het belang van restricties en reguliere calls ten opzichte van fixed windows. We zien en horen sindsdien vooral verbeteringen op alle gebieden, zoals verwacht en voorspeld vanuit de tests. De algehele kwaliteit van de planning is beter en de dynamiek is afgenomen.

Daarnaast heeft Nextlogic inmiddels enkele verbeteringen doorgevoerd die leiden tot beter inzicht rondom fixed windows, het eenvoudiger inboeken van de juiste terminal capaciteit en werken we aan de mogelijkheid om iteraties in de optimizer te prioriteren. En voor de TO’s heeft Nextlogic onlangs een optie ontwikkeld waarbij direct voor het hele jaar terugkerende fixed window capaciteit aangemaakt kan worden. Dat scheelt veel tijd voor de TO, de windows staan er vroeg in en het wordt bij gebruik ook snel duidelijk of bepaalde windows te kort zijn.

Verder gaat Nextlogic in augustus diverse rapportages genereren om de kwaliteit van data invoer inzichtelijk te maken. We blijven alert op de aanwezigheid van eventuele problemen in het algoritme, op dit moment is daar echter nog geen indicatie voor. Wanneer daarin verbeteringen mogelijk zijn zullen we dat uiteraard direct proberen door te voeren.

Wat kun je zelf doen

Als eerste en belangrijkste stap kun je er als deelnemer voor zorgen dat vraag en aanbod op de juiste manier worden ingevoerd; foutloos, zo vroeg mogelijk en realistisch planbaar. Hoewel we situaties tegenkomen die erop zouden kunnen wijzen dat de optimizer sneller of beter zou kunnen rekenen aan fixed windows, zien we dat het merendeel van de fixed window problemen te herleiden is tot de ingevoerde data door deelnemers. We helpen je graag aan de hand van onderstaande punten om deze problemen zoveel mogelijk te voorkomen.

Foutloze invoer van de fixed window-call door BO

Uiteraard mag een fixed window nooit de maximale aantal moves/containers overschrijden voor de betreffende call. Als dit wel gebeurt is er mogelijk geen ruimte om deze call juist af te handelen. Zorg er dus voor dat het aantal moves op de call de fixed window-afspraken niet overschrijdt.

Spaarzaam gebruik van restricties door BO

Met een restrictie in dezelfde rotatie als een fixed window loop je als BO grotere kans dat het window niet gepland wordt zoals afgesproken. Door de restrictie geef je eigenlijk aan dat er andere zaken nog belangrijker zijn. Met name restricties op calls vóór het fixed window kunnen tot ongewenste situaties leiden, zeker als de capaciteit op de terminal waar de restrictie op zit beperkt is. Wees dus zeer terughoudend in het toepassen van restricties. Zie hierover ook de aparte mail over het juiste gebruik van restricties in Jira: Restricties - Jira Service Management (atlassian.net).

Tijdig invoeren van fixed windows door BO en TO

Voor een betrouwbare planning kunnen de BO's hun fixed windows het beste ook minimaal 8 dagen van tevoren inplannen. Deze fixed windows worden dan als eerste ingepland en worden met een hogere mate van zekerheid op het juiste moment afgehandeld. Voor TO’s geldt hetzelfde, hoe eerder capaciteit vrijgegeven wordt hoe rustiger de planning.

Foutloze invoer van de capaciteit door TO

Aan de kant van de terminals zien we regelmatig dat capaciteit van te korte duur of te korte kadelengte wordt opgevoerd. Of dat deze na een wijziging niet meer voldoet. Onvermijdelijk plant de integrale planning deze barge dan op een later, ongewenst tijdstip. Een zorgvuldige invoer van kadecapaciteit zonder fouten is dan ook essentieel voor het behalen van een fixed window. Indien er meerdere fixed windows op hetzelfde moment zijn vrijgegeven dient daar uiteraard ook evenveel capaciteit tegenover te staan.

In het algemeen zien we dat TO's capaciteit regelmatig aanpassen (al dan niet met fouten), waardoor er op het juiste moment onvoldoende capaciteit beschikbaar is binnen Nextlogic om een planning te maken conform de verwachtingen. De oorzaak hiervoor ligt dan binnen de beperkingen van de beschikbaarheid van kadecapaciteit.

Realistisch uitvoerbare fixed window codes in MCA Barge door TO

Hier begint voor de terminals alles: de afgesproken fixed windows kennen een van-tot tijd en een aantal moves, en worden middels een fixed window-code door de terminals in MCA Barge opgevoerd. Nextlogic gebruikt die codes vervolgens via de interface met MCA Barge. We zien hierbij enkele zaken die tot planningsproblemen kunnen leiden:

1. De opgevoerde fixed windows in MCA Barge zijn vaak te kort voor het aantal moves: er worden onrealistische kraansnelheden verondersteld die in de praktijk zelden waargemaakt worden, maar vooral: die anders zijn dan waarmee binnen Nextlogic gepland wordt. Dan leidt dit in elk geval al tot afwijkingen in de planning.

2. Op bepaalde momenten worden meerdere fixed windows tegelijk verwacht op basis van de afspraken. Op sommige kades worden op eenzelfde tijdstip tot wel drie fixed window-codes vrijgegeven. Als de capaciteit dat niet aankan, zal tenminste één van de beoogde calls niet tijdig afgehandeld worden.

Benodigde actie: TO's evalueren fixed window-codes en vensters op structurele overlap en juistheid van moves t.o.v. vensters, kraansnelheden en pre- en posthandlings.