Configuring the Optimization Profile

The Optimization Profile is structured into multiple tabs. The first tab is the Basic Settings tab. Here you can define the weights of the objective function.

The objective function of the DS Optimizer is a weighted sum of the following criteria:

• Makespan
• Total setup times
• Total setup costs
• Maximum delay costs
• Total delay costs
• Total mode costs

You can define the weights of the objective function in the Optimization Profile. The weights define how the trade off between different objectives is evaluated by the DS Optimizer. During optimization, the algorithm tries to minimize the objective function, that is, it tries to find a schedule in which the heavily weighted times and costs are as small as possible.

How the optimization algorithm is calculating different solutions and how these are evaluated is illustrated in the subsequent figure.

In this example, six orders A - F must be scheduled. The objectives are the minimization of setup times and total delay and both objective criteria have an equal weight (it is assumed that the weight is 1 for simplicity). The basic logic of the optimization algorithm is to schedule all activities as early as possible on any of the resources.

In the first solution, the orders are scheduled in the sequence A-B-D-C-E-F (indicated by the number inside the order). The setup time should be 100 and the delay of this solution is 50. Considering the weight, this amounts to a total objective function value of 150. In the second solution, the orders are scheduled in the sequence D-C-F-E-B-A (indicated by the number inside the order). The setup time should be 60 and the delay of this solution is 80. Considering the weight, this amounts to a total objective function value of 140. In the third solution, the orders are scheduled in the sequence D-F-B-E-C-A (indicated by the number inside the order). The setup time should be 80 and the delay of this solution is 90. Considering the weight, this amounts to a total objective function value of 170.

The algorithm continues to create more solutions as described in the previous lesson on genetic algorithms and always keep the best solution (solution 2 in this example).

This process continues for the specified maximum runtime. The Maximum Runtime is also defined in the optimization profile on the Basic Settings tab.

You can specify that the optimization run is to be ended once the first solution is found. If you set this indicator, the optimizer completes the run after finding the first valid solution. You can use this option to restrict the runtime for an optimization problem to the absolute minimum.

There is no simple way to estimate a reasonable run time for a specific planning scenario in theory. The run time depends very much on scenario-specific details. Internally, each optimization run is a search process. It is very hard to estimate how long it needs to search, until it finds a pleasant solution. Therefore, in a project you should run the optimizer on a realistic (in terms of volume of data and complexity) test set in order to analyze the run time behavior of the algorithm.

For many scenarios, the runtime behavior of the algorithm shows an asymptotic shape like in the figure Runtime/Termination Criteria. In the beginning of the process, the improvements concerning the minimization of the objective function are significant, whereas after some time the curve gets flat, presumably because the algorithm has come close to the optimal solution. A reasonable estimate for the optimizer runtime can be obtained from this graph (some (buffer) time into the flat part of the curve). This is what you can then define as Maximum Runtime for productive use.

You can obtain this information either visually from an interactive optimization run or by looking at the explanation log of an optimization run (on the Solutions tab). In general, a recommendation is to use whatever time is available for optimization, since the solution will never get worse.

Furthermore, you can also specify on the Basic Settings tab how optimization handles operations that are late. You have the following options:

• Schedule late operations

  If you choose this option, the optimization schedules all operations.

• Deallocate late operations, if they end after the end of the optimization horizon.

  If you choose this option, the optimization deallocates operations that end after the end of the optimization horizon, and positions them as late as possible within the optimization horizon.

• Deallocate all late operations.

  If you choose this option, the optimization deallocates all operations that are late for the requirement date/time or end after the end of the horizon.

If you choose the second or the third option, the optimization shows the deallocation costs as part of the objective function and displays them as a curve in the optimization diagram. Even though the algorithm does not delay operations due to capacity restrictions by doing this, delay costs can occur due to receipts being too late or demand being too early. For both options, the optimization tries to minimize the number of deallocated orders.

On the Additional Strategies tab, you can enter a threshold value to specify the exact hour/minute starting from which you want optimization to deallocate the delayed operation. For example, if you enter a threshold value of 48 hours and an operation is delayed by more than 48 hours, it is deallocated. If the operation is delayed by less than 48 hours, it will not be deallocated. You can also force the optimizer to Deallocate Successors of Deallocated Operations on the Additional Strategies tab. In this case, the algorithm uses the activity and pegging relationships to determine the succeeding operations and deallocates them also.

A use case for the deallocation functionality is to highlight capacity overloads in the medium term, while planning in a planning or simulation version. In the active planning version, deallocation is typically not helpful, because the plan is not feasible as long as operations are deallocated. However, in a planning version, deallocation of operations can highlight when and where, that is on which resources more capacity would be required to get a feasible plan that meets the order due dates. As a result of this insight, available capacity can be increased in the active version/productive environment.

Note that the deallocation functionality cannot be used if campaigns are in the scope of optimization, or if bottleneck optimization is used as a decomposition method.

There are two strategies available at the end of the optimization run. Using backward scheduling the system tries to schedule the activities that were scheduled too early as close as possible to the requirement dates. Forward optimization minimizes setups and delays, but all activities are scheduled as early as possible. During backward scheduling activities are scheduled as late as possible without violating due dates based on the result of forward scheduling.

Using compact scheduling the system tries to reduce the lead time of the orders that is to plan each order with the smallest possible amount of time between the activities. The objective function criteria setup or delay are not worsened by this logic. With compact scheduling, no additional orders are delayed.

In general, the DS Optimizer tries to schedule all activities as early as possible. There are only these two mechanisms that deviate from this principle: Compact Scheduling and Backwards Scheduling. Even if compact scheduling and/or backwards scheduling are used, most of the runtime and optimization process is used to schedule all activities as early as possible, the compact scheduling/backwards scheduling is only used as a mechanism at the end of the optimization process to address these two objectives. The compact scheduling mechanism tries to minimize the total duration of an order by reducing gaps between activities. The backwards scheduling mechanism tries to minimize the earliness of an order by moving it closer to its requirement date. Both mechanisms are applied (if selected) on the intermediate optimization result that has been created in forward scheduling mode, that is, all activities being scheduled as early as possible.

Compact scheduling allows you to reduce order lead times. The lead time of an order is an important indicator for evaluating the quality of production plans that are generated automatically. You can use this function to reduce order lead times and generate an improved production plan. Shorter lead times also reduce storage costs and wait times.

The compact scheduling step can only be successful if the orders to be optimized do not contain any fixed activities. If the orders contain fixed activities, the compact scheduling logic can align the order to its fixed part only. To use compact scheduling, you must set the Compact scheduling indicator on the Basic Settings tab in the optimization profile.

The figure Compact and Backwards Scheduling illustrates the difference of both strategies.

The example consists of four orders (with different colors) with three operations each, one on each resource. The requirement dates for each order are indicated by triangles in the same color of the respective order. The first Gantt chart shows the optimization result without either compact scheduling or backwards scheduling. All operations are scheduled as early as possible, that is leftmost. Since the second operation of each order takes significantly longer to process than the first operation, there are gaps between the first and second operations of each order. This means, the leadtime for each order is larger than it should be, which means work-in-process and unnecessary waiting times.

This is changed in the second Gantt chart with compact scheduling being active. The compact scheduling mechanism aligns the first and second operations of each order. The third Gantt chart shows the influence of backwards scheduling being active. Two orders are moved to the right to better align with their requirement dates.

Compact scheduling and/or backwards scheduling can be conflicting with the optimization criteria. If the sequence of activities is determined as the optimal setup sequence, but the requirement date sequence is different, it is possible that compact scheduling and/or backward scheduling can deteriorate the optimization result. However, this is not allowed in standard as illustrated in the next figure.

The example consists of four orders (with different colors) with three operations each, one on each resource. The requirement dates for each order are indicated by triangles in the same color of the respective order. The first Gantt chart shows the optimization result without either compact scheduling or backwards scheduling. All operations are scheduled as early as possible, that is leftmost. The shown order sequence should reflect an optimal setup sequence. This would be the result of optimization, if setup times had been in the focus.

Since the second operation of each order takes significantly longer to process than the first operation, there are gaps between the first and second operations of each order. This means, the leadtime for each order is larger than it should be, which means work-in-process and unnecessary waiting times. Furthermore, all orders are scheduled ahead of their requirement dates.

By default, the backwards scheduling logic is not allowed to deteriorate any objective function criteria. Therefore, if backwards scheduling was applied to this solution, the result in the second Gantt chart would be obtained. The order sequence would be kept, but all orders are shifted right to align better with their requirement dates.

Even this solution could mean a deterioration of the objective function, if makespan had been weighted, because the second solution has a higher makespan than the first solution. Whether the makespan can be increased or not is defined on the Additional Strategies tab of the optimization profile with option Do Not Increase Makespan.

Whether solution two or three is optimal, that is whether the setup sequence (which has been defined as an objective criteria) or the avoidance of earliness (which can be achieved by sequencing orders by their requirement date in solution three) is more important, can also be influenced with special optimization parameters that are explained in a subsequent lesson. What is considered optimal in a specific planning scenario is highly dependent on business requirements.

On the Order Processing tab, you can define which order categories are to be rescheduled by the DS optimizer. Activating the check boxes means that corresponding order categories can be rescheduled during the optimization run. All other order categories are fixed for optimization. Available order categories are:

• External Procurement
• In-house Production
• Stock Transfers
• TLB Shipment
• Network

The main use case for DS optimization is the scheduling of production (production orders, process orders, planned orders). However, several scenarios exist, in which other order categories must be rescheduled in accordance with production. The most prominent is external procurement. If you select external procurement as a relevant order category, the DS optimizer can also reschedule purchase requisitions. For purchase requisitions, you can select the Consider Planned Delivery Time indicator. If you select this indicator, the purchase requisitions will always be scheduled outside their planned delivery time. Note that purchase orders are not rescheduled by the DS optimizer, but considered as fixed receipts instead.

If you want to optimize across locations, you can select resources on both locations. With this selection, also the elements connecting the production activities on both locations, that are transport orders or stock transfer orders, become part of the optimization scope. If you select these order categories, the corresponding stock transport requisitions are rescheduled by the DS optimizer. This does not include any vehicle routing or does consider any transportation capacities, but the calendar of the transport resource is considered.

Finally, if you select Network, the DS optimizer is able to reschedule project orders. Since project orders do not have a pegged due date, the DS optimizer plans as if the current end date of the project is its due date.

In addition to the selection by order category, you can select, which operations are rescheduled by the scheduling status. You have the following three options:

• Scheduled only

  If you select only scheduled operations for optimization, the deallocated operations remain deallocated, but are rescheduled so as not to restrict the optimization of scheduled operations by dependencies.

• Scheduled and Deallocated

  If you select scheduled and deallocated operations for optimization, the DS optimizer schedules all operations and will also allocate all operations as part of the optimization run.

• Deallocated Only

  If you select only deallocated operations for optimization, the scheduled operations are not changed by optimization, but considered as fixed. The deallocated operations receive the status scheduled by the optimization run.

  This setting can be used, if the plan should be kept stable, but only some additional orders (the deallocated ones) should be inserted into available capacity.

Using order priority, you can set which orders should be scheduled with greater preference. There exist different ways of prioritization of orders. On the one hand side, priorities can be considered soft using costs in the objective function. On the other hand, priorities can be considered as a hard constraint. Using order priority on the Order Processing tab, the algorithm divides the available orders into two groups: the group with orders that meet the given order priority, and the group with orders that do not meet the given value. The orders that meet the order priority are rated as very important and are scheduled with greater preference during optimization. You can use the order priority in connection with the ATP Category to specifically choose certain order types with a higher priority. These are then scheduled first during optimization.

Example with Order Priority:

You have entered the order priority as the value 2. The algorithm forms two groups of orders. Orders with the order priority 1 or 2. These orders are considered very important and the algorithm schedules them with preference. The remaining orders with an order priority of 3 or more are rated as less important.

Example with ATP Category and Order Priority:

By choosing a set of ATP Categories, you have, for example, determined that production orders should be scheduled with preference over other order types during optimization. You have also entered the order priority as the value 2. The system then divides the available orders according to their ATP category and according to their order priority. From that the algorithm forms four groups of orders: Production orders with order priority 1 or 2 are in group 1 and have the highest priority. Production orders with an order priority 3 or more are in group 2 and rated as less important. All other order types with order priority 1 or 2 are in group 3 and rated as less important. All other order types with order priority 3 or more are in group 4 and are rated as least important.

When the algorithm schedules the orders, it essentially does so by group. Orders from a lower group are scheduled after orders from a higher group. Thus, orders from a lower group can only use the capacity that has been left once all orders from higher groups have been scheduled.

There are different options to define whether orders/operations are to be considered fixed for optimization or not. The following objects are fixed in principal during optimization:

• Manually fixed, started, partially confirmed, or completely confirmed operations.
• Operations that do not lie on the resources selected for optimization.
• Activities outside or only partially within the optimization horizon.

Apart from these, you have the following options to control, which objects the algorithm considers as fixed for the optimization run. This fixing is only relevant for the optimization run as such and are not taken over into the application.

• Orders with Fixed Activities

  If you set this indicator, orders that have at least one fixed activity are fixed during optimization.

• Orders Partially Located Outside the Optimization Horizon

  You can fix orders that start before the optimization horizon. If you set this indicator, those orders which begin before the optimization horizon and extend into it are fixed during optimization. All activities of these operations cannot therefore be rescheduled during optimization.

  You can fix orders that end beyond the optimization horizon. If you set this indicator, those orders which begin in the optimization horizon and last after it has ended, are fixed during optimization. All activities of these operations cannot therefore be rescheduled during optimization.

• Released Operations

  You can choose whether the operations that are already released for production are fixed during optimization, or whether all operations of an order that has at least one released operation are considered fixed during optimization.

Validity periods are determined for orders based on the source of supply. Validity periods control, when the order can be scheduled. For example, when a critical component in a product is changed, you can define how long you can produce the product with the old component and from when the new component has to be used. This is expressed with the validity period of the order. Regarding validity periods, you can influence the optimization algorithm as follows:

• Regard as hard

  The optimizer must consider the validity periods for the order to be scheduled. It is not possible to schedule orders outside their validity periods.

• Regard as soft

  The optimizer has to schedule orders earliest at the beginning of the validity period, but it is allowed that they are scheduled after the end of the validity period. If the validity period is exceeded, then this is treated as a lateness of the order and the corresponding costs are calculated (according to the weights in the optimization profile). The lateness caused by a violation of the validity is penalized with costs which are twice as high as the costs defined for the lateness of orders with highest priority costs.

• Ignore

  The optimizer does not consider validity periods.

• Regard as Deallocated

  The system behaves as it would under Regard as soft. In addition, it deallocates the orders that violate their validity periods and returns them with the Scheduling Status deallocated back into the validity period. The validity period is thus adhered to. When the system returns orders with the deallocated status, it ignores activity relationships and pegging relationships.

The following figures illustrate this behavior.

The first chart shows the situation before an optimization run. All orders are scheduled in May, although some orders have a validity period from the beginning of June to the end of July. If validity periods are ignored by using the corresponding setting in the optimization profile, all orders are scheduled in May in the optimization result. This is reflected in the second chart.

The first chart shows the situation before an optimization run. All orders are scheduled in May, although some orders have a validity period from the beginning of June to the end of July. If validity periods are regarded as soft and the start of the optimized plan is the beginning of May, the orders without restricted validity are scheduled in May in the optimization result. However, the orders that are valid from the beginning of June are scheduled in June in the optimization result. Since these orders do not violate the end of the validity period, there are no additional delay costs calculated other than those relative to their requirement dates. This is reflected in the second chart.

The first chart shows the situation before an optimization run. All orders are scheduled in May, although some orders have a validity period from the beginning of June to the end of July. If validity periods are regarded as hard and the start of the optimized plan is the beginning of May, the orders without restricted validity are scheduled in May in the optimization result. However, the orders that are valid from the beginning of June are scheduled in June in the optimization result. Since these orders do not violate the end of the validity period, there are no additional delay costs calculated other than those relative to their requirement dates. This is reflected in the second chart. In this example, the result matches the result from the previous example.

The first chart shows the situation before an optimization run. All orders are scheduled in May, although some orders have a validity period from the beginning of June to the end of July. If validity periods are regarded as soft and the start of the optimized plan is the beginning of August, all orders are scheduled in August in the optimization result. Since the orders with a restricted validity period violate the end of the validity period, there are extra delay costs calculated. The delay with reference to the end of the validity period is penalized with costs which are twice as high as the costs defined for the delay of orders with highest priority costs. This is reflected in the second chart.

The first chart shows the situation before an optimization run. All orders are scheduled in May, although some orders have a validity period from the beginning of June to the end of July. If validity periods are regarded as hard and the start of the optimized plan is the beginning of August, the optimizer cannot return any planning result, because no feasible solution exists. This is reflected in the second chart.

In some planning scenario, it is reasonable to plan only specific BOM levels. For example, if you follow a top-down approach, you want to optimize the finished good production first and afterward you want to align production of semifinished goods to the planning result for the finished goods. Likewise, you can follow the opposite direction and plan the production of semifinished materials first and afterward plan the finished goods in a bottom-up approach. The DS optimizer supports both scenarios.

If you have several operations on different resources and you select only a certain set of the resources (for example the resources for the production of finished goods), then operations on the not selected resources (for semifinished products) should not influence the result of optimization. By default, the fixed operations on the predecessor resource would propagate an earliest start time for the operations on selected resources. This is not desired here, because you want to plan finished goods first and align production of semifinished materials in a later step. Therefore, you want the optimizer to ignore any constraint and be able to schedule a successor operation before its predecessor operation, if the predecessor operation is on a resource which was not selected for the optimizer run. This function is activated in the optimization profile in the tab Order Processing with the flag Ignore Upstream Orders. This function only relates to operations from different order which are connected via pegging.

It would be advisable to ignore relationships with upstream orders, either if you are planning final assembly first and are then going to adjust the upstream stages of production accordingly, or if you have not yet planned the upstream stages, which could result in shortages and the generation of an "incorrect" pegging structure to fulfill these shortages. If you would like optimization to consider relationships with orders of upstream stages of production, you should have planned these upstream stages beforehand.

If you select Ignore Upstream Orders, the optimization algorithm does not consider pegging relationships with orders of upstream stages of production/resources during optimization. An order is considered upstream if it has subsequent orders for further processing in the optimization range, and if it meets one of the following conditions:

• The order is scheduling at least one non calendar resource outside of the optimization range.
• The order is not scheduling any resources that have been selected for optimization or is only scheduling calendar resources and is in a pegging relationship with an order on a resource that has been selected for optimization.

If you choose that you want the system to consider upstream orders, optimization considers pegging relationships and time relationships with these orders as fixed and takes these into account as a secondary condition for the orders in the optimization range.

Likewise, you can set the Do Not Consider Subsequent Orders indicator, if you want to ignore subsequent manufacturing levels. This is advisable if you plan production step by step along the material flow. You can thus plan a manufacturing level without the current situation on the subsequent level influencing the result on the current level. If the orders of the subsequent manufacturing levels are not observed, optimization has no information about the due dates that must be kept. If optimization is to keep to these due dates, the subsequent resources must be either planned infinitely or the subsequent orders are deallocated and then optimized together with the current planning step.

The last option that you can select on the Order Processing tab is how you want to deal with orders with begun and confirmed operations. The begun or confirmed operations themselves are considered as fixed by the optimizer. The remaining operations of those orders can be treated in the following ways:

• Schedule normally

  This is the default setting. If you set this indicator, the algorithm schedules the activities still to be planned for orders with started/partially confirmed/finally confirmed activities based on the weightings of the objective function during optimization.

• Schedule with Prioritization

  When you set this indicator, the system schedules orders with started/partially confirmed/finally confirmed activities prior to scheduling all other orders during optimization.

• Schedule with Prioritization, Retain Order Sequence

  When you set this indicator, orders with started, partially, or finally confirmed activities are scheduled during optimization prior to all other orders and the order sequence already specified in confirmed activities will be retained. You should use this option if you want the resource order sequence which was given during confirmation of the first individual order activities to be retained, for example because components have already been procured in this sequence.

On the Resource Processing tab, you can control the DS optimizer options that relate to resources.

The first option is to control how to deal with Non-Selected Calendar Resources. You can decide whether in-house production activities on calendar resources that were not selected for the optimization run are considered fixed or whether these activities can be rescheduled.

If you have scheduled activities on calendar resources (such as times of goods receipts, where you use calendar resources as handling resources) and if these calendar resources have not been selected for the optimization run, the activities can either be moved or not based on this setting. If you have already chosen the calendar resource for optimization using the resource selection, this setting is not relevant. An example is that you have then not selected the calendar resource in the work area of the detailed scheduling planning board, because the goods receipt activities are not planning-relevant for you. Despite this, you want to allow the optimization algorithm to reschedule goods receipt activities to ensure that these activities are moved along together with the corresponding production activities.

The second option, that you have on the Resource Processing tab, is to control how to deal with Non-Selected Secondary Resources. You can decide whether activities on non selected secondary resources are scheduled infinitely or whether these are considered fixed.

You use Infinite Scheduling if you do not have to plan secondary resources as finite or if finite planning for these resources is not necessary until a later planning step. In this way, you can ensure that optimization is not too restricted and can therefore attain better results. If a resource was not selected for optimization, and an activity uses this resource as the primary resource, then the activity is fixed, if the resource is used in the selected mode, or the mode cannot be selected, if the resource is used in a mode that was not selected.

You use Fix Activities and Ignore Non-Selected Modes to protect the planning of a resource from disruption during optimization. The algorithm uses this setting to fix activities that reserve non selected secondary resources in the chosen mode. Non selected modes with non selected secondary resources are not considered during the optimization run.

The settings related to Resource Capacity Load allow you to define whether resources should be considered as finite or infinite and whether finiteness is measured on a time-continuous or bucket level. If you want the DS optimizer to always dispatch activities to resources with a finite capacity load, even if you have not set the Finite Scheduling indicator in the planning parameters of the resource master, you can choose Always Schedule as Finite.

You determine which capacity of the resource is to be used for finite scheduling in PP/DS among the following options:

• Time-continuous Capacity

  If you have set the time-continuous capacity as finite capacity, the algorithm then schedules the resource time-continuous finite.

• Bucket Capacity

  If you have set the bucket capacity as finite capacity, the algorithm then schedules the resource bucket finite.

• As Specified in the Resources

  With this setting, the algorithm checks in the master data of the resource, whether the resource must be scheduled bucket finite or time continuous finite.

This option applies only for those single-activity and multiactivity resources, for which a bucket capacity has been defined.

Typically, you schedule resources as finite or infinite based on what has been defined in the master data. For this, you choose option Schedule According to Master Data Settings. In this case, you can use the finiteness level to control which application schedules the resource finitely and which schedules infinitely.

In the field Finiteness Level on the Resource Processing tab of the optimization profile, you specify the maximum finiteness level up until which the resource is scheduled finitely. This means that if the value is greater or the same as the finiteness level for the resource, the resource is scheduled finitely. Whereas if the value is smaller than the finiteness level of the resource, the resource is scheduled infinitely. If you specify the value 0 as the finiteness level in the optimization profile, the optimizer finitely schedules the finite resources that are either not assigned a finiteness level or that are assigned the level 0 in the resource master data. If you have not set the finite scheduling indicator for a resource, this setting overrules the finiteness level settings and the resource is scheduled infinitely.

In the example, there are three orders (100, 200, and 300). All orders comprise three operations to be scheduled on resources RES1, RES2, and RES3 in this sequence. The finiteness level maintained in the resource master for RES3 is set to 100. If the finiteness level in the optimization profile is defined as 50 (<100), then RES3 is scheduled infinitely. If the finiteness level in the optimization profile is defined as 150 (>100), then RES3 is scheduled finitely.

It is possible to assign different priorities (A–O, Z) for different modes in a production data structure. In the optimization profile on the Resource Processing tab, it can be defined which modes are selected by the optimization algorithm based on the mode priority. The Lowest Mode Priority selection allows you to define up to which mode priority the algorithm can choose among the available modes. For example, if you specify the lowest mode priority C, the algorithm only considers modes with priorities A, B, and C; meaning that it only schedules operations on the resources belonging to these mode priorities. If you do not specify a value for the lowest mode priority, the algorithm considers all modes that can be scheduled automatically (modes with priorities A to O). Modes with mode priority Z can only be selected in manual scheduling (drag&drop) in the detailed scheduling planning board.

For modes that are currently selected with a mode priority that is lower than what has been defined in the selection for the Lowest Mode Priority, you can choose between two options for Lower Priority Modes:

• Choose a different mode

  The algorithm reschedules all operations on higher priority modes. If no higher priority mode has been defined for this operation in the associated production data structure, the algorithm keeps the original mode.

• Retain mode

  The algorithm retains the lower priority modes.

For example, if there are two alternative modes available for an activity: M1 with priority B and M2 with priority D. You have specified C as the Lowest Mode Priority. The activity is scheduled on mode M2 before optimization. If you set that you want to choose a different mode, the algorithm reschedules the activity on M1. If you set that you want Lower Priority Modes to be retained, the algorithm leaves the activity on mode M2. If you set the Lowest Mode Priority to A, the algorithm keeps mode M2 in both instances.

The DS optimizer can consider the time buffer that you have defined in the resource master data for scheduling. This is referred to as resource buffer in the optimization profile. You use the time buffer in ePP/DS as a safety time to protect the resource or the activities processed on the resource from unforeseen delays in material staging. For example, if you have defined an end-start relationship with a minimum interval of one hour between two activities A10 and A20. A10 is processed on the resource R1, and A20 on the resource R2. If you have entered a time buffer of one hour in resource R2, A10 must be completed on R1 not later than two hours before the start of A20 on R2.

You can differentiate if you want to use the resource buffer on pegging relationships (Consider Resource Buffer for Pegging) and/or order-internal relationships (Consider Resource Buffer (Relationships)). In both cases, the buffer time is added to the minimal interval maintained in the production data structure or on the pegging relationship. For both options, you can either use the time buffer always, never, or only on infinite resources.

In the example, there are three orders (100, 200, and 300). All orders comprise three operations to be scheduled on resources RES1, RES2, and RES3 in this sequence. A time buffer of 8 hours has been defined in the resource master for RES2. If the resource buffer was not considered, then the operations on RES2 are scheduled immediately upon completion of their predecessor operations on RES1. If the resource buffer was considered, then the operations on RES2 will be scheduled only 8 hours after completion of their predecessor operations on RES1.

Another option to include a buffer time between two activities is to use planning-related minimum intervals instead of process-related minimum intervals, which are used by default. In order-internal relationship links between two activities, there are two minimum intervals defined based on what you have defined in master data. By selecting Planning-Related Minimum Interval, you choose to use the longer minimum interval for scheduling within the DS optimizer. How process-related minimum intervals and planning-related minimum intervals are derived from master data like wait time or queue time in different scenarios is explained in SAP Note 604878.

Furthermore, you can specify whether you want order-internal relationships to be scheduled by the DS optimizer. Scheduling relationships means that the DS optimizer checks the calendar of the relevant activity for availability. A prerequisite for using this capability is, that you have defined in the production data structure, that a relationship link is to be scheduled and whether the calendar of the resource, that defines the start of the relationship link (predecessor resource), or the calendar of the resource that defines the end of the relationship link (successor resource) is relevant for scheduling. You have the following options:

• The algorithm is to always schedule these relationships: The DS optimizer is to include the availability of the relevant resource when it calculates the minimum and maximum intervals between the activities connected by these relationships.
• The algorithm does never schedule these relationships.
• The algorithm only schedules relationships on resources that are planned infinitely.

Finally, you can define on the Resource Processing tab, how the DS optimizer is to take resource networks into account. Resource networks describe the physical links between resources in a plant such as processing units, vessels, packaging lines. A resource network depicts the flow of materials through a plant. They basically represent transport possibilities to move products produced on one resource to another resource where it is consumed.

The objective for the use of resource networks is to model restrictions of the flow of product through the plant based on the physical abilities to connect resources and to reduce the number of master data permutations in production data structures by eliminating the need for mode coupling.

You can influence the behavior with two parameters. First, you have to decide whether resource networks are considered at all using Consider Resource Networks. You can choose between the following options:

• Ignore

  Resource networks are not considered.

• Order internal only

  Resource network connections are only considered order-internally.

• Cross order only

  Resource network connections are only considered between orders, that is on pegging links.

• Always

  Resource network connections are always (order-internally and between orders) considered.

In a resource network, you can assign a priority to each connection. The second parameter Lowest Resource Network Priority defines the lowest priority of the resource network connections that the optimization algorithm can use. If you do not specify a value for the lowest resource network priority, the algorithm considers all resource network connections that can be scheduled automatically (priorities A to O).

The alternative way to allow only specific combinations of alternative modes for consecutive operations within an order is the use of mode coupling as an attribute of the internal relationship link. This typically requires to create many permutations in the production data structure, whereas resource networks are much easier to define.

Imagine there are multiple operations in a row, with different resources, and you want to define a specific linkage. It is required to define the mode linkage as identical mode number (type 3) in the source of supply. However, as long as each resource is listed as its own mode, within its operation, and you define the mode linkage without restriction (type 0), no permutations are required. By creating the resource network master data and establishing links there instead, this creates the valid possibilities of material flow along resources. A key feature is that a resource network can be assigned to many products at once so the linkages are done in one place instead of every source of supply.

For example, if there are three operations in an order. The first operation has two alternative modes A1 and A2. The second operation has four alternative modes B1, B2, B3, and B4. Finally, the third operation has three alternative modes C1, C2, and C3. The allowed connections are indicated by arrows in the graph. When using resource networks, two modes are required for the first operation, four for the second operation and three for the third operation. The allowed connection is defined by the resource network. If mode coupling was used, 12 modes must be defined for each operation to express the same constraint.

The optimization scope for DS optimization is defined by the resource selection and the optimization horizon.

You can maintain the start of the optimization horizon, end of optimization horizon, and start of the optimized plan. The start and end of the horizon define the selection period. All activities within this period are eligible for optimization. They are planned no earlier than the start of the optimized plan.

For all dates (start of optimization horizon, end of optimization horizon, and start of optimized plan) you can specify the number of months/weeks/days/hours to define the date regarding the start of the current month/week/day/hour and relative to the start date of the optimization run:

• If you enter a positive value N, the date is the start of the month/week/day/hour, N months/weeks/days/hours after the start date of the optimization run. Example: If you enter 2 for Start of Month and start the optimization run on 06/21/2026 at 12:00:00, the date is 08/01/2026 at 0:00:00 (start of the second month after the current date).
• If you enter a negative value -N, the date is the start of the month/week/day/hour, N months/weeks/days/hours before the start date of the optimization run. Example: If you enter -1 for Start of Day and start the optimization run on 06/21/2025 at 12:00:00, the date is 06/21/2025 at 0:00:00 (start of the current month before the current date).
• If you do not enter a value or enter 0, the start date is the start date of the optimization run. Example: If you enter 0 for Hours and the start of the optimization run is on 06/21/2025 at 12:00:00, the date is 06/21/2025 at 12:00:00.

To simulate your entries, you can choose the Check function. The system uses your entries to determine the start and end dates/times of the optimization horizon and the start of the optimized plan and displays this data in the check area.

The following figure illustrates, which activities are rescheduled by the DS optimizer based on your resource selection and the horizon defined in the optimization profile.

When you call up optimization, you set the optimization horizon (start and end) and the start date for the optimized schedule. The second dimension relevant for optimization is the set of selected resources. The optimization function reschedules orders and operations that are completely within the optimization horizon (defined by a start and an end date) and not fixed and that are assigned to a selected resource. If you plan interactively in the detailed scheduling planning board and have selected a subset of displayed resources, only these selected resources are transferred to the optimizer. If you have not selected any resources in the detailed scheduling planning board, the system transfers the resources that you specified in the work area for the detailed scheduling planning board to the optimizer. In particular, the system can only reschedule an activity to alternative resources during optimization when these resources are included in the resource selection for optimization. The system does not change anything outside of the optimization window during planning. Activities outside of the optimization window are fixed during optimization. However, the fixed activities determine by their relationships to the non fixed activities in the optimization range, whether and how far these activities can be rescheduled during optimization. The optimized schedule is, therefore, adjusted to accommodate the fixed activities.

The planning time fence is not relevant for the DS optimizer. The DS optimizer ignores the planning time fence, that is, the DS optimizer can also change the planning within the planning time fence if this falls into the optimization horizon. A suitable optimization horizon must selected so that the optimizer does not reschedule orders that appear within the planning time fence. In this case, the optimization horizon should first start outside the planning time fence or coincide with the limits of the planning time fence. In this way, orders that appear in the (earlier) planning time fence, are not scheduled by optimization. Suitable settings should be made in the optimization profile for orders that overlap with the optimization horizon. If planning time fences of varying length are defined for different products, the previously mentioned adjustment to the optimization horizon is not possible since this cannot be defined on a product level. In this case, you should (manually) fix the orders for products with longer planning time fences before the optimization run.

The settings on the Costs tab of the optimization profile allow you to refine the costs as they are used based on the weights of the objective function in the Basic Settings tab. You can define delay costs and mode costs in a more granular fashion using the Costs tab.

The delay costs are calculated as the duration of the delay (the difference between the receipt date and the requirement date) multiplied by a cost factor depending on the priority of the order. That way, you can put more emphasis on not-delaying high-priority orders compared to orders with a lower priority.

You can define a maximum of six successive priority intervals between 1 (highest priority) and 255 (lowest priority). By specifying the order priorities 3, 6, 9, 12, and 15, for example, you define the following priority intervals:

• Order priority from 1 to 3
• Order priority from 4 to 6
• Order priority from 7 to 9
• Order priority from 10 to 12
• Order priority from 13 to 15

In this case, the sixth priority interval is automatically the interval 16 to 255. The delay costs you specify for an order priority are therefore valid for all orders that lie within the interval and that have a priority. You define the penalty costs on an interval basis for a maximum of six successive priority intervals, where the costs that have a decreasing priority (increasing priority value) must decrease or remain the same. If you do not specify any values for the costs, the optimizer uses the default value 1 for all order priorities. The same is true for orders that have no priority or a priority of 0.

There exist different ways to obtain the order priority. The order priority can be defined either by the sales order or by the location product. In Model and Version Management, you specify where an order acquires its priority, depending on the planning version.

The second cost component that you can influence on the Costs tab are mode costs. You define the priority-dependent mode costs on an interval basis for a maximum of 11 successive priority intervals, where the costs with decreasing priority must increase or remain the same. The system uses the priority-dependent fixed and variable mode costs, and the length of the activity to calculate the mode costs.

A prerequisite for using this cost element is that you have assigned mode priorities to operations. You can assign an activity to different modes, which means different primary resources on which the activity can be carried out. These alternatives are not usually of the same value. For example, the capacity of a fast, costly special machine should be used before the slower, less costly, replacement machine.

Thus, you assign priorities to the modes (that is, the alternative resources) in master data. The system schedules these alternatives according to these priorities. A mode with priority A has the highest priority, a mode with priority B has the next highest priority (and so on, up to priority O). You can assign priority Z to a mode when you want to schedule the respective resource only manually in the detailed scheduling planning board. You manually schedule resources that you want to use only in exceptional cases for production, for test or training machines, for example.

For example, if you specify the following costs: 10 up to mode priority D, 20 up to mode priority H, 40 up to mode priority L, and 80 thereafter, the mode costs are as follows:

• 10 for activities that are scheduled in modes with priority A to D
• 20 for activities that are scheduled in modes with priority E to H
• 40 for activities that are scheduled in modes with priority I to L
• 80 for activities that are scheduled in modes with M to O

To reduce the costs for an activity, the DS optimizer can choose a mode with lower costs for the activity during optimization. That is, it reschedules the activity to an alternative primary resource with lower mode costs.

On the Additional Strategies tab, you can parametrize options that you have selected on the Basic Settings tab. For the Backwards Scheduling option, you can choose to not increase makespan and for the Deallocate option, you can define a threshold from which delayed operations are to be deallocated and whether successor operations of deallocated operations are also to be deallocated.

In addition, you can define on the Additional Strategies tab whether and how to use decomposition.

You can use time decomposition to decompose the overall planning problem according to time intervals. You can define whether time decomposition should be used (On - User-Defined) or not (Off). You can also let the algorithm decide automatically (On - Automatic).

If you choose On - User-Defined, you must define the threshold for which problem size you want to use decomposition and you can define the window size. Start of Decomposition specifies the number of activities that you want to use as the threshold for time decomposition. Once this number is reached, the algorithm uses decomposition when running optimization. During decomposition, the algorithm divides the optimization range into individual overlapping subproblems (windows) and solves the problem in intervals. If the optimization problem contains fewer activities than this threshold value specified, the DS optimizer attempts to solve the entire problem in one go. Window Size (size of the subproblems) defines how many activities you want the algorithm to group into each subproblem (window).

The second decomposition approach is bottleneck optimization. For this, you define a resource as a bottleneck resource, by setting the Bottleneck Resource indicator during work center maintenance.

If you select bottleneck optimization, the algorithm runs a bottleneck optimization during optimization. This approach follows the theory of constraints, that optimization is only required on the bottleneck resource. The first subproblem would then be the scheduling of orders only on the bottleneck resource(s). The order sequence on the bottleneck resource(s) would afterward be fixed and the second subproblem would solve the scheduling of all resources, taking the sequence of the bottleneck resource(s) as an additional constraint into account. The first step (optimization of the bottleneck resource(s) takes a separate objective function into account. The weights for this objective function are defined on the Additional Strategies tab. The objective criteria that can be weighted include delay costs, storage costs, mode costs, setup costs, and set up times. This step creates an optimum sequence for orders that are being processed at the same bottleneck resource. The algorithm then adjusts the order sequences at the other resources to the optimized sequenced at the bottleneck resource.

Bottleneck optimization is only possible if the following prerequisites are met:

• The orders to be optimized are only allowed to have one operation at the bottleneck resource that is to be processed as a primary resource.
• If you are working with alternative modes, all the possible alternative primary resources must be bottleneck resources.
• Resource selection must contain all the alternative bottleneck resources and also all the non bottleneck resources from the same production level.
• No other bottleneck resources can be included within the resource selection.

Direct or indirect relationships between operations on bottleneck resources are not allowed in the optimization run.

A production campaign is a series of production processes (batches) in an optimal sequence, within a certain defined start and end, in an uninterrupted sequence on a dedicated production line. Each batch is corresponding to an order. So, the production campaign is a collection of planned orders and/or process orders. Each order is either a member of one campaign or none. Single and multiproduct campaigns are supported.

Prerequisites for campaign planning are the definition of bottleneck resources and that the orders to be optimized contain only one operation that is processed at a bottleneck resource. The optimization process for campaign planning involves two steps:

1. Creating new campaigns on the bottleneck resource (while operations at the non bottleneck resources are scheduled infinitely)
2. Optimization of the overall schedule considering the non bottleneck resources (normal PP/DS optimizer run, but keeping the sequence on the bottleneck resources fixed)

Before campaign optimization is started, the system automatically deletes setup/clean-out orders within the optimization horizon. Each order is not allowed to have more than one operation with a bottleneck resource. On each production level, one bottleneck resource can be defined by activating the respective check box in the resource master data. Alternative resources for processing this operation must also be bottleneck resources, that is, all modes for the operation must have a bottleneck resource as the primary resource. The complete set of alternative bottleneck resources must be contained in the resource selection for the optimization. No other bottleneck resources are allowed in the resource selection. The campaign profile has to be defined in Customizing. The minimal campaign size is always one batch. The maximal campaign size is defined in the campaign profile. The setup matrix is extended by an additional setup PDS, to be able to build a separate setup/cleaning order for the campaign.

For campaign optimization, the optimizer uses the same specific objective function as for bottleneck optimization. What happens to existing campaigns during campaign optimization is defined in the setting for Processing of Existing Campaigns. Options are:

• Dissolve

  The system dissolves the campaigns before optimization and generates new campaigns during optimization.

  Example: (A A A) B (A) B --> (A A) (B B) (A A)

  A and B represent orders for products A and B, while the orders in parentheses represent a campaign.

• Retain

  The system can shift existing campaigns, but is not allowed to make any other changes. It cannot delete orders from campaigns, add new orders to campaigns, or reschedule campaigns on alternative bottleneck resources.

  Example: (A A A) B (A) B --> (A A A) (A) (B B)

• Extend

  The system can add orders to existing campaigns and shift these campaigns. It cannot delete orders from the campaigns, or reschedule campaigns on alternative resources.

  Example: (A A A) B A B --> (A A A A) (B B)

On the Expert Settings tab, you can define how you want to distribute the runtime of the optimization algorithm among the different phases of the optimization algorithm. You can define the percentages of the overall optimization runtime that should be used for campaign optimization, the calculation of the initial solution of the genetic algorithm, the improvement phase of the genetic algorithm, and the backward scheduling logic.

If you choose Automatic, the runtime is distributed as follows:

The Consider Minimum Runtime option allows you to define an additional termination criteria other than the Maximum Runtime limit that you have defined on the Basic Settings tab. Typically, the DS optimizer uses the maximum runtime. If you define also a minimum runtime and choose this option, the DS optimizer will already terminate, if the minimum runtime has elapsed and a solution has been found. If no solution has been found within the minimum runtime, the algorithm continues until the first solution has been found or the maximum runtime has been reached.

Since the genetic algorithm is well suited for parallelization, you can choose to run the algorithm with multiple parallel processes. You can define the Maximum Number of Parallel Processes that are to be started for the optimization run on the Expert Settings tab. The system uses the maximum number specified if enough slots are available in the load balancing of the Remote Control and Communication Framework (RCCF). If enough slots are not available, the system reduces the number to the number of free slots.

The Maximum Number of Identical Messages allows you to control how many messages of the same type are written to the optimization log. The default value is 10. Furthermore, you can control what information is written to the explanation log of the DS optimizer. In the explanation log, you can display explanations about the optimization results to better understand and evaluate these results. You must have set the Explain Result indicator on the Expert Settings tab page in the optimization profile for the system to create an explanation log after the optimization run. To display the rescheduled activities and the solutions found in the explanation log, you must also set the Log Result and Log Interim Solution. The following information is then displayed after the optimization run:

• Delays: On this tab page, you can view the orders that are delayed. The system also displays the duration of the delay, the missing product quantity, and resources or components that caused the delay.
• Fixings: On this tab page, you can view the fixed activities. The fixing reasons are also specified.
• Deallocations: On this tab page, you can view the activities that were deallocated in the optimization run. The causes that led to the activity deallocation are also specified.
• Reschedulings: On this tab page, you can view the activities that were rescheduled in the optimization run.
• Solutions: On this tab page, you can view information about the quality of the solution found, such as the duration, the makespan, and the total setup times.

On the Expert Settings tab, you have the option to influence the planning result by fixing either the mode selection or the sequence of a specific set of resources. Then, you can fix the currently assigned modes on single-activity resources, and/or multiactivity resources and/or bottleneck resources and/or container resources. This means that only the sequence and start time of activities can be changed, but not their mode. Likewise, the sequence fixation fixes the sequence of activities on single-activity resources, and/or multiactivity resources and/or bottleneck resources and/or container resources. This means that only the start time can be changed, but not their mode or their sequence.

Pegging information is an important input parameter for DS optimization. The pegging link between a planned order and its requirement object (for example, a sales order) defines the date that is targeted by the DS optimizer. If there was no pegging link, the optimizer would not know when to schedule the planned order and can only use the end of the optimization horizon as a substitute. To avoid missing pegging links, you can define a Maximum Delay Allowed by Backward Pegging (in hours). This field overrides the product-specific, maximum allowable delay defined in the material master for creating a dynamic pegging relationship. At the beginning of the optimization run, the algorithm recreates pegging by creating new dynamic pegging relationships between the receipt element and the requirements element in the optimization horizon. The algorithm can also create backward-looking pegging relationships where the receipt element is delayed in relation to the requirements element. The newly created dynamic pegging relationships are only relevant for optimization. These pegging relationships are the starting point for optimization. This pegging step is executed in LC and provided as input to the optimization algorithm.

In general, pegging with continuous material flow is supported by the DS optimizer. If you choose Consider Exact Continuous Material Flow, the algorithm performs an exact allocation of the continuously produced and consumed quantities. Regarding the activities which are connected with continuous material flow (pegging), the DS optimizer can achieve the greatest possible degree of overlap for these activities. If you do not select Consider Exact Continuous Material Flow, the algorithm does not perform an exact allocation of the continuously produced and consumed quantities, but performs a simplified computation of material flow. Depending on the duration of the involved activities, an alignment on starting times (end times respectively) takes place. This alignment leads to very good results in the case of 1:1 pegging. In the case of 1:n, n:1 or n:m pegging, the algorithm cannot achieve all possible overlaps without this option.

The exact computation of continuous material flow is performance-critical. Therefore, use this function only if necessary. Alternatively, model as few input or output components with continuous consumption as possible.

Exact computation of continuous material flow cannot be combined with campaign optimization on bottleneck resources. If there are already existing campaigns in the optimization scenario which must be respected, the algorithm tries to achieve the non interruption of campaigns, but cannot guarantee it. Violations of the non interruption of campaigns are not reported during optimization. Furthermore, the decomposition functionality is automatically deactivated if you activate the exact computation of continuous material flow. For more information and more restrictions, see SAP Note 1533835.

The capacity change function allows you to change the capacity of multiactivity resources within the optimization horizon starting with the start of the optimized plan. For example, you can use this functionality to reduce the capacity of a resource in the future to keep some capacities for unexpected spot orders. On the other hand, you can also increase the capacity, if you want to overplan your resources, because you are expecting order cancellations.

You can define multiple periods with different capacity according to the following logic:

• Period Number

  You can define any number of periods for the multiactivity resource. The periods have consecutive numbers with no gaps. The period with the lowest number starts at the beginning of the optimized plan. The period with the next highest number follows immediately after the first period, and so on. The valid capacity outside of the time period defined by the periods is the capacity defined in the multiactivity resource (corresponding to a capacity of 100%).

• Period Duration (in hours)

  Period duration to which a changed capacity for the multiactivity resource should apply.

• Capacity of multiactivity resource in percent

  Capacity in percent of the multiactivity resource in the given period, in relation to the 100% capacity that is defined for the multiactivity resource in master data. During optimization, the system loads the multiactivity resource up to the maximum given percent value. You can enter values over or under 100%. When you enter 50%, for example, the system loads the multiactivity resource by up to 50% during optimization; that is, it schedules two machines instead of four.

By defining reduced capacities for the optimization, you reserve capacity in the optimized schedule; for example, for last-minute special orders. By defining capacities over 100% for the optimization, you can create overload periods in the optimized schedule.

The example shows a multiactivity resource with 10 capacities. These must be reduced to nine in the first 24 hours. They must be increased to 15 in the subsequent 12 hours and reduced to eight in the next 48 hours. In the remainder of the horizon, the standard capacity of 10 must be planned for.