SAP S/4HANA: The smart approach is selective and lean by design

We’ve been talking about SAP^® HANA^® and then S/4HANA^® for a long time now.

First came HANA in 2010…

The HANA database in itself came as a revolutionary first, way back in 2010 – an ERP company recognising the sheet weight of data that exists in ERP systems today. SAP focused their investments first in a technology platform that could support a modern ERP application landscape capable of meeting the growing demands of faster processing of complex, increasingly digitised and connected, businesses; businesses that now have billions of lines of data being used to drive them.

And so the die was cast, and the HANA conversation started as a technical one – a database one – for five years. By the time S/4HANA was released in 2015, this was already baked into people’s mindsets. Moving to a HANA (as it was known) could save you a lot of resource and time overheads, giving the business improved efficiency and capability to react, just by being able to leverage the capabilities of the HANA database. It was a costly, high-performance system, so it was adopted only where the cost was balanced or exceeded by business benefits. S/4HANA licensing was a further cost, and so the conversation became confused: Do we run new processes on HANA? Do we need to if it’s so fast that our old ones will work in half the time?

The high-performance, but high-cost database also started the increasing trend of analysing where your data should be held. What needs to be within that high-performance application, and what only needs to be referred to or used in analytics? What is replication of that data to Test and Development environments costing us if we’re on HANA?

Now we’re thirteen years down the line, and quite a few clients are still not on HANA or S/4HANA – they are on ORACLE, MySQL, DB2/6 and Sybase ASE databases (SAP’s acquired interim which brought IQ and other tech with it).

There are also quite a lot of SAP clients who have moved to HANA and S/4HANA, but it’s a slow and significant shift – with roughly 80% of core clients still to move.

Two things seemed to be on many minds:

• Firstly, if you didn’t have the needs of the more complex businesses, then the value return on HANA wasn’t enough to invest in it.
• Secondly, as companies have acquired 20-45 years of data in ERP systems now (30 years ago is now 1994, and SAP was founded in 1972, so you do sometimes find data in systems that goes back to the 1970s), they realised you certainly didn’t need to store this all in a HANA database. This was clearly a move to approach with trepidation and careful planning.

So we had a big debate about databases and benefits; technology and data itself at huge scale; composable ERP and clean cores. New business processes were possible, but not because SAP was going to build them for you – more because they were going to give you a new platform to enable your business processes. It was primarily an IT department consideration around the horsepower of the ERP platform behind ECC.

…then S/4HANA in 2015

Five years after HANA was released, in 2015 SAP released SAP S/4HANA, its new ERP platform to completely replace R/3 and NetWeaver. Except that – unlike the R/2 to R/3 move – this wasn’t a completely new system. The ABAP code core is still there, the client/server model is absolutely still there (though more cloud connected) and the upgrade primarily changed central finance operations (and it’s notable that CFIN could be installed on ECC).

At this time, while S/4HANA transformed the finance core, the other operations that had always been integrated (suppliers and procurement, supply chain, big customer relationship systems) started to be moved out into other technologies. SAP acquired external companies and looked to where the HANA base could be leveraged. However, technology wasn’t deeply integrated, and so clients buying into SuccessFactors (the new HCM, except it didn’t have payroll), C4C (the new CRM, except it wasn’t HubSpot or Salesforce), Ariba and the like found significant growing pains moving to a composable model that all came under one company’s licensing structure, but wasn’t really one technology – and certainly wasn’t one all based on HANA.

So, the message was confused. But with BTP, the move of S/4HANA to a roadmap for cleaning up the core (and moving it progressively to a DevOps cloud model that would match it to the acquired cloud functions and to best-of-breed competitors), SAP is moving in the right direction to make the most of technology.

The rainbow of ‘field’ approaches that people look at taking when wanting to move to S/4HANA is diverse in discussion, but mostly quite simple. A green or brown core, and then selected process transformation. As most people know now after a long-winded industry dialogue, the two basic routes are something like this:

• Greenfield: start with a brand-new system and processes – no historical data just master data, and key information required to completely re-design your ERP. In other words: attempt radical change
• Brownfield: keep your data and historical data – slowly effect change on the new platform.

And here’s where our niche in EPI-USE Labs comes in. People often assume that greenfield means no historical data, and brownfield means all of your data. This isn’t correct.

SAP have been talking about Selective Data Transitions (SDT) and landscape transformation (LT / SAP LT / SLO / SLT) for a while. It is entirely possible to enable clients to disconnect concerns about data from the general approach to adopting S/4HANA. Which then means every conversion can be selective, no matter the way of moving to S/4HANA. This is important, as it ties back to maximising your return on investment, and ensuring an efficient utilisation of that high-performing database that’s caused so much fuss since 2010.

So where do you start?

What’s important to understand is that everyone wants to improve business processes, but unless your ERP environment is very small, the cost of starting from scratch is unlikely to be fruitful, as it will split focus across all your processes, not just the ones that you can improve significantly on S/4HANA. While a brownfield – even if it takes a line of slower selective transformation – can still change some key business configuration and processes.

So, my recommendation would be to start with a pilot brownfield core and key processes to pilot (data can still be selective!) and to adopt incremental steps to move towards standard processes only where they add value.

It may also be a good step to run a parallel pilot – take a small subset of data and run it into both a green and a brownfield pilot system. Sharpen that axe before you try to chop down the tree!

To summarise:

(Of course, my thinking on the topic is influenced specifically by my experiences, and I encourage comments and debate!)

Every company that wants to move from ECC to SAP S/4HANA should:

• be taking a selective data transition approach, regardless of the colour of the field they are wishing to setup camp on.
• be targeting a clean core (an admirable goal), but understanding that customisations will still exist (on BTP and similar platforms), and so if your business is complex enough to need to run SAP, then you probably don’t want to move to a purely greenfield setup in one step. In this case, if a brownfield approach can still be selective and transformative, but has a lower cost of change – why not take that path? Unless you identify a clear business benefit from the green approach, this would be my guidance.
• consider parallel brown and green pilots on a subset of core (recent) data to be able to take an informed decision.

Don’t ever forget that any project of this type (as per Cloud Migrations and old school upgrades) are a unique change, and a unique chance – when you’ll briefly have two parallel landscapes – to redesign your business configuration (customisation) in ERP and to redesign your data from Development systems to Production systems (and maybe even to stand up S/4HANA in a way that non-production systems are always anonymised or pseudonymised from now on to protect your data).

We see a lot of companies who focus on improving business processes, but forget about optimising their DevOps environment. The problem with this is that they often end up with a very large platform bill for their S/4HANA estate. It’s quite common to miss the data in this way, especially when looking across the full landscape (Dev, QA, Pre-Prod, Project Tracks, all through to Production). However, if you don’t build the full landscape to a careful design before you move, you might spend years trying to optimise it afterwards (and paying the associated bills until then).

Optimise your move to S/4HANA using specialist software like EPI-USE Labs' Data Sync Manager to ensure a 'Lean Secure ' SAP estate

I’ve been kicking around the paradigm of ‘Lean Secure SAP’ in EPI-USE Labs for a while now. It’s focused on data from Production and through all non-production DevOps systems. It still fits, and my recommendation to anyone moving to S/4HANA is to have a data design for the whole landscape; the goal being to run with lean data, lean systems, and with data privacy baked in.

Know that you don’t need to worry about the colour of your field with regard to this; the clean core and the move to standard code, processes and a better business setup can affect your data approach, but it doesn’t need to define it.

If you do careful preparation – especially of business partners and finance – and you carefully plan your approach to code, process and data, then you can optimise your return on investment and potentially reduce your TCO so significantly over the next five years (through this good planning) that your value and benefits can really outweigh – significantly – your investment in the S/4HANA platform. The HANA and S/4HANA tech really is fantastic. While you need expertise to look at your license costs/approach carefully, there is a world-class ERP platform here that has technical and functional capabilities that can change how you do business.

I would recommend starting with a brown selective approach, and pilot this; and consider also setting up a small green system, to prove the best approach for your business.

Then I would espouse a Lean Secure SDT approach; to think about the green-to-brownfield spectrum only as an approach to code and processes. To draw a dotted line to data, and ask what taking only what you need looks like.

You might want to just keep all your data, if you only have a few years of history and a small landscape, but otherwise I’d advocate for everyone being natively selective and consciously aware of how they manage their data during this project, for Prod to DevOps, testing and projects systems.

This project may be your last unique chance to optimise your landscape during a major conversion. Now that SAP is looking to more of a regular cloud-tied released schedule, with a clean core concept everyone will eventually get to, will we ever have another major conversion of this sort? If so, it will be a very long time until such a chance will come again: so sharpen your axes before you swing!