The Strange Changes with the Count of Fiori Apps
Executive Summary
- Fiori has seen an unusual growth in the number of Fiori apps, which relates to the “Fiorized” apps.
- We provide the real story on Fiori apps and estimate how many Fiori apps are currently being used.
Video Introduction: The Strange Changes with the Count of Fiori Apps
Text Introduction (Skip if You Watched the Video)
There have been some strange occurrences with the number of Fiori apps. This is because SAP has been gerrymandering the numbers of Fiori apps. This makes it difficult to determine how many Fiori apps there actually are. This connects to the overstatement by SAP of S/4HANA implementations as Fiori is so strongly tied to S/4HANA. No IT media entity, nearly all paid by SAP nor any SAP consulting company will cover this topic due to financial bias. You will learn about the background of how SAP is exaggerating the scope of Fiori.
Our References for This Article
If you want to see our references for this article and other related Brightwork articles, see this link.
Notice of Lack of Financial Bias: We have no financial ties to SAP or any other entity mentioned in this article.
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 merely 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 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 could add so many “Fiori” apps to the app’s 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 HANA’s performance to leverage Fiori. But that never made any sense.
However, now that it is clear that 82% of the Fiori apps aren’t Fiori at all, it is are only SAPGUI with some additional coloration 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 about 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 are 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 an S/4 license (most of them for free). This is the only definition of a customer — do you own (somehow) an 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 it has to be integrated into 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 give a gift certificate for a particular plumbing service, and 80% of the people who 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 the major consulting companies pushed it.
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. 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 many 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, happen to be in line with their financial interests. I can guarantee that those who 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 incredible to me, knowing what is known about forecast bias, that we don’t seem to discuss preference 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, which is what is known as S/4 Enterprise Management, is released. And it isn’t yet released. What is currently being rewritten 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 owned an 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.
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 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. They were not undertaken because of S4’s value (as it is currently developed application – set of applications) but because of SAP’s control 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 little over 1000 apps that are concentrated in small data intensive transactions. 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 live may be using some of the Fiori apps.
Conclusion
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 Fiori apps’ possible usage indicates that Fiori’s overall usage must be minimal. This likely fact, combined with the fact that Fiori apps have been around for several years now, argues very poorly for Fiori’s possible 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.