In the context of verticals such as consumer packaged goods, the consumers of such goods have a wide variety of SKUs to choose from in any given product category. These SKUs may have minor variations in terms of ingredients or packaging. For example, a nutrition bar with the same basic content or ingredients could be sold with different flavors such as almond, chocolate, or vanilla. Another example is a chocolate pudding snack with sugar-free variation that otherwise has the same set of ingredients as a regular pudding. Furthermore, in a private-label business specifically, different retailers sell the same exact product wrapped in different packaging custom to that retail organization. Although from a customer’s point of view, such a wide variety of choices is a benefit, from a production planning point of view, accurately planning production so that SKUs that are similar in content are produced together is a challenge.

Thus, in a context where a production planner has to plan for a wide variety of SKUs characterized by dissimilarities and similarities in various attributes, such as flavor, size, or any other parameters specific to the SKU, the production planner has two choices. One is to plan and produce the SKUs in an order closely representing the demand. However, that might require significant changeover costs to change the flavor of the SKU being produced. The second choice is to group the demand of like SKUs together in a production cycle reducing changeovers. In such instances, production planners usually earmark certain weeks in a month for producing certain kinds of flavors that they would like to see planned in a logical group. This is similar to block planning with the planner wanting the planning tool to work with prespecified dates for production of certain SKUs in a group. Although planning in blocks of time earmarked for a certain SKU group by itself may not be very efficient because it is not demand driven per se, it brings a whole lot of predictability into the production plan model. Predictability is something that everyone on a shop floor wants.

When the production plant level limitations or guidelines in terms of the blocks are taken into consideration up front in SNP for medium- to long-term planning, these plans roll over into the short-term Production Planning and Detailed Scheduling (PP-DS) horizon, making the transition fairly smooth with minimal manual touches and interventions.

I discuss some of the SAP offerings and limitations for SKU group planning that you can implement.

Aggregate Planning

Supply Network Planning (SNP) provides standard ways of defining single-level product aggregates in which you can define SKUs at a higher level with loosely defined bill of material (BOM) structures. These SKUs exist only in APO as a product and represent a group of SKUs with a certain similarity in characteristics that the planner would want to plan together in terms of production.

There are three specific sets of data to be defined at the aggregate level:

1. An aggregate product is an actual SKU defined in APO that can be programmatically created using business rules, representing all the like SKUs in the group. Like SKUs can be based on attributes such as flavor, size, or any other parameters specific to the kind of SKUs being aggregated. Figure 1 shows a sample aggregate product defined in an APO system that consists of five other SKUs. The planning product or SKU group is defined using naming conventions representing what the group consists of.

Figure 1

The planning product or SKU group

2. An aggregate resource is an actual resource defined in APO, representing all the resources that the SKUs within the SKU group consume. Although the aggregate product defined in the previous step consumes aggregate resources, the member SKUs consume the resources that it rolls up to in terms of aggregate resources. Figure 2 shows how an aggregate resource is defined. In this example I created an aggregate resource that consists of resources that manufacture the SKUs that belong to the same group. Medium- to long-range planning results would first have to be viewed on aggregate level resources in terms of consumption.

Figure 2

An aggregate resource

3. An aggregate production data structure (PDS) is the equivalent of a BOM, and routing information in APO real time linked to equivalent structures in an SAP ERP Central Component (ECC) system. A PDS has to be defined that consumes the aggregate resource. The aggregate PDS defines how aggregate resources are consumed in terms of variable or fixed consumption parameters, based on the production number of aggregate SKUs. At the same time they represent, in hierarchy terms, the group of different individual PDSes. Figure 3 shows how this structure is defined in APO. Note that SAP does not provide any way to directly create PDS in APO for aggregate products without using custom logic. BAPI_PDSSRVAPS_SAVEMULTI may have to be used to create an aggregate level PDS.

Figure 3

Aggregate PDS represents a group of individual PDSes that consume resources based on a production plan of SKUs

To summarize, aggregate planning reduces the size of the planning problem, which is one of the greatest advantages of using this functionality. In the example that I just described, a planning problem that would otherwise have five SKUs and five different PDSes would be reduced to one SKU and one PDS. Disaggregation of plans from a higher to a lower level based on quota or demand can be further applied to arrive at a detailed level plan, should there be a need to do so in the SNP planning horizon.

Although aggregate planning is a useful tool, it has some limitations and complexities that could set off an implementation timeline by several months. A few limitations that we discovered in prototyping that led us not to go down this path were:

• The product hierarchy maintenance is fairly rigid and may not be very user friendly, specifically when the SKU mix in a group is dynamic. Realigning or reorganizing the product hierarchy based on the latest mapping of SKUs with SKU groups is tedious, specifically when this mapping or relationship is dynamic.
• There are very limited ways to disaggregate information from an aggregate to an SKU, with no provision for a custom method of disaggregation.
• Data maintenance and even a one-time setup may be prolonged and complex, specifically when supply planners are looking at SKU-level resource consumption information from the medium to the long term.

Based on our assessment, aggregate planning is a good fit when planners are not particular about plans for specific SKUs outside of the PP-DS horizon. Further, it makes sense to go with the full-fledged aggregate planning solution only if there are ways to automatically sync the product hierarchy between SAP ERP Central Component (ECC) and the SNP system. This might require ABAP automation for sustainability, and thus impact project timelines. Product hierarchy could be used in ECC for a variety of purposes including but not limited to financial reporting.

Block Planning

The scenario described in Figure 4 is that of a production plan in which certain sizes of the cups are planned to be produced in certain weeks. In this plan, all the desired flavors also have to be produced based on the demand. For example, there may be a greater demand of chocolate cups in smaller sizes, whereas butterscotch has a greater demand in the larger cup sizes. The purpose of block planning in such a scenario within SNP is to be able to get the right sequence within a week that can be imported within PP-DS module.

Figure 4

The intent of producing certain sizes of pudding cups in certain weeks of every possible flavor within a week

The setup matrix defined in PP-DS can be leveraged in SNP so that changeover costs and times are predefined. This information is used to come up with an optimal sequence and size of blocks that can be imported into PP-DS.

Block planning as a feature works well for situations in which changeovers are significant as a proportion of total production time, and also when there are frequent changeovers. In a highly production-constrained scenario in which asset utilization with high customer fulfillment is the key, it may make sense for you to explore this feature.

Standard block planning in SNP can only be implemented with the SNP Optimizer. IT_PROMO structure in the SNP Optimizer log shows SNP planned orders created with the Setup Activity ID and Order Sequence number. These can be imported to Production Planning-Detailed Scheduling (PPDS) for execution.

There may be a need to model only a subset of transitions (e.g., one flavor to another is fairly significant from one size to another), instead of all transitions that are modeled in PP-DS via the setup matrix master data defined. Block planning may be an unwanted complexity in such a solution. Many food consumer packaged goods (CPGs) companies have weekend clean-outs of machinery, also known as sanitation cycles, which is a natural pause in a production run. This aligns with SNP weekly runs as well, and thus sequences coming out of an SNP Optimizer run, for example, may propose the same starting flavor every time after clean-outs. This may not always be a desired production strategy, as planners may want to continue with the same flavor before and after the clean-outs. This production strategy is not possible with block planning delivered by SAP SNP  without some extensive customization.

The sequence of orders with block planning in SNP is only determined within the bucket. Therefore, while you can get a sequenced plan within the bucket, you can’t get it to combine multiple orders across buckets. A week in a specific business context may be too short a time to block plan, and thus it may make sense to leverage this functionality only when the time periods are in the order of months.

SKU Group Planning Using Dummy SKUs

After an extensive search, we zeroed in on an approach I  describe as SKU group planning using dummy SKUs. This approach requires very minimal customization at three different places, and also requires master data definitions supported by SAP.

SNP Optimizer is the only algorithm delivered by SAP that models the shelf life of a SKU. The SNP Optimizer is able to factor in SKU expiration based on shelf life and cost of disposition of SKUs beyond expiration. The SNP Optimizer engine uses the inventory of the dummy SKU immediately, and avoids having any remaining projected inventory, thereby optimally leveraging the inventory for purposes of SKU grouping. The dummy SKU is distinct from the member SKUs in terms of the planning process. This dummy SKU is predefined with a very short shelf life, such as one or two days, and configured to be produced on a dummy resource that is opened on specific weeks of a fiscal month. The dummy SKU could also be defined with a certain lot size so that the SNP Optimizer uses the dummy SKU as a component to produce certain finished goods within a group.

I now explain the steps to invoke SKU group planning via minor custom enhancements.

Supporting Master Data Fields and Objects

The critical master data that supports the custom SKU grouping functionality includes the product master of the dummy SKU and regular SKU, the resource master and PPM for the dummy SKU. Different master data elements also include important fields. I now discuss these elements.

Product Master

In view /SAPAPO/V_FNMAT, accessible via transaction code SPRO, you need to define three different extra attributes. These attributes are permissible by the standard SAP system via configuration. In your configuration, define these custom fields in table MATKEY: Dummy SKU Group, Material Type, and Shelf-Life Target. The MATKEY table is an important table in APO. It is similar to the MARA table in ECC in that it has all product-specific attributes such as based unit of measure, shelf life, weight, volume, and packaging material that is independent of the location where the material is stocked. This table has flex fields that can be custom assigned based on specific business requirements in configurations accessible via menu path SAP Implementation guide > Advanced Planning and Optimization > Master Data > Maintain Freely-Definable Attributes. Defining the extra attributes populates the custom fields in the MATKEY tables. These tables are accessible by many function modules within APO. The extra fields in MATKEY in the configuration, relevant for planning at SKU group level, appear in the product master as shown in Figure 5.

Figure 5

Define three custom fields

These fields play an important role in the logic in terms of information they carry. To view the product master in APO, execute transaction code /sapapo/mat1 (Figure 6). Note that the Dummy SKU Group field includes the name of the group. All homogenous sets of SKUs that have to be planned together would roll up to a specific dummy SKU group. The Material Type field is informational in terms of whether the SKU is a component, finished product, or a SKU group. The Shelf-Life Target field is intended to carry the value of the shelf life of the SKU in question. A dummy SKU would have a value of, for example, one or two days.

Figure 6

Custom fields defined in APO product master

You do not want to use the standard Shelf-Life Target field and other fields such as Planning with Shelf Life (Plng with Shelf Life) and Min. Shelf Life in the product master. In other words, custom shelf-life target fields override the standard shelf-life target fields in the product master. These standard fields are used by PP-DS for alert generation and also for material requirements planning (MRP) calculations. Further, this field is refreshed from CIF based on SAP ECC master data settings. By changing or manipulating standard fields of shelf life, you could potentially disrupt alert functions in PP-DS. With a custom field, you can overwrite the value of shelf life, where needed. For example, if you want to model shelf life of 270 days instead of shelf life of 540 days, it would be possible to have a custom field to drive the calculations.

Figure 7 is another view of the product master. This screen shows the standard fields for shelf life. The standard shelf-life field can be used in PP-DS for doing planning based on shelf life, and alternatively also in SNP within the framework of the SNP Optimizer to do planning based on shelf life. The fields relevant that control these functions include Shelf Life, Min. Shelf Life, and Plng with Shelf Life. Select the Min. Shelf Life radio button and the indicator for Plng with Shelf Life. Note that I have entered Shelf Life 540.00 in the Shelf Life field and 270.00 in the Req.Min.Sh.Life field. Click the save icon to save your entries.

Figure 7

Standard SAP fields for shelf life

The next step is to manually create other master data objects such as dummy SKUs and dummy resources. You then assign them to the Active Model and run a Live Cache consistency check. The Dummy SKU is defined with a minimum set of master data. To define it, execute transaction code /sapapo/mat1 and follow menu path Advanced Planning and Optimization > Master Data > Product > Product. Figure 8 shows the relevant fields for Dummy SKU Product master definition. You define the Shelf-Life target field as 001 because it is an alphanumeric field. It is optional to populate the specific Material Type as DUMMY for ease of data organization and identification.

Figure 8

The Properties tab of the product master of dummy SKU

In the product master, follow menu path Advanced Planning and Optimization > Master Data > Product > Product and click the Procurement tab (Figure 9). Enter E in the Procurement Type field for in-house production (Figure 9). In SAP APO procurement, type E represents a SKU having a valid production source of supply. Further Procurement cost is defined as 10, which comes into play while calculating disposition costs during an SNP Optimizer run when the SKU is beyond expiration. Click the save icon to save your data.

Figure 9

The Procurement tab of the product master of dummy SKU

SNP Optimizer has to factor in costs for delays in fulfilling or not fulfilling a demand on a dummy SKU. A demand on a dummy SKU depends on the SKU based on planned orders proposed at a header SKU in PDS definition. Using transaction code /sapapo/mat1, create an option to technically create dummy SKUs, each representing unique SKU groups (Figure 10). You can use SAP scripting or any automation tools available in a standard SAP system to automatically create many SKU groups. You can add different values for penalty costs for delay (Delay Pen.) and nondelivery (ND Penalty) for different kinds of demands, such as forecast or sales order. These values are used within the framework of SNP Optimizer. In general, a non-delivery penalty is kept higher than the product of Max-delay and Delay penalty fields. Further, penalties for sales orders are kept higher than forecasts.

Figure 10

Delay and non-delivery penalities defined on a dummy SKU

There are as many dummy SKUs as SKU groups. In my example I went up to 15. You have to create your own nomenclature to create the dummy ID. SAP does not allow duplicate names, and therefore, the system ensures that it is always unique. After you create different Dummy SKUs with a certain naming convention that is easier to correlate it with the SKUs intended to be grouped, the assignment as defined in Figure 6 is made by executing transaction code /sapapo/mat1 for the SKU that needs to be grouped or rolled-up to a Dummy SKU group. The additional field Dummy SKU group in the Properties tab carries the information on the exact Dummy SKU group to which the SKU rolls up.

The components that go into SKUs that are to be grouped are also suggested to have periodic lot-sizing definitions defined as shown in Figure 11. These period types define the time frames used to aggregate the demand for which to plan an order. For example, if you define a value of a week and the number of period as 1, the system would sum up demands every week and plan for supply orders against it.

Figure 11

Define a period type for a dummy SKU

Define Dummy Resources

Dummy resources are defined so that they can contain production open and downtime for the dummy SKUs. To define a dummy resource, use transaction code /SAPAPO/RES01 or follow menu path SAP Menu> Master Data > Resource > Resource (Figure 12). In the screen shown in Figure 12 WDUMMY2_2151_001 is an example of a dummy resource that produces the dummy SKU in preassigned blocks of open time of the resource.

Figure 12

Dummy resource master data for a dummy SKU

Dummy resources are defined with the same location calendar as other resources in that plant. You can define downtime in dummy resources as per the frequency of production required as shown in Figure 13. (Figure 13 is the bottom of the screen shown in Figure 12.) To select downtimes, click the drop-down icon on the right side of the field under the Type of Downtime column and choose an appropriate option. This information is usually provided by business users. Downtime definitions define the times the resources are open.

Figure 13

Downtime definitions in a header resource

The Production Process Model

The purpose of the production process model (PPM) is to make the dummy SKU a producing product linking to the dummy resource. The SNP Optimizer respects the shelf life of only a produced product. To define a production process model, use transaction code /SAPAPO/SCC03 or follow menu path SAP Menu > Master Data > Production Process Model > Production Process Model (Figure 14).

Figure 14

PPM links the dummy SKU as an output component with a dummy resource

In the screen shown in Figure 14, DGP_DUMMY_2151_02_PPM is an example of a production process model that maps the dummy SKU named DGP_Dummy_2151_02 with the dummy resource named WDUMMY2_2151_001. You do not have to define an input component because it is not relevant in the planning model that I run in my example.

You define only the variable for consumption, as shown in Figure 15. Because downtime is already updated for resources, finished goods are grouped with dummy production (refer back to Figure 6). The three master data objects — a dummy SKU product location, dummy resource, and a corresponding PPM that is uniquely defined in APO — support the objective of shelf life planning with the SNP Optimizer. These objects group similar SKUs for purposes of group planning. In the screen shown in Figure 15, note that the Bucket Consumption variable is kept at 1 second, the lowest possible value in the model. This results in the resource being treated as infinite. Therefore, there is no constraining based on this resource.

Figure 15

Bucket consumption defined as 1 sec

User Exits and Enhancements to Support SKU Group Planning

I describe the three different enhancements to support SKU group planning in the SNP Optimizer, with an outline of their logic.

The first enhancement is BADI /SAPAPO/CURTO_SNP, Method CHANGE_SNP_PDS_R3 (Figure 16). The purpose of this development is to read the additional attribute in the product master in APO for the header SKU for which the PDS is about to be created. The dummy SKU is added to the PDS as an input component if the following conditions are satisfied:

• The dummy SKU defined in the ATT01 field in the MATKEY table is not initial in APO.
• The dummy SKU has a PPM defined.

Figure 16

Logic defined in PDS structure change to include dummy SKU as a component

The second enhancement is BAdI /SAPAPO/CL_EX_CIF_OP, Method ORDER_OUTB_MODIFY_AFTER_EXTRAC (Figure 17). The SKU starting with DGP (Dummy Group SKUs) is eliminated from the Planned Orders being published to ECC to avoid queue blocks. The reason to do this is to avoid unnecessary queue blocks since the Dummy SKU does not exist in ECC. For ease of logic and identification, I recommend that you define these Dummy SKUs with unique characters at the beginning of the name of that SKU.

Figure 17

Logic defined for publishing of SNP planned orders into ECC to strip off information on the dummy SKU

The third enhancement is BAdI /SAPAPO/IF_EX_SDP_OPT_LOG Method /SAPAPO/IF_EX_SDP_OPT_LOG~ACCESS_INPUT_LOG (Figure 18). The Dummy SKU is the only SKU in the model that should have shelf life planning turned on. The rest in scope are flagged as inactive for shelf life planning inactive. This is to reduce the load on the SNP Optimizer, and ensure that the shelf life of other SFG/FG SKUs does not distort the SNP Optimizer model and cause an excessively long runtime.

Figure 18

Logic defined to pass shelf life information into input of the SNP Optimizer based on an extra attribute of the product master

SNP Optimizer Settings to Drive SKU Group Planning with Dummy SKUs

The Shelf Life planning feature has to be turned on within the SNP Optimizer. The purpose of Shelf Life settings is to enforce a minimum lot production of SKU groups for more efficient production plan management. The SNP Optimizer profile is accessible via SAP Menu > Supply Network Planning > Environment > Current Settings > Profiles > SNP Optimizer Profiles.

Figure 19 shows the Shelf Life settings in the SNP Optimizer. The Shelf-Life Target is only maintained for Dummy SKUs and is blanked out for other SKUs (refer back to Figure 6).

Figure 19

SNP Optimizer settings

Lower lot size at the SKU Group level influences the number of SKU Group production proposals in a week. In a standard SNP, there is an inverse correlation between lot size and number of production planned orders in the planning horizon. Therefore, you can control the number of orders created in the system by influencing the lot size of the dummy SKU.

To view the results of an SNP Optimizer run, execute transaction code /sapapo/snpoplog or follow menu path SAP Menu > Supply Network Planning > Reporting > Optimizer Log (Figure 20). SNP Optimizer tends to produce SKU members of specific dummy SKU groups in the same week matching with MATKEY mapping.

Figure 20

The SNP Optimizer log

Note that the results shown in Figure 21 are based on the settings shown in Figure 6 and are also shown in Figure 20.

Figure 21

MATKEY view showing mapping between the SKU and the dummy SKU group

The above sections on SKU Group planning summarize the master data and enhancements required to activate the functionality.

Applications of SKU Group Planning with Dummy SKUs

The approach described in the previous sections helps you understand how a dummy SKU can be used to club together the production of like SKUs that make business sense to a production planner in terms of how production schedules are run. Heavy changeover costs or times can influence the sequence for running the production schedules, specifically when there is a wide array of SKUs to be produced in a production cycle that spans multiple weeks.

There are several other applications of SKU group planning with dummy SKUs, and the embedded shelf life solution.

1. Sharing capacities across locations in terms of SKU groups: There could be multiple locations producing the same SKU groups. In a capacity constrained situation, SNP may offload demand from different SKUs spread across different SKU groups to other locations, which may not be desirable from a Production Planner stand point. It might be more useful to instead share a logical set of SKUs forming an SKU group. This way the sharing logic works at SKU group level instead of SKU level.
2. Quota arrangement at different levels: Because of planned downtime at a location, one may want all the production to move to a different location for a set of SKUs. It would be easier to manage this via downtimes specified on a dummy resource.

3. Custom shelf life planning: There might be genuine regular components or finished goods with limited shelf life or ship life, in which case the custom object is helpful in accounting that constraint in the SNP Optimizer.

4. Multilevel SKU grouping: There may be more than one dimension of the grouping to be considered while planning (e.g., flavor, allergen, or size). It is possible to construct multi-layered SKU grouping definitions using the model defined in this document.

A Comparison of SKU Group Planning Strategies

Table 1 shows the advantages and disadvantages of the three SKU group planning strategies.