Yesterday I attended a meeting of the Dutch SAP User Group (VNSG) on the topic ‘Customer Fiori Experiences’. As usual, the audience was mostly consultants/developers of SAP consultancies, and only a few actual end-customer attending. After interesting sessions on the state of Fiori (a.o. on SAP Fiori Cloud Edition), the meeting ended with a roundtable to share experiences. And in particular to discuss and answer on the topic how-to increase Fiori adoption in the market. According to latest numbers, (only) 10% of SAP customers world-wide are active with Fiori, and significant subset of them merely with 1 or 2 first Fiori Apps. Note, in The Netherlands the number is higher, as we’re very technology-savvy and typically run ahead of the rest of the world on adoption of new technologies.
There was large consensus in the group that the minimal actual Fiori implementations is for a major part still due unfamiliarity. Not so much by business and end-users, but by majority of SAP developers for which the step to Fiori / UI5 is [too] big, and they prefer to just stick within their comfort zone. Although there might be truth in this, I personally think the more important causes are others.
The most important is that for SAP customers there must be a tangible business case to switch to Fiori. It is not sufficient, even irrelevant for SAP organizations to switch to new technology and products just because SAP is now delivering it (and promoting it as the next great thing). Even though standard Fiori Apps do not have a license cost (anymore), there is still investment costs involved to transition from current application formats (e.g. GUI transactions, Portal application, WebDynpro) to Fiori as new UI and interaction concept. The investment costs are within preparing the IT landscape infra (introduce NetWeaver Gateway, and Fiori Front-End Server), deploying Fiori Apps plus the required underlying Gateway OData services in the SAP landscape, align with and convince Enterprise Architecture plus (IT) security that Fiori is a future-proof and secure/safe approach, educating end-users. And typically the standard Fiori Apps are not addressing the core of the specific organization, and custom Fiori Apps + Gateway OData services must be developed. And there is again the business case: if there is an existing application that still does the job, even with outdated, stone-aged layout and user-experience, there is little business motivation to invest in improving that for the internal employees. So what is needed then? In my experience and opinion, the precondition to introduce + land Fiori usage within any organization is that there is a concrete trigger – business or IT (savings). This can be that an existing SAP application (standard or custom) no longer suffices and requires to be redesigned and rebuild – and thereby introduces the opportunity to take new UI and mobility requirements into account. Or because there is a new business demand, and again in the current days with ‘mobility-first’ this must be included from beginning of. A third trigger is Application Lifecycle Management, which forces organizations to upgrade their landscape to recent NetWeaver version. Also this can be good moment to reconsider for (some) applications to migrate them into a modern UI experience.
Note, what does not help the market growth of Fiori is the SAP image: stable and robust functional platform, that you do not have to (should even) touch much. SAP could therefore also take a rewarding approach: make it tangible benificial for SAP customers to introduce Fiori => introduce new functional capabilities only via/as Fiori. Actual SAP is following this approach, with 'Fiori-tizing' S/4 HANA.