Confirming Business Processes in a System Conversion
For a system conversion, the customer's sandbox system is converted first. After this conversion, the existing business processes need to be tested to verify they are behaving as expected. SAP Cloud ALM can be used to define the test cases and formally document each business process test has been completed. This process is described in detail in the last unit of this course, Testing Configured Business Processes. If issues are identified during testing, the tester captures this feedback directly in SAP Cloud ALM to create a running list of identified problems that need to be resolved.
Note
The SAP Fiori Launchpad and apps should be enabled before testing begins. This is described in Unit 4, Setting Up Systems for Implementation.
Business process testing can be divided into two sprints:
Sprint 1
Sprint 1 is the testing of current processes. The goal is to validate the business processes in the converted system are working as they previously did from a functional perspective. Some Fiori apps are mandatory to be used in the converted system as a direct replacement for the transaction code. However, most of the testing will be done through the classic SAP GUI or through the web GUI versions of the apps, which run in the SAP Fiori launchpad.
For example, in Order to Cash, the primary tasks are to review an open sales order and complete the pending documents. This involves creating the delivery, posting the goods issue, creating the billing document, and finishing the collection. This testing helps to confirm the conversion has not affected any of these business processes and the end outcome is the same as in the customer's old system.
Sprint 2
Sprint 2 is focused on identifying improvement opportunities. Think back to the SAP Readiness Check completed in preparation for the system conversion. There is a section that identifies the transaction codes the customer has been using (based on their actual usage data), and shows which SAP Fiori apps can directly replace those transactions. Later in the Prepare phase, it's recommended to run a dedicated workshop to review these new Fiori apps for different business processes in the sandbox system deployed for the Fit-to-Standard Workshops (usually the SAP S/4HANA Fully Activated Appliance). This workshop is described in the SAP Activate Methodology task, Run the Scope and Envision the Future Workshops.
Now, in the Explore phase, you should have already enabled the SAP Fiori launchpad and apps in the customer's own converted sandbox system, and the customer can experience some of their business processes with the new Fiori apps and their own data. Seeing their own data with the new Fiori apps can often help the customers decide to move toward using more Fiori apps, rather than the transactions in the classic SAP GUI or even the web GUI versions of the apps that run in the Fiori launchpad. The purpose of Sprint 2 is for the customers to decide to use as many Fiori apps as possible in their converted system landscapes.
After the successful conversion and testing of the customer's Sandbox system, the remaining systems can be converted with the same process used for the Sandbox system. If customization activities needed to take place in the Sandbox system to resolve issues identified during the business process testing, those same activities should be completed in the other system landscapes.
After the conversion of each subsequent landscape, formal business process testing must occur to ensure the business processes are behaving as expected in each converted system. Formal tests must be documented, and again Cloud ALM should be used to create the test cases and plans and have each tester document completion of the tests.
For more information, please refer to the SAP Activate Roadmap task, Additional Post-Conversion Activities in the Sandbox System.