In real life, a customer may refuse an order. Or reschedule: “Oh, I’m leaving now on an urgent matter. Please arrive in 4 hours.” And even if, in general, the Robot has built all the routes as profitably as possible for you, but car orders are scattered throughout the city, then if one client refuses, your car will go to a distant area in vain, and you will incur extra costs. The same thing happens when delivering goods to hypermarkets: the driver arrives at the hypermarket, and there is a long line there. And it would be logical for him to go to other stores for now, and in a couple of hours try to drive up to the “hyper” again. If the Robot were able to plan orders “in a cluster”, so that each car primarily serves one area of the city, and at the same time maintaining optimal costs, then this would take into account the risks. After all, if one of the clients refuses delivery or there is an unexpected queue at the ramp in the “hyper”, then the car will still “spin” in this area, and there will be no special losses if it goes to other delivery points for now and then returns back. The problem is that, as a rule, the greatest planned cost savings are achieved with some spread of orders across the city for one car. However, we have found a solution: at the cost of increasing computing power, the LOGIMUS Robot can change decisions in accordance with the strategy chosen by your logistician: maximum savings (dispersion of points around the city is allowed for one car) – maximum risk accounting (accumulation of orders for each car). Smoothly managing the strategy, your logistician will build different solutions with different costs and different quantities. Each of them will be optimal within the grouping specified by the logistician, and will take into account the risks of the client refusing the order or unexpected queues for unloading.
