Nowadays, organizations often rely on ERP systems to support their core business processes, i.e., ERP is their digital backbone. The most used ERP system in the world is SAP. And organizations using SAP will have a lot of work in the coming years. For example, because they will need to upgrade to the new S/4HANA version of SAP, or they may want to migrate to cloud infrastructure.
ERP and SAP systems are implemented by IT teams. However, for the acceptance (often including end-to-end testing) mostly key-users and operations & maintenance people are responsible.
In this blog, we will explain what it means for cross-functional teams, and the surrounding people, to implement, test and accept new versions of SAP implementations. And how to train these people.
ERP systems are the backbone of organizations nowadays
The time that organizations built their own bespoke IT systems, exactly aimed at what the organization wanted, has long gone. Today, it is most common to implement business processes using ERP systems.
ERP is short for enterprise resource planning, and these words don’t tell the whole story. ERP systems are now capable of covering all business processes within even the largest organizations. However, configuring these ERP systems is a delicate and complicated task.
SAP general structure
SAP supports business processes in several so-called main flows which are called lead-to-cash (for sales), source-to-pay (for procurement), recruit-to-retire (for human resource management) and design-to-operate (for production). Organizations use parameters to adjust the workings of SAP to their needs. Also, the SAP systems may be connected to other systems, for example, to a company-specific website.
This all brings challenges and risks. Any bottlenecks appearing in a live SAP environment can lead to a full stop of delivering services or goods to the customers, which causes all kinds of operational, financial, social and media impacts.
SAP implementations and transitions
When organizations work on SAP implementations and transitions, they mainly change the existing situation (Greenfield situations do not occur very often). Since SAP is often considered as “standard software” these changes commonly are not done by specialized IT delivery teams (with people with a wide variety of skills in cross-functional teams). Instead, the implementation is often done by a few (mostly external) consultants, who expect the business representatives, such as key users and operations & maintenance people, to do the acceptance testing. The consultants are often not familiar with the business specific circumstances, which poses additional risks of misunderstandings.
How can key-users and operations & maintenance people assess the quality level?
Usually, the key-users and operations & maintenance people are not professional testers. They do know a lot about their business processes, but testing changes to the systems and giving relevant information about the quality level requires specific knowledge and skills. To support them in finding the answers to the question of whether the SAP solution meets their needs, they need focused and proper training. For this reason, the TMAP certification scheme was recently extended with the training course “TMAP: Quality engineering for SAP”. This training course will educate them on the basics of quality engineering and testing, specifically focused on dealing with business processes that are supported by SAP systems.
Well-trained people can easily collaborate to the benefit of the organization
The key-users and operations & maintenance people don’t work in isolation. They will need to collaborate with the IT suppliers that implement SAP or related IT systems, and they will collaborate with their peers in the organization that actually use the SAP systems. By having the proper training, these people can better collaborate because they have an adequate vocabulary and skill-set.
What is your experience with quality engineering and testing in an SAP implementation? Please, let us know.
This blog has been co-authored by Rik Marselis
This is the latest blog in the series How to train cross-functional teams.
Here you find the second blog How to be a good cross-functional team member, the third blog Does every team member need coding skills, the fourth Five different ways to train a cross-functional team member, the fifth Challenges of agile at scale , the sixth Do cross-functional team members need business knowledge?, the seventh What’s the difference between training on-line and on-site?, the eight Solutions to the testing challenges when working agile at scale, the ninth Solutions to the testing challenges when working agile at scale - part 2, the tenth Three tips when working with teams with people from different backgrounds , the eleventh Social sustainability, the twelfth Three tips when working agile at scale the thirteenth Today’s teams need Roles, not Functions, the fourteenth How to train team members about business knowledge, the fifteenth Happiness is a key quality indicator for team members