Executive Summary

  • LaunchPad Support is targeted toward a specific category of SAP customers that wants to fix long term shortcomings in their SAP applications.
  • In this article, we explain our support approach and what is SAP custom development.

Introduction

There are several categories of SAP customers. LaunchPad Support only targets a specific category of these SAP customers for our services. We support companies that are not getting what they need from SAP and which are in a later stage of their SAP application’s lifecycle within that customer. And this gets into the topic of what is SAP custom development, which is highly connected to the subject of SAP support. 

A Lesser Addressed Market, Particularly for Many SAP Applications

This is a much more significant percentage of the overall SAP customer base than customarily acknowledged. And to understand why means understanding the stages of SAP applications. 

The Stages of SAP Applications’ Lifecycle at SAP Customers

In the early stages of an SAP’s application being implemented at an SAP customer, the focus is on trying to address tickets, many of which are due to the discrepancy between what was sold by SAP and the reality of SAP. It can take years to go through and exhaust the various discrepancies. SAP’s support is designed to “wait the customer out.”

This means mostly trying to get the customer to give up on most of the tickets, and trying to close tickets as quickly as possible.

That is, a significant part of SAP’s support strategy is denial, and getting the customer to accept that what is not working for them is normal. When SAP customers are in this stage, they are very much wedded to SAP support, and with the “hope” of finding solutions through tickets, they are not a fit for LaunchPad Support. 

In the later stages of an SAP’s application lifespan at the customer, the tickets have mostly been followed up. In many cases, the SAP customer will not have obtained resolution to their satisfaction. SAP custom development is more common, and typically there are several opportunities for more custom development to address the gaps in the application. 

What is SAP Custom Development as Part of Support

SAP support is entirely ticket oriented and provides zero support for custom code. Instead, SAP gaslights and browbeats customers into thinking they are at fault for not using 100% SAP standard, which, of course, does not meet customer’s requirements. Customers are told that SAP contains all of the “best practices,” and any nonuse of SAP functionality is moving away from best practices as we cover in the article How SAP Uses Best Practices to Control the Implementation.

No SAP resource working for SAP nor SAP consulting firm will ever point out that this position is entirely self-centered and is about reinforcing the false claims made during the sales process, about the percentage of the customer’s requirements that will be met “out of the box” by SAP. Remember, the claims is 90% of the requirements are achieved “out of the box.” Yet 92% of SAP customers either moderately or highly customize at least SAP’s ERP system. 

What is SAP Custom Development: Custom Development in Early Stages of an Implementation

Nearly every SAP project has a large amount of unanticipated custom code. Then the implementation team arrives to deliver the bad news that many of the requirements are not actually covered by SAP. In this way, SAP is sold as a comprehensive solution but is actually a starter kit. 

As SAP custom development is initiated and the RICEF list grows, eventually, the list must be prioritized, and many customizations end up being cut out of the first go live. Many of the SAP custom developments are simply to reverse engineer “legacy” applications from the customer that SAP had stated would no longer be necessary. These applications were working perfectly fine in their own “houses” but these applications are typically refactored into ABAP, at great expense. This gives the illusion that much more of the work at the company is being performed by the SAP application than is the case. The “value add” of refactoring the applications into SAP is that now they are within SAP — which is stated as the new standard at the company. 

What is SAP Custom Development: Custom Development in the Latter Stages of an SAP Application

As time passes at SAP customers, SAP does less and less of the actual work and refactored pre-existing programs, new programs or Excel usually are increasingly relied upon to do the work. 

What began as a “clean sheet of paper” SAP implementation that was supposed to save the company money, becomes just one of the many systems that are used. The degree of reliance on SAP is overestimated with so much SAP custom development residing in SAP, but which has nothing to do with the code that is actually part of SAP. By this time, SAP has a new version or a whole new product that it offers to the customer. Every single one of the problems in the first SAP product is said to be fixed in the new SAP product, and in most cases, the same promises from the first product are simply carried forward in the sales and marketing literature for the new product.

Reconstituted and Migrating SAP Promises

There are many examples of this, but the marketing and sales material around S/4HANA is a perfect example of this. S/4HANA was proposed to do things that were supposed to have been accomplished already with SAP Business Suite. SAP consulting firms assist SAP by never bringing up the initial promises. 

In this way, SAP is not held accountable for its previous promises because the previous promises can always be migrated to the new product, which of course, the customer has not yet experienced, and therefore cannot definitively contradict. 

The Ideal LaunchPad Support Customer

An ideal LaunchPad Support customer is a company that is in the later stage of their usage of an SAP application, that needs long term issues addressed and that has already gone through the SAP support process and realizes that the answers will not come from SAP. These are also smarter SAP customers that are savvy to SAP’s ways. There is no mutual interest between SAP customers that want to stay on the SAP treadmill and continue to waste large amounts of their IT budget on a series of promises that don’t come true. 

Our Support Advantage

Unlike SAP or SAP consulting firms, LaunchPad Support takes an efficient approach to custom development. This means we do not develop new booster functionality by using SAP’s ABAP. We use the best development language for the needs of the application. Our hosting and deployment solution is also far more efficient than SAP.

Let us contrast this to SAP’s approach to ours in an easily comparable table.

Development and Cloud Comparison

Comparing cloud and development.
ApproachesSAP SupportUs
Remote or Cloud Costs
SAP expects customers to pay its HEC margins for giving terrible cloud advice.
Included in our support fee.
The Objective of Cloud Offering
To Maintain control. Obtain a high margin from its HEC network.
Choosing the best possible option.
Cloud Capabilities
Limited by what SAP determines as appropriate.
We access an enormous numbers of services.
When Cloud Dev is Proposed
SAP's weak set of development and cloud tools (such as SAP Cloud)
We deploy from 100% from AWS
Dev. Languages
Almost Entirely ABAP, with a few diversions.
The beset language for the development requirements.
Development
Primarily On Premises
100% Cloud
Overall Cost Implications
Paying SAP 22% hurts custom development -- costs are additive.
Brightwork reduces both support and development costs.
  • SAP: SAP proposes primarily on-premises development and the use of a feeble and uncompetitive set of development and cloud tools (such as SAP Cloud). These development tools will not be used outside of SAP customers. SAP development and cloud has nothing to do with choosing the best.  
  • LaunchPad Support: Because we use modern development languages, and we deploy from AWS, we have enormous flexibility to pick and choose the most appropriate services. Because leveraging public cloud providers cannot be very effectively marked up, SAP can’t follow this approach. SAP’s Upcharge as a Service does not apply to LaunchPad Support. 

Unlike SAP support, which pushes customers back to standard functionality, which has already been tested and does not support the requirements, LaunchPad Support either applies its booster functionality or develops new boosters that address the gaps. 

Conclusion

For companies that require older SAP applications to be repaired, SAP support is not only a bad value, but it is also very much like throwing money away. We offer support at a lower price than SAP; however, for late-stage SAP applications, SAP support is very close to functionally useless. This is one of the reasons that SAP obtains such an enormous margin on support.

  1. Restricted Coverage: SAP covers very little in their standard support.
  2. Custom Development: Eventually the work switches to SAP custom development management, which SAP does not support. This is because the vast majority of support work for late-stage SAP applications is custom development and custom code management. This is where we have focused our support offerings.

This presentation illustrates the problems with SAP support and how LaunchPad 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