The right way to move to S4, do emotion/feelings/commitment  trump logic?

The right way to move to S4, do emotion/feelings/commitment trump logic?

"It is a capital mistake to theorize before one has data." - Arthur Conan Doyle, A Scandal in Bohemia. But I think he may be wrong in the case of S4

A move to S/4HANA is largely categorized in colours and terms (green, brown, yellow, blue, hybrid & technical) and current ECC users spend considerable time, money & factors for deciding the strategy of the move. While more commonly considered factors include –


  1. How complex the existing ECC landscape is
  2. The amount of bespoke code
  3. The number of instances
  4. How robust the existing system is
  5. The time to value
  6. What areas will provide the greatest benefit
  7. Detailed Code and benefits analysis


During decision-making on the right way to move to S4 I’ve found people don’t look at the more important strategic factors like – emotions, corporate memory and career enhancement and the stamina of the organisation to commit to a change programme in a changing business environment . The success of an S/4 migration is influenced at least as much, if not more, by these factors as it is by the rational, analytical technical ones.

I would say the single most important factor is the buy in of the CXO community , and maintaining this during the project

For example in any long greenfield journey to S4 the CXO of a company may decide to stop and pause as the client strategy has changed, or the financial health of the company is looking doubtful and the S4 programme is not seen as vital to the companies immediate survival. These are not points that can be picked up by endless analysis of the as it, the to be and the technical debt.


Technical/financial analysis are expensive, take time, generally provide evidence in support of a decision that most clients knew ahead of the study & rarely expound a definitive recommendation in an opposite direction. In the end, there always are pros and cons to the chosen route and possible regrets upon completion when not approached appropriately. So, any decision balances emotions and analysis to reason a ‘correct way forward’.


I suggest the analysis should be done pragmatically but viewed as a first phase of project setting budgets, starting the design, deciding architecture and not just working out the correct route to move.


I’m observing patterns emerge from the S/4 migrations corresponding to the success rates of the approach taken. The main issues aren’t technical alone & all approaches work equally well but there is a hierarchy of risks impacting successful completion.


  1. Technical migrations work! With a strong partner and plenty of rehearsals, I haven’t personally encountered a single failure yet, albeit a failure under 10% is possible (depending on the ask)
  2. Selective migrations where the solution is adjusted and changed when upgrading also almost always works! The reasons of failure are usually when clients cannot decide on what they want to move, what they want to and keep as-is, change their minds mid-way, or the migration rules become complex. The risk of failure maybe slightly higher than a pure technical migration but still very low
  3. A fragmented SAP estate migrating in small incremental extensions with S/4 roll outs in tandem seems to work well but is harder to deliver a complete S4 vision since all the moving parts must be co-ordinated. While it’s agile in smaller pieces, the risk is on realizing the complete vision from the onset
  4. Greenfield seems to have the largest risk. I see at least 50% of these projects change to either 1, 2 or 3 or are paused and waiting to restart


In summary, a MOVE to S/4HANA pauses/stalls not because the software doesn’t work, or the cutover fails. I see them pivot or pause because management commitment is lacking or changes during the programme. If you want to move to S/4, get on with it, do it fast and make sure the business is bought in. Only a huge level of business commitment for a short period will help, since you are replacing something that although not perfect works ok.


If you have decided that Greenfield is the correct approach, take a long hard look at your business and the sponsors. Anticipate their understanding of the program & their commitment in the long term when budgets may get tight or there is a call on time and resources that might be taken.


Maybe is you are moving to S4 and there is a good chance of success, sign up to a fixed price with a partner for migration or use a tool to selectively transform and migrate, and push on as fast as possible, with a clear vision to exploit the value of S4 once it is complete.


Sorting out the technical debt and heavily bespoke solutions after technically moving to S/4 or using selective migration tooling is not a cakewalk, but I think is a more solvable problem than holding greenfield nerves.


This is a personal blog and does not reflect anybody’s views but my own, so I welcome your feedback and other opinions.

 

 

Seemant Parth

Solution Architect: SAP S/4HANA: Enterprise Asset Management, Project and Portfolio Management, MRO & ETO

4 年

A good analogy, indeed. Simplification of technology has so many merits.

回复
Reza Rassuli

Founder & CEO of SDA - #1 Solutions provider for Vendor Invoice Management (VIM) & Source-to-Pay (S2P) - SAP AI Evolution Enabler, Unleashing the Power of SAP BTP for Your Digital Transformation advisory

4 年

Emotion on the side, this is not an IT project but a business project. As you said moving to S4H technically with the right SI is not the issue!

回复
Gavin Rugg

SAP Consultant for Sales & Service

4 年

Bought brand new in 2006, still the best car I've ever owned ?? Article is a great read and couldn't agree more with the opening points.

  • 该图片无替代文字
Mark Chalfen

Partner at PwC UK

4 年

I am not sure you can write off a Greenfield that quickly. If you know why you want or potentially need to move to S4, your approach will follow. If the programme is set up to achieve a goal and truly business led then a Greenfield can be the only approach and a team is focused on achieving a common goal. An example might be to take x% of cost out in a process or function. If the process and system are designed to achieve that you will find greater success in delivering the programme. Being able to constantly measure the goal and making key decisions around that goal keep the ship on track.

要查看或添加评论,请登录

David Lowson的更多文章

社区洞察

其他会员也浏览了