The migration to S/4HANA with Fiori is a costly & time-consuming project that will yield a low ROI. Previous approaches failed since they laid the responsibility on the customers’ hands.
In this article, the author argues that the migration to S/4HANA with Fiori is a costly and time-consuming project that will yield a low ROI. Stakeholders and managers of companies running SAP are now requested to open their pockets. However, previous approaches, similar to Fiori, failed since they laid the responsibility for the transition on the customers’ hands. Instead, the author suggests seeking tools that will retain the extensive investments in SAP made by customers. This should be done by enabling customers to enhance their existing ABAP-based reports and to enable to publish them as Firoi-like apps. This way, when SAP will come up with its next version, T/5 with Biori UI, we all will not need to read this article yet once again.
It’s well known that for companies running SAP, the migration to S/4HANA and Fiori (SAPUI5 apps) is a question of When rather than If. One way or the other, these companies will move to S/4 – They will do so either by will or with some help from SAP. The music will stop anytime soon when SAP will announce the End-of-Life of earlier ECC versions.
SAP, a software company that has invented the ERP space, was founded in 1972 with the catchphrase: “the company in the business of helping businesses”. Apart from SAP itself, companies running SAP are not software companies investing in the ERP domain. Moreover, companies running SAP on-boarded SAP in the first place, to be able to concentrate on their core businesses – software projects are not their forte. However, the migration to S/4 with Fiori is nothing short but a software project.
Fiori technology leads to a reduced need for development and improved mobile work capabilities. Nevertheless, when moving to S/4 with Fiori, the old SAPGUI processes are not reusable. Every legacy SAPGUI process, to be converted to Fiori, must be revised. That process, its UI along with the supporting code, must be rewritten. A countless number of articles dealing with the path to S/4 could be found. Articles that advocating the necessity of Fiori, praising the advantages of Fiori, and suggesting methods to ease the migration to Fiori. None argue that it’s going to be a walk in the park, though.
All in all, the inevitable migration to S/4 with Fiori, poses a software project in front of companies that did not want to develop ERP software in the first place.
As it’s a software project, we are talking about and should plan for, next we will try to assess it in terms of resources, time & money, expected artifacts, and Return On Investment.
From the resources aspect, the SAPUI5-based Fiori coding introduces new challenges to SAP developers. A new web-based development skill-set (such as UI5, Javascript, and PhoneGap, to list a few) is now needed. Notwithstanding, in order to code a full Fiori process, SAP developers (still) need ABAP knowledge. The needed CRUD (Create, Read, Update, and Delete) operations, manifested as ODATA services, are still coded in ABAP. Thus, for the old ABAP developers, it’s an ‘adapt or perish’ situation. Shortly, we will find ourselves recruiting SAP developers with ABAP knowledge and Full-Stack capabilities.
Time & money are of the essence in such projects.
To estimate such cost we have to, firstly, define a typical entity/process to be converted to the new framework. Generally speaking, ERP is comprised of transactional or non-transactional processes. The complex transactional process is composed of a few screens and many functionalities. SAPGUI transactions such as VA01, ME21N, and MIRO (creating sales order, purchase order, and invoice, correspondingly) are such examples. Whereas, the non-transactional process usually materializes as a query or an operational report.
Neither SAP nor its customers plan to expose full-fledged transactions as Fiori applications. These complex SAP GUI transactions are often used by very few well-trained personnel very extensively. Thus, price/performance-wise, it makes little sense to invest in moving them to Fiori. Actually, in its article UX Transformation for ECC customers, SAP argues exactly that. Fiori represents a fundamental shift to a role-based system. The old ONE GUI for ALL USERS in all roles, in all industries, in all countries is Distilled down to ONE version for ONE user or user group (emphasis in original). This statement made by SAP comes, of course, with a cost. Hence, an old SAGUI report that used to serve various audiences, must be now split into several different Fiori apps. Each app built, UX-wise, to best serve that ONE version for ONE user statement. That is to say, the typical Fiori app is often a subset of the functionality of SAP GUI transactions. Note that the more complex transactions often stay in the SAPGUI or handled using the Web GUI (with the new Belize / Quartz theme). All things considered, the typical Fiori app would be in the complexity of a SAP GUI report/query and we will need more Fiori apps than the equivalent SAP GUI objects we used to have.
Money-wise, the typical Fiori app with that complexity requires between 4-6 developer’s days together with two days of implementer and a tester each – Roughly 5.5K$ per Fiori app. Thus, to serve a single SAPGUI in Fiori we will need at least two apps, 11K$ in total.
We should add an amount of 200K$-300K$ needed for the Fiori migration infrastructures in terms of project assembling, Basis work, and training.
The educated IT manager may figure out that around 500K$ (half a million Dollars) will buy the organization roughly 20 old SAPGUI reports served as Fiori apps. That looks expensive, yet checking organizations that are moving to Fiori (currently not on S/4), the numbers are far higher.
What can we tell about the resulted Fiori app – the expected artifacts?
Is the artifact a clone of the original report? No, we are talking about a brand new object that is composed of a new UI, a new ODATA service, and a new set of backend methods. Like any newly developed code, it’s exposed to bugs and data errors for quite a long time until it reaches maturity.
Will the artifact hold to the next big SAP release, T/5 (if we were to guess that big release name)? No. Based on the technology leaps made between R/2, R/3, and S/4, by the time SAP will launch its next big release (if at all), it will probably use a technology we have never dreamt about and certainly never planned for.
Then, will the artifact hold for the next 3-5 years? No. The pace SAP introduces new controls and approaches will make any Fiori app look ridiculously old after 3 years (or so) of its issuing. The UX world is running fast and no-one, SAP included, can foresee how the next table-control, for example, will look like.
With a costly and lengthy project with yielded artifacts that will not hold for too long, it’s a bit weird to get any Return on that investment.
All in all, the forced S/4 migration project requires new/upgraded resources and lots of time & money. In return, we expect to get brand new artifacts (turning the old SAP GUI development into sunk money) and a questionable Return On Investment.
This, somehow oppressive analysis, may be relieved by knowing that the route to the web presented by Fiori is the right way. Maybe Fiori is, indeed, the Kwisatz Haderach [Dune, Bene Gesserit’s term for the unknown being whose powers can surpass time and space] – Shortening of the Way?
Next, we will try to assess the chances of Fiori’s success in light of early tries, made by SAP, to move to the web.
As of year 2,000, SAP is trying to push hard towards the web. It started with the SAP dot com initiative and it goes on ever since. Back in the days, SAP presented the BSP (Business Server Page) application along with HTMLB (business HTML). If the reader does not familiar with the terms, apparently there is a reason. These technologies are rarely mentioned in the last decade. Moving forward, the Webdynpro Java and Webdynpro ABAP (thereafter) presented yet another approach. In between, we had SAP NetWeaver Visual Composer and many mobile frameworks (Sybase Unwired Platform evolved into The mobile platform [EOL, 2020], to name a few). All RIP. Companies invested in those areas are now cutting the losses.
Surprisingly, the only approach that survived is SAP Internet Transaction Server (ITS), aka Web GUI. The ITS was the first approach of SAP to extend business applications to a Web Browser or the Internet. It was done by converting SAP Dynpro (SAP GUI screen) into HTML format. Actually, the ITS is the fallback SAP offers its S/4 customers, whenever no Fiori app exists. Using the Belize theme, any SAP GUI screen is presented in the Web looking, somehow, like the Fiori app.
Recently SAP even developed a new engine for rendering HTML pages – a successor of Web GUI: Slipstream. It is based on SAPUI5 and offers better support for mobile devices.
What made ITS succeed while all other approaches failed?
ITS was the only approach to generically and systematically convert any SAP GUI objects into HTML. Whereas, all other approaches laid that burden on the back of the companies running SAP. BSP, HTMLB, Webdynpro JAVA & ABAP, all force SAP customers to code each and every object into the web framework.
Moreover, it looks as if the ITS approach was not the first time SAP handled transitions on its own. Basically, the SAP open SQL represents exactly this approach. Developers code in ABAP and the Basis-layer makes it work on any OS and any DB. Actually, using that very logic, the move from R/2 to R/3 was done almost transparently. ABAP code and GUI screens running in R/2 moved on to R/3 seamlessly. The Basis layer, SAP is known for, was always the foundation stone for every successful transition.
However, the Fiori approach looks more like BSP, HTMLB, Webdynpro JAVA & ABAP than the ITS.
If SAP managers and the organizations’ stakeholders would like to retain their investments, they must insist on rollout-like technology. Technology that would use existing investment put in ABAP and expose it as a Fiori-like application. No new code for data fetch, no new code for UI, and hopefully, no new code to extend the old ABAP baseline (report/query/DB table).