SAP S/4HANA and the Clean Core: whiter than white, or shades of grey?

There has definitely been a bit of a laundry theme going on in my head recently… it’s something that has been nagging away at the back of my mind ever since my elderly washing machine recently gave up the ghost.? By the time I had managed to secure delivery of a replacement, the laundry backlog had grown to such proportions as to require a visit to the laundrette (thank you for coming to the rescue, Posh Wash in Horsell).? After the trauma of trying to find sufficient pound coins to pay for a large machine wash (more complicated than you think in a post-covid largely cashless society and on a Sunday morning), I was actually sneakily looking forward to unleashing my inner Dot Cotton.? However, it appears you are no longer allowed to enjoy a crafty cigarette* whilst watching your undies going round the spin cycle – so I was forced instead to thoughts about work – in this case, considerations around governance on S/4HANA implementation, and which topics ought to be subject to a formal Design Authority approval process.

?

Clean Core: flavour of the month?

I notice in a lot of SAP’s recent publications that they have started talking more about the ‘clean core’ construct.? It’s not a new idea… indeed, here at Deloitte, it has been a central theme of our view on ‘what good looks like’ in a SAP-centric application architecture for quite some time.? Indeed, the theme goes back much further than that.? In my 30+ years of working on SAP enabled transformations, pretty much every project I have worked on has had something embedded in its project charter capturing a similar theme, around implementing:

• Standard SAP
• Vanilla SAP…
• an 'out of the box' solution…
• ...the list goes on…

What is the Clean Core?

The pedant in me does like a good definition – after all, if we are going to ensure that we achieve that sparkling clean core, it is good know what we are actually aiming for. In more recent times, the concept of the Clean Core comes from the approach taken in implementing SaaS ERP solutions (a favourite subject of mine), and is perhaps best summarised through the notion of isolating any 'extensions' (i.e. additional functionality added to the core solution to meet client needs not met as standard) from the core solution. In more detail, this is embedded in SAP's '5 Golden Rules' principles, which I have written about before.

'Why is the Clean Core'?

(OK – shoot me for poor grammar – but I am a firm believer that to understand the ‘what’, you first need to understand the ‘why’).

What benefits does keeping the core clean deliver for an organisation?

• reduces Total Cost of Ownership
• ensures smooth and streamlined upgrades, as these occur in the core, so businesses don't get 'stuck' on a legacy release
• allows organisation to change and innovate, whether through the adoption of new standard functionality, or by providing a clean base on which to platform a changing organisation
• reduces business risk
• future proofs the solution for the journey to Cloud

?

How does the core get ‘dirty’

Given the historical provenance of these aspirations for implementing a 'standard' ERP solution, how is it, then, that we come across so many legacy clients with a lot of custom development even though most SAP programmes start with the best of intentions?

Most organisations build up a degree of technical debt over time. Some of this is justified, but in more modern implementations, should be technically architected in such a way as to separate the developments from the core (an approach not available historically):

• Non-standard requirements - for example industry specifics
• Processes which are differentiating for the client

However, some of this debt may also have built up for other reasons:

• A 'break fix' approach to issues
• A lack of knowledge about functionality that the system can deliver as standard
• Taking an IT rather than business-led approach to the solution

Cleanliness and S/4HANA: ‘dirt in the core’ or a grey area?

I have seen a lot of LinkedIn and SAP Blog posts discussing whether the WRICEF concept is dead (and indeed coming up with a whole range of alternative acronyms for how we should be looking at this area in modern ERP).

For the uninitiated, this acronym represents

Workflows

Reports

Interfaces

Conversions

Enhancements

Forms

(the stuff that typically isn’t delivered out of the box by SAP and usually requires client specific tailoring)

I agree that this feels like quite a legacy construct.?

In this article, I think the key area I want to focus on is the ‘E’ (Enhancement).

In the old days, this was simple enough – it represented ABAP custom code development.? However, in the world of S/4HANA, a lot of people seem to assume that Extensibility is the same thing as Enhancement (after all, it doesn’t even disturb the time-honoured acronym).? However, they are misguided in making this assumption… and to understand why, we need to dive a bit deeper, and understand what Extensibility actually is.

Extensibility in S/4HANA

In S/4HANA, there are two main types of Extensibility:

In-App

This is the 'Key User' extensibility above. Think of it as the 'Citizen Developer' role... something so simple that even I can manage it... very much akin to traditional configuration.

Side by Side

In the picture above, this is covered by the 'Developer' option(s). Traditionally this was handled by separate development on SAP Business Technology Platform (BTP); more recently, this has expanded to include the newer embedded ABAP functionality (something for discussion in a future article).

An example:

Historically, (in ECC days) when a client needed their CO-PA (profitability Analysis) solution to be set up, one of the first tasks would be to configure the characteristics by which they wanted to slide and dice their P&L (e.g. product hierarchies, regions etc). This was maintained through transaction KEA5 - and I never recall seeing this having to go through a governance process - it was just a normal part of the configuration setup.

In S/4HANA, with the move of this functionality to Margin Analysis, the same requirement, to add a characteristic, can be delivered through Key User extensibility (indeed, in S/4HANA Cloud, this is the only way to do this config). Using extensibility in this way actually delivers a number of further benefits - such as automatically adding the characteristic to standard reports and APIs (which traditionally would have required additional manual development and/or report configuration tasks).

Can we take all this cleanliness too far?

I have heard tales of clients deciding against the use of key user extensibility and/or extension of the coding block (ADCOCA if you want to get all technical) based around a ‘clean core’ argument.? I think this is a direct consequence of making the Extensibility = Enhancement assumption.? Given SAP’s directive that this type of extensibility can actually be a direct replacement for traditional config tasks, is there a danger that an application of the legacy WRICEF construct without first adapting it for a more modern ERP approach could leave clients in a worse position than they might have been historically from a functionality perspective?

To close, I will leave you with an equation – a simple mantra to implement by

Extensibility ≠ Enhancement

?

“Now, light up a Superking Menthol, make yourself a nice cup of tea, pull up a seat for a bit of a chat, and let me know your thoughts on the subject while I wait for the spin cycle to finish.”

* actually, I am not a smoker, but I didn’t want to let that spoil a good bit of EastEnders imagery