SAP HANA and S/4HANA – a simple guide (II)

This provides a significant step forward in the ability to customise the interface to specific roles and improve the user experience. It’s easy to see how having key figures and activities available at a glance could have a number of benefits.

Fiori comes with a number of SAP provided apps and organisations can also develop their own apps. For a S/4HANA conversion how much effort should be placed on Fiori? How many apps will be deployed? How much time will be spent on optimising launchpads for specific roles?

Implementation considerations

As with any ERP implementation or upgrade, a conversion to S/4HANA will be a complex project. SAP provides free training available on open sap:

https://open.sap.com/

In addition to training, there is a recommended roadmap. Between these, it’s possible to plan out all required activities. I’d like to highlight three areas of focus:

1. Business case considerations

As we’ve seen a S/4HANA conversion is like a hybrid between a technical upgrade and an introduction of new business features. With this in mind, what is the business case behind the investment? It could range between:  

• It’s a ‘must-do’ program to ensure we stay on the latest version, but we want to minimise cost and effort;
• It’s an opportunity to simplify our IT architecture, access as many of the business suite enhancements as possible and implement Fiori for all our users with our own apps. We want to invest a lot of time and effort and improve the way we work.

When considering the benefits, it’s critical to ensure that experts who understand the state of the current systems and current ways of working are involved.

In my experience the pre-sales and business case activities are often limited to senior management and architects, this can lead to an overestimation of the benefits that the users of the system will receive.

I’d recommend validating the business case with functional and technical experts. This may lead to an adjustment of the plan for improved scope, more refined focus and a more realistic project plan.

2. Preparation is critical

The recommendations and learnings which I’ve applied to R/3 and ERP upgrades also apply to S/4HANA. The biggest of these is related to preparation. Serious work should start 3-6 months prior to the start of the project proper. The work that should start early includes topics such as:  

• Master data cleansing
• Transaction data cleansing (i.e. ageing analysis)
• Ensuring that existing processes are understood and documented
• Ensuring that existing configuration is understood and documented
• Ensuring issues and problems are understood and documented
• Ensuring custom developments are understood and documented
• Ensuring the right resources are available for the project
• Ensuring the biggest pain points within the current process/system steps are understood and have been included in the scope consideration as part of the business case.

The majority of SAP projects run into problems in the requirements, fit-gap and testing stages because the current system and process were not well understood or considered or there were hidden issues. It’s critical to surface these early.

3. Involve the right people early

Typically a large organisation may run a global SAP upgrade/implementation something like the below:  

• A small team develops a business case with senior management involvement;
• A first project runs the upgrade for one business unit/country/region as a pilot and as part of this defines a global standard approach to the upgrade, the project is highly biased to one business unit/geography;
• The upgrade is then executed across different geographies/business units, they struggle with the design decisions made by the first unit;
• Within each individual project, the first stages start with the involvement of a small number of people and as they progress an ever-increasing number of people up to user acceptance and training activities with the full teams.

With this approach, the best experts and ‘real knowledge’ may not see the planned solution until user acceptance testing occurs. By this time it’s too late to change anything without major project delays. I’ve always disliked how user acceptance testing is included in traditional IT projects, it’s never a chance to accept a system works acceptably for a business, it’s often more an argument on whether the system works according to what was agreed and written down in previous project stages.

When you plan your project, look at the team staffing, from the very first phases:  

• How many of the team members have worked in your business operations?
• How many of your team members are middle managers?
• How many of your team members are external contractors or consultants that don’t know the details of your operations?

Free up your at least one operational experts from each in scope function and ensure they are involved from the start. Make sure the profile of this person is someone that will continuously socialise and gain feedback and input from their peers.

Final thoughts

There are still a lot of topics to be considered such as the details of the simplification list for each function and the impact on ‘add on’ systems e.g. analytics. However, hopefully understanding what HANA and S/4HANA are from an evolutionary and technical perspective makes it easier to figure out how it all fits together.

What aspects of understanding and planning SAP related work do you find most challenging?

This is also posted on my LinkedIn – https://www.linkedin.com/pulse/sap-hana-s4-alexander-roan/ And on my website – https://www.alexroan.com/category/technology/    

From: https://blogs.sap.com/2020/06/04/sap-hana-and-s-4-hana-a-simple-guide/