The explanations in the explanation log of the DS Optimizer are sometimes hard to understand/interpret, because the user is not able to review the same situation that has been explained/identified as the root cause by the optimization algorithm. This can have several reasons:
- Compact scheduling and/or backward scheduling is activated in the optimization profile: The explanations are generated after the forward scheduling process and before compact scheduling and/or backward scheduling. You cannot use these mechanisms to better understand the explanation protocol.
- Dynamic pegging is used in LC. Therefore, when you look at the result, orders are shown as late, that the optimizer has not identified as late. Orders are pegged to each other, which the optimizer does not report as root causes. The optimizer reports orders as root causes, which are not pegged to the late order. All this can happen, because LC repegs the orders dynamically. You can fix peg orders before optimization to be able to look at the same data after the optimization run that has been used by the DS Optimizer.
If the DS Optimizer delays an order, the root cause is typically one of the following:
- Capacity: At least one of the resources required in the order is not available in due time to schedule the order before its requirement date.
- Components: At least one of the components required in the order is not available in due time to schedule the order before its requirement date.
- Maximum relationship links: Maximum relationship links prevent the order from being scheduled before its requirement date, because no matching available capacity for linked operations is found.
The figure illustrates how a maximum relationship link between two operations can cause an order to be late. Assume that there is an order with two operations 10 and 20. The first operation must be scheduled on resource 1 and the second operation must be scheduled on resource 2. A maximum relationship links is defined between operations 10 and 20. Although there is available capacity on both resources before the requirement date of the order, the order can be scheduled late, if the available slots on both reserves are outside the maximum allowed time interval defined in the relationship link. This is illustrated in the first chart of the figure, whereas the second chart of the figure shows how the order could have been scheduled on time, if the maximum relationship link between both operations was not present.
Interpretation of Values for Delay in the Explanation Protocol
Sometimes, you may struggle to explain the values for delay in the explanation protocol, because they do not match across the different tabs (Delay, Delay: Resources, Delay: Products). The reason is as follows: Only the delay that is reported for an order on the Delay tab corresponds to the delay of the order. The delays reported as root causes for the delay provide the potential a resolution of a delay can have, if the corresponding constraint was not existing. Therefore, the delays reported as root causes can be higher or lower than the delay of the order itself.
This is explained with an example:
- An order requires two components in the first operation.
- The order consists of three operations (each on finite resources).
- The optimizer schedules the order as follows:
- Operation 1 is scheduled on day 5 because the receipt of the second component (order) is on day 5. The first component is in stock.
- Operation 2 is scheduled on day 9 because the resource is occupied by other orders from day 6 to day 9.
- Operation 3 is scheduled on day 18 because the resource is occupied by other orders from day 10 to day 18.
- The order has a requirement date on day 14.
In this situation, the explanation log provides the following information:
- Delay tab: Here, you find the delay of the order, that is 5 days (day 19 - day 14).
- Delay: Resources tab: Here, you find the order twice:
- for the resource from operation 2 with the indicated delay of 3 days (because the order accumulates here 3 days delay, from day 6 to 9).
- for the resource from operation 3 with the displayed delay of 8 days (because the order here waits 8 days for processing, from day 10 to day 18).
So, the delay shown on this tab represents the potential of how much delay can be avoided on this resource when looking infinitely at the respective resource. Like in this example, this number has no relation to the "real" delay of the order. The value provided here can be smaller or larger than the delay of the order.
- Delay: Product tab: Here, you find an entry for component 2 with the value 5 days, because it delays the order by 5 days. Again, the value shown can be smaller or larger than the order delay.
What does explanation xyz in the explanation log mean?
The most frequent explanations provided in the explanation log and their root causes are listed after this:
- Mode not possible due to missing resource
An operation has several modes. Each mode represents a different resource. Not all resources are in the scope of the optimization. Therefore, certain modes are excluded from the optimization process and the optimizer is limited to those modes whose resources have been selected.
- Some modes have been dropped due to too low priority
An operation has several modes. Each mode has assigned a priority. In the optimization profile, you have chosen to allow only the use of modes up to a certain mode priority. Therefore, all modes are excluded from the optimization process that have a lower mode priority than the one specified in the optimization profile (tab Resource Processing, Mode Priorities).
- Fixed because only deallocated activities can be rescheduled
This explanation applies to an allocated operation, if you have chosen in the optimization profile, that the optimizer should allocate only deallocated operations (tab Order Processing, Selection by Scheduling Status).
- Earliest start date due to start date of optimized plan
An order cannot be scheduled before its requirement date, because the time between the start of the optimized plan and the requirement date is shorter than the remaining processing time even if the fastest mode was chosen and all resources were considered infinite. This explanation is typically triggered for orders with requirement dates in the past.
- Earliest start date due to order validity
An order cannot be scheduled before its requirement date, because the time between the start of the validity period of the order and the requirement date is shorter than the remaining processing time even if the fastest mode was chosen and all resources were considered infinite.
- Earliest start date due to planned delivery time
An order cannot be scheduled before its requirement date, because one of the purchase requisition(s) pegged to the order (or one of its pegged predecessors) has a planned delivery time, that delays the potential start time of the order in such a way, that the remaining time between the potential order start time and the requirement date is shorter than the remaining processing time even if the fastest mode was chosen and all resources were considered infinite. This explanation can occur if you have chosen to plan external procurement and consider planned delivery times in the optimization profile (tab Order Processing, Order Categories to be Rescheduled).
- Earliest start date due to pegging
An order cannot be scheduled before its requirement date, because one of its pegged predecessors is fixed and cannot be scheduled earlier. It means that the time between this pegged predecessor (for example, a planned order that is fixed or not in scope of the selection) and the requirement date is shorter than the remaining processing time even if the fastest mode was chosen and all resources were considered infinite.
- Delay due to capacity conflict
A resource is identified as a root cause for the delay, (a) if the remaining time between the operation on this resource and the requirement date is shorter than the remaining processing time even if the fastest mode was chosen and all subsequent resources were considered infinite AND (b) the operation could have been scheduled earlier on this resource, because this would have been allowed by any preceding operations, but the resource is occupied by other operations/orders at the same time.
- Delay due to maximum interval and subsequent capacity conflict
A maximum interval is identified as a root cause for the delay, if operations linked by the maximum interval could be scheduled earlier, if the maximum interval was not present.
- Keep deallocation due to fixing
An operation is deallocated, because either it was fixed or it was deallocated before optimization and deallocated operations were out of scope of optimization based on settings in the optimization profile (tab Order Processing, Order Categories to be Rescheduled).
- Deallocation due to end of optimization horizon
An operation was deallocated, because the optimizer could not find a slot to schedule the operation before the end of the optimization horizon and you have selected to deallocate operations, if these are to the right of the optimization horizon in the optimization profile (tab Basic Settings, Additional Strategies).
- Deallocation due to deallocated predecessor
An operation was deallocated, because at least one of its predecessors met the criteria for deallocation and you have chosen to deallocate successors of deallocated operations in the optimization profile (tab Additional Strategies, Deallocate).
More information on how to interpret the optimization result is provided in SAP Note 3205348.