How to Understand Aggregate Production Planning and Resources in SAP APO

Table of Contents: Select a Link to be Taken to That Section

Executive Summary

Aggregate Production Planning
Aggregate Production Planning in SAP APO
What is an Aggregated Resource in SAP APO?
What is the Relationship Between the Aggregate Resources and SAP APO SNP versus PP/DS in this Sample Design?
What are the Possible Alternatives without Enabling Aggregate Resources in SAP APO?
What are several Complications of this Approach?
Is this Requirement Valid, or more of an Understanding Issue of How SNP/CTM and PP/DS are Used.

Introduction

Aggregate production planning is when production planning is performed when one of the production elements is aggregated. One type of aggregate production planning is aggregating the resources, although it is not common to do this.

Our References for This Article

If you want to see our references for this article and other related Brightwork articles, see this link.

Notice of Lack of Financial Bias: We have no financial ties to SAP or any other entity mentioned in this article.

This is published by a research entity, not some lowbrow entity that is part of the SAP ecosystem.
Second, no one paid for this article to be written, and it is not pretending to inform you while being rigged to sell you software or consulting services. Unlike nearly every other article you will find from Google on this topic, it has had no input from any company's marketing or sales department. As you are reading this article, consider how rare this is. The vast majority of information on the Internet on SAP is provided by SAP, which is filled with false claims and sleazy consulting companies and SAP consultants who will tell any lie for personal benefit. Furthermore, SAP pays off all IT analysts -- who have the same concern for accuracy as SAP. Not one of these entities will disclose their pro-SAP financial bias to their readers.

Aggregate Production Planning in APO

One interesting requirement that I recently came across was for SNP to scheduled on aggregate resources. This, of course, would only apply to resources that perform the same processing.

For instance, line A and line B that both produce Widget XYZ (the assumption here also is one resource per line, just the bottleneck resource being modeled).

The concept behind this requirement is that the supply planner should not be assigning planned production orders to the exact resource as they don’t have the information to do so. Therefore, the requirement is for them only to see the aggregated resource. In conclusion, I will explain why this is partially a misunderstanding of how supply planners interact with SNP versus how production planners interact with PP/DS. This can be a problem on projects where the delineation between SAP APO SNP and PP/DS is not properly explained. However, this can also be a case in some projects where a repetitive manufacturing environment produces the necessity to perform interactive supply and production planning rather than following the standard workflow of SNP and PP/DS, which has a sequential flow from supply planning to production planning.

However, this can also be a case in some projects where a repetitive manufacturing environment produces the necessity to perform interactive supply and production planning rather than following the standard workflow of SNP and PP/DS, which has a sequential flow from supply planning to production planning.

This is an additional problem because SNP creates the initial production plan when it has production constraints (and this is quite common). In fact, I was told by a client one time that “supply planning and production planning are the same things.” However, they aren’t; if one did not study the two subjects and fell onto an SNP project uninitiated, one could easily come to this conclusion. However, the question of using aggregated resources is still interesting and will be evaluated in this article.

Understanding Aggregated Resources and SAP’s Standard Functionality

There are a few things to consider before I go through and describe a potential design:

There is an aggregated resource functionality in SAP APO, which I have never seen deployed and which I have not personally tested.
It is part of aggregate production planning functionality, which also applies to SNP (that is, you can apply I found this quotation of interest from SAP on this topic:

If you carry out optimization-based planning with resources, you must always create a resource at the header product level. The SNP optimizer uses the resource and costs defined at the header product level for aggregated planning. Creating resources is optional for the SNP heuristic. The total of the resource capacities defined at the header product level should form the resource capacity at the sub-product level. If you are using several PPMs/PDSs at the sub-product level, the resource consumption of the PPM/PDS at the header product level should form the resource consumption of the different PPM/PDS’s at the sub-product level. However, there are only around three messages on search.sap.com that directly relate to aggregate resources, as the search link in the references at the tends of this article demonstrates.

These messages are also copied in the references section. The configuration for aggregated resources appears quite onerous. At this client, we are not running a procedure for PP/DS, so we may have some extra options available to us that are not available to other projects that are using the PP/DS heuristics or the PP/DS optimizer. This design’s first step is to check how resources can be aggregated, just from SNP’s resource information. This is the most basic level of analysis. That is, if there is no good way to aggregate resources even conceptually, then this design would run into problems:

Reviewing Resources in SAP APO

Below is where much of the important detail about the resource capacity is located on the Time-Cont. The capacity tab of the Multimixer resource tab. We will revisit this view with callouts for the pertinent fields in just a minute. Before we do, let’s see the capacity broken out by the day. By selecting the capacity button, we can see the capacity by the calendar. After evaluating the fields, I find two that may be used to adjust the capacity. Both are called out below: Therefore, if either field above is set to 100%, that means the resources are available at the standard capacity at 100% of that capacity. However, can these fields be leveraged to support an aggregated design? Possibly and here is how:

Either field is essentially a way of adjusting the capacity resource. These could be adjusted. However, it may not be the most direct way to aggregate resources.
The capacity could be aggregated for, say, two resources. So if each resource had a capacity of 2000 units for the time the resource is declared up, an aggregated resource could be created with a capacity of 4000 units. SNP would only have the single aggregated (0r virtual) resource, while PP/DS would hold both the aggregated (virtual) resource and normal resources (that is, the real ones).
If one were to run a PP/DS procedure, this design would not work. However, in our present design, the production planners move the planned production orders to the Detailed Scheduling Board resources manually. The planners know which resources are virtual or aggregated and which resources are real.

Sample Design Diagram

The design regarding the system interaction and where aggregated resources appear would look like the following:

Design Caveat

This design assumes that the resources that are being grouped are identical. Two resources that differ in any way (outside of the capacity, which is being summed by the hypothetical CIF ABAP program) would not be able to aggregate two resources with different begin and end dates. This would be a limitation because companies with lines that perform the same work have differences between the resources/work centers.

Is This Design Feasible?

I think it is. This design could be accomplished, but with some downstream implications that are probably negative. However, I would prefer it over SAP’s standard resource functionality. Again, the simple customized design would probably work because no procedure is run in PP/DS because of the particular client circumstance. In fact, the design could still work, but if a procedure were run in PP/DS, the aggregated resource would need to either be removed from the systems or assigned no capacity.

Is This Design Appropriate, and is the Requirement Legitimate?

A major issue with SAP projects is that SAP consultants will begin configuring a demo before they have asked if the requirement is legitimate. I don’t think this one is. I think there are several reasons that a client may think an aggregated resource is necessary for SNP.

The client may not appreciate that the SNP planner does not work at the production planner’s detail level. The SNP planner runs a procedure (or uses reorder point planning), checks the planning book, and then reviews the supply planning parameters. The procedure manages the assignment of a planned production order to a resource (either CTM or the optimizer — not the heuristic). However, we are using CTM, in this case, to perform what is called constraint-based planning. This leads to the next point:
SNP/CTM creates or attempts to create a feasible plan. However, it does not perform a resource assignment. This means when the planned production orders are released to PP/DS, the procedure (or no procedure in this case) takes over. Does this wipe out the SNP scheduling? Yes, it does. However, it is not as bad as it seems. This is because SNP/CTM is only responsible for passing a feasible plan to PP/DS. This means if a planned production order cannot fit into the production schedule for one week, it will be moved, and PP/DS will not ever see that planned production order until the next week. However, there is a caveat, which is described in bullet three below:
A company should maintain a timeline delineation between SNP/CTM and PP/DS. That is, if PP/DS is responsible for scheduling two weeks out, then CTM should essentially not worry about the first two weeks. If a rush production order needs to come through and be scheduled, at that point, it is outside of the domain of supply planning and should not be scheduled by CTM. Many clients will push back on this, but many clients walk the tightrope between execution and planning. This is controlled by the CTM profile in the Planning Scope tab, which is shown below. However, this leads to another point.
There can be an issue in some repetitive manufacturing environments by creating a dividing line between PP/DS and SNP. In cases where supply and production planning are performed interactively – that is, a planner does both jobs, there may be a limited benefit to an application like PP/DS. In some cases, it can make more sense to have the planners perform their interactive planning and then port the changes to planned order back to CTM through moving planned orders in the SNP planning book.

Notice the planning start and planning end times and dates, allowing the configuration to precisely control the beginning and end of CTM processing receipts and requirements.

Go to top

Conclusion

Aggregate production planning and aggregate resources are tricky, whether the “standard” SAP functionality is leveraged, or something custom is written. However, I took a step back on this requirement and concluded that it is not necessary. It is needed to explain better how SNP/CTM and PP/DS work independently and how they work in conjunction. Aggregate production planning is still uncommonly implemented.