Latest news

You can edit the content of this box by changing the 'description' custom option for the page or post.

S/4HANA Scoping Secrets and Hacks

Emily Kucukalic Tuesday, October 17, 2017 Blog

So you’ve read all that’s out there on S4…but you still don’t know how to start your migration. Sounds familiar?

In the world of S4H, there is soooooooo much information, on so many topics, that it’s hard to answer the simplest of questions;

  • Can my system be upgraded?
  • What is the functional impact of the upgrade?
  • What is the impact on my custom code?

The answers to these questions will provide fundamental decision points that you will need to address when developing your transition plan.

Getting the answers will require a little bit of effort, but it will mean that you can start to develop the details around your plan.

SAP provides some tools to help. Its useful to break these into two themes, namely; technical discovery, and functional discovery.

Technical Discovery.

Here, there are two tools which you should use immediately. The maintenance planneis a cloud-based application that will profile your system components. The maintenance planner checks the system with regards to OS/DB, business functions, industry solutions, and add-ons. If there is no valid path for the conversion (for example, the add-on is not released yet), the Maintenance Planner prevents the conversion. That’s right folks, it stops you dead in your tracks.

Now you can either wait for SAP to enable or change the no valid path status or you can start to plan for a re-implementation.

Then there is the custom code analyser. This is typically run from your development system and will perform checks of your custom code. You will need to load the customer code analyser (OSS note 2185390) and run the job, which then needs to be analysed in a system that has NW7.50 at a minimum.

These two processes will give you a technical insight into the migration path. You can even implement some coding changes to new developments to limit the changes required in future.

Functional Discovery

Just a glance through the 654 page “simplification document” will tell you that there are lots of changes across the board. Here, a lot of the impact will, of course, depend on your existing functional footprint.

The Simplification tool is a good place to start the discovery process (OSS 2399707). You can run this via Solution Manager or a standalone system, with a copy of your production data. The results will tell you which of the simplification items are relevant or not based on your system setup.

If they are ‘not relevant’ you can ignore the result.

If they ‘are relevant’, or ‘relevance cannot be determined’, then you need to check the classification of each item.

Here, they can be assigned one of five possible statuses. Any of these tell you that there is an impact waiting to be discovered. When this was run on our internal systems, it returned a 75/25 split between not relevant and relevant.

Digging a bit deeper, we can perform a more useful analysis. Rather than checking whether a simplification item is relevant or not relevant, you can compare the transactions you are currently using to the list of obsolete or impacted transactions documented in the simplification document.

You can also report on the user(s) who were running the transaction, and the frequency. This gives you a better idea of the change impact to help determine the extent of retraining/process change that needs to be performed.

Your system is already storing transaction history (ST03N) for a period determined by your configuration. Run an export program on this history and then compare it at a transaction/report level to the over 1600 redundant/obsolete transactions that are recorded in various SAP documents, allowing you to produce statistics of the impacted transactions, by functional area and by user.

You now have two pieces of functional analysis. The first lets you explore the design impact on changes in specific areas of SAP that are relevant. The second look at the end user impact changes based on profiling the usage statistics in your system against the list of redundant/obsolete transactions in S4.

Many users have, over time, become conditioned to the “it’s a technical upgrade only, I don’t need to worry” mode of thinking. This means that getting the end user impact analysis right is fundamental to successfully navigating a migration.

You are probably starting to think that the business case for an upgrade to S4 is going to look less like a technical, ‘leave it to the basis team’ project and more like a functional, ‘we need to engage process leads and change management specialists’.  And you would be correct!

We hope some of the secrets we have shared will help you scope out the start of your migration. We live and breath this stuff, so contact us if you want to know more.

Henry Fernandez

Henry is the Plaut Advisory Services lead and has been doing SAP stuff for close to 30 years. He is currently exploring a range of interesting technology developments and can sometimes be found in Plaut’s Sydney Innovation Hub.

Click here to get in touch with Henry.

Leave a Reply

Your email address will not be published. Required fields are marked *