Why not after the transformation?
Let us get first thing clear, it is definitely not a good idea to push addressing Segregation of Duties (‘SoD’) AFTER SAP S/4 HANA transformation. Very simply, it can be very costly and resource-intensive, as it may require revisiting roles, responsibilities, and user access on top of ongoing operational activities to stabilize the new SAP S/4 HANA system. And it also means that you are operating with unmitigated risks in the interim – potentially exposing the organization to fraud and compliance risks.
Therefore, while it may be tempting to push SoD remediation after the SAP S/4HANA transformation to avoid delays and complexity during the migration, the risks of non-compliance and operational disruptions may outweigh the benefits.
So, let’s talk about whether we should address this as part of the transformation project or take the bull by horns and manage it even before starting the transformation.
SAP S/4 HANA transformation
A typical SAP S/4HANA transformation project involves several key phases, each with its own set of activities and deliverables. The transformation process can vary depending on the organization’s size, complexity, and industry. Some of the key activities include Assessment and Readiness Check, Fit-Gap Analysis, Role and Security Mapping, Testing and User Training.
When planning a transformation to SAP S/4HANA, one of the critical considerations is SoD, which one of the most important internal control measures in any organization. SoD ensures no individual has excessive and conflicting control over multiple steps in a financial or operational process.
As companies move from SAP ECC to SAP S/4HANA, integrating SoD into the project plan can enhance security and compliance. However, deciding whether to begin the SoD initiative before or during the migration can significantly impact the project’s success. This blog highlights some of pros and cons of both approaches.
Addressing SoD before the SAP S/4HANA transformation
Here are some of the benefits of starting with SoD even before the S/4 HANA transformation project starts in earnest.
- Proactive Risk Management: Starting the SoD process early gives businesses the opportunity to identify potential risks and conflicts before SAP transformation, making the transition smoother. Early intervention can prevent system access issues and ensure that roles are appropriately aligned both with business functions and SoD requirements.
- Clearer understanding of new SAP S/4HANA roles: With a proactive SoD assessment, businesses can map existing ECC roles to the new S/4HANA model, ensuring that role definitions are clear before they are implemented in the new system. This allows for a better understanding of how user access will be impacted in the future system.
- Avoids ‘distractions’ during transformation: Neither project team nor business users like to talk about SoD. And they want to focus on the functional and technical aspects of the projects and security aspects are often sidelined & often under-budgeted. Addressing SoD issues early reduces allows transformation project to focus on the business transformation without getting distracted by the security aspects, especially SOD which can be very time consuming.
However, this approach is not without its problems.
- Potential changes to SoD requirements: It is possible that the Assessment and Readiness Check and Fit-Gap Analysis may recommend major changes to the business process, potential impacting the SoD risk definition itself. In such scenario, a lot of rework may still be required during the transformation.
- Potential changes to current SAP roles: If SoD is tackled before the S/4 HANA transformation, the changes to roles and responsibilities in ECC might need to be revisited once the migration is complete, especially if S/4HANA’s role architecture differs significantly from ECC.
- Possible resistance from users: Early changes to SoD may encounter resistance from users who are familiar with existing roles and responsibilities, especially if the new processes are seen as cumbersome or restrictive. However, this will still be an issue during the transformation project if not tackled earlier.
SoD as part of the SAP S/4HANA transformation
Here are some of the benefits of managing the SoD as part of the S/4 HANA transformation project.
- Unified approach to SAP role redesign: Handling SoD during the migration allows the company to redesign roles with full knowledge of the S/4HANA system. This means that roles and responsibilities are better suited for the new environment, aligning with the simplified and standardized processes of SAP S/4HANA.
- More efficient resource allocation: Integrating SoD management into the transformation process means that the SoD effort can be more efficiently managed as part of the larger migration process.
- Minimized effort duplication: Addressing SoD during the migration avoids the potential redundancy of revisiting role design post-migration. SoD and role mapping are integrated into the transformation rather than being done in silos.
This approach is also not without its problems.
- Potential for delayed compliance: This essentially means that you live with SoD conflicts and the associated risks for a longer time, which waiting for the transformation to complete (and this can take years in some cases). Focusing on SoD during the transformation could delay the identification and resolution of critical access issues. Without an early focus on SoD, businesses risk exposing themselves to compliance violations or system access issues.
- Increased risk of errors and overlooked SoD conflicts: While designing roles within the SAP S/4HANA system, it’s easy to overlook conflicts or improper role assignments, which can lead to compliance gaps or security issues. If not thoroughly tested, the security architecture may not fully meet internal control standards.
- Increased complexity: Migrating to SAP S/4HANA is already a complex process. Adding SoD management in the middle of the transformation can complicate change management efforts, especially if employees are simultaneously adjusting to new software and role restrictions.
Conclusion
Both approaches have their advantages and drawbacks. Starting SoD before the transformation provides a proactive approach to security and compliance, ensuring that potential issues are handled early. However, it requires significant upfront effort and careful planning. On the other hand, managing SoD during the SAP S/4HANA transformation allows for a more integrated and system-specific approach but could delay compliance and increase the risk of overlooked SoD conflicts.
Ultimately, the decision should be based on the organization’s priorities—whether it’s a smoother, risk-managed transition or a more streamlined, integrated approach to role redesign in the context of the new SAP S/4HANA environment.