Introduction to SAP APO

Executive Summary

• The most common APO modules implemented in APO are covered in this introduction to APO.
• APO has important interactions with SAP ERP.

Introduction to SAP APO

In this article, you will receive a high-level overview of the entire SAP APO suite.

What is APO Made Up Of?

SAP APO is made up of a series of applications that address most companies’ supply chain planning areas. One area of great interest to companies is how SAP ERP supply chain planning differs from the advanced planning available in SAP APO. While a point-by-point comparison could be its own book, generally speaking, SAP ERP contains a simplified version of some of the SAP APO functionality, so an application from SAP ERP can be substituted, at a lower level of functionality, for an application in SAP APO. To show you how this works, let’s look at one area well understood by many people, Supply Network Planning (SNP).

In SAP ERP, the forecasts and sales orders are taken into account and reorder point methodologies are used to develop the in-stock positions at the various locations. However, SAP APO can do much more than this. For instance, not only does it have more methods to apply to develop the supply network plan (such as the ability to prioritize demands with Capable to Match [CTM] as well as the ability to optimize against cost), it also has many more settings that lead to a more nuanced and sophisticated supply plan than SAP ERP. Additionally, as a planning system, SAP APO can have different planning approaches tested without ever affecting the transactions managed in SAP ERP. This simulated capability is one of the significant advantages of planning systems generally. But it’s important to note that the vast majority of companies that purchase and implement SAP APO also have SAP ERP. Therefore, an important project objective is to determine which areas will be handled in SAP ERP versus which will be managed by SAP APO. Unfortunately, there is no easy answer to this, so it must be solved on a project-by-project basis.

The Scale of APO

But because no company has implemented the entire SAP APO suite as of this writing, it’s common for a company to use only one application from SAP APO. Implementing two makes the company a serious user of SAP APO, and implementing three to four applications makes that company an intense user. What this means is that companies that decide to implement SAP APO select the areas of supply chain management that are most important for them and implement the SAP APO application or applications for that area, leaving the rest of their supply chain controlled by a combination of SAP ERP and other legacy or best-of-breed solutions. Determining which applications are the best to implement isn’t as straightforward as it sounds, however. Many companies are currently attempting to move toward service level planning (a.k.a. inventory optimization); however, this functionality is contained within an application that many customers don’t look at unless they’re considering service parts planning.

In addition to resources, your company needs to keep an open mind because there may be functionality accessed from applications that weren’t originally thought to be part of your initial implementation. But they could add value to the company. This is just one side of the story, of course. The other side is that SAP APO is now such a broad suite of products that there are applications that cover areas of the supply chain for which companies don’t have business processes. For instance, many companies don’t have manufacturing operations, so they don’t need Production Planning and Detailed Scheduling (PP/DS). Not every company does supplier collaboration, so obviously, they wouldn’t need SAP Supplier Network Collaboration ( SNC).

Limiting the Implementation

In addition to limiting the implementation of different applications, companies also don’t implement all of the functionality within a given application. In fact, when performing SAP APO diagnostics on accounts, the amount of functionality implemented within an SAP APO application is usually surprisingly small. For example, I have seen SAP Demand Planning (DP) implemented to act as a container for the forecasts from other systems, but it performs no forecasting itself. And I have seen PP/DS used only to level production output and nothing else. There’s nothing wrong with this, and implementing even small functionality areas can be beneficial to a company because each of the applications can be used for narrow or broad implementations.

For now, let’s look at an overview of the different SAP APO applications.

SAP APO Applications

SAP APO is an umbrella term for several applications that address specific areas of the supply chain. Table 2.1 lists the applications that make up SAP APO:

The SAP APO Applications

SAP APO is an umbrella term for several applications that address specific areas of the supply chain. Table 2.1 lists the applications that make up SAP APO:

Another component that comes with SAP SCM is called the Core Interface (CIF), used for integration. Some people consider CIF an application; however, I don’t list it as an application here because it’s an integration component necessary for SAP SCM to run but doesn’t provide supply chain functionality. SAP SCM Configuration FoldersThe SAP Easy Access configuration screen organizes the applications by folder. The Implementation Guide (IMG), which is where the more basic configuration items are set up, also organizes the applications by folder. The SAP Easy Access screen incorporates settings from the IMG into its configuration (see Figure 2.1).

The Organization of the SAP Configuration Menus

The SAP configuration menu is now broken into folders with older SAP SCM applications in the Advanced Planning and Optimization folder. APO was the original name of SAP SCM, and the term still applies to the suite. For applications such as SNP and DP, these are listed under the Advanced Planning and Optimization folder. Newer applications such as SAP SNC and SAP EWM are not purely planning applications. Therefore, they are listed under the overall SAP SCM folder but not under the Advanced Planning and Optimization subfolder.

Roughly one-half of the applications (DP, SNP, PP/DS, GATP, and TM) are older and more established, so they have many implementations behind them. The other half (SAP SPP, SAP EWM, SAP EM, SAP SNC, and F&R) are more recent additions that have received the bulk of the development work in the past few SAP SCM releases.

SAP SCM Application Interactions

Understanding how each application operates is one part of understanding SAP SCM. However, another equally important component is knowing how the applications interact with one another and other systems. Because we’ll cover each application in its own chapter, we’ll spend the rest of this chapter discussing interactions. But keep in mind that although there are strong tendencies for certain applications to work together, SAP SCM doesn’t have a singular workflow
between the applications.

The Core Interface (CIF) is an integration harness with pre-built adapters that transfer both master and transactional data between SAP ERP and SAP SCM. CIF supports all of the integration applications, although to different degrees, which is why we’ve placed it in Figure 2.4 as unassociated with the SAP SCM applications. This way, it represents CIF as a platform component. The one caveat to the figure above is about F&R and EWM. Both of these applications are just getting started in the marketplace as of this writing, so there isn’t much integration to date.

In the following figure, you’ll see the second types of most common integrations.

SAP ERP to SAP SCM SAP SCM can be implemented without SAP ERP, but it’s extremely uncommon, and I have never heard of a single case of SAP SCM being implemented this way (this isn’t to say it doesn’t exist). The integration between the systems is a primary reason SAP became the number one advanced planning vendor globally. Today, SAP ERP’s interaction with SAP SCM is more defined than the interactions between the SAP SCM applications. The most common SAP SCM to SAP ERP interactions are shown in the following figures.

Investing in Documenting What Was Done

In performing research for our upcoming book on SAP SCM, we decided to research case studies. After several hours, we came away very much surprised at the poor quality of the case studies, produced by both SAP and large consulting companies. Most seem to be happy to introduce the client and module used, then briefly discuss the business problem and then begin lauding the great success before listing some suspiciously rounded numbers on the financial benefits. The experience of reading many of these case studies is the equivalent of opening a large container that you carried many miles only to find it empty. One consulting company that shall remain nameless provides two page case studies that essentially say that one of the SCM modules was implemented in some clients in some countries. The consulting company did a fantastic job and saved 10 million dollars. The case study asks the reader to use their imagination to fill in all the missing details. This must be really not at all confidence, inspiring to their prospective clients.

Note to Consulting Firms

You must have people that actually know how to write put together case studies. It’s not something to be given as a special project to someone with limited experience on the beach and then pairing them up with a partner. If the case study is overly controlled by the sales or marketing group, it will be one sided, lack detail on how things were accomplished, and lose its authenticity. The case study needs to have involvement from someone, preferably multiple people that were actually on the project, and must have equal editorial control given to consulting — and if development was performed on the project — then to development as well. For those unsure how to implement this, blogging software — like the kind used for this blog — allows multiple individuals to collaborate on written work and provides a control model (some participants are contributors, some are editors, etc..) which can help coordinate the entire process of bringing together people who do not report up through the same organizational structures.

Reasons for Poor Case Studies

I have heard for quite a bad state of case studies that they are put together by the sales arm of the consulting company (and by SAP), and this arm of the company sees documenting what was done as getting in the way of the sales process. Another reason given is that companies don’t want to give up trade secrets. However, this is hard to believe as all types of details can be given up before anything proprietary is given up.

A lack of documentation for what was done brings up a concern for how the lessons learned from SCM projects are actually occurring. It is understood that a company does not want to disseminate everything about a project, but writing pure brochureware, and which is not updated or integrated with the learnings from other projects, is not the way to go either.

The History of APO and the Influence of i2 Technologies

To understand SAP APO design, it is important to comprehend the environment when it was first developed and released and how the situation changed as SCM was continually developed. This history below is seen through the author’s lens, who began in SAP ERP and then switched to i2 Technologies, before moving into SAP SCM several years later. It is an interesting story, which we have not seen documented elsewhere, and which also provides an insight into SCM regarding its design and orientation.

If internalized and analyzed, this history can be used by companies to make informed decisions about future supply chain implementations.

APO’s Origins

SAP APO was introduced at the height of the advanced planning trend back in 1998. This was when i2 Technologies was the number one advanced planning vendor, and Manugistics was close on its heels. It’s hard to conceive of at this point because SAP APO became so dominant in the advanced planning space, but SAP was not seen as a factor and was not predicted to become one.

At one time, i2 Technologies and SAP entered into a joint development relationship that SAP eventually broke off (the details of how and why are unknown to us). However, while the relationship never resulted in a product, it is clear from analyzing the early APO footprint and working in implementing both products or groups of products that SAP was heavily influenced by their relationship with i2. We can not say how many of the ideas or methods from that partnership ended up in the APO product because we don’t know what SAP’s starting point was. However, SAP has a long term strategy of “adopting” IP from vendors that it creates partnerships with. And this is part of the complaint by Teradata in their lawsuit against SAP for IP theft, which you can read in our analysis in the article How True is SAP’s Motion to Dismiss Teradata’s Complaint.

i2 was instrumental in influencing APO. Later companies, such as MCA Solutions, would serve as templates for later modules like SAP SPP. And SAP has demonstrated a long-term strategy of taking the intellectual property of smaller software companies. Their trademark approach is the dangling of a “partnership,” which in almost every case ends up benefiting the smaller software company very little. The xApps program was a massive competitive intelligence operation designed to gain access to intellectual property that SAP could backward engineer into their products.

SAP interacted with i2 at the beginning of the APO development and was when SAP had few resources knowledgeable in advanced planning. This was critical for SAP to allow them to create a starting point for their product. i2 eventually sued SAP for stealing intellectual property. What SAP learned from their partnership with i2 was important for the directions they took later with APO.

APO’s i2 Influence

Planning engines need a lot of memory. The SAP APO name for this memory area is called liveCache. At the time, i2 was powerful in factory planning and supply chain planning. They were known for memory resident engines that we’re able to plan and re-plan very quickly. Until this point, planning systems would not pull the entire problem into memory but would write back and forth to a database. i2’s contribution was to load the whole problem into memory, which was only possible because of the hardware improvements in memory capacity and price. They were also one of the first companies to use the term “optimization“ in the supply chain space for its marketing literature and promote the benefits of supply chain optimization.

The term optimization soon became a buzzword and highly desired functionality, even though many of the executives and their supporting managers at companies and analysts most likely did not understand the operations research-based meaning of the term.

The Misleading Success of i2 Technologies at Texas Instruments

i2’s early successes at companies such as Texas Instruments made the industry sit up and take notice to take a look at this “advanced planning thing.“ It’s hard to believe as I write this, but at one time, i2 was viewed as a threat to SAP’s core ERP product. In fact, SAP was considered to have a legacy product, as this quote from AMR Research directly states.

“The sad thing is, without knowing it, (SAP)R/3 has become a legacy platform.“ – AMR Research 2001

Some analysts began disparaging SAP for not having an advanced planning suite.

In hindsight, this interpretation was unfounded. Anyone who works in planning knows that planning and execution are done differently things.

• Even if i2 and Manugistics had continued to grow, and SAP had never introduced APO, companies would still need SAP ERP because advanced planning applications do not process the recommendations.
• Secondly, the supply chain areas of ERP are just one part of ERP. ERP also has finance and accounting portions. At this time, there was some discussion by analysts about getting rid of execution systems altogether. This was proposed by analysts, but I recall it being recommended several times by people inside of i2 when I worked there.

But Gartner has a poor history of accuracy in its projections, as we cover in the book Gartner and the Magic Quadrant.

Gartner Gets it Wrong…Again

However, unfounded it was part of the psychology at the time. Most certainly influenced SAP’s decision to seek a partner in the advanced planning space and base its supply chain planning product on that vendor. These vendors were bringing out functionality in the supply chain that made SAP ERP seem dated at the time. In this way, APO can be seen as a defensive product brought out to neutralize the momentum of vendors like i2 and Manugistics.

From reading statements of SAP executives at the time, it seems that they were not particularly enthusiastic about developing APO and were probably perplexed that some customers were even interested in this functionality.

The Early Versions of APO

The early versions of APO impressed no one, and it almost certainly would not have survived if SAP had not given the product away for free at existing SAP ERP accounts. Furthermore, because SAP had always outsourced such a large percentage of its consulting to the large consulting companies, they were some of APO’s first adopters. It is estimated that in the early stages, ¼ of all the APO installations were at consulting companies that had set up training systems.

Thus APO had two strong selling points that the niche advanced planning vendors could not match, even while the functionality considerably lagged:

• Large consulting companies had the incentive to promote APO with their SAP ERP clients to get more of the consulting work. (the niche vendors never had the relationships or outsourced the same percentage of consulting to the major consulting companies)
• APO was integrated into SAP ERP (for details, see chapter 9).

APO’s early incarnations featured five modules, which are listed below:

1. DP
2. SNP
3. GATP
4. PP/DS
5. TP/VS

This solution design was limited to these modules as late as APO 4.1. However, Internet Collaboration Hub (ICH) appeared before 4.1 but never became a completely developed module until later releases. APO gradually grew out to encompass ten modules, although none of them as commonly implemented as three of the original (DP, SNP, and PP/DS)

How to Best Understand the Terms SAP SCM vs. SAP APO

SAP SCM and SAP APO are often used interchangeably, but there is a difference between the two. When APO had fewer modules, it was known as simply SAP APO. However, several years ago, SAP rebranded the product SAP SCM but kept the name APO for the older modules. So SAP SCM is an umbrella term that includes both the APO modules and newer modules. The breakdown looks like this:

APO = DP + SNP + GATP + PPDS + TPVS + SPP + CIF

SCM = APO + SNC + Event Management + EWM

There are other components in each classification, but these are the major ones that most people discuss. The one exception to the rule is SPP. SPP is a new module but was placed in the APO hierarchy.

More Execution in the Comming Releases

The new modules are stretching the definition of “planning” while SNC and EWM have planning functionality; they also have a lot of execution functionality that never was placed in SAP SCM or APO previously. While APO’s old meaning was advanced planning, the new meaning of sAP SCM appears to be – advanced supply chain functionality, planning, or execution. This would provide a logical background for the name change from APO to SAP SCM.

SAP Planning Terminology

For us, the use of APO is no longer as good a term as SAP SCM. SAP SCM describes all the modules, whereas APO only describes some of them. However, the name change SAP pulled off is a bit confusing because there supply chain functionality in SAP ERP, but there is no “advanced planning” in SAP ERP. So by changing APO to SCM, SAP has created the possibility for some confusion. However, that is where we are; as long as everyone understands SAP’s terminology, that is important.

Maturing from SAP APO to SAP SCM

As SAP SCM began to accumulate implementations, SAP began to hear of additional needs from companies. As they were sophisticated needs, they were seen to fit with the APO product naturally. However, many of them were not distinctly advanced planning oriented. New modules such as Supplier Network Collaboration (SNC), Extended Warehouse Management (EWM), Event Management (EM), and Forecast and Replenishment (F&R) first appeared and then were enhanced in following releases. This is, in our view, the reason for the name change from APO (Advanced Planning and Optimization) to SCM (Supply Chain Management). In fact, the SCM folder organizations show APO still as a major folder with the older modules of DP and SNP below it, while most of the newer modules such as EWM and SNC outside of this folder hierarchy.

SPP is located under the APO folder as it is an advanced planning application. While the name change is logical, it is also somewhat confusing as SCM also refers to SAP ERP functionality. Therefore, now when one speaks of SAP SCM, occasionally, it is necessary to declare whether one is speaking of SAP SCM or SCM functionality within SAP ERP.

Why SAP’s Renaming of APO to SCM Failed

There was an attempt by SAP to change the terminology around APO that occurred concerning APO some time back. Essentially this was done to try to differentiate the more executional modules, like EWM, from the planning modules — many of which had optimizers. SCM is the umbrella term. In fact, my book on SAP was titled “Discover SAP SCM,” which means that it provided coverage of all the modules in the SCM suite, not just the APO modules.

What Happened With the Renaming SAP APO to SCM?

I spent time explaining what the difference was between APO and SCM to clients for a few years, actually. And my conclusion is that the name change was a waste of time, and the name change has not been taken in the industry. The APO and SCM modules are all referred to as APO. If I could rename my book title to “Discover SAP APO,” I would. I may talk to my publisher about a rename in a future edition.

Why?

SAP’s product renaming is always hit and miss. In fact, most renames don’t work out. For instance, no one is sure whether it is BI or BW, and often call this product BI/BW, or one or the other. Unknown to many people who work in SAP, SAP changed the name of SAP ECC (once SAP R/3) to SAP ERP. I started using the term “SAP ERP” after I was told by my publisher that SAP is moving to SAP ERP with my clients. On many occasions, I have been stopped and asked, “what is SAP ERP?” The ERP system is now reverting to the term R/3 with the term ECC falling into disuse.

However, aside from the spotting track record in renaming, aside from just making the rename, SAP never really spent much effort explaining the rename and its logic. Secondly, the rename was poorly conceived because SAP SCM also refers to SAP ERP modules. Therefore, any linguist would tell you SCM was not a good term to describe APO as it would always be confusing as to one was discussing SAP SCM in R/3 or SAP SCM as in “APO.”

Future

Therefore, I am dropping the term SCM from my blog posts because I have to explain what it is every time I used it. I have also been removing the term SCM from posts and replacing them with APO.

Key Learning

I think what I learned from this is that SAP does not entirely control what people call its products. Rather than leading and following SAP’s official “policy” on terminology, it’s better to take a wait and see attitude and see if other people are using the new term. All that SAP was successful in doing was creating confusion about their product with the renaming. Once SAP can’t get traction with a rename, they generally go back to the old name. They did this with BI/BW, and I am confident they will do this with APO.