Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

d.d. 1213-07-2022

In het kader van met elkaar en voor elkaar lees je in dit bericht lees je over wat we met elkaar samen kunnen doen om de prestaties rondom fixed windows op korte termijn te verbeteren. Het lezen van dit bericht kost je ca. 10 5 minuten, maar en is in onze ogen essentieel om samen nog betere resultaten te bereiken.
Er is
Zoals de meesten van jullie weten is er soms onvrede over de wijze waarop fixed windows worden ingepland, zo bleek ook vorige week woensdag weer tijdens het BO/TO overleg. Het algemene beeld onder planners is . Er zijn planners die aangeven dat fixed windows onvoldoende in hun beoogde venster gepland worden. Uiteraard nemen we dat signaal als Nextlogic serieus, maar zijn we mogelijk en beseffen we ook dat we niet altijd naar iedereen even duidelijk zijn over hoe we dat doen. In deze mail een toelichting op het probleem, wat Nextlogic op dit moment dit oppakken. In dit bericht lees je wat Nextlogic hieraan doet en minstens zo belangrijk: wat iedere deelnemer er zelf aan 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.
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 leeuwendeel van de fixed window problemen te herleiden is tot de ingevoerde data door deelnemers. Als eerste en snelste stap dienen we er met elkaar zeker van te zijn dat vraag en aanbod op de juiste manier worden ingevoerd; foutloos, zo vroeg mogelijk en realistisch planbaar.
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.
Hieronder volgt een korte toelichting, inclusief wat je er zelf aan kan/moet doen

Realistisch uitvoerbare fixed windows codes in MCA Barge (door TO’s)

Hier begint 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 FW 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 NXL 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 FW-codes en vensters op structurele overlap en juistheid van moves t.o.v. vensters, kraansnelheden en pre- en posthandlingsEn 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 FW 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 juist 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 zal plant de integrale planning deze barge dan op een later, ongewenst tijdstip plannen. 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.

Tijdig invoeren van fixed windows door BO en capaciteit bij de TO

...

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.