How to Best Understand the Faux SAP RDS

Executive Summary

  • SAP introduced a Rapid Deployment Solution, which does nothing to speed project implementations.
  • Why the RDS is specifically designed to deceive customers.

Introduction to the SAP RDS

In this article, we will cover the SAP RDS or the Rapid Deployment Solution. SAP proposes that using the RDS speeds implementation, however in this article we will review if this is true.

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.

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

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.

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 SAP Project Management Content

SAP Research Contact

  • Interested in Our SAP Research?

    The software space is controlled by vendors, consulting firms and IT analysts who often provide self-serving and incorrect advice at the top rates.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, contact us and we will be in touch.

References

https://www.sap.com/services/rapid-deployment.html

https://www.zdnet.com/article/sap-defying-gravity-whoda-thought-that/

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

Did SAP’s ASAP Methodology Ever Reduce Project Timelines?

Executive Summary

  • ASAP was a methodology (or method actually) to reduce SAP project timelines.
  • The evidence is that it never 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?

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 1.5 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 SAP Project Management Content

SAP Research Contact

  • Interested in Our SAP Research?

    The software space is controlled by vendors, consulting firms and IT analysts who often provide self-serving and incorrect advice at the top rates.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, contact us and we will be in touch.

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