Page Comparison

Wanneer de schipper zich niet aan de opgegeven volgorde restrictie houdt, kan de volgorde niet meer kloppend worden gemaakt. Dit zorgt ervoor dat uw rotatie niet meer gepland en geoptimaliseerd wordt.

Het overmatig gebruik hiervan heeft grote nadelen voor de gebruikers van de integrale planning:

• De “planningspuzzel” die de optimizer moet oplossen wordt steeds lastigeris complex. Het plannen van calls met een restrictie is vele malen complexer doordat er voor deze call minder oplossingsmogelijkheden zijn. Hoe meer calls met weinig mogelijkheden, hoe moeilijker een oplossing voor alles te vinden is. Dit kost bovendien heel veel rekentijd die ten koste gaat van andere verbeteringen in de planningcomplexer de puzzel wordt.

• Het kan ervoor zorgen dat fixed windows niet juist gepland worden. Dit is bijvoorbeeld het geval wanneer er één fixed window op de plaats zou moeten komen van één of meerdere reguliere calls en die reguliere calls deel uitmaken van een rotatie met een restrictie.

• Leg ook experimenteren aan banden: Elke keer dat een restrictie wordt toegevoegd of aangepast moet de optimizer opnieuw hiermee aan het werk. Dit leidt tot extra dynamiek in de planning, zeker als een restrictie meerdere malen wordt aangepast of snel weer wordt verwijderd. De BO die experimenteert ondervindt hier mogelijk geen hinder aan, maar collega BO’s worden wel geconfronteerd met ‘last minute’ wijzigingen. Het gebruik van restricties is altijd als een risico beschouwd en daarom ook opgenomen in de spelregels die we met elkaar voor aanvang zijn overeengekomen.

Volgorde restricties dienen er met name voor om laden/lossen van containers binnen één rotatie mogelijk te maken en om eventuele stuwage problemen op te lossen. Dus wanneer de lading een bepaalde volgorde noodzakelijk maakt, gebruik dan een restrictie, maar alleen als het niet op te lossen is op andere manieren.

Hieronder volgt een toelichting aan de hand van een voorbeeld over de werking van de restricties in de Integrale Planning.

...

Controleer daarom altijd de opgegeven restricties en pas aan indien nodig.

Pas vooral geen restricties toe om de volgorde of geplande tijden te beïnvloeden: dit werkt echt averechts en beschouwen we gezamenlijk als oneigenlijk gebruik. Niet alleen voor je eigen rotaties, maar ook voor alle andere deelnemers (Bo’s & To’s) heeft dit bovendien negatieve gevolgen, zeker wanneer kadecapaciteit schaars is.

...

• Een restrictie wordt ingezet om (te proberen) een call eerder gepland te krijgen dan zonder restrictie

• Een restrictie wordt meerdere keren aangepast, soms wel meer dan 5 keer op 1 dag

• Een restrictie wordt ingezet om een call A voor call B ingepland te krijgen. Call B is een fixed window. De terminal van call A wijzigt beschikbaarheid, waardoor call A überhaupt niet meer ingepland kan worden tussen scope in en de fixed window tijd van call B. Hierdoor mis je de fixed window en ga je later de haven uit, zonder restrictie was dit niet gebeurt. Als dit wordt gemeld bij de BO is de restrictie plots niet meer nodig.

• De optimizer heeft alle calls goed ingepland en draait soepel. Op dat moment besluit een BO om een restrictie toe te voegen ‘om te kijken wat het met de planning doet’. Hierdoor verandert ook de planning van 15 andere rotaties (soms ‘last minute’) en zit de optimizer een tijd in hard violations. Na soms 2 uur rekenen is de planning weer stabiel en ziet de BO . Het doorrekenen kost nu eenmaal tijd. Als na 'x' tijd de BO constateert dat de uitkomst van de restrictie toch niet zoals gewenst is, dus haalt de BO deze er weer af met als gevolg dat de optimizer opnieuw aan het werk moetdit een verandering met zich meebrengt. Ook de omliggende rotaties worden vervolgens opnieuw gepland met mogelijk weer ‘last minute’ wijzigingen tot gevolg.

• Als de optimizer meer moeite moet doen om puzzels op te lossen, kost het ook meer tijd Des te onnodig complex, des te langer het duurt om de planning te optimaliseren. Uiteindelijk betekent dit dat de optimizer met een minder optimale planning komt dan wat er mogelijk zou zijn zonder (veel) volgorde restricties.

• Als beschikbaarheden wijzigen kan het zomaar zijn dat die volgorde restrictie die je voorheen een voordeel bezorgde je nu juist een nadeel geeft.

• Het wijzigen of toevoegen van restricties kort van tevoren zal altijd leiden tot last minute verschuivingen, niet alleen voor je eigen barge maar vooral ook voor anderen.

• Juiste reden: Een volgorde restrictie gebruik je alleen als deze strikt noodzakelijk is vanuit het oogpunt van stuwage of stabiliteit van het schip. Elke restrictie die verwijderd kan worden als deze een ongewenste planning geeft is niet noodzakelijk en onjuist gebruik.

• Juiste manier: Zet de restrictie er direct in bij het aanmaken van de rotatie en wijzig deze daarna niet meer.

...

Zowel Nextlogic als BO’s en TO’s rekenen op jouw medewerking om het oneigenlijk gebruik van restricties tegen te gaan. Daarmee wordt de integrale planning nog beter én stabieler. Vanuit Nextlogic zullen we de data in de komende twee weken extra intensief monitoren of dat inderdaad het geval is. Als er

Als we geen verbetering in gedrag te zien is of als deze te beperkt is zullen we ons genoodzaakt zien zien zijn we genoodzaakt om aanvullende maatregelen te nemen. We rekenen erop dat dit niet nodig is, maar denken hierbij onder meer aan de volgende opties, die we dan nader zullen invullen:

• De tijd dat restricties toegevoegd kunnen worden aanpassen.

• Transparant maken van inzet van restricties per BO. Iedereen kan dan zien hoe vaak elke BO restricties inzet, hier zitten nu al grote verschillen in.

• Score op restricties aanpassen. Door een aanpassing in bestaande puntenscores kunnen we ervoor zorgen dat rotaties met restricties minder snel een score opbouwen en daardoor minder aandacht krijgen van de optimizer.

• Slack-opslag voor rotaties met restricties sterk verhogen: door inzet van restricties mag de optimizer dan ruimer plannen en zal dat schip langer in de haven zijn.

• Elke keer dat een restrictie wordt toegevoegd of gewijzigd neemt de score toe

...

• restricties

...

• .