There is continuing debate on how existing systems can be remodeled for S/4 Hana, but the general consensus is that migration to the new suite requires a full redesign of an organization’s business processes. With such a significant change in how people work – and with S/4 Hana’s more open, digital core – security simply has to be a key stream in any transformation program.
Yet, when advising organizations on how to implement S/4 Hana, some systems integrators (SI) are promoting the use of best-practice roles and processes – essentially pre-configured protocols that can be loaded into the system.
The problem with this approach is that it doesn’t consider security at the point of design – which can have considerable consequences, not just for the migration project, but also business as usual post go-live.
Why security is a major factor in S/4 Hana migration
While it’s been designed to enhance and simplify the SAP user experience, S/4 Hana comes at the cost of increased complexity behind the scenes – particularly in the area of security and access.
In its cloud-based form, S/4 introduces a whole range of new security considerations, such as data encryption, certification protocols, patching, cyber security and more. With SAP Fiori, improved mobility is a major component of S/4, but this opens up organizations to many more routes into core business systems and data.
With S/4 Hana also promising integration with a wider variety of systems (such as SAP Fieldglass and Ariba), user access permissions will need to be more carefully managed than ever.
A delicate balancing act is therefore required. Access controls that are too restrictive could undermine the freedom and fluidity of the user experience, but less severe access to systems will increase security risks.
Pre-defined roles and standard segregation of duties just don’t go far enough to manage these new dynamics – and could mean users are able to access an enterprise’s systems without the right permissions.
‘Best practice’ isn’t always the best option
Using pre-configured roles and processes, organizations could design an entire system around best practices aimed at achieving efficiency gains – only to find that they have to go back and redesign their processes to ensure security is set to the appropriate levels. This can be damaging in a number of ways:
- Project overspend
The redesign of business processes will come with a sizeable budget. Doing it right from the start is expensive in itself, but fixing it close to the end of the migration project will cost significantly more.
- Missed deadlines
Having to rework business processes takes time, which may mean deadlines are missed – including that all important 2027 cut-off point for ERP support.
- Project rejection
Pressing ahead without implementing proper security could see a project rejected by external auditors, resulting in delays and extensive remediation work – also risking reputational damage for the internal project team.
- Data loss and downtime
In the event that the project proceeds without falling foul of auditors, there remains significant business risk as a result of inadequate security – with the potential for data loss, downtime and the consequential impact on operations.
Is security a focus in the S/4 Hana program?
While most systems integrators are undoubtedly experts in digital transformation, they’re not necessarily specialists in security. As such, not enough attention is paid to security in many S/4 programs.
Typically, a transformation or integration partner will be focused on operational efficiency gains, improved business performance and growth – yet the most effective business processes may not always be the most secure, unless they have been designed with security in mind.
Using pre-configured processes over a full redesign of security protocols is clearly a less expensive option too. And customers may not always be presented with security costs from their integration partners, because it is likely to inflate the overall S/4 Hana business case.
Any organizations that feels the security focus is lacking from their program, should consider challenging their SI partner for their views on security and fully engaging their own internal security team as soon as possible.
Security should be considered at the very outset of any SAP S/4 Hana implementation, not added retrospectively as a best-practice bolt-on.
It’s vital that the enterprise team takes ownership of the project, and makes it clear to prospective partners that ‘best practice’ might not be good enough when it comes to the vital issue of security.
Add Comment