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

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.
  • The evidence is that neither of them ever worked, and may have never been intended to work.

Introduction

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

The Stated Intent of ASAP

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

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

Therefore they invented ASAP. And they simply 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 really just a standard implementation methodology. Essentially there are major steps, and then within those steps, there are substeps. 

  • ASAP had a number of tools, including things like Microsoft Project templates and other associated tools. However, there was nothing that SAP provided that actually 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 as the actual intent of ASAP?

Was it to reduce the actual timelines of SAP projects?

That is doubtful.

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 very difficult software to master.
  • Oversold Software: SAP is normally oversold, which means that a part of almost all projects is the consulting team having to manage the expectations that were 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 that is required helps “blow” the budget and the timeline of the implementation.
  • SAPGUI: SAP’s SAPGUI is difficult to navigate and requires repeated cycles of training in order to get users to use 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 comes 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. In fact, they have just the opposite incentives. There are some SAP projects that have gone on for 5 to 10 years. The Caterpillar Logistics SAP implementation is a good 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 actually 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 actually interested in shortening its implementation durations, then 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 extremely expensive. 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 exact 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 very difficult to see ASAP having any real impact on projects.

SAP Consulting Companies “Aligned with ASAP?”

Furthermore, nearly all of the SAP consulting companies would market that they were “aligned with ASAP.” However, were they really 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 interested in making less money even if it improved the condition of their clients.

Interestingly, if you analyze the internal financial incentives at consulting companies, 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 really a combination of a number of 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 one particular RDS package, as it depends upon which RDS is being discussed. Therefore, it can only be said what RDS are 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 which assumes a small and simple solution, with very little 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 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 steps of ASAP. The following was found:

  • Under Project and Budgeting, ASAP for RDS has two more documents.
  • Under Project and Operational Standards ASAP has a number of ALM documents that are not part of ASAP for RDS.
  • Under Execution, Monitoring, and Controlling of 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 extra 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 a number of documents that ASAP for 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

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

*ASUG – These bullet points were published by ASUG, 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. That is 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, at least that they have published, that shows RDSs lower TCO of either HANA or any other SAP product.

  • There is also no evidence that RDS lead to faster implementation.
  • There is no evidence the resulting implementing 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 is referring to is not best practices in the conventional sense of the word.

SAP calls what would normally be called configuration documentation “best practice documentation.” But here are some important 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?: What SAP actually did is 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 specific 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 that are sold under the construct of using RDSs stop using RDSs very 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 which assumes a small and simple solution, with very little 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 actually 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 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 the part of both SAP and their consulting partners to mislead customers into thinking that the implementation duration will be shorter than it will turn out being. 

Who Developed the Idea of the RDS and Why?

The important 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 normally have a habit of attempting 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 there is no marketing or salesperson who can tell a consulting resource what will speed implementation as they have never implemented software before. The RDSs has 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. Although in their defense, most of the senior people in these consulting companies do not have any idea 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.

Now the SAP consultant or SAP employee will ordinarily not care if anything in an SAP Press book is true. Many of these books are simply designed to get excitement around an area that SAP is introducing. A book like this one will be basically 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 actually pay what is normally 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 unflattering information or information that contradicts the official SAP position would never be published in a book by SAP Press.

As I was told by an editor at SAP Press, “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 a marketing literature here, or something that is 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 to even 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 the actual implementation history of HANA.

The Real Project Duration of HANA

A typical HANA implementation will take between 1 year and 1.5 years to finally migrate. This means that the customer has to run the HANA sidecar this period of time and absorb the cost of doing so. 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 how much they would improve implementations and increase 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

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 simply introduced the ASAP methodology — which did not contain anything different than a multitude of previous implementation methodologies, and did not address the fundamental reasons why SAP implementations took and take so long.

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

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

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

Financial Disclosure

Financial Bias Disclosure

Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.

Search Our Other SAP Methodologies Content

References

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

Enterprise Software Risk Book

Software RiskRethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects

Better Managing Software Risk

The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.

Finding What Works and What Doesn’t

In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.

Chapters

Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model