Understanding the Complexities of the Standard SAP ERP to APO Integration

What This Article Covers

• What are common questions with respect to SAP ERP to APO integration?
  
• What is the CIF?
• What is a seriously false assumption regarding this integration? 
• Why aren’t external prototyping applications frequently used in supply planning? 
• What are the problems with complex solutions like cost optimization, and how can external prototype environments help manage them?

Background

I am frequently asked how difficult it is to connect various best of breed planning solutions to SAP. I typically answer that integration between planning systems and SAP is greatly overrated in terms of difficulty. I often comment that planning systems have the benefit of have only a few interactions with ERP execution systems. I also tell people that ask that I have integrated planning systems to SAP roughly five times (both serving as the integration application engineer and managing the integration) and have never run into a major complication or missed deadline (unlike my experience with actually implementing supply chain application modules).

However, what is most interesting about the question, and an assumption that is often unexamined is that SAP ERP is not simply naturally integrated with its own planning system. The primary integration device between APO and SAP ERP is the Core Interface or CIF. The CIF takes a great deal of work to get working properly, lacks transparency, has weak error checking and consumes significant resources to “dial in” and get working properly. Secondly, the CIF requires more maintenance that any adapter that I have created (as part of a team) from scratch. I have known this for a number of years as I have been working with APO since 2002, however, recently I learned something else about the integration between SAP ERP and APO which I did not fully appreciate before, and this relates to the lack of controllability of the interface on the part of the implementing company. To explain this I will need to describe a recent experience.

Sales Orders and Forecast Consumption

APO has a setting which controls if and how Sales Orders consume the forecast. There are three quantities associated with a Sales Order, a Requirements Quantity, an Original Quantity and a Confirmed Quantity. SAP gives you the option of consuming the forecast from any of these quantities. This would seem pretty straightforward, however, it isn’t. This is because the consumption is not only controlled by directly telling the system through APO configuration, which of these quantity to use to consume the forecast, but this feature is also controlled by a field on the Sales Order called the Requirements Type. Using one Requirements Type causes consumption of the forecast to occur, using a different setting turns consumption for Sales Orders off. In the company I was consulting for, we spent quite some time attempting to troubleshoot this problem. Furthermore the documentation on this issue was slight and we had to raise a note to SAP. The lesson from this experience is that the values on the transactions that flow from SAP ERP control important functions within APO. However, is this desirable?

SAP would clearly say this is desirable. However, my experience is that it isn’t. SAP developed from an execution system, and entered into the planning market in my view, primarily at the nudging of analysts who very shortsightedly declared ERP “dead” back in the late 1990’s (which brings up the topic of the accuracy level of software analyst firm’s projections). SAP brought their extreme complexity and detail oriented approach which they had developed from their experience in execution systems to APO, which is not an execution system. Unfortunately, this has not been a very good match.

Why Planning Systems Should be Designed Differently from Execution Systems

Planning systems deal at a more aggregated level than execution systems, and having three quantities associated with a Sales Order is not necessary, and having configuration in the ERP system that controls important functions such as forecast consumption in APO is really more of a liability. As a planning consultant, I want to entirely control the consumption within APO, and I don’t want surprised like this that I then have to sort out with the ERP team. This glitch prevented the client from using the consumption logic for several months. The issue is that SAP has never seemed to understand that planning systems are different from execution systems, and this has resulted in a difficult to implement software suite in APO vs. best of breed vendors. For those that don’t think this one setting is that big of an issue, it should be understood that this is just one setting (and a not well documented setting). There are hundreds of settings like this, and every time I arrive on a project, because the project documentation is not well maintained in 90% of the instances, I have to check everyone one of these settings. This is why it takes so long to troubleshoot APO vs. other planning software.The importance of not documenting everything in APO was highlighted by the experience described here.

Integration Transparency

In the cases that I have created custom integration harnesses, I never ran into these problems because I was able to control the meaning of the transported objects (Sales Orders, On Hand, Stock Transfers, Purchase Orders, etc..) much more easily that with the CIF. However, with the CIF, you end up getting unwelcome surprises exactly like this. SAP has taken the approach that there should be tremendous complexity in the logic of the integration between their ERP system and APO. I think don’t think this has been a correct decision.

Conclusion

When evaluating SAP solutions, far too much credit is given for the adapters that SAP has created. This is not only true of APO, but true of the SAP BW (The SAP data warehouse) as well. The APO to BW adapters that ship as part of BW are extremely limited, and really just enough for SAP to discuss the “built-in” adapters with potential leads and to place into marketing literature. Similarly, of all the integration harnesses I have worked with, (all of the non-CIF ones being custom coded), I have liked working with the CIF the least. It imposes both a high maintenance overhead, and controls the integration in a way that oftentimes the client does not want. Therefore, it is interesting that APO is considered integrated to ERP, when my experiences have lead to conclude its worse than creating a custom integration from scratch. Just as interesting, I have never heard this topic discussed on any discussion board or article.

Share

Tagged as: CIF