The Trouble with SAP APO Add-Ins

Executive Summary

  • What is SAP APO Add-Ins?
  • What is the problem in getting reliable information on SAP APO Add-Ins?
  • How do the Add-Ins position SAP Consulting in the future?
  • The problem in testing SAP APO Add-Ins.
  • Conceptually, should Add-Ins be sold separately?

Introduction

I was recently asked to evaluate two add-ins to APO. One being the APO Change Monitor and the other being the Assistant for LIfecycle Management. For whatever reason, these Add-Ins have not come up with much frequency on my previous projects. Come to find out that APO has several Add-Ins that are listed at this link. Interestingly, these Add-Ins can be relatively minor, such as the Assistant for Lifecycle Management, which allows you to declare dates that products will become obsolete and which products will succeed them and use their demand history in future forecasts. On the other hand, other Add-Ins are very significant. One of the Add-Ins promises inventory optimization. I happen to focus on inventory optimization and know that SAP does not have a product in this area. Therefore, this PDF’s information seems to indicate that they do, which would be surprising to their main partner in inventory optimization, which is SmartOps. This brings up the question of how reliable the information is about these Add-Ins.

It also makes the message coming from SAP Product Management even more confusing. Before, they declared no intent to offer inventory optimization and that SmartOps was their single partner. Now they do, but the solution looks weak, and inventory optimization is very complex. It is the most sophisticated technology in supply planning and is not simply an “Add-In” to an APS solution. If these are new products, the issue of reference clients becomes important because while many clients may have implemented DP or SNP, an Add-In may have very few actual clients where it has gone live. If a particular Add-Ins do not have several reference accounts that SAP can provide, the price can most likely be negotiated down.

Consulting Promotion

For some time now, SAP has been happy to allow the vast majority of consulting to be taken by the big consulting firms and then offer deep point expertise on things like the SNP Optimizer or other areas when clients run into problems. However, SAP Consulting has tied in consulting work with several solutions that are not, in fact, Add-Ins, although they have listed these services on the overall Add-In sheet. This indicates that SAP may be interested in taking more consulting work in the future and is positioning themselves for this work. Most of the offerings are listed as improving the current solutions that companies have already employed, such as “Optimizing MRP” (i.e., improving MRP).

I do a fair amount of this improvement work myself. While SAP can bring deep subject matter expertise, SAP Consulting cannot tell clients that other non-SAP software would be a better fit to offer areas that SAP does not have or that software should be blended /integrated with SAP. However, this is often the correct answer. Most clients I work with have gotten the easy stuff out of SAP already. The value is blending their SAP solution with either best breed applications in production or run as desktop applications that can do specific things that APO cannot. That is one of the issues relying upon SAP for post-implementation advice; it looks at the solution from only a single vendor perspective. In case anyone thinks I am recommending a large consulting firm for a broader perspective, I am not. SAP has so intensively co-opted the major consulting firms that they tow the SAP company line as well.

The Inability to Test Add-Ins

Even current APO customers are unable to test these Add-Ins. Normally, I can access any of my client’s systems and tell them if certain functionality works or does not work and whether it is useful to implement. However, with Add-Ins, one must purchase these products first, which makes the client dependent upon SAP, to tell the truth on the Add-In’s capabilities. Also, whether APO can do something now not only changes depending upon the release (and the enhancements that the client has written into the software) but also based upon whether the Add-In has been included. This makes for even more confusion on projects. There is already too much confusion because SAP sales reps or Product Marketing documentation frequently says APO can do things that it either can’t do or is so difficult or clumsy to get done that it’s not worth doing. So from the perspective of solution clarity and functionality testability, Add-Ins are a big step backward.

Should Add-Ins be Separate or Simply in the Product?

Several of the Add-Ins do things that other best-of-breed applications already do. It raises the obvious question of why companies have to pay more for functionality included in the base application. It also creates another layer of complexity that must now be explained.

Conclusion

Obviously, SAP sets the price and conditions of software sale, and companies are free to buy or not buy the Add-Ins. However, one must include these Add-Ins in the total cost of purchasing APO compared to other applications that include all this functionality that SAP charges separately for free. The problem is that current APO customers don’t have this option. They are locked into APO to find that some significant functionality is now being taken out of the normal upgrade path and is moved into Add-Ins. Generally, if clients push back on this pricing, SAP will change their approach here. I think Add-Ins is a bad precedent for SAP to set and for the clients to accept. There are multiple issues here which don’t seem right to me. Everything from breaking with industry norms to solution clarity to fairness in pricing. On all these factors, Add-Ins bring up areas for concern.