S/4: First steps on the journey
Following my previous blog about the misalignment of views on what an S/4 project is, I’d now like to explore the approach SAP recommends, and specifically what is involved in an S/4 Sandbox or Pilot.
In this blog, read about:
- S/4: First steps on the journey
- Why does a Sandbox come first?
- What happens in my Sandbox?
- Your S/4 playbook is ready
The initial decision for organisations is whether to go Greenfield (new clean S/4 installation) or Brownfield (system conversion but much more), or for more complex cases a ‘Selective Data Transition’. The fantastic guide from ASUG/DSAG - ‘Mapping your journey to S/4 HANA - A Practical Guide for IT Leadership’* suggests that typically a business-driven project will be Greenfield, and an IT-driven project will be Brownfield. As outlined in my previous blog, it’s important to bring both parties into the discussions early, regardless of who’s driving the project. This isn’t a project that can be done in isolation by either side.
Get your S/4 Assessment Report
Our S/4 Assessment report can give high-level insight into the likely levels of effort of each approach, and early warning for any considerable blocks that may await:
- Number of Customers/Vendors without BPs linked
- Technical blockers e.g. Non-Unicode system
- Areas of SAP used by your system which are no longer supported
- Amount of custom code
- Visual Interactive Dashboard of the system to frame up internal conversations
But it’s important not to have to set a position early on, because your view may change as you gain more information about either direction. This is incredibly important to consider when applying for funding, otherwise you may find it very hard to turn back when new information comes to light.
Why does a Sandbox come first?
If you decide to investigate the Brownfield route further, SAP recommends doing a Sandbox four months before, and suggests you may need to do that conversion 2-3 times before you’re ready to start the actual project. Although that sounds daunting, a lot of the hard work will actually be done in the Sandbox phase, making the project itself simpler and quicker.
It’s important to understand from the outset that this conversion is not like previous upgrades.
S/4 is a new product line
Firstly, S/4 is a new product line. What SAP means by this is your existing licenses aren’t carried forward, so you need to discuss the costs of different options with your SAP account manager. While Greenfield would allow you to consider the S/4 Cloud or S/4 Cloud single tenant options, these are not possible with Brownfield or Selective Data Transitions.
S/4 needs replatforming: HANA 2.0 and Linux
The second factor that makes this so much more than previous conversions is a technical one. S/4 HANA requires HANA 2.0 and a Linux operating system for the database server. So you will need to replatform the system unless you are already running Business Suite on HANA, in which case you will probably still need a database upgrade. This part also has implications on hardware, since you can’t take just any server to use for the replatforming. A HANA preconfigured appliance or a server capable of going through the HANA TDI (Tailored Datacentre Integration) process are required.
S/4 functional rework before SUM
The third factor is a functional one. Before you can begin the Software Update Manager (SUM) process, you have to resolve a number of functional changes brought about by the simplifications in S/4. These are seen from the Simplification Item Checklist which forms part of the SAP Readiness Check 2.0. In some cases, the checks highlight relevant information (Relevance checks) but in some cases they are mandatory changes (Consistency Checks), where functionality in use is no longer supported. Understanding the impact of these not only makes the Sandbox project valuable, but may even cause you to revisit the Greenfield vs Brownfield discussion. And this is why the Sandbox comes first.
What happens in my Sandbox?
Before your sandbox is upgraded, you will load the SAP Notes to install the Simplification Item Checklist. In 1809 there are around 600 simplification item checks, with 40-80 expected to be relevant for a particular system. With S/4 some functionality from peripheral standalone systems like GTS is being provided directly in S/4, but replacing simpler ERP functionality from the same area. So anyone currently using the Foreign Trade functionality in ERP will have to move to the new International Trade functionality available in S/4**. But if you are currently running GTS as an add-on to ERP, it would have to be uninstalled before you begin the upgrade.
So as you can see, some of these checklist items are not simply applying a SAP Note or changing a config setting. They could trigger additional projects that need to be completed before the upgrade can occur. It’s also possible that the business might want to look at external solutions to integrate instead of moving directly to the SAP recommended functionality.
Chasing moving targets (versions and scope)
The important thing to understand here is that each S/4 on-premise release is bringing more simplifications. So potentially more major obstacles to overcome. But you are now not able to go to an older S/4 version than 1709. So the later you go, the more work there may be to get there. My personal view is that this is intended to accelerate the S/4 adoption SAP craves. I do find it odd though that a customer on Ehp8 and able to stay there till 2025 has versions which are now not available between their current version and the latest. That’s a new situation for SAP customers.
The Customer Vendor Integration (CVI) activity also has to be undertaken before the upgrade can begin. Although the process is not particularly time-consuming technically, it may open a whole can of worms when it comes to data quality and data cleansing – which may also enliven the business if they wanted to go Greenfield.
From a data governance and security perspective, although every Vendor and Customer must have a BP (and indeed Employee) the Customer/Vendor masters are not going away. The data is still duplicated in the same tables with no announcement yet if/when they will be removed.
Now you can Replatform and do SUM
With all these steps complete, we can replatform to Linux/HDB, or do that as part of the upgrade using the Database Migration Option (DMO). Although this project is mainly around working out the route to take, keep in mind the end project will probably need significant downtime, so this should be considered and noted in the Sandbox conversions.
The SUM process can then begin and those Simplification Item checks are also validated before the upgrade itself starts. Even with the checks all resolved, you may hit other issues which require SAP Notes to be applied to the system.
Check your custom code
Once the system has been upgraded, you can then leverage the ABAP Test Cockpit to start reviewing custom code. With the ABAP Eclipse editor, you can also leverage ‘Quick fix’ options where the change needed is something simple like adding ‘ORDER BY’ to a SELECT statement because the data is no longer sorted in the table. If you have third-party add-ons you will also need to check that they have a version that can support your planned S/4 version. This is a conversation you can start early, so that their correct version can be applied to the Sandbox when the custom code remediation takes place.
This might also be a good opportunity to look at Fiori and the Auth changes needed in S/4. There are a massive number of Fiori apps available, typically to provide much smaller functionality than the big transaction codes the business is used to. Check out the Lighthouse Fiori apps*** as a good starting point.
Your S/4 playbook is ready
The outcome of your Sandbox project provides the Runbook for your S/4 migration. All the major steps that will be required have at least been scoped, even if they have not all been carried out completely. The project itself will of course require a lot of change management, but at least the path to take and activities needed from a system perspective are clear. You can look to do the project more than four months before you really want to begin, but keep in mind the S/4 version you go to in your Sandbox must still be an available option when your project starts, otherwise there would be further simplification items needed.
This approach was taken with our EPI-USE colleagues for the Purdue S/4 project which has been nominated for the 2020 SAP Innovation awards****.
Relevant links:
* DSAG/ASUG document
** Blog on International Trade functionality available in S/4
*** Fiori Lighthouse Apps
**** The Purdue S/4 project has been nominated for the 2020 SAP Innovation awards.
Leave a Comment: