What is happening, if you call the optimizer for vehicle scheduling and routing?
To make transportation decisions it needs a lot of different information: You need all locations, the locations directly referenced in the Freight Units and all possible transshipment locations. Based on this set of locations the optimizer has to search for possible lanes. If you have the lanes, it has to detect all the resulting distances and duration of possible transports. Of course it has to read also all resources on these lanes, possible schedules and bookings. Then it has to consider the current situation on these resources, incompatibilities, handling resources, driving constraints and some more objects. You can use the explanation tool to see all this data sent to the optimizer for every optimization run. But the explanation log will be an own blog.
Why do I mention all these different objects? All these objects are needed to create transportation plans. The optimizer has to read most of their attributes and has to consider them during the building and evaluation of transportation plans.
This means that each of the mentioned objects and nearly each of their attributes have an effect on the result of the optimizer. Therefore it is very likely that there are some small faults in the data. As result you will see an unexpected plan. Some parts of the plan are not acceptable or are completely different to the business so far. Now you have the difficult task to find the fault in the data, responsible for the unwanted plans.
In most of the TM processes you work with a very limited number of objects. For example,if you create the Freight Units for a Forwarding Order. If the resulting Freight Units are somehow not ok, you know that you mainly have to look to the Forwarding Order and the Freight Unit Building Rule. It would be senseless, to check your transportation network or to check the existing Freight Orders.
But this is different for optimization. A missing lane could lead to complicated routings of Freight Units and you see a bottleneck situation in a completely different transshipment location. Existing fixed Freight Orders could block resources for a very long time, so that we have a capacity shortage and use expensive resources or deliver very late.
That means you can see that something is wrong in the plans created by the optimizer. But it is very hard to find the root cause for these decisions.
Looking at my experience there are three main reasons which cause most of the problems:
- Wrong selection
Very often it is simply the selection for resources, Freight Units or horizons which
is not ok.
- Transportation Network, especially missing lanes
Very often we see that lanes are missing, sometimes for specific means of transport only, sometimes completely.
- The Planning process is not clearly defined
Usually everyone can say what he wants to plan and how this should happen. But if you decide to go to the next step and
set up a periodical planning process, then you have to define, what has to happen with the planning results of the former planning run. Which decisions
have to stay fixed? Which decisions should be adapted by new Freight Units and what do you want to re-plan completely?
You can avoid all these pitfalls easily, if you don't wait until all objects of your scenario are defined and you start a big-bang test, but if you start testing early. As soon as you have the first parts of your implementation done, start testing, if the automatic planning works like you would expect it.
It may be it’s not the finally needed result, because things like incompatibilities are still missing. But you can check the plan based on your current status of your implementation. Do the plans look like you expect them? With every new part of your implementation you have expectations how it should change the optimization result. If it is working like you expect it, most probably everything is running fine with the last implementation step. If the results are surprising, you can imagine that it is somehow because of your last implementation steps.
Then you know where you have to look for.
For the three main pitfalls this means:
- To check if your selections are working well, you can use the explanation tool. You see all objects which are passed to the optimizer in the input part. Check if your new objects are selected and sent to the optimizer.
- To see if the definition of your network is fine, you have to look to your planning results. Evaluate the result of the optimizer carefully. Check the messages about possible routing problems and look at the resulting routings and dates. If the routing is not like you expect it, it might help to play around with the transportation proposal. It is internally using the same functionality like the optimizer. Try to force the freight unit to your preferred route and see, if there are messages or computed cost are ok, or if the unexpected route is cheaper.
- Don't stop after one test! Repeat it two or three times! Add additional freight units and repeat the test. Is the
behavior like you expect it or do you need to adapt some planning parameters like
the horizon?
Of course this is nothing new to you. Everyone says, test early. But especially with that many different types of objects involved and the usual high volume it is key: start testing optimization early.
It might be that it is your first optimization project and it seems very difficult and time
consuming to you, to get such tests running, than look for help! SAP offers expert consulting for transportation optimization. Experts can help you to do some regular tests and consult you how to go on. Especially you will learn from them a lot and most probably you can do it in the next project by your own.
I want to say it very clear: There is no way around such functional incremental testing. Otherwise you will have the large optimization run at the end of your project. You will get the pressure of the end user for every unexpected behavior and you have to find the problem in very large set of all the optimization relevant objects.
So far I wrote only about the functional part. Of course, if we speak about optimization, there is always the question about performance, too. I already said that every object or constraint will change the optimization result. And this means it can also have a very great impact on the search logic and the runtime. So it makes no sense to start volume tests with the half of the functionality. It is hard to predict if the missing features, especially combined with the already implemented ones – are performance critical or not. This depends on a lot of details, like which of the constraints are the most restrictive ones at the end.
The performance forces us to the same approach like already described for features. Add the features step by step and test the optimizer again. You might see that a certain feature increases your runtime significantly. So we know at least the reason where to search, if we have runtime issues at the end. In this case of course the expert consulting is very helpful again. And in the very hard cases of course SAP supports you as much as possible.
The good thing about all these test efforts: For most of us successfully passed optimization tests create at least a little bit fun and pride about the done work. The next blog will be about a good starting scenario for the incremental approach.
