d.d. 12-07-2022
In dit bericht lees je wat we met elkaar kunnen doen om de prestaties rondom fixed windows op korte termijn te verbeteren. Het lezen van dit bericht kost je ca. 10 minuten, maar is essentieel om samen nog betere resultaten te bereiken.
Er is 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 dat fixed windows onvoldoende in hun beoogde venster gepland worden. Uiteraard nemen we dat signaal serieus, maar zijn we mogelijk niet altijd even duidelijk over hoe we dat doen. In deze mail een toelichting op het probleem, wat Nextlogic op dit moment doet en minstens zo belangrijk: wat iedere deelnemer er zelf aan kan doen om de fixed windows beter te laten plannen.
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:
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.
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 posthandlings.
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
Met een restrictie in dezelfde rotatie als een fixed window loop je als BO grotere kans dat het FW 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 gebruik van restricties in Jira: Restricties - Jira Service Management (atlassian.net).
Foutloze invoer van de capaciteit bij de terminal
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 wijziging niet meer voldoet. Onvermijdelijk zal 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
Het is essentieel dat TO's ruim van tevoren (min. twee weken) de capaciteit voor vaste fixed windows alvast inplannen. Voor een betrouwbare planning van fixed windows kunnen de BO's hun windows het beste ook minimaal 8 dagen van tevoren inplannen. Deze fixed windows worden dan als eerste ingepland en zullen met een hogere mate van zekerheid op het juiste moment worden afgehandeld.
Voor de TO’s heeft Nextlogic 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 fixed windows te kort zijn.
In augustus gaat Nextlogic 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 nog geen indicatie voor, maar we sluiten dit zeker niet op voorhand uit. Wanneer daarin verbeteringen mogelijk zijn zullen we dat direct proberen door te voeren.