Martijn Meerman: Good morning, listeners and viewers of Studio Ab Ovo. Today we’re talking to Ard Jan Cieremans, business consultant at Ab Ovo, working at NextLogic. Welcome, Ard Jan.
Ard Jan Cieremans: Thank you. Welcome to Ab Ovo as well.
Martijn: What do you do at NextLogic?
Ard Jan: NextLogic is a service for planning inland container vessels across the different terminals in Rotterdam.
What we do is bring together demand and supply. Demand comes from the inland barges arriving in Rotterdam to deliver or collect containers, while supply is the capacity available at the terminals.
The terminals tell us which cranes they have available, at which quays and locations. Barge operators tell us which container terminals they want to visit in Rotterdam.
From the hinterland, you basically have a choice between transporting containers by truck, train or barge. If there is enough time to transport the containers to Rotterdam by barge, they are put on a barge. If there is more urgency, they may go by truck or train, or through a combination of different modes.
Martijn: What determines that choice? Is it mainly time? A barge can carry many more containers than a truck.
Ard Jan: Time is important because when you rent a container to transport goods, you only have that container available within a certain time window.
At a specific time, you have to collect the container from the port or an inland terminal, and you have to deliver it to the terminal in time for the deep-sea vessel that will transport it around the world.
If you collect your container too early, you have to pay because you are using it for longer. If you deliver a loaded container to the terminal too early, you occupy space at the container terminal, so you also have to pay for that.
You therefore need to be on time. Otherwise, you can face demurrage and detention charges.
I also wrote a report about this together with Erasmus University, looking at the impact of demurrage and detention on container logistics.
Martijn: That must be difficult because the container itself may be predictable, but when you’re travelling by sea or along rivers, all kinds of circumstances can interrupt the journey.
Ard Jan: Exactly. If there is a crisis in the Suez Canal, for example, or ships have to sail around Africa, the entire rhythm of the planning changes.
Shippers in the hinterland also have their own rhythm for transporting containers to Rotterdam and back so that they can continue their journey around the world.
If something goes wrong within that dynamic, congestion can develop at the deep-sea terminals. That can disrupt the entire planning process.
Martijn: So you have traffic from the deep-sea terminals towards the hinterland and from the hinterland towards the deep-sea terminals. Does NextLogic take care of both sides of that planning?
Ard Jan: Yes. Imagine that I’m a barge operator planning inland vessels travelling to and from Rotterdam.
I check how many containers I need to collect or deliver at different terminals. I tell NextLogic: I want to visit this terminal and collect 40 containers there, collect another 40 somewhere else, and deliver 40 containers to two other terminals. Or it could be 200 containers.
We then plan those calls.
The deep-sea terminal tells us at which bollard position it has a crane available and what the crane’s handling speed is. Based on that information, we plan the calls.
This morning, I checked the system and saw around 300 rotations in the planning. A rotation is the combination of calls that forms a route through Rotterdam. Altogether, we had approximately 950 calls in the planning.
Martijn: How many containers do you handle in a year?
Ard Jan: Around four million.
Martijn: It’s almost impossible to imagine the volume of goods that represents.
Ard Jan: And it includes all kinds of goods. It can be small plastic pellets, cars, paper, wine and sometimes even gold. Almost everything can be transported in containers.
Martijn: You often see cars transported by rail on specialised wagons, but they are also transported in containers?
Ard Jan: Yes. Tesla, for example, transported cars in containers. Several Teslas could be stacked inside a container.
In the beginning, Tesla did not have enough volume to justify using large specialised deep-sea vessels, so they transported the cars in containers instead.
Martijn: Because the volume was too low to fill an entire specialised ship, containers allowed them to combine the cars with other cargo.
Ard Jan: Exactly.
Wine is another example. Wine can be transported in a large bag placed inside a container, which is then filled with wine.
And, of course, there are refrigerated containers. Aviko in the Netherlands, for example, uses refrigerated containers to transport potato products to places such as Saudi Arabia.
Martijn: Does the type of cargo inside the containers also have to be taken into account when planning them?
Ard Jan: Yes.
Martijn: How does the planning system work? It’s digitised today, but when did the process of digitising this planning begin?
Ard Jan: The main issue when we started was the need to match demand and supply.
Before NextLogic, much of this was done manually. An inland terminal planning a barge would call the different terminals in Rotterdam and arrange appointments. They might agree to visit one terminal on Saturday, another on Sunday and another on Friday.
They created a plan beforehand.
Once you start executing that plan, however, you depend on whether the containers are actually available and on the situation in Rotterdam.
On a quiet day without congestion, a barge might be able to complete its entire rotation as planned. But when there are delays at a terminal, those delays create a domino effect throughout the Port of Rotterdam.
A delay affects everyone.
In the past, everybody would start calling each other to solve the problem. The skipper on board the inland barge might also try to rearrange the planning. This was happening 24 hours a day, seven days a week.
Martijn: So many different groups and individuals were calling one another to reorganise everything.
That must also have made it difficult to stay within the time windows. The more people involved in the process, the more opportunities there are for mistakes.
Ard Jan: There are many stakeholders.
The company supplying the container gives you a specific window during which you can collect and return it.
Then you have the shipper who wants the goods transported and has a deadline. Often there is also a freight forwarder with a deadline. The barge operator planning the vessel has a deadline as well.
And then there are the deep-sea terminals.
Those terminals also have to deal with the very large deep-sea vessels. One of those ships might unload around 7,000 containers at once. Sometimes a vessel remains at the terminal for 36 hours while it is being unloaded and loaded.
Deep-sea vessels operate on rotations around the world, and those schedules have to be maintained.
Martijn: Weather and other circumstances can obviously affect those schedules as well.
Ard Jan: Exactly. That’s why deep-sea vessels normally have priority at the terminals.
The deep-sea terminals have contracts with the deep-sea vessel operators. They have a contractual obligation to unload and load a ship within a particular period because that vessel has to leave the port on time.
It may need to reach Hamburg on schedule or continue back towards Asia.
If a deep-sea vessel falls behind schedule, the financial consequences can be enormous because it may eventually arrive late in places such as Shanghai.
Martijn: When you’re comparing 7,000 containers on a deep-sea ship with perhaps 200 containers on a barge, the scale is completely different.
Looking at efficiency, can you quantify how much more efficient the process has become because of the software? Is the benefit mainly time or money?
Ard Jan: One of the main difficulties was that there wasn’t really a benchmark.
In the beginning, everybody was making their own appointments. To establish the first benchmark for the planning, we actually had to create it manually.
We had data showing how long inland barges stayed in the Port of Rotterdam. We knew when they entered Rotterdam, when they left and which terminals they visited.
We used that data to estimate the existing performance and create our first benchmark.
Then we made the first planning models matching demand and supply. We could immediately see that an algorithm could find and combine demand and supply far more effectively.
Martijn: So you really started from scratch. There wasn’t already a large part of the process digitised.
You essentially looked at individual vessels, followed the rotations they were making and used that as the starting point.
Ard Jan: Yes. We were also planning for the Second Maasvlakte while it was still being developed.
At that point, you didn’t really know what the future balance would look like. You didn’t know exactly where barges would sail, how many calls they would make at the existing terminals and how many they would make at the new terminals on the Maasvlakte.
The new cranes and terminals also had to start operating.
Martijn: You have described many different roles and people working on individual parts of the port operation. Was it difficult to bring everybody together and persuade them to share their knowledge and data so that you could create one planning solution?
Ard Jan: When you start automating planning, creating the automatic planning system itself is obviously important.
But I think about 80 percent of a project like this is change management.
If you’re used to calling a terminal and arranging things personally, that is a major change.
Terminal planners and barge operators were used to calling each other informally. They could discuss situations directly and make arrangements. Suddenly, someone comes along and says: we now have an algorithm that calculates the planning.
That’s a significant change.
Martijn: It removes some of that informal and personal interaction. You can no longer simply phone someone and ask whether they can help you out on this occasion.
Ard Jan: That’s true.
On the one hand, the old system involved a lot of phone calls and a great deal of stress. Everybody was talking to everybody else, trying to match supply and demand. It wasn’t very efficient.
On the other hand, people can feel that they have more opportunity to intervene in the planning when they can phone somebody directly.
Now, the planning is generated by an algorithm.
Sometimes the algorithm appears to do strange things. But those decisions can often be explained by last-minute changes. A deep-sea vessel may have containers that suddenly aren’t available, for example, or a terminal may be delayed.
The planning then has to change.
The algorithm can make around 26,000 calculations in a single day. Within one calculation, it may evaluate more than 10,000 possible ways of changing the planning.
That continuously produces updated planning.
Martijn: A person could never perform that number of calculations.
But that also shows that working as a business consultant in IT is still very much about people. You have to make sure that everybody trusts the calculations and trusts the software.
What kind of optimisation technology is behind it?
Ard Jan: We use CPLEX as an optimiser.
And the system has an impact on a lot of people. We talk directly with representatives of barge operators and terminals, but behind them are all the people involved in daily operations.
I think the system now affects more than a thousand people.
You can’t interact personally with every one of them. That would be impossible.
That’s why the change process is so important. You have to be able to explain what is happening.
Being able to explain automatic planning generated by an optimiser and bridging the gap between the technology and the users is one of the biggest complexities.
Martijn: And one of the biggest challenges.
Do you feel that people now trust the system and are using it to its full potential, or are there still steps to take?
Ard Jan: There are always steps to take.
For us, it was also the first time that we had automated planning at this scale in the port. It was therefore difficult for everybody to predict beforehand exactly what would happen.
Martijn: So everybody was on the same journey.
It wasn’t a matter of Ab Ovo saying, “We know exactly what to do, so just trust us.” You had to trust each other while moving towards the same goal.
Ard Jan: Exactly. And you need continuous feedback from people.
When you work on a project like this, you naturally dive deeply into the details. Then you have to explain those details to the people using the system.
They will never see everything in exactly the same way as we do from the calculation side because they view it from the operational side.
Martijn: When you talk about planners, does the system also take into account the people working directly at the terminals or on the vessels?
Ard Jan: Yes.
At the deep-sea terminals, for example, they have a NextLogic screen where they can see the planning.
Even shippers can access information. A logistics manager working at a factory in Germany can see what is happening because many different systems are connected.
Everybody can see the status of the container.
That transparency creates another dynamic.
A shipper somewhere in the hinterland, with whom we don’t necessarily have direct contact, may see many changes taking place in the planning and want an explanation.
They need to know that their container will arrive on time. Otherwise, it may miss its window and that costs money through demurrage and detention.
Martijn: So alongside the physical operation of getting a container from A to B, there is an enormous operation behind the scenes just to keep everything running and continuously update the planning.
You mentioned around 26,000 calculations, with each calculation potentially evaluating more than 10,000 options. It’s almost impossible to comprehend the scale.
That also means you have to place a great deal of trust in the technology you’re working with.
Everybody is now talking about AI and new developments in software and computing. Do you see new possibilities for the future? How do you expect this to develop?
Ard Jan: With increasing computing power, I think new opportunities will emerge.
It is difficult to steer calculations when you’re dealing with so many different parameters. But as computing power increases, other options should become possible.
The challenge is the size of the complete puzzle.
If we stopped the planning and tried to find the absolute lowest possible score, the optimiser would continue searching for an extremely long time.
The score includes factors such as how late barges are and whether barges are planned at the same time. Different situations contribute different penalty points.
The optimiser tries to minimise the total score.
Martijn: So essentially you’re trying to reach the optimum efficiency score.
Ard Jan: Exactly. Reaching the absolute optimum would be wonderful, but finding the theoretical optimum could take ages.
There are simply too many possible combinations.
You can’t take the entire planning problem and calculate every possible option at once, so we calculate parts of it.
As computing power increases, it may become possible to take much larger parts of the planning into account simultaneously.
Martijn: So the future isn’t necessarily about completely different software. It’s also about having more computing power available, allowing the existing optimisation software to operate more efficiently and dynamically.
Ard Jan: Exactly.
I’m looking forward to using a quantum computer one day and seeing what that can do.
Martijn: To conclude, when this podcast ends, what’s the next thing you’re going to do? Will you go straight back to looking at the planning?
Ard Jan: Yes. I’ll look at how the planning is behaving.
The environment is so dynamic, with millions of possible choices within the puzzle, that it’s always important to check what the system is doing.
If we see something different that we can’t immediately explain, we dive into it and find out what is happening.
Martijn: Good luck with that, and thank you for joining us.
Ard Jan: Thank you.
