Skill requirements in an S/4HANA World

Skill requirements in an S/4HANA World

I’ll get to the topic of actually moving to S/4HANA later but for now I wanted to address the topic of skill set requirements after/during the move to S/4HANA as it really is one of the most common questions that comes up when I talk to customers about their S/4HANA implementation. Questions like:

“Will it all be in ABAP?”

“Do I need any extra skill sets?”

“What infrastructure will I need outside of HANA?”

“How do I approach my SAP development projects?”

So let’s take these in order:

Will it all be in ABAP?

The answer to this one of course is no. While the main system will of course be NetWeaver based, which is ABAP, much of the UI elements that will be delivered as standard by SAP will utilize Fiori – SAP’s answer to modern user interfaces on SAP.

Just to be clear though, I’m not suggesting that the bulk of your SAP support team will change. You’ll simply be adding a support/development function that can cope with, extend and develop in line with the Fiori paradigm.

On the reporting side, with S/4 (as with Suite on HANA (SoH)) you have the ability to create and utilize native HANA views directly on top of your transactional data giving you the ability to gain real-time reporting on top of your ECC system and that will require native HANA modeling skills rather than the traditional BW skills.

Do I need any extra skill sets?

Yes. But also likely no. What I mean by this is that, S/4HANA is largely based on SAP’s Fiori application set, where a large number of transactions have been transition from their SAP GUI based predecessors to web based, mobile responsive, web applications. These web applications are designed and built using industry-standard technologies in the form of HTML5, JavaScript and OData. So if your business has a web-development arm for either external or internal reasons then it is likely you already have the required skills to develop or extend interfaces on SAP.

The main SAP-specific skill required to support Fiori applications is that of SAP Gateway but any good ABAPer should be able to turn their hand to this with little/no problems.

For the reporting side where native HANA views can be created on top of your transactional data to obtain real-time reports, you will be looking at a SAP HANA modeler to unlock that potential.

What infrastructure will I need outside of HANA?

In general to run S/4HANA, nothing. Since the release of SAP NetWeaver 7.4, SAP have included the required components to run both Fiori and custom-Fiori applications right out of the box. That combined with HANA and the included XS engine, the sky is literally the limit when it comes to running and building your own Fiori-like applications.

But stepping back from the runtime and looking at the design-time and development flow there may be some requirements that could be considered alien to the native SAP developer. With SAP’s move towards truly web based user interfaces built with the best-of-breed web technologies you may find yourself looking to employ some of the management and testing technologies that are employed in that area. I mean technologies such as “Git” for source code management and of course 3rd party web UI test tools such as “Selenium”.

How do I approach my S/4HANA projects?

So this one is interesting. Traditional SAP projects utilizing the waterfall methodology would look to complete a lengthy design and blueprint phase followed by an even longer implementation phase. In my view, that is not an approach that should be taken when implementing or extending S/4.

The user MUST be put first. It is just that simple.

I started my career in SAP mobility where concepts like design-thinking and user-centric design were born so therefore it is no surprise to me now that we have to change our thinking when it comes to SAP projects in general. No longer can we produce process-focused solutions, we must instead analyze what the user needs and why they need it and then design them to be the best they can be for those users on each and every platform they may choose to use them on.

Our solutions must be designed to complement our users and aid them in achieving their goals in the most efficient and pleasing way possible. In a nutshell – we must approach our S/4 projects from our end-user’s perspective.

So there you have it, some of the more common questions around skill-requirements and approaches when considering a move to S/4HANA.

Obviously I’ve not covered a lot of these topics in detail above so please feel free to reach out if you have any more-specific questions.

Comments are closed.