“Not all those who wander are lost.”
J.R.R. Tolkien, The Fellowship of the Ring
I probably feel as many authors of travel guides now. Chapter 2 usually describes how you get to the country of your choice, but actually you would rather like to write about the country itself. I'm sure authors of books do not follow the sequence of chapters, but as I write in blog format I'm doomed for linearity ... 😉 But believe me it's not gonna be less interesting.
In the first part 1 of this series, being more of an overview, I mentioned already the key words Itinerary (Part 2a) and Route Planer (Part 2b).
Let's focus today on the Itinerary with the two main options Conversion (meaning you, travelling there) and New Implementation (meaning you or your partner giving birth to a new 'baby' in S/4HANA land).
"Should I Convert or go for New Implementation?"
When I hear that question, it comes with subtle tone of fear. As many travelers experience, fear is just lack of information. So let's dig into that.
Upfront, I've seen very rare cases, where you can give a straight answer right away on that question. Both ways come with have their challenges and it depends very much from the specific context and the IT-Strategy of an organization for the next years. So my advise is to take the time and gather the necessary information before taking the decision. And here I have some good news for you. A couple weeks ago the new version of the S/4HANA Readiness Check has been launched, with a number of improvements:
- the customer can actually run it by her-/himself. Only for the interpretation of the results I advise to pull in an expert, who can compare and consult on which way to take
- the check comprises now all checks
- it runs in the cloud and once setup, you
- can rerun it (e.g. after commissioning unused developments or bringing standard modifications back to standard )
- have an excellent dashboard, visualizing the outcome of the different checks
After mentioning all the checks and raising expectations that they will help you to take a decision, it's time to put some meat on the bone. In a nutshell the checks show:
- what challenges you have to handle on your travel to S/4HANA land in terms of
- Simplification Items
- Add-On & System Functions
- Custom Code
and
- how you need to size your infrastructure, which helps you when talking to your hardware vendor and building the business case
- which FIORI Apps might be relevant for you and
- which documents need to be processes before converting (Business Process Analytics)
Now one-by-one:
Simplification Items
Yes you guess is right, it is related to the simplification list. Namely, when running the check for your system, it will identify the items out of more than 470 entries, which are relevant for you and provide recommendations how to tackle them.
The items are categorized in:
- current functionality in S/4HANA unavailable, with sub-categories of
- equivalent exists
- equivalent on roadmap
- no equivalent
- Non-Strategic Function, with sub-categories
- equivalent exists
- no equivalent yet
- Change of existing Functionality.
From the discussion with customers let me here add a remark. The number of items has minor relevance. You really have to look into the items in detail, in order to judge the impact of a S/4HANA-Conversion.
Add-On & System Functions
This check shows separately for Add-Ons and Business Functions, which of them are compatible and which aren't. For the incompatible ones it needs to checked, regardless whether they are used or not
- whether a newer compatible version is available or
- how they can be uninstalled
Since there were Add-Ons and Business Functions created, which SAP is not aware of you might encountered also the status 'unknown'.
Custom Code
The Custom Code Check is a high-level analysis of customer developments against the simplification list and provides recommendations (link to the corresponding SAP Note), impact estimations and categorized the finding accordingly:
- usage of functionality not supported anymore
- semantically incompatible
- syntactically incompatible
- performance impact
This check helps you to plan a todo-list of code-modifications ahead of a S/4HANA conversion in order to eliminate possible shows-stoppers and unload the critical path of your conversion project.
For more detailed analysis please refer to this fabulous blog.
Sizing
This check does what it says. It will calculate based on your current system the memory requirements after the S/4HANA Conversion. Important information, though, when talking to your HANA-Hardware vendor. It will also tell you the potential for memory saving after clean-up and as goody on top list the tables by their size, so you get an idea about your heavy weights in your database.
FIORI App Recommendation
Since there are hundreds of FIORI-Apps and every one needs to be deployed and customized it is very helpful which of these Apps are actually of interest for you. Based on your current system usage this report creates a list of recommendations. The recommended FIORI apps are briefly explained and grouped by business role and relevance.
Business Process Analytics
Last, but not least important information for you business when approaching an S/4HANA Conversion. This check shows the transaction backlog, like open documents, which are overdue for processing. The identified items are grouped by document type and age.
For all items it needs to checked, whether they can be closed and archived in order not to migrate unneeded document in the conversion.
Awesome, what this travel check unveils for your journey to S/4HANA land, but again, I strongly advise to discuss the results with knowledgeable and experienced expert.
The setup-effort for the Readniess Check is rather limited (you find the implementation details here, namely in the End-User Guide on page 8). The preparation for the checks are simple and straight forward.
However, please note that the check classes from the notes, which need to be implemented, are subject of continuous developments and improvements. Latest with the availability of a new S/4HANA release, you should also replace the implemented check classes in your system with the new versions from the corresponding SAP Note.
Since we now know, which valuable information are provided in a single dashboard, I complete that chapter with two types of information, which are not part of the S/4HANA Readiness Check.
- Consistency Check of General Ledger Accounts and Financial Documents
It is a prerequisite in any S/4HANA-Conversion. For details check Note 1592904. - Business Scenario Recommendations
This check (available here) takes your system usage data (for the experts: extract from ST03N logs) and suggests per Line Of Business, who to make most use out of S/4HANA. You receive a pdf-document like this sample-report, which is great way to talk to your business stakeholders in your company about S/4HANA. It also comes with an executive summary, which has been much appreciated.
With these information in your backpack help you to decide about the pros and cons for either going for a Conversion or a New Installation.
Conversion
So far we have mentioned the two parts of S/4HANA land, S/4HANA on-premise and S/4HANA Cloud. But on the way there there are two famous intermediate stops, which make sense to give a closer look.
First Stop: SAP SuiteOnHANA (SoH)
SoH the first place, which was discovered on the way to S/4HANA-Land. It's simply explained: Take your current SAP ERP on any Database and migrate it on a HANA database.
In today's times, why would you first travel to SoH instead of taking a direct connection to S/4HANA? Only in particular situations I would advise today for a stopover at SoH. Here two valid motivations I came recently across:
1. Challenges with Infrastructure
Some customers migrate huge SAP landscapes with ERP, CRM, SRM, BW to HANA Databases with a complex deployment model, using multi-tenant capabilities of HANA in a virtualized environment of their Data Center. These customers first wants to get the foundation of their HANA-Infrastructure right, before they approach the functional giantleap of S/4HANA. Fair point!
Starting point in this case is a vanilla installation of Linux RedHat or SuSe on which the HANA database is installed. This approach is also called SAP TDI (Tailored Data Center Integration - find more here)
2. Urgency
... or to stay with travel jargon: out of fuel. Customers who have not applied for years
- Enhancement Packs (short EhP, providing additional functionality - so actually optional) or
- Support Packs (short SP, providing bug fixes and legal changes - so actually mandatory)
need to act quickly and want to bring their system on short-term notice on the latest version, without much of effort. This closes critical compliance gaps (with upcoming GDPR not to be underestimated), applies bug-fixes and improves maintainability.
In the meantime going to SoH became a standard service provided by SAP System Landscape Optimization (SLO), who have industrialized these kinds of migrations. Mostly done in a couple of months for a reasonable budget. In any case not to be underestimated, so I would not try it myself or to stay in travel terminology: Don't paddle yourself, but rather take the ferry. Risk of high waves and white-water!
The impact of the project
- for IT department:
- purchasing and deploying new HANA-compliant hardware (check SAP Note 1943937)
- upskilling of administrators for HANA Databases
- optimizing Custom Code for HANA (here, all you need to know)
- a few authorizations have to be adapted, to make use of new transactions (for details check the attached pdf in SAP Note 1761546)
- for End-users:
- some new functionality like the MRP Live (Transaction: MD01N) or the Line-Item Reports ending on H (like Transactions FBL1H, FBL3H, FBL5H, FAGLL03H ... for details check the attached pdf in SAP Note 1761546)
- depending on the gap of the upgrade step and the used functionality in SAP ERP, minor to high testing efforts
The sightseeings on SuiteOnHANA are rather limited in comparison to S/4HANA
- after optimization, many transactions run faster
- some new transactions available
- some transactions, which were due to high data volume not usable anymore are
back available (like Change of Installed Base - Transaction IP52) - faster backups, shorter batch job times
- reduced database footprint
Remark on the Business Case: In case you are one of the candidates for SoH, you might need input for your business case. Some customers may decommission existing databases and reduce by doing so their maintenance costs.
Next Stop: SAP S/4HANA Finance
Other customer go further but take another stopover before landing at the 'real' S/4HANA land: S/4HANA Finance. You might think: "Wait a minute! The sign says something with S/4HANA, why am I not there yet". Well you might compare it with Metropolitan areas like Paris or London. Just because the sign says 'London', it could be you just reached 'Greater London', it's still a 6 hours walk to 'Piccadilly Circus'.
So let me give you a map to picture it a bit better how much S/4HANA is actually in S/4HANA Finance.
S/4HANA Finance, formerly called simple Finance, is an AddOn to your SuiteOnHANA. It came with three versions:
- simple Finance 1.0
- simple Finance 2.0 (official version 1503)
- simple Finance 3.0 (official version 1605) will be also the last version.
Having introduced the version numbers here, a short comment on that. You might not dedicate too much meaning to it, but believe me it is key in the S/4 HANA discussions and has caused already some misunderstandings. Obviously the first two digits indicate the year of release and the last two the month. So here a brief overview
| S/4HANA FINANCE | sFin 1.0 1503 1605 [not to be continued] |
| S/4HANA on-premise | 1511 1610 1709 [new release every 12 month, so next one 1809] |
| S/4HANA Cloud edition | 1605 1608 1611 1702 1705 [new release every 3 month, so next one 1708] |
As you might notice, one digit can make a huge difference when discussing about S/4HANA.
I strongly recommend to indicate always the actual product when using the version number.
With S/4HANA Finance the finance data model within SoH is drastically simplified. The key word is Universal Journal which absorbs many existing tables, for all summary and aggregation tables, which were required due to technical constraints of classical databases. The two pictures below show this simplification (btw. ADOCA table corresponds to the mentioned Universal Journal).
So what could be a reason for this stopover, instead of travelling the last mile to S/4HANA? The reasons can be found in two areas:
- IT: The system remains on the old code line and get's only an injection with the new code line for the finance domain.
- less likely that AddOns and Business Functions will cause problems during conversion
- No reason to worry about vast majority of items in simplification list
- additional impact on Custom Code limited to finance related implementations
- Business: here the primarily reason is that mainly the Finance Department is in involved. This spreads business impact on Line-of-Business (LoB).
And what about the impact? H ere we see a longer list of aspects to be considered by your Finance Department
- although New General Ledger only needs to be activated technically, it is still the moment to check, whether or not to use it operationally (big topic, here the details)
- same is true for New Asset Accounting. You do not have to use, but it needs to be technically activated and a potential moment to go for it (also big topic, here the details)
- check needs to happen is all financial documents are consistent
- a profound testing period needs to be foreseen by end users
A complete list of what needs to be done, when going to S/4HANA Finance can be found here.
A typical misconception in the discussion is, that LoB Finance will not be needed in rowing on the last mile to S/4HANA land. Do not raise wrong expectations here. Since the system as such will fundamentally change when going from S/4HANA Finance to S/4HANA, the colleagues from Finance department will be at least needed for testing again and most likely also in the one or the other process re-engineering discussion. I strongly recommend to share that in the big picture of the roadmap when embarking to S/4HANA land.
To make all these wordings a bit more visual here an overall map of the travel itineraries. If you check flight radar of S/4HANA projects being live or in progress you will see the majority travelling the bold line, but again, there can be reasons why to take the stopovers.
New Implementation
If you decided to decommission your old system (be it SAP ERP or any other ERP) in your country of origin and give birth to a new system in S/4HANA land, most of the considerations above are not relevant.
Moreover you face a brand new setup with all pros and cons. While the itineraries for the conversion are straight forward, new installations require a thorough planning. For that we will use the already mentioned route planner called SAP Activate.
Since the scrolling bar has been heavily shrinking down already, I will take up this topic in a dedicated post.
Looking forward to your comments and questions. Enjoy your week.
Blog-Series:
- Travelling to S/4HANA land - Part 1 - Getting a taste of the country
- Travelling to S/4HANA land - Part 2a - Itineraries
- Travelling to S/4HANA land - Part 2b - Route Planer
- Travelling to S/4HANA land - Part 3 - Two regions in the same country: cloud & on-premise
- ... more to come ...
- SAP Managed Tags:
