Many organizations have now started their journey to SAP S/4HANA or are currently in the midst of an implementation. It is important to integrate controls early in the implementation, rather than going through the effort of trying to incorporate these after go-live. This is referred to as a “design in” approach, opposed to a “retrofit” approach. Controls are integrated throughout the implementation and design decisions are augmented with real time controls input. Controls are verified with a specific focus in testing and training and confirmed with post go live reviews. With a “design in” approach there are less manual control activities, which reduce the burden on business stakeholders, and also the opportunity to leverage testing cycles already planned as part of the implementation to avoid additional effort from testers. Although this can be a cost investment in the beginning, over time it will save the company money in the long run by utilizing a risk-based approach to cover the applicable compliance requirements. The approach to the control design can align to any implementation methodology, which typically follows the hybrid agile methodology. Hybrid agile methodology takes the traditional agile methodology and mixes it with waterfall methodology concepts (e.g. build, test, deploy).
Hybrid Agile Framework
The main sections of the hybrid agile framework are program increment (PI) planning, sprints, testing and training, and deploy and support:
- PI Planning
- Identified features are placed into the product backlog
- These features are then broken into small pieces called user stories, which are placed into several sprint backlogs.
- Sprints
- Short time frames, or sprints, are used to configure or develop small, focused parts of the solution (user stories)
- Typically three to seven sprints (depending on small or large implementations), each one three to four weeks in length
- Each iteration involves a cross-functional team working in all functions: design, test, demo and build
- A working component is demonstrated to stakeholders at the end of every increment
- Sprints help minimize the overall risk and allows the project to adapt to changes quickly.
- Testing and Training
- System integration testing (two or three rounds) ensures testing coverage of end-to-end overall solution
- Execution of the UAT test scripts will validate that the business requirements are met
- End user training can be tailored to include user guides, live classroom trainings, WebEx and other available training platforms
- The project team can work to identify key stakeholders, departments and change champions who will help support the adoption of the new processes from the SAP implementation.
- Deploy and Support
- Key activities such as data readiness, data migration and mapping documents prior to cutover activities
- Hypercare support immediately following go-live to ensure any issues are resolved in a timely manner.
Life Cycle of a User Story
Before a user story can be placed in the sprint backlog, it must be estimated by the scrum team. Estimation should be completed by the entire team, particularly involving the business process owner and solution team. The solution team will own the final estimate. The score is measured using story points (e.g., Fibonacci Sequence) by weighing complexity, uncertainty and effort around the tasks required for a given story. Tools are available, such as planning poker, that allow the scrum team to anonymously vote on a score and discuss their reasons after the votes are revealed. Once the story is then scored and placed in the sprint backlog, it will follow development, testing, demoing and acceptance.
How to Design SAP Controls
Many organizations will already have a comprehensive risk control matrix (RCM) as a starting point. When a company is upgrading from ECC to SAP S/4HANA, a mapping exercises can be performed, while a new SAP S/4HANA implementation should follow a risk-based approach to identify new controls. The goal should be to increase reliance on SAP S/4HANA automated controls and automated compliance processes, minimizing reliance on manual controls. While designing the controls, the organization should consider enabling a top-down, risk-based centralized internal control framework and processes, as well as integrating dashboard reporting (e.g., a manual or IT-dependent control can leverage SAP Fiori Tiles).
The following are types of controls to consider:
These controls should then be placed into user stories and incorporated in the various sprints. When writing out control user stories, it is important to address three main sections:
“As a [role],
I want to [goal]
so that I can [benefit].”
An example of a user story with a control could be as follows:
As an accounts payable processor, I must not be able to post vendor invoices in SAP when three-way match (PO, GR and IR) fails or is not within the configured acceptable differences to properly process payments to vendors.
By looking at this user story above, Logistics Invoice Verification Tolerance Keys can be configured via transaction code OMR6, with various upper/lower amounts and percentages. The following keys are examples for three-way match:
- IR to PO line item tolerance key – ensures invoice line items are within the price tolerance when compared to PO line items
- IR to GR quantity tolerance key – compares quantity between the invoice to the goods receipt
- IR quantity where no GR tolerance key – ensures a goods receipt is entered prior to an invoice receipt.
How to Test SAP Controls
Before controls are tested throughout the agile project lifecycle, it is important to integrate controls as part of user test scripts. Adding controls in the test scripts ensures that the front-end is working as planned for the user. For example, with the three-way match concept, the user can see if an error/warning message is generated when invoice line items are above the price tolerance when compared to PO line items.
From a back-end perspective, we recommend an organization tests during integration testing, user acceptance testing and post go-live. An organization could have multiple rounds of integration testing, but it is key to ensure that controls are configured in the different environments. Make sure that control values are reflective as to what has been discussed with business process owners (e.g., tolerance amounts and percentages).
Client Story: A Fortune 500 Company Specializing in Tools and Storage, Security Services and Engineered Fastening
The goal of our project was to identify, document, and test business process controls during the client’s SAP Central Finance (CFIN) and multi-year S/4HANA hybrid agile implementation. The outline below summarizes the key steps taken during design and validation of the controls.
Design
- SAP Control Activity/Description Workshops – evaluated the SAP risk, control activity, criticality and categorization for applicability based on the company’s understanding of the to-be processes
- SAP Control Values Workshops – evaluated SAP control values for each control to define specific SAP settings to be considered as control benchmark and baseline
Validation
- Validation Testing – extracted the controls data from the target SAP environment during system integration testing (SIT), user acceptance testing (UAT), and post go-live. Analyzed control values to determine if in-scope SAP controls were set up according to the control baselines and summarized potential exceptions or changes to the configuration from the baselines.
In Summary
Whether the client’s journey is a net new SAP S/4HANA implementation or a migration from ECC, SAP controls should not be forgotten and should be a vital part early in the process. Project team members, business owners and IT leads should play an integral role to ensure automated and report-based (IT dependent) controls are optimized for the designed SAP application. The controls should also be placed into product and sprint backlogs as part of the PI planning activities to ensure proper design and validation of system functionality. This will ensure the overall success of the project and also assist with compliance (e.g. SOX) requirements.
To learn more about our SAP capabilities, contact us or visit Protiviti’s SAP consulting services.
