Introduction to SAP APO GATP

What This Article Covers

  • An Explanation and Introduction to PP/DS
  • GATP and CTM
  • Availability Checking
  • Available to Promise
  • Different Levels of ATP Checks
  • Multilevel ATP Check (M-ATP)
  • Availability Checking for Kits (or BOM)
  • Rules-Based Availability Checking
  • What Attaining ATP Proficiency Can Mean
  • Capable to Promise
  • ATP Tree Structure
  • Scope of Checking
  • The GATP Time Horizon

Introduction

The need to provide commitments back to customers is called available to promise (ATP) capability. This is a capability offered by operations to sales. Strong ATP functionality is important to a company’s credibility with its customers. And while this is a desired state, unfortunately, there are many cases where companies make promises to customers without knowing if they can actually meet the demand. The ability to provide a solid promise quantity can allow a company to better use its internal resources and keep its customers satisfied. Of all of the applications in SAP SCM, Global Available to Promise (GATP) is often considered the most difficult to explain and, as a result, the most difficult to understand. This isn’t because the concept behind GATP is so difficult to grasp (in fact, it’s quite straightforward) but because the implementation and design of GATP is quite involved and dependent on other SAP SCM applications and SAP ERP. A few reasons for the general opaqueness of the application include the following:

  • ››GATP is actually a much more complex concept of availability checking, which is the background with which many people come to GATP.
  • ››There are a number of different ways of implementing GATP and different types of ATP that can be provided by GATP.
  • ››The GATP configuration is the least straightforward of the SAP SCM applications. The configuration screens lack an inherent logic that the other applications have.

Because of these factors and the limited information available on GATP, we’ll only cover the fundamentals in this chapter and provide you with as much depth about the basics as possible. To maximize your understanding, let’s begin by drawing the parallel between Capable to Match (CTM) and GATP.

GATP and CTM

CTM is a much easier area of functionality to understand, and because there are a number of similarities between CTM and GATP, it’s a good place to start.

Let’s look at the similarities between CTM and GATP:

  • ››Orders or planned orders are associated with inventory or production capacity.
  • ››Supply selection is performed in both applications.
  • ››Both can be connected to PP/DS and allocate productive capacity to customers. In both cases, this is an optional way of running the applications.
  • ››Both use ATP categories. (ATP categories are the represent stock, requirement, forecast, and receipt categories, all of which can be turned on or turned off during an ATP check).
  • ››ATP categories represent both sides of the supply and demand equation.
  • ››Both processes deal in terms of allocation and priorities. CTM generates the allocations, while GATP represents these allocations to the order management system.
  • ››As of SAP SCM 7.0 (for GATP), both CTM and GATP can schedule backwards and forwards.

Pegging is used in SAP SCM to describe a connection between demand and actual inventory. Allocations are used to describe a connection between demand and future inventory.

However, in addition to these similarities, there are also differences, and understanding these differences will help you understand GATP.

  • ››GATP is performed in real time and connects back to the order management system (either SAP ERP Sales and Distribution [SD] or Customer Relationship Management [SAP CRM] in a 100% SAP solution). CTM doesn’t connect in real time to any order management system but instead performs its processing in batch.
  • ››Giving priority to certain customers over other customers who have ordered earlier is the heart of CTM. GATP allocation is based upon who places a request first. CTM is based partially on who places the order first (particularly if fixed pegging is selected); however, CTM also allocates inventory on the basis of the customer priority level. So while CTM uses both time and priority to allocate, GATP works primarily on time.

So now that you have an idea of the differences and similarities of GATP and CTM, let’s look at GATP within the broader umbrella term of availability checking.

Availability Checking

Availability checking is the standard functionality of SD. It provides a return date and quantity on planned sales orders, which leads to a distinction that should be understood. So, it’s important to differentiate between availability checking, which is the functionality in SAP ERP, and availability to promise in GATP. This is an important distinction to draw because on projects, these terms are often used interchangeably, so being unaware of the differences can lead to confusion. Availability checking is a broad category of obtaining information on material availability that can cover both current on hand as well as planned on hand. There are several types of availability checking available from different areas within SAP. Figure 6.1 shows both the types of availability checking and their location within SAP.

Available to Promise

Available to promise (ATP) is a type of availability checking offered in GATP. However, it’s not the only type of availability checking provided by the GATP application. Another form of availability checking is called capable to promise (CTP), which we’ll discuss later in this chapter. ATP provides extra functionality over SD availability checking, which makes it significantly enhanced. One of the major differences between availability checking in SAP SD and in GATP is that GATP looks out across many different locations, comparing forecasted inventory positions with planned demand, and returning both a promise quantity and a location that will satisfy the demand. It can continue searching until it finds a location, even a location distant from the customer, which can satisfy the demand. GATP not only returns a confirmation on requested quantities and dates but also different alternatives regarding when material might become available. It can present this to SAP ERP or SAP CRM, or other order acceptance systems, and the customer connecting to these systems then

has an opportunity to accept or reject the altered proposal. As with availability checking, after the customer provides a confirmation on the commitment, it becomes a planned order and an allocation. This has the immediate effect of reducing planned capacity or planned inventory, or both. Much like CTM, a specific customer is allocated inventory or production capacity. GATP has complex application interactions, as shown in Figure 6.2.

GATP can be seen as an intermediary between the SAP SD and SAP CRM applications and the SNP and PP/DS applications. GATP holds the planned inventory and planned orders in liveCache with GATP in a way that allows the application to provide a real-time response. For the solution designed as just described to work, GATP must be continually updated with information from SNP and GATP. Basic Functionality and Concepts of GATP The specific supply and demand elements that can be included in an ATP check are listed here:

  • ››Supply
    • –– Warehouse stock
    • –– Planned receipts
    • –– Production orders
    • –– Planned orders
  • ››Demand
    • –– Sales orders
    • –– Deliveries
    • –– Reservations

Different combinations of these elements can be selected to be included in GATP during configuration.

Different Levels of ATP Checks

There are different levels of ATP checks. Each has different functionality and also different levels of configuration and maintenance effort, in addition to different levels of data update and quality requirements. The different levels of ATP check are shown in Figure 6.3.

Multilevel ATP Check (M-ATP)

Multi-level ATP is designed for assemble-to-order operations and for configurable products. Like CTP, which we discuss in a few paragraphs, this architecture connects GATP to PP/DS. The difference is that the output of this ATP check is stored in an ATP tree structure. The ATP tree structures store the ATP check output for the short term, until the ATP check output is converted to receipts in a batch process.

Multilevel ATP checking is advantageous when the subassemblies to the prospective sales order are already manufactured or procured, and they aren’t placed in final assembly until they receive a sales order. This provides maximum flexibility to the manufacturer and allows for lower inventory costs. There are two ways of running the M-ATP check: ››Automatic source determination

  • ››Two-step process:
    • –– The plan for requirement is exploded
    • –– The sales order is entered for configured products

Availability Checking for Kits (or BOM)

This method of ATP requires integration with SAP CRM. A kit is a combination of items that are planned together, while a BOM is a series of co-planned items that result in a manufactured or assembled item. If stock for the kit or BOM is available, the extent of the interaction between ATP and SAP CRM is limited. However, if no kit or BOM stock is available, this method of availability checking has GATP connecting to integrated Product and Process Engineering (iPPE) to schedule kit production. iPPE enables PP/DS to collect all of the data for an entire product lifecycle in one integrated model. It’s particularly well suited to products with many variants and to repetitive manufacturing.

Rules-Based Availability Checking

Rules-based availability checking allows the check to be performed with either substitutes of the same product at different locations or alternate PPMs. This requires the set up of rules that control the ATP process. These rules, which control substitution such as product substitution and location substitution, are managed in integrated rule maintenance and are part of the master data of GATP.

Rules-based availability checking allows a high degree of configurability for the ATP check. For instance, it could set up the system to look in the same location for a substitutable product, in a different location for only the requested product, or some other combination.

What Attaining ATP Proficiency Can Mean

GATP has a powerful set of functionality, and if implemented correctly, a company with ATP capability can gain great credibility with its customers. This is because ATP allows a company to commit on orders with credibility. By reducing the need to move around and reallocate inventory to different customers when delivery dates approach, it greatly increases execution stability. In addition, all other things being equal, a company with reliable delivery dates should pick up market share from those competitors that lack this capability and over-promise to these same customers.

Capable to Promise

SAP calls this an availability check, not an ATP check. However, in other documentation, SAP shows both CTP and multilevel ATP checking as subcategories of availability checking that calls PP/DS. Regardless of its categorization, from the supply side, not only can planned inventory be included in the analysis but also planned production capacity. SAP SCM performs this by including PP/DS in the ATP check. Incorporating production capacity in the ATP process changes the definition of what is being done from ATP to CTP. The change in terminology is clear from what is planned to be available, which is the future planned inventory position, to what is “capable” to promise, or what the factory capacity could produce.

One way to break down the different ATP methods is by defining which ones connect to PP/DS and which ones only check inventory (Figure 6.4). Using PP/DS with GATP allows for the allocation of capacity in addition to the allocation of inventory, providing a higher degree of integration between your customers.

When using PP/DS in conjunction with GATP, the following apply:

  • ››A PP/DS horizon must be created for the product and stored in the product location master.
  • ››In the active version, it’s important to have PP/DS set to change active planning.
  • ››The structure link of the “Standard Planning Procedure 3” should be configured.
  • ››There should be no order splitting or partial delivery.
  • ››PP/DS should be called with the location determination activity.

In addition, there are specific heuristics you should run in PP/DS in conjunction with CTM:

  • ››SAP_PP_CTM Planning Shortage Quantities
  • ››SAP_PP_003 (this adjusts the procurement proposal for the finished product, if you’ve reduced the requirements quantity in the sales order)

Similarities Between CTM and M-ATP

Many people notice the similarities between CTP and M-ATP and naturally ask how the two compare. The best way to think of it is that M-ATP is a lighter version of CTP. M-ATP provides less time-specific results than CTP. While results are stored in the ATP tree with M-ATP, in CTP, the orders are created immediately within PP/DS. Other differences include that CTP schedules using the detailed scheduling portion of PP/DS, and M-ATP uses lead times to derive dates. Also, CTM considers lot sizes, while M-ATP doesn’t. From these differences, you can see that CTP is a much more involved and feature-rich solution, but the advantage of M-ATP is that it takes far fewer computing resources. The right solution for your company depends on the accuracy required as well as the project’s budget.

The topic of PPMs and PDSs was covered in Chapter 5, Production Planning and Detailed Scheduling (PP/DS), however, we wanted to mention here that if either the PPMs or PDSs aren’t constrained, then the ATP value and date will be returned, but there’s no guarantee that the quantity is feasible. That is, there’s no guarantee that the quantity can actually be met because the planning, in this case, is being performed with the assumption of infinite capacity. However, the main point of ATP and CTP is that the ATP value and date are realistic. If all products are procured, then GATP is only dependent upon the accuracy of the plan produced by SNP. ATP begins to get particularly complex when it takes productive capacity into account because this becomes more involved than simply checking against planned inventory. This makes perfect sense in that ATP is checking the planned inventory, or checking against what is planned to be available, and CTP checks against both what is available and what is capable of being produced.

ATP Tree Structure

GATP also has the ATP tree structure that we’ve referred to several times already. ATP tree structures are used for storing data not returned to the calling system (either SAP SD or SAP CRM). For instance, there is an ATP tree structure for each request schedule line in the sales order that contains the requirements data for the finished products and components. This can be thought of as a buffer for GATP that is used to enhance performance. It exists because continually creating receipts generated by GATP in PP/DS and SNP would degrade the performance of the system. This conversion with the ATP structure can be performed during off peak times when few people are on the SAP SCM system. ATP tree structures are used for the following:

  • ››Backorder processing
  • ››M-ATP checks (they are particularly important here because M-ATP connects to PP/DS, and this interaction is resource consuming)
  • ››Third-party order processing

Third-Party Order Processing

Third-party order processing is one of the most interesting aspects of GATP. This is where GATP presents the availability and receives commitments on requests from a customer, while the fulfillment of the request is performed by a supplier to the owner and maintainer of the GATP system. This opens up a possible state where the information system is separated from the company actually performing the logistics functions, and it also opens up a number of alternatives for new ways of doing business. Third-party order processing is accomplished by setting up supplier profiles in GATP configuration, and then assigning products to these suppliers. By leveraging this functionality, GATP can be run by a company that simply manages systems but has no factories or even any inventory or warehouses. Third-Party Order Processing at Amazon.com A good way to think of this is how Amazon.com operates. They match customers and suppliers through the website. Sometimes Amazon is selected as a vendor, but often another supplier showcased on the site is selected. Either way, Amazon manages the matching process and the customer contact, and maintains the data of the on-hand balances of different direct-to-customer suppliers. It’s a similar concept to third-party order processing in GATP, but GATP is providing commitments based on both current inventory and planned inventory. Amazon is only matching demand with current supply, so the time horizons between Amazon.com and GATP are very different. GATP can look out for planned on-hand and productive capacity far into the future, providing specific commitment dates. Amazon.com also provides geographic shipping differences, which you can read more about at https://sapplanning.org/2009/05/07/gatp.atp.trees and amazon.com.

Amazon

Amazon does allow pre-ordering, but it doesn’t work the same way as its ordering for items that are currently in stock. How these pre-orders are allocated against future inventory or serves as a signal to increase production is unknown to us. However, there is no confirmed date on pre-ordered items. On the other hand, stocked items do have confirmation dates.

We can also use Amazon.com as an example of a well functioning ATP system because it’s a system that many people use and can be immediately referenced simply by visiting the site and placing items in the shopping cart. The company is also a leader in connecting many vendors seamlessly into its website. Amazon could, if desired, stop fulfilling orders and simply serve as a website to match supply and demand. By understanding Amazon.com, both from the web frontend and the inventory backend, it’s easier to understand GATP.

Scope of Checking

During an ATP check, the scope of the check must be defined. Table 6.1 shows some of the alternatives that the ATP check can be applied against.

These are all optional entries, and GATP can be configured to include all of these, or any combination of them. However, inclusion or exclusion of each stock or receipt element greatly affects the GATP output, and the decision needs to be fully analyzed. A very important setting for GATP is the time horizon, which has a strong influence on system performance, as well as how far out allocations can be set. We’ll move to this topic now.

The GATP Time Horizon

Performing the ATP or CTP check is a computationally intensive activity. One way to help place a boundary around the problem and reduce the time spent computing a result is by limiting the time horizon. This is a common strategy throughout SAP SCM. To use this strategy, GATP is set to limit its checking to a defined horizon, beyond which requirements aren’t checked. This is called the checking horizon. This horizon is entered in the ATP tab of the product location master. This means that different checking horizons can be set not only for a specific product but also for a product location. However, in most cases, a single product usually has one checking horizon, and groups of products usually have the same checking horizon. But it’s important to know the option does exist. To go to the ATP tab where the time horizon is set, go to product location master by choosing APO • Master Data • Product • Product. Then on the introductory screen, add a Location, so the system takes you to the product location master rather than just the product master. After selecting the return key, navigate to the ATP tab (Figure 6.5).

Now that we’ve discussed the functionality of GATP, let’s move on to the technologies that make GATP possible.

liveCache What GATP is doing as an application is impressive when you consider what’s going on behind the scenes. GATP looks out across many locations, for many periods, and can also return with changed proposals. The fact that this is done in real time means that GATP is the most computationally intensive of the SAP SCM applications. Not coincidentally, it’s also a key user of liveCache. Integration The sales process is managed in SAP ERP, however, GATP is within SAP SCM. ATP requests are communicated in real time to GATP, so the integration between SAP ERP and SAP SCM is the bottleneck to this process. We aren’t aware of a more real-time interaction between SAP ERP and SAP SCM than the interaction between SAP ERP and GATP. GATP Release History As one of the original applications, GATP has seen fewer improvements in recent releases than many of the other applications. SAP SCM 5.1 (SAP SCM 2007) improvements included:

  • ››ATP check can only consider substitute products from master data for interchangeability that belong to the interchangeability supersession chain group type. ››Enhanced ATP characteristics view.
  • ››Rules-based ATP checks can be defined to access the input products, input location product before the substitute product, substitute location, or substitute location product. SAP SCM 7.0 improvements include the following:
    • ››New capabilities for consignment of vendor-managed inventory such as a consignment indicator, shipment split, and consignment stock in transit.
    • ››GATP now supports backward consumption.

The enhancement that GATP needs but hasn’t had is a redesign of the configuration screens.

Conclusion

GATP is a sophisticated application that is best considered by companies that are already at an advanced state in their supply chain planning. Applications such as SNP depend on the quality of data in SAP ERP and, in some case, the quality of data coming from other applications in SAP SCM. However, GATP depends on everything that SNP depends on, in addition to the quality of the overall supply plan from SNP. GATP is demanding in terms of data quality and the implementation quality of the applications it relies on. GATP is one of the most resource intensive of all of the SAP SCM applications. However, if implemented correctly, GATP can provide a significant advantage to your company. In the next chapter, we’ll move on to cover transportation planning and vehicle scheduling.

Advice on Enjoying the Multimedia Presentation

To see the full screen just select the lower right-hand corner and expand. Trust us, expanding makes the experience a whole lot more fun.

 

This presentation illustrates the problems with SAP support and how Brightwork SAP Support addresses these shortcomings. 

What Kind of Support is This?

If this does not sound like standard support, you are right. And that is the point.

We designed our support to help our customers get the most out of SAP, not to maximize our margin or to try to protect previous sales inaccuracies. We know how to get your SAP applications working better.

To see the broader information about our SAP support see our main SAP Support Page.

References

Setting Up the Supply Network Book

NETWORK

Setting Up the Supply Network in SAP APO

Constructing Supply Networks

The only book on supply planning to focus entirely on how to configure supply networks in APO, and how to meet highly customized requirements that relate to supply network design. You won’t even find these topics covered in depth in SAP Training classes.

Serious Network Setup in APO

Through extensive use of graphics and screen images, this book will familiarize you with Supply Network Planning in SAP APO and show you what you need to do to design supply networks for real-life applications, where common business requirements necessitate a nonstandard system design.

After reading this book you will:

  • Be able to set up master data objects for the supply network.
  • Have a detailed understanding of the two primary data objects in APO: locations and transportation lanes.
  • Understand multi-sourcing – the ability for a supply planning system to choose intelligently between alternate sources of supply.
  • Know how to design the supply network for complex and non-standard workflows, such as planning locations that are external to the supply network.
  • Understand how to manage storage locations with MRP Areas for allocation and GATP.
  • Be able to model intercompany transfers.
  • Consider all aspects of network design, including physical master data set-up, parameters, planning run sequence, problem division, how and when billing documents are created, and more.
  • Learn when a parallel simulation version of the supply network is appropriate — and when it is not.

Chapters

  • Chapter 1: Introduction to the Supply Network
  • Chapter 2: Locations in APO
  • Chapter 3: Transportation Lanes
  • Chapter 4: Sources of Supply and Multi-Sourcing
  • Chapter 5: Managing Storage Locations with MRP Areas for Allocation
    and Global Available to Promise (GATP)
  • Chapter 6: Modeling Intercompany Transfers
  • Chapter 7: Capacity-constraining Vendors/Suppliers
  • Chapter 8: Conclusion
  • Appendix A: The Supply Network and Simulation
    References

Introduction to SAP APO SNP

Executive Summary

  • This is an explanation and introduction to the basic concepts of SNP.
  • We cover the reality of SNP functionality and usage.

Introduction

In this article, you’ll get a high-level overview of the entire SAP APO SNP.

Having a responsive supply network that can seamlessly integrate with your own systems is critical in a demand-driven market. With Supply Network Planning (SNP) in SAP APO, you can achieve this goal. SNP manages your supply network and the planned inventory positions at all of your product locations. The common outputs of SNP drive the procurement and production processes with requirements that have been filtered through SNP and managed in a way to provide systematic procurement and production signals that are, in some cases, constrained and realistic. SNP is important in matching supply with demand. When both SNP and Global Available to Promise (GATP) are implemented, the supply plan from SNP is used to commit on requests, and when allocation is performed, the inventory from SNP is allocated by GATP.

SNP as the Heart of APO

SNP is often considered the heart of SAP APO because it ties together many of the other SAP APO applications. Those implementing SNP must be keenly aware of the interrelationships with other SAP APO applications. SNP is about managing the inventory at all of the locations that make up the supply network, which is all of the stock holding locations (warehouses, manufacturing plants, regional distribution centers, even retail stores, in some cases). Although there are several ways to achieve your supply network plan objectives, the end result of your supply plan should be to have the best possible inventory position per location along with the necessary transactions being sent to the execution system to make this happen.

Taking the Demand Plan

At the highest level, your demand plan, which is a time bucketed forecast that either begins as or is eventually disaggregated to a product level, is compared with the stock on hand and in-transit to determine your production, procurement, and inventory repositioning decisions. This demand plan can come from SAP DP or other demand planning applications.

The strength of the system is its capability to look out to the edge of the planning horizon (which is set as a parameter); incorporate all of the planned inbound and outbound material movements, along with the future expected demand; and make decisions that put the company in the best position to meet demand at the lowest possible cost. A 100% SAP solution looks like Figure 4.1.

Basic Functionality and Concepts of SNP

SNP is designed to plan the movement of material through a supply network. The supply network is made up of locations, connected by transportation lanes. Methods of Running SNP SNP can be run in three ways: heuristics, Capable to Match (CTM), or the SAP Optimizer. The method you select will have a great effect on the implementation and on the resulting output. The decision to select one method or another is often due to company characteristics such as the following:

  1. 1Whether the company is generally supply constrained
  2. Whether the company maintains good cost data and can agree on how these costs are to be applied
  3. The effort the company is willing to place in both the implementation and in the maintenance of the solution

The SNP Optimizer

The methods differ along a number of dimensions. For instance, optimization is the most time consuming of the methods for running SNP. The time it takes is understandable when you consider what the optimizer is doing. SAP Help describes this in detail:

“The SNP optimizer takes into account all model constraints simultaneously. This means that the optimizer takes into account the available capacity of all resources at the same time. Thus, during multilevel production, for example, all the manufacturing levels are incorporated simultaneously into planning.”

The optimizer is designed to result in the best possible plan with respect to constraints such as transportation lane capacity and warehouse capacity. However, “best” is subjective and based on assumptions. So if “best” to your company means meeting requirements at the lowest possible operational (not implementation) costs, then the optimizer is the “best” of the three methods. However, the optimizer has the highest implementation and maintenance cost.

This is primarily because the detailed cost information required to set up and run the SNP optimizer takes a great deal of effort to build, agree upon, and maintain. Many companies find that they simply don’t have this level of detail and can’t commit to developing it. In our experience, optimization is beyond most companies.

To run the optimizer, you need to quantify the following costs:

  • ››Production
  • ››Storage
  • ››Transportation
  • ››Procurement

The SNP optimizer runs through a routine that creates a number of different plans that each result in a different cost calculation. It then selects the plan that produces the lowest overall costs. The optimizer also attempts to minimize costs while meeting the demands placed upon the system. It performs this optimization against constraints that are the natural limitations of the supply network, such as transportation and storage capacity.

The SNP Network and Deployment Heuristic

On the opposite site of the complexity and implementation effort continuum from optimization is the heuristic method. Because they are less precise, heuristics, or “rules of thumb” as they are colloquially known, are the fastest way to arrive at a solution. The use of heuristics shares some similarities to using Materials Requirements Planning (MRP) in SAP ERP, but they provide far more flexibility than MRP. Heuristics are also the easiest to implement, and planners can usually understand what heuristics are doing most easily of the three methods.

Furthermore, a number of heuristics are designed for specific problems, so combining heuristics can lead to a solution that is customized to a given planning situation. Unlike CTM or optimization, heuristics require a multistep planning process. After heuristics are run, capacity leveling is performed to move loads off of overcapacity periods and resources. Because the process is so close to MRP, if you want the most incremental change possible from MRP, heuristics are a good alternative.

Capable to Match

Capable to Match (CTM) is the third way of running SNP. CTM is suitable for clients that are resource constrained and that have a number of customers that they need to allocate inventory to in a prioritized manner. A simplified way of thinking about this planning approach is that the end result of a CTM plan is that higher priority customers take inventory from lower priority customers. For example, between two customers of different priority that place their orders on the same day, the higher priority customer receives a full allocation, and the lower priority customer receives whatever is left over. Depending on whether fixed or dynamic pegging is used, a day later a higher priority customer can place an order and possibly take all of the inventory from both of the previous customers.

Fixed pegging means assignments are permanent; dynamic means the assignments can change on each successive planning run.

Capable to Match Configuration

Let’s look at some of the configuration details for CTM. CTM is primarily configured through CTM profiles defined in Table 4.2.

The important things to know about configuring the CTM profile are that you can set multiple parameters differently between the profiles; there’s no limit to the number of profiles you can create, and they can be copied over providing a high degree of flexibility in terms of how CTM is run and how the parameter data for CTM is maintained.

Figure 4.2 shows the CTM Planning Scope tab, which is where the Master Data Selection of the CTM Profile is selected. This determines what will be included and what will be excluded from the planning run.

Figure 4.3 shows the Strategies tab of the profile, which controls critical settings such as whether CTM should use fixed pegging or dynamic pegging. The pegging type has important implications for system performance as well as for which companies receive allocations.

Fixed Pegging assigns the requirement to the supply once, and Dynamic Pegging reassigns requirements that were assigned to supply in previous runs again, and during every new planning run. Another important setting is the scheduling direction that directs CTM to schedule before or after the lead date minus the total lead time.

While prioritizing customers is the most implemented prioritization method in CTM, CTM can prioritize requirements a number of ways:

  • ››Location
  • ››Delivery priority
  • ››Product number
  • ››Desired quantity

The entire CTM logic is based on the idea that the implementing company is capacity constrained. However, companies don’t stay constrained, or at the same level of constraint as time passes. In some years, for instance, during recessions, companies that were previously capacity constrained can find themselves with overcapacity, so you need to discuss this topic during the implementation. Technically, CTM can be run without capacity constraints, and although this undermines the concept, companies do model this way.

SNP Resources

Resources are used in multiple applications in SAP APO to model constraints in the supply chain. Of all the SAP APO applications, resources are used most in PP/DS. However, SNP, TM, and SAP EWM all use resources. SNP resources come in more of a variety than the resources in the other applications because SNP is modeling more types of activities, though at a higher level.

For instance, SNP uses transportation resources, which are similar, although used differently than vehicle resources used by TM. There are different types of resources because there are many types of constraints in the supply chain. The resources in SAP APO that apply to SNP are listed in Table 4.3.

Common SNP Objects

SNP has a number of the same elements as SAP DP, so if you just read Chapter 3, these will be familiar (Table 4.4).

Capacity Leveling

Capacity leveling is performed as part of the heuristic planning process and for specific bottleneck resources (resources that restrict the capacity of the operations). Under heuristic planning, constraints aren’t set, and the plan is allowed to place an unlimited amount of capacity on resources. This is the first step of the planning process when using heuristics. The second step is called capacity leveling. Capacity leveling moves loads that are too high for the resources to before or after the period of time of the request date.

This results in either excess inventory being held (if moved prior to the request date) or an order delay (if moved after the request date). But if customers can know this far in advance, they can either accept or reject the schedule adjustment. Rejecting it usually means you’ll have to search for other suppliers. However, even when you have to turn away customers, your credibility could be enhanced because the customer has ample time to make alternative arrangements.

Capacity Leveling Profiles

Profiles are used to control the capacity leveling process. This allows for the reuse of the same capacity leveling profile options, which can be configured. Table 4.5 shows several of the options in the profile.

This concludes our look at the different methods for running SNP, so let’s move on to other aspects of the application.

The Planning Book

As with SAP DP, SNP also uses the planning book to provide planners and users with a view into the planning data. SNP comes with a number of standard planning books that enable the following functionality:

  • ››Sales and Operations Planning
  • ››Interactive SNP and Transport Load Builder
  • ››DRP
  • ››VMI
  • ››Interactive Scheduling Agreements
  • ››Hierarchical Planning
  • ››Product Interchangeability

The planning books are all designed for specific processes, but planning books can be created flexibly to customize the view for the various planners.

The planning books, in addition to custom reports, are important ways for planners to gain information from and interact with SAP APO (Figure 4.4).

SNP stores the data that is in the planning book in a way to support user needs, which we’ll discuss next. liveCache and Data Storage SNP allows data to be stored in several ways:

  • ››liveCache time series objects
  • ››liveCache orders
  • ››InfoCubes

While InfoCubes are long-lasting structures stored in the SAP DP Data Mart and designed to be repeatedly queried, liveCache is designed to provide performance and storage for values that constantly change. The pegging, which connects demand elements to supply elements, occurs in liveCache. After pegging has been performed, the data is moved out of liveCache into the normal SAP relational database. Safety stock mitigates variability in the supply chain. SNP Subcontracting SNP can plan not only the internal capacity of the company that implements and manages SNP but the capacity of subcontractors.

This capacity setup data originates from SAP ERP and is imported into SAP APO as a subcontract relationship. You’ll gain significant extra functionality if you use SNP production process models (PPMs), which are the source for obtaining products that are produced internally. PPMs allow for production planning to be modeled at a high level within SNP. These PPMs represent production capacity that resides at the subcontractor’s plant. Another method of incorporating external partners is through SAP SNC.

SNP and Supplier Network Collaboration

Planning subcontracting material is becoming increasingly common. To meet this growing need, SAP has invested significant development effort in enhancing the functionality in Supplier Network Collaboration (SAP SNC). SNP even has its own subcontracting planning book view that ships with the product. This allows SNP to incorporate the subcontracting planning process. And this is where the planners view the input from business partners that may be in far away subcontract suppliers, but which are collaborating with the company that has installed SNP.

SNP Product Location Tabs SAP APO has a large number of settings available for SNP on the product location master tabs, which are where the parameters are located that can significantly alter the output of the supply plan based on their configuration. Table 4.6 provides a synopsis of each of the tabs and the controls that are contained within them.

SNP Deployment

SNP Deployment controls which requirements will be covered by a shortage of supply and which won’t. Deployment is required where the plan doesn’t pre-position sufficient inventory to meet all demands.

It allows stock to be distributed among locations that are vying for the same inventory by the following alternatives:

  • ››Deployment heuristic
  • ››Deployment optimizer
  • ››Real-time deployment (essentially similar to the deployment heuristic) Deployment Heuristic Under the heuristic method, there are two ways to use deployment heuristics:
  • ››Fair share
  • ››Push The applicability of each depends on whether the planning company’s products are over or under supply. If a product is under supply, the method called fair share is used to allocate the inventory to competing locations. There are several ways to run fair share in terms of allocation:
  • ››Proportional distribution (based upon previous demand allocation)
  • ››Proportional fulfillment of target stock
  • ››Quota arrangements The push method takes care of the opposite problem, where there is too much supply that needs to be pushed out to forward locations.

The following list is a sample of some of the ways that push distribution can be performed:

  • ››Pull distribution
  • ››Push distribution by demands
  • ››Push/pull
  • ››Quota arrangement

The deployment Optimizer Like the standard SNP optimizer, the deployment optimizer works off of costs that have been set up by the configuration team. However, it also can follow distribution rules and constraints that are set up in the SNP deployment profile. This concludes the review of the SNP functionality, So let’s wrap up the chapter with a look at the release history and then a brief case study that shows SNP in a real-world scenario. SNP Release History Because SNP is one of the original applications, it has received only minor updates for the past few releases. But some of the most important improvements in SAP APO 7.0 include:

  • ››Enhanced queue processing
  • ››Enhanced supply demand matching
  • ››Characteristic-dependent planning, shelf life planning Case Study Company This high-tech consumer electronics manufacturing firm is in multiple consumer and business electronic markets globally with a strong focus on product lifecycle management.

Conclusion

SNP is one of the most implemented applications in SAP APO. It provides a strong combination of functionality, is highly flexible, and can incorporate both supply constraints and production constraints (with the use of PPMs and PDSs). SNP is a very good introductory application to begin using SAP APO due to its logical design, deep functionality, and flexibility.

Advice on Enjoying the Multimedia Presentation

To see the full screen just select the lower right-hand corner and expand. Trust us, expanding makes the experience a whole lot more fun.

 

This presentation illustrates the problems with SAP support and how Brightwork SAP Support addresses these shortcomings. 

What Kind of Support is This?

If this does not sound like standard support, you are right. And that is the point.

We designed our support to help our customers get the most out of SAP, not to maximize our margin or to try to protect previous sales inaccuracies. We know how to get your SAP applications working better.

To see the broader information about our SAP support see our main SAP Support Page.

References

Setting Up the Supply Network Book

NETWORK

Setting Up the Supply Network in SAP APO

Constructing Supply Networks

The only book on supply planning to focus entirely on how to configure supply networks in APO, and how to meet highly customized requirements that relate to supply network design. You won’t even find these topics covered in depth in SAP Training classes.

Serious Network Setup in APO

Through extensive use of graphics and screen images, this book will familiarize you with Supply Network Planning in SAP APO and show you what you need to do to design supply networks for real-life applications, where common business requirements necessitate a nonstandard system design.

After reading this book you will:

  • Be able to set up master data objects for the supply network.
  • Have a detailed understanding of the two primary data objects in APO: locations and transportation lanes.
  • Understand multi-sourcing – the ability for a supply planning system to choose intelligently between alternate sources of supply.
  • Know how to design the supply network for complex and non-standard workflows, such as planning locations that are external to the supply network.
  • Understand how to manage storage locations with MRP Areas for allocation and GATP.
  • Be able to model intercompany transfers.
  • Consider all aspects of network design, including physical master data set-up, parameters, planning run sequence, problem division, how and when billing documents are created, and more.
  • Learn when a parallel simulation version of the supply network is appropriate — and when it is not.

Chapters

  • Chapter 1: Introduction to the Supply Network
  • Chapter 2: Locations in APO
  • Chapter 3: Transportation Lanes
  • Chapter 4: Sources of Supply and Multi-Sourcing
  • Chapter 5: Managing Storage Locations with MRP Areas for Allocation
    and Global Available to Promise (GATP)
  • Chapter 6: Modeling Intercompany Transfers
  • Chapter 7: Capacity-constraining Vendors/Suppliers
  • Chapter 8: Conclusion
  • Appendix A: The Supply Network and Simulation
    References

How to Replace the Optimizer in SNP and PP/DS

Executive Summary

  • The real story on SNP and PP/DS is considerably different than what SAP proposes.
  • The optimizer cannot be made to run properly in either application and this is why we recommend turning the optimizer off and using an external optimizer with APO database.
  • SAP support is misleading many customers into continuing down a path that will never work.

Introduction to the SAP Optimizer

SAP has had long-term problems on its optimization projects. This includes both the optimizer in SNP and the optimizer in PP/DS. You will learn these issues in this article.

SNP and PP/DS

The SNP optimizer is designed to create a plan for the initial supply plan (usually the MRP run in ERP) and the deployment plan (generally called the DRP run in ERP).

The PP/DS optimizer is designed to create a production plan and production schedule.

Both optimizers use the ILOG optimizer to perform the optimization.

The Real Story with SNP and PP/DS

PP/DS: There is an optimizer in SAP’s production planning and scheduling module (PP/DS), but no client that I have ever seen or heard of actually uses it.

SNP: Within SNP the same optimizer does two different things.

  1. The Network Optimizer Run: It plans the initial network supply (production and purchase orders)
  2. The Deployment Optimizer Run: It produces stock transport orders to move material through the supply network.

I have performed quite a lot of work in troubleshooting these optimizers. This includes reviewing the output as well as pulling data out of the log file to chart the time it takes to run the optimizer and explain the results to management.

I have concluded that the 2nd optimization run, the deployment optimizer makes no sense in it output under any circumstances, and should not be used.

This is covered in the following article.

Real Word Recommendations on the Optimizer

I told this client to disable the deployment optimizer and the COPT 10 parameters that were supposed to improve the output (that SAP sold them for $50,000) — was not usable. The IT director did not appreciate the research that I did as he wanted me to use my credibility to tell the business that the output was good and they needed to start using it. Just two months ago I was contacted by a recruiter representing that same company, and they are still looking for someone to come in and help them fix the deployment optimizer. This is because IT does not want to admit that they made an error when selecting the optimizer many years ago.

The network deployment optimizer does produce usable output, but it is probably the most difficult procedure to test that I have run into since I started working in advanced planning back in 1998.

SAP had a specialist in the optimizer in Germany, or at least he was working there several years ago. SAP charged something like $400 per hour for him, and mostly what he did was say that the optimizer was working as it should. At multiple accounts, I saw the same thing. Typically IT would hire him; he would say everything looked great to him, and then IT would go and tell the business to stop complaining because the optimizer has been blessed by SAP’s top Ph.D. on the topic.

The State of ILOG

SNP uses the ILOG optimizer. ILOG was an independent company, but it was purchased by IBM. And like most IBM acquisitions, their profile declined a great deal after the purchase. Now no one talks about ILOG. Most software vendors do the same thing. They buy an off the shelf optimizer and then write parameter controls and user interfaces for configuration around it. When I usually tell my clients that SNP uses ILOG, they are normally very surprised. SAP does not communicate anywhere that it uses an off the shelf optimizer.

Pulling the Optimization out of SAP

One way of interpreting is whether there is an off the shelf optimizer that can be found. The answer to that question is there certainly is. I have never participated in a project like this, so I can’t say how it would work exactly. But it could be possible to switch out the ILOG optimizer for another off the shelf optimizer — and then have that optimizer adjusted by the people that specialize in it. I can reach out to a colleague of mine who has a recent start-up and is at a level of detail below me as he has written code around optimizers.

The second question is whether there is another optimization application that performs supply planning. There certainly is. However, since SNP was developed, the industry has moved away from cost optimization for supply planning. Let’s take a short diversion into cost optimization.

What is a Cost Optimizer?

This means that the objective function of the system costs. That is one places the cost of transportation, the cost of storage, the cost of production, etc.. in the system. The optimizer minimizes those costs.

This is what I refer to as a first generation optimizer. SAP copied their design from i2, my old employer. But the approach never really made much sense. I cover this in the following The Rise and Decline for Supply Chain Optimization.

This design harkened back to the mid-1990’s and was an attempt to take the same approach from cost optimization that had been applied to production scheduling. Cost optimizers never really worked very well for supply planning applications. I have thought that perhaps a better approach to optimization is optimization around service levels, and which can treat locations as interdependent stocking locations. The category of software is called inventory optimization and multi echelon planning. These are two different technologies or sets of mathematics in one application. The definition of each are listed here and here.

However, there is a catch….the implementation of these optimizers take a significant amount of time. It would mean throwing away the logic that a company had invested in developing its costs. So recommending them would, at least at first blush, not seem to be a good option.

DemandWorks has greatly simplified optimization in their product Smoothie. Overly complex optimization has greatly damaged the reputation of optimization. But DemandWorks has brought they’re easier to use design optimization.

Conclusion

I can say with a relatively good confidence level that SAP is not providing much value in the updates they are providing the optimizer. Most likely SAP is keeping hope alive by promoting the idea that just more tweaks are required, and the company will finally get what they want. There is a way of finding out, but it means reviewing the output of their system.

Regarding providing them with a recommendation, we need to know more about their history with the optimizer. It may be as simple as finding them an optimizer replacement, but there may be more to it.

SAP’s software has a very low ability to support any supply or production planning business with an effective optimization solution. Paying $400 per hour to resources from Germany in SAP does not lead to good outcomes.

Replacing the optimizer with an external solution is clearly the way to go.

For companies interested in replacing the optimizer from SAP, can reach out to Brightwork for more details.

Advice on Enjoying the Multimedia Presentation

To see the full screen just select the lower right-hand corner and expand. Trust us, expanding makes the experience a whole lot more fun.

 

This presentation illustrates the problems with SAP support and how Brightwork SAP Support addresses these shortcomings. 

What Kind of Support is This?

If this does not sound like standard support, you are right. And that is the point.

We designed our support to help our customers get the most out of SAP, not to maximize our margin or to try to protect previous sales inaccuracies. We know how to get your SAP applications working better.

To see the broader information about our SAP support see our main SAP Support Page.

References

Capacity Planning Book

Combining Two Types of Capacity Planning

This book is called capacity management because it encompasses two areas of planning that are usually discussed independently. Short-term capacity leveling or capacity constraining, which is the movement of demand to fit within the available supply, and long-term capacity planning. This is the planning of long-term market demand to determine if the capacity should be changed.

Using Comparative Applications

In this book, both topics are covered, and they are included using multiple software applications to explain the concepts of capacity management. These are two closely related processes. However, they are often discussed separately. This book combines their explanation as well as their relationship to one another.

By reading this book you will learn:

  • How resources are modeled in capacity management systems.
  • How the structured nature of capabilities leveling and constraining differs from capacity planning.
  • How the various planning processes fit into one another, and where the gaps can be found.
  • The time horizons of the capacity management process.
  • How to improve capacity management at your company.

Chapters

  • Chapter 1: Introduction
  • Chapter 2: Capacity Leveling
  • Chapter 3: Constraint Based Planning
  • Chapter 4: Resources
  • Chapter 5: Forecast Consumption, Allocation, Scheduling Direction and Timing
  • Chapter 6: Capacity Planning with S&OP and the MPS
  • Chapter 7: The Relationship Between Planning Systems and S&OP System
  • Conclusion

How to Best Use Deployment and DRP

Executive Summary

  • Deployment is how inventory is pushed through the supply network and DRP is one method of performing the deployment.
  • We provide a simple way of understanding DRP.

Introduction to Deployment and DRP

To deploy means to move or push. DRP is a particular method of performing the deployment. In this article, you will learn how deployment is performed by DRP in systems.

What is DRP?

DRP stands for distribution resource planning. Because it sounds so similar to the term MRP (material requirements planning), DRP is often referred to, even in publications as distribution requirements planning. In fact, the less official acronym conversion is more logical because DRP was based upon MRP, and uses MRP logic – but without the BOM or production resources, to push material through the supply network.

DRP Definition

  • DRP moves material outbound through the supply network after MRP or the initial supply plan runs and brings material into the supply network.
  • DRP is one of the most important methods in supply chain planning. However, MRP (and DRP) while old, are still the most common methods of performing deployment planning. DRP is one method of creating the deployment plan.

What Supply Planning Thread is DRP Part of?

DRP is one method of creating the deployment plan. But what is being performed is actually deployment. This is moving the material outbound through the supply chain to the final customer.

  • The first is the planning of production orders and purchase requisitions to bring into facilities. This brings material into the supply network, and schedules production (more detailed production planning is performed further on in the workflow by a specialized production planning application). Sometimes this is enabled with the MRP procedure.
  • The second component is the deployment plan where planned stock transfers are created to push material between the internal locations and finally out to wholesale or retail locations. This is sometimes enabled with the DRP procedure.

The Common Usage in Industry of the Term DRP

Many people if not most people in supply chain planning use the term Distribution Requirements Planning interchangeably with the term deployment. This comes from working in environments where the only deployment method that is available or used is Distribution Requirements Planning.

I was at a client that named all of its initial supply planning run profiles in the SNP Optimizer “DRP,” which of course was highly confusing for me optimizers do not run DRP, and DRP is part of the deployment run, not part of the initial supply planning run. Every time someone used the term DRP at this client; they were referring to the initial supply planning run.

So let us first get clear on what is deployment.

The Relationship Between DRP and Deployment

DRP is the only method available for deployment in SAP ERP, or most other ERP systems but it does not exist in SNP, with its closest equivalent being the SNP Deployment Heuristic. However, DRP is only a particular method of performing the deployment. To reemphasize, deployment is the business process, not the method, of moving stock through the supply network. This is shown in the graphic below which showcases the different methods that are used for deployment:

deployment-methods

Distribution Requirements Planning (DRP) is very close to MRP regarding its logic and degree of complexity but is completely different regarding scope. While MRP is used for creating the initial plan (creating purchase and production order recommendations), DRP is used for deployment and only creates stock transfer recommendations between the locations internal to the supply network. In its earliest incarnations, DRP was as simple and limited in its functionality as MRP, but eventually, ERP companies added additional functionality to allow DRP to do things like fair share between locations under conditions of surplus or shortage.

What Distribution Requirements Planning Considers

DRP considers the entire supply network for outbound movements down or through the supply network, whereas MRP is focused only on bringing material into and scheduling production at individual locations. The two supply planning methods also have different levels of granularity. MRP is run first, and DRP is normally the last supply planning procedure to be run. The graphic on the following page describes the focus of DRP in graphical form.

drp

Distribution Requirements Planning for Deployment

Deployment is the main function of DRP. However, DRP is only one method of deployment. Deployment can also be performed by the methods described below.
deployment

 

Deployment Defined

Deployment is defined as the movement of material from locations “higher” in the supply network to locations “lower” in the supply network. Deployment moves material from one level or echelon of the internal supply network down to the next level. In a normal deployment run, parent locations supply specific child locations, and the assignment of child locations to parent locations is held in a table of the supply planning application. These are the valid location-to-location combinations in the supply network. The layers of parent-to-child locations are referred to as “echelons.”

A supply network with more than one hierarchy of parent-to-child locations is called multi-echelon. The term “echelon” was first coined in published form in a 1958 paper by A.J. Clark in which he stated the following:

  • The word ‘echelon’ is used rather than ‘level’ to avoid confusion with stock levels, rather than ‘stage’—although the word has been used in this context—because ‘multi-stage problems’ has recently been used to designate issues in which time is divided into discrete decision intervals or stages.
  • DRP, and deployment generally for that matter, can only create one type of recommendation—a stock transfer recommendation. For this reason, it is run after production planning, MRP, and the initial supply planning run. Stock transfers are created after the planned stock position at each location is determined. By simply using need dates, DRP moves material down through a supply network.

Software that has added functionality uses a push or pull approach to moving material and also considers the following factors:

  1. The Forecast
  2. Actual Demand
  3. Quota Arrangements
  4. Target Stock Level

Below is the Single-Item, Single-Level deployment run screen in SAP ERP. The

options provide a good idea of what the procedure does.

single-item-single-level-mrp

SAP also has a good description of DRP, which I have quoted below.

In DRP, during the net requirements calculation, the system compares available stock and the scheduled receipts from the supply source with planned independent requirements (forecasts) and incoming sales orders. If there is a material shortage (available stock is less than the quantity required), the system creates an order proposal. — SAP Distribution Resource Planning (PP-SOP-DRP)

Distribution Requirements Planning Examples

The application, Demand Works Smoothie, which performs both MRP and DRP, allows the supply plan to be recalculated for the current item and its dependent demand. This can be set up on the policies tab of Smoothie, which can be seen on the following page.

smoothie-policies-tab

smoothie-supply-tab

This view shows how material and inventory flow through the supply network. The push of material through the supply network is performed by the DRP functionality within Smoothie.

A Simple Way of Understanding DRP

Demand Works Smoothie is an application that can be populated by a spreadsheet. When used in production, Smoothie’s application database is normally populated by an external SQL database. However, the fact that Smoothie can be populated from a spreadsheet makes it a very good environment for testing and education. Smoothie creates the entire supply network as a series of links in the DRP BOM table. These links connect the supply network locations together for the model. Locations, which relate to each other and send or receive material to or from one another, are defined by links in the table.

These links are represented by a single tab in a spreadsheet, which is shown on the following page.

smoothie-mrp

Location Links in Distribution Requirements Planning

Notice the simplicity of the setup. Here we have created “links” for some products from the San Diego distribution center (DC) to both the San Francisco and San Jose DCs. The existence of the link sets up a viable pathway, referred to earlier as a valid location-to-location combination or “transportation lane” between the two locations for that product. Other factors that can be populated are the Link Type (zero is a supply link), the Offset Days (the lead time between the locations) and the Factor (how much the product converts to at the new location). For supply planning operations, Factor will normally be “one,” as the movement of a material through a supply network does not change its quantity.

Advice on Enjoying the Multimedia Presentation

To see the full screen just select the lower right-hand corner and expand. Trust us, expanding makes the experience a whole lot more fun.

 

This presentation illustrates the problems with SAP support and how Brightwork SAP Support addresses these shortcomings. 

What Kind of Support is This?

If this does not sound like standard support, you are right. And that is the point.

We designed our support to help our customers get the most out of SAP, not to maximize our margin or to try to protect previous sales inaccuracies. We know how to get your SAP applications working better.

To see the broader information about our SAP support see our main SAP Support Page.

References

I cover DRP in the following book.

Supply Planning Book

SUPPLY

Supply Planning with MRP, DRP and APS Software

Showing the Pathway for Improvement

Supply planning software, and by extension supply planning itself, could be used much more efficiently than it currently is. Why aren’t things better?

Providing an Overall Understanding of Supply Planning in Software

Unlike most books about software, this book showcases more than one vendor. Focusing an entire book on a single software application is beneficial for those that want to use the application in question solely. However, this book is designed for people that want to understand supply planning in systems.

  • What methods fall into APS?
  • How do the different methods work and how do they differ in how they generate output?
  • What is the sequence of supply planning runs?

These types of questions are answered for readers in this book.

This book explains the primary methods that are used for supply planning, the supply planning parameters that control the planning output as well as how they relate to one another.

Who is This Book For?

This book as a practical primer for anyone looking to perform a supply planning software selection, any person beginning a supply planning project, or anyone who just wants to understand supply planning software simply better.

Chapters

  • Chapter 1: Introduction
  • Chapter 2: Where Supply Planning Fits Within the Supply Chain Planning Footprint
  • Chapter 3: MRP Explained
  • Chapter 4: DRP Explained
  • Chapter 5: APS Supply Planning Methods
  • Chapter 6: APS for Deployment
  • Chapter 7: Constraint-based Planning
  • Chapter 8: Reorder Point Planning
  • Chapter 9: Planning Parameters
  • Chapter 10: How MRP, DRP, and APS Relate to One Another
  • Chapter 11: Supply Planning Visibility and Master Data Management
  • Chapter 12: Understanding the Difference Between Production Versus Simulation

How to Understand Redeployment Decision Matrix for SAP APO

Executive Summary

  • Different Redeployment Designs in Conjunction with APO
  • Redeployment Decision Matrix
  • Integrating with the SAP Deployment Solution
  • The Approach for Transportation Lane Management
  • The Downsides

ReDeployment

Introduction

Redeployment is a much less discussed supply planning thread. Some redeployment is necessary at most companies.

Different Redeployment Designs in Conjunction with APO

Companies do not meet their redeployment (not be confused with deployment needs, which are met with the SNP deployment heuristic) needs with APO. I have been through this topic with several companies, with a desire by either the consulting company or SAP that we “get creative” in coming up with a way around the fact that there is no solution in APO.

  • This request to get creative is usually issued from the person who was responsible for checking if SNP could meet all of their supply planning needs or the SAP account manager who needs political cover for why both deployment and redeployment were not sufficiently explained during the discovery phase of software selection.
  • However, while a lot of calories has been burned on this topic on several clients, (after testing the cost optimizer and CTM with various custom configurations), the result has been the same. We end up not doing redeployment in APO. Redeployment does not exist in SAP SNP and never did.

Companies that want redeployment functionality do not use APO for deployment, and they have three basic alternatives available to them:

  1. Create a custom report that allows the redeployment to be performed manually.
  2. Use an application that has redeployment functionality, and integrate this application with APO.
  3. Create a custom application that performs redeployment.

Redeployment Decision Matrix

redeployment-decision-matrix

Integrating with the SAP Deployment Solution

Regardless which alternative above is chosen, it is still necessary that the redeployment transportation lanes be turned on when STOs are brought over from SAP ERP and turned off before the SNP heuristic running.

  1. If a custom report is used, then the redeployments are created manually.
  2. If an application is used (either custom written on a third party application), then stock transfer requisitions are created automatically (outside of APO of course), and they are then evaluated before being approved and sent to SAP ERP to be converted to STOs.

Redeployment stock transport orders are scrutinized much more heavily than normal deployment stock transport orders. There is massive value judgment that often goes along with how redeployment stock transport orders are viewed because they are considered to be rectifying a mistake. Considering that I mostly work with companies that do things like manipulating/flush safety stock to make their quarterly inventory targets or can’t justify why different supply planning methods were selected, the value judgments are routinely applied to redeployment STOs is peculiar.

Some companies cap redeployment transportation budgets, which is again weird, as when a program is used redeployments must already pass a test, one of which is the transportation cost of the redeployment movement.

Sometimes the “if our forecast was only better” argument may be brought up. However, a certain percentage of deployments will always be wrong, and as time passes, the stock can be repositioned to locations where it has a higher probability of being consumed.

That reduces duplicate production, reduces inventory and inventory carrying costs as well as obsolete stock. However, nonetheless, when a redeployment solution is rolled out, it will tend to have more manual oversight over the STRs that are generated than normal deployment STRs.

The Approach for Transportation Lane Management

There are several steps to managing the setup of the SNP model so that a multi-method approach (that is one which also uses an SNP heuristic, as that is the main point of contention) is consistent with redeployment STOs. The steps are the following:

  1. Setup redeployment transportation lanes (RTLs) between all locations for which a redeployment stock transport order could conceivably be created.
  2. Use a process chain to activate and deactivate the RTLs.
  3. Setup a specific time when redeployment STOs will be sent over to APO. Redeployments tend to be infrequent. Weekly will tend to be the highest frequency (and quite rare actually), with bi-quarterly or quarterly being a far more common frequency.
  4. Use a Process Chain to activate the RTLs, bring over the STOs to APO, and then de-activate the RTLs with another Process Chain.

The Downsides

This is undoubtedly work and long-term maintenance. This work is necessary because the RTLs create strong location-to-location relationships which we are not part the normal deployment flow. SAP Development did not think to provide the ability to have transportation lanes assigned for different purposes (for instance, allows for the creation of RTLs which are coded so that they are ignored by the initial supply planning run and the deployment planning run).

Essentially SAP development not only did not build in redeployment functionality into APO but also developed its heuristic solution without consideration to whether a company would ever want to perform redeployment. This issue applies to the SNP heuristic, but not with CTM. That is CTM can plan “loops” while the SNP heuristic does not.

Advice on Enjoying the Multimedia Presentation

To see the full screen just select the lower right-hand corner and expand. Trust us, expanding makes the experience a whole lot more fun.

 

This presentation illustrates the problems with SAP support and how Brightwork SAP Support addresses these shortcomings. 

What Kind of Support is This?

If this does not sound like standard support, you are right. And that is the point.

We designed our support to help our customers get the most out of SAP, not to maximize our margin or to try to protect previous sales inaccuracies. We know how to get your SAP applications working better.

To see the broader information about our SAP support see our main SAP Support Page.

References

Supply Planning Book

SUPPLY

Supply Planning with MRP, DRP and APS Software

Showing the Pathway for Improvement

Supply planning software, and by extension supply planning itself, could be used much more efficiently than it currently is. Why aren’t things better?

Providing an Overall Understanding of Supply Planning in Software

Unlike most books about software, this book showcases more than one vendor. Focusing an entire book on a single software application is beneficial for those that want to use the application in question solely. However, this book is designed for people that want to understand supply planning in systems.

  • What methods fall into APS?
  • How do the different methods work and how do they differ in how they generate output?
  • What is the sequence of supply planning runs?

These types of questions are answered for readers in this book.

This book explains the primary methods that are used for supply planning, the supply planning parameters that control the planning output as well as how they relate to one another.

Who is This Book For?

This book as a practical primer for anyone looking to perform a supply planning software selection, any person beginning a supply planning project, or anyone who just wants to understand supply planning software simply better.

Chapters

  • Chapter 1: Introduction
  • Chapter 2: Where Supply Planning Fits Within the Supply Chain Planning Footprint
  • Chapter 3: MRP Explained
  • Chapter 4: DRP Explained
  • Chapter 5: APS Supply Planning Methods
  • Chapter 6: APS for Deployment
  • Chapter 7: Constraint-based Planning
  • Chapter 8: Reorder Point Planning
  • Chapter 9: Planning Parameters
  • Chapter 10: How MRP, DRP, and APS Relate to One Another
  • Chapter 11: Supply Planning Visibility and Master Data Management
  • Chapter 12: Understanding the Difference Between Production Versus Simulation

How to Set up Regional S&OP Process Threads

Executive Summary

  • Background on Planning Versions and Simulation
  • Some Common Reasons for Using Different Versions
  • Version Copy In APO
  • Copying Back Changes to the Active Version from the Inactive Version
  • Process Issues of the S&OP Thread
  • Security Issues and Simulation Version
  • Report Generation and Extraction from the S&OP Version
  • Beyond the Standard APO Problem Decomposition

global_instance

Introduction

When setting up regional S&OP process threads, it’s necessary to discuss the version copy. An S&OP planning run is typically performed in a simulation version – that is a non-live version in APO.

Background on Planning Versions and Simulation

Planning systems typically have a standard ability to made duplicates of a supply chain planning model as well as its transaction data. This means that the planning system can have multiple “versions.” These versions may often be only slight variations of one another. In a planning system, a slight variation input can make very large differences in the planning output.  In technical terms, a version is a separate schema, which resides on the same database. Therefore, the schema is copied, and pointing is used to control the schema, but it is on the same server, the same database and communicates with the same processor. One reason for this that maximizes the use of the resources (for instance a simulation version can be processed when the live version is not being processed) but also it is easiest to perform a version copy from the same database. This is shown in the graphic below.

planning-versions

More resources are required when one uses duplicate version. It means more data and the version copy itself takes processing resources and must be scheduled for light periods of system use.

Only the 000 version is integrated with SAP ERP; all other versions are kept in APO. Typically simulation versions begin with a version copy of the live version. Versions can be flexibly named any three-character combination. So a version could be named “SOP,” as you can see from the screen shot below:

Version Copy In APO

The version copy is the most important part of the process. The version copy allows the company to leverage all of the hard work in setting up the version to make a perfectly pristine copy of all of the configuration, master data – and if desired the transaction data. When the transaction data is included as well – the version can be referred to as a snapshot in time. It should be remembered that the inactive version cannot communicate with the ERP system, so whatever is brought over regarding the transaction is all the transaction data the version will ever have. As time passes, the version copy becomes less and less current.  New version copies can be performed to bring the offline version up to date.

versioncopy

This is transaction /SAPAPO/VERCOP.

The copy is mostly from the active version or 000 to an inactive version such as 001, 002, etc. But there are two exceptions.

  • It is possible of course to copy from on inactive version to another. This would be done if some changes had been made to an inactive version and the first inactive version needed to be kept as is, and more changes made to another version.
  • Master, data can be copied from an inactive version to an active version. The reason for doing this is described in the following section.

In the scope area of this screen, one can decide to bring in just a portion of the overall model. This, of course, can reduce the size of the version copy. But it is also more work. A version copy essentially creates a new version. But it can also be deleted which is done with the transaction /N/SAPAPO/MVM. That way old versions that are not being used can be deleted to reduce the size of the database.

Copying Back Changes to the Active Version of the Inactive Version

A nice feature of version management in APO is the ability to copy master data from the inactive version to the active version. This is a major time saving because it means that changes that were made to master data in inactive version. Say due to simulation, can be directly copied over to the active version. This is both an issue of reducing the effort required but is also provides a quality control benefit. Because it is not necessary to go through and check all the areas that were changed in the inactive version and ensure that the exact changes are also made in the active version.

Processing Issues of the S&OP Thread

Simulation runs such as the S&OP thread tend to be run on an ad hoc basis. This planning thread is infrequently run – particularly for the entire model. No batch jobs need to be scheduled for the S&OP run. Smaller ad hoc runs can be performed at any time, and because of their small size, tend to not significantly or adversely impact system performance. Therefore the main impact of the S&OP planning thread tends to be on disk space and as will be discussed, in several paragraphs, in the effort to write reports from the S&OP thread.

Security Issues and Simulation Version

S&OP versions tend to be region specific. Therefore in a global instance of APO, it can be desirable to restrict access to the simulation version only to those individuals with APO access that are within the region. The SAP role authorization model does allow for users to be assigned a role, which only allows them to go into specific versions.

Report Generation and Extraction from the S&OP Version

S&OP versions also need to have data extracted from them to be useful. There are in fact extremely few supply chain planning applications that can provide this functionality, and SAP APO is not one of them. SAP has tried over time to present several different S&OP solutions and has never been able to introduce a successful S&OP application. SAP has a new S&OP application under the “HANA” moniker, but I have yet actually to see it, it’s considered experimental and does not have a very high likelihood of being successful. See more at this link

selection-for-optimizer

Advice on Enjoying the Multimedia Presentation

To see the full screen just select the lower right-hand corner and expand. Trust us, expanding makes the experience a whole lot more fun.

 

This presentation illustrates the problems with SAP support and how Brightwork SAP Support addresses these shortcomings. 

What Kind of Support is This?

If this does not sound like standard support, you are right. And that is the point.

We designed our support to help our customers get the most out of SAP, not to maximize our margin or to try to protect previous sales inaccuracies. We know how to get your SAP applications working better.

To see the broader information about our SAP support see our main SAP Support Page.

References

S&OP Book

S&OP

Sales and Operations Planning in Software

Getting Clear on S&OP

S&OP is a commonly discussed, yet infrequently mastered area of planning. S&OP continues to be one of the most misused and overused terms in business.

S&OP is a type of long-term planning that attempts to match supply and demand and provides input to a financial plan to support the firm’s overall strategy. S&OP is in part a subcategory of consensus-based forecasting. It means driving to a consensus on what are branches within the company or entity that are often more competitive with one another than actually collaborative.

No Problem on Getting Consensus?

Obtaining this consensus is no easy task, and beyond the political aspects of S&OP, S&OP comes with its unique software challenges because it means both planning at a higher level of aggregation than other planning processes, while also exposing the specific constraints so that those constraints can be evaluated for possible alteration.

All of these issues and more are addressed in specific detail in this book. By reading this book you will learn:

  • What is the difference between S&OP and IBP, and how does this relate to the difference that is often described in the marketplace?
  • What are important features of S&OP applications and how do some standard S&OP applications differ in their design?
  • What are the implications of aggregation to S&OP application and process?
  • What are the political considerations that are required to be understood to be successful with S&OP?
  • What are the natural domains for executive adjustment versus lower level planning adjustment?

Chapters

  • Chapter 1: Introduction
  • Chapter 2: The Relationship Between Planning Systems and S&OP Systems
  • Chapter 3: S&OP Versus Integrated Business Planning
  • Chapter 4: SAP IBP, ANAPLAN & SAP Cash Management
  • Chapter 5: The Impact for SAP IBP with HANA
  • Chapter 6: S&OP, Aggregation, and Forecast Hierarchies
  • Chapter 7: Challenges in S&OP Implementation
  • Chapter 8: How Misunderstanding Service Level Undermines Effective S&OP
  • Chapter 9: Conclusion

How to Adjust CTM and the SNP Heuristic for Changes to Location Products

Executive Summary

  • Understanding the Requirement.
  • How the SNP Heuristic has Product Locations Added to the Procedure.
  • How the CTM Heuristic has Product Locations Added to the Procedure.
  • The CTM Master Data Selection

multi_method_planning

Introduction

The requirement described in this article is to have updates to products be assigned to groups so that the group is changed, and which automatically is picked up by the run profiles in the SNP heuristic and CTM. The concept is that the client will “code” a spreadsheet which is filled with product location combinations with the method that is used, (reorder point, reorder point, CTM forward scheduling profile, CTM backward scheduling profile), and that any new products or product changes would be coded this way. This is part of using multi-method supply planning.

The concept is that the companies that want to do this will “code” a spreadsheet which is filled with product location combinations with the method that is used. That is:

  • Reorder point
  • CTM forward scheduling profile
  • CTM backward scheduling profile

…and that any new products or product changes would be coded this way.

This spreadsheet would be set up by the configuration team but filled out by the business after the algorithm and instructions are explained to them. A new material (product location) would have automatic master data assigned to it (and for instance a reorder point set for it) as well as the product location being added to the procedure that is run (the CTM Profile or the SNP heuristic selection).

The SNP Heuristic Master Data Selection

The SNP heuristic allows the configurator to choose product location combinations within the run setup screen (which can be saved as a variant). This is called a manual selection. Yet, the SNP heuristic can also be run by associating with a Selection Profile. Creating a selection profile provides more flexibility and allows one selection profile to be connected to any number of SNP run configurations.

This is shown in the screenshot below:

This is added at with this transaction.

This is essentially a grouping mechanism. However, how this grouping mechanism would work on new products greatly depends whether a range, an excluded range is used, or individual values are used. This can be seen from the next screenshot.

Therefore, if the added product is added to the selection assignment, the SNP heuristic would not need to be adjusted. But of course without an enhancement of some type, adding to the selection assignment is a manual process.

The CTM Master Data Selection

 CTM is very similar to the SNP heuristic, except that it defaults to using a Master Data Selection, which is similar to the selection assignment, but also different in some important ways. As you can see below, I can run CTM for all data in the model, or just for the master data selection.
The master data selection is set up in a way that is shown in this article.
However, the products can be quickly added by adding a range. Below the range that I have set is from product 19 to product 34.
If a new product is added and is within the defined range it will be picked up by the CTM master data selection profile. I can add a range to the External Procurement and In-House Production. However, for this example, we will just focus on the selection of Location Products. Once each range is selected the individual product locations will appear in the tabs to the right of the settings tab above.

Advice on Enjoying the Multimedia Presentation

To see the full screen just select the lower right-hand corner and expand. Trust us, expanding makes the experience a whole lot more fun.

 

This presentation illustrates the problems with SAP support and how Brightwork SAP Support addresses these shortcomings. 

What Kind of Support is This?

If this does not sound like standard support, you are right. And that is the point.

We designed our support to help our customers get the most out of SAP, not to maximize our margin or to try to protect previous sales inaccuracies. We know how to get your SAP applications working better.

To see the broader information about our SAP support see our main SAP Support Page.

References

Being apply to apply multiple methods to different product location combinations is an important capability to have. It is covered depth in the following book.

Multi Method Planning Book

MULTI

Multi-Method Supply Planning in SAP APO

Choosing Supply Planning Methods

Which supply planning method meets your company’s business requirements?

The answer might surprise you! Here’s the truth: There is no one right supply planning method for all situations, even within one company! In fact, it is unnecessary to choose only one method, and using multiple supply planning methods is feasible and in most cases, has many advantages over using a single method.

Multi-Method Uses

This book explains why no one supply planning process meets all requirements and lists the many benefits of using multiple supply planning methods. This book gives practical advice about selecting supply planning methods and method modifiers, and goes deep into the “how to” of implementing mixed methods, and how specifically to setup them up in SAP APO, which are approaches taken from real projects. The book is also useful as a general document on how multi-methods can be used in supply planning applications.

Chapters

  • Chapter 1: Introduction
  • Chapter 2: The Different Supply Planning Methods Available within SAP SNP
  • Chapter 3: Combining Supply Planning Methods Across External Systems and ERP Systems
  • Chapter 4: Preparing for the Prototype for Multi-Method Testing
  • Chapter 5: Prototyping the Multi-Method Supply Planning Model
  • Chapter 6: Coding the Product-Location Database /Spreadsheet
  • Chapter 7: Planning Beyond a Single Supply Planning Method Per Echelon
  • Chapter 8: Creating a Dynamic Master Data Selection for Automatic Product Location Switching Between Methods
  • Chapter 9: Overcoming the Human and Information Challenges of the Multi-Method Approach
  • Chapter 10: Combining SNP with Inventory Optimization and Multi-Echelon Planning
  • Chapter 11: Conclusion

An Important Issue with Subcontracting in SAP APO

Executive Summary

  • Subcontracting functionality works in specific SAP APO modules. It is important to understand the subcontracting process flow.

subcontracting_in_apo

Introduction

I cover subcontracting in this articleSubcontracting, in supply chain management, is the outsourcing of a manufacturing process, where the OEM (original equipment manufacturer) provides some of the parts or a semi-finished good to the subcontractor. Therefore, a stock transfer would have to be created to move the material from the OEM to the subcontract locations, and a purchase requisition/order would need to be created from the supplier to the subcontract location.

The Background on The Subcontracting Issue

The subcontracting issue that I have documented is an issue that I ran into on a project with a client that attempted to perform subcontracting. I had left the project before I learned what happened to this issue, however, subcontracting surfaced again as a requirement on another project. This issue has had many OSS notes opened for it, and is documented in other places on the internet.

The issue is that when the PDS is used (this problem is unknown when the PPM is used).

  1. No PReq is created by the multi-level heuristic (it is also unknown if this same issue persists if the CTM is used or if the SNP optimizer is used) (unless the TLane is created manually)
  2. The STR is created by and sits in APO and is not transferred to SAP ERP.
This is described in the screenshots below:
This is how the subcontractor process flow should work (there are several subcontractor process flows, which is described in this link)

Advice on Enjoying the Multimedia Presentation

To see the full screen just select the lower right-hand corner and expand. Trust us, expanding makes the experience a whole lot more fun.

 

This presentation illustrates the problems with SAP support and how Brightwork SAP Support addresses these shortcomings. 

What Kind of Support is This?

If this does not sound like standard support, you are right. And that is the point.

We designed our support to help our customers get the most out of SAP, not to maximize our margin or to try to protect previous sales inaccuracies. We know how to get your SAP applications working better.

To see the broader information about our SAP support see our main SAP Support Page.

References

Setting Up the Supply Network Book

NETWORK

Setting Up the Supply Network in SAP APO

Constructing Supply Networks

The only book on supply planning to focus entirely on how to configure supply networks in APO, and how to meet highly customized requirements that relate to supply network design. You won’t even find these topics covered in depth in SAP Training classes.

Serious Network Setup in APO

Through extensive use of graphics and screen images, this book will familiarize you with Supply Network Planning in SAP APO and show you what you need to do to design supply networks for real-life applications, where common business requirements necessitate a nonstandard system design.

After reading this book you will:

  • Be able to set up master data objects for the supply network.
  • Have a detailed understanding of the two primary data objects in APO: locations and transportation lanes.
  • Understand multi-sourcing – the ability for a supply planning system to choose intelligently between alternate sources of supply.
  • Know how to design the supply network for complex and non-standard workflows, such as planning locations that are external to the supply network.
  • Understand how to manage storage locations with MRP Areas for allocation and GATP.
  • Be able to model intercompany transfers.
  • Consider all aspects of network design, including physical master data set-up, parameters, planning run sequence, problem division, how and when billing documents are created, and more.
  • Learn when a parallel simulation version of the supply network is appropriate — and when it is not.

Chapters

  • Chapter 1: Introduction to the Supply Network
  • Chapter 2: Locations in APO
  • Chapter 3: Transportation Lanes
  • Chapter 4: Sources of Supply and Multi-Sourcing
  • Chapter 5: Managing Storage Locations with MRP Areas for Allocation
    and Global Available to Promise (GATP)
  • Chapter 6: Modeling Intercompany Transfers
  • Chapter 7: Capacity-constraining Vendors/Suppliers
  • Chapter 8: Conclusion
  • Appendix A: The Supply Network and Simulation
    References

https://sap.ittoolbox.com/groups/technical-functional/sap-apo/apo-sub-contracting-with-third-party-provision-of-components-in-ppds-top-priority-issue-4548609

Is it Possible to Use DP and PP/DS Without SNP?

Executive Summary

  • A question that sometimes arises is whether DP or PP/DS can be used without SNP.
  • There are important implications for doing this which we will cover.

Introduction to DP and PP/DS without SNP

There is a standard flow to APO concerning demand, supply and production planning. The flow is the demand plan is released to SNP, which is then released as a supply plan to PP/DS. However, ever APO module that is implemented takes effort, time and money and of course maintenance.

What was recently proposed to me was to implement DP with PP/DS, but without SNP. It is not hard to consider how the flows between the ERP system, DNP and SNP would appear, as I have shown below.

Design

PP/DS’s Supply Planning Capabilities

Secondly, there are capabilities that PP/DS has that do cover supply planning.

PP/DS generally has a short planning horizon. However, the planning horizon is flexible, as can be seen in the screenshots below:

Image 046

This is the PP/DS tab in the Product Location Master in APO. Notice that the PP/DS Planning Time Fence field, as well as the PP/DS Horizon field, are available to be set by the user.

Secondly, on the Characteristic Based Deployment tab, deployment — a supply planing function and typically performed in SNP, can be performed from within PP/DS.

Image 047

Here is another setting called the Time Profile. 

Image 048

This allows the planning period to be set up automatically from within the Detailed Scheduling Planning Board. 

Image 017

This is a default time profile that can also be changed from within the DSPB. 

Storage and Planning Buckets

PP/DS plans in daily buckets. That it does not have the flexibility to use different planning buckets and storage buckets that DP and SNP do have.

Here you can see in SPRO where the planning bucket profiles are set (the buckets that are shown in the Planning Book) that there is no planning bucket profile for PP/DS.

Image 049

Long Time Horizon Planning

When SNP is used, often a telescoping Planning Book is configured. You can read about how to configure this type of Planning Book in this article.

I quote from this article below:

“It is a frequent request at different clients is to provide a telescoping view of the Planning Book. This means that they want to see the Planning Book in days, then in weeks, and then in months, and they want to specify how many periods they would like to show each (7 days, 14 weeks, 16 months etc.). In order to do this its necessary to perform configuration of the Time Bucket Setting. Unfortunately, SAP does not ship with a standard telescoping Time Bucket Setting, so it must be created anew for each company during implementation.”

This telescoping has several advantages. First, the planner does not need to see a fine level of detail out further in the planning horizon. Secondly, by using a more appropriate level of granularity for most of the planning horizon, this cuts down on processing time.

The Storage Bucket Profile is assigned to the Time Bucket Profile, which is then assigned to the Planning Book.

Image 051

Here are some of the standard Storage Bucket Profiles. 

Image 052

Here are some of the Time Bucket Profiles. Notice that the Storage Bucket Profile is assigned to the Time Bucket Profile. 

Image 050

Finally, the Time Bucket Profile is assigned to the Planning Book. 

Therefore, the problem is that PP/DS does not come with the same flexibility concerning how the granularity of its planning can be controlled. This is a long way of demonstrating that PP/DS is not designed to run a long-range horizon — of course it can do it as is demonstrated by the earlier settings that showed the planning horizon of PP/DS is controllable.

However, PP/DS is designed to plan at a fine level of detail for its overall horizon.

Purchase Requisitions

PP/DS creates Preqs as does SNP. PP/DS uses the procurement type which is on the Procurement Tab of the Product Location Master the same way that SNP does to determine whether to create a Purchase Requisition or a Planned (Production) Order in response to a requirement.

0008

Procurement Type (F – Ext Proc, E – In House Prod, X – Either, P External Procurement Planning)

Lot Sizing

The lot-sizing settings apply to both SNP and to PP/DS. Therefore, if a Fixed Lot Size is set for 25,000 units, then this lot size applies to both PP/DS and SNP.

SNP Functionality

So while there is considerable overlap in the settings used by SNP and PP/DS, there are,  naturally several things that SNP does that PP/DS does not do — and this is the problem with using DP and PP/DS without SNP in the middle.

This includes, but is not limited to the following:

  1. Forecast Consumption: Forecast consumption is the decrementing of forecasts by sales orders.  Optimally speaking, forecasting is only a placeholder for a sales forecast. Forecast consumption prevents both the forecast and the sales order from being used to drive supply. The purpose of backward and forward forecast consumption is to reduce or remove the natural tendency to over order when consumption only occurs in one period. This is explained in the following article. PP/DS cannot perform forecast consumption — while SNP does do forecasting consumption. Therefore, the options if SNP is out of the implementation is to perform forecast consumption in ECC, and this means that the forecast is sent to ECC rather than to SNP.
  2. Receipt of the Forecast: The natural flow in APO is releasing the forecast from DP to SNP. Therefore, there is no transaction which releases the forecast to PP/DS. This means that if SNP is left out of the equation that some custom method must be created to drop the forecast directly from DP to SNP.

Conclusion

Given the restrictions listed above, it is difficult to recommend going without SNP,  if one is using DP and PP/DS.

Advice on Enjoying the Multimedia Presentation

To see the full screen just select the lower right-hand corner and expand. Trust us, expanding makes the experience a whole lot more fun.

 

This presentation illustrates the problems with SAP support and how Brightwork SAP Support addresses these shortcomings. 

What Kind of Support is This?

If this does not sound like standard support, you are right. And that is the point.

We designed our support to help our customers get the most out of SAP, not to maximize our margin or to try to protect previous sales inaccuracies. We know how to get your SAP applications working better.

To see the broader information about our SAP support see our main SAP Support Page.

References

Brightwork Forecast Explorer

Improving Your Forecast Management

SAP DP cannot be run effectively without help from another application.

Brightwork Research & Analysis offers the following free software for tuning forecasting systems. See by clicking the image below:

Constrained Book

CONSTRAINED

Constrained Supply and Production Planning in SAP APO

How Constrained Supply and Production Planning Works

Constraint-based planning generates something that is appealing to all manufacturers: a feasible supply and production plan. However, constraint-based planning software was first implemented over twenty years ago, and yet few companies (as a percentage that all that have tried) have mastered constraint-based planning.

Getting the Real Story

This book provides the background information, detailed explanations, step-by-step examples, and real-life scenarios to assist a company in becoming proficient at constraint-based planning, along with valuable information about what SAP APO can do for supply and production planning in reality, rather than just in theory. Here you will learn about resources the mechanism for constraining the plan in APO and for determining the feasibility of the plan and how constrained supply and production planning work together (and how they don’t).

Also, this book talks about constraint-based planning at the supplier level: can a vendor’s production be capacity-constrained?

By reading this book, you will learn:

  • The different resources available in APO, how production resources differ from supply planning resources, and the role resources and other significant constraints play in constraint-based planning.
  • How constraints integrate across the supply planning and production planning applications.
  • The areas of disconnect between supply and production planning applications, and between SNP and PP/DS in particular.
  • The difference between unconstrained (or infinite) planning and constraint-based planning.
  • The benefits of constraint-based planning and how it differs from capacity leveling.
  • Various types of demand, and how backward and forwards were scheduling work.
  • The benefits of using production constraints in the supply planning system, and how SNP and PP/DS can be synchronized to produce the desired output.
  • The methods that can do constraint-based planning in SNP and PP/DS–heuristics, CTM, and optimization–and how to configure these methods.
  • The difference between hard and soft constraints, and how to plan using multiple constraints.

Chapters

  • Chapter 1: Introduction
  • Chapter 2: Understanding the Basics of Constraints in Supply and
  • Production Planning Software
  • Chapter 3: Integrating Supply and Production Software with Constraints
  • Chapter 4: Constraint-based Methods in APO
  • Chapter 5: Resources
  • Chapter 6: Capacity-constraining Vendors/Suppliers
  • Chapter 7: The Disconnection Points Between Supply Planning and Production Planning

How to Understand the Key Figure Setting Options in SAP APO

Executive Summary

  • Covering the Planning Book configuration which means understanding Key Figure options and the available settings.
  • Key Figures used in DP and their configuration are covered in this article.

Introduction to Proportional Factors

When reviewing a Planning Book, it is important to consider that each Key Figure has a large number of ways in which it can be configured. For instance, if we look at just one area, calculation, there are multiple ways that a Key Figure can be calculated based upon another input. In this article, you will learn all about the configuration options regarding the proportional factors.

What Are Key Figures?

Key Figures are the rows that populate Planning Books in APO. The Planning Book is the most used user interface in DP and SNP (actually the only real interface for DP). Key Figures have a default configuration, but that configuration can be altered, and of course, when a new Key Figure is added to a Planning Book (which frequently occurs on DP projects) it means that the configuration must be performed to match the business requirements.

The Planning Book Configuration

The Planning Book is made up of key figures (contained in the rows) that intersect with time buckets (the columns). These key figures can be composed of the following items:

  1. Single Categories: For instance, to show a single category of stock in a single Key Figure.
  2. Multiple Categories: For instance, to show multiple categories of stock in a single Key Figure.
  3. Calculations of other Key Figures: These are calculations and functions that include configuration settings in APO. This is called a macro.

Many of the rows that planners see in the Planning Book are actually calculated values. Through normal use of the Planning Book, there is no way to know for sure which key figures are combinations of categories, or which are calculations (macros) that include other key figures. A number of the macros are standard calculations that ship with APO. For instance, the reorder point key figure is a macro. Any macro can be adjusted, whether it is a custom macro written for a company or a standard macro.

Key Figures Options

Inside of the Planning Area, the Key Figures can be adjusted with the following categories of options:

  • Accuracy Fixing & Calculation Type
  • Disaggregation
  • Neg, Zero, His.N. Changeable
  • SNP Mode and KF Semantics

Accuracy Fixing & Calculation Type

  1. Accuracy: This is how many decimal points the Key Figure will calculate to. The options are the following:
    1. No Decimal Places
    2. Two Decimal Places
    3. Three Decimal Places
    4. Maximum Accuracy
  2. Fixing: Fixing is the ability to lock the cells in a Key Figure. This prevents changes from occurring, for instance when a manual adjustment is made higher in the hierarchy. The options are the following:
    1. Simple Key Figure: (That is no fixing)
    2. Fixable Key Figure
  3. Calculation Type: This is the “primary” method of aggregation and disaggregation for a Key Figure. This determines how values are split as one traverses down a hierarchy, and how the values at lower levels in the hierarchy combine upwards. The options are the following:
    1. S: Pro Rata
    2. P: Based Upon a Different Key Figure
    3. A: Average
    4. N: No Calculation
    5. I: Pro Rata; If Initial: Based on Different Key Figure
    6. D: Average at the Lowest Level of Detail
    7. E: Average of All Details Not Equal to Zero
    8. F: Average of Lowest Level Non-Zero; Disaggregation Pro Rata

Disaggregation

  1. Disaggregation Key Figure: This is the Key Figure upon which disaggregation is performed. A Key Figure can be disaggregated on another Key Figure, but does not have to do this. Some types of disaggregation, such as the I: Pro Rata, will disaggregate on another Key Figure if the value in the period is blank. However, if the value in a period is adjusted — or that is not blank, it will not disaggregate on another key figure.
  2. Time Disaggregation: This is the second type or dimension of disaggregation which is available for a Key Figure. This is how the periodicity in the Planning Book is related to the periodicity of the Storage Bucket. The options are the following:
    1. I: Proportional Allocation
    2. P: Proportional distribution; but other Key Figure in initial.
    3. E: Equal Distribution
    4. N: No time based distribution
    5. R: Read Value from last period; Write: No allocation
    6. K: Based on Another Key Figure
  3. Key Figure Time Disaggregation: This is the Key Figure on which the disaggregation is performed.

Neg, Zero, His.N. Changeable

  1. Neg.N.All: This determines if a cell can be negative. (Interestingly in setting this to not allowed, I was still able to enter a negative figure into a cell in the Key Figure.)
  2. Zero All:
  3. Zero Fixable: If one want to enable “fixable” in bullet point 2, this must also be selected.
  4. Hist.N.Changeable:
  5. InfoCube: Here any of the InfoProviders that are available in the system can be selected.

SNP Mode and KF Semantics

  1. SNP Mode: The options are the following:
    1. A: Automatic flow key figure
    2. D: DP key figure
    3. F: Flow key figure
    4. W: Soft constraint key figure
    5. H: Hard constraint key figure
    6. P: Parameter key figure
    7. X: Key figure for fixed receipts.
  2. KF Sem: This stands for Key Figure Semantics. This will apply a three digit code to each Key Figure.

Conclusion

As you can see there is quite a lot that can be configured to change the behavior of a Key Figure. When reviewing an existing implementation, a good place to review is the settings of the Key Figures. Any change can be made to Key Figures within the Planning Book by selecting Key Figure Settings from the Extras menu in the Planning Area.

Advice on Enjoying the Multimedia Presentation

To see the full screen just select the lower right-hand corner and expand. Trust us, expanding makes the experience a whole lot more fun.

 

This presentation illustrates the problems with SAP support and how Brightwork SAP Support addresses these shortcomings. 

What Kind of Support is This?

If this does not sound like standard support, you are right. And that is the point.

We designed our support to help our customers get the most out of SAP, not to maximize our margin or to try to protect previous sales inaccuracies. We know how to get your SAP applications working better.

To see the broader information about our SAP support see our main SAP Support Page.

References

Forecast Promotions Book

PROMOTE2

Promotions Forecasting: Forecast Adjustment Techniques in Software

The Constant Issues with Promotions Planning

Promotions keep increasing in companies, but the ability to manage promotions is simply nowhere near to keeping up.

Accurately accounting for promotions is the only way to guarantee the availability of the promoted product during the promotion period. Not only do in-house promotions change demand, but so do competitor promotions; being able to forecast the impact on your demand is vital to maintaining service levels.

Promotions Forecasting in Software

All promotions can be measured for their effect on sales, and the history of any promotion can be used to adjust the forecast to account for future promotions. In this book, through the use of graphics and screenshots, you will receive a tutorial on how software applications can be used to maintain this history and adjust forecasts.

By reading this book you will:

  • Gain an overview of the different categories and types of promotions.
  • Understand how forecast accuracy is impacted by promotions.
  • Learn how to create a database of historical changes, and then use this information to predict future changes in demand when similar promotions are run.
  • Appreciate promotions from the perspective of both Sales and Marketing, and Supply Chain.
  • Recognize common issues with forecasting for promotions.
  • Create strategies for communicating with Sales and Marketing about future promotions, and for translating this information to Supply Chain and Forecasting.

Chapters

  • Chapter 1: Introduction
  • Chapter 2 Where Demand Planning Fits within the Supply Chain Planning Footprint
  • Chapter 3: The Common Problems with Statistical Forecasting
  • Chapter 4: Introduction to Best Fit Forecasting
  • Chapter 5: Comparing Best Fit to Home Grown Statistical Forecasting Methods
  • Chapter 6: Sales Forecasting
  • Chapter 7: Sales Forecasting and CRM
  • Chapter 8: Conclusion