Did SAP's ASAP Methodology or RDS Ever Reduce Project Timelines?

Table of Contents: Select a Link to be Taken to That Section

Executive Summary

ASAP was a methodology (or method actually) to reduce SAP project timelines. RDS was a grouping of tools designed to do the same.
What is the reality?

Introduction

SAP’s ASAP was one of the company’s broader initiatives. SAP ASAP was a project methodology whose intended purpose was to speed SAP’s implementation projects. In this article, we cover what happened with ASAP.

Notice of Lack of Financial Bias: We have no financial ties to SAP or any other entity mentioned in this article.

This is published by a research entity, not some lowbrow entity that is part of the SAP ecosystem.
Second, no one paid for this article to be written, and it is not pretending to inform you while being rigged to sell you software or consulting services. Unlike nearly every other article you will find from Google on this topic, it has had no input from any company's marketing or sales department. As you are reading this article, consider how rare this is. The vast majority of information on the Internet on SAP is provided by SAP, which is filled with false claims and sleazy consulting companies and SAP consultants who will tell any lie for personal benefit. Furthermore, SAP pays off all IT analysts -- who have the same concern for accuracy as SAP. Not one of these entities will disclose their pro-SAP financial bias to their readers.

The Stated Intent of ASAP

ASAP was, in great part, a type of counter-marketing. By the mid-1990s, SAP had received a well-deserved reputation for being very difficult and time-consuming to implement.

SAP wanted a magic wand that they could use to dispel the accurate impression that SAP projects took too long and were too expensive.

Therefore they invented ASAP. And they asserted the opposite.

ASAP was introduced with a great deal of fanfare, with the impression given that SAP had created something new. However, ASAP was just a standard implementation methodology. Essentially there are major steps, and then within those steps, there are substeps.

ASAP had several tools, including things like Microsoft Project templates and other associated tools. However, there was nothing that SAP provided that allowed a project to be sped up.
SAP’s applications themselves were not made easier to implement.
Furthermore, the types of tools offered by SAP already existed on projects.

The Actual (Sales) Intent of ASAP?

What is the actual intent of ASAP?

Was it to reduce the actual timelines of SAP projects?

That isn’t very certain.

This is because there are well known structural impediments to improving the implementation timelines, which included the following:

SAP’s Inherent Difficulty and Complexity: SAP is a complicated software to master.
Oversold Software: SAP usually is oversold, which means that a part of almost all projects is the consulting team having to manage the expectations created during the sales process. On one project, we spent months going around and around on how to “get creative” to make SAP do something it was not designed to do regarding deployment. However, SAP account management did not want to admit “defeat,” so we wasted a lot of time coming up with different combinations of functionality, none of which worked.
Customization Creep: Because all SAP projects are oversold, the amount of customization required helps “blow” the budget and the timeline of the implementation.
SAPGUI: SAP’s SAPGUI is challenging to navigate and requires repeated training cycles to get users to use it properly.
Outsourced Consulting: SAP is the only software vendor that we have ever tracked that outsourced almost all of its consulting to consulting companies. Only around 2% of SAP’s revenues come from consulting. SAP does this in exchange for recommendations, and consulting companies enjoy recommending software where they can make the most money. However, consulting companies have no interest in reducing implementation durations. They have just the opposite incentives. Some SAP projects have gone on for 5 to 10 years. The Caterpillar Logistics SAP implementation is an excellent example of this, with hundreds of consultants from IBM and Accenture billing Caterpillar Logistics for over a decade. This produces an excellent income and job security for SAP consultants. The last thing any SAP consultant wants is rapid deployment. SAP knows this, and if SAP were interested in reducing implementation durations, they would implement more of their projects themselves. However, that is not their model and not what SAP’s success is based upon.

Notice that none of these characteristics have changed since ASAP was first implemented. If SAP was interested in shortening its implementation durations, why were none of these structural and impactful features changed?

Did SAP ASAP Ever Do Anything?

In 2015, what is SAP’s reputation as a software vendor regarding its implementations? That they take a long time and that they are costly. We have the only online TCO Calculators available online and have accounted for these facts in our calculators, which you can check. This is the same reputation that SAP had back when ASAP was introduced in the mid to late 1990s!

In many projects, we never noticed projects being sped by ASAP or any other methodology. Therefore, it is tough to see ASAP having any real impact on projects.

SAP Consulting Companies “Aligned with ASAP?”

Furthermore, nearly all SAP consulting companies would market that they were “aligned with ASAP.” However, where they aligned with making less money? Because that would be the implication of implementing SAP faster at companies. Interestingly, I have worked with quite a few consulting companies. I have never run into an interest in making less money, even if it improved their clients’ condition.

Interestingly, if you analyze consulting companies’ internal financial incentives, they are entirely based on billing hours. So how exactly would any SAP consulting company be interested in reducing its billing hours?

What Are the SAP RDSs?

There currently roughly 120 RDSs, but this number is misleading as many of the RDSs are still being developed, although it is difficult to be sure if all the RDSs will continue to be developed.

RDSs overlap with SAP Best Practices but are a combination of several different things. They are often confused with wizard-driven configuration assistants, but they are not this.

RDSs significantly differ from one another. Therefore, it cannot be said what is in any particular RDS package, as it depends on which RDS is being discussed. Consequently, it can only be said what RDS is generally.

As many RDSs are still being developed – but have been “released,” the quantity of what is in an RDS greatly varies from RDS to RDS.

A Generalized Description of RDSs

The best-generalized description of RDSs would be the following:

SAP Basis notes
Process flow documentation
Configuration guides (the same as those that are referred to in SAP Best Practices)
Basic Demos (assumed to be data and accompanying documentation) (in only some cases, but not all RDSs have them)
An implementation approach assumes a small and simple solution, with tiny requirement gathering as the standard – simple configuration is accepted in all areas. (although this point is not generally emphasized)

RDSs are a standard package. For example, the RDS Foundation Starter RDS includes material for the following areas:

ERP
HANA
Lumira
Fiori
BOBJ

However, at a previous prospect, while the RDS Foundation Starter was included in the scope, only one or two areas above were in scope.

The larger RDSs have enough content to organize the documentation per area of SAP. We will go into Accounts Receivable to see the detailed view.

Within one area, some explanation is of the area is combined with document links.

ASAP for RDS

There is also ASAP for RDS. A check was performed comparing what is available from ASAP 8 to ASAP 8 for RDS under one of the ASAP steps. The following was found:

Under Project and Budgeting, ASAP for RDS has two more documents.
Under Project and Operational Standards, ASAP has some ALM documents not part of ASAP for RDS.
Under Execution, Monitoring, and Controlling Results, ASAP for RDS has an Agile Project and Sprint Backlog document.
Under Project Team Training ASAP for RDS, there are more documents than under ASAP.
Under Business Process Map, ASAP for RDS has an additional Agile Lean Blueprint document.
Under Data Migration Approach and Strategy, ASAP has several more Data Migration documents.
ASAP for RDS has a subheading and two documents under Demo Environment that ASAP does not have.
Under Phase Closure and Sign Off phase Deliverables, ASAP has some documents that ASAP RDS does not have.

Overall, there is slighting different documentation offered between ASAP and ASAP for RDS. However, the differences between ASAP (standard) and ASAP for RDS appear to be minor.

SAP’s RDS Claims

“Build your roadmap with multiple RDS packages that leverage the latest innovations in SAP HANA.
Low TCO, faster speed to market, low custom code, easy usability, and agile implementation.
Best practices content to harmonize your processes
Quick ROI
We need to improve the business process NOW!
At least 40% time and effort reduction compared to a similar scope of a traditional project.” – *ASUG

*ASUG – ASUG published these bullet points, but ASUG is just a media outlet for SAP. Like SAP Press, they do nothing and publishing nothing without checking with SAP and/or often being sent the material from SAP. These bullet points came from and should be considered straight from SAP.

These claims are made in rapid sequence, but let us step back and analyze each of them.

Multiple RDSs and Innovation?

Curiously, after analyzing RDSs, we can say only the first claim has any validity, and only partially, as only half of the claim is true. It is possible to use multiple RDS packages, but this does not lead to leveraging any innovation that you would not leverage without the RDS.

Lower TCO/Faster to Market?

SAP does not have evidence that they have published, which shows RDSs lower TCO of either HANA or any other SAP product.

There is also no evidence that RDS leads to faster implementation.
There is no evidence the resulting implementation is more usable.
There is no evidence that it is Agiler.

Best Practices and Process Harmony?

RDSs do not contain best practices, except to the degree that the RDSs contain previously published best practice documentation. Yet, the SAP best practice documentation that SAP refers to is not best practices in the conventional sense of the word.

SAP calls what would usually be called configuration documentation “best practice documentation.” But here are some crucial features of his documentation.

Anything Useful in the RDSs?: In the areas that I configure, I would never use this documentation.
What Did SAP do to Create the RDSs?SAP did take a configuration document from a project and called that particular configuration best practices. And again, every one of these documents was already published before the RDS was introduced.

Quick ROI?

SAP does not perform TCO estimations, so it is not in a position to perform ROI calculations.

Need to Improve Process NOW?

There is no evidence that RDS improves business processes or improves them faster.

40% Reduction in Implementation Time?

The 40% that SAP throws out is entirely made up, most likely by marketing. The point of that number is to offer a specific number to customers and prospects. When people see a particular number, they tend to think of it as more credible.

SAP provides no evidence for any of the claims for RDS.

What Really Happens on RDS Sold SAP Projects?

What happens on projects sold under the construct of using RDSs stops using RDSs quickly into the project once the customer figures out what is in them. The projects that use RDS are invariably reset and extended.

What the RDSs (Actually) Are

We cover this in more detail in the article How to Best Understand the Faux RDS. However, we can provide a synopsis of that analysis here.

The best-generalized description of RDSs would be the following:

SAP Basis notes
Process flow documentation
Configuration guides (the same as those that are referred to in SAP Best Practices)
Basic Demos (assumed to be data and accompanying documentation) (in only some cases, but not all RDSs have them)
An implementation approach assumes a small and simple solution, with tiny requirement gathering as the standard – simple configuration is accepted in all areas. (although this point is not generally emphasized)

As a long-time SAP implementer, who was hired to evaluate the RDS’s value, I can say that the hastily cobbled together RDS packages do not have any value to implementation. It takes longer to understand what is in each RDS that the RDS gives back in value.

After analyzing many RDSs and reflecting on them, I could not think of any use I would have for the items as part of the RDS package.

The Real Outcome of Introducing and RDS

The unfortunate outcome of the analysis of RDSs is that it took time to evaluate quite a few of them. And then to explain to people who did not know what was in them why was SAP was telling them was incorrect and that not only would RDSs not add value, they would result in an unrealistic timeline being created that would never be met.

It is difficult to see the RDSs as anything more than a dishonest attempt on both SAP and their consulting partners to mislead customers into thinking that the implementation duration will be shorter than it will turn out to be.

Who Developed the Idea of the RDS and Why?

The critical thing to remember is that RDSs were not developed by SAP consulting. SAP consulting most likely had a part in categorizing the already existing documents into “RDS” packages, but the idea most certainly did not come from them.

They were created by SAP marketing and promoted by SAP sales, two groups that generally tend to downplay the duration of projects to customers: Spoiler Alert: so they can sell more.

RDSs were the absolute minimum amount of work that SAP could do (by grabbing pre-existing items that had been around for years) and put them into an RDS so that marketing could say that they had “something.” And no marketing or salesperson can tell a consulting resource what will speed implementation as they have never implemented software before. The RDSs have the distinct odor of SAP marketing first, creating all of the claims (based on what they knew prospects would want to hear) and then issuing the task of finding pre-existing documentation to put into the RDS.

Who Told the Truth on RDSs?

And at the risk of being a broken record, there was not a single SAP consulting company. We could find that contradicted the story of the SAP RDS in any published form we could find. Quite the contrary, SAP consulting companies have routinely promoted RDSs. However, most senior people in these consulting companies do not know what is actually in an RDS.

Making RDSs “A Thing”

SAP has a relationship with a publishing company called SAP Press. SAP does not outright own SAP Press, but they remotely control them. When SAP is trying to push a new application or concept, they rely upon SAP Press to publish a book in the area. Some of these books are written by outside consultants. For example, I wrote a book for SAP Press. But a book like this, which deals with a marketing construct, will ordinarily be written by a person who works for SAP.

And there is a book on RDS by SAP Press.

The SAP consultant or SAP employee will ordinarily not care if anything in an SAP Press book is true. Many of these books are designed to get excited around an area that SAP is introducing. A book like this one will be straight material that SAP would like customers to think is true. The more they buy into the RDS, the more software SAP can sell. People reading an SAP Press book may think they are getting real information, but they aren’t. They are getting information that SAP approves of being published. Much of it is straight from SAP marketing.

Curiously, with SAP Press books, buyers pay what usually is around $70 for the right to be propagandized. I have read many SAP Press books in my life. I read them more as media criticism. Some of the things in them are true, but any critical information or information that contradicts the official SAP position would never be published in a book by SAP Press.

As an SAP Press editor told me, “our job is to make SAP look good!” (Her exclamation point, not added in). Replay that in your mind for a moment. Is that the actual job of a publication? Are we talking about something identified as marketing literature here or something masquerading as an independent book?

RDS and HANA

As with other products, HANA also has an RDS. Below you can see a typical slide from SAP on RDSs for HANA.

However, data points coming in from many locations are not showing quickly implemented HANA projects. The reason for this is that HANA is still immature as a product and uses both components below it that must be mastered as well as other databases that are sold with HANA, like ASE and IQ that perform tasks that are necessary even to use HANA.

Due to HANA’s high complexity and immaturity, it takes longer than other databases to implement, whether an RDS is used or not. At some point, the information about HANA’s long implementation duration will get out. In those cases, SAP will respond to those concerns by pointing to the RDS.

Again, the RDS is useful for telling the customer not to observe HANA’s actual implementation history.

The Real Project Duration of HANA

A typical HANA implementation will take between 1 year and 1.5 years to migrate finally. This means that the customer has to run the HANA sidecar this time and absorb the cost. This is a longer duration than is pitching by SAP account executives, and it is one reason why HANA’s TCO is so high. This is where the RDS comes in. It has no value for the project; its “value” is in the sales process. That is, the RDS is valuable for SAP sales, not for the customer.

We cover HANA’s TCO in the first and only independent TCO analysis of HANA.

How SAP Pretended RDSs Sped and Simplified Implementations to the Investment Community

RDSs were used to excite the investment community on improving implementations and increasing license revenue.

Snabe’s explanation is that SAP has spent a good amount of time optimising implementations and cited RDS as one of the key planks in that strategy. As I said, we could have a good conversation on that topic alone. What I am hearing is that yes, RDS does simplify implementations, but only where you’re prepared to implement SAP’s version of best practices. We have yet to see substantial evidence from customers as to how that’s working out. – ZDNet

Go to top

Conclusion

There were things that SAP could have done to improve the speed of the implementation of their applications. However, SAP did not do anything in these impactful areas and instead introduced the ASAP methodology. It did not contain anything different from many previous implementation methodologies and did not address the fundamental reasons why SAP implementations took so long.

In our accuracy rating, SAP ASAP receives a 2 out of 10.

Many people who talk about RDSs have never researched them and don’t know what is in them. RDSs follows a long line of things that SAP has introduced, including ASAP Methodology and Solution Manager, along with other items predicted to speed the SAP applications’ implementation time but have never had the intended effect.

In our accuracy rating, SAP RDS receives a 1 out of 10.

References

https://www.computerweekly.com/news/2240083294/Choosing-a-partner-for-building-a-SAP-service-oriented-architecture