- 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.
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?
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 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
Enterprise Software Risk Book
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.
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