ERP Implementation Considerations for SAP S/4HANA

There are obviously many flavours of Enterprise Resource Planning (ERP) solutions, and as an independent consultancy, Project One has no ties or alliances. However, given we work with a number of large organisations who are aligned to the SAP world, we have recently gained significant experience and insight from programmes implementing SAP’s latest offering, S/4HANA. 

 

As with most cross-functional and IT enabled programmes, these types of change are complex and often experience delivery issues. We’ve summarised our collective wisdom to bring you the key areas to avoid and mitigate with 25 Golden Rules. 

 

You might reflect that some of these are obvious – if so, why do so many organisations continue to ignore them or believe they can short-cut the fundamentals to start sooner or accelerate an already delayed programme?  

 

Have a read, and please so get in touch if we can help you and your organisation. 

 

 

Programme Ownership 

 

  • Start with a clear vision and ensure exec sponsorship, and critically, ownership of the programme of change before you begin. 
  • The move to S/4HANA should be business led – it is a Business Change project enabled by systems change. 
  • Invest in change management from Day One, but there is a big spectrum on this from ‘lift and shift’ for some, to fundamental changes to process and org/op model for others.  
  • Keep comms super simple, S/4HANA can become overly complicated and the business users can quickly become lost and disengaged.  
  • Invest in a network of internal Change Agents, Super Users, Adoption Leads to ensure uptake and support across the business. 

 

 

Business Data 

 

  • Data migration has proven to be one of the most consistent workstreams that causes most issues and delays across S/4HANA implementations. It is not a simple data migration route to move from ECC6 to S/4HANA. Have a clear definition and process for data migration, and proactively work out the potential root causes of data migration failure. 
  • A concept of data ownership and planning for data migration needs to be defined and agreed in the early stages of the programme. Legacy data is typically years old and has been subject to extensive customisation; the business often struggle to fully understand the business implications of the SAP data objects. 
  • Be very clear architecturally what the Master Data Objects are and where they are to be mastered, and how they will flow. Invest time to ensure people understand the difference between master/transaction data, and how they underpin business processes. 
  • From a business perspective, try to avoid having to freeze master data for significant periods of time – reliant on people manually tracking which is never sustainable or /controlled. 
  • Allow time to learn from early data loads and build in lessons ahead of completing subsequent rehearsals / migration to production. 

 

 

Programme Governance 

 

  • The Governance structure is most important, get it right to begin with, and stick to it.  
  • Get the right sponsors, right stakeholders and right level of communication all aligned and do not just assume they are.  
  • The definition of how decisions will be made, who can decide what, which is collegiate vs individual, programme vs business, should all be worked out at the beginning.  It will seem like an overhead but makes it much more straightforward later on. 
  • Ensure up front that governance, planning and decisions are openly shared and agreed where multiple business units are in scope. 
  • Ensure a business design authority is appointed and empowered from the outset. Although the end-point may seem a long way off for the business it is vital they engage at the outset to avoid costly errors and risk of re-work downstream. 

 

 

Scope and Sequence 

 

  • Ensure scope alignment with the vision and ambition for change. This means cross checking scope questions with the vision as the scope will inevitably evolve through the discovery stage.  
  • Be specific as scope has many dimensions, e.g. functionality, legacy systems, sourcing, business and/or geographic sequencing of implementation – decisions which will affect time and cost. 
  • Typically Finance goes first, however the finance function touches every part of the organisation so be aware of overly complicated interim states during a full roll-out. 
  • Rolling out a template approach for multi-site organisations has advantages, however many industry sectors and geographies have particular localisation rules which will amplify the desire or need for customisation – you must minimise this.  
  • There is no right sequencing answer for a multi-business and/or multinational roll-out, however do the analysis of pros and cons, involve the business stakeholders, and stick with the decision. 

 

 

Delivery Team 

 

  • Involve the wider business early on beyond just the business design authority. It’s important to plan for a shift from Programme ‘push’ to Business ‘pull’ as the programme gets into deployment phase. 
  • Ensure an ethos of One Team with shared outcomes and success.  
  • These programmes are long and tough and so investing in teambuilding and fostering a sense of shared purpose is well worth it.  Ensure both the Programme team and BAU staff are considered as key audiences within the overall Comms & Engagement strategy. 
  • Getting the right people involved at the outset is fundamental to success. It’s common for resources to change over the lifetime of the project, so attend to stabilising the core of the team and plan for succession of key people. 
  • Don’t assume business teams know their processes 100%. Moving to S/4HANA is a lot about unpicking deeply embedded processes, which have been left to their own devices for a significant period of time. 

 

 

Don’t all of these apply to every ERP implementation? 

 

Well yes and no! Each ERP implementation needs solid foundations before the more visible work is done. However, S/4HANA is not an upgrade from ECC6; it is a fundamentally different product based on the HANA database. Both on-premise and cloud solutions are available, and the latter will drive clients to adopt a vanilla solution. This represents a ‘once in a lifetime’ opportunity to re-design business processes to align with best practice. Real time analytics, enhanced revenue opportunities and IT simplification are all quoted benefits. 

 

Due to the likely significant process changes this must be a business-led transformation programme which is inherently complex and will need a multi-year lifespan to conceive, plan and execute. As said earlier, data is at the heart of a S/4HANA implementation; the mapping to the S/4HANA data model is not simple and the business often struggle to fully understand the business implications of the SAP data objects.  

 

A number of things to think about, all of which will require close management. At Project One, we have worked with several customers to help them select and then implement the most relevant and effective ERP platform. If you would like to discuss any of the above, or just have a general conversation about your transformation journey then please contact david.knappett@projectone.com 

Previous Insight

Are you looking for critical business transformation?

Let’s talk real change
Sign up to our eNewsletter

Get the latest news, relevant insights and expertise from our change experts

Marketing updates confirmation(Required)
Privacy policies confirmation(Required)