- Fiori has seen a bizarre growth in the number of Fiori apps, which in part relates to the “Fiorized” apps.
- The number of Fiori apps related to just S/4HANA.
- We provide the real story on Fiori apps and an estimate of how much Fiori apps are currently being used.
There have been some strange occurrences with the Fiori apps. You will learn about the background of how SAP is exaggerating the scope of Fiori.
Background on Fiori
Fiori has had a lot of marketing hype but has had minimal uptake as the article, How to Understand Why Fiori Won’t be Able to Survive. SAP needed to make it seem as if Fiori is growing faster than it is.
The Unusual “Growth” in Fiori Apps
SAP has been quite deceptive on Fiori and has been exaggerating the number of Fiori apps for some time. Interestingly, SAP for quite some time had fewer than 1000 Fiori apps. Then around eight months ago, the number of Fiori apps significantly increased. Doing some investigation explains why.
Here at the Fiori Library. It shows 8565 apps in total.
Now we will filter the Fiori apps by which are SAP GUI apps. Notice the different Application Type options.
Here we filter by those Fiori apps that are SAP GUI.
This shows that there are 6660 out of 8565 Fiori apps that are SAPGUI and not based upon Fiori. That is more than 77% of the apps that are SAPGUI. That leaves 23% of the total apps being non-SAPGUI in their origin.
SAP’s Statement on the “Fiorized” SAPGUI Apps
SAP states the following about these SAPGUI Fiori apps.
“S/4HANA comes with a large set of new SAPUI5 applications. But there is still significant functionality that requires the use of classical SAP GUI and Web Dynpro ABAP applications.”
Right. But the original plan was all these apps were going to be developed as Fiori apps. What happened to that plan?
It appears that SAP needed to exaggerate the number of apps that count as “Fiori” and that it simply rebranded SAPGUI apps a Fiori. Then they placed them on the Fiori App Library to mislead customers as to the true number of Fiori apps.
When Fiori was introduced, it was presented as wholly apart from SAPGUI. It was to be so much better than SAPGUI and so much better than any other UI that it would be something the world had never seen. Notice the quote from Jim Hagemann.
“We’ve come a long way from the old SAP GUI,” he said. “The challenge is clear. We are no longer benchmarking against some other business software, because most of them are not very beautiful. We are benchmarking against consumer software. We’re committed to providing the most exciting user experience in the industry.” – SAP co-CEO Jim Hagemann
But did that happen? Well for 77% of the Fiori apps on the Fiori Library they are SAPGUI!
Jim, you can’t come a long way from old SAPGUI if you, in fact, are offering SAPGUI.
Fiori’s Technical Underpinnings
Now let us go back to more quotations about Fiori’s technical underpinning.
“In the past SAP GUI and Web Dynpro ABAP have already undergone several iterations of design improvements.
But still, the look and feel of SAP GUI and Web Dynpro ABAP applications was very different to SAPUI5 based Fiori applications. Therefore things users have learned from using the new SAPUI5 based applications, such as the placement of buttons or usage of icons, couldn’t be applied to the classical applications.
Our goal for the “Belize” implementation was to minimize the disruption between the different UI technologies by bringing SAP GUI and Web Dynpro closer to Fiori. We applied as much as possible of the Fiori visual design, e.g. colors, sizes, button placement, icons,… , to the two classical technologies.””
Well, this does not make SAPGUI and Web Dynpro Fiori. Let us now review how many of the apps listed and counted under the Fiori library are Web Dynpro.
So that puts us as 417 apps for Web Dynpro.
417 + 6,666 (SAPGUI apps) comes to 7,077 non-Fiori “Fiori” apps.
That means that 82% of the apps that are listed as Fiori are not Fiori apps.
The Real Story on the SAPGUI “Fiori Apps”
So this is to Fiorize SAPGUI screens. This is how SAP was able to add so many “Fiori” apps to the apps library. By pretending that SAPGUI apps that have been repurposed are Fiori.
This is covered in the article Fiori Lie Detector when the author says the following:
“Please SAP, call GUI transactions with a blue background which are opened inside a new browser tab within an iFrame anyhow you want … but not Fiori.
Fiori principles were totally forgotten on such move and even if someone might like the result and want it, you are denying yourself.” Can Fiorized SAPGUI Apps be Used with AnyDB?
All of this brings up another interesting question.
The original logic of limiting Fiori to HANA was that they were new. At some point, SAP attempted to promote the idea that you needed the performance of HANA to leverage Fiori. But that never made any sense.
However, now that is clear that 82% of the Fiori apps aren’t Fiori at all, is are only SAPGUI with some additional colouration or Web Dynpro.
Are SAPGUI “Fiori” Apps Available for AnyDB?
SAP makes the issue more confusing by stating that these SAPGUI apps are not available for AnyDB.
When we ran a filter on the SAP Fiori Library for SAPGUI apps that also could run on AnyDB, we came up with the following results.
We then performed a different filter. Looking just for Business Suite or ECC apps.
So 701 apps.
However, ECC can be run AnyDB combined with Oracle.
So what happens when we filter for the AnyDB apps of this group?
Back to the 209 apps from the earlier search.
Why doesn’t SAP show all of the SAPGUI apps working for AnyDB? I would be interested in hearing comments as to why SAP does not include SAPGUI “Fiori” apps as not working with AnyDB. Does going through the process of “Fiori-washing” remove their previous ability to work with AnyDB?
How to Get the Real Story on S/4 HANA
For the foreseeable future, the only way to know what parts of the rest of the S/4 suite work, is to test them or learn second hand from someone else (who you trust) who has tested it. You can’t ask SAP or ask their consulting partners. In most cases, the answer is that S/4 is ready to be implemented as soon as you can get around to signing a statement of work with them! Beyond this, S/4 is being made to appear far more implemented than it is.
One of the exaggerations that SAP proposes is that S/4 has 3700 customers.
I don’t doubt that 3700 companies somehow ended up with a S/4 license (most of them for free). This is the only definition of a customer — do you own (somehow) a S/4 license. But the actual number of S/4 implementations is probably less than 100, with most of these not live. And none of them live in the whole suite — for reasons that should be obvious at this point in the article. SAP recently reported that they have 170 customers live. SAP has stated that 30% of their clients are referenceable.
- 30% of 170 is 51 companies, well below my estimate of even less than 100 companies.
- And live can also mean different things. If S/4 HANA is live, it is live only with Finance, so that means it has to be integrated to ECC to function.
The Ridiculous Concept of the S/4HANA Customer Number
The idea that SAP likes to give that 3700 S/4 customers are in some state of using this software is so ridiculous that the industry needs to come up with a more strict measurement of what a customer is. A customer should not be someone who is only sitting on shelfware. If you are a plumber and you give a gift certification for a particular plumbing service, and 80% of the people that have this certificate never use your services, this 80 % are not “customers” of that plumbing service. SAP has given away so many copies of S/4 that they will not release the actual revenues for the application. I suspect they have not only given away copies to existing users (who should get it for free) but for net new deals as well.
By the way, I am not the first to question the 3700 customer number for S/4. Most people who study this topic think this number is highly overstated.
Previous Proposals on SAP Application Readiness
Exaggerating the readiness of applications is nothing new for SAP. So please, if some people are going to comment to the contrary, let’s not pretend to be so shocked. SAP APO was released back in the early 2000s was a barely functional product that only made it through those early days because it was pushed by the major consulting companies.
Another “application” that comes to mind as one that was significantly pre-announced was Netweaver. I take the following quotation from Vinnie Mirchandani’s book SAP Nation 2.0:
“With so many unanswered questions, an emerging viewpoint is that S/4, as initially defined, is just a placeholder. If anything, it will probably evolve in the same manner as another of SAP’s initiatives, NetWeaver, did a decade ago. In their 2004 book on NetWeaver, Dan Woods and Jeff Word said with confidence:
“All this talk about successive versions and incremental progress and fulfilling visions could easily give you the wrong impression that SAP NetWeaver is still on the drawing board. That’s not at all true. SAP NetWeaver is here now. All the SAP NetWeaver components that we have mentioned are working products and can be purchased and used to make your business run better today.”
That turned out to be completely untrue. In fact, NetWeaver was never actually released as it never actually existed. NetWeaver was a name appended to other applications. I pointed this out repeatedly and wrote on this, and now all the people who were so high on NetWeaver never emailed me to apologize. On project after project, NetWeaver is nowhere to be found. Where is the World is Carmen San Diego? Where in the World is NetWeaver is a much better game to play.
Quickly Disappearing When Being Held Accountable
I seem to debate a lot of people who have incredible confidence in their positions, but then appear to disappear when it turns out they were wrong. One excuse they will use is that they could not have known differently because they were told something was true by SAP. Anything to avoid the responsibility of being held accountable for previous statements. By the way, all these items which were so easy to see at the time, just happen to be in line with their financial interests. I can guarantee that those people that may respond to this post and talk about how S/4 is the “next stage,” and how it has an entirely simplified data model, will all have a financial bias for why they want S/4 to be accepted. However, they won’t discuss this financial bias. They will instead carry forward the conversation as if they are some impartial observer. However, I am in fact impartial, financially at least.
Debating the Financially Biased
I do not financially benefit if customers buy S/4 or do not buy S/4. That is an important consideration. Also, unlike anyone who works for Bluefin, IBM, etc… as an independent, I can write what I believe to be true. I covered the topic of forecast bias in the book Supply Chain Forecasting Software and included it again in this LinkedIn post. And it is amazing to me, knowing what is known about forecast bias that we don’t seem to discuss bias when considering what people and companies propose.
Now, NetWeaver was something at the beginning related to rewriting parts of SAP in J2EE but later devolved into a marketing construct. S/4, unlike Netweaver, is something. It will not only turn into a marketing construct, but its development has been and will look like it will be fraught with greater confusion and problems than most other SAP applications. But whatever one’s opinions of S/4, and it should be acceptable to be unimpressed with S/4, without being admonished about how S/4 has a new data model that “simplifies everything.”
At least we should be able to agree whether S/4 as a suite, that is what is known as S/4 Enterprise Management is released. And it isn’t yet released. What is currently being re-written was written by thousands of people over decades, so no surprise it is taking longer than projected by SAP.
The Math for the Estimate
To estimate the amount of Fiori apps usage and how drastically it differs from the statements made by SAP, we have to isolate where Fiori apps are used.
- Fiori apps have been designed to be used mostly with the S4 ERP system.
- S4 only works with HANA, and Fiori only works with HANA for roughly 87% of its apps.
Therefore determining likely Fiori usage means estimating S4 usage.
According to SAP, they have 50,000 ERP customers across 25 industries. I have been on projects where it is claimed that SAP has upwards of 250,000 customers. However, this would mean any company that was in possession of a SAP license for any application. It would not necessarily include active customers. SAP may count customers that used their software ten years ago and moved off of their software.
So for this estimate, I have gone with the 50,000 ERP customers to compare against the total number of S4 customers.
Estimating the Number of Customers
I have spent time estimating the number of customers using S4 with inputs from multiple sources and come to around 150. This is 150 global customers either in the current state of implementing S4 or having already implemented it (almost all only having implemented S4 Finance). The largest concentration of these implementations is in Germany, and they were not undertaken because of S4’s value (as it is a currently being developed application – set of applications) but because of the control that SAP has over these companies.
That would mean that of the 50,000 customers, 150/50,000 or .003 of SAP ERP customers use S4. But this is not 150 live customers with S4.
However, this is not sufficient for estimating how small the usage of Fiori is.
Fiori Not a Replacement for SAPGUI
Unlike what has been proposed by Hasso Plattner, Fiori is not a replacement for SAPGUI. Fiori is only a series of a little over 1000 apps that are concentrated in small data intensive transaction. No company can use S4 without spending most of its time in SAPGUI. Companies would use S4 some percentage of the 1000 apps, but these apps replicate screens in the SAPGUI, and there would be a transitionary time and training required to use these Fiori apps.
- Therefore of the 150 implementations of S4, some small subset of the overall transactions accessed by SAP customers that use S4 use some Fiori apps.
- Of these 150 implementations, only some portion of which are live may be using some of the Fiori apps.
SAP is deceiving customers by re-badging SAPGUI as Fiori.
When SAPGUI “apps” are removed, the actual number of Fiori apps is 1488. And even this number is greatly exaggerated because of how SAP counts what an “app is.” In SAP’s world, a Fiori app is 82% of the time not really “Fiori,” and it is 100% of the time not an actual “app” but just a segment of a workflow.
Understanding these limitations of the possible usage of Fiori apps indicates that Fiori’s overall usage must be incredibly small. This likely fact, combined with the fact that Fiori apps have been around for several years now, argues very poorly for Fiori’s likely survival.
Curious about the reality of S/4HANA implementations? See our The S/4HANA Implementation Study, for real story and details on actual S/4HANA implementations.
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.
S/4HANA Implementation Research
We offer the most accurate and detailed research into S/4HANA and its implementation history. It is information not available anywhere else and is critical correctly interpreting S/4HANA, as well as moderating against massive amounts of inaccurate information pushed by SAP and their financially biased consulting ecosystem.
Select the description that best matches you.
Option #1: Do You Work in Sales for a Vendor?
See this link for an explanation to sales teams.
Option #2: Do You Work for an Investment Entity that Covers SAP?
See this link for an explanation for investment entities.
Option #3: Are You a Buyer Evaluating S/4HANA?
For companies evaluating S/4HANA for purchase. See this link for an explanation to software buyers.
Search Our Other S/4HANA Content
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