SAP S/4HANA Vs.

SAP Suite on HANA

Between SAP Suite on HANA and SAP S/4HANA, some level of confusion still exist which I got
know after speaking with a large number of people. For those who are wrestling with the differences
between the two products let me provide some clarity. Before making any decisions it goes without
saying that it is vital to understand the contrasts in the journey to each product and their functionality.
SAP Suite on HANA
First came, SAP Suite on HANA. On SAP HANA the traditional SAP ECC solution is available as
the name suggested. The engine (database) is now a HANA engine although it has all of the
traditional functionality of an ECC environment. There is no concept of data simplification as nearly
all of the SAP transaction codes are available. To create real-time reporting one can access to
the HANA live studio. To utilize the HANA Database and provide additional performance benefits
the solution also boasts amended transactions.
On HANA the route to Suite to digest is pretty simple. From your current database to HANA it should
be upgraded to ECC6 Enhancement Package 7 and then a database migration should be
performed. Without too much business involvement this technical exercise can be achieved
(regression testing is a must).
SAP S/4HANA
A new product is SAP S/4HANA. Around the core ECC solution it is based. A number of
differences are there, however:
Simplification of the data has been done. Within certain processes into a single table by replacing
the core tables this can be achieved.
Due to the ‘principle of one’, some traditional functionality is no longer available after the new
functionality has been released.
With over 3000 CDS views currently available embedded reporting has been released. Within the
S/4HANA environment, SAP BW and SAP BPC can be embedded. Within the new product
S/4HANA enables certain scenarios to be performed– not all however; it will not replace BW or BPC.
Either by a system conversion from an ECC solution (including Suite on HANA), or a new install the
route to S/4HANA is achieved. From ECC6 to S/4HANA there is no upgrade path. With the reason
being to enable the new simplified data model a system conversion needs to take place. In order to
replace it from your existing system you need to be conscious on the lost functionality as part of the
move to S4/HANA.
SAP S/4HANA Versions
The on-premise S/4HANA solution is of two versions. With a simplified Finance module and full ECC
scope SAP S/4HANA Finance is the one which is Suite on HANA. Availability of this product is still
there and soon a new release is due.
Materials Management and Operations as well as Finance are simplified by SAP S/4HANA
Enterprise Management. By “S4CORE” “SAP_APPL” has been replaced which has a different
base component. In ECC there are modules which have been replaced.
Still there is an evolution of each of these products and therefore what you currently have in your
ECC solution may not provide all of the functionality you with certain Industry Solution functionality
which is not yet available. Within S/4HANA Enterprise Management Modules in the roadmap to be
simplified modules such as Production Planning and Quality Management are there. Although the
functionality will still be available within S/4HANA the HR module will not be simplified.
Following are the Comparisons of versions
Suite on S/4 HANA Enterprise
Functionality SAP ECC6 S/4 HANA Finance
HANA Management
Core SAP ECC processes Yes Yes Yes Yes
Core SAP ECC modules and Not fully due to principle
Yes Yes Yes
Funtionality of one
HANA Database No Yes Yes Yes
HANA live reporting No Yes Yes No
SAP Embedded reporting No No No Yes
Simplified Finance data model No No Yes Yes
Simplified Materials
No No No Yes
Management and Operations
SAP Fiori availibility Yes Yes Yes Yes
Some for
Optimised SAP Fiori Apps No Some for Finance Yes
HANA
Embedded BW No No Yes Yes
Embedded BPC No No Yes Yes
Not System conversion System conversion or
Route to new Solution Upgrade
applicable or new install new install
Not Not
System Conversion effort Low High
applicable applicable
Core Component SAP_APPL SAP_APPL SAP_APPL S4CORE
Not
Project Effort Medium High Very High
applicable

Tips for a Successful SAP Business Suite on HANA Migration

To reduce risk larger organisations are breaking their journey into several steps to SAP S/4HANA.
Upgrade of the core ERP system onto the SAP HANA database platform is the first logical large
step. To answer the question I reached out to my team: on HANA migration how one can ensure the
success of an SAP Business Suite? What I found out has been mentioned below.
1. A full-size production copy should be started with
This is a mistake to start with your first system as a development system, although it can be
tempting. As soon as possible on a real full-size copy you need to cut your teeth, because on a real
system only you will see how it is like to work.
The full database size should be included in a production copy, and for a cutover plan you have the
beginnings of the timings, on a simulation of production you can build a detailed run book based,
and the current code set (a different code-base to production is what the development systems
often have) is what you have.
2. Housekeeping should be started early
You don't want to be wasteful with database space if you have an in-memory database like HANA,
before you get to HANA start a spring clean and delete all the data you don't need as it is useful. It
cleans up hundreds of gigabytes, even terabytes of database typically as we have a standardized
process for this. 1.2TB in size housekeeping table was found in one client.
Housekeeping often takes 2-6 months to complete which is because of the amount of data that
needs deleting. A really long time can be taken by the clean-up jobs to run, and by being too
aggressive you should not impact business operations.
3. Burn in your production hardware
On Sunday at 4am when you cutover to your new HANA database, if it will be reliable is what you
want to know. Install the production hardware early, as a High Availability (HA) cluster configure it
and then for 1-2 mock migrations use it which is what we always recommend.
You could even use it for your first sandbox iIf it's ready in time, (see point 1). For some time prior to
cutover either way, you want it running, so prior to production migration any teething hardware
configuration errors are resolved.
4. In other infrastructure changes consider rolling
The number of test cycles is the primary cost driver of a HANA migration. To can improve stability
and reduce TCO you should consider rolling in additional changes because you will be thoroughly
testing it.
Including Linux Application Servers, VMWare, Unicode Conversion, Enhancement Pack upgrades in
the past we have rolled in all manner of changes.
5. The entire application landscape should be looked at
At the core of your SAP environment the Business Suite system exists and in the application
support area of your organization it will touch almost everyone. This means to update other areas at
the same time, like BW, Portals, or Solution Manager there is an opportunity.
Project management office, Basis, ABAP and Test Management resources are already available,
and compared to doing a separate update at a later time extending the scope is incremental.
6. Test Management Focus
Mature SAP R/3 environments have been in place for 10-15 years or more with many clients. They
had a solid test management process when they were implemented but there has been degradation
over a period of time, the quality and structure of test management.
The first step for organizations to get to S/4HANA is the SAP Business Suite on HANA and in the
years to come there will be more testing, so a good job of test management is what it really makes
sense now. As compared to business process your test coverage should be evaluated, ensure
where appropriate the modern tools are in place and look at test automation.
7. For custom code remediation use the right tools
Over the last decade within SAP environments, custom code has ballooned rather like test
management. Clients with 30-50,000 custom code objects are often seen, and there is no usage
of 30-80% of this code. For the 2009 year end close Reports were written and since then it has
never been run.
On HANA custom code remediation is critical to do, because by default your custom code will not be
optimized and to optimize the Business Suite on HANA SAP spent a lot of time. Severe performance
problems and issues with functionality can result in.
With tools like Custom Code Cockpit (CDMC), Usage & Procedure Logging (UPL) and
Clonefinder,SAP Solution Manager is the starting point for this, which help in understanding
custom code.
With tools like smartShift one can partner which from your existing system takes the custom code
and to automatically remediate your custom code applies a set of algorithms such as the cost
reduction, and human error.
8. Critical processes are identified and benchmarked
Your business users will expect lightning speed once you mention the word HANA. On HANA project
the expectations of a Business Suite will be high, and a lot of excitement will be there!
Those processes that are important to the business should be identified and should be
benchmarked. Some critical month end reports might be, but it was an approval mobile app in one
client’s case for promotions - C-suite executives is used by this app.
 Ensure they are measured as part of the test process once they are benchmarked today, and for
the HANA platform additional focus can be put on ensuring they are optimized. The communication
strategy helps this.
9. Early in place get the right project assets
To a Business Suite on HANA migration there are a few project assets which are specifically
important. In the project library it is recommended that you get this place, in a shared location
available to all, and regularly update them.
a. Run Book is the first, step-by-step guide to the migration and a few hundred pages it typically
spans. It means that, due to unforeseen factors if at the last minute you need to switch out
resources, to look after the next step of the project very experienced resource can be brought. In
addition to this it ensures that mistakes are less likely to be made at 5am on a Saturday morning at
the end of a long shift.
b. A set of project plans is the second option. 3 levels: High-Level, Mid-Level and Detailed are
recommended.

High-level plan: With the steering group it is used to communicate, and on it the milestones are
defined, so where the project is at a weekly granularity in PowerPoint can be seen by a C-suite
stakeholder.
 Mid-Level plan: Onto a large sheet of paper it is typically printed and can be read by human, so
progress can be understand by all project members; in Excel it is usually planned at a day-by-day
level.
 Detailed project plan: It is often several thousand lines long and is in Microsoft Project, and by the
Project Management Office it is updated.
10. An extended hypercare optimization phase should be added
Despite taking care with custom code optimization, test management and good planning it has been
ave found that between the cracks a few performance issues will fall and on HANA some processes
may be slower, because for a disk-based RDBMS they were optimized. In addition, than your old
database because HANA is so much faster, in the production system some processes will need to
be reshuffled, so batch Windows can be reduced.
Run an extended hypercare is recommended for both of these reasons. After month end a go-live
window is typically 1-2 weeks, rather than the usual 2-week window for 6-8 weeks after that it is
recommended to run. To capitalize on the benefits early this enables to take advantage of the HANA
platform improvements immediately and the existing project team is used.
11. Remember it is a technical migration
The Business Suite on HANA migration in most cases is a purely technical exercise.
Unlike S/4HANA where there will be a new UX (Fiori), process changes etc. On HANA you can get
onto the Business Suite and after that on the cool things like the Fiori UX, HANA Live etc one should
focus on.
What this means is with your timeline you can afford to be aggressive. Planning, testing and
executing still need to be done, but to move quickly is possible, and be averse to risk. For example,
in 8 weeks to HANA in the manufacturing industry we have moved a large SAP BW client, and to
HANA in 16 weeks a large SAP ECC client, including thousands of test cases and a large amount
of code remediation.
12. The following sun is considered
Across three time zones that operate as a single unit we have a cohesive, global Basis team. How
each other works they know, and a shared approach and document storage are there with them.
More than anything else, it accelerates the migration phases of the projects and has some cost
advantages. In addition, it means that it gives much more accurate early timings as even the first
migrations are run 24/7.