Tag Archives: Optimization

Running the Optimizer for a Single Location Versus the Sub-Problem

Posted on by

Background

One very interesting question is whether the SNP optimizer should be run interactively. Companies that migrate to cost optimization do so most frequently from MRP or from supply planning heuristics. However both of these methods can be run interactively, without negatively affecting the rest of the product locations. However, cost optimization works differently. The CPLEX optimizer within SNP divides the overall supply network problem into a series of sub-problems, in a process called decomposition. Decomposition is explained at this link below:

http://www.scmfocus.com/sapplanning/2011/10/12/snp-optimizer-sub-problem-division-and-decomposition/

SNP allows the interactive running of the optimizer from within the product location combination. This can be activated by selecting the Optimizer button within the planning book as can be seen below.

SAP documentation is lacking in this area, however, there seems to be a flaw in the interactive design. This is because an optimizer should never be run for a single product location combination but should follow the exact decomposition that is setup in the SNP Optimization Profile. However, the message log below shows that only one location is brought into the optimizer’s memory for processing. This means that the sub-problem for this product is not being respected. 

This is not a production facility, and there are therefore no production costs. In fact the costs are quite limited with the vast majority of costs only being storage, this is simply a recalculation of the storage costs that were calculated during the past optimization planning run.

The optimizer cannot in effect do anything because no transportation lanes are included in the optimization run, which means that it is not interacting with the other locations. However, for a supply plan to make any sense, a location must interact with different locations. Therefore, running the optimizer in this way is illogical, so it is difficult to see why it is an option. What SNP should do is perform the optimization for the location sub-network that is part of the decomposition which is in the SNP Optimization Profile. That is what is assigned to the interactive optimization run above, so why does it not go off what the Optimizer Profile is telling it to. Instead, it forces the planner to add all of the locations that are part of the sub-network in order to perform the optimization correctly. However, what if they miss one? The optimizer could produce a poor result because of just one missing location. This is not a user friendly form of interactive optimization. Simple mistakes like this, which would have been caught by a person experienced in how interactive modeling is performed in real life, were entirely missed by SAP development, and have never been corrected.

http://www.scmfocus.com/sapplanning/2011/10/12/using-an-external-system-to-check-optimization-results/

Best of breed supply planning applications are simply far ahead of SAP SNP, which is why I question the sanity of going forward with an exclusive SNP solution for simulation, and its not only in supply planning. PP/DS is also completely uncompetitive when it comes to simulation as this post describes.

http://www.scmfocus.com/productionplanningandscheduling/2011/01/20/simulation-in-ppds-vs-planettogether/

I can’t wait for my next conversation with an SAP consultant to tell me that the problems with SAP are mostly due to ineffective user training. However, I know that somewhere this week some senior manager or partner at a large consulting company like IBM or Accenture will tell some prospect about how great SAP is in simulation. The partner could care less and will say anything for cash. However, this is one reason why SAP never has to improve its simulation capability, but can just continue to develop new products without fixing the older ones. This is because they know no matter how bad their functionality, the big consulting firms will always have their back.

Conclusion

Running the optimizer interactively for a single product location is an completely illogical way of performing optimization, and this is only necessary because when performing interactive optimization. SNP is strangely not respecting the sub-problems as setup in the SNP Optimization Profile. SAP could have made it easy to perform optimization interactively, but didn’t. This is a serious problem, because typically, there is only enough time to run the network optimizer once per week, and an interactive optimizer would be a great addition. In fact, there are companies that have developed entire workarounds because SNP cannot do this simple function.

If the planner desires to perform optimization on the fly, it can be done, but the planners must enter all the locations that are part of the product’s sub-network must be included in the planning book, and only then should the optimizer be run. It is unfortunate that SAP does not automatically perform the optimization for the entire sub-network for any product which is a part of the sub-network, rather than breaking the sub-network relationships and simply processing for one location.

Diagnosing the Reasons for Over Ordering with the SNP Cost Optimizer

Posted on by

Background

One generally thinks of supply planning inaccuracy in terms of both equally distributing over and under ordering .However, on several occasions I have witnessed SNP both under and over-order. This is most common when either the CTM or the cost optimizer is used. Its rare for much in the way of comprehensive diagnostics to be run on SNP, and the way that companies generally find out about is when planners complain about the results. I have analyzed the overall system results and found over ordering as high as 50% with the cost optimizer. Actually, considering how most companies set their costs of unfulfilled demand so high in comparison to other costs, I am surprised it is not higher. (See the problems that companies have in setting costs appropriately in cost optimizers in the post below):

http://www.scmfocus.com/inventoryoptimizationmultiechelon/2011/05/how-costs-are-really-set-in-cost-optimization-implementations/

Disproportionate cost setting can be one reason for consistent over or under ordering. However, there are other reasons. This can be learned from analyzing the supply planning output. For instance, the graph below demonstrates overages that are not really driven by excessive unfulfilled demand penalty costs. The reason for this is that the overages are not high across the board, but only in minority of cases.


Over Ordering in R/3 or SNP?

When facing this issue, some people may think about the interaction with R/3 and question whether R/3 is partially responsible for the over ordering. Of course, when two systems can create orders, it makes the diagnostic of which is the guilty systems more complex. However, SNP does not convert and then rename R/3 generated Purchase Requisitions to SNP Purchase Requisitions. The same is true of SNP Planned (production) Orders. The reason SNP is set this up this way is so that there is trace-ability as to what system generated what recommendation. Pre-existing R/3 Purchase Requisitions do affect SNP, in that they reduce the size of or in some cases (that is when operating correctly), eliminate SNP generated purchase requisitions. That is the summation of the relationship between SNP generated purchase requisitions and R/3 (MRP) generated purchase requisitions. Therefore when an SNP Purchase Requisitions is viewed in the planning book, the viewer can be certain that the purchase requisitions were generated by SNP.

Therefore, the issue with high SNP ordering is not because purchase requisitions were created in R/3 and were then adjusted in SNP. Purchase requisitions created in R/3 have a specific order category and any previous R/3 or SNP generated purchase requisitions are used to make future SNP Purchase Order recommendations. R/3 cannot force SNP to make bad decisions, unless it sends inaccurate data such as the stock on hand.

When in the Time Horizon does Over Ordering Occur?

Another important clue to what is causing over ordering is when in the planning horizon the over-ordering is occurring. This is particularly important for cost optimization, because cost optimization is often run with a series of different decompositions, or divisions of the overall supply network problem. (to read more about decomposition, see this post below)

http://www.scmfocus.com/sapplanning/2011/10/12/snp-optimizer-sub-problem-division-and-decomposition/

Decomposition with respect to time means that the problem is not processed by the CPLEX optimizer (its important to refer to CPLEX because CPLEX’s makes the optimizer SAP uses — SAP makes no optimizer, and CPLEX’s documentation is better than SAP’s and its useful to know CPLEX when the optimizer is not SAP as CPLEX is used as the optimizers by many supply chain applications.) all in one horizon. With time decomposition enabled, the optimizer processes earlier segments of the time horizon first. Sub-problems are given a maximum runtime (a subproblem being normally a single product-location subnetwork – see the link above for more details). After they reach the max runtime, the problem is no longer processed, and the end state is whatever the optimizer was able to get through. In some circumstances the sub-problem solves optimally, but sometimes it does not. On those that did not solve optimally, the later periods in the time horizon will be a lower quality solution than the earlier periods as the later periods were less processed, or not processed at all. This can be demonstrated by taking a sample of the over ordered products and checking to see if a majority of them did not solve optimally. If a high number of the product sub-problem did not solve optimally, there is a good chance that this is the problem, and then discussions can commence on making adjustments such as enlarging the processing time window buy adjusting the operational workflow, or the easiest and often least expensive alternative, adding more hardware.

Conclusion

There are a number of reasons for over ordering in any optimizer, including SNP. This article has described several things to look for which can lead one to determine the route cause. Once the route cause is determined, the solutions become obvious. While the current practice seems to be let the planners find the problems with the solution, this is not a very good practice. Diagnostics of the type I described in this article should be run right off the bat when the optimizer is first being tested. Planner input is valuable, but the overall system must be diagnosed in aggregate to determine if the solution is a good one.


How Soft Constraints Work with Soft Constraints Days’ Supply and Safety Stock Penalty Costs

Posted on by

Background

The topic of the use of days’ supply in a cost optimizer like the SNP optimizer is an interesting one. We begin by looking at what SAP has to say on this topic.

You can also use safety stock for static days’ supply planning with the SNP optimizer. When using static days’ supply planning, it should be ensured that there is at all times at least as much on-hand stock of a product as is required within the days’ supply horizon.

To do this, define a safety stock method for the appropriate product on the Lot Size tab page in the location product master (SZ, MZ, SM,or MM) and enter either a safety days’ supply that is not period-dependent in the location product master or a safety days’ supply that is period-dependent in the interactive planning table. Note that for safety stock methods SM and MM, the SNP optimizer only considers independent requirements as well as dependent and distributed demands caused by fixed orders, since these demands and the demand locations are already known before the optimization run.

The optimizer uses the days’ supply planning results as a basis for creating the safety stock. – SAP Help

The codes that SAP is referring to is the safety stock method that is being used. SAP is using this term, but it is not the “method” as generally understood in supply planning generally, where it for instance states whether the safety stock is dynamically calculated. Instead, when SAP states method, they mean essentially where the system looks in order to derive the safety stock. As can be seen below, the Safety Stock value and the Safety Days’ Supply are interrelated fields.

There is an option to populate either or both of these fields. When both are populated, the Safety Stock Method becomes SM. SM means that the greater of either the Safety Days’ Supply or the Safety Stock as entered in the bottom field will be used to calculate the safety stock. This is advantageous because the safety days’ supply varies as it is a forumla. This formula is shown below:

Days’ supply = Total Inventory / Average Daily Consumption

On the other hand, the Safety Stock is “hard coded” and does not vary. This keeps the safety stock above a minimum level, which is useful when for instance the sales orders or forecast is low. However, when the forecast or sales orders increases, this allows the system to increase above the minimum Safety Stock. This essentially replaces the dynamic safety stock which is available to the right in the screen shot below and which changes depending upon the variability in supply and demand. Many companies would like dynamic safety stock, but simply find it to be too much master data to maintain.

How Days of Supply Actually Works

In a cost optimizer, everything must be broken down into a cost. When Days’ Supply Planning is used (that is a Days’ Supply value is set in the field above), this allows the optimizer to leverage the penalty cost for violating safety stock. When the optimizer is setup it is assigned different costs for both implicit and explicit costs. (this is described in the post below)

http://www.scmfocus.com/inventoryoptimizationmultiechelon/2011/05/how-costs-are-really-set-in-cost-optimization-implementations/

The cost assigned to safety stock violation (which can be set globally or at a product location combination), is the cost the optimizer incurs when it violates the safety stock. Safety stock is a soft constraint, which means it can be violated, but at a penalty cost. This would contrast to a hard constraint, which would be something like a production constraint, which absolutely caps how much can be scheduled per day at a number which the optimizer may not violate. Hard constraints do not require costs to be associated with them because there is not option to exceed them. Things like transportation costs are not constraints, they simply scale with the units of transportation scheduled. The same applies for storage costs. In SNP, storage costs are incurred on a daily basis per unit. Another example of a soft constraint is the cost of unfulfilled demand. The objective function of SNP is to minimize costs, so the unfulfilled demand is declared as a penalty cost, to encourage or direct the optimizer to meet as many demands as is feasible, given the hard constraints.

Getting back to how the safety stock is leveraged, anytime the planned Days’ Supply is lower than the target Days’ Supply, the safety stock soft constraint is violated and the safety stock penalty cost is incurred.

Day’s Supply in Practice (with the optimizer)

Companies are generally good about entering a Days’ of Supply, however, where they tend to fall down is in setting the penalty costs for safety stock violations. The optimizer will emphasize maintaining a Days’ Supply value only to the degree that it has to in order to minimize costs. If the penalty costs are set low relative to other costs (which they tend to be for some reason), one can expect the system to frequently depart from the Days’ Supply desired by the company at each product location combination.

Conclusion

How Days’ Supply works with optimization and safety stock penalty costs has been described above. This is important to understanding how significantly the system varies from the Days’ Supply. As with any other cost, the SNP cost optimizer will only respond to, and perform activities that help it achieve its objective function, which is to minimize costs.

References

http://help.sap.com/saphelp_scm70/helpdata/en/79/70833c8b079c2ee10000000a114084/content.htm

 

Incremental Optimization and Pre-Existing Orders as Fixed Constraints

Posted on by

Background

As with CTM, the SNP Optimizer can be run in net change mode. This allows the fixing that occurred in the previous optimization run to be maintained. This is well described in the quote below:

“Incremental optimization defines how to deal with results from previous planning runs. If the Do not delete any orders indicator is not set (see below) or if fixed orders exist the algorithm might run into infeasibilities if the existing orders are considered as hard constraints that need to be fulfilled. To influence this, demand originating from fixed (and existing) orders can be treated either as a hard constraint, a pseudo-hard constraint…a corrected forecast, or a forecast. - Real Optimization with SAP APO

However, in most cases this indicator is disabled and the optimizer recreates all orders during every run. This of course takes longer, than if this not performed. The authors do a good job of explaining the fixed orders themselves as constraints.

References

“Real Optimization with SAP APO,” Josef Kallrath, Thomas I. Maindl, Springer Press, 2006

 

Using an External System to Check Optimization Results

Posted on by

What This Article is About

  • What limits the understanding of a system? 
  • Why is properly supported interpretation so important to understanding complex systems? 
  • Why are external prototyping systems generally not used? 
  • What have been the problems with cost optimizers generally? 

Background

I recently worked on a project where the company was concerned as to whether the costs that it had placed into its cost optimizer were correct. It turns out that it had setup its costs, and then changed its costs over time primarily based upon the output of the system. The company wanted to know how the optimizer actually worked did not think that it got very good information from SAP on this topic. I realized from my interactions with them that because they did not actually understand how the optimizer worked in detail, they were not as able to control it. Secondly the setting of costs was very much trial and error. Thirdly, I did not read in the configuration documentation or in discussing with the client that the implementation partner had properly explain what the optimizer was doing. I have been using an application for prototyping forecasting and augmenting DP for some time, but I had not considered finding an application to triangulate a cost optimizer against. However, it is an excellent idea. One of the reasons that companies have a problem with visibility to the optimizer’s workings is that most enterprise solutions are deliberately hidden by the vendor. The next quote explains why:

Programming or computer science approaches use a programming language such as FORTRAN, C, or C++ to combine the model and the data and either produce a matrix or either input file for a commercial solver, or even include the solution algorithms in one program. In standard business software this approach is quite common because there is minimal to no need of changing the model in a client specific way and keeping the model, business logic, and probably the solver together in one development environment reduces development complexity. Another advantage is keeping together application design and optimization development in one tool results in seamless applications.

Disadvantages are the difficulty to understand and to be read by others, the difficulty to maintain the code, and the dependence on operating systems and compilers, to mention a few. - Real Optimization with SAP APO

This is very well said, but I take issue with the orange text in the quotation above, as I have had several clients communicate an interest to me to see the mathematics of the SNP Optimizer and to possible adjust it. The reason it is not available is explained very specifically in the following quote:

The detailed mathematical model formulation is not revealed by SAP, which is understandable from the commercial and intellectual property points of view, but it may create a disadvantage because it makes the interpretation of the results very difficult. - Real Optimization with SAP APO

Exactly. This makes external validation more important, because the optimization mathematics cannot be tinkered with. I have had very good success in testing DP against a prototype environment, certainly a similar external optimization simulator could bring similar benefits. This brings benefits in the area of extra functionality, transparency as well as the ability to verify functionality in DP.

Why External Prototyping and Validation Tools Are Generally Not Used?

In discussing this with topic with an executive at one of my clients, I was told that he had never thought of using anytime of tool to test the results, and that they had never used such a tool for ERP. This many be why tools of this type not generally used, because the model is ERP, and with ERP the supply chain complexity is sufficiently low that it is mostly unnecessary. However, even with ERP I can see a benefit to externally modeling MRP and DRP, but again because these are simpler methods that the planning methods available within APO, the necessity may not be as great, but it is still valuable. Cost optimization is however a perfect candidate for an external system to run because there is general confusion as to how it works. What is becoming increasingly useful is optimizers which can work with spreadsheets. Applications like MatLab have a spreadsheet connector, however, if that is not used then it is necessary to enter data arrays into the modeling application. The following is an interesting quote on the development of spreadsheets that combine with optimizers:

Before spreadsheets became popular, optimization was available as stand alone software, it relied on an algebraic approach, but it was often accessible only by technical experts. Decision makers and even their analysts had to rely on those experts to build and solve optimization models. Spreadsheets, if they were used at all, were limited to small examples. Now, however, the spreadsheet allows decision makers to develop their own models, without having to learn specialized software, and to find optimal solutions for those models using solvers. The spreadsheet has become almost ubiquitous, as least in the business world. The spreadsheet has come to represent a common language for analysis. Second, the software packages available for spreadsheet based optimization now include some of the most powerful tools available. The spreadsheet platform need not be an impediment to solving practical optimization problems. – Optimization Modeling with Spreadsheets

The Problem with Cost Optimization Historically

Cost optimization as a way of performing supply chain planning in multiple areas (supply, production, transportation) back in the mid-1990′s. At the time it was assumed that cost optimization was simply a better way to perform planning and that it would eventually take over. This did not happen, and clients ran into many problems with cost determination. This is the short version of events. There is a longer story to this, which I have documented here.

http://www.scmfocus.com/scmhistory/2010/07/the-rise-and-decline-for-supply-chain-optimization/

Understanding the history of cost optimization, and the concerns of this client I was working with it lead me to consider how often cost optimization projects have run into problems because the business did not have it fully explained to them how to develop costs because they did not understand how the optimizer actually dealt with costs. This has led to an interest to replicate the SAP optimizer in a general optimization tool such as MatLab or Oracle Crystal Ball (with their respective optimization plug-ins). This will allow me to show people how the optimizer is working with a small data set for basic cost estimation, and can even be used for other simulation purposes, such as supply network redesign (that is what happens if certain transportation lanes are allowed). I presented this idea at one session, and one concern voiced was how the optimizer could replicate what is inside of SAP. Firstly, SAP never originated any work in optimizers, what it added was the optimizer mathematics, but this work was most likely taken from published papers with a few tweaks based upon the needs of some clients.

The engine the SNP Optimizer uses is CLEX which is available to anyone to buy. CPLEX actually integrates with MatLab with a product called TomLab. However, also MatLab has its own optimizer plug-in, and the optimization mathematics for the various optimizations in different supply chain spheres is in the public domain. There are problematic cost optimization projects all across the country that could be improved in this way. The issue of course is that it would take time and cost more in the beginning and most clients probably won’t have the patience for this approach. More details on understanding the difference between enterprise optimizers and general solvers can be seen at the link below:

http://www.scmfocus.com/supplychainsimulation/2011/10/12/understanding-the-difference-between-enterprise-optimizers-and-modeling-languages/

Prototype Environments Generally

However, the opportunity is not limited to cost optimization. I currently use an external prototype tool to troubleshoot and improve SAP DP, and will be relying upon the same tool to model MRP in an external was as well. The more that I discuss with different clients, the more I am able to explain that modeling outside of the production system can bring significant benefits. In my experience, clients are never exposed to the “single solution approach” this in the large consulting companies, because they don’t understand the concept of simulation and what is and what is not a good simulation environment.

Multi-Purpose Uses for General Optimizers

Checking the results of a production system is not the only use of an external optimizer. Another is to perform sensitivity analysis for strategic planning. This is described in the post below:

http://www.scmfocus.com/supplychainsimulation/2011/10/25/a-sensitivity-analysis-approach-for-supply-chain-optimization/

Conclusion

There are very significant benefits to using external prototype environments to both help explain what the application logic is doing to the business, to help tune SAP and to assist in the setting of values. The cost optimizer in particular should be externally modeled outside of SAP to make the functions transparent and to be able to simulate quickly. This is something I will be working on in the future, and which I plan to write about extensively. However, the benefits of using flexible simulation environments generalizes outside of the cost optimizer into other areas of the supply chain such as demand planning and MRP.

References

“Real Optimization with SAP APO,” Josef Kallrath, Thomas I. Maindl, Springer Press, 2006

“Optimization Modeling with Spreadsheets,” Kenneth Baker, Wiley, 2011

 

 

 

 

 

SNP Optimizer Sub Problem Division and Decomposition

Posted on by

Background

In finding a way to segregate the problem, cost optimizers are typically programmed to process material supply network by material supply network. This is called “decomposition,” which means to “decompose” the problem as described below:

Decomposition in computer science, also known as factoring, refers to the process by which a complex problem or system is broken down into parts that are easier to conceive, understand, program, and maintain. – Wikipedia

SAP has the following comment on decomposition in its help:

Decomposition is a flexible tool for balancing the tradeoff between optimization quality and required runtime. When runtime is unrestricted, the SNP optimizer usually provides a better (optimal) solution without decomposition; however, when a fixed runtime has been specified, using decomposition could assist the optimizer to find a better or, in fact, feasible solution. - SAP Help

Decomposition can take place along a number of dimensions. For instance in SAP SNP, decomposition can take place upon the following dimensions:

  1. Time
  2. Product
  3. Resource

This can be found on the Solutions Methods tab of the SNP Optimizer Profile.

Time, product and resource are all stated differently from one another.

Time Decomposition

Time asks for a window size. SAP recommends using time decomposition and says that it improves solution quality (which is not surprising as problem division tends to improve solution quality). Time is a relatively easy to dimension on which to decompose due to the lack of problems with interdependence. The number of windows breaks down the planning horizon into buckets.

Product Decomposition

The product decomposition is entered as a percentage. This divides the problem into product groups.

Resource Decomposition

This is the only decomposition method in SNP requires more master data in order to implement. The master data of resource priority profiles is then assigned when this is engaged. Of the different decomposition methods, resource decomposition is the least frequently used and the most difficult to understand.

Resource decomposition speeds up the solution process by analyzing the material flow and basic optimizer decisions about production, procurement, and transportation to determine a resource sequence. The optimizer can then create sub-problems for the individual resources, which are solved in sequence. The optimizer makes decisions in every sub-problem that cause the resource to be loaded.- SAP Help

However, one important issue here is how SAP has designed SNP with respect to resources versus how the resources, and more specifically the categories of resources that are used. SAP’s resource setup allows a wide variety of resources to be used, as can be seen from the screen shot below:

However, while many resource categories are possible, the vast majority of SNP implementations only actually constrain on production constraints. Optimization only focuses on or uses constraints which are set to finite. (If not finite, the resource can be used for information purposes, to allow planners to see what weeks are over capacity.)

Because of this fact, the complexity involved in as SAP says “analyzing the material flow and basic optimizer decisions about production, procurement, and transportation to determine a resource sequence,” is a lot more simple than it sounds. This is because if the only resource to be analyzed are production resources, then it really just comes down to combining products that share the same resource together as a sub-problem. Without this, a sequential run of each product (each product that shares the resources as a separate sub-problem, as in the case with product decomposition) would result in one product receiving the resource allocated to its production before another simply based upon the “luck” of the sequence of the product sub-problem being run through the optimizer.

Using Both Product and Resource Decompostion

There are a few interesting things about this comment from SAP with respect to using both product and resource decomposition at the same time.

It is particularly advisable to use resource decomposition if the production processes always load the resources in a similar sequence. Resource decomposition does not reduce memory requirements. If you want to use product and resource decomposition together, the system carries out the resource decomposition first. The product decomposition then tries to improve upon the results of the resource decomposition. – SAP Help

The portion in orange is of course very interesting. It is also surprising, at least to me. If I had been designing the decomposition method with developers at SAP, I would have requested that when both resource and product decomposition are selected, would mean that the system would look at both at the same time. This would in effect increase the size of the sub-problem, as products with shared resources would be included as part of the same sub-problem. This conceptually would be described below:

This type of decomposition solves the issue of resources that are shared across products. It does have the disadvantage of creating a larger sub-problem, however, shared entities that have inter-relationships should be in the same sub-problem. However, SNP does now work that way. Instead, it processes the decomposition sequentially. This cannot possible be as good a solution as the design described above. However, this would seem to be an issue with CPLEX rather than SAP, as CPLEX is the solver doing the work behind the scenes, but this is SAP’s setup, and I have to say, the fact that one optimization does not respect a previous optimization, makes this design looks quite strange to me. In fact, I am unsure if I would use it. This would lead one to perform the decomposition by manually breakup the problem into different runs, which is of course less desire-able and requires extra maintenance effort. Furthermore, the more resources there are, the less feasible this solution would be. Interestingly, I have never read any post or book which criticized SAP’s resource decomposition method before.

Decomposition Benefits

The following quote is instructive with respect to the benefits of decomposition:

Since the existence of many restrictions or – to a higher extent – discrete variables can lead to high computational efforts, SAP APO offers various possibilities to reduce the storage and runtime requirements by dividing the problem into parts. Particularly in the case the supply chain model results in a MILP (mixed integer linear program) problem solver runtimes can get very high; integer models are a consequence of discrete decisions such as modeling lot size intervals. As the implementor does not have direct access to SAP’s mathematical model formulations these methods of handling the solution times are the approximate way of influencing the behavior of the SAP APO optimizer (apart from changing master data that define the coefficients in the model equations). Especially when dealing with large MILP problems the runtime of the algorithm might be cut by decomposing the problem into smaller subproblems. - Real Optimization with SAP APO

Optimization with Integers and Integer Relaxation

While it may appear to be a minor issue, in fact setting a number of the variables to integers in fact greatly lengthens out the run-time, and APO does not have an option for relaxing integer constraint as most other optimizers that I have worked with do.

Here is an example of integer relaxation within the Frontline Solver for Excel. It is set as a default to 5% of integer optimality. This allows the solver to still find a very good solution, but to spend much less time calculating it. Because Frontline Solver is much more frequently used for calculating strategic objective functions with far fewer outputs, relaxing the integer requirement is a much more simple matter than doing so in a supply planning enterprise optimizer which calculates a tremendous number of value as output, all that would have to be adjusted post-optimizer in order to be actionable in the real world.

The concept to integer relaxation is one to solve the problem more quickly for testing, and secondly all of the output (such as purchase orders) could be relaxed within the optimizer, bringing much faster solution times, but with internal rounding. Therefore, 45.3 units would become 50 units in order to meet both the lot size quantity and the integer requirement. (sending .3 of a unit makes great sense from a mathematical perspective, but does not make much sense in the real world. APO could accomplish this with a post optimization rounding routine, but evidently the developers preferred not to go down this track, which means much more hardware is required to run SNP than would have been required if this approach was taken. I am currently writing an article on integer relaxation and I will insert the link to that article here when it is complete.

Josef Kallrath, Thomas I. Maindl go on to describe how the problem decompositions changes depending  upon the decomposition selected.

Resource decomposition is based on the analysis of the material flow and the basic decisions about production. After the analysis, sub-problems are developed for the individual resources according to which the resource assignment is generated. With product and resource decomposition priority profiles can be established to determine the sequence in which the optimizer aggregates and plans product groups and resources. - Real Optimization with SAP APO

Time decomposition on the other hand divides the optimization problem by the time horizon.

Finally, there is an option for vertical and horizontal aggregation of planning data where the optimization is dealing with aggregated data.. Vertical aggregation is concerned with product demand and horizontal aggregation deals with subgroups of the supply chain network - Real Optimization with SAP APO

More on Problem Division

While decomposition sounds comprehensive. In fact, this is only one method, and the most automated method of dividing the optimization problem. Another way is to manually divide the problem into different optimization runs. For instance, some companies may use product decomposition, but then divide the problem by product attribute, so that product with similar attributes are run together. This can overlay with how many production facilities there are that produce each type of product. In general the topic of both decomposition and run division is one of the most all encompassing and complex of all the optimization decisions.

Conclusion

Different optimizers have different ways of decomposing the problem. The selection is actively made during the design stage based upon either time, resource or product. Of the three product is the most common, which breaks each sub-problem into a sub-network per product within the overall supply network.

References

“Real Optimization with SAP APO,” Josef Kallrath, Thomas I. Maindl, Springer Press, 2006

http://help.sap.com/saphelp_ewm70/helpdata/en/01/bc044017355c0ce10000000a1550b0/content.htm

SAP Help