What Systems Integrators Don't Explain About S/4 Hana
[shutterstock_655887151]
Blog Security

What Systems Integrators Don’t Explain About S/4 Hana

With the clock ticking on the 2027 deadline, more and more SAP customers are preparing to move away from SAP ECC to S/4 Hana. And while years to ‘upgrade’ to a new system might sound like a comfortable lead time, it isn’t considering the level of change that is likely to be involved. Implementation of SAP S/4 Hana is anything but a simple swap between systems.

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:

  1. 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.

  1. 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.

  1. 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.

  1. 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.

Source:
Turnkey Consulting

About the author

Tom Venables, Turnkey

Tom Venables is SAP Security Architect at Turnkey Consulting.

Add Comment

Click here to post a comment

Sign up for e3zine´s biweekly newsbites

Please do not use administrative mail adresses like "noreply@..", "admin@.." or similar as these may get blocked for security reasons.

We use rapidmail for dispatching our newsletter. By signing up, you agree that the data you have entered will be transmitted to rapidmail. Please take note of their terms and conditions and privacy policy.termsandconditions.

Our Authors