Service Provider Assignment & Resource Management

This topic describes the resource management functionality for carrier/equipment optimization.

Parameter settings can impact functionality and results. There is a group of "Service Provider Assignment" parameters.

Note: Work Assignments and Capacity Limits should not be used together. Work assignment logic uses resource schedules as the limited resource to be planned against, rather than capacity limits.

Cross-dock & Capacity

Since pool/cross-dock shipments are built individually, each shipment captures the best available carrier and equipment. However, each shipment is unaware of the capacity usages that are obtained by other shipments in the same bulk plan run.

For example:

Given these assumptions:

• Service Provider A: has a daily capacity limit of 1, offering the cheapest rate.
• Service Provider B: has a daily capacity limit of 1, offering a more expensive rate.
• Service Provider C: has no capacity constraint, offering the most expensive rate.

After a bulk plan run, three shipments come out of cross-dock (X-dock), S1, S2 and S3, all use the cheapest carrier Carrier_A. Since Carrier_A only has 1 equipment available each day, when committing these shipments, capacity trigger will be fired. To solve this problem, Oracle Transportation Management re-checks capacity at the end of bulk plan using a Capacity Usage Summary table to maintain the counter for each capacity usage used in the shipment graph. If the capacity usage on a specific shipment is over-limit, Oracle Transportation Management re-assigns the next available cheapest resource (combination of carrier and equipment) to the shipment, excluding any resource that already reach capacity limit. If the new resource is successfully assigned, Oracle Transportation Management updates the counter in Capacity Usage Summary table. If no available new resource for that shipment, the whole shipment graph is not saved.

The algorithm of ranking the shipment to be evaluated is discussed later. Let us assume now we check capacity in the order of shipment S1, then S2 and S3.

1. Check capacity for shipment S1, assigned Carrier_A has 1 available, keep the carrier; update usage count. Carrier_A now reach its limit and is put on the excluded list: [Carrier_A].
2. Check capacity for shipment S2, assigned Carrier_A that has no available capacity; then check for the next cheapest carrier: Carrier_B, Carrier_B has 1 equipment available, assign it to S2, update usage count, Carrier_B reaches the limit, and is put on the excluded list:[Carrier_A, Carrier_B].
3. Check capacity for shipment S3, Carrier_A and Carrier_B both reach limit, assign Carrier_C (most expensive one and has no capacity constraint) to shipmentS2.

After the carrier assignments, the shipment graph looks like this:

 

Equipment Selection & Capacity

The previous example assumes that the equipment remains the same and only carriers are reassigned. In reality, Oracle Transportation Management may arrive at a better solution if it keeps the same carrier and assigns a different equipment group. The optimization will return an optimal result. It could be the same carrier with a different equipment group, or the same equipment group with a different carrier, whichever costs less.

The algorithm assigns best alternative equipment/carrier, depending on the configuration of the Equipment Group Profile:

1. For multi-modal set, a best-fit equipment group in each equipment group profile is picked. Oracle Transportation Management finds a least cost and feasible rate for this equipment group and then compares it with other rates based on equipment from other equipment group profiles. Oracle Transportation Management then chooses the least expensive one among all the rate options.
   
   E.g.: Multi-Modal Set:
   
   Equipment Group Profile:Dry Van Equipment Group Profile:Vessel Container
   28FT Dry Van (best fit) 20FT General Container
   40FT Dry Van 40FT General Container (best fit)
   53FT Dry Van 50FT General Container
   
   In the above example, Oracle Transportation Management first chooses the 28FT Dry Van and 40FT General Container from each profile, and finds the least cost feasible rate option for each equipment group individually, compares the cost, and chooses the least expensive option.
2. For non-multi-model set, each equipment group in the equipment group profile is evaluated individually; and the least cost and feasible rate among all the rate options based on all equipment groups within the profile is found.
   
   E.g.: Single Equipment Group Profile
   
   Equipment Group ProfileSingle Profile
   28FT Dry Van (best fit)
   40FT Dry Van (least cost)
   40FT General Container
   60FT General Container
   
   In the above example, Oracle Transportation Management would find a rate for equipment group and compare their cost; 28FT Dry Van is the best fit equipment but not the least cost; 40FT Dry Van is bigger but is cheaper, so it is chosen.

Note: Re-rate logic does not change the Equipment Group on the shipment if there is no Equipment Group Profile or Equipment Group Profile Set defined on the itinerary leg.

Note: The property glog.business.equipment.allowRotation impacts how the ship unit/line item fits in the equipment.

Re-rate Shipments after Bulk Planning

During the bulk plan/multi-stop process, Oracle Transportation Management does not evaluate all equipment groups in each equipment group profile due to performance concerns. It only evaluates the best-fit equipment group, calculates cost and service time, and then compares the results from other equipment group profiles to choose the least cost feasible one. Therefore, better equipment options may be missed. In the above example, 40FT Dry Van is cheaper than 28FT Dry Van, but it is not the best fit equipment, so it will be thrown out.

Oracle Transportation Management extends the reassigning carrier resource functionality from carriers that have capacity constraints to all carriers to optimize the equipment assignment. The parameter " RerateAllShipmentsAfterBulkPlan" controls this behavior.

• If set to TRUE, Oracle Transportation Management re-rates all shipments regardless of its capacity usage.
• If set to FALSE, only re-rate shipments of which carrier capacities are no longer available (over limit).

• Note: Oracle Transportation Management only evaluates the rates that have the same Rate Service ID as the rate that was previously assigned during bulk plan process and since Rate Service ID remains the same service time is not recalculated.

Re-calculate Shipment Cost after Shipment Planning

For some time-based rates, the shipment cost calculated during bulk plan and build shipment process may not be accurate. Therefore, you can use the Recalculate Cost check box on the Rate Offering to force recalculating cost after shipment is built.

Split Order & Capacity

If shipments were split, Oracle Transportation Management only checks capacity for the first shipment and counts the number of split shipments as the number of equipment needed for a particular capacity usage. Split shipments on the same leg may reference a different Capacity Usage ID.

Prioritize Carrier Selection for Shipments

The parameter, CARRIER CAPACITY WEIGHTING FACTOR, can be used to calculate the weighted significance of carrier selection. The higher the value, the more significant the first choice carrier is; the lower the value, the more significant the second choice carrier is.

General process of re-rate shipment graph collection

Track Capacity Usage

Both Capacity Limit and Capacity Usage are referenced by Capacity Group on Rate Offering. To only use one of these two, use the Track Capacity Usage check box on the Rate Offering as follows:

• Track Capacity Usage=TRUE, and Capacity Group field is not null, Capacity Usage is tracked during the planning process;
• Track Capacity Usage=FALSE, or Capacity Group field is null, Capacity Usage is not tracked during the planning process.

If you run a Capacity Commit report and want to bypass Capacity Limit/Usage, populate the Capacity Group field on Rate Offering and set Track Capacity Usage to FALSE (not selected).

This field only has an effect when the Capacity Group field is not NULL.

Unlimited Capacity Usage

Carriers only need to set capacity limit data on the lane or equipment type that has capacity constraint, or the lane or equipment type that carriers care about capacity usage. If there is no capacity limit defined on certain lanes or equipment types for a carrier, Oracle Transportation Management assumes the carrier has unlimited capacity.

For example, Carrier A (represented by Capacity Group A) has a limit of 10 shipments per day for Equipment Type Dry Van from East coast to LA, but has no limit for the same equipment type from West coast to LA. It has no capacity (limit of zero) for the same Equipment Type from Central to LA, so the following Capacity Limit is set:

Capacity Group	Lane	Equipment Type	Time Period	Capacity Limit
A	East Coast to LA	Dry Van	Daily	10
A	Central to LA	Dry Van	Daily	0

 

Since no capacity limit is defined for lane: East to LA, Oracle Transportation Management assumes it is unlimited.

Multistop

To have multistop shipments consider carrier capacity constraints, set parameter Consider Carrier Capacities During Multistop to true.

Shared Equipment Between Legs

Service provider assignment can use commitments to assign service providers to shipments on legs that share equipment with other legs. Note the following:

• When order movements on the other shared equipment legs are not already planned, then OTM will be able to choose equipment group as well as service provider.
• When order movements are being planned, and the corresponding order movements on the other shared equipment legs are already planned, then OTM will not be able to choose equipment group, since it has already been chosen on the other shared equipment legs. OTM will be able to choose service provider (from among the service providers that support the already-selected equipment group).
• When the order release is being planned, or when order movements for multiple shared equipment legs are being planned (but no shared equipment leg order movements are already planned), OTM has a limitation: it will only be able to choose the equipment group that it would have chosen without commitments. Thus, if the service providers with the commitments do not use the same equipment group set, OTM may not be able to plan according to the commitments, because its equipment group choice is limited, and the equipment group selection affects the carrier selection.

Service Provider Assignment Time Window Functionality

OTM allows you to feasibly change the shipment's start date inside the service provider assignment logic to improve the solution quality when only limited resources are available (capacity limit). This can be useful when the demand outstrips supply. Generally, OTM takes shipments with pre-assigned start and end times and assigns the least cost service provider with regard to the provided time window and equipment. However, there are cases where the pre-assigned shipment start date on the shipment keeps OTM from finding the optimal solution. For example, you have two identical order releases with no time constraints and two service providers. One of the service providers is cheaper, but it has a capacity limit that allows only one shipment per day. The other one is more expensive, but it is unlimited. For this scenario, the optimal solution from a cost perspective would be to generate two shipments on two consecutive days. However, because of the pre-assigned start and end time, OTM chooses to use both of the service providers and makes two shipments on the same day. To avoid a scenario like this, OTM allows you to shift the shipment start date by setting the following parameters.

• SPA MAX DAYS TO CONSIDER: This parameter determines how many extra possible start days,OTM will consider for each shipment, subject to capacity limits. When using this parameter, it is best to set this no larger than needed, as it can have a performance impact. For example, if two extra days is sufficient to find the right resources, then there is no reason to set it higher than 2.
• SPA TIME CHANGE POLICY: This parameter provides priority level control about whether OTM should encourage delaying the shipment start date in order to take advantage of a cheap but capacity-limited service provider.

Following are some scenarios along with the appropriate parameter settings:

1. The only available carrier has capacity limits, and the start dates of some shipments must be delayed in order to be able to schedule all the shipments successfully.
   Set the SPA MAX DAYS TO CONSIDER to be a sufficient value, SPA TIME CHANGE POLICY does not affect the solution, as there is only one available carrier.
2. There is an expensive carrier with unlimited capacity. You would like to change the shipment with any priority to start dates in order to use the cheap carrier.
   Set SPA MAX DAYS TO CONSIDER to be a sufficient value and set SPA TIME CHANGE POLICY to Encourage Time Change.
3. There is an expensive carrier. You would like shipments to start on their earliest start dates unless capacity is used up.
   Set SPA MAX DAYS TO CONSIDER to be a sufficient value, Set SPA TIME CHANGE POLICY CHANGE to Discourage Time Change.

4. Orders have different priorities (low, medium, high) and capacity limits. You want the higher priority orders to be shipped on their earliest start date and push medium and low orders to later days.
   Set the SPA MAX DAYS TO CONSIDER to be a sufficient value, Set SPA TIME CHANGE POLICY TO Discourage Time Change for High Priority Shipment. Note that, when Priority is introduced, OTM will always assign capacity to the higher priority shipment before the lower priority shipment.