- SAP has made enormous claims for Fiori being a game changer for SAP applications.
- The evidence is not only that Fiori is not impressive technically, but that it is little used and not progressing as stated.
In the previous articles on Fiori, I brought up some of the issues that have prevented Fiori from being used by SAP customers. And how Fiori was leveraged as a cynical marketing ploy to keep companies from exploring real options in the market for user interfaces.
These limiting factors on Fiori include the following:
- Tying Fiori Unnecessarily to HANA. SAP first attempted to charge for Fiori. When unsuccessful decide to use its investment into Fiori to tempt customers to buy Fiori. There has never been any reason to restrict Fiori to HANA. One reason I heard was that because Fiori as so report oriented that it would have to have HANA. This is untrue, in fact, most Fiori screens are quite low in data density. Nevertheless, SAP thought it was quite clever by restricting Fiori to HANA. The major problem being that there are so few S4 instances live in the world. Thus it has been an important part of limiting Fiori’s use to a tiny segment of the market.
- SAP and its Partner Network misrepresented Fiori as a Complete Replacement for the SAPGUI. In actual reality, it is a series of apps. The development of Fiori apps seems to be slowing. As I check the Fiori app library, the library is now up to 1015 apps. At one point they were adding 15 apps per month.
- SAP and its Partner Network Misrepresented Fiori as a User Interface That Works Equally Well on Computers, Tables, and Phones: Yet, Fiori’s heritage is actually as a mobile app. It is not designed to show the data density of a computer screen for complex transactions. It is a “lightweight” user interface. Fiori can be displayed on a computer, but this is not the same as saying that Fiori is a user interface designed for computers.
- SAP and its Partner Network Misrepresented of the Effort Involved with Fiori: Even for companies that purchased S4 because they were tricked by SAP’s marketing. Or because they were somehow connected to Hasso Plattner. (Hasso Plattner remotely controls purchases of many companies in Germany and other businesses that has some type of interest, this is why most S4 implementations have been in Germany.) It’s difficult to justify going to effort even to bring up Fiori. Fiori requires a parallel technology and training pathway. It requires a lot of resources. All to migrate some transactions to a use interface that has little chance of survival. Honestly, at this point why would, a company invest the effort to do this knowing that Fiori is not the future of SAP’s user interface?
SAP not only misrepresents Fiori and its applicability but uses it to “UI wash” its SAPGUI. This is pointed out by Max Favillon at his blog.
“Browse SAP websites and try to figure out what its user interface looks like, you will have a hard time, no screenshot whatsoever, a lot of beautiful picture of smiling business people using laptops, smartphones, and tablets, but not even a glimpse of what SAP applications UI looks like. ”
In SAP marketing’s eyes, the UI that SAP customers use is not the real user interface or SAPGUI, but some combination of Fiori, along with the stock photography pictures of people smiling at laptops. Why use an alternative like AppsFreedom or LiquidUI or when clearly everyone is laughing looking at their laptops?
I also brought up in the article on SAP uses indirect access to block companies from purchasing alternative user interfaces. This is where SAP requires customers to buy copies of Fiori that they will not use to connect another user interface to SAP applications.
Fiori has the following problems that have prevented its uptake.
- Who Recommended Fiori?
- Why Did They Recommend It? (hint — it’s related to money)
- Why is SAP now so Silent on Fiori?
- Why did certain people look at Fiori and think it was going to work?
There are a huge number of people offering advice in SAP that is not looking critically at what SAP is offering. They should not be listened to. If you have an advisor like a Deloitte or IBM that only parrot what SAP’s marketing literature says, these entities should not be relied upon. One should remember the limitations placed on partners.
- SAP monitors all messages that are presented at SAP conferences or that is produced by the partner marketing department.
- SAP can edit or block any material that a partner produces on SAP. Not that SAP partners tend to care about disseminating false information.*
- *(I do not mean to give the impression that SAP partners struggle against SAP’s influence. If anyone working for a large consulting company is for a split second thought that I proposed that they may at times attempt to communicate information, not in line with SAP marketing and that they have even the sliver of independence, I apologized for my clumsily worded sentence.)
This reminds me of a debate I had with a Deloitte consultant years ago about SOA or service-oriented architecture. I made the point that SAP would never support SOA in actual practice. While SAP may put SOA on their PowerPoint sales presentations. This was because SOA was about open systems. SAP had at that point used the difficulty of integration as a strategy for blocking out vendors that have better functionality that they have. They have done this for decades. So why would SAP embrace SOA? SOA would give customers greater freedom and restrict SAPs ability to use its monopoly power.
At this time (around 2006) SAP was promoting SOA in its marketing literature.
The Deloitte consultant I was speaking with became visibly frustrated with me. At one point had enough and said
“What I am saying is that SAP is saying that they will support SOA!”
I seemed to make him angry for whatever reason.
For this and many other consultants, there is no interpretation of what SAP says. SAP makes a statement, and an army of consultants line up to repeat this statement. As SAP marketing lives in a permanent fantasyland. This means that these consultants spend a lot of their time repeating false statements.
And by the way, guess that happened with SAP and SOA?
- SAP never did anything to support it.
- SOA finally flamed out as a concept as it was always a bit of a pipe dream.
- SAP moved on to promoting something else.
- No one, not SAP nor SAP’s partner network ever admitted they were wrong about SOA.
- SAP did not issue an apology for talking up something they never supported.
That is how the trends and information dissemination works in IT. And so it will be with Fiori.
Fiori “Part Two”
As soon as SAP switches to a new illusory user interface, Hasso Plattner will come out and announce how revolutionary it is. The slavish consulting companies will begin repeating whatever Hasso says as the future direction. Beautiful PowerPoints will be created which will herald the new luxurious SAP user interface.
The entire process will repeat itself.
Fiori, the “new SAP user interface.” For which Hasso Plattner declared that.
“SAP now has the best user interface in enterprise software.”
All before anyone had used it. A user interface which has been slathered over SAP marketing materials, SAP conferences, etc.. is failing. It is failing for some important reasons that are presented in this article. These reasons are unlikely to change. The people that uncritically supported Fiori look foolish as Fiori is nowhere to be found on SAP projects.
More deep analysis from SAP partners like Deloitte and IBM on the topic of Fiori.
I will take credit for calling out Fiori’s limitations early, but really, it was not that difficult. I spoke to several people with far more experience than me in user interface development that predicted Fiori was going to fail. They could not say anything publicly. Unlike me, they are not unaffiliated, independent consultants. The only complex factor is if you have a mental bias or financial bias towards SAP. I don’t, therefore it is an easy conclusion to reach.
So What is Next for SAP and Fiori?
Fiori is not a sustainable user interface for SAP or SAPGUI replacement. It is a mobile application with limited applicability to most of SAP’s transactions. SAP already invested mightily in SAP Mobile. After SAP Mobile had failed, they purchased Sybase, partially for its mobile offering called Sybase Unwired Platform. After the Sybase acquisition, SAP then purchased Syclo. Years later SAP has done nothing with any of these acquisitions and no one uses SAP Mobile.
One SAP account manager told me that it was just impossible for SAP to compete with mobile application development. This type of development is at a completely different price level than SAP is accustomed to. The mobile development environments are produced on Android and the iOS. And developers for these OSs can be found relatively easily, and their development productivity is quite high. Higher than the productivity of anything that SAP offers. They have nothing to do with SAP, and it is not an area where SAP can compete. Mobile is doing great without SAP.
SAP does have its own app marketplace.
And no one cares. These are primarily brochure-ware apps that were developed and that I have never seen on a single project. Here is one example. It follows the Tableau school of making analytics seem around twenty times easier than it is in real life.
A demo with all reality of an episode of CSI Miami. Where every screen owned by the Miami CSI office is a 27 inch Mac display (because local municipal crime lab budgets are of course unlimited). And labs with three-dimensional modeling software. Software that recreates crime scenes real time! Software that performs DNA matching in the time it takes to get a coffee.
I have never seen anything approaching this on any SAP project. Most SAP projects are just trying to get through a long queue of uninspiring reports from the SAP BW.
I have seen companies set-up their internal development using iOS as a platform that has nothing to do with SAP. The data is integrated to SAP. It works great and mobile is not an area that SAP has a chance of being involved in, so SAP should probably stop wasting its resources to “make it happen.” There are segments that you don’t necessarily have to provide an offering.
While SAP has been wasting time with Fiori, SAPGUI keeps getting older. With Fiori losing credibility, it may be time for SAP to pivot to a new user interface offering!
SAP has been bringing out some new sexy user interface for decades now. Those with a good memory may recall Duet. A partnership with Microsoft that failed. I don’t have the list I once saw that showed all of SAP’s new user interface introductions over the past 15 years, but it was quite lengthy. SAP has had. SAP did this already when the pivoted from the highly touted Personas to the highly touted Fiori. Both of which never existed for the vast majority of customers on anything other than PowerPoint presentations.
The Problem: SAP’s Changed Strategy on Fiori
SAP has changed its strategy on Fiori, from one of charging for the SAP Fiori Apps to making Fiori as part of a packaged deal — that is packaged with HANA.
This is what is known as a Faustian bargain. It does not allow the SAP Fiori Apps to succeed on its own merits, but instead unnecessarily ties Fiori to HANA. However, there is no technical reason for this to be the case. SAP has put a significant amount of effort into Fiori, but Fiori has a very poor future if SAP continues to limit the use of Fiori apps to customers that are running HANA.
Overall, SAP is presenting customers with a risky product in Fiori. I cover the topic of enterprise software risk in great detail in the book Rethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects, and the fact that Fiori is offered by a large software vendor like SAP does not change these risks.
Fiori is much more involved than is commonly presented. SAP and their surrogates want to make the use of Fiori sound as painless as possible, but because Fiori is not technically baked and because it is used to drive customers to HANA, it is often presented under pretenses.
Being Part of the Solution: Our Predictions on Fiori
The information coming out about Fiori from SAP and from the SAP consulting companies has been largely false. Fundamental inaccuracies have been provided to customers, such as overestimating Fiori’s uptake, as well as how much functionality Fiori covers in S/4HANA.
After 4.5+ years after Fiori has been introduced, and there are extremely few customers that use Fiori. Brightwork Research & Analysis called out the problems with Fiori repeatedly while SAP consulting firms have been providing bad information. The amazing topic is that companies continue to rely on SAP consulting firms for what is true about SAP. We beat every single entity that covered Fiori. All SAP customers had to do to not wasted money on Fiori was contact us. The Fiori story never made any sense to us.
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 Fiori 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