Validation and methodology
First, a procedure conforming to this was defined with the validation team based on existing documents and the general method for validating the customer’s computerized systems and discussed in detail as a team. The changed approach was heavily optimized, on the one hand, to satisfy the approach to a global template and to take into account the specifics of SAP or a complex, global system. Separate instructions were defined for central issues such as change management or user and authorization management, but also the handling of audit trail reviews, configuration and development or the data migration strategy. At the same time, the approach was also defined in such a way that the specific aspects of parallel roll-out projects and already parallel locations were taken into account, e.g. in the procedure for project change requests or for regression tests for live sites.
In addition to the aspects of validation, part of the methodology is the inclusion of project management and general requirements for the company, such as SOX requirements, in order to also meet tax authorities’ requirements without generating further non-integrated documentation in addition to the validation documentation. Among other things, a quality gate approach and procedures were established for tracking the status of all project deliverables.
Since the previous templates were also heavily redundant and more suitable for the introduction of simple systems, they had to be simplified and the redundancies replaced by central documents.
With the definition of the method, the project members were then trained in the method and are continuously coached.
Focus on the business aspect of documentation
When defining the design documentation, special emphasis was placed on the business orientation. This is particularly reflected in the definition of the various configuration elements from SAP, so that both the elements themselves as well as the rationale for their configuration is comprehensible. For this purpose, the definitions of the template were clearly separated from permitted localizations, including the use of corresponding namespaces to separate them. The focus on the requirements of the business can also be found in the test strategy, as the test of user requirements combined with the test of potential risks is the primary focus. Integration tests are also part of this, which ensure that business processes work end-to-end and at the same time reflect the day-to-day processes. They also form the basis for the regression tests and thus simplify the testing of future releases.
QFINITY provided support here, especially with regard to the review of the content, in order to achieve coaching towards a meaningful, clear documentation of the design that does not simply adopt the SAP standard but rather defines the specifics of the customer. With these defined customer specifications, meaningful and relevant user requirements can then be defined and tests can thus be focused on the configured processes rather than the SAP standard.
Introduction of SAP tools and validation of the basic system
Since the company was still strongly document-oriented, the advantage of introducing electronic change management was also demonstrated by QFINITY and the introduction of the SAP Solution Manager ChaRM process with the use of electronic signatures was also included in the project scope. QFINITY defined the process in the SAP Solution Manager together with the technical SAP implementer in order to make the process as lean and user-friendly as possible while complying with regulatory requirements.
In order to also support the SOX aspects, the SAP GRC (Governance, Risk, and Compliance) was introduced in the project, which allows the checking of roles and users with regard to Sensitive Access and Segregation of Duties (SoD). Appropriate technical controls were also implemented.
In addition to these specific tools, the SAP PO (Process Orchestration) for managing interfaces and SAP BW / 4HANA (Business Warehouse for reporting) as part of the S / 4HANA system landscape must also be validated before the actual business processes can be introduced in S / 4HANA . In order to handle this uniformly for processes in finance, supply chain management, production or master data management, an overarching business process list (Business Process Master List) was defined, which takes into account all processes of the system landscape, i.e. also processes such as change request management or access risk analysis (ARA) in SAP GRC. This is the basis for a GxP evaluation of the processes and the definition of process ownership for the various business processes in the company.
