- The Run Simple marketing program by SAP has been quite popular.
- In this article, we review the accuracy of the Run Simple campaign.
For several years now SAP has been using the term simple in its marketing and sales. There is Simple Finance, Simple Logistics, the term “Running Simple,” or “Run Simple,” that is used in many SAP presentations. So what does all this simple stuff mean? In this article, I will cover what is behind it and how the concept should be interpreted by buyers and those that study SAP.
I will begin by analyzing some the statements I was able to find about simplicity from SAP and determine the accuracy of these statements to come to a general conclusion about running simple.
The Effort Put Behind SAP Run Simple
At SAP conferences, SAP and partners drove the concept of SAP Run Simple into the ground. Each partner seemed to have simply worked into their catchphrase “Run Simple with E&Y.” “Let IBM Show You How to Run Simple.”
For a while, there everything was “SAP Run Simple” and a lot of people who had never worked with the software, or had but had forgotten how it worked, were running around saying how simple everything was going to be. SAP Run Simple was the catchphrase that was on SAP marketing literature and SAP Run Simple was woven into many different areas of SAP messaging. Of course, the SAP partners picked up SAP Run Simple with an uncountable number of consulting companies using different takes on SAP Run Simple in order to co-promote with SAP. With SAP Run Simple everything was supposed to now be simple in SAP.
In his book SAP Nation, Vinnie Mirchandani does a very thorough job of covering the history of SAP’s use of the term simple or proposing they will simplify going back to the 1990’s.
The High-Level Concept of SAP Run Simple
At the high level, SAP has been fighting the perception that it ‘s hard to use and that it is expensive. Problems are fighting those perceptions, as they are both true.
- Is SAP is Difficult to Use?: If you want to produce a forecast, approve a PO, check on inventory, it will be more difficult than in other applications. SAP is known as the most complex of the enterprise software applications. I say this complexity is a perception — however, as a long time SAP consultant, I can say that it is true. One example of this is how long it takes to get things done in the user interface or the SAPGUI. Another is example is how SAP makes integration more difficult than other vendors by preventing the direct interrogation of its database. They are still the only vendor I know of that uses an intermediate document, a relic from the hierarchical data formats of the mainframe era for application integration. Now one might say the complexity is worth it. Whether something is worth its inherent complexity is really a separate discussion from whether something is complex. Interestingly, much of the marketing by SAP that promotes S/4 HANA is how much it simplifies what were complicated things in SAP. The problem though is that it relies upon simplistic platitudes regarding a simplified data model and on the use of Fiori. However, Fiori is not a user interface, it is a series of apps with a very hazy future. I cover this in the article What is in the Fiori Box? Also, is SAP agreeing that their software is very sophisticated right now?
- Implementation Costs: SAP has the highest cost implementations in nearly any software category that you want to compare. I know this from working on many SAP projects and comparing them to non-SAP projects. Full TCO calculators on SAP and non-SAP applications show this research and allow people to calculate the TCO for their projects. It is precisely why so many consulting companies recommend SAP. No consulting company suggests lower cost SaaS solutions which they can’t make the most money on.
I am bringing up this information above as simply background as to why SAP is motivated to present their systems as easier to use.
Clearly, the “simple” campaign is part of changing the perception.
Understanding the Marketing of SAP Run Simple
Let us take a look of some of the marketing statements on Running Simple. Here is one that caught my eye.
If we simplify everything, we can do anything. SAP helps you streamline your processes, so you have the agility to create new growth opportunities for your business with the world’s most innovative platform.
There are a lot of statements like this on the SAP website. The first part of the paragraph is a platitude or a nursery rhyme. Much like the phrase “if you don’t stand for anything you will far for everything,” or “if the glove does not fit you must acquit.” It is a sentence designed to appeal to our reptilian brains. The last part of the paragraph is completely untrue.
SAP is not the world’s most innovative platform. Also, SAP is not a platform. Every single area of functionality that SAP internally developed it has copied from someplace else (I speak only of the applications SAP developed. I don’t know the acquired applications well enough to make that claim — but those are not SAP applications). That is not necessarily a bad thing, as long as it is credited, but saying you are the most innovative platform does not acknowledge where you obtained these ideas. Like Microsoft, SAP can say that it is big. It can say that it is successful. It can claim enormous monopoly power, that it has the most highly compensated consultants in IT.
However, it cannot claim innovation.
I can list of vendor after vendor that has participated in true innovation. I don’t want to just list them here, but I point out innovative functionality in software vendors at SCM Focus. Let us show some respect for the true innovators. This actually reminds me of a tension-filled interaction between Tywin Lannister and Joeffry on Game of Thrones. At one point Jeoffry, in an effort to establish his authority states “I am King!” Tywin Lanister responds “Any King who has to say “I am King!” is no true king.”
It is amusing. See the clip below:
Wouldn’t Tywin say the same thing to SAP for saying they are the most innovative platform in enterprise software? I think he would.
In an article on the topic of making things simple by Frank Scavo, he presented the following areas where SAP was proposing it was more simple with its newer products.
- A Simpler Code Base
- A Simpler User Interface
- Simpler to Implement
- Cloud Deployment Simplifying Ongoing Support
- Making SAP Simple to Deal With
Let’s go through each of the quotations individually, and then analyze whether the information provided by SAP in each area is true or likely to be true.
A Simpler Code Base
Under HANA the applications can now simply record transactions and not have to create any summarized data fields for later reporting. With HANA, reporting always goes back to the source data in memory to build aggregated data fields on the fly. This shrinks the size of the programs, greatly reducing the number of lines of code, making them less error-prone and easier to debug. It also means that users can now drill down from summary data to details in any way they choose, without having to write special reports or customize the code.
True of False?: Some aspects of column based databases are more simple than row-based databases (what HANA proposes to replace). However, nothing definitive can be said either way. I cover this in Does S/4 HANA Have a Simplified Data Model? SAP has been like a dog with a bone on this one, and they are completely mistaken on this topic.
These are a second point that the code in the application layer has been cut down and simplified. This has repeatedly been referred to by SAP. However, this comment by an architect in the book SAP Nation 2.0 makes me question this proposal.
“What SAP has done with S/4 is simplify the underlying structure through database views in HANA. So it’s another layer on top of the database that compounds very granular underlying database tables into logical business constructs; something that has always been done by the application logic in SAP (the data in SAP is dumb — all the intelligence is in the logic) And since that SAP logic is all process driven in the “order to cash” or “procure to pay” themes, making business sense of that data can be a real bitch. What it is NOT is a material reduction in tables or a simplification of the data structure. Buy definition, it can’t be because those hundreds of million lines of ABAP code all point to those original tables in some way; so until the code is rewritten, the tables still need to exist. And that includes all the customer customizations…”
Additionally, I find this quotation very confusing, because my understanding was that all the ECC tables had been converted into columnar tables and all the code in S/4 in the application layer had been rewritten to address those column based tables.
This quotation calls this into question.
“It’s another layer on top of the layers that already exist. It is additive. And the more layers, the more issues with context and integrity — and the more challenges in maintaining relationships when the underlying tables change. Also, though the views are great for getting things out, but they really can’t put things back. So it’s really analytics only. To put it back in SAP, you have to follow the old rules and it has to go to the original tables.”
If this architect is correct, then I was misled by several people from SAP that pitched S/4 HANA to a broader group over a year ago and me. Of course, they were just repeating a message they were told to repeat and probably did not know themselves.
Secondly, HANA will take longer to implement, and there is less in the way of skills to manage any HANA complexity compared to competing databases. This is because there are fewer HANA skills in the market than for the competing databases that could be used. This is similar to buying an uncommonly purchased car — it will mean less available mechanics to work on it.
So more likely that not, HANA is a more complex implementation than implementing without HANA. There may be some maintenance benefits from HANA versus more traditional databases, as there are fewer indexes, (which I cover in several articles here) but again HANA has other complexities that come along with it. Here are why SAP’s comments on HANA are so unreliable:
- SAP misstates both the origin and advantages of column-based databases. None of the technological underpinnings to HANA are exclusive to SAP, and in fact, none of them were invented by SAP.
- SAP routinely lists the advantages of HANA without listing the disadvantages.
That means any statement by SAP on HANA must be put through a reality blender, to get a balanced final output.
The Verdict? Most Likely Untrue.
A Simpler User Interface:
SAP Fiori provides the user interface for Simple Finance. Fiori apps operate across desktop and mobile devices to provide a simplified user interface for SAP’s applications. They are not just a new presentation layer but in many cases combine SAP transactions into a single user process. For example, entering a manual payment in Accounts Payable can now be done in a single screen instead of the multiple screens it previously required in SAP. On a side note, after much push-back from customers, SAP announced that Fiori apps will now be delivered at no charge to customers under maintenance, removing one barrier to adoption of Simple Finance.
True or False?: Fiori cannot be the user interface for Simple Finance, or what is now just “Finance.” It can’t be the user interface for all of S/4 HANA when it is eventually released in what now looks like next year. I explain why this is the case in the article What is in the Fiori Box?
The user interface for S/4 HANA will be the same (outside of some Fiori apps here and there) will be SAPGUI. Companies that want to get a modern interface need to seek out third parties that are far better at modifying and representing the SAPGUI than SAP is.
The Verdict? Untrue.
Simpler to implement?:
Implementation tools and methodologies are built right into the application, based on SAP’s previous work with its Rapid Deployment Services. These include wizard-like tools to guide and configure the applications. There are data migration tools to map data from existing systems into Simple Finance—whether from previous versions of SAP or from other systems. Implementation testing is also managed within the system itself. In addition, Simple Finance is integrated with SAP’s collaboration system, Jam, to encourage knowledge exchange. If a user runs into problems, for example, he or she can reach out to other users for help.
True or False?: The Rapid Deployment Services of RDSs are a hodgepodge of mostly already existing material that has been repackaged. For instance, it includes:
- Best Practices documentation, which isn’t best practices. That is another topic which I cover in this article Evidence for SAP’s Best Practice Claims.
- Configuration documentation
- Some confusing flow charts
- Various documents of different types depending upon the RDS in question.
- Some demo data, again very much depending upon the RDS in question.
A lot of this has been around for quite some time, and is just repackaged into “RDSs.”
I can’t speak to the proposed data migration tools mentioned in the quote. It ‘s hard to see how implementation testing could be performed in the application.
Jam is an unknown quantity at this point, and it is not enough to hang your hat on. Overall, one would have to see new SAP applications installed more quickly than older applications before anything definitive can be said.
In November 30 2015, Hasso Plattner published How to Understand the Business Benefits of SAP S/4 HANA Better.
This article shows some clear frustration on the part of Hasso with the well documented fact that SAP’s customers are having a problem seeing the value in S/4 HANA.
Lets understand each of Hasso’s observations and see how they stack up. You can first read Hasso’s article, which I have provided the link above and then read this one as I have taken out what I think are the most important quotes. I have each of the quotes and my comments organized under the exact headings that are from Hasso’s article.
Hasso on The Reduction in Complexity from S/4 HANA
“For years our customers complained about the complexity of the business suite and asked for simplification. Now some fear they have to relearn a lot and that will cost time and money. The simplification of the UI is real and will save time with the first day of productive use. The business functionality of the transactions is still the same but comes in a much more efficient form.
The dramatic simplification of the data model, the fact that any field can be used as an index for selecting data and the unprecedented short response times are allowing for much faster development cycles of new applications. The deployment of extensions in SAP HANA Cloud Platform is an elegant way to enhance SAP S/4HANA systems or to build completely new applications. SAP S/4HANA combines the proven set of core business functionality, in many languages and for nearly all countries, with the ability to venture into completely new dimensions of applications. This capability is key when business processes are developing at an ever increasing speed and core enterprise systems cannot just be complemented by point solutions but have to also accommodate these changes. This reduction in complexity also lowers the threshold for smaller companies to switch to SAP S/4HANA.”
Lets look into the detail in each area brought up by Hasso.
- For Years Our Customers Complained About the Complexity of the Business Suite (ECC): Yes, this is true. However, most of the complaints did not have to do with what HANA is improving. Many of the companies did have to do with the SAPGUI. However, again SAP buyers cannot expect Fiori to cover many of the ECC screens for some time. So Fiori will be used along the same old SAPGUI. Therefore, complaints will continue.
- The Dramatic Simplification of the Data Model: I cover in Getting Clear on S/4 HANA, that it is debatable whether HANA actually simplifies the data model.
- ..The Ability to Venture into Completely New Dimensions of Applications: It is hard to see how this is true. S/4 has a (partially) new UI. And Fiori can be customized much more easily than SAPGUI, however, it is still a lot of work, and there is not really a consensus on Fiori yet in terms of whether it will actually stick longterm. The later part of this paragraph is sort of fanciful sales talk and its difficult to really address what Hasso is describing.
The Verdict? Some Things are Untrue; Others are Unknown.
Cloud Deployment Simplifying Ongoing Support
SAP also wants run simple in how customers keep their applications up-to-date. Like most traditional on-premises vendors, the majority of SAP customers are not on the latest releases of its products. The reason is that applying new versions (in SAP lingo, “enhancement packs”) is often a labor-intensive activity—testing the new code, retrofitting any customizations, regression testing to be sure nothing gets broken, and migrating data. SAP’s solution is to take over these responsibilities by hosting customers’ systems in SAP’s HANA Enterprise Cloud (HEC). This program, already rolled out to some early SAP customers, is essentially a managed services offering in which SAP takes all responsibility for day to day operation of the system in SAP’s own data centers. Notably, SAP also takes responsibility for keeping the customer’s system up to date with the latest enhancement packs and bug fixes. It even supports systems with custom modifications.
True or False?: This one is pretty easy. This quote is several years old, and this has not happened. Some of this may be related to price, and some to simply SAP trying to be good at something that it does not have experience in. However, there is no momentum for this year after the HEC was introduced. Everything at the beginning of this quotation above is still the case today.
The Verdict? Untrue.
Making SAP Simple to Deal With
Bill McDermott is always good for some major whoppers. I question how good McDermott is a spokesman at this point for SAP because he has built up a history of saying things that turn out not to be true. It is probably a good time for him to take is stock options and for SAP to bring in a new fresh face to pitch this crazy stuff.
He (McDermott) continued: “For customers, we’re committed to a beautiful user experience. We will make it simple to do business with SAP: simple pricing, pay-as-you-go in the cloud, simple web experience.”
Those are big promises. Anyone who has negotiated an acquisition of SAP software knows that SAP contracts are incredibly complex. Pricing is opaque, with many various types of named users defined for each product. SAP’s terms and conditions around indirect access (when other systems access information from an SAP system) are onerous.
The result is that it is nearly impossible for an SAP customer to be fully compliant. When SAP does an audit of a customer’s use of SAP products—which it has the right to do—it will find problem, if it looks hard enough.
Even finding the right person in SAP’s organization to deal with is not a simple matter. Whether it is the result of having a worldwide organization or peculiarities of German corporate governance, it is difficult to understand who reports to whom, or who is responsible for what.
True?: I don’t think I need to add anything to what Frank Scavo said.
The Verdict? Untrue.
SAP Run Simple
SAP has huge media influence. The advantages of being big are real. SAP can simply reach out to most media outlets and find them compliant to most messages that SAP has to give them. SAP is a major advertiser so that combined with being big goes a long way to getting their message out.
If a media outlet presents this information without commentary, which they often do, and if SAP does this through a lot of media outlets, then it can seem that the media outlet is endorsing SAP’s marketing machine, when that may not be their real intent. However, if SAP quotations are provided without objective commentary from the article author, then it is very easy to create an echo chamber. That is a lot of pollyannish statements are made by SAP that becomes taken for granted.
Was SAP Run Simple Ever and Accurate Concept?
I have worked in SAP since 1997, and I don’t recall anything in SAP to be simple. SAP may be the standard. It may be robust. But it is not simple. I have noticed a strong correlation between people who propose SAP’s new simplicity and how far away they are from SAP applications, and i.e. how little they know. And of course, it’s much easier to believe something complex is simple — if you don’t have to do the work yourself to configure or setup said system.
Secondly, there was always a problem with using the term “simple” as part of a production name that SAP marketing never picked up on. The word “simple” is a superlative adjective, and adjectives don’t make a lot of sense as part of application names. And after a while, it makes more sense to just drop the adjective as it just becomes redundant. This would be like calling a system “handsome” or “fantastic.” Let us apply this to another application, say the SAS Forecast Server, would become the:
“SAS Outstanding Forecast Server”
See…it just does not work.
Secondly, S/4HANA is not simple. Parts of S/4 HANA can use the Fiori user interface, but quite a bit about S/4HANA is actually more complex. This includes all the changes that are a part of S/4HANA that need time to be understood and incorporated properly into companies.
What Happened to Run Simple?
Then just as quickly as SAP Run Simple had arrived on the scene, the term was removed from the SAP marketing literature. Simple Finance was rename to just Finance. Simple Logistics was renamed to a number of different items, but the word simple was no longer used. SAP Run Simple had run its course as a term to use.
SAP Run Simple, which is supposed to apply to S/4HANA really makes no sense, particularly when SAP Run Simple is supposed to apply to just about everything from S/4 to Fiori to HANA, when all of these items are new and will require years of burn in to reach the stability of the products they are replacing.
It is no easy feat keeping up with SAP’s S/4HANA terminology. SAP went through a period where they invested mightily in what was essentially a false marketing construct — that the new applications were somehow simple.
Basically, for all of SAP’s emphasis on their Simple program, it ‘s hard to find any substance to any of it. That is there is no evidence that new SAP applications will be any simpler, in actually any dimension than previous applications.
- SAP has made some proposals, but they are easily disproven and are designed to exploit those with little understanding of SAP.
- Other proposals are unknown and depend upon seeing the results in the field. However, they are presented as if they are already proven. This is a consistent theme in SAP’s writing. Unproven conjecture and bragging are presented as if it is an academically researched and settled topic.
As far as I can tell, “Run Simple” is directed at simpletons.
Search Our Other S/4HANA Content
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.
I cover how to interpret risk for IT projects in the following book.
The Risk Estimation 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