Modeling Tips and Tricks

Planning problems can be easier or more difficult to solve for the DS Optimizer depending on how they are modeled. The following lesson provides some best practices on how to define planning problems and what to avoid. Note that these are recommendations only, and sometimes a constraint must be defined, because it characterizes the planning problem, and is not only a nice to have feature. Then, the constraint must be defined in the planning data.

Constraints should be modeled in the system whenever they represent technical constraints for production. For all other constraints, an in-detail investigation is recommended to clarify the need for them. In general, a planning system like PP/DS needs a higher degree of master accuracy than a transaction system.

Routings or recipes must be consistent. That means, the internal relationship links that connect the different operations with their attributes (FS=Finish-Start; FF=Finish-Finish) and minimum or maximum durations should be defined in such a way that there exists a feasible solution.

Inconsistent constraints defined in master data are identified by the DS Optimizer. If there are relationship links that contradict each other, then the planning problem is infeasible. The DS Optimizer has an internal logic to repair such contradictions/inconsistencies. However, it can only guess what can be wrong and it is recommended to address the root cause in these situations and correct the underlying master data.

The decision to use either alternative modes or alternative production versions (sources of supply) influence the selection of planning algorithms. In general, it is recommended to use alternative modes instead of alternative production versions. Whether you use alternative modes or alternative production versions (PDSs) influences the selection of planning procedures.

The DS Optimizer can only switch between alternative resources, if they are represented as alternative modes in the PDS. If alternative production versions are used, the decision for the production resource is done before DS optimization. If you want to optimize across resources, then model all alternative resources which can be used for a production activity as alternative modes in one PDS. Use mode priority Z for resources which should be scheduled manually by the planner. If DS optimization should be done resource by resource and already planned orders should not change the resource, then alternative PDS (that is alternative production versions) can be used also.

BOM levels impose more constraints in planning, but they also allow more freedom for decoupled planning. A detailed investigation of the correct BOM level is recommended.

From DS optimization perspective, there is however no significant difference on whether, for example, five operations belong to the same order and are linked via order-internal relationship links, or whether there are five operations belonging to five different orders and they are connected in the same way via pegging links. As long as there is 1:1 pegging, both planning situations are more or less equivalent. However, if the pegging situation changes to a 1:N, N:1, or even N:M pegging, the planning using different BOM levels become significantly more complex.

You should model maximum relationships between activities only when there are technical or business constraints. Do not model maximum time distance between activities for non technical reasons like "have to ensure material flow" or "want to reduce lead times". The DS Optimizer takes care of that and you will only complicate its task if you add more constraints that do not exist in reality.

In PDS (production data structures), you should not maintain any relationship to the start time of a sequence-dependent setup activity. If you want to maintain activity relationships, you should only do so at the finish time of the sequence-dependent setup activity (or at the start time of the corresponding produce activity.

If you have defined the relationship link pointing to the start of a sequence-dependent setup activity, two orders can be scheduled like in the first chart. If the DS Optimizer would try to insert another order in between the two, this would create a violation of the relationship link of the last order, if the duration of the setup time was increased by this insertion. The same does not happen if the relationship link is pointing to the end of the sequence-dependent setup activity or to the start of the produce activity. Thus, the latter option makes planning for the DS Optimizer much easier.

Pegging links and time constraints crossing the selection (optimization horizon and/or selected resources) yield time constraints for the orders and operations that are within the optimization scope. An operation cannot be scheduled earlier than its (fixed) predecessor outside of the optimization scope.

Therefore, if you select narrowly, these constraints can block operations from being moved by the DS Optimizer.

Pegging establishes a link between the receipt and requirement elements of a product. There are two different types of pegging relationships: fixed and dynamic. Fixed pegging enables you to fix a pegging relationship, that is, the pegging relationship will not be changed automatically by the system during planning. You can fix a particular quantity of a product receipt (manually or with heuristics) to a specific requirement.

The system creates a pegging network of orders linked to one another, which represents the relationships between the receipt and requirement elements of a BOM structure. Pegging links represent hard constraints for the optimizer. If the pegging structure is inconsistent itself, the optimizer will not find a solution. You can control the creation of pegging links using the parameters in the material master of by using heuristics to fix or unfix pegging.

Since pegging links are constraints for the optimizer, because they propagate for example the information when a component becomes available to produce a finished product, a simple FIFO pegging structure makes planning a lot easier as complex N:M pegging.

The pegging information from LiveCache (LC) is provided as an input to the optimization process. There is no difference to the optimization process whether the pegging is dynamic of fixed. However, there can be a huge impact on the interpretation of the optimization result depending on whether the pegging was fixed or is created dynamically in LC. Note that the DS Optimizer does not change any pegging. Only LC changes the pegging.

Assume that there are two customer requirements, the earlier one with priority 2 and the later one with priority 1. Both are pegged to a corresponding order to meet the requirement. The result of DS optimization may be to change the sequence of the orders to fulfill the customer requirement with priority 1 on time and delay the fulfillment of the order for the customer requirement with priority 2. This is more optimal than delaying the fulfillment of the customer requirement with priority 1. However, with dynamic pegging, the pegging links are adjusted, such that the earlier order also meets the earlier requirement, not considering the priority. Whereas the planning result can be identical in both situations, its interpretation becomes more difficult, because the user does not see the same pegging in the result, than what was used to retrieve the result.

Missing pegging can lead to infeasible plans. If an input node of an order is not pegged to a predecessor order, the DS Optimizer does not have any information to when the order can start, because this information cannot be propagated from the (non existing) predecessor order. Thus, the order can be scheduled at a time when the component is not available.

Maximum pegging links (shelf life) lead to similar effects like the usage of maximum relationship links as explained before. Therefore, they are difficult to optimize and should be avoided if possible. The FIFO pegging strategy typically creates easier pegging networks for optimization.

If you must run several optimization runs, you should schedule them with some time in between to avoid peak load on the application server and LC.

Technically, when you run the DS Optimizer, in the first phase, most of the server load is on the application server/LC side, because this is where all the data relevant for optimization must be collected and send to the optimization server. Once all data is present on the optimization server, the complete load is on the optimization server and no load on the application server/LC. Once the optimization algorithm has completed its calculation and generation of explanations, the result data is transferred back to the application and LC. Thus, if you must run several DS optimization runs in parallel (for example for different plants), you should do so in a staggered approach, such that the load on the application server and LC for data collection happens sequentially on the application server and not in parallel.

Testing of finite planning with a full data load is important. The behavior of a constraint system with partial data load differs totally(!) from the system behavior with full data load.

Think about whether seasonal adaptation of parameters during the business year is required. Test the maximum capacity load which can occur during your business year. Consider seasonal variations. A 90%-test is typically not sufficient.

Block Planning is the planning or preassignment of resource capacities for products with specific attributes, with the purpose of using the capacities more rationally. The attributes are described using characteristics from the SAP system. In block planning, you define blocks on a resource that have a specific duration and attributes, for example, a duration of two days per block on which you manufacture products in various colors.

In some industrial sectors, such as the metal and paper industry (piece-oriented production), the planning of orders and operations for various plants/resources/work centers is not solely based on available capacity and the sequence and priority of deadlines. Upstream planning is more often used to define which type of products and which attributes are to be produced in a plant. This is mainly because processing these grouped products requires the plant to be set up in the same way. Changing the setup incurs high costs in terms of time and money. Set sequences of products or regular maintenance periods at set intervals also play a role, especially in block duration.

The DS Optimizer supports block planning. Block planning scenarios are common in the paper/glass/steel industries. Reservation of blocks on resources requires preplanning of resources for products with defined characteristics. Blocks are hard constraints for the optimizer. The assignment of orders to a block and the sequence within the blocks is determined with a normal PP/DS optimization run. No additional settings are required.

In the planning scenario Order Confirmation after Optimization, customer orders are taken unconfirmed. Existing customer orders and assigned production should not be delayed by new orders. This is managed by fixing the pegging. During the night, an MRP run generates orders and after the optimizer schedules the orders such that delays are minimized. At the next day, customer orders are confirmed. Their priority is increased and their pegging (to production orders) is fixed. Using different priorities for confirmed and unconfirmed orders, different costs can be assigned to delays (in the optimization profile). Therefore, already confirmed customer orders should keep their date, while new orders are scheduled using the remaining capacity.

The planning logic is illustrated with the next two diagrams.

The existing production is pegged (fix) against customer orders and procured material to guarantee feasibility. (This has been the result of the preceding planning run.) Customer orders are taken in SD without immediate confirmation. An infinite MRP run generates production and procurement orders for the newly arrived customer orders. These are still infinitely planned and pegged dynamically.

To ensure that the new orders are procured correctly, their pegging is fixed. This is done by a heuristic after the MRP run. The DS Optimizer solves the remaining planning problems (for example capacity overload due to infinite MRP run). In the DS Optimizer, run different priorities and priority costs are used for existing and new orders. Existing orders are assigned a higher priority, because these should keep their confirmed dates, whereas new orders are planned with lower priority to fill them in when possible close to their desired date. The fixed pegging ensures that the existing planning situation is kept stable. Using back order processing, confirmation dates are assigned to the new customer orders.