Despite its modern interface, Fiori's coverage of traditional SAP GUI transactions is limited, leading to a mix of SAP GUI and Fiori usage, with some users finding the transition slower due to added layers of interaction.
HANA, being an in-memory database, inverses traditional infrastructure costs by requiring more expensive memory for storage rather than relying on cheaper disk storage, making careful planning essential for cloud migrations.
Many S/4HANA migration projects focus on replicating old ECC functionality, missing out on the thousands of new features and improvements that can drive significant business value and innovation.
Before beginning your S/4 migration make sure you’re aware of these 5 common pitfalls.
1. Fiori coverage is patchy in S/4HANA
SAP’s UI has been dull for decades. SAP GUI was outdated in the late 90s, so 25 years on it’s laughable by contemporary standards.
That said, it’s functional. It works and is generally consistent despite decades of development. Many software vendors struggle with the consistency of their UI as developers and product leads come and go. SAP has done a reasonable job of maintaining standards and evolving components of the UI over time.
With the launch of Fiori around 2015, SAP lauded a new era of UI. Based on HTML5 (remember when that was the new new thing?) Fiori offered up a more modern interface fit for the incoming millennial generation of employees.
Fiori’s tile-based construction made it easy to navigate through business transactions, with Fiori apps replacing (in part or in full) traditional SAP transactions.
The downside – millions of SAP users around the globe had gotten used to the transaction shortcodes as a quick way to jump to their required business function. Fiori added a layer of scrolling and clicking to this speed, with some new Fiori converts complaining that users were slower in the new UI than the old SAP GUI.
Maybe a time and motion study as part of a business transformation project could show the before, after, and impact on business agility?
But the bigger challenge with Fiori – especially as part of a move to S/4HANA – is that the coverage of Fiori apps just isn’t broad enough. Yes – there are plenty of apps. Yes – some of them are slicker – especially the dynamic analytics apps. But there just isn’t 121 coverage of SAP GUI transactions to Fiori apps.
Some SAP GUI transactions have been atomised into multiple Fiori apps. Other transactions have no direct GUI replacement (and SAP’s documentation on the mapping of these is patchy). But even some transactions that do have Fiori alternatives don’t have like-for-like functionality.
Take the much used VA01 transaction – Create Sales Order. After all, what would business be like if we didn’t have sales orders?
The VA01 equivalent in Fiori is Process Sales Orders. Taken at face-value, this is a direct replacement.
But there are devils in the details.
Here are some direct warnings from the documentation on this app.
Be aware that in this app, you can only change a limited number out of all the address fields available in the system. Any additional address-related data for the ship-to party that is directly connected to these fields and that you cannot change in this app is deleted.
This could be the case when you first created the sales order using other channels, such as the “Create Sales Orders – VA01” app or an API.
For example, when you change the street name, house number, postal code, and city, the system automatically deletes the building number from the previous address.
If the system finds an error in any header field or if you enter an invalid value for an item field, you cannot save your item.
Not all fields are editable. Also, no warning is displayed in the item details.
Hardly compelling is it?
And this is just one example transaction. Most organizations will rely on a few hundred transactions to run their business processes.
This will leave most businesses with a gap between what they were sold (modern new Fiori UI) and what they end up deploying – a mix of SAP GUI and Fiori.
Yes – there are web UI versions of the old SAP transactions, which removes the need to deploy the desktop SAP GUI to users, but they’re not much more than a slightly different hue of color with some more modern interface controls.
2. SAP HANA infrastructure has an upside-down cost profile
Let’s start with HANA vs. S/4HANA.
Many people struggle with the difference. And, the more senior people are (e.g. CIOs) the more prominent this misunderstanding seems to be.
HANA is a database.
Like Oracle, MySQL, DB2 – HANA is just a database.
When SAP talks about HANA 1.0 and 2.0 – that’s simply a version of the database.
Traditionally, you probably ran SAP on Oracle or DB2 or Sybase. SAP architects used to proudly state that SAP would run on any database (AnyDB) and any OS, with complete abstraction of the application layer from the OS and DB layer.
This was its architectural genius.
However, commercially for SAP, it meant that a slice of their potential income was being syphoned off to competitors – in particular Oracle.
So, SAP designed their own database called HANA.
HANA is an in-memory database and has some pretty clever ways of speeding up access to data by the way it stores information.
S/4 is SAP’s latest ERP offering. It replaces ECC, which replaced R/3.
S/4 is a collection of functionality that delivers a set of business processes.
S/4 is the application. HANA is the database.
You can run ECC on HANA. This is called Business Suite on HANA. Whilst not optimized to be as fast as S/4, ECC on HANA is still fast.
If you run the HANA database, you are accessing data from memory on your infrastructure, not from disk.
HANA does some clever stuff to cache hot data into memory so that not everything needs to be in memory, but in general, there is much more frequently accessed data in memory than there is on disk.
And this is why your HANA infrastructure needs are upside down.
Traditional databases use cheap storage (disk) for data and expensive compute (memory) for processing. In memory databases use expensive compute (memory) for storage.
Which means that your infrastructure costs invert. If you’re hoping to run on the same kit or expect the same cost footprint from your hyperscaler, you’ll be disappointed.
This also makes the decision on moving to cloud important as part of your HANA migration planning. Note – that’s HANA and not necessarily S/4HANA.
3. RISE isn’t a new version of SAP
Companies talk about implementing RISE, or moving to SAP’s new RISE solution.
R/3, ECC, S/4 – are all versions of SAP’s ERP suite.
RISE isn’t. RISE is just a commercial wrapper for services and licences that enables SAP to offer a more cohesive cloud offering.
When you ‘implement’ RISE, you’re most likely implementing S/4HANA on a cloud platform that is managed by SAP. That could be AWS, Azure, GCP or SAP’s own cloud environment – which used to be called HEC (HANA Enterprise Cloud).
It is possible to move to RISE (as a commercial offering) and remain on ECC.
RISE only exists so that SAP can own the stack (Application, Database, Hosting) and so that SAP can count their revenues as cloud subscription – which is a nice message to shareholders.
RISE includes some other stuff too – but the lion’s share is a commercial repackaging of things you could already purchase.
4. S/4 doesn’t replace ECC
Let’s first start with a brief history lesson.
SAP R/3 comprised a series of integrated modules covering the various business processes functions. These had 2 or 3 letter acronyms – MM=Materials Management, FI=Finance, SD=Sales & Distribution, PP=Production Planning, SRM=Supplier Relationship Management, EWM=Enhanced Warehouse Management.
The core SAP modules have been in place for 20+ years and have been enhanced over time with new functionality.
SAP realized that certain functionality could be improved and in the late 1990s bolted on New Dimensions products. These covered better analytics (BW=Business Warehouse), better Supply Chain (APO=Advanced Planner & Optimizer) and Customer Relationship Management (CRM). Warehouse Management (WM) was improved and spun out to EWM (Enhanced Warehouse Management).
Over the years, SAP either built or bought other add-on solutions like Ariba, Success Factors, Hybris, Integrated Business Planning (IBM) and FieldGlass.
With the move to S/4HANA, SAP had a conundrum – functionality in the ERP core (ECC) which clashed with functionality in the new add-on solutions, which clashed or overlapped with functionality in the now old New Dimensions products.
This means that S/4 doesn’t cover some of the core functionality that ECC used to.
- There’s no SRM – as that now lives in Ariba
- There’s a lack of HR and Payroll – as that now lives in SuccessFactors
- There’s no longer a CRM solution – as this is covered in part by Hybris
- APO no longer exists – as this is partly covered by APO and partly by core S/4 functionality
- EWM has been absorbed into the S/4 core, with options to integrate to a stand alone EWM solution.
The upshot is that moving from ECC to S/4 for some SAP customers isn’t simply a lift-and-shift. If you use any of the above displaced functionally, you’ll need to implement their alternatives (or a competitor’s solution) before switching off ECC.
5. Code remediation in S/4HANA is a thing
SAP code is largely written in SAP’s proprietary ABAP programming language. The core solution is written in ABAP, and customers can create their own custom programmes in ABAP too.
These custom programmes (often referred to as Z Programmes because they are named beginning with the letter Z for convenience) represent many years of thought, effort and investment. They’re the things that make your SAP system unique to you so that it can run your business the unique way that it runs.
It should be that your Z Programs are the things that drive your competitive advantage.
Truth is, most companies customize other things too – simple, standard things that perform commodity business processes.
This is where fit-to-standard comes in – moving to S/4 is an opportunity to review your custom code and decide whether to retain it, replace it, or revert to standard functionality. Bear in mind that new functionality could have been released since you originally customized your SAP solution.
But the code you decide to keep won’t simply work with HANA (in ECC or S/4).
In both cases, you will need to change your custom programmes to comply with new SAP conventions in order to either work, or be performant with the new faster HANA database. Why move to a faster database if your code doesn’t run as fast as it could?
The code has to be changed for Business Suite on HANA (ECC) and for S/4HANA – each with its own unique conventions.
If you ask your Systems Integrator, they’ll gladly remediate your code for you. 100 custom programmes, 10 days per programme, $1,000 per day equates to a $1m prize.
And it adds months of delay to your move to S/4HANA.
It is possible to automate the analysis of your custom code and even automate the remediation of code. This makes it cheaper, but crucially faster – meaning that you can spend more time testing and managing business change.
Nobody knows what’s new in S/4HANA
Most SAP integrators are constrained by the number of people they have. Many of their people have been working on SAP programmes for decades. They’re close to retirement and stuck in their ways. There’s also a lack of new talent in the SAP ecosystem compared to other technology platforms.
This means that S/4 migration projects are often approached using out of date thinking and 20+ year old methods.
The focus of most S/4 migrations is to get the old ECC functionality replicated in S/4.
But that’s not where the business value lies. And it won’t light up your CEO’s eyes as part of your business case presentation.
Aside from the Fiori apps, there are thousands of new features in S/4HANA. Many of these could provide the impetus for your business case, or alleviate a major frustration in your critical business processes.
Conversely, some old ECC functionality has either been removed or changed significantly in the move to S/4HANA.
The trick is knowing what’s different – what’s been removed, improved, changed or added?
What’s been removed or changed has a business change impact.
What’s been improved or added should be on your roadmap – either as part of migration to S/4 or shortly after.
There are also hundreds of APIs available in S/4HANA which enable real-time integration. If you simply replace the interfaces you have today in ECC, you’ll spend millions getting what you have today with a new version number.
But if you explore what’s available, you stand a better chance of improving the way that your business runs.
SAP doesn’t have a single central source of this information. FusionGraph enables you to analyze your current ECC usage and overlay everything that’s new, changed, removed or improved – so that you can build an S/4 business case, and properly plan the business impact of moving from ECC to S/4HANA.