The unexpected challenges of an SAP S/4HANA implementation
“SAP is SAP is SAP, right?”
“It’s just an upgrade, it can’t be that different from SAP ECC6.0!”
“It’s a faster database with a web front end isn’t it?”
By now you’re probably realising that these statements all have one thing in common: they are wrong, wrong, wrong! When setting out on an SAP S/4HANA implementation, whether an upgrade to S/4 from ECC6.0 or a greenfield implementation, if you don’t leave behind your carefully nurtured preconceptions about SAP, you are setting yourself up for an almighty shock and at worst, a failed SAP implementation.
There have been many blogs over the last couple of years dedicated to the differences between S/4HANA and ECC6.0 and I don’t want to rehash that same old territory. Rather, I’d like to give you an insight into the kind of things which will trip you up on your S/4 journey unless you provide provisions for them, meaning appropriate timing and resourcing. Don’t get me wrong, you could get by, by learning a few of the new bits of functionality, cruising on through your implementation and going live without much incident. But you will not be doing yourself or your business any favours. There will be a whole world of opportunity out there which you will not be picking up on, and that world is shaped like an Italian flower….Fiori.
So what is the big deal with Fiori?
Isn’t it just a web front end to the traditional SAP GUI? No! Fiori is the new face of SAP ERP; SAP brand it a “user experience” (UX) instead of “user interface” (UI) and they are right. Fiori is all the things you would want from a decent website, but also harnessing the underlying power of SAP HANA database and traditional SAP functionality.
Recently, a project director said to me that one of the advantages of Fiori was that it converts SAP from a system which needs intensive training to one which needs hardly any. I get the point. He wasn’t 100% correct, but the structure of Fiori is certainly simple and coherent. Adaptive and delightful? If implemented correctly, yes, absolutely. And what about role-based? Let’s come to that in a minute, as it is one of the central pillars of Fiori.
SAP Fiori presents SAP data in easy to read applications which can be accessed from any device (including your smartphone – believe me, I do it). There are three types of apps:
which are web representations of the traditional SAP transactions – all of you Order to Cash consultants out there will recognise this:
Fact sheet apps
which show key information from which you can drill down into SAP transactions and master data:
which push out real time information about business operations, meaning users are presented with their work without proactively having to run a report:
The implementation of Fiori is our first unexpected challenge. If you don’t do this right, your implementation will be dull, lifeless and valueless. Do it properly and it becomes exciting, intuitive and brimming with added value. Focus your attention on the analytical and the fact sheet apps. There are some fantastic standard apps provided by SAP which will need to be activated for you to make the use of them. Remember: how can you add value to your organisation through S/4? Always keep this in mind, and you will find Fiori offers incredible potential to do just that. If you only use the traditional SAP transactions in Fiori, you will be missing an opportunity to add a great deal of extra value.
But hold on, what about “role-based”? What does that mean?
Well here’s our second unexpected challenge. I wanted to separate it out from the discussion around Fiori apps as it is a whole different conversation.
We all know about SAP security roles in standard ECC6.0, and they are still there in SAP S/4. But there is a whole new level of security around Fiori. Here is where you can make a huge difference to your users’ lives. I implore you to follow SAP’s recommended Leonardo design-led approach to this. Get out and talk to your users first (the “Discovery” phase). Build out “as-is” flows, understand what they do and how they do it. What are their pain points? What takes longer than it should or is harder than it should be? Build out your “to-be” high-level prototype based on all you have learned – what would the ideal system look like? You can use the Fiori role-based nature to improve their lives! Create a dashboard tailored to each individual business function, showing only what they need to see. Add apps and links into their user groups which make their life easier, more intuitive. Push the work to them rather than have them go and search for it. Through Fiori’s system of catalogues and groups, this is all possible and highly desirable.
But beware! Don’t fall into the trap of leaving this until the end of the build process, when you have done all your configuration and development. I would recommend that this process is front and centre of your deployment from the outset. Assign a Fiori architect, who is well versed in the principles of Fiori and get some coordination with your basis and security teams. You will need to create user groups, catalogues and target mappings, as well as expose the transactions you want to the front end and activate your apps. I’ll leave you with this picture to ponder over. It may not explain it fully but this is a subject which could occupy days!
So that’s two unexpected challenges down, but what about the traditional configuration in the back end of SAP? Surely that is pretty similar to what it used to be? Well, as every good SAP consultant loves to say, the answer is yes and no. In a concerted effort to help, SAP has produced a very useful “simplification” document, detailing all the changes. The problem is, it is over 900 pages long! The link is here.
The main unexpected challenges you have to watch for are, in no particular order are below – this is by NO MEANS an exhaustive list (Please remember that these changes improve your SAP implementation and should be embraced).
• New General Ledger
Classic GL is no longer available in S/4. Get your FI analyst trained up on this otherwise, it will be painful.
• Business partners
Customers, contacts and vendors are no more! The traditional transactions such as XD3, VAP3 and XK3 are obsolete and will simply redirect you to the transaction BP. If you are familiar with SAP CRM then fear not, as this is comfortable territory, but if not, do your research.
• Credit management
Traditional SD credit management has been turbo charged in S/4 with greatly increased functionality. It’s not that hard, but you need to be aware of it as you must use it (there is no option not to).
• Foreign trade
Foreign trade data has been shipped out to SAP GTS. However, don’t worry if your implementation budget does not allow for GTS. SAP have realised the error of their ways and have, since version 1709, brought back into scope legal control, embargos and intrastat reporting. Everything else…now in SAP GTS only.
• Revenue recognition
Another turbo charge from SAP, with Revenue Accounting and Reporting (RAR) being spawned. This is quite a biggy – under estimate at your peril.
• Output management
By definition output management across all functions will now use the Business Rules Framework (BRF+). It takes some getting used to, but the option to stay with your traditional NAST approach is still available, but you will need to make some small config settings to allow this.
• Warehouse Management
The SAP solution for WM is now extended warehouse management (EWM), either embedded as a native integration or as a side-car approach. The old WM is still available, but for how long is not clear as SAP have expressed their intention to retire it.
MRP runs in ECC are usually overnight, whereas in S/4, we are introduced to the concept of MRP Live, running MRP in real time using the in built power of HANA. Furthermore, SAP have future plans to integrate some features from APO (including Global ATP) into the core functionality – this is exciting news!
Advanced ATP is new to S/4 – features like location substitution – automating STOs between plants based on ATP rules – is pretty neat.
• New tables
There are many new tables you should be aware of in S/4, especially if you are upgrading from an ECC6.0 system rather than carrying out a greenfield implementation.
I hope I haven’t scared you. SAP S/4HANA is an exciting development in the SAP journey and there are other opportunities out there which you may like to investigate too – namely SAP Cloud Platform, which has some really funky features; SAP personas, where you can personalise familiar screens and create links and new buttons; and SAP co-pilot, which may end up making things like workflow a thing of the past.
My main piece of advice is: upskill your implementation team before you embark on the project – SAP ECC6.0 skills just won’t cut it in an SAP S/4HANA implementation. You wouldn’t want a bicycle mechanic working on your Ferrari, would you?
You may also find it useful to read Eursap’s blog post on: How to use SAP Activate for your SAP S/4HANA Roadmap
Good luck with your S/4HANA journey!