Migrating to SAP S/4 HANA? Then automate what matters first

By Jeba Abraham, Practice Leader | Digital Assurance & Quality Engineering | Texas-West Division, Sogeti USA

More and more manufacturers are turning to SAP S/4HANA as a springboard for transforming production planning, supporting complex assembly processes, and optimizing operations. Yet, while the potential for efficiency and quality gains is very real, I would argue that without a strategic approach to test automation in SAP S/4HANA, there is a real risk of the transformation causing business disruption.

I am a firm advocate of automating strategically—one of the key principles in the SAP Testing Manifesto. Utilizing the power of automation prudently will add value beyond the traditional ‘regression testing’.

A mining and manufacturing organization’s SAP S/4HANA journey

That’s an approach that helped a large mining and manufacturing organization on its SAP S/4HANA journey. The company had multiple ERP systems as a result of mergers and acquisitions over the years, leading to a highly-fragmented landscape. Moving to SAP S/4HANA was a huge business transformation program designed to get all business units working as one organization, while bringing new planning and execution capabilities.

But this wasn’t going to be an instant wholesale rollout of SAP S/4HANA across the steel manufacturer’s many sites. Rather, the plan was to adopt a phased approach with a focus on how SAP S/4HANA could meet a specific business need, beginning with three steel mills in Europe. Then, if successful, SAP S/4HANA would be rolled out further afield.

Prior to SAP S/4HANA it was impossible for inventory in one mill to be aligned with the inventory in another. The manufacturer wanted to build cross-mill planning capabilities across geographies as one of the key outcomes of the program, ultimately resulting in faster delivery times for customers.

Addressing the data challenge

This would represent a new world of business underpinned by both SAP S/4HANA and cloud. A major program was rolled out to build different pieces of the solution that, in addition to SAP S/4HANA, included:

• Separate systems for parts of the end-to-process (such as transportation, procurement, configure price & quote)
• A CRM
• An adjustment to the legacy Level 2 Manufacturing Execution System (MES) layer

All of these needed to be integrated seamlessly with SAP S/4HANA. And here is where the program hit a stumbling block. That problem was data integration between the L3 and L2 MES.

Stainless steel comes in all shapes, sizes, thickness, and compositions depending on diverse uses across industries. Different alloys are used according to customer requirements—and each customer requirement is unique. The variant configurator within SAP S/4HANA was built with a complex set of rules on what permutations and combinations of the product characteristics were allowed.

However, when integration testing began on SAP S/4HANA, we discovered that an order worked for one product, but failed when a different product was configured. The integration testing failed because the variant configurator’s rules were not fully aligned with the rules that existed within the L2 MES application. As such, orders from SAP S/4HANA were getting rejected because the MES application said that such a configuration couldn’t be manufactured.

This wasn’t only an IT problem. Without the integration testing results for a wide coverage of variants, the business was starting to lose trust in the overall solution, putting the program objectives at jeopardy.

Automated analysis and parallel testing

We came up with an automated solution to carry out a form of parallel testing. By analyzing more than two years of sales—customers, product, characteristics, etc.—we finalized a set of 3000 sales orders that covered most of the configurations we wanted to include in the integration testing. These 3000 sales orders were recreated in SAP S/4HANA and sent to the MES system for integration testing. Our strategy was that if the MES system could accept the majority of sales orders with product variants that mirrored two years of production data in our ‘parallel testing’, then we could confidently say that the data integration worked.

Despite using automation, this process took time. However, it simply would not have been possible to replicate two years’ worth of sales orders manually. And without creating those orders in multiple cycles, we could never have achieved the same outcome. We had to analyze and configure the data to process the sets of orders. The testing was carried out in four cycles—pausing the order creation to painstakingly analyze all failures and fix the variant configurator rules before running the next cycle. It wasn’t just a case of regression testing and fine tuning, but of understanding the context as well.

This context is important. You need to consider why you are automating testing – the strategy. What business outcome will it deliver? In the case of this example, the outcome we achieved was the business assurance that there would be no business disruption due to data integration issues. But more broadly, automated testing would underpin the wider roll-out of SAP S/4HANA as the manufacturer pursued its strategy to transform operations by bringing together all business units on a single platform towards a sustainable future.