This is a blog post based on a presentation I gave at SIT Maidenhead this year.
I am Senior SAP Developer at the University of Warwick and we are in the early stages of a S/4HANA conversion project. For our well-established system, the step to S/4HANA represents a considerable undertaking and needs to be planned well. It also means that in a multi-disciplinary team like ours at the University, different team member roles require a different transformation of skills. Here, I would like to give you an early take from my perspective on what I see as the new key skill areas for a SAP Developer when faced with a S/4HANA conversion.
Please note that this is not a "How-To-Implement-S/4HANA-Guide", but a take from a SAP Developer perspective on what new topics and tasks may be lurking on the horizon for you. It is also a snapshot of my current understanding.
Our SAP system was implemented at the University in the late 90s. We are currently running Suite on HANA, which obviously takes the sting out of HANA-related ABAP changes, since these have already been performed as part of the upgrade to HANA.
For an envisaged S/4HANA on premise brownfield conversion, we have started to use an iterative sandbox approach (build->convert->test->scrap->build->convert->test->scrap etc). This means that several conversions will take place in order to acclimatise the team with the steps and tasks required in order to perform a conversion. This is helpful for the following reasons:
I'd like to stress the importance of the second point re data cleansing and tidying: it is important to realise that any of these changes need to be applied to all systems in your landscape. Eventually, the data related changes will need to be signed-off by somebody in charge in your organisation once these are to be applied to a Productive environment. Plan and include the timelines for this in your project plan at an early stage.
Once the team has sufficient knowledge and confidence with the new environment, User Workshops with key "Superusers" will be woven into the sandbox iterations. This will guide team members on which user group will require which set of functionality / UI (Fiori, Fiori Enhanced, UI5 bespoke, SAP GUI for HTML, Personas or good-old- GUI for Windows/Java). Moreover, it will start the dissemination of new features and create excitement about the opportunities of the upcoming new SAP release.
As Donald Rumsfeld once said, "there are knowns and unknowns". There are also "known unknowns". The importance here is to eliminate the latter through preparation and training. In terms of skills and tasks I would separate these into 3 areas: Basics, Must-Haves and Nice-To-Haves.
The first thing you should get your head around are ABAP Adaptations. You need to find out what the development effort is to adapt your custom ABAP code in order to make it work in the new S/4HANA world. For instance, Customers and Vendors have now been moved to Business Partners (customer-vendor integration, or CVI for short). Material numbers are now 40 and not 18 characters anymore. All this drives development effort and all eyes are on you to figure out by when you can get the system working again.
Tip 1: use SAP's own Readiness Check. This will give you a first flavour of what a conversion to a S/4HANA system in your landscape could be like. The Readiness Check dashboard (pictured) gives you a high-level custom code analysis.
The Readiness Check also gives you a good overview for other Business Process Analytics ("how many orders are not closed?" for instance), which can be a good conversation opener for functional colleagues in user workshops.
Tip 2: use a remote ATC check from a remote system (preferably on ABAP Stack >=7.52) to get the full picture on ABAP Adaptation effort. At the University, we downloaded the full list and then separated each of the findings into "easy" (0.25 days), "medium" (0.5 days) and "hard" (1 day) adaptations. This gives you a very crude total figure that will nonetheless make your Project manager very happy.
Tip 3: use data collectors as early as possible in Solution Manager to collect usage data for custom code in your Productive System. This will pinpoint any custom code which is not used at all. "Dead custom code" is a no brainer when it comes to retiring old code before you convert and adapt (Custom Code Lifecycle Management).
The above should give you some basic requirements and effort planning to get started. I can highly recommend the blog posts by olga.dolinskaja for ABAP Adaptations and ATC setup.
Let's get two things out of the way first:
But it's fine, because during the sandbox iterations it will help you to familiarise yourself and develop skills with Launchpad Designer, Fiori Apps Library and Fiori Frontend Server ("nuspeak" for Gateway) service enablement (transaction /IWFND/MAINT_SERVICE). When it comes to so-called KPI Fiori tiles (the ones with the fancy dynamic display), you also need to learn how to dig deeper and enable integrated BW components, for example, of the system to make these work.
I would also recommend to have a look at your current security concepts, since the new FLP-based world might force you to review some of the existing roles and authorisations in your landscape. My relatively early take on this is: if you are using a lot of bespoke authorisations with very granular restrictions then you might want to set aside time in your project plan to redesign this in the new S/4HANA world.
If Fiori apps can not provider your users with the luxuries they have become accustomed to then you have to dig a little deeper into your Fiori Enhancement box-of-tricks. This is likely going to include Javascript skills to understand and develop UI5, develop Gateway services. You may also decide to develop a completely bespoke UI5 app, use Personas or simply drop into SAP GUI for HTML when a Fiori tile is clicked. Further down I will talk more about the importance to know and differentiate between these UI options. In other words, a timely delivery of the S/4HANA project will also depend on your skills to evaluate effort to deliver on a user requirement needed on Day 1.
I can only scrape the surface of this HUGE topic here, but rest assured you will need CDS skills, because so many things cascade from this, such as:
Use SAP's own Help and Training materials to learn about CDS views. There is also a SAP Press book on CDS coming to a virtual or real bookshelf soon.
Having identified FLP and CDS as must-haves, we are now moving into the greyer area of nice-to-haves for Developers - if you disagree with some of my suggestions here, please leave a comment below as I'd love to hear more. These are mainly about UI and UX, helping me to help other team members to promote the system to users.
The first key skill to gain is to get a handle on UI options, by which I mean to become proficient in knowing when to suggest or use the multitude of SAP-based UI variations offered with S/4HANA:
The above list obviously represents a sliding scale in terms of development effort and skill levels needed. The point I am trying to make here is that it can be very helpful for a developer to know when to use which. As a consequence, this level of knowledge can be very helpful when it comes to project and timeline planning ("how long is it going to take you to rebuild a bespoke Goods Issue UI5 app?", for example).
Each time I observe end users interacting with S/4HANA, I notice that Enterprise Search appeared to be one of the feature highlights. It is not hard to see why: it is practically Google for the Enterprise and allows you to experience a SAP system in a very new way by simply searching for any keywords and receiving a quick response. This is a far cry from navigating around using transactions.
Developers should see this as an opportunity to promote benefits such as this to their end users. In other words, if there is a feature that makes SAP more popular, make sure it works and is responding fast. Also, look into any options to create your own Enterprise Search for custom business objects. For example, there may be a bespoke transaction which creates data in Z* tables. Why not create a custom Enterprise Search help to let users search for these, too?
On the whole, I would summarise my experiences thus far into the following points:
As mentioned in the introduction, my summary here is merely a first experience sharing exercise. It also represents a snapshot in time. I would be very to hear about your experiences or feedback comments below.
Thank you for taking the time.
I am Senior SAP Developer at the University of Warwick and we are in the early stages of a S/4HANA conversion project. For our well-established system, the step to S/4HANA represents a considerable undertaking and needs to be planned well. It also means that in a multi-disciplinary team like ours at the University, different team member roles require a different transformation of skills. Here, I would like to give you an early take from my perspective on what I see as the new key skill areas for a SAP Developer when faced with a S/4HANA conversion.
Please note that this is not a "How-To-Implement-S/4HANA-Guide", but a take from a SAP Developer perspective on what new topics and tasks may be lurking on the horizon for you. It is also a snapshot of my current understanding.
Background
Our SAP system was implemented at the University in the late 90s. We are currently running Suite on HANA, which obviously takes the sting out of HANA-related ABAP changes, since these have already been performed as part of the upgrade to HANA.
"our" S/4HANA OnPrem journey
For an envisaged S/4HANA on premise brownfield conversion, we have started to use an iterative sandbox approach (build->convert->test->scrap->build->convert->test->scrap etc). This means that several conversions will take place in order to acclimatise the team with the steps and tasks required in order to perform a conversion. This is helpful for the following reasons:
- it gives the team a more realistic view on timelines for build and conversion
- it prepares the team for any data cleansing or tidying tasks necessary
- it allows for increase the release level (first 1709, then 1809, then plus Feature Packs) and experience the benefits of an improving digital core
I'd like to stress the importance of the second point re data cleansing and tidying: it is important to realise that any of these changes need to be applied to all systems in your landscape. Eventually, the data related changes will need to be signed-off by somebody in charge in your organisation once these are to be applied to a Productive environment. Plan and include the timelines for this in your project plan at an early stage.
Once the team has sufficient knowledge and confidence with the new environment, User Workshops with key "Superusers" will be woven into the sandbox iterations. This will guide team members on which user group will require which set of functionality / UI (Fiori, Fiori Enhanced, UI5 bespoke, SAP GUI for HTML, Personas or good-old- GUI for Windows/Java). Moreover, it will start the dissemination of new features and create excitement about the opportunities of the upcoming new SAP release.
How to prepare as a SAP Developer?
As Donald Rumsfeld once said, "there are knowns and unknowns". There are also "known unknowns". The importance here is to eliminate the latter through preparation and training. In terms of skills and tasks I would separate these into 3 areas: Basics, Must-Haves and Nice-To-Haves.
Basics
The first thing you should get your head around are ABAP Adaptations. You need to find out what the development effort is to adapt your custom ABAP code in order to make it work in the new S/4HANA world. For instance, Customers and Vendors have now been moved to Business Partners (customer-vendor integration, or CVI for short). Material numbers are now 40 and not 18 characters anymore. All this drives development effort and all eyes are on you to figure out by when you can get the system working again.
Tip 1: use SAP's own Readiness Check. This will give you a first flavour of what a conversion to a S/4HANA system in your landscape could be like. The Readiness Check dashboard (pictured) gives you a high-level custom code analysis.
The Readiness Check also gives you a good overview for other Business Process Analytics ("how many orders are not closed?" for instance), which can be a good conversation opener for functional colleagues in user workshops.Tip 2: use a remote ATC check from a remote system (preferably on ABAP Stack >=7.52) to get the full picture on ABAP Adaptation effort. At the University, we downloaded the full list and then separated each of the findings into "easy" (0.25 days), "medium" (0.5 days) and "hard" (1 day) adaptations. This gives you a very crude total figure that will nonetheless make your Project manager very happy.
Tip 3: use data collectors as early as possible in Solution Manager to collect usage data for custom code in your Productive System. This will pinpoint any custom code which is not used at all. "Dead custom code" is a no brainer when it comes to retiring old code before you convert and adapt (Custom Code Lifecycle Management).
The above should give you some basic requirements and effort planning to get started. I can highly recommend the blog posts by olga.dolinskaja for ABAP Adaptations and ATC setup.
Must-Haves
Fiori Launchpad
Let's get two things out of the way first:
- you will enable A LOT of Fiori tiles
- you will troubleshoot QUITE A FEW Fiori tiles
But it's fine, because during the sandbox iterations it will help you to familiarise yourself and develop skills with Launchpad Designer, Fiori Apps Library and Fiori Frontend Server ("nuspeak" for Gateway) service enablement (transaction /IWFND/MAINT_SERVICE). When it comes to so-called KPI Fiori tiles (the ones with the fancy dynamic display), you also need to learn how to dig deeper and enable integrated BW components, for example, of the system to make these work.
I would also recommend to have a look at your current security concepts, since the new FLP-based world might force you to review some of the existing roles and authorisations in your landscape. My relatively early take on this is: if you are using a lot of bespoke authorisations with very granular restrictions then you might want to set aside time in your project plan to redesign this in the new S/4HANA world.
If Fiori apps can not provider your users with the luxuries they have become accustomed to then you have to dig a little deeper into your Fiori Enhancement box-of-tricks. This is likely going to include Javascript skills to understand and develop UI5, develop Gateway services. You may also decide to develop a completely bespoke UI5 app, use Personas or simply drop into SAP GUI for HTML when a Fiori tile is clicked. Further down I will talk more about the importance to know and differentiate between these UI options. In other words, a timely delivery of the S/4HANA project will also depend on your skills to evaluate effort to deliver on a user requirement needed on Day 1.
ABAP Core Data Services
I can only scrape the surface of this HUGE topic here, but rest assured you will need CDS skills, because so many things cascade from this, such as:
- Code Pushdowns (move processing from the application to the database layer, where possible)
- Gateway Service exposure (most of SAP's Fiori applications use CDS exposed services and so should your bespoke apps)
- Embedded Analytics (one of the cornerstones of why you should move to S/4HANA is enabled through CDS) - there is also a good introductory SAP Press book on this.
- Custom reports in Fiori Custom Analytics apps (helps you to move away from custom reports and to a world where users can model their own reports)
Use SAP's own Help and Training materials to learn about CDS views. There is also a SAP Press book on CDS coming to a virtual or real bookshelf soon.
Nice-to-haves for a Developer
Having identified FLP and CDS as must-haves, we are now moving into the greyer area of nice-to-haves for Developers - if you disagree with some of my suggestions here, please leave a comment below as I'd love to hear more. These are mainly about UI and UX, helping me to help other team members to promote the system to users.
UI Options
The first key skill to gain is to get a handle on UI options, by which I mean to become proficient in knowing when to suggest or use the multitude of SAP-based UI variations offered with S/4HANA:
- Fiori (ie "vanilla")
- Fiori enhanced (using so-called "hooks")
- SAP GUI for HTML
- Personas
- WebDynpro
- bespoke UI5
The above list obviously represents a sliding scale in terms of development effort and skill levels needed. The point I am trying to make here is that it can be very helpful for a developer to know when to use which. As a consequence, this level of knowledge can be very helpful when it comes to project and timeline planning ("how long is it going to take you to rebuild a bespoke Goods Issue UI5 app?", for example).
Enterprise Search
Each time I observe end users interacting with S/4HANA, I notice that Enterprise Search appeared to be one of the feature highlights. It is not hard to see why: it is practically Google for the Enterprise and allows you to experience a SAP system in a very new way by simply searching for any keywords and receiving a quick response. This is a far cry from navigating around using transactions.
Developers should see this as an opportunity to promote benefits such as this to their end users. In other words, if there is a feature that makes SAP more popular, make sure it works and is responding fast. Also, look into any options to create your own Enterprise Search for custom business objects. For example, there may be a bespoke transaction which creates data in Z* tables. Why not create a custom Enterprise Search help to let users search for these, too?
Summary
On the whole, I would summarise my experiences thus far into the following points:
- Plan in iterative cycles, sandboxes
- Include key ("super") users at the earliest stage possible
- Capture conversion issues early and plan these into your delivery
- Focus on the basics and Must-have skills listed above
- If you are about to deliver a lot of new code, also embrace new(er) paradigms like ABAP Test Cockpit (ATC), ABAP Unit testing and Test-Driven Development (TDD)
- Great topical bloggers to follow are: Jocelyn Dart, Olga Dolinskaja
- Get clued-up on embedded analytics and Enterprise Search
As mentioned in the introduction, my summary here is merely a first experience sharing exercise. It also represents a snapshot in time. I would be very to hear about your experiences or feedback comments below.
Thank you for taking the time.
- SAP Managed Tags:
8 Comments
