14.2    Creating Your Own Roadmap

To help you create your own roadmap, in this section, we’ll use examples to discuss different initial situations. This section describes the details you’ll have to keep in mind and provides recommendations. In this context, we’ll start with determining the new target landscape first and then identifying the best way to achieve this goal. Nevertheless, we cannot cover every possible customer situation. So your specific roadmap may differ significantly from the ways we describe for various reasons.

For new customers who have not used SAP products at all, the best way to introduce SAP S/4HANA is as a new implementation. For customers using SAP ERP, the first step is to define or analyze the current target landscape. Depending on how long ago the system landscape was established and how the existing architecture meets today’s business and IT requirements, this assessment involves more or less effort. Your first analysis should answer the following questions, for example:

• Which applications can be used to meet future business requirements in the best possible way?
• How many SAP S/4HANA production systems are supposed to be used (for example, regional or global production systems)?
• Does existing architecture need to be retained for other applications, or are certain functions covered by SAP S/4HANA?

This first planning step and the answers to these questions, by themselves, cannot determine whether a new implementation or a system conversion is ideal for you.

However, in a decentralized system landscape, you can now identify whether you’ll have to transform your landscape through a system consolidation. In general, migrating to SAP S/4HANA always allows you the opportunity to rethink your landscape strategy.

[»]  Additional Information on the Production System Strategy

Criteria for defining an optimum production system strategy still apply in SAP S/4HANA. The relevant SAP white paper is available at http://tinyurl.com/Strategy-Whitepaper. (Access to the SAP Enterprise Support Academy required.)

Consolidating system landscapes has been an issue for SAP customers for more than ten years. Many customers have already consolidated their SAP ERP systems and harmonized their business processes. You’ll have to take into account and evaluate various criteria.

The most important criteria are the business requirements for global process harmonization and for the global management of business processes. These criteria should be the driving factors of the strategy you select. You should analyze whether a global harmonization makes sense or whether adaptations at the regional level or within business areas is feasible. These decisions also have an impact on the technical side. Globally consolidated systems require a single defined system configuration as well as efficient change and troubleshooting processes. Furthermore, a uniform release calendar with test periods and downtimes can be implemented. Another criterion is how risks regarding system performance, scalability, and operation issues are addressed. Figure 14.3 illustrates some considerations to keep in mind when developing your landscape strategy.

Figure 14.3    Decision Process for a Landscape Strategy

Let’s take a traditional SAP ERP system that covers financial and logistics functions as an example. Typically, the result of a system strategy is one of the following configurations:

• A single global production system
  This case is common among small regional enterprises or global enterprises that leverage globally harmonized processes and a global supply chain.
• Global production systems per business area
  This strategy is ideal for varying or organizationally independent business areas.
• Regional production systems using a global template and uniform master data system
  This configuration is often used in large enterprises with regional supply chains, for example, in the consumer goods industry.

The main difference when determining your landscape strategy for SAP S/4HANA compared to traditional SAP ERP systems is that SAP ERP can be found in the transactional system. In most enterprises, dividing the landscape into regional SAP ERP systems based on a global template would not reduce the business value more than a global SAP ERP system. SAP S/4HANA now enables you to perform comprehensive analyses and planning activities within the transactional system.

A global SAP S/4HANA system thus allows for operational reporting and financial planning at a global level in real time. In contrast, a regional SAP S/4HANA configuration would require a separate installation of SAP Business Warehouse (SAP BW). Consequently, the business value added by a global SAP S/4HANA system is higher than that of a global SAP ERP system when compared with the relevant regional architecture. Technically, system performance and scalability are no longer barriers to a global system thanks to the performance and throughput of SAP S/4HANA.

SAP S/4HANA makes global configurations more attractive. Compared to the previous SAP ERP system, SAP S/4HANA does not change the production system strategy of most enterprises that already use a central landscape.

For enterprises that use a decentralized, nonconsolidated, and/or nonharmonized SAP ERP landscape, the following considerations are relevant:

• In the long run, you should benefit from the innovations found in SAP S/4HANA.
• Even in an entirely technical system conversion to SAP S/4HANA, you will have to make some application-specific adaptations to the existing solution.
• Instead of converting all decentralized systems separately, combining the conversion with a landscape consolidation makes sense—provided that a consolidated landscape is suitable.
• Migrating to SAP S/4HANA would create more value and reduce operating costs.

Consequently, for enterprises with decentralized landscapes, migrating to SAP S/4HANA is the ideal starting point to also consolidate their systems.

SAP S/4HANA also enables you to use functions within the system that previously belonged to separate, additional applications. Examples include production planning and detailed workflow planning, which was previously only available in SAP Advanced Planning and Optimization (SAP APO).

However, we must mention that all existing deployment scenarios for SAP ERP are still feasible with SAP S/4HANA. No technical requirements for changing the landscape exist, and you should always implement potential changes with a detailed business case. To help you define a target landscape for components that can be used directly in the SAP S/4HANA system, consider the following:

• Global views as single systems
  If several regional SAP S/4HANA systems are part of the planned target landscape, you’ll have to set up all applications that require a global view as global single systems. Examples include SAP BW systems or SAP BusinessObjects for global reporting, planning, and consolidation. If required, you can also use SAP APO or SAP Integrated Business Planning (SAP IBP) and/or SAP Transportation Management (SAP TM) for global transport planning, which would be the same as in an SAP ERP-based landscape.
• Mission-critical systems as single systems
  All mission-critical systems, such as systems that automate production processes or warehouse management processes, should be defined as single systems. A common example is SAP Extended Warehouse Management (SAP EWM). If you had SAP EWM set up as a single, SAP ERP-independent system in your existing landscape, this setup would probably still be the case after migrating to SAP S/4HANA because SAP EWM plays a critical role for the enterprise.
  A separate system offers several advantages, such as independence for software modifications and the reduced risk of collateral effects. However, if SAP EWM system covers rather uncritical processes (more like traditional SAP Warehouse Management in SAP ERP), you should think about codeploying SAP EWM in combination with SAP S/4HANA.

Finally, you should check the added value from the newly integrated processes that are only available when specific functions of SAP S/4HANA are codeployed. You should compare the potential benefits and disadvantages, as well as the costs, of such a migration.

Examples include the ability to use operational reporting with SAP S/4HANA embedded analytics instead of operational reporting with SAP BW or the ability to use detailed production planning integrated in the new material requirements planning (MRP) function within SAP S/4HANA instead of a separate SAP APO system.

Some potential disadvantages you’ll have to consider include standardized maintenance and release cycles, common system downtimes, and possibly longer downtimes for smaller functions because the software is updated for all components in parallel.

After defining the new target landscape, you can specify the appropriate migration scenario and the sequence of the actions required. Depending on the target situation, the following questions may arise:

• Is a system conversion the appropriate scenario for your migration to SAP S/4HANA, or should you consider a new implementation?
• What is the appropriate approach for a system conversion if multiple SAP ERP systems need to be consolidated into a few SAP S/4HANA systems?
• How can the necessary steps be sequenced appropriately, and what relationships need to be taken into account?

The following sections use examples from different customer situations to identify the possible answers to these individual questions.

14.2.1    Initial Scenario: Single System

In the first scenario, your enterprise has a central single SAP ERP system. Because a system consolidation is out of scope here, you can only choose between a system conversion and a new implementation. The following options are possible:

• Standard: system conversion
  Assumption:
  • The existing solution mainly meets your existing business requirements.
  • Your business requirements do not need a completely new implementation.
  Advantage:
  • A one-step procedure to SAP S/4HANA without reimplementation is possible.
• New implementation according to the greenfield approach using the model company
  Assumption:
  • The existing solution is too complex and/or no longer meets your existing business requirements.
  • You have business requirements that need a new implementation and a return to the standard (irrespective of SAP S/4HANA).
• New implementation reusing an existing template
  Assumption:
  • The existing solution still meets your business requirements, but the system contains a large volume of (unused) legacy data.

For many SAP customers, at first glance, the standard method for system conversions seems to be the ideal solution to convert an existing SAP ERP system into an SAP S/4HANA system. The major advantage of this scenario is that your existing configuration and data are kept. This kind of conversion can also be implemented in one step, depending on your initial situation.

For this recommendation, we assume that the solution used so far meets the business requirements and a complete new implementation is not necessary. You can also implement minor changes (such as returning to the standard for customer-specific adaptations in isolated areas, cleansing custom code, and implementing new functions) in system conversions.

If the solution currently used is too complex or no longer meets existing requirements and/or if you generally want to implement a new system (irrespective of SAP S/4HANA), this way is the ideal solution. If your system is 20 years old or older, starting from scratch is likely ideal because requirements have likely changed considerably over time.

In this case, migrating to SAP S/4HANA is ideal for implementing a new system. You can use SAP Best Practices and the preconfigured model company to reduce costs and implementation project duration to a minimum (see Chapter 6). For a new implementation, you’ll only transfer your master data and open items from your existing SAP ERP system. Historically completed data is not copied in general. In special cases, you can set up an SAP S/4HANA system from an existing template, which means that the configuration and custom code from the existing SAP ERP system will continue to be used.

Even if this example refers to a customer with a single system, the procedure would be the same if multiple SAP ERP systems existed—if the landscape stays the same on SAP S/4HANA and a consolidation is not required.

For customers who decide to convert their SAP ERP system to SAP S/4HANA, the question arises whether the system is supposed to be converted in one step or in multiple steps. As we discussed in Chapter 10, various ways to perform a conversion are available. Figure 14.4 provides an overview.

In most cases, the one-step procedure for converting from SAP ERP to SAP S/4HANA is technically feasible and makes sense. Nevertheless, customers may ask themselves whether the one-step procedure is generally the simplest way or whether two or even more projects should be planned and implemented, in particular if only migrating to the SAP HANA database is planned as an intermediate step. Table 14.1 summarizes these differences again.

Figure 14.4    SAP S/4HANA Implementation Paths

Criterion	Option 1	Option 2
	One-Step Conversion to SAP S/4HANA	First Project: Database Migration to SAP HANA Second Project: System Conversion to SAP S/4HANA
Time to value	Faster implementation of the SAP S/4HANA target environment (analytics, new financials solution, new MRP run, SAP Fiori, etc.)	Faster on the first level with SAP HANA (better performance, SAP HANA Live, etc.) More time to implement the SAP S/4HANA target solution
Migration costs	In total, lower costs because you’ll implement one large project with one test phase	Higher costs due to two separate projects with two separate test phases Overlapping tasks can lead to unnecessary costs
Risks and consequences of the migration	Higher project complexity Potentially longer downtime	Lower project complexity Two potentially long downtimes Potentially higher risk due to reduced focus on individual test phases

Table 14.1    Comparing One-Step and Multiple-Step Procedures

When evaluating the different options, you should always consider and compare the duration of the implementation project, its overall costs, and its risks:

• The one-step procedure provides the major advantage that only one project is required—the fastest way to SAP S/4HANA. In comparison, costs are also lower because the costs of test cycles or for project management are only incurred once.
• For two-step procedures, two projects are necessary; the second project may be delayed due to other priorities (for example, due to additional rollouts or functional projects). Depending on how long the first status is kept (which would be an SAP Business Suite powered by SAP HANA here), unnecessary and redundant costs may be incurred. For example, if SAP HANA Live or SAP Fiori are to be introduced after the first step, additional costs may be incurred for modifications that are necessary at a later stage because many of these functions are included in SAP S/4HANA.

On the other hand, the project complexity of a one-step procedure is higher than of pursuing two subsequent projects. Therefore, the general project risks are also higher. However, you can still minimize these risks with in-depth preliminary analyses and planning processes as well as by scheduling sufficient resources and test cycles. Unfortunately, enterprises often underestimate the test effort required for two separate projects, which would leads also to higher risks. Experience has shown that the project risks for the two approaches are nearly identical.

In the end, your decision should be based on general considerations:

• The balance between identified business requirements with the new options available in SAP S/4HANA, taking into account the schedule for implementing these potential benefits
• System-specific migration risks and options for minimizing risk
• Other dependencies, for example, the estimated duration of the implementation project, how the project fits into the release calendar with other projects, and the availability of required resources
• The current status of the existing system, taking into account the necessary technical requirements

When making these decisions, the question often arises whether an additional intermediate step to SAP S/4HANA Finance makes sense instead of directly migrating to SAP S/4HANA.

In this case, you should consider the duration of the project, its costs, and its risks to decide whether to deploy SAP S/4HANA Finance as an intermediate step. In individual cases, business areas may expect significant benefits provided by the new financials functions in SAP S/4HANA and want to achieve this added value as fast as possible. This intermediate step is particularly relevant if the implementation to SAP S/4HANA suffer from delays due to customer-specific complexity in the logistics area or if the necessary third-party applications are not yet supported.

14.2.2    Initial Scenario: Decentralized System Landscape

As we described earlier, migrating to SAP S/4HANA offers a good opportunity for decentralized system landscapes to be consolidated. Several options exist to combine an SAP S/4HANA project with a system consolidation. In general, the following approaches are useful:

• A new implementation, either based on an existing template or using SAP Best Practices, including preconfiguration and subsequent data migration. In this approach, your data will be copied from all your existing SAP ERP systems, which and usually includes master data and open items. Under certain conditions, you can also copy other historical data; however, this data duplication would increase costs and effort.
• A system conversion of your existing SAP ERP system followed by the migration of the data from all your other existing SAP ERP systems. In most cases, you’ll convert one of your more central systems, the one with the most appropriate existing configuration or system size. As with the first approach, the data migration only includes master data and open items.
• A complete consolidation of all SAP ERP systems into a central SAP ERP system, where all historical data is kept, as described in Chapter 12. This consolidation can be performed by following a one-client or a multiple-client approach; afterwards, the resulting SAP ERP system is converted to SAP S/4HANA.

The criteria described in the previous sections can help you find the best possible way for this example. How well does the solution you currently use meet existing and future business requirements? Do you have a general requirement for a new implementation of the existing landscape, and does historical data have to be transferred? Answering these questions helps you make the right decision.

The following examples may be used for orientation:

• Consolidation if business requirements remain the same
  Your current solution still meets all business requirements in all SAP ERP systems, but you want to consolidate the systems. You can use one of the systems as the starting point for SAP S/4HANA. Further adaptations (such as returning to the standard, code modifications, and activating additional SAP S/4HANA functions) are planned. You can create a solution based on a uniform template and then implement the solution in several systems. Then, you can consolidate these systems into a smaller number of regional systems or into one global system.
• Consolidation based on a leading configuration
  Configuring one SAP ERP system is ideal because you can then use the system as a template for all other business areas or regions that are currently mapped in other systems or with other configurations. For example, a solution used in one of the larger regions is ideal for smaller, deviating implementations in satellite regions. In this case, the goal is to consolidate and harmonize all the systems on the basis of the configuration of the leading region.
• General modifications required
  An existing solution usually meets the requirements of at least one system, but general modifications are often necessary to stay competitive, regardless of whether you have migrated to SAP S/4HANA. In this case, a new implementation based on a template from at least one existing and largely appropriate system is feasible.
• No SAP system as the basis
  The existing solution no longer meets your business requirements, and no SAP ERP system is available to be used as a template or starting point for SAP S/4HANA. In this case, a new system must be implemented, ideally using SAP Best Practices.

For historical data that needs to be transferred, the main issue is data volume. Normally, only master data, as well as transaction data in the form of open items, is transferred for new implementations. If historical data plays a role in your new system landscape for critical reasons, the complexity of the project may increase considerably, thus increasing effort and costs because of additional required data transformations. As a result, you should always discuss this kind of requirement thoroughly and consider alternatives, such as data archiving, first. Depending on your current situation, various options are available (see Figure 14.5).

Depending on your answers, the matrix shown in Figure 14.5 can guide you to the preferred migration scenario. Note that these recommendations are only rough proposals and do not replace general and customer-specific analyses and evaluations. You’ll always have to take into account the time to implement (based on the duration of the project) as well as costs, benefits, and risks. Factors that you don’t have to consider include the current status of the system, the need for historical data, the number of systems to be consolidated if required, and consequently the differences between the systems involved. The technical feasibility of the selected scenario does not have to be analyzed in detail, in particular in the case of specific data migration requirements.

Figure 14.5    Decision Matrix for Different Requirements

[+]  Relevance of System Consolidation When Migrating to SAP S/4HANA

Consolidation activities are not a prerequisite for migrating to SAP S/4HANA and should not be considered necessary if you had not identified a need for these activities before. You can generally expect that a system conversion of a single system or a new implementation of SAP S/4HANA, followed by data migration from the other SAP ERP source systems, is always easier to implement than harmonizing all systems in advance.

SAP S/4HANA provides entirely new deployment options for your system landscape. Functions that previously required separate systems are now available as components of SAP S/4HANA. Customers often ask how these new functions impact migrating to SAP S/4HANA and defining a roadmap, including the relationships among the individual steps included in the migration.

We should mention that there is no technical requirement for modifying an existing landscape. You can convert existing SAP ERP systems to SAP S/4HANA and keep and continue to operate all related systems, such as SAP BW, SAP APO, or SAP Supplier Relationship Management (SAP SRM). If you need additional single systems, you can add them to the landscape, regardless of whether you’ve migrated to SAP S/4HANA.

In other words, these systems run on both SAP ERP and SAP S/4HANA. For example, you can start by introducing SAP EWM, regardless of other required migration steps. However, if you use one or more of SAP S/4HANA’s new codeployment options and want to replace the corresponding function from the existing single systems, you can only start the project during or after migrating your SAP ERP system to SAP S/4HANA.

Numerous examples of these projects are available, such as implementing the Advanced Available-to-Promise (aATP) materials management function in SAP S/4HANA, which replaces the Global Available-to-Promise (GATP) function from SAP APO. Another example is implementing the Self-Service Procurement function in the SAP S/4HANA procurement solution, which covers the same functionality as the corresponding function within SAP Supplier Relationship Management (SAP SRM).

14.2.3    Sample Roadmaps

This section provides sample roadmaps for migrating to SAP S/4HANA to better illustrate the topics discussed in previous sections. Even though the situations described in this section may not exactly map to your specific situation for your system landscape, you can still obtain useful information for creating your own roadmap.

From a Single System to an SAP S/4HANA Single System

The first example involves a global SAP environment with regional SAP EWM systems. The existing solution consists of the following components:

• A single global SAP ERP system
• A single global SAP APO system used for the GATP function
• A single SAP SRM system for the Self-Service Procurement function
• A single SAP BW system for operational and strategic reporting as well as SAP BusinessObjects Planning and Consolidation for financial planning and consolidation
• The recent introduction of SAP EWM with the aim of creating three regional systems in order to minimize risks

A long-term target landscape with SAP S/4HANA looks as follows:

• A single global SAP S/4HANA system will be introduced. In addition to the functions used in SAP ERP today, the plan is to map the following functions with SAP S/4HANA:
  • Real-time reporting with SAP S/4HANA embedded analytics
  • Financial planning and consolidation as a part of SAP S/4HANA
  • Advanced ATP and Self-Service Procurement
• In addition, a global SAP Integrated Business Planning (SAP IBP) system will operate in the cloud for sales and distribution, planning, and procurement.
• A global SAP BW system will be used for strategic reporting based on historical data.
• Three regional SAP EWM systems will limit the risk of failure.
  

  Figure 14.6    From a Single SAP ERP System to a Single SAP S/4HANA System

Figure 14.6 illustrates these changes graphically. A value-driven roadmap for migrating to this new target landscape could look as follows:

• You can proceed with the implementation of the SAP EWM systems as planned because no changes are necessary.
• First, SAP IBP in the cloud is used for new functions, such as SAP IBP for Response and Supply, which complements your existing SAP APO implementation. This cloud-based implementation is a new implementation, which you can carry out regardless of whether you’re migrating to SAP S/4HANA.
• You can then add the planning function for demand (SAP IBP for Demand) to SAP IBP, which replaces the corresponding function of the SAP APO implementation. This adoption is also independent of migrating from SAP ERP to SAP S/4HANA.
• You can convert the SAP ERP system to an SAP S/4HANA system in one step because the solution currently used still meets most of your business requirements.
• When converting to SAP S/4HANA, and in subsequent projects, new functions will be added to the new system (for example, operational reporting and Advanced ATP), which replace their corresponding functions in SAP BW and SAP APO.
• After converting to SAP S/4HANA, you should migrate your financial planning and consolidation functions from the separate SAP BusinessObjects Planning and Consolidation (BPC) system to the corresponding function embedded in SAP S/4HANA. The previous Self-Service Procurement function is also migrated from the separate SAP SRM system.

Figure 14.7 graphically illustrates the entire roadmap for this example.

Figure 14.7    Sample Roadmap for Migrating to a Single SAP S/4HANA System with Integrated Systems

From an SAP ERP Landscape Distributed across Regions to a Global SAP S/4HANA Landscape

In our second example, we’ll start with a system landscape distributed across multiple regions that will be consolidated into a global system landscape. The initial situation of our landscape distributed across multiple regions is the following:

• Three regional SAP ERP systems use a harmonized global template. One SAP ERP system, for the leading region, is much more comprehensive, while two smaller regional satellite systems also exist.
• Three regional SAP BW systems are used for regional operational and strategic reporting.
• A fourth global SAP BW system, including BPC, is used for enterprise-wide reporting as well as for financial planning and consolidation.

The long-term planning for this SAP S/4HANA target landscape could look as follows:

• You introduce a single, global SAP S/4HANA system because day-to-day operations have been globalized. In addition to the SAP ERP functions used so far, the following functions will be added:
  • Real-time reporting with SAP S/4HANA embedded analytics
  • Replication-free financial planning and consolidation with the BPC function included in SAP S/4HANA
• A global SAP BW system is used for strategic reporting based on historical data.
  

  Figure 14.8    From a Regional SAP ERP Landscape to a Global SAP S/4HANA Landscape

Figure 14.8 shows the entire landscape before and after the conversion. An appropriate roadmap for this migration to the target landscape could look as follows:

• You convert the largest SAP ERP system of the leading region into an SAP S/4HANA system in one step.
• You then migrate selected data from the regional satellite systems to the new SAP S/4HANA system. This data includes relevant master data and transaction data in the form of open items.
• You add the new real-time reporting function to the new SAP S/4HANA solution. You can add these real-time reporting functions during the system conversion or add them before or after migrating the data from your other regional systems. You can then gradually add further reports to replace the reporting from your regional SAP BW systems.
• From the separate BPC system, you can migrate the financial planning and consolidation function to the corresponding function in SAP S/4HANA. However, all regions must be integrated into the new SAP S/4HANA target landscape before you can move these functions. After integrating all the regions, the financial dataset is complete, which is required for financial planning and consolidation in SAP S/4HANA.
• The global SAP BW system remains unchanged and is populated with data that is relevant for strategic reporting and historical data from regional SAP BW systems. These systems can be removed from the landscape after this process has been completed. This step is largely independent of the actual migration to SAP S/4HANA.