Imagine for a minute that you were given the key to a Bentley Continental GT. You may never have driven a Bentley, much less even been within 100 feet of one. With a 6.0-liter twin turbo W2 with 552 horsepower engine, it's capable of going from 0 to 60 mph in 4.7 seconds, reaching a top speed of 198 mph, and it features a base price of $149,990. Thus, the odds are that for most of us, the Bentley is out of reach. Still, is there anything that would prevent you from being able to open the door, slip the key into the ignition, and drive away? Would you need any special training or licenses first? Absolutely not. Though the Bentley lies on the outskirts of automotive possibility, it is still a car. Your learning curve is 0. It turns out that things aren't so different when it comes to SAP Advanced Planning and Optimization (SAP APO).

I spent a year writing SAP SCM: Applications and Modeling for Supply Chain Management. Writing this book provided a unique opportunity for me to dwell on a topic as I might never find cause to otherwise – in my case, I was able to study and reflect on SAP APO and its design and to compare its parts at a distance the way a scientist might, rather than always close up as a practitioner must. In doing this, it occurred to me that most people don't really know the subject they work with every day.

Most of us came about our SAP APO expertise the hard way: which is to say from the bottom up, inductively, from the detailed to the general. So much detailed knowledge without effective summary comes with some costs. When SAP APO experts struggle to navigate the SAP APO forest for non-experts, when all they know are details at the level of bark, branches, and leaves, it can be hard to communicate effectively with customers, potential customers, managers, and the whole panoply of other stakeholders who are inevitably a part of SAP APO projects, programs, and deployments.

Wouldn't it be nice to have a common frame of reference to explain SAP APO with the same simplicity that others might talk about a really hot car? Fortunately, as it turns out, there is.

The Universal SAP APO Process

As you'll see shortly, SAP APO follows three simple universals precisely: input, processing, and output. Start with the end in mind, and reverse that order so you can think through it more clearly. Output is the end result; processing does the work to get you there. Processes require inputs so they have something to work on. Finish-to-start; output-to-process-to-input: it's the same formula every time and it works.

Outputs. The three planning modules of SAP APO, Demand Planning (DP), Supply Network Planning (SNP), and Production Planning/Detailed Scheduling (PP/DS), all follow this pattern. Whether you are talking about forecast, supply, production, or the shop, you know that there is an output. For DP, this output is the forecast. For SNP, it is usually a multi-site or geo-level, capacity-constrained supply plan equating effectively to an APICS (formerly the American Production and Inventory Control Society, now the Association for Operations Management) master production schedule (MPS). For PP, the output is usually a site-level build/inventory/buy plan, and for DS, it is a work-center-level detailed build schedule (Table 1).

SAP APO's modules for DP, SNP, PP, and DS each follow a common template framework. If you know one module's details, then you already know quite a bit about the rest in general.

Process. To achieve these four output types, all three modules apply a similar decision management process to support the managers or analysts who employ them. All three modules possess one or more versions of an analytic planning run. For DP, naturally, these are statistical tools, whereas SNP and PP/DS have a variety of solvers at their disposal: heuristic, linear, and otherwise. All three modules can take advantage of an easily configurable Alert Monitor that flags exceptions thrown by the analytic runs for further investigation by the manager or analyst. Also, all three modules present user interfaces that allow managers and analysts to employ qualitative analysis and human judgment to make new inputs that will affect future analytic runs, ideally minimizing or pushing out exceptions that the Alert Monitor caught in the previous run (Figure 1).

Figure 1

The universal SAP APO framework

Inputs. Like any computer program, the processes presented by SAP APO's modules require inputs to work. There are typically primary and secondary inputs. The primary input is the output of the process preceding it. In other words, the input to DS is the PP production plan. The input to site-level PP is the SNP build plan or master production schedule. The input to SNP is a demand forecast. The input to DP is known demand and a variety of secondary inputs.

All modules can also employ secondary inputs depending on their unique configuration and application. DP often considers historical forecasts, customer orders in various states of maturity, and competitive or cannibalization factors. SNP relies on sources of supply such as current inventories, work in process (WIP), in-transit stocks, open purchase orders, as well as some data on capacity constraints. PP has a similar list, only at a higher level of detail, and DS, focusing on the immediate, has no use for WIP and in transits, but instead requires additional detail on productivity constraints such as the availability of equipment and labor to man workstations.

The SAP APO Process Applied in DP

Figure 2 depicts the SAP APO universal framework that I've uncovered, but applies it for the specifics of DP. The figure is divided into two parts that you can loosely delineate as being the SAP APO configurator or modeler's view at the top and the end user's view at the bottom. I emphasize the looseness of this contrast here because the end user or any non-expert stakeholder in an SAP APO project or deployment can be seen as starting with the vagueness of the view shown at the bottom of the figure. With the necessary guidance from experts and direct practice with the system, a novice can move decidedly toward the more sophisticated modeler's perception at the top. I'll unpack that top level view first.

Figure 2

Figure 2 The Universal APO Framework Adapted for the Specifics of DP - At the top a modeler's view, at the bottom an end-user's perception. (Source: Adapted from SAP SCM: Applications and Modeling for Supply Chain Management, Daniel Wood, Copyright © 2007, John Wiley and Sons. Used with permission of John Wiley & Sons, Inc.)

An SAP APO DP analyst or developer needs to systematically tackle modeling and configuration of each of the following components:

• The primary input interface
• Any secondary input interfaces
• The quantitative, analytical runs
• Alert monitor profiles
• An interactive user interface
• A final output interface

For DP, the primary input is almost always customer sales orders/live customer demand. Beyond that, a whole variety of inputs can be pulled into DP depending on the unique needs of the organization deploying DP. Common DP secondary inputs can include archival data about historical forecast and sales, as well as competitive market data. Market data can include promotions for the products being sold that are taking place, promotions for competing products, new releases, or competing or cannibalizing products going out to market by the same vendor.

SAP APO DP provides three statistical runs that you can configure to operate using the input data provided: univariate analysis, multiple linear regression, and composite forecast. You can configure Alert Monitor profiles in the supply demand planning (SDP) tab for the unique exception concerns of the business to call out when certain circumstances or events show up on executions of a statistical analysis. In response to flagged conditions called out in the Alert Monitor, end users can employ a customized configuration of the planning book apart from the Alert Monitor to interact with the inputs and processed data of DP and its quantitative runs. The planning book allows for the specific balance of analysis and manipulation by end users who employ their qualitative judgment to make final determinations about processed outcome. Sometimes this means adjusting inputs and re-running quantitative forecasts, while in other cases it entails manual adjustments to the quantitative, processed output. In other words, people don't always trust computers. If the forecast says there will be demand for 100,000 units, but an empowered demand analyst knows that representatives of a specific customer company have committed to opening a purchase order (PO) for another 10,000 (or conversely, have indicated that they will cancel an open sales order), then the analyst can apply accommodations for this manual override through the planning book configuration.

These changes to the quantitative forecast result in what is sometimes described as a judged forecast, implying that while quantitative runs provide value-added insight, human intellect remains the gold standard of judgment. Whatever the final adjustments are to the forecast, people rely on the demand analysts or planners interacting with the processed output of DP to make that judgment and submit it as output to supply planning, where it is taken over by SNP.

This overview of the DP process, while a summary, nevertheless entails considerable detailed knowledge of the contents, processes, capabilities, and sequence of activities provided by SAP APO DP. It is the end state of introducing a stakeholder or inexperienced user to the SAP APO DP process. When you begin with such individuals or groups, prime them with what you know they can understand even without such detailed knowledge: Input, Process, and Output – all of which are shown in the bottom half of Figure 2.

The SAP APO Process Applied in SNP

Figure 3 depicts the SAP APO universal framework that I've uncovered, but applies it for the specifics of SNP. SNP operates on a geographical level (such as Asia or North America) or minimally as a whole group of sites. SNP coordinates supply and demand at this higher level, then delivers a supply plan or master production schedule to the sites, which work out more specific, execution-level details in PP/DS. As with Figure 2, the SNP image is divided into two parts loosely tied to the expert and novice view. Again, I'll look at the expert's view first.

Figure 3

The Universal APO Framework Adapted for the Specifics of SNP - At the top a modeler's view, at the bottom an end-user's perception. (Source: Adapted from SAP SCM: Applications and Modeling for Supply Chain Management, Daniel Wood, Copyright © 2007, John Wiley and Sons. Used with permission of John Wiley & Sons, Inc.)

The primary input to SNP is the output of DP: a judged, final demand forecast. The first point of difference between DP and SNP is that SNP juxtaposes the demand picture against the supply and capacity situation, where as DP gets the best demand picture possible. SNP, therefore, requires as many secondary inputs as there are sources of supply. Figure 3 shows supply sources for materials on order from suppliers, on-hand inventory, work in process, and in- transit inventory, though this is by no means a necessarily complete list. Every organization must account completely for its unique supply picture. In addition to supply, SNP takes capacity into account. Capacity is not so much a matter of modeling orders that are fed by interfaces as it is modeling supply chain structures that include both sites (such as vendors, factories, and distribution centers) and transportation lanes with specific limits on capacity capability.

SNP's planning runs compile all of these inputs – demand, supply, and capacity – together. There are three planning runs available to SNP: the heuristic planning run; Capable-to-Match (CTM), which emphasizes priorities; and the linear optimizer. A variety of factors determine which run is employed, not least of which is the technical sophistication of the SAP APO adopter. In any case, you can tinker with the runs to apply rules emphasizing product type, vendor, customer, cost, or other factors.

As with DP, SAP APO adopters configure the Alert Monitor to highlight outcomes of SNP planning runs through the SDP tab. Human supply analysts or planners can also react to exceptions called out by the Alert Monitor on the planning book, which again must be specifically configured for SNP use. Along with the planning book, end users can also begin to employ the product view. In addition to displaying orders and activity as units spread across time, the product view illuminates the specific ties between units of demand and the supplies that are being allocated by planning runs to fulfill them.

Subject to specific configuration of the planning book, the planner or analyst interacting with the system's quantitative output makes the final judgment of outputs. Analysts can either make adjustments to inputs and re-do planning runs or, if permissible in their organization, they can make direct modifications to the final output.

At the bottom of Figure 3, you can see a couple of nearly universal features of the SNP process that to users of legacy tools who are nevertheless unfamiliar with the details of SAP APO SNP recognize. All master production scheduling processes must receive a demand forecast as a primary input, and they must have some series of interfaces informing the system of sources of supply. Almost all such processes entail some kind of hand-off back and forth between supply and capacity analysis. The integration of supply and capacity analysis is one of the primary benefits of using SNP. The result of this process is a master plan, that is, a high-level plan taking into account multiple sites and often entire geographies. The plan splits responsibility for certain components of production and distribution to individual sites and sends the site-level plans to them as output, where they become the input to the site-level, detailed planning process.

The SAP APO Process Applied in PP/DS

PP/DS is a bit of a stand-out module in SAP APO not least of all because, as the slash in its title implies, it is really two modules in one. The objectives of PP versus DS are so separate that I could reasonably address each separately, but since they are packaged as a unit and since space is limited, I will address them together.

SNP generates a demand/supply/capacity plan for a whole geography inclusive of many sites and even many different kinds of sites. This high-level plan is rarely actionable without specific attention to detail on a site level. PP/DS has the responsibility and capability of providing that attention.

When SNP's planning runs generate order proposals to fulfill unrequited demand, they only generate them as planned orders. These are suggestions effectively for future supply, which can materialize as either a production or purchase order in its final state depending on whether the adopters have configured the material in the product master. The PP component of PP/DS takes planned orders from suggestions to actual, actionable production and purchase orders.

To achieve its ends, the PP component of PP/DS typically uses many of the same secondary inputs as SNP. PP requires information on all of the supplies available to fulfill demand requirements on a detailed level. The difference is in the interpretation of the primary input. SNP is a pure planning tool – it has no capability for execution and exists only to match demand with supply and capacity. PP is not pure in this respect. It does some planning, but it does some execution too; specifically, it acts as the bridge from planning to execution. SNP is a master production plan, the demand source for PP, yet it is a demand source that is already wise to supply, having committed inventories to demand fulfillment and having proposed planned orders to create new supply. PP takes the supply component of the SNP production plan, adjusts it for site-level, time-constricted precision, and makes the pure SNP plan actionable by converting planned orders to production and purchase orders.

In other words, SNP knows, “We have stock on hand or inventory in transit for that demand, and we need to create a new planned order to fulfill it.” PP begins with this as an input and says, “We will use this specific stock and this specific in-transit inventory to satisfy that demand, and there is no reason not to convert a planned order to a production order to create still more supply.” This is depicted in Figure 4, with SNP providing an MPS to PP and PP achieving the initial analysis with its own heuristic planning run. It is also possible to apply CTM on a PP/site level if CTM prioritization capabilities are necessary beyond those of the heuristic run.

Figure 4

The Universal APO Framework Adapted for the Specifics of PP/DS - At the top a modeler's view, at the bottom an end-user's perception. (Source: Adapted from SAP SCM: Applications and Modeling for Supply Chain Management, Daniel Wood, Copyright © 2007, John Wiley and Sons. Used with permission of John Wiley & Sons, Inc.)

As with both SNP and DP, the Alert Monitor can capture exceptions from the heuristic planning run or the PP/DS CTM run using only the specialized PP/DS alerts on the PP/DS tab. It is particularly important on the level of PP/DS for human analysts and planners to evaluate Alert Monitor outcomes in order to help determine whether or not to convert planned orders to actionable purchase or production orders. Those actions typically can be made via the product view, which, together with the Production Planning Table, is the primary user interface for the PP component of PP/DS in principle. It is useful to know, however, that for analytical purposes nothing restricts a PP/DS analyst from employing an SNP planning book. Often making a planning book available for site-level PP/DS work serves both the interests of end users and customers, given the high level of customization and graphical interaction that is possible within the planning book.

As with DP and SNP, final judgment in PP ultimately belongs to an end user because these judgments result in definitive, actionable orders whose next stop is DS:Detailed Scheduling, where they are produced. Detailed Scheduling can be thought of as a mini module within PP/DS, specialized for shop-level scheduling, but I suggest caution here. Note that Figure 1 illustrates that DS has analogs for all of the major components shared by DP, SNP, and PP – all the componentry that makes the former two distinct modules. What's more, while PP must make an account for demand, supply, and capacity, DS is much more specialized and does not attempt to create new supplies. Where supply is concerned, it is only interested in whether or not the supply is available to begin work when scheduled. DS recognizes that a live production order (demand as it sees it) exists and is ready for scheduling, that the requisite raw materials are staged at appropriate work centers, and that work centers are up and running within their own schedule bottlenecks. The key issue for DS in this regard is capacity: When are work centers ready to run?

DS also has a quantitative processing engine: a scheduling optimizer that is capable of either a constraint- based solve or a genetic algorithm – the former focused on constraints such as equipment or labor availability, the latter employing logic for re-combination of orders, inheritance of schedules, selection, and cross-over to derive an optimal schedule. Even though it is packaged as a unit with PP/DS, the entire process is effectively repeated. DS processes the settled production order schedule from PP using either its constraint or genetic optimization algorithm, and end user's address configured Alert Monitors using critical exceptions that require qualitative analysis and attention. Finally, direct work is performed on schedule outputs of the optimization runs through the DS-specific planning board user interface where end users exercise considerable influence over the final schedule – moving orders in, pushing them out, increasing or decreasing their quantities, or changing their statuses, so the final output of DS can be said to either be a live; production schedule or production itself.

As with DP and SNP, look at the bottom of Figure 4 to gain a more rudimentary view of the PP/DS processes with which you can anchor novice end users and stakeholders. The exact narrative varies somewhat whether you are talking about PP or DS, but, as always, universals are present. At the level of PP, you always deal with the conversion of a pure plan to an actionable one. At the level of DS, you are no longer concerned with matching demand and supply, nor with creating new supplies; you only want to develop the optimal short-term execution schedule using known, live constraints on the ground, whether those constraints come from supply, labor or equipment. In other words, SNP and PP planning runs generate new orders for new supply if doing so creates a more optimal schedule. The DS optimizer is so close to execution that it simply works to build the best schedule with available labor, equipment, and material, and it focuses almost entirely on calendar optimization.

Daniel Wood

Daniel Wood is a lecturer at Arizona State University in the W.P. Carey School of Business and a former industry SAP SCM business system analyst. He is author of SAP SCM: Applications and Modeling for Supply Chain Management (Wiley)

You may contact the author at daniel.c.wood@asu.edu.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.