6 pitfalls to avoid in SAP S/4HANA implementation testing
If you run your business on SAP, you’ll be aware of S/4HANA. It’s SAP’s new generation ERP software suite, launched as an on-premise solution in 2015 – with the broader cloud version following in 2017.
SAP has announced its decision to focus all future development work on S/4HANA and will be ending maintenance of older core SAP suites by the end of 2025. So, even if you’re currently running on an old core, such as SAP ECC or SAP ERP, you need to start considering your move to S/4HANA.
While the 2025 deadline might feel a comfortable distant horizon, as with any major IT change, time is of the essence and planning the move should begin now. Depending on your current SAP landscape, there are three main transformation scenarios:
- ERP system conversion, which is a complete conversion of the existing SAP system to S/4HANA;
- Landscape conversion, which consolidates the current regional SAP landscape into one global SAP S/4HANA;
- Wholly new (greenfield) implementation of S/4HANA.
The importance of testing
Testing is an essential element in all three scenarios. SAP, as it is widely used, is a complex system with both standard templates and customization relating to geographies and requirements. The impact of moving to S/4HANA on current and expected business flows must be tested at several levels. At Sogeti, we always draw up a comprehensive test strategy to define the testing approach for each migration.
There are six main testing pitfalls to avoid in this process to ensure that your end-to-end system migration is controlled across the complete application landscape.
- Insufficient documentation
Little or no detailed requirements capture at the outset is a common issue in any change project. How do you know what to test if you haven’t captured details of all the integration touchpoints (applications, systems, workflows, process and data flows, etc.)? I recommend bringing an SAP-specific subject matter expert (SME) into the team from the word go. This will ensure that your testing is prioritized on the test cases of most value because they understand SAP process language and will support the testing team.
- Solution architecture categorization
When moving to SAP S/4HANA it is vital to understand the business requirements on which the new solution architecture will be built. Without capturing this information at the testing requirements stage, it will be impossible to understand the test data you’ll need going forward in order to categorize your architecture. A change project is dependent on the solution architect and should always include one or more SAP SME to guide the testing and bring an understanding of the end-to-end processes under test.
- High test data volumes
Expect significant volumes of test data as you migrate to your new SAP S/4HANA landscape. You’ll need new test cases and scripts. What should you test – and when? If you’ve embedded an SAP SME in your project team, as suggested above, this isn’t such a big challenge. Why? Because they will draw on their experience of best SAP practice to utilize existing SAP data from within your system. As an indication of the volume of test data you can expect, Sogeti’s S/4HANA Business Assurance service utilizes a repository of more than 1,300 module-level and end-to-end system integration-level generic test scenarios and test cases for SAP S/4HANA.
- Minimization of manual testing
With so much to test in your new environment, how do you minimize text execution work so that it remains within limits? The starting point is to think about the potential for automation tools to reduce manual work effort and create a ‘lights-out’ testing environment. Automation should always be part of your test strategy to ensure that IT is able to respond to the increased release frequency and pace of change that are characteristic of today’s increasingly digital workplace. As an independent testing partner, Sogeti recommends an initial assessment of the entire applications landscape (not just SAP S/4HANA) to identify the most suitable automation tools. For example, we might suggest Worksoft Execution Manager, UFT or TOSCA, depending on the company application and tooling landscape.
- Test environment set-up in the cloud
Setting up your test environment in the cloud can be a challenge because you need to consider both the type of testing tool and how to ensure access from your own premises and from offshore. An on-demand testing model requires automation tools that can support on-demand/lights-out testing. In a hybrid landscape, you may be testing in the cloud and on-premise, leading to connectivity issues. So, your cloud test tool setup must be appropriate to overcome the challenges in terms of performance, data, application and test tools.
- Optimization of service costs
Costs – and how to reduce them – will always be a challenge, no matter where you are on your digital transformation journey. Using existing test cases is one way to optimize your testing costs. At Sogeti, we also create Regression Packs to ensure that it is cost-effective to publish standard testing templates from one country to another and reusability is high – enabling program or code changes to be undertaken to accommodate geographic differences. Execution machines enabling on-demand testing can be switched off so that you only pay for what you use. Without on-demand you may end up with multiple resources carrying out your testing, adding to the cost.
Although the move to the cloud is still at an early stage for many organizations, SAP’s decision to focus on its cloud-based S/4HANA solution sets the stage for wider cloud adoption. With this in mind, the availability of standard SAP templates will make the transition to S/4HANA manageable – albeit with the above challenges addressed.
Get in touch
To find out how Sogeti’s SAP S/4HANA Business Assurance solution removes the risk from your upgrade to SAP S/4HANA, please get in touch.
- Shashank KalloleManager, Sogeti India - Finland
+ 358 403-726-649
Shashank KalloleManager, Sogeti India - Finland
+ 358 403-726-649