A few years ago, some consulting firms advocated ‘back to standard’. If it was not standard, it had to be removed: add-ons and custom codes had to disappear. Non-standard was evil. Some people, even to this day, treat going ‘back to standard’ as a positive action regardless of the content.
The truth is that initial SAP implementation often started at a time where Business Process Reengineering was ‘à la mode’ and lack of functionality mixed with such BPR often lead to custom specification being embedded in SAP system.
Then, corporation improved business processes not always for the best, but most of the time for good reasons.
I can see two reasons for going ‘back to standard’ and two reasons for staying ‘off-standard’.
Reason 1 – Back to standard
I remember a project with an astounding list of 2000 specific requirements. I joined as an integration expert just a few months away from going live. This company’s ERP had two key processes making a difference: Transportation in a cost-effective way, and Sales representatives’ incentives.
When going through the custom development, only 3 out of 2000 requirements were related to those key processes! Obviously, when custom development does not add value, getting rid of it is an improvement.
Reason 2 – Back to standard
Another obvious reason for ‘back to standard’ is when a new standard feature has been developed, making custom usages irrelevant. When moving to S/4, some changes will be mandatory based on which version of the S/4 HANA simplification list. As an example, moving house bank data from customizing to master data. You may question the benefits from such a process, but you will have to change your process and get rid of potential custom codes.
Reason 1 – Staying off-standard
When there is a ‘unique value proposition’ for this change. When the custom development is clearly a key part of your company differentiator. What makes you unique is probably not a software standard: There is no SAP standard feature for Airbnb.
Reason 2 – Staying off-standard
When you do not understand the business rationale for the custom development. Enhancing standard requires time and effort. There is probably a reason behind this investment. Before removing an enhancement, I would suggest an investigation into who has done it and why.
Life of IT systems is an ongoing movement
From my point of view, the life of IT systems is not a ‘back to standard’ approach. It involves an ongoing movement to business relevancy, ease of use, and cost efficiency. Standard is easier to implement and often the best option. But applying ‘back to standard’ across the board is not a reasonable approach. If you drive a car and move back to standard, you end up walking!
When going through an S/4 HANA implementation, you will be tempted to adjust to the company default model. But when should you revert to the default setting or replicate your legacy system?
SAP has a pragmatic approach: It’s your decision and you have options. It will probably make sense to embrace new functions, but you are entitled to keep existing features.
With some fanatic ‘back to standard’ approach, the ‘move to new (S/4) standards’ may involve some pitfalls – that stem from a lack of understanding of the current processes; especially when removing them.
Removing an existing process is the easiest thing to do: no need for replacement, design, or reflection. No one present to advocate the existing business process.
When you hear that ‘With HANA, volume is greatly reduced, and aging is a new process so you do not need archiving in your new system.’ – also question it. Again, you must first understand what and why you do not need to involve an archiving process as part of S/4 HANA conversion. Ask a subject matter expert to find out what could be the pitfalls and what could be the benefits for subscribing first to SAP archiving as part of your migration plan.
Happy road to S/4.
Because your data matters.
Thierry JULIEN, CEO and Founder of TJC Group
