This article describes a feature in route planning.
Increase recipient satisfaction by planning related orders together
It is logical to assume that two orders to the same address on the same day will always be planned together automatically, because, in isolation, that is least expensive. However, the rest of the order pool may change this calculation. For example, a nearby order may have a time window that decays in the middle of when the second order is planned to be delivered. In that case, without further limitations, the optimisation may have to break up the sequence of the two orders to minimise cost.
Recipient satisfaction can however be worth the extra cost, and we have implemented a feature to allow always planning related services and orders together, even when more expensive.
Note! For convenience, in the following description, to facilitate simple descriptions, an order denotes either a shipment (with a pickup address and delivery address) or a service (with only a service address). Where there is a functional difference, this is called out explicitly with the terms shipment and service.
There are different steps to the grouping of orders.
1. Grouping orders together
2. Determining combined time windows
3. What to do about non-viable groups
How it fits into the planning flow
Planning related orders and services together is only performed within the same pool of orders. Any identified groups are treated as a single entity in terms of planning, with all constraints combined. It is then performed:
- after filtering out orders and services in the order group and
- before performing the route optimisation.
Grouping orders together
The grouping feature will be described using the following example.
Figure 1. The set of orders for route planning.
A group of orders are sent for planning as a single group.
Figure 2. The location clusters are created.
Since at least one grouping is enabled in the rule set, clustering is used. The clustering checks the distance between orders by using a 100 meter radius for all orders. As can be seen, some of these distances overlap other orders. The clustering radius is visually exaggerated in the image for illustrative purposes.
Figure 3. Overlapping clusters are merged.
Clusters 1-9 are created. Clusters 1, 2 and 7 each contain only a single order. As can be seen, clusters 3, 4, 5, 6, 8 and 9 have multiple orders.
In cluster 3, all the orders were within the radius of each other order in the cluster. These orders are then clustered together. The same is the case for clusters 4, 5, 6 and 8.
In cluster 9, however, the most north-western order and the south-eastern order do not overlap each others clustering radius. However, they each overlap the two middle orders. In a first iteration, there would then be two clusters: 9A and 9B. 9A includes the two middle orders and the northwestern order. 9B includes the two middle orders and the southeastern order.
Since there are orders that are in both clusters (the two middle orders), 9A and 9B are merged into one cluster, cluster 9.
Now that the method has produced 9 clusters, grouping can begin. In our example, the planner has enabled grouping by customer and grouping by booking ID.
Orders that do not share any relevant data with any other orders are marked black. These create solo-groups A, B, C, I, J, K and M. Of these, A, B and I were never going to be grouped. However, C, J, K and M could have been grouped had the data matched. As an example, since the order in group C did not share any booking ID or customer information with any of the orders of group D, it has gotten its own group. In other words, it was physically close to two related orders, but wasn’t for the the same recipient.
Orders that match on booking ID (or relational ID) are marked blue. These create groups D, E, G and L. These orders have been ordered together by a customer, and will be planned together.
If customers are allowed to book add-on services, but the booking ID will not match the original booking, the planner can allow grouping by customer. Orders that match on at least one of customer full name and telephone number will then be grouped. They are marked green in figure 4, and are represented by groups F and H. In our example, a customer has booked a delivery in one booking, then later booked an add-on service for the same day.
Note that groups F and G each have one order marked in their colour but then a third has both colours. This scenario is described with figure 5.
Figure 5. Overlapping groups are merged.
The group N is result of merging groups F and G. This order matches the booking ID of group G and the telephone number of group F. In our example, an original booking is made for a delivery and a return. In our example, the return has faulty customer data. Later, an add-on service is booked, and created through manual data-entry.
The two orders of the original booking is naturally grouped, even if the return has faulty customer data, because they share booking ID. Further, as long as the follow-up service shares at least one of full name or telephone number, it is grouped with those orders it shares those properties with. Then, any groups that overlap by containing the same orders are merged.
The grouping method thus concludes with the groups A-E and H-N.
The combined order
Since the purpose is to create a single planning order, the group will need to only have one set of constraints for planning. That means:
- One time frame
- One weight
- One volume
- One task duration
Arrival time windows
After the groups have been created, the combined constraints are created. A very significant combined constraint is the arrival time window. The route planning will endeavour to adhere to the time frames of all orders, called the overlap time frame.
This combined overlap time frame is produced by using the latest start time from among all orders, and the earliest end time from among all orders in the group. This produces the outcomes as described with figure 6 shows four different groups, each with two or three orders marked in grey, and the combined time frame coloured in green.
Figure 6. Overlap time frames
In scenario A, a first order has an arrival time frame of 8:00 - 16:00. A second order has a time frame of 10:00 - 18:00. The combined time frame will be 10:00 - 16:00.
In scenario B, a first order has an arrival time frame of 8:00 - 16:00. A second order has a time frame of 14:00 - 16:00. The combined time frame will be 14:00 - 16:00.
In scenario C, a first order has an arrival time frame of 8:00 - 16:00. A second order has a time frame of 10:00 - 18:00. A third order has a time frame of 13:00 - 18:00 The combined time frame will be 13:00 - 16:00.
In scenario D, a first order has an arrival time frame of 8:00 - 12:00. A second order has a time frame of 12:30 - 18:00. The combined time frame will be 12:00 - 12:30.
Since any overlap duration is considered viable, the order creator and bookers should note that short overlaps will be allowed through and will produce routes that are harder to fulfil in a satisfying manner.
Non-viable groups
It is possible to create groups that cannot be planned together. The following describes a few scenarios and the fallback options that the planner has available. In general, the planner can select whether this should result in the group being split for planning individually, or to keep the group together for adjustment by the planner.
Figure 7. Invalid overlap time frames
When two orders in a group have time frames that does not overlap, they cannot be route planned together. This produces two different errors, depending on the settings set by the planner in the rule set.
More technically, the orders cannot be planned together when the latest start time is later than the earliest end time from among the orders of a group.
Option 1: Unscheduling
Unscheduling makes sure that the orders to be planned are unscheduled and that the planner therefore identifies the error when a route plan is created. The planner can then rectify the data error or ungroup the orders for a subsequent re-planning. It should be used when it is imperative that orders should be planned together, even when this means being more hands-on in the route planning.
In scenarios E and F, the planner has selected unscheduling.
In scenario E, a group has
-
a first order with time frame 8:00 - 13:00 and
-
a second order with time frame 14:00 - 18:00.
Since no overlap exists, the two orders, remaining grouped, are unplanned, and populates the ‘unplanned’ as part of the route plan. No viable overlap is found, indicated with the red bar.
In scenario F a group has
-
a first order with time frame 8:00 - 13:00,
-
a second order with time frame 14:00 - 18:00 and
-
a third order with a time frame of 8:00 - 18:00.
Although the third order could be planned with any of the first and second order, the group cannot collectively be planned, and therefore, even this third order is unplanned. No viable overlap is found, indicated with the red bar.
Option 2: Ungrouping
Ungrouping makes sure that the orders are always included in the route planning, even when this results in a worse recipient experience. This should be used when automation is more important than catching every small issue, and when this error scenario is sufficiently rare.
In scenarios G and H, the planner has selected “when no overlap, ungroup. Scenario G (marked with green bars G1 and G2) has a group with
-
a first order with a time frame of 8:00 - 13:00 and
-
a second order with time frame 14:00 - 18:00.
Therefore, no viable overlap is found in the group. Because the planner has determined that this should ungroup the orders, each of the orders are assigned their own group, and planned individually.
Scenario H (marked with green bars H1, H2 and H3) has a group with
-
a first order with a time frame of 8:00 - 13:00,
-
a second order with time frame 14:00 - 18:00 and
-
a third order with a time frame of 8:00 - 18:00.
Again, no viable overlap is found in the group and, because of the configuration of the planner, the orders are ungrouped.
Note that though the third order could in principle be planned with either of the first or the second order, it will also be ungrouped and planned alone because there is no effective way to select which orders stays in the group.
With the ungroup setting, all of the associated effects as for any individually planned order results for the orders: they may go on the same route or different routes, they may be unplanned if capacities are exceeded, and if they happen to be planned on one route and one after another, their relative sequence would be created without consideration of any sequencing rules, since sequencing is only considered inside groups.
Comments
0 comments
Please sign in to leave a comment.