ECC & S/4HANA: Deviance and scope

Using the power of Google, I found a ‘project’ defined as –

‘An individual or collaborative enterprise that is carefully planned to achieve a particular aim‘.

Placing this relatively apt definition in context of projects/programmes in the SAP ECC & S/4HANA world, I found something enlightening.

Reflecting on SAP ECC

In the world of SAP ECC, a project was easy to define. You knew the modules, you knew the places you would deploy, the method you would use (waterfall with a template), budget constraints, the resources available, why you were doing the project and the outcomes expected.

Several decisions were made before the project started, the scope generally bound by the systems you were replacing and outcomes you wanted to achieve. This defined the team that was needed, the workshops required etc.

This made it possible to turn up in the project room on day one with a pretty clear idea of what you had to do, albeit with a lot of arguments and flexing of detailed scope and revisit from time to time the project from a more technical lens.

Business change was generally driven from project deliverables in a similar linear fashion which is why managing such projects remained a challenge despite having concrete measurable activities.

Enter SAP S/4HANA

You’re figuring out the project, with tighter budgets, more nuanced skills but business benefit realization must happen in a shorter timeline. Things have already changed.

There are so many choices about how you solve issues, knowing that bespoking the hell out of S/4 is a clear no-no. Deciding BTP or other components, the use of SaaS products from other vendors, has direct implications on costs, skills, future business operations etc.. In the good old ECC days, decisions were almost binary, now almost unlimited possibilities exist on the ‘how’.

Implementation is no longer governed by waterfall. Flexibility with agile and Dev-Ops for bundling of components with smart tools to achieve business buy in and value trumps all. Binding the scope and the process’s you will implement tightly from the get-go isn’t viable. Business and technological disruptions are far too rapid to envision the next 18 months let alone the next 5 years, which was the darling of blueprints in the heydays.

S/4HANA ensured opposites compliment. A clean and standard core that delivers an overwhelming majority of your process’s, and the ability to deliver innovation and differentiation using the platform around it which can do whatever you can dream of. Business change occurs far more rapidly, hitting new communities quickly, maybe less location by location or module by module, but more process by process.

Summary

While much has stayed the same, budget and resource constraints, desired best outcomes, but the way you reach your aims is totally up for grabs. Effectively on ECC you could see exactly what was going on at all times in your project box, in the new S/4 world, it’s far more organic and flexible, but still needs to be controlled tightly else the investment is at risk. With a fixed budget what method would allow the flexibility outside the core, whilst maintaining the clean core? Over the coming weeks I hope to share my thoughts on how to deliver with these new approaches