- 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.
- Best Practices: SAP has long proposed that customers do not need to customize SAP, but can use it as is, as it contains best practices, which we cover in the article How Valid are SAP’s Best Practice Claims?
- SAP Accelerated SAP (ASAP): (Which we cover in the article, Did SAP’s ASAP Methodology Ever Reduce Project Timelines?
- Solution Manager: (Which we covered in the article The End of the Line for Solution Manager?)
- SAP RDS: (Which we cover in the article How to Best Understand the Faux SAP RDS)
- Preconfigured Solutions: These are what SAP or consulting companies say allows SAP to be brought up more quickly as so many of the settings are “preconfigured” mostly based on an industry template.
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?
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 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
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