SAP S/4HANA Cloud ou On-Premise - S4IC, revendeur SAP en Belgique
SAP S/4HANA: how do you choose between a cloud, on-premise or hybrid deployment?
SAP S/4HANA Cloud ou On-Premise - S4IC, revendeur SAP en Belgique

SAP Universal Journal – One Single Source of Truth

The Cloud compared to renting an apartment

The choice between the On-Premise and the Cloud version can be compared to the decision to buy a house to renovate using the latest technologies or to rent a fully furnished, equipped and secured apartment.  In the case of an empty house to be renovated (like On-Premise), it is necessary to provide capital to invest in renovation works and to ensure security in case of fire or theft. The advantage of being owner is that you can choose your furniture and appliances. You can also add as much equipment as you wish.  In the case of renting a furnished, equipped and secured apartment in a building (Cloud), you choose the apartment that suits you and benefit from all the advantages offered by the building management, such as surveillance cameras or concierge services. With the Public Cloud, you share hardware, memory, network equipment, and security framework maintained by SAP, just as you share utilities, the front entrance, or the building pool.  Migrating from SAP ECC or another ERP to SAP S/4HANA increases the options. S/4HANA offers the option of an On-Premise, Cloud or Hybrid deployment. To help you make the right decision, we have listed in detail the areas that will impact your organization. 

Features of Cloud compared to On-Premise

1. License 

The licensing model is similar to real estate management.   

As an SAP customer, if you buy the On-Premise software, you are buying a product. You own the software as an asset; you are in a CAPEX scheme.    

If you purchase the Cloud version, you are buying a service and do not own the software. You are in a subscription license model and pay an annual fee for the software as a service (SaaS), including maintenance and upgrades. This is called OPEX. 

2. Infrastructure

In the case of an On-Premise system, your IT team is responsible for the infrastructure. They manage the servers, the network, the storage, the operating systems. They ensure security and disaster risk. They have to plan the purchase, installation, testing, upgrades and security of all elements.  

With a Software as a Service, all of this is done by SAP.  

3. Reliability and security

The Cloud service provider offers the hardware and knowledge to apply the latest security measures. The Cloud significantly reduces the risk of implementing a new data system and helps companies, especially smaller ones, focus on growth.   

Some companies are reluctant to use the cloud for a variety of reasons. They have questions about ownership, leakage or control of their data. They have doubts about the level of security guaranteed. Yet only the largest companies can afford to hire top security specialists.   

A provider like SAP offers maximum security due to economies of scale. 

4. Flexibility

The Cloud increases flexibility. It means dependence on the Internet but independence from the office. Wherever they are, your customers and staff have access to your data centers, with access limited in function of your criteria. 

5. Upgrades

With any On-Premise version, upgrades are available annually. You schedule them at your own pace so you can better manage their impact on your business processes and organization. The logical downside of a slower upgrade is that you don’t get the latest innovations. 

In thet Cloud version, updates are quarterly or bi-annual and either automatic or accompanied by SAP. This formula allows you to reap the benefits of its innovations immediately. 

6. Customizations

The On-Premise solution and the Private Cloud Edition solution allow for a wide range of customizations, while the Public Cloud Edition solution offers a reduced set of functionalities. It is a template-based solution. The customer relies on the Best Practices of the line of business (LoB).

Main features of the On-Premise and Cloud Editions

Licence model 

SAP S/4HANA On-Premise Edition 

  • Traditional license 
  • Buy a product 
    • License purchase fee + annual maintenance fee. 
    • You are the owner of the license 

SAP S/4HANA Cloud Edition

  • Subscription license 
  • Buy a service
    • Annual fee for the license + SaaS + maintenance + upgrades. 

SAP S/4HANA On-Premise Edition 

  • Infrastructure, software, hardware.
  • Storage / operating system.

SAP S/4HANA Cloud Edition

No infrastructure, software or hardware.

SAP S/4HANA On-Premise Edition 

Your It department is in charge of the maintenance. 

SAP S/4HANA Cloud Edition

Outsourced to SAP  

SAP S/4HANA On-Premise Edition 

Security management is of your own responsibility. 

SAP S/4HANA Cloud Edition

Security management is supported by SAP.

SAP S/4HANA On-Premise Edition 

Defined and supported by you 

SAP S/4HANA Cloud Edition

Defined and supported by SAP 

SAP S/4HANA On-Premise Edition 

High adaptability level.

SAP S/4HANA Cloud Edition

  • Public Cloud: Configuration predefined by the Best Practices, with limited adaptability 
  • Private Cloud: High adaptability level, nearly like On-Premise 

SAP S/4HANA On-Premise Edition 

Unlimited variety of add-ons 

SAP S/4HANA Cloud Edition

  • Public Cloud: no add-ons 
  • Private Cloud: only add-ons certified by SAP 

SAP S/4HANA On-Premise Edition 

Maximum control and autonomy

SAP S/4HANA Cloud Edition

Easy and fast 

Some companies choose to remain On-Premise for the production entities and to regroup the financial and commercial entities in the Cloud. In this case, they apply the SAP S/4HANA hybrid model. 

SAP S/4HANA editions

1. SAP S/4HANA On-Premise

SAP S/4HANA On-Premise Edition works identically to previous versions of SAP ECC. There is nothing fundamentally new about how to implement it. 

2. SAP S/4HANA Cloud Public

SAP S/4HANA Public Cloud Edition, known previously as Multi Tenant Edition (MTE) or Essentials Edition (ES) is a Software as a Service (SaaS) offered by SAP. No non-SAP hosting is allowed. 

With SAP S/4HANA Public Cloud Edition, the customer relies on industries Best Practices. The deployment is a Greenfield. 

3. SAP S/4HANA Private Cloud

Private Cloud is dedicated to a single enterprise.  SAP S/4HANA Private Cloud Edition, known previously as the Single Tenant Edition (STE) or as Extended Edition (EX), offers more flexibility and control than the Public Cloud Edition. In addition, the Private Cloud Edition allows for multiple hosting options on SAP’s Cloud Platform, Amazon Web Service (AWS), Google Cloud or Microsoft Azure. The planned deployment for the S/4HANA migration can be Greenfield, Brownfield or hybrid. 

This table provides additional information about the features of the different options:

Customization and standardisation - SAP S4/HANA Cloud, on-premise ou Hybride

ON-PREMISE

PRIVATE CLOUD

PUBLIC CLOUD

On-Premise on customer's infrastructure

Dedicated system landscape on SAP Cloud infrastructure, AWS or Azure

SAP's Public Cloud infrastructure

PaaS

SaaS

Traditional/perpetual licensing

Subscription license

Subscription license

Governance by SAP customer

Governance by SAP & SAP customer

Governance by SAP

Highly customizable

Customizable

Standardized

Plan your own updates

Biannual (theoretically) Schedule your own update Mandatory every 2 years

Quaterly update

Greenfield, Brownfield or Hybrid

Greenfield, Brownfield or Hybrid

Greenfield deployment

Highest total cost of ownership

Low TCO

Lowest TCO

Can be reconfigured

Can be reconfigured

Cannot be reconfigured

SAP code and all other modifications are allowed

Does not allow the standard SAP code but allows all other modifications

Does not allow the creation of specific programs in ABAP and does not allow to

Allows extensions ;

Allows all add-ons ;

Can add code

Allows only add-ons certified by SAP on the Cloud ;

Can add code

Does not allow extensions ; Impossible to add code

Many large enterprises are turning to the Private Cloud Edition because of the advantages of monitoring, flexibility, customization and security it offers. The major argument in favor of the Private Cloud Edition is the ability to retain the existing configuration and transaction data with a selective data transition. 

However, the combination of SAP S/4HANA On-Premise and Cloud could be a preferred option for large enterprises due to their organizational structure. It also allows to phase the migration and to benefit more quickly from the advantages of S/4HANA.

How can we help you?

If you need advice or clarification on SAP S/4HANA matters, please contact us. We provide consulting to companies who are considering SAP ERP implementation or migration to S4/HANA. 
Share

Copyright S4IC – 2021​

Data migration : a high-risk phase in an SAP project, by S4IC, SAP partner in Belgium
Data migration: a high-risk phase in an SAP project! How to avoid errors?
Data migration : a high-risk phase in an SAP project, by S4IC, SAP partner in Belgium

Data migration: a high-risk phase in an SAP project

It is a decisive stage in any migration to SAP S/4HANA. Data migration is a fastidious task, requiring a great deal of effort from project teams, as well as from business users, who have to validate all the data that will be fed into their new ERP system. In this critical phase, it’s important to avoid amateurism and opt for industrial solutions.

Broadly speaking, there are 4 main types of SAP migration that require data migration. The one that was initially recommended by the publisher, the Greenfield, with the implementation of already existing Best Practices. And the alternative, which is the migration of choice, the hybrid migration (or Data Selective Transition, the official term used by SAP).

Finally, there are circumstances of transformation or reorganisation that require a reinstallation, and obviously the new SAP installation. For these 4 types of migration, the company will have to transfer the data from the old system to the new one.

In SAP, there are data fields whose content is completely free, but there are also fields whose content is structured: these are known as ‘Drop Lists’. These can be configuration points such as VAT codes, payment terms, etc. or basic data (item, customer, etc.) on which documents, such as invoices, are encoded. The basic data is managed by the company. The configuration data was created when the system was installed and has often evolved to meet the specific needs of the business. Depending on the migration scenario, all or some of the values in these fields change, and these changes seriously complicate each SAP migration.

If the company opts for a Greenfield migration, the team in charge of the migration will have to find correspondences between the values used in all the choice lists of the old system and those proposed in the best practices of the new system. The conversion effort required to complete this transition can be considerable.

In the case of hybrid migration (the Data Selective Transition), certain elements can be retained and others will have to be rethought, depending on what the company wants to modernise during the migration.

The choice of approach does not exclude the removal of all obsolete data, such as old establishments, old VAT codes, etc. Implementing SAP S/4HANA also involves mapping all the fields to be migrated with those in SAP. Here again, this scenario suggests that it will take months of effort to complete this work.

The secret of a successful migration: the SAP Data Dictionary

Advices for a successful data migration project, by S4IC, SAP partner in Belgium

To successfully complete a migration, the data must be processed exhaustively. It’s a colossal task, but the project team has an ace up its sleeve: the SAP Data Dictionary. In simple terms, this is a database that stores all the tables and fields, along with their characteristics. For each field, it is possible to find its reference table if it exists. Using this repository, you can immediately find the changes made by the company to its ERP, identify the drop lists and list the possible values. Extracting the data enables us to check which values from these drop lists are still alive, i.e. still being used in the processes in place. For example, if there are 3,000 payment conditions modelled in the ERP, only 25 of them are actually in use. Migration is the ideal opportunity to clean up all this obsolete reference data.

The advantage of an approach based on the Data Dictionary is that it can automate all these checks and provide the project team with all the fields and values that require a decision to be made about their future. Another advantage is that we can work on real production data and therefore on the real configuration of SAP and its processes. We can systematise checks on absolutely all drop lists. It’s an approach that avoids unpleasant surprises. When you carry out a traditional data transfer, these values are identified after the analysis phase. You end up with a lot of unknown data that has to be analysed afterwards. Some of this data can have an impact on entire processes.

Industrialising the migration process is the key to success

In this migration methodology, you need to identify the objects that are going to be migrated, such as production orders, orders, suppliers, etc. You need to define how to extract all this data, and plan the mapping of these objects with those in the new system. You need to define how all this data is to be extracted, and map these objects to those in the new system. If the source system is SAP, having an ETL capable of reading all the tables and checking the data structures will be a key asset. If this is not the case, the mapping will have to be done manually and all the source tables and their equivalents in the target SAP system will have to be found. We will then look at the contents of the tables, drawing up a list of the values found for all the Drop Lists. The project team can then work on this data and decide whether to keep, modify or delete it. These transformations can sometimes be very complex and require code to make the necessary adaptations. It is the business users who will decide what to do with each piece of data. In this phase, you need to work on complete data and not on samples, before starting to think about data transformation.

SEAzam et SEAmapp - Data migration

If one key point is to rely on an ETL to carry out all the extractions, another key point is to ensure the right transformation tool. When several million records need to be migrated, using table view transactions or writing extraction programs is a waste of time, and office tools such as Excel or Microsoft Access are no longer sufficient. Cutting files into multiple fragments is just a last resort. When there are 25 conversions to be carried out on a single table, it quickly becomes impossible to manage correctly. Today SAP has more than 30,000 tables, and even if we’re far from using them all, we absolutely must banish all home-made approaches to data processing.

In a project to migrate to SAP S/4HANA, the team in charge of data migration will carry out the entire migration several times. There will be one migration to fine-tune the tools, one or more migrations to run the configuration tests, to enable user training, plus one or more ‘dry runs’ to check that data loading goes smoothly on D-day. Generally speaking, an SAP migration project involves between 3 and 5 data extraction/transformation/loading phases. To avoid inconsistencies and blockages, it is essential to automate these operations. It is totally unrealistic to expect to repeat such complex operations 5 times or more using Excel without making mistakes…

What’s more, you need to bear in mind that in large companies, an SAP project can be spread over several years. Between the time when the consultants put the first conversions in place, and the time when the migration actually takes place, a lot of data will have evolved. Data migration is a constantly evolving process. With each extraction, we can be confronted with changes. This is all the more reason to use tools and automate data migration as far as possible.

Are you planning a data migration project?

Share

Copyright S4IC – 2021​

Data Selective Transition, by S4IC, SAP supplier in Belgium
SAP S/4HANA migration: what is a Data Selective Transition?
Data Selective Transition, by S4IC, SAP supplier in Belgium

SAP S/4HANA migration: neither Greenfield nor Brownfield!

The deadline for migrating legacy SAP systems to SAP S/4HANA is approaching. According to the Enhancement Pack installed, by 2027 or 2030, ECC 6, the ERP of many European companies, will no longer be supported by its publisher, SAP. We need to be prepared to migrate, and there are much more effective alternatives to the Greenfield approach.

Deploying SAP S/4HANA because you are forced to by the end-of-support schedule is certainly the least good reason to migrate. On the contrary, you should take advantage of this generational change to modernise the processes that drive your business, so as to benefit from the technical innovations of this new version. It brings a powerful ‘in-Memory’ database and a host of functions that did not exist in SAP ECC 6. However, migrating a system that has been in production for 15/20 years is no mean feat, explains Alain Rivet, financial consultant, project manager and architect at S4IC :  « Most SAP installations are now over 15 years old. In that time, many companies have undergone multiple transformations: mergers/acquisitions/subsidiary closures, and all this history is reflected in their ERP. Developing a system with such a complex history can be very complicated. A Greenfield approach is therefore an opportunity to get rid of all this obsolete data. » However, starting from scratch can be problematic. For years, companies have been developing specific applications around their ERP. This represents a considerable investment that is difficult, if not impossible, to abandon at the snap of a finger. « The Greenfield approach is not aberrant in itself, but if you have numerous interfaces it can become costly, » underlines Louis Alves, Finance specialist and Product Costing SA expert at S4IC.

In the Activate methodology, SAP proposes the ‘Show and Tell’ technique. For those who choose the Greenfield approach, this technique accelerates the analysis phase. It is based on the best practices implemented to create in SAP S/4HANA the processes corresponding to the customer’s needs. The result of this approach is the BPD (Business Process Description).  « This approach makes it possible to implement these best practices very quickly, » admits Alain Rivet, « but business users often forget the processes that are least used… and it’s during testing or in production that these reappear… with all the consequences that this can have on the business ».

For the expert, SAP is undoubtedly the most configurable software in the world: of the 130,000 transactions it integrates, more than 100,000 are intended for parameterisation. A well-executed Greenfield migration will, above all, focus on this configuration. It is only when the necessary functionality cannot be fully covered that it is supplemented with specific developments.

Brownfield vs Greenfield: to choose between the devil and the deep blue sea!

SAP migration, by S4IC, SAP reseller in Belgium
A nother option is to opt for a Brownfield migration, i.e. to reproduce ECC on SAP S/4HANA almost identically. By keeping the existing settings, users will not be confused by the data in the new version of SAP. Training in Fiori, the new SAP S/4HANA user interface, will suffice. This approach also means that many of the specific developments that have cost the company and its business users so much effort can be retained. However, this approach does not make it possible to take advantage of the new SAP S/4HANA functionalities. What’s more, Brownfield requires a data archiving project beforehand. « It doesn’t make sense to transfer 15 years‘ worth of accounting entries into SAP S/4HANA, » explains Alain Rivet. « Archiving is a relatively complicated process. You have to ensure that the processes are consistent. For example, archiving purchase orders will mean archiving all the subsequent documents (receipts, invoices, etc.), but this is not the standard approach. »

Brownfield upgrades also involve converting existing data and transferring it to the new tables. The automatic conversions in the upgrade process do not cover the situation of all customers. And resolving these specificities can also be very time-consuming.

De facto, the Brownfield approach simply perpetuates the complexity accumulated in ERP over 15 or 20 years. « Choosing between Brownfield and Greenfield is a bit like choosing between the devil and the deep blue sea », says Louis Alves. Each approach has the defects of its qualities. A company that has developed dozens of interfaces on its SAP system will have to redo them all if it opts for Greenfield. It will benefit from all the best practices coded by SAP in S/4HANA, but all the codes that users are used to will change, which will have a real impact in terms of change management.

The hybrid approach, a middle way with multiple advantages

« Experience shows that it is often preferable to opt for a middle way, » says the specialist. This middle way is the hybrid approach (or Data Selective Transition, the official term used by SAP). The basic idea is simple: an SAP system is easy to modify as long as it contains no data. The idea is therefore to separate the parameterisation of the data and to model the ERP according to the company’s needs before reloading the data. This avoids the pitfalls of archiving and converting data during the upgrade, and gives you the freedom to activate new functions or correct things that were not optimally implemented when ECC was installed. Some processes can be kept as they are if they are considered to be performing well or too critical for the company to change. « If the company decides that its purchasing management does not need to change, the migration team will be able to transfer this process to SAP S/4HANA without any impact on users, » explains the expert. Other processes that are considered obsolete can be replaced on the basis of the best practices implemented by SAP. In this way, the company obtains its own installation of SAP S/4HANA with all the functionality it requires. Its data is then loaded into the system. In this way, the new architecture incorporates everything the company wanted to retain from the past and all the improvements it wanted to make. « As the best practices defined by SAP have not been loaded in full, there are far fewer conversions to be made and users will find many of the codes they are used to. »

What’s more, in a Greenfield or Hybrid migration, only those developments that will continue to be used will be retained. « It’s really a modular approach, where we choose the processes that need to remain as they are, those that need to evolve, and all of which will be installed on a dedicated SAP S/4HANA installation, » adds Alain Rivet. « In the end, it’s an ideal approach, because it avoids the need to set up training plans, avoids the stress of change for the teams, and above all contains the time overruns that are so common in these major SAP projects ». With the Greenfield approach, the migration team will be asking business teams who are already working full time on day-to-day management to spend 4 or 6 months thinking about new processes and asking themselves the same questions they answered 15 years ago. This approach clearly raises the issue of lead times, as the integrator’s initial commitment is often doubled or tripled. « The hybrid approach helps to contain these problems, because the data migration to be carried out is much more limited. As we’re not starting from scratch, we’ll save time on training and on getting the system up and running again, because a large proportion of users will be back to their usual way of working. The impact of the migration is less at each stage of the project, and this impact is much better controlled because it’s the company itself that decides what needs to be changed and what doesn’t ».

While migration to SAP S/4HANA is inevitable for all companies that remain loyal to SAP, it is possible to limit the impact of such a project on the business. A hybrid approach (Data Selective Transition) is often the best way to go.

« An SAP project can be summed up in 4 dimensions,’ explains Alain Rivet. ‘On the one hand, there are the processes, which are based on configuration and possibly specific developments. Then there's the repository and transactional data, followed by people and authorisations. By managing each of these aspects independently, we can work on the processes, transform those that can be improved, retain those that need to be, and this will have a direct impact on the complexity of the migration. »

Share

Copyright S4IC – 2021​