Does Design Thinking Improve SAP’s Implementation Speed?

Executive Summary

  • Design thinking has been proposed, but there is no evidence that it does so.
  • Why design thinking appears to be another in a long list of ideas to reduce the predicted implementation duration.

Introduction to Design Thinking

SAP introduced a new approach to a software implementation that it says can speed the implementation of SAP systems. SAP calls this design thinking, and in this article, we will review this concept.

Design Thinking Explained

In SAP’s publication Digitalist, they explain Design Thinking and system implementation in the following way.

“Not long ago when customers bought an SAP software product they had to wait months, even years before they could use it at their company. That’s changed with the advent of design thinking at SAP. This approach speeds up the development of technology solutions designed to delight users. At its core is the “developer 2.0” who bears little resemblance to familiar stereotypes. Design thinking developers want to know as much as they can about user needs and desires. These developers iterate quickly, in a matter of hours if necessary, and always as part of a new kind of team where the end user rules.”

So there is a problem with this quotation. First, Design Thinking was adopted by SAP, but it was not invented by SAP, which is what this quotation makes it appear to be. SAP is using the term “advent” which means “the arrival of.” So the sentence is technically accurate, but without looking up the term, many readers will take away that SAP invented Design Thinking. There are many more direct ways of explaining that SAP has adopted design thinking.

Where Did Design Thinking Originate?

As anyone can read on the Wikipedia page for Design Thinking, the concept officially goes back to the 1980s. However, the idea is fungible enough so that it probably goes back much further than that.

Secondly, while the article makes it appear that SAP software implementation is sped explicitly through design thinking, it turns out that the article moves to other specific things that speed the implementation of software.

“The Deployment Cockpit is one example of design thinking in action. Currently in pilot phase, this collaborative tool gives customers who have purchased an SAP Rapid Deployment Solution (RDS) instant access to everything they need for timely implementation. It’s an online portal that contains not only documents like a step-by-step implementation guide, but equally important, real-time access to every SAP consulting team member. There’s no searching or guesswork. Customers know who to contact at every stage of the process because they can see who’s working on which task and the status. With teams often scattered across multiple countries in various locations, instant access is crucial to on-time deployment.”

So now we have to items, the Deployment Cockpit and the Rapid Deployment Solution (RDS). Are these subcomponents to design thinking? As for the RDSs, we have analyzed RDSs and even evaluated many specific RDSs and have concluded that RDSs not only do not speed SAP implementations, most SAP consultants will not have any use for them, as we cover in the article How to Best Understand the Faux RDS.

Design Thinking or Agile?

As the article continues, it now migrates over to a new topic but calls that topic design thinking also.

“Given the new approach, Nabi Zamani, a developer on the team, wasn’t certain they would meet the project deadline. However, prototyping based on continuous user feedback actually sped up the process. Traditional development typically separates the product definition and development phases. But with design thinking, the entire team works together from defining the product through implementation.”

People may find this to be eerily similar to another well-known implementation methodology, which is called Agile.

So is design thinking part of Agile?

Design Thinking or Requirements Gathering?

“The design evolved as they collected feedback from over a dozen people globally who would be using the tool. These conversations revealed findings sometimes at odds with initial design directives from the internal management team at SAP.”

Once again, if that sounds eerily familiar, it is because this is the definition of requirements gathering.

It appears that SAP is new to getting feedback before development or implementation, which is strange.

Overall, it is becoming increasingly difficult to determine where design thinking comes into play as every example provided by SAP related to design thinking turns out to be something else.

This History of SAP’s Approaches to Speeding SAP’s Implementation

The following are previous tools or techniques that SAP said would speed SAP implementations.

So the question might be if all of these methods have already been successful in speeding SAP implementation, why is there the necessity for the introduction of another SAP implementation accelerator?

Conclusion

SAP’s design thinking as it relates to SAP implementation is not anything. It is simply another in a long line of items that SAP has introduced that are intended to make it appear as if SAP applications can be implemented faster than they can be. When an item is introduced as doing something, and then as soon as a specific example is required, that item points to something else, that means that original item is not anything.

Secondly, SAP implementations do not encourage creativity. SAP implementations are performed by SAP or consulting partners, and they seek rigid adherence to SAP messaging. That is, the implementers are to be passive recipients of SAP’s messaging.

The degree to which SAP is actually inconsistent with design thinking is explained by the following quotation from Wikipedia on design thinking.

“While feedback in the scientific method is mostly obtained by collecting observational evidence with respect to observable/measurable facts, design thinking feedback also considers the consumer’s emotional state regarding the problem, as well as their stated and latent needs, in discovering and developing solutions.”

This is a method for coming to new and creative solutions based on multidimensional inputs. This is not useful for systems implementation of a rigid packaged application like SAP, because you are not building anything new (except for customizations), you are implementing a predesigned application and fitting it to requirements as much as possible.

Design thinking comes into play when there is a great deal of originality required, and this means it is the opposite of an SAP implementation, which are more like assembly line affairs. The largest SAP consulting companies are rigid hierarchies where creative people do not last long. What is amusing about this is that SAP has adopted this philosophy without understanding that design thinking is the exact opposite of SAP’s controlled and mechanistic culture.

Design thinking for speeding SAP projects receives a score of 1 out of 10 for accuracy.

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.digitalistmag.com/industries/high-tech/2013/01/15/design-thinking-in-action-025302

https://en.wikipedia.org/wiki/Design_thinking

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 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