Table of contents
- Deadline for migration to S/4HANA
- Testing in SAP S/4HANA Transformation Projects
- What are the reasons for testing failures in an S/4HANA Project?
Deadline for migration to S/4HANA
The move to SAP S/4HANA, the latest flagship business suite from SAP, is inevitable as the deadline of 2035 is fast approaching. These months will pass in the blink of an eye. The onlookers are slowly beginning to realize the gravity of the situation as the tsunamic wave of migrations from ECC to S/4HANA is getting to its epicentre.
But what has that to do with SAP S/4HANA migration projects and the enterprises looking to adopt S/4HANA?
Well, the more number of conversion projects, the more is the demand for workforce, which means more cost and less quality. Quality takes a toll during the testing phase which I, thus far, believe is the phase that decides the success or the failure of a S/4HANA conversion project. Things might seem fine during the conversion or re-implementation, but it will lead up to multiple production issues after Go-Live.
The move to S/4HANA could be through:
- System Conversion
- Greenfield Re-implementation
- Landscape Transformation
Testing in SAP S/4HANA Transformation Projects
But in all the above methods, the one common yet significant activity is Testing. SAP recommends Activate methodology for S/4HANA Projects.
Each phase of Activate has its own set of buzz words associated with it. For Discover, it is Value Scoping and Impact Study. Similarly, for Prepare it is Project Team Preparation and for Explore the words associated are Cutover Preparation and Design of the system. Coming to the Realize phase, the keyword associated is Testing, Testing, and only Testing.
SAP Landscapes, as we all know, are complex and the business processes are coupled in, out, around and beyond the standard functionalities. In such cases, we are talking about an enterprise which is in the beginning of its Digital Transformation journey. And, the disruption that S/4HANA brings to these landscapes is huge: technically, functionally, business process wise and also technologically.
So, this disruption requires careful compensation in the form of testing. A sustainable way to approach this would be through careful planning, strategizing and highly controlled execution and monitoring. Before we go into the ‘How’ part of testing, let's talk about the ‘What’ part.
What are the reasons for testing failures in an S/4HANA Project?
- Lack of Landscape Architecture Understanding (AS-IS to TO-BE)
- Lack of Knowledge about the processes or the process owners itself
- Improper Scope Definition between the testing and defect management Teams
- Piled up Conversations and Collaboration messages
- Improper identification of stakeholders and criticality of businesses
- Improper execution of plans and phase sign-offs
- Improper Monitoring and Reporting Methods
Phew, now let's try and understand what each of these means and how they can evolve themselves into Show Stoppers, Potholes, etc.
Lack of Business Architecture Understanding (AS-IS to TO-BE)
Why should someone even think about landscape architectures while considering the move to S/4HANA? It is important to understand the current to-be process. Basically, S/4HANA Conversion is process and data driven and not just a technical upgrade. For we know, the simplifications from S/4HANA cut across everything, right from field changes to process simplifications. So, a vision of the architecture design becomes inevitable during the test requirement phase or even during the assessment project you undertake before your move to S/4HANA.
Lack of Knowledge about the process or the process owners
There are a lot of things that can go wrong in a transformation project. An organization requires a clearly defined Business Process Documentation to start the transformation project. But, most of the times, organizations miss out on this critical factor. They do not undertake this study before starting the project. This could pose a serious threat to the transformation project.
Without the business process understanding, it would be nearly impossible to move into S/4HANA with so many simplifications.
Improper Scope Definition between the testing and defect management Teams
A proper end-to-end testing means we are talking about a BPML that has been running businesses for many years. An average sized enterprise may have around 1000+ processes, each having multiple test cases based on their data. When a RACI Matrix is drawn on the test management, it would make the system integrator accountable. The Project Health deteriorates severely only during the testing because of the involvement of the test engineering teams as well as business end users. So, a clear scope definition on the test items as well as the KPI Metrics is required. If not a plan, then at least a testing strategy is needed.
Piled up Conversations and Collaboration messages
The introduction of external business and testing teams brings along hundreds of email communications and issue logs every single day. So, a pile-up of communication data means improper test and defect management, which would eventually reduce the project health as well as the productivity of the consultants.
A conversation pertaining to a test case log or an issue log could give so much information about the entire project itself, like the criticality of the business process to be tested, type of defect, if the issue has been raised to SAP or not, aging of the Issue etc
Improper identification of Stakeholders and criticality of businesses
A transformation project testing does not mean a 100% coverage of the BPML items. It could also mean covering the items that are getting impacted and are critical to the business. This way, the project team can focus on what’s really necessary and get the test cycle done in quickly. But the second question now is,
“Who knows what gets impacted when the move to S/4HANA is made?” and “Who can estimate the criticality of the business processes?”
Thus, identifying the key stakeholders and the criticality of the business is very essential for the success of the testing phase. Why the business criticality should be considered is a whole different topic by itself which can be taken up in a separate blog where the v³ analysis would be covered.
Improper execution of plans and phase sign-offs
When we talk about plans and cycles, it involves what needs to be executed, when it has to be executed, how it has to be executed, who has to execute it, the entrance criteria and the exit criteria definitions.
Related custom objects, T-Codes, business processes, modules, WRICEF objects, standard functions, OSS notes, TR objects, etc. A lot of effort will be saved with the help of all these trivial information. Execution of test cycles also means they are directly linked to the phase closures and sign-offs.
Improper Monitoring and Reporting Methods
With huge data being generated every day across multiple workstreams, reporting would be a challenge with data accumulated in multiple places and across spreadsheets. There are several chances to miss out on critical impact items and thereby ending up with overhead issues in the long run.
The readers might now get an idea on what and how an unplanned testing affects the transformation project. The above problems can have multiple different ways of handling it. We’ll discuss more on how we can come up with suitable methodologies and frameworks to tackle them in the upcoming blogs.
With the kind of automation that KTern offers for system conversion, it’s time for you to get started with SAP S/4HANA Conversion rather than worrying about the complexity of the migration. Want to learn more about KTern? Look at our demo system or schedule a guided demo according to your available timeslots.