among the teams and causes confusion over the ultimate ownership of the testing environment
The test manager should insist on a test environment where the testing team has complete control (for instance control over the accounting periods, running payroll, etc) and where the environment is not shared with other entities in particular during the test execution phase.
6. No controls for promoting/transporting objects into production
In many SAP projects that I have consulted for, there are very little controls for promoting objects into a live production environment. Other projects are very lax with their rules for promoting objects and have no means for auditing the approval process for transporting objects or do not include all the necessary stakeholders in transporting objects.
ERP systems like SAP R/3 offer benefits such as tight integrations across its modules and sub-modules and access to real-time data, but these benefits can backfire or even become otiose when a poorly tested or not even tested object is transported into a production environment. A faulty transported object such as a configuration change or code for an interface can have a deleterious cascading effect on other SAP functionality in the production environment. For instance a change to the HR module within payroll can affect functionality in the FI-CO module.
To mitigate the risk of transporting objects it is necessary to include approvals and set up a system of workflow where stakeholders from the testing team, Basis team, and configuration leads have input into objects that will be transported into production. A project should set priorities for transporting objects based on their criticality, document and approve objects that get transported after having been tested, and establish the frequency in which objects will be transported (i.e. every Friday at 4:00 pm) to avoid impacting end users as much as possible.
The company Mercury Interactive offers the tool Kintana which can help companies to move objects into various SAP clients and instances while maintaining a history log for auditing purposes of the objects that were transported and the entities approving the transports. Alternatively, I was a project where the organization created a home grown repository within Lotus Notes that provided managerial visibility for moving and transporting SAP objects which included notifications and approvals.
Whether a commercial tool is purchased or a home grown application is developed the main objective is to place stringent controls for moving objects into production with the necessary approvals while maintaining a history log.
7. Flaws with BPPs
For those projects adhering to the ASAP SAP methodology BPPs (Business Process Procedures) are artifacts or outputs from the realization phase. BPPs are documented based on stand alone or for single SAP transactions. The BPP provides detailed information in the form of instructions with screen shot print outs for how to execute a given SAP transaction (i.e. SAP transaction MM01–Create Material).
Admittedly, BPPs can assist a tester or end user on how to execute a given SAP transaction based on the project’s specific customizations. However, and this is often the case the SAP configuration team will document BPPs in a given environment such as the configuration environment with configuration data and then the SAP configuration team fails to update the BPPs to reflect the changes of the QA environment. The failure to update the BPPs diminishes their value for the testing team.
When BPPs are not updated they contain obsolete data, and may lack the necessary information to execute an SAP transaction for an SAP environment that has had customizations since the time the BPPs was initially created. Furthermore, many organizations do not perform any form of version control