The saying goes “things come in threes” but when I started Googling about why this is the case, it would appear that it is largely a clever literary trick to get the audience’s attention or to make content more memorable. Not being the type of person to let the reality of this discovery spoil a good opening to an article, what triggered this train of thought was a series of recent events relating to the topic of SAP S/4HANA and its Fiori frontend.
It all kicked off while I was talking to a colleague who is currently working on a project where another SI partner is carrying out the S/4HANA implementation. My co-worker expressed surprise that they were planning on only accessing the system via the backend SAP GUI and I was asked for my opinion as to whether this was a common and/or sensible approach. Meanwhile, on a large greenfield S/4HANA programme that I’m currently engaged with – a member of the team initiated an interesting discussion as to whether we should demo via the Fiori apps or use the backend during our Explore phase workshops?
To compound my thoughts further, I was reading a blog about the impact of S/4HANA (written by an SAP partner), and one of the themes was that Fiori should be considered as optional, or as something that you might deploy as a subsequent wave in a S/4HANA implementation. These various events got me thinking about if/why deploying S/4HANA without its Fiori frontend might be an option to consider.
Getting the most from SAP S/4HANA
If you are implementing S/4HANA Cloud, then you can’t even touch the backend so my discussion here relates purely to the various offerings on the on-premise code line (but notably it does therefore also cover the S/4HANA Single Tenant Cloud offering). In the on-premise code line-based products, you can access the backend of the product, and indeed you need to do so as an implementation team to carry out configuration.
However, it is not entirely true that you can deploy S/4HANA without using Fiori at all. There are several apps which are only available via the Fiori frontend and have no backend transaction counterpart. The setup of ‘House Banks’ is a good example of this – as more innovations and new functionality are deployed by SAP, many of these will only be deployed via Fiori, so as time passes, the gap between what you can do in the backend and the overall capability of the solution will grow. Whilst you can carry out a lot of your business processes accessing the system via the backend rather than using Fiori apps, in doing so, there is a lot that you will miss out on.
User experience – at the very simplest level, the Fiori user experience is a lot more intuitive, so less training is required for new users. For clients moving from a legacy SAP landscape, there will be change management issues and an element of training required, but these are not as significant as some might estimate. Besides, with Fiori, users get access to powerful tools, such as ‘Enterprise Search’ plus the ability to access much improved context-sensitive help.
New ways of working – it would be mistaken to assume that there is a 1:1 relationship between Fiori apps and SAP GUI transactions. Sometimes, a transaction may have been decomposed into multiple apps (or vice versa); either way, it promotes new, more efficient ways of working. In particular, the ‘Insight to Action’ mantra that SAP use to promote S/4HANA is relevant here. For example, where a KPI app provides the user with a business metric into which they can drill down, depending on their findings actually transact to take corrective actions, all within a single app, rather than having to separately run a couple of separate reports, followed by carrying out a further transaction. This represents a real opportunity for business process improvement.
Reporting – without Fiori, the user will be severely restricted in their ability to exploit the benefits of the embedded analytics that are a core part of S/4HANA (to me, they represent one of the most significant improvements) and would potentially necessitate the use of a more traditional BW solution to be able to deliver even fairly simple operational reporting. The KPI reports alluded to above are also only available via Fiori.
Intelligent ERP – the innovations supporting ‘Intelligent ERP’, such as machine learning, process automation, and conversational ERP and collaboration are again only available through Fiori. The pace of innovation in these areas is significant and again, can provide real business process improvements.
The burning question – could you, would you, should you?
Could you? The simple answer here is yes. You could deploy S/4HANA to a user audience and allow them to access the system via the backend using only the old SAPGui transactions that a legacy ECC SAP user will be familiar with. However, some tasks will need to be carried out via a Fiori app. Superficially, this approach might appear to be a way of minimising change impact, and would remove the additional training costs associated with implementing the new solution, but to me, that is a naïve view, and I think a business taking this approach could lose more in missed benefits than they would gain in savings around change management.
Would you? Here, my instinct would be to say no. To me, deploying S/4HANA but not using the Fiori frontend is a bit like putting a Ferrari engine into an old mini. It might seem like a good idea, a bit like a low-cost way of getting a faster car (OK – so I may be labouring the analogy a bit here) but given the limitations of the underlying vehicle (chassis not stiff enough; weak brakes etc.), you would actually never be able to harness all the potential power available to you. I would also be a bit suspicious of scenarios where not using Fiori was proposed, and want to understand in more detail the reasoning why.
Should you? Again, my gut reaction is no. Looking at all the benefits available via Fiori and to me, a lot of these cannot be separated from the core benefits of S/4HANA, I would find it hard to come up with a business case for taking this approach.