Are we missing an SAP S/4HANA® implementation phase?

Publish date:

Through the many years of ERP implementation, there has been a common language we have all used to talk about the project phase. With SAP S/4HANA®, is the game changing?

A long long time ago, in an office far way following a major SAP R3 win three youngish consultants sat down and worked out an SAP implementation methodology that would guarantee a good client outcome and make sure the delivery was controlled and managed well, this was in the days before SAP themselves had suggested an approach. We came up with a methodology with 5 phases and were amazed that our competitors that also had a very similar approach.

All the methodologies had catchy names and ran something along the lines of project preparation, buildprint realization, prepare to go live, go live, and run or discover, prepare, explore, realize, deploy and run, which are the SAP activate phases.

However, I am not sure this works for me anymore, I think there is another phase needed and one that is more important in getting the SAP S/4HANA  solution delivered and giving the benefits, you want.

Back in the day, we rolled up on day one, someone built the hardware, and installed SAP some people went on training courses, project organizations were announced, along with the development of a project charter and governance, and then we completed the phase with a kick-off meeting with the sponsors and possibly a few drinks and team building. The next day, we went straight into the blueprinting and then, if we got everything right, we would roll straight into build, test and go live in serial and structured way, of course there were sometimes overlapping phases, and increased use of agile and rapid visualization, etc. – but this is how we did it. Once the initial go live was secured, we went on to the roll out carrying our fit gaps and deployment or possibly adding additional functionality. The technology deployed was pretty much wall-to-wall SAP and there was a clear delineation between the team doing the support and the project.

I think the arrival of SAP S/4HANA and the intelligent enterprise has changed all this, especially in the larger more complex clients.

Firstly, the arrival of the standard core means the differentiation is outside of SAP and often delivered on other PAAS solutions that change more frequently, and may not all be SAP. Rollout no longer needs to site by site or module by module. It can now be app by app or process by process, with much more overlapping. In many large clients, there will be a phased retirement of ECC, at the same time as an SAP S/4HANA solution ramps up.

There is a lot more complexity in the deployment and in areas such as the provision of cloud services, security, and user registration, end-to-end process monitoring, etc. We will be living in a hybrid cloud world. New skills will be required far more quickly in the support teams and things may go live very fast – but perhaps for only a few functions.

The support teams will support the old and the new at the same time, with faster releases, more items going into back log as we may go live with an MVP, as the PAAS will be a heterogeneous, they will need a lot more skills and items such as BI may be totally revisioned, with some items going into the core, some into other products and some into the cloud.

I would argue that all this additional sophistication and perhaps complexity will require a new phase, which for the purpose of this piece I will call enablement. It will come after the project kick off and probably before blueprint and it will provide a layer or technology, architecture process, support, governance, etc. that will support the next build print phase of the project in whatever phase that takes.

It might well include the need to build new architectures, i.e. API layers, end-to-end monitoring, etc., a new approach to user registrations, new support agreements, training, etc.

I do think it needs to be a proper project phase and not just BAU, as it will require a team to be aligned around a common goal, a budget, recourses, and proper governance to make it a success. I would recommend it come after the preparation phase as you all need to agree why you are doing this before you start and set up the project office, budget and team.

Based on this new enabled layer, the deployment and build of the SAP core and the intelligent enterprise around it can take whatever direction it needs to, based on a series of sensible steps or business priorities, but this would be so hard without the enablement phase.

If you really want to get value out of your SAP S/4HANA deployment and continue getting value from it as you move forward, I think a little time on this phase might be a vital ingredient for success you can them move directly into rapid incremental build and deployment and the faster and more reliable delivery of value.

Contact me directly or visit one of our CoEs closest to you

Also, check out our SAP S/4HANA® Cloud for Automotive Suppliers offering which we have co-developed with SAP.

Related Posts

cloud services

Accelerating Digital Transformation through Low code

Joydipto Banerjee
Date icon September 7, 2020

In today’s fast paced environment, across industries, organizations are launching major...

Capgemini Invent

Ten ways to raise business performance with your SAP S/4HANA® journey

Markus Jakob
Date icon September 1, 2020

Organizations today are looking to renew their core business and drive sustainable growth...

automotive

Is becoming an Intelligent Enterprise your chicane?

David Lowson
Date icon August 12, 2020

Former McLaren CEO, Ron Dennis, said: “You don’t expect to be at the top of the...