- Checking with Experienced Database Resources
- The Typical Coverage Available
The SAP Run Simple is a widely derided joke in SAP circles. In this article, we question how much ComputerWorld got right regarding Run Simple.
“Nothing has earned a reputation for head-banging complexity among IT professionals more than ERP, but as enterprise-resource planning leader SAP tries to recast its image with the slogan “Run simple,” there’s no guarantee that customers will buy it.
SAP hammered the simplicity mantra home in virtually every keynote, conversation and bit of signage at its annual Sapphire user conference last week. Still, the fact remains that enterprise platforms like SAP’s are anything but simple, and neither are their customers. SAP sells to large, multifaceted enterprises, and implementations are a big deal, often requiring outside help.”
At this point, the article makes it seem that it is going to head down a truthful path. The Run Simple program was in exact opposition to how SAP’s software actually works.
“Most organizations don’t buy SAP because they have simple problems to solve,” said Geoff Scott, CEO of the Americas’ SAP Users’ Group (ASUG). “You purchase it because you’re a complex organization with complex business processes.”
ASUG’s Independent from SAP?
ASUG is in SAP’s pocket, and this is an idiotic justification why SAP’s software is co complicated to use and so expensive to implement. It is false because there are many things related to SAP’s complexity that has nothing to do with the organizations that buy SAP, but instead to SAP’s design. However, ASUG only makes statements that are designed to defend SAP.
“It is nice to see that SAP acknowledged that it hasn’t always been a poster child for simplicity, and that clients have struggled in navigating the many offerings and resources available in this huge company,” said Monique Hesseling, a partner with Strategy Meets Action. But it will take time and effort for SAP to overcome the perception that it’s big, complicated, and sometimes difficult to work with, she added.
SAP did not acknowledge this with their Run Simple marketing program. Rather, they stated that customers could run more “simple” with SAP than with competing solutions. This seems to be a projection on the part of Monique Hesseling.
“She does see signs of progress, though, particularly in SAP’s delivery to insurance clients, which are the focus of her firm. Maintenance and service tickets get escalated and dealt with significantly faster than in the past, she said.”
This is false. SAP’s support has been in long-term decline as we covered in the article What to Do About SAP’s Declining Support.
“SAP also responds faster and more accurately to requests for proposals, and she has found greater openness and interest in understanding the customer within the company at all levels.”
It is difficult to know what this means.
“Some of the credit for the pared-down approach goes to SAP’s new S4/Hana in-memory platform, which has simplified much of the technological foundation. By eliminating fixed database aggregates and redundancy, for example, the new system can reduce a company’s data footprint by a factor of 10, SAP says.”
This has nothing to do with the previous statement. One is a statement about being open and understanding the customer, and the transition is to a statement about a technology, which then launches into a nonsensical term called “in memory” which we covered in the article How to Understand Why In-Memory Computing is a Myth.
The Data Footprint Reduction?
The claims of data footprint reduction are also false as we cover in the article The Secret to Not Talking About The Cost of SAP HANA.
“By performing both transactional and analytic processing in the same system, the technology promises throughput that’s between three and seven times faster than the traditional SAP implementation. Analytics can be as much as 1,800 times faster.”
This is not what benchmarking on HANA indicates, as covered in the article HANA as a Mismatch for S/4HANA and ERP. SAP has no benchmarking or other data points to support the claim of analytics being 1,800 faster.
“Overall, SAP cofounder and chairman Hasso Plattner said in a keynote at the conference, the goal is to enable the “boardroom of the future,” where an entire corporation can be run from a smart watch or phone.”
We have already covered this as a “pants on fire” inaccuracy in the article Did Fiori and S/4HANA Actually Run on a SmartWatch?
“You’ve taken a 20TB database and compressed it to 10TB or 5TB — I get that,” he said. “But to us, simple is also about faster and easier configuration, getting people up to speed faster and getting changes into production super fast.”
What is SAP’s obsession with compressing databases? The answer is that HANA is priced per GB. But overall the topic of database compression is not very relevant to non-HANA databases. Oracle 12c and IBM DB2 have no size limit. Database compression does not translate to business value.
“That’s where I want to hold their proverbial feet to the fire,” Scott said. “SAP, if you can deliver on that promise, wow.”
Scott works for ASUG, which is a proxy for SAP. Scott will not be holding SAP’s feet to the fire on any claim.
“SAP needs to make software easier to buy and consume, with modernized deployment options, and it also needs to transform the services market so that software is faster to configure, without as much need for specialist consultants, agreed John Appleby, global head of SAP Hana at Bluefin Solutions.”
This has been proposed for decades, but nothing SAP has introduced, from ASAP to RDS has changed the complexity, implementation duration or cost of SAP implementations. For multiple articles on previous items that were presented to accomplish these objectives see the Brightwork research list A Study Into the Accuracy of SAP.
The Reliability of Jon Appleby?
“S/4Hana is a big step in the right direction,” Appleby said. “The user experience is modern and user-centric, the functional configuration is guided and therefore much faster, and deployment options are varied and meet the needs of modern businesses.
Appleby believes that most customers would embrace the paradigms of S/4Hana if they could, but some may have found their decision delayed by business events or other IT operational issues.”
Jon Appleby is one of the least reliable sources on SAP. He not only has repeatedly been found to provide highly inaccurate information on SAP products, How John Appleby Was So Wrong About His HANA Predictions, but he is Hasso Plattner’s “goto” guy to make massively exaggerated claims about SAP products.
The Reliability of Steve Lucas?
“Steve Lucas, global president of the SAP Platform Solutions Group, acknowledges the challenges associated with promising simplicity in a highly complex technological landscape.
“What we learned after 40 years of building apps is that the stack for building apps had become unreasonably complex,” he said.”
In 2015 Steve Lucas had worked for SAP for a short time, and he came to SAP through an acquisition. Therefore, this quotation seems a bit deceptive. But like Appleby, Steve Lucas has a long history of making inaccurate statements as we covered in the article Analysis of Steve Lucas’ Article on What Oracle Won’t Tell You About HANA.
In our analysis, Steve Lucas not only misleads listeners but does not understand many of the topics on which he speaks.
This article receives a score of 3 out of 10, for the acknowledgment that SAP’s applications are complex.
Financial Bias Disclosure
This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.
The Real Story on ERP Book
How This Book is Structured
This book combines a meta-analysis of all of the academic research on the benefits of ERP, coupled with on project experience.
ERP has had a remarkable impact on most companies that implemented it. Unplanned expenses for customization, failed implementations, integration, and applications to meet the business requirements that ERP could not–have added up to a higher Total Cost of Ownership for ERP were all unexpected, and account control, on the part of ERP vendors — is now a significant issue affecting IT performance.
Break the Bank for ERP?
Many companies that have broken the bank to implement ERP projects have seen their KPIs go down— but the question is why this is the case. Major consulting companies are some of the largest promoters of ERP systems, but given the massive profits they make on ERP implementations — can they be trusted to provide the real story on ERP? Probably not, however, written by the Managing Editor of SCM Focus, Shaun Snapp — an author with many years of experience with ERP system. A supply chain software expert and well known for providing authentic information on the topics he covers, you can trust this book to provide all the detail that no consulting firm will.
By reading this book you will:
- Examine the high failure rates of ERP implementations.
- Demystify the convincing arguments ERP vendors use to sell ERP.
- See how ERP vendors take control of client accounts with ERP.
- Understand why single-instance ERP is not typically feasible.
- Calculate the total cost of ownership and return on investment for your ERP implementation.
- Understand the alternatives to ERP.
- Chapter 1: Introduction to ERP Software
- Chapter 2: The History of ERP
- Chapter 3: Logical Fallacies and the Logics Used to Sell ERP
- Chapter 4: The Best Practice Logic for ERP
- Chapter 5: The Integration Benefits Logic for ERP
- Chapter 6: Analyzing The Logic Used to Sell ERP
- Chapter 7: The High TCO and Low ROI of ERP
- Chapter 8: ERP and the Problem with Institutional Decision Making
- Chapter 9: How ERP Creates Redundant Systems
- Chapter 10: How ERP Distracts Companies from Implementing Better Functionality
- Chapter 11: Alternatives to ERP or Adjusting the Current ERP System
- Chapter 12: Conclusion