s4h100 en Col04 Ilt

S4H100 SAP S/4HANA Implementation Scenarios

.

.

PARTICIPANT HANDBOOK INSTRUCTOR-LED TRAINING . Course Version: 04 Course Duration: 2 Day(s) Material Number: 50135509

SAP Copyrights and Trademarks © 2016 SAP SE or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other countries. Please see http://global12.sap.com/corporate-en/legal/copyright/index.epx for additional trademark information and notices. Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP SE or its affiliated companies shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP SE or SAP affiliate company products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this document or any related presentation, or to develop or release any functionality mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’ strategy and possible future developments, products, and/or platform directions and functionality are all subject to change and may be changed by SAP SE or its affiliated companies at any time for any reason without notice. The information in this document is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are cautioned not to place undue reliance on these forward-looking statements, which speak only as of their dates, and they should not be relied upon in making purchasing decisions.

© Copyright. All rights reserved.

iii

Typographic Conventions American English is the standard used in this handbook. The following typographic conventions are also used.

This information is displayed in the instructor’s presentation

Demonstration

Procedure

Warning or Caution

Hint

Related or Additional Information

Facilitated Discussion

iv

User interface control

Example text

Window title

Example text


Contents vii

Course Overview

1

Unit 1:

2 5 21

Lesson: Why do we Need a New Business Suite Lesson: Introducing SAP S/4HANA Unit 2:

22 28

Unit 3:

48 52 59 62 75 79

Unit 4:

174

System Conversion Lesson: Introduction Lesson: Aspects for Planning a System Conversion Lesson: Different Migration Options Lesson: Choosing the Right Option Lesson: Migration Services Lesson: Best Practices Exercise 3: Migration of Cost Elements Lesson: Example: Custom Code Analysis Exercise 4: Custom Code Review

Unit 5:

144 152 163 173

New Implementation Lesson: New Implementation Overview Lesson: New Implementation to SAP S/4HANA Exercise 1: Upload File with Data Services Lesson: New Implementation to SAP S/4HANA Cloud Exercise 2: Upload File with SLT

81 87 95 107 111 115 123 129 137 143

Overview of the Implementation to SAP S/4HANA Lesson: The Three Ways to SAP S/4HANA Lesson: Basics about Migration and Tools for Migration to SAP S/ 4HANA Lesson: Migration to SAP S/4HANA Lesson: Migration to SAP S/4HANA cloud Lesson: SAP Activate

32 35 39 47

Overview SAP S/4HANA

Landscape Transformation Lesson: The Content of Landscape Transformation Lesson: Central Finance - a deployment option Exercise 5: FI Posting to Central Finance

Unit 6:

SAP Info Sources and Further Courses Lesson: Further Courses and Useful Links


v

vi


Course Overview

TARGET AUDIENCE This course is intended for the following audiences: ●

Program/Project Manager

●

Solution Architect

●

System Architect

●

Technology Consultant


vii

viii


UNIT 1

Overview SAP S/4HANA

Lesson 1 Why do we Need a New Business Suite

2

Lesson 2 Introducing SAP S/4HANA

5

UNIT OBJECTIVES ●

Describe the need for a new Business Suite

●

Describe SAP S/4HANA and its key features


1

Unit 1 Lesson 1 Why do we Need a New Business Suite

LESSON OBJECTIVES After completing this lesson, you will be able to: ●


Why do we need a new Business Suite?

Figure 1: The World Is Now Digital

If you look at the numbers shown in the figure, it becomes obvious that the world around us is not getting simpler; it is getting more complex, for the following reasons: ●

Exponential growth of digital information - social, mobile, big data

●

Globalization and spread of business networks

●

Internet of Things (you could also say, the Internet of everything)

The response so far was to add more complex business processes, more complex organizations, and more complex software solutions. At the end of 2009, 5% of the world's population owned smartphones. Four years later, that figure jumped to 22%. Currently, 1.7 billion people are on social networks. Over the next three years, that audience will surpass 2.55 billion. By 2020, 5 billion people will enter the middle class and come online, while 50 billion devices will be connected to the "Internet of Things," creating a digital network of virtually everything. Cloud computing - a $41 billion business in 2011 - will grow to a $241 billion business in that same time frame. The exponential proliferation of mobile devices, social media, cloud technologies, and the staggering amounts of data that they generate have transformed the way we live and work. In fact, 61% of companies report that the majority of their people use smart devices, for everything from email to project management to content creation.

2


Lesson: Why do we Need a New Business Suite

While all of these advancements have improved our lives and provided us with greater opportunities for innovation than ever before, they have also accelerated the rise of an entirely new problem to contend with, unprecedented and crippling complexity. The world may be getting smarter, but it has not become easier. Massive consumerization of IT means online purchasing, banking, completing online applications become commonplace. Think about how much digital data you created today. Maybe some of it was of interest to some organizations? Data is the new oil.

Figure 2: Advances in Technology

In the last few years, there have been significant advances in technology that application developers can take advantage of to build smarter and more powerful applications. For example, multi-core processors enable parallelism of tasks, which means more throughput of data and faster processing to give us real-time responses. Big memory enables us to fit an entire organization's database in memory; this means that we lose the mechanical spinning disk and the latency that it brings. Advances in the design of on-board caches means that data can pass between memory and CPU cores rapidly. In the past, even with large memory, this was a bottleneck as the CPUs were demanding more data and the journey from memory to CPU was not optimal. We can now easily add more servers to our landscape to add more processing power or memory, to scale to any size. SAP re-wrote their business application software to exploit the new hardware fully. SAP worked closely with leading hardware partners, who shared their designs of their new CPU architectures, so that SAP could write the best software. Cloud computing technology has matured in the last few years, and is now a compelling deployment option for our customers who do not want to take on the complexity and cost of the installation and maintenance of IT landscapes. Virtualizing machines means lower costs of running enterprise-wide applications where public cloud service based on subscription models reduce the costs and simplify for all.


3

Unit 1: Overview SAP S/4HANA

Figure 3: Time to Rebuild the Business Suite for the Digital World

Since the beginning of enterprise computing, SAP has been rebuilding the business applications whenever major technology shifts have occurred. The following are some key moments in the application development history of SAP: ●

●

●

●

1979 - SAP invents ERP. SAP builds standard business software based on mainframe technology. The name, SAP R/2, supports and integrates major business functions in realtime and handles multi-country and multi- currency implementations. 1992 - With the rise of the PC, the introduction of client server architecture means another re-write of the applications so that we exploit the power of a 3-tier architecture approach, where processing is split across 3 layers of processing. A new graphical interface encourages end-user productivity. This is the birth of SAP R/3. 2004 - Now the web is firmly established as the common business network and customers demand better integration with business applications and the Web. SAP develops a new integration application platform, called SAP NetWeaver, to enable this. Now, all SAP applications run on a common platform, and customers and partners can build and integrate existing application easily, using widely adopted Web standards, such as SOA. The R/3 name was changed to SAP ERP. 2015 - A new wave of advances in hardware architecture brings massive computing power at reduced cost. Huge memory and multi-core processors arrive. The underlying design of the existing SAP applications is not optimal for the new hardware. A re-write of the complete suite is required. This is called SAP S/4HANA.

LESSON SUMMARY You should now be able to: ●

4



Unit 1 Lesson 2 Introducing SAP S/4HANA



Introducing SAP S/4 HANA

Figure 4: SAP S/4HANA Next Generation Core and Lines of Business Solutions for the Digital World

SAP S/4HANA is not a single product. Customers can start with the basic components and add to them later. SAP S/4HANA Enterprise Management is a great place to start. This is known as the "simplified core". Perhaps it might help to think of SAP S/4HANA Enterprise Management as the replacement for SAP ERP. Here, we find support for all core business processes, such as order to cash, procure to pay, and so on. For many customers, this is where their SAP S/4HANA adoption begins. Seamlessly integrated with the core, we find SAP S/4HANA Lines of Business (LoB) solutions. These are options that can be added at any time, and provide best-in-class lines of business solutions and connections to SAP Business Networks. In the past, we had multiple add-on applications surrounding a core (for example SAP ERP, SAP CRM, and SAP SRM), but with overlapping models and much redundancy. Now, overlaps and redundancy have been completely removed from SAP S/4HANA.

Note: SAP S/4HANA is built natively and optimally to run only on the SAP HANA platform.


5


Figure 5: Key Aspects of SAP S/4HANA

SAP S/4HANA is built on SAP HANA, so we inherit all of the capabilities of this powerful data management and application platform. This includes advanced text mining, predictive analysis, simulations, and powerful real-time decision support. A brand new user experience is delivered to improve the productivity and satisfaction of business users, and brings the interface up to a consumer-grade experience on any device. SAP S/4HANA can be deployed on premise, in the cloud, or by a combination of both, to provide flexible options to customers. The data model has been massively simplified. This means that we lost unnecessary tables and, of course, the data in those tables, to shrink the footprint dramatically and to simplify the application design and extensibility.

Figure 6: SAP HANA - The Great Simplifier

The key enabler of SAP S/4HANA from the software side is called SAP HANA, and it is the platform on which SAP S/4HANA is natively built. In 2005, SAP started researching the possibility of developing their applications built on an inmemory database. When SAP realized that no traditional database vendor had what was needed, SAP began its own in-memory database development. SAP worked with leading chip manufacturers to identify the optimal design of a database that could exploit the full power of the new generation of powerful processors.

6


Lesson: Introducing SAP S/4HANA

The first release of SAP HANA was in 2011. It was positioned as a standalone datamart solution, where customers could capture data from any sources in real-time, load the data to the in memory database, and build BI reports and applications on top. Then, SAP began offering SAP HANA based Accelerators, which were deployed as sidecar engines to run alongside traditional SAP ERP functions that were critical to businesses, yet were performing slowly. Around the same time, SAP developed new applications that were completely powered by SAP HANA (for example, Smart Meter Analytics). Around 2012 SAP successfully ported the first already-existing major application, SAP BW, to run completely on SAP HANA. This was quickly followed by the porting of SAP Business Suite. We call this Suite on HANA (SoH), and it should not be confused with SAP S/4HANA. In 2015, SAP started from scratch and rewrote the complete business suite natively to run only on SAP HANA. Unlike Suite on HANA, SAP S/4HANA is a brand new code-line, which works only on SAP HANA. Unlike Suite on HANA, the applications do not have to work on any other vendors' database. This means that we were not restricted by the limitation of those databases and could code freely to exploit the full power of SAP HANA.

Figure 7: SAP HANA - The Platform for S/4HANA

SAP S/4HANA inherits the built in capabilities of SAP HANA. This is evident throughout the new SAP S/4HANA applications. The following are some of the key capabilities of SAP S/4HANA. ●

Application Services: As well as a database, SAP HANA can provide many application services. This means that many applications can be built in a 2-tier model, rather than a 3-tier model. For example, imagine an application that allows a project manager to check quickly that all team members have competed their timesheets. This could easily be developed as a Web application, where only a Web browser and SAP HANA are required. No application server is needed. This is because SAP HANA can handle the business logic as well as the database services. SAP HANA provides a full development environment with productivity tools supplied in the box. Everything that the developer needs at design time, as well as what is needed at run time, is there.


7


●

Processing Services: SAP HANA can handle many new types of data. This data includes text, spatial, graphs, and more. However, it is not enough to simply store these new data types, we need to be able to build applications that can process and integrate this data with traditional data types, such as business transactions. SAP HANA provides native in-memory engines that process any type of data in real time.

●

Integration Services: SAP HANA has multiple data consumption options built in. We can analyze continual streaming data, read data remotely in any data source, read Big Data stores, such as Hadoop, and synchronize in both directions with remote databases, and devices that collect data (IoT). SAP HANA has built in Extraction, Transformation, and Loading (ETL) capabilities, so separate software is no longer needed to clean, enrich, and profile data from any source.

●

Database Services: SAP HANA is a full in-memory column and row store database that can support both OLTP and OLAP requirements, and is built to run on high-end hardware. It stores data optimally, using automatic compression and, can manage data on different storage tiers, to support data ageing strategies. It has built-in high availability functions that keep the database running and ensure that mission critical applications are never down.

Figure 8: Traditional Approach to Data Model and Application Code

Traditional applications were built on a hierarchical data model. Detailed data was summarized into higher-level layers of aggregates to help system performance. On top of aggregates, more aggregates were built, as well as special versions of the database tables to support special applications. As well as storing the extra copies of data, application code had to be built to maintain extra tables and keep them up to date. These extra tables also needed to be backed up, so even the IT operations were impacted. In addition to aggregates, another inefficiency needed to be removed. Database indexes improve access speed because they are based on common access paths to data. However,

8



they need to be constantly dropped and rebuilt each time the tables are updated, and more code is needed to manage this process. The traditional data model is complex, and a complex data model causes the application code to be complex. It has been found that up to 70% of application code is built specifically for performance of an application and adds no value to the core business function. With a complex data model and complex code, integration with other applications and enhancements are difficult, and simply not agile enough for today's fast-moving environment.

Figure 9: Remove Complexity with SAP S/4HANA

Using the raw power of SAP HANA, we can aggregate on the fly in sub-seconds from any line item table. There is no need for prebuilt aggregates. SAP HANA can generate any view of the data at runtime, all from the same source tables. SAP HANA organizes data using column stores, which means indexes are usually not needed. They can still be created, but usually offer little improvement. Therefore, as well as losing the aggregates and indexes from the database, we can also lose huge amounts of application code that deal with aggregates and indexes. We are left with a simplified core data model and simplified application code. It is now much easier to enhance the applications and integrate additional functions.


9


Figure 10: Massively Reduce Data Footprint

Tables in SAP HANA are compressed automatically, so that we can store huge amounts of data in little space. Further data footprint reductions are achieved because we removed huge numbers of tables that are not needed, along with unnecessary indexes. We can also reduce the in-memory data footprint by implementing data ageing strategies, as follows: SAP HANA can split data across an in-memory tier (we call this HOT storage) and a diskbased tier (we call this WARM storage). All processing and database services are common, which means that a developer does not need to know where the data is physically located; this is handled internally by SAP HANA. The benefit of this is that data that is used less frequently can be moved from HOT to WARM store automatically, so that we are not filling memory with data that is less useful. This data is still available whenever it is needed.

10



Figure 11: Simplified Applications

We have covered the simplification of applications from the technical side, so let us now look at how this simplification applies to the business side. In traditional SAP ERP finance, financial postings were supported by two key documents, the Finance (FI) document, and the Controlling (CO) document. These documents provide the required views of the finance data from a legal perspective (FI) and an internal management accounting perspective (CO). There is a lot of overlap between these documents. Application code had to deal with these two types of postings whenever a business event occurred that triggered a financial outcome, for example, a material receipt. With SAP S/4HANA Finance, we now have only one document, called the Universal Journal Entry. A single financial posting is made to one table, which holds all of the information that is needed by both legal and management accounting. The application code is simplified, and any views of the data that are required are created quickly by SAP HANA. This means that we do not lose any business meaning, we just lose the underlying complexity of the application.


11


Figure 12: Next Generation User Experience with SAP Fiori

With SAP S/4HANA comes a brand new user experience. This is called SAP Fiori. SAP Fiori is not a software product; it is the name of a design approach that was created especially for SAP S/4HANA. The key aspects of the design are as follows: ●

●

SAP Fiori applications should focus on specific job functions (as opposed to an overcomplicated screen filled with functions for different users).

●

They should offer only the essential information that a user needs to get their job done.

●

They should be intuitive enough to use with little or no training.

●

They should include embedded analytics to support in-process decision making.

●

The look and feel should be consistent across all applications.

●

12

SAP Fiori applications must run comfortably on any device and should present a modern consumer-grade quality.

SAPGUI is still supported, and can be used alongside SAP Fiori applications to provide for an easy transition for existing SAP customers who are familiar with the classic interface.



Figure 13: Embedded Analytics and Decision Support

What do embedded analytics really look like to a business user? The figure, Embedded Analytics and Decision Support, shows an example of a material planner's new SAP S/4HANA application. On the left, we see only the critical missing parts that need to be procured. The parts are presented because they need some action. As the planner clicks each part, the main screen presents the shortfall situation in an easy-to-interpret graph for their analysis. The planner can drill down to any part of the graph to break down the aggregated demand or supply columns to find out why the parts are being consumed too quickly, or why the supply is falling short. The planner can choose an action and then simulate the effect before committing. This is an example of how online transactional processing (OLTP) and online analytical processing (OLAP) are now combined.


13


Figure 14: Special Case HANA Enterprise Cloud (HEC)

We have two SAP S/4HANA editions: on-premise and cloud. The on-premise edition provides many opportunities for customers to customize their system, and all aspects of the solution are maintained by the customer. By using SAP S/4HANA cloud edition in the public cloud, which is shared with other companies, you will have limited opportunities to customize the system and SAP will update the system when new releases appear. If you are a HEC customer, then your solution is hosted by a third party and you access your system via the internet. This might, mistakenly, be called a cloud solution, but, in fact, it is regarded as an on-premise solution. It is simply that your on-premise solution is managed by a third party. This is important to know, because, in this case, the System Conversion scenario, within SAP Activate methodology, applies. This means that the "cloud" in which the HEC on premise edition runs has nothing in common with the SAP S/4HANA cloud edition.

14



Figure 15: Cloud-Deployment-Models

SAP offers three different Cloud-Deployment-Models such as Private Cloud, Public Cloud, and Hybrid Cloud. Private Cloud is owned by customer, operations and management by customer, or 3rd party or both. The System is assigned to a dedicated customer, access through VPN (Virtual Private Network). It can be operated on a customer site as well as remotely. Public Cloud is one system used by different customers. It is operated by Service Provider, not by customer and has self-service access. Hybrid cloud is a mixture of two or more deployment models. It is integrated by standardized or custom interface technology, supporting the transfer of data and transaction.

Figure 16: SAP's Cloud-Deployment-Models


15


SAP Business Cloud contains: SAP Data Center, SAP Managed Operations, and SAP Support for both deployment models Private Managed Cloud, and Public Managed Cloud.

Figure 17: SAP the Cloud Company Powered by HANA

SAP as a Cloud Company has three different services: SAP HANA Enterprise Cloud (HEC), SAP HANA Cloud Platform (Platform as a Service, PaaS), and SAP Cloud Apps (Software as a Service, SaaS).

Figure 18: HEC AND HCP Side-by-Side

One of the most important innovations in SAP HANA is that it allows the applications that users love to use. No longer do we have to have applications that let us take action, transactional applications, and other applications that let us do the analysis we need. This division was a function of the limitations of older databases and forced complex landscapes with multiple technologies and terrible user experiences. With SAP HANA, applications that

16



provide "in-context analytics" are easy to build. This not only brings efficiency to the business, but also simplifies IT landscape by requiring fewer technologies and servers. SAP HANA ENTERPRISE CLOUD ●

Run SAP applications in a private managed cloud environment

●

Fully managed private and dedicated cloud

●

●

Designed for mission critical operations, with no tradeoffs on performance, integration, security, failover, and disaster recovery SAP manages the HANA cloud environment from infrastructure to applications

SAP HANA CLOUD PLATFORM ●

Build new applications in an application development environment running in the cloud

●

Robust lifecycle management and application development services

●

Build extensions to core SAP applications and run in the cloud

●

Build extensions to SaaS applications and run in the cloud

Figure 19: SAP HEC - Nobody Knows SAP Better Than SAP

SAP HEC is flexible, secure, scalable, and offers Private Cloud.


17


Figure 20: SAP HANA Enterprise Cloud Gives You Flexibility

SAP HANA Enterprise Cloud Gives You Flexibility. It follows the idea of scalability of Cloud Computing. This means scale in or scale out of infrastructure resources if required.

Figure 21: SAP HANA Enterprise Cloud Core Services

SAP HANA Enterprise Cloud Core Services refers to assessment on technical aspects, Onboarding and Migration toward SAP HANA Enterprise Cloud, Cloud Infrastructure with enterprise-class Service Level Agreements, and Application Management providing application incident support and monitoring.

18



Figure 22: The Value of HEC in the Acceleration of Digital Transformation

●

Simplicity, Experience, Optimization, Peace of Mind, A Foundation for Innovation

●

Simplicity - allowing customers to deploy and realize the benefits of HANA quickly

●

Experience - supporting over 1,100 instances of SAP HANA, no one else comes close

●

●

●

Optimization - designed to support any SAP HANA landscape, no one knows SAP HANA better than SAP Peace of Mind - providing an integrated support model that feeds into HANA Development A Foundation for Innovation - combined with HCP and AMS for HEC provides customers a comprehensive cloud portfolio and foundation for continuous innovation




19


20


UNIT 2

Overview of the Implementation to SAP S/4HANA

Lesson 1 The Three Ways to SAP S/4HANA

22

Lesson 2 Basics about Migration and Tools for Migration to SAP S/4HANA

28

Lesson 3 Migration to SAP S/4HANA

32

Lesson 4 Migration to SAP S/4HANA cloud

35

Lesson 5 SAP Activate

39

UNIT OBJECTIVES ●

Describe the three different scenarios to SAP S/4HANA

●

Explain what migration is and describe the different tools of Migration

●

Describe the migration to the on premise edition SAP S/4HANA

●

Describe the migration to SAP S/4HANA cloud

●

Describe how SAP Activate supports your implementation


21

Unit 2 Lesson 1 The Three Ways to SAP S/4HANA



The Three Ways to SAP S/4 HANA

Figure 23: SAP S/4HANA: One Code Line, Different Products

In the figure, SAP S/4HANA: One Code Line, Different Products, the icons on the top righthand corner, SAP S/4HANA and SAP S/4HANA cloud, are very important. This is the first thing we have to distinguish because the on-premise system is basically what was released at the end of 2015 with release number 1511. We also have the SAP S/4HANA cloud, which is software as a service (SaaS). This is a real public cloud, basically. When we say cloud, we are normally not talking about the HANA Enterprise Cloud (HEC), which could be seen as the on premise edition in a hosted environment. The Business Suite, which sometimes comes into play when we talk about SAP S/4HANA Finance was previously known as Simple Finance. So these are the differentiators when we talk about SAP S/4HANA.

22


Lesson: The Three Ways to SAP S/4HANA

Figure 24: Transition to SAP S/4HANA: The 3 Transition Scenarios (1)

SAP HANA Enterprise Cloud (HEC) is an on-premise system that can be reached in the cloud. It is an on-premise system that can be converted as described in the "System Conversion" scenario.

Figure 25: Transition to SAP S/4HANA: Scenario: New implementation

The New Implementation The new implementation targets customers who want to move from their legacy system, whether an SAP ERP System or a non-SAP System, and implement SAP S/4HANA from scratch. This scenario is also known as a Greenfield approach. The benefits for you, as a customer, are that you can re-engineer and simplify your business processes on SAP S/ 4HANA , taking advantage of the latest and best ready-to-run business processes. You can use predefined data migration and best practices to start you off in a guided implementation. You can introduce SAP S/4HANA quickly and cost-effectively, and rapidly adopt additional innovations later. In a new implementation, you can also take full advantage of SAP Activate, the innovation adoption framework for SAP S/4HANA.


23

Unit 2: Overview of the Implementation to SAP S/4HANA

Duration Of The New Implementation The volume and complexity of your data migration, as well as the number of data migration objects affects the duration of the new implementation. The volume and scope of the business processes that you want to implement on SAP S/4HANA also affect the duration. New Implementation Approach In on premise, you first install SAP S/4HANA with the software provisioning manager and then perform an initial data load from a source system, either through file upload from a legacy system, or, if the source is SAP, through direct system connection. The tools used are SAP data services for on premise or the SAP landscape transformation for the cloud.

Figure 26: Transition to SAP S/4HANA: Scenario: System Conversion

System Conversion Transition Scenario System conversion is for customers who want to convert their current system into an SAP S/ 4HANA system, bringing an ERP core system, whether it is already using SAP HANA as a database, or it is on another database, to SAP S/4HANA. The benefit is that you can move to SAP S/4HANA without a reimplementation; there is no disruption to your existing business processes and, once the conversion is completed, you can reevaluate your existing process flows and adapt them as you want. The parameters that influence the duration of a system conversion are technical as well as functional. You need to consider the number of systems that you have in your current ERP landscape and that you want to bring to SAP S/4HANA, and the actual size of your productive source database. In terms of the functional influencers, you need to consider, for example, how many company codes you have, how many ledgers, and so on. The steps for a system conversion are as follows: 1. Check your add-ons, business functions, and potential industry solutions using the maintenance planner. This is to ensure the SAP S/4HANA compatibility of those components.

24



If there are compatibility issues, a de-installation tool is available for enabled SAP and partner add-ons. 2. Once you have completed the checks for add-ons and for industries, pre-check to identify further preparation steps, such as, the activation of the customer-vendor-integration. An optional check, which you can conduct at any time, is a custom code check to ensure code compatibility with SAP S/4HANA. Your custom code continues to run if the SAP S/ 4HANA simplifications and its new data model allow it. The custom code check tool identifies conflicts where, for example, custom programs access data structures that changed with SAP S/4HANA. The custom code checks are based on the simplification database content, which contains all incompatible changes of the data model, including business functions in SAP S/ 4HANA. 3. Once you have completed all checks and adjusted your custom code, the third step is to run the actual conversion. You can run the actual conversion in one step, using the database migration option for software update manager. With that, you have performed a system conversion.

Figure 27: Transition to SAP S/4HANA: Scenario: Landscape transformation

The Landscape Transformation Landscape transformation targets customers who want to consolidate their landscape, or to bring data into an SAP S/4HANA system selectively. Examples of a selective transformation are Central Finance, where the finance function is centralized, and you can take advantage of the universal journal and of statutory reporting using central finance. Another example is the selective carve out of a company code, which you want to bring to SAP S/4HANA as a front runner in your enterprise for SAP S/4HANA. The benefits are such that, with the landscape transformation, you can perform a selective transformation to SAP S/4HANA, and allow a phased approach, focusing on areas with high return of investment, a low total cost of implementation, and adapt to SAP S/4HANA in stages.


25


With the system consolidation, with harmonized and simplified processes, you will reduce the number of systems in your current landscape, lower your total cost of ownership, and improve the quality of your master data. Project parameters that influence the duration are, for example, the number of selected units that you want to consolidate, or the number of company codes that you want to carve out. What are the steps to consider? ●

●

The consolidation of clients from different source systems into one new or existing SAP S/ 4HANA system using the system landscape transformation. Next, consider the selective data transformation, where you carve out single entities and migrate selective applications, such as central finance using the system landscape transformation.

Landscape transformation is a scenario that we will not cover in detail in this course. This course focuses on system conversion, as well as new implementation in the cloud and new implementation on premise. Later, in the tool section, we provide some links to more information on the landscape transformation, as well as the other two transition scenarios.

Figure 28: Transition to SAP S/4HANA: The 3 Transition Scenarios (2)

The figure, Transition to SAP S/4HANA: The 3 Transition Scenarios (2), compares the three transition scenarios on a high-level view and also on the data view. On the top left-hand side, you see a New Implementation, you see "degree of standardization" and "size of the repository to be kept" on the x-axis. New Implementation here means you only migrate master data and selected transactional data. From a transactional point of view, it is basically open sales orders, purchase orders, accounts payable receivable and so on. It is important to note that you cannot migrate historical data, that means, closed purchase orders that are already done, billed, you cannot migrate. Why? Because we are using application interfaces. So, if you migrate such a record, the system would treat it as transactions that create a new order, for example. No historical data is possible.

Note: No historical data is possible in a new implementation scenario!

On the contrary, on the bottom right-hand side of the figure you see System Conversion. This is where you convert a complete existing system: The data never actually leaves the system.

26



In New Implementation, you have a legacy system, you pull the data out, and load it into the new system, so you have an old one you have to retire and you have a new system. With System Conversion, data never leaves the system, there is never a second system in place. Data gets converted into an SAP S/4HANA system, which also converts all the historical data to a new structure if needed. This is beneficial because you have your historical data, but again it depends on how big the system is because that might influence the runtime. If you have a 4 to 5-terabyte system where 80% of it is historical data that you are not looking at, system conversion might be a thing you want to do. Discuss this up front, maybe do some Data Volume Management (DVM), this will help you decide whether you want to go for a System Conversion or a New Implementation. Landscape Transformation is in between; for a system consolidation, it is worth a lot; for carve-out, it is of course a bit less but it is still moving data from one system to another. This figure gives you a good overview how the system differs from an implementation point of view, and what you have to consider when planning such a project. LESSON SUMMARY You should now be able to: ●



27

Unit 2 Lesson 2 Basics about Migration and Tools for Migration to SAP S/4HANA



Migration

Figure 29: What Is Data Migration?

We often talk about Data migration without defining it. The important point to note is that simply moving data is insufficient; the goal of a data migration project is not simply to move and transform data from one system/ format to another; rather, it is to ensure that the moved data is of high quality, is fit-for-use, and supports the underlying business processes and operational goals of the organization.

Figure 30: Data Migration Happens

Data migration happens in a lot of different ways, such as, merger and acquisition, divestitures, data comes in, data goes out, application consolidations, business transformation projects, or of course new implementations. Data migration is not a one-time

28


Lesson: Basics about Migration and Tools for Migration to SAP S/4HANA

event. If you have, for example, a scenario of a central system or you start with a single company code first, you have a migration now, and you will have migrations in the future - for example, you start implementation with a certain country with SAP S/4HANA, and then you would like to load additional countries into the same system. Risks around data migration should be addressed very early so that you can manage that risk. The opportunity migration offers is the possibility to start with better data, specifically if you are coming from non-SAP as you have to do some sort of a data harmonization when you go to SAP S/4HANA. For data quality, take the opportunity to ensure that all the data that you need in the system is in a good shape.

Figure 31: The Problem with Migration Projects

Analysts say that more than 80% of data migration projects run over time and over budget. Cost overruns by 30%, time overruns by an average of 40% percent, and 80% of organizations underestimate costs by at least by 50%. Over half of all ERP implementations are reported as challenged due to data integrity or data accuracy problems.

Figure 32: Transition to SAP S/4HANA: Migration Tools Overview

As you see in the figure, Transition to SAP S/4HANA: Migration Tools Overview, there is one tool for each scenario; the only exception is the New Implementation. On the top row, you see the New Implementation for on premise or the HEC ( the on-premise version in a hosted


29


environment). The migration tools we recommend are SAP Data Services. For the cloud we use the Embedded Migration Cockpit. The Legacy Migration Workbench (LSMW) tool can be used, too, but it is not recommended. LSMW does not support the new SAP S/4HANA data structures, such as business partner master data. Furthermore, LSMW does not support best practices, as SAP Data Services does.

Figure 33: SAP Data Services

SAP Data Services is a tool, not a service. It is a full blown ETL (extract, transform, load) tool. With Data Services, you can basically connect to all the sources, such as BW, an SAP system, Oracle apps, HANA, databases directly, structured and unstructured files, data in Excel sheets or Access databases. You can do all the transformation in SAP Data Services. It provides content with a lot of pre-transformed workflows and data flows. Everything is preconfigured and you have a lot of checks available, you do not have to start from scratch. When you install Data Services it is empty, but you can download content for free. You can use that content in your migration project. From a loading perspective, you have either batch or real-time processes, and you can load into various target structures. In our scenario SAP S/4HANA would be the target environment.

Figure 34: SAP Information Steward Complements SAP Data Services

30


Lesson: Basics about Migration and Tools for Migration to SAP S/4HANA

The SAP Information Steward supports business users as well as IT users to ensure overall data quality. Business users can see how their information measures up against information governance rules and standards. IT can share data quality metrics with business users and involve them in owning the data problem.

Figure 35: SAP Landscape Transformation

SAP Landscape Transformation tool helps you to analyze, plan, and realize transformation projects within common business scenarios, such as corporate mergers and acquisitions, divestitures, internal reorganizations, and projects to harmonize existing business processes. ●

Analysis Perform analysis for transformation Compare repository and Customizing of systems

●

Leverage Sell, Buy, and Restructure Sell or buy a company or parts of it Execute business unit reorganizations

●

Unify and Transform Data Gain transparency in financials and logistics Harmonize master data

●

Consolidate and Reduce IT Costs Consolidate systems with matching release or across releases

●

Migration Projects: Powerful tool for SAP – SAP migration Migrate all data, including history




31

Unit 2 Lesson 3 Migration to SAP S/4HANA



Migration to S/4HANA

Figure 36: SAP S/4HANA New Implementation: Data Migration Functionality (On-Premise)

The figure, SAP S/4HANA New Implementation: Data Migration Functionality (On-Premise), outlines how the solution works, including all of the functionality provided with the migration content. In the figure, the steps shown are as follows: 1. Legacy data environment The legacy data environment refers to the source systems for the migration. The legacy environment can be any third-party source system that is supported by SAP Data Services connectivity (almost all sources are supported as SAP Data Services supports ODBC protocol). SAP systems on a lower release that cannot be upgraded could also be the legacy system. The Rapid Data Migration package comes with pre-built content for SAP S/4HANA. 2. Extract and profile Data is extracted from the source and placed in a staging area in SAP Data Services. At this point, you can conduct technical profiling with SAP Data Services. Additionally, you can start profiling the source systems at an early stage, using SAP Information Steward. The Data Services environment is used as a staging area that extracts and profiles the

32


Lesson: Migration to SAP S/4HANA

data. The profiling can include looking at patterns in postal codes. For example, what percentage of postal codes has 5 digits? It could also be how many material numbers follow a specific pattern. You might be interested in how many unique IDs there are in a certain table. The extraction and profiling of data is an important first step in a data migration project in order to assess the quality of the source data and mitigate the overall risk for the data migration project to be successful. 3. Cleanse, transform, and validate This includes updating the data so that it meets specific patterns, mapping and transforming the data according to rules, and validating data against the SAP S/4HANA business context. This can involve combining two fields into one, splitting fields, updating the data in a field to match certain rules (for example, telephone number formats), and validating data against required fields and lookup values from the SAP S/4HANA context and configuration. In addition, duplicate data records can be eliminated with this step. 4. SAP configuration extraction Once the data is extracted, it is important to know how the data needs to be prepared for SAP. The solution reads business context and configuration settings in SAP S/4HANA to help map the data. As part of an SAP S/4HANA implementation, the system is configured with many values, such as cost centers, company codes, and country values. This step requires knowledge of the SAP business context to transform and then validate the data in Data Services against the SAP configuration and customisation settings. Mapping of the source data normally requires mapping fields that comply with the SAP configuration. 5. Load Once the data is transformed and validated, it is then loaded into the SAP S/4HANA system. This is normally loaded through IDocs and WebServices, but can also be loaded using files and BAPIs. 6. Reconciliation Reconciliation looks at what was actually loaded versus what was expected to be loaded. This ensures that all data was loaded and is ready for use. 7. Dashboards and business reporting Throughout the process, dashboards are available for people involved to remain informed about the status of the migration. Additionally, the migration project often sets data quality expectations and governance around data management. The entire process of assessing the data, validating it according to business rules and SAP context lays the groundwork for ongoing data governance. For example, if customer records were checked to ensure that every customer had at least two associated contact persons, this process can continue to ensure that all new customer records have two contact persons.


33


Figure 37: Rapid Data Migration Solutions

●

●

Service Marketplace is the standard entry point for Rapid Data Migration. Here you find all additional solutions such as non-SAP S/4HANA, SAP ERP, SAP CRM, SAP Billing for Utilities, cloud solutions from SAP, SAP SuccessFactors, C4C, Workforce Analytics, BW, or SAP Hybris Marketing, even for retail. This gives you an overview on how much content is available. In addition we offer Rapid Data Migration to SAP S/4HANA on premise. There is an SCN community on the SCN community network/dm (data migration).


34



Unit 2 Lesson 4 Migration to SAP S/4HANA cloud



Migration to SAP S/4HANA cloud

Figure 38: SAP S/4HANA New Implementation: Data Migration to SAP S/4HANA Cloud in Detail

The move to the SAP S/4HANA cloud can be considered as a New Implementation project with classical data migration activities. Data transfer is supported by a data migration server toolset included in the S/4HANA stack (SAP Landscape Transformation (SLT)). In cooperation with SAP Service Center, the virtual private network (VPN) connection connects your source system with the cloud target system. You can migrate master data such as the following: ●

Customer & Vendor (source system = classic customer, vendor; target system = SAP S/ 4HANA Business Partner)

●

Material Master

●

Bank Master

●

Activity Types, Activity Type Groups

●

Cost Centers, Profit Centers, Profit Center Groups, Cost Center Group


35


●

Inventory Balances

The figure illustrates the following: ●

(a) SAP Landscape Transformation (SLT) Tool required on customers OP system

●

(b) Customer needs to establish VPN connection to OP System

●

(c) For new customers (legacy migration) a template-based approach is used (XLS)

S/4HANA Cloud System ●

SAP Cloud Operations: provision of cloud instance

●

Customer: Implement configuration in target

●

●

Customer: Implement integration to SAP Business Suite System or use template-based approach Service Center: Re-Implement customer enhancements

S/4HANA Cloud Data Migration ●

●

Consulting Service: -

Maintain data mapping (Business Objects to be transferred) in SLT

-

Transfer of master data; Transfer of transactional data

Customer: Data Validation

Figure 39: SAP Landscape Transformation - Outlook: S/4HANA Data Migration / Landscape Transformation Platform

SAP legacy systems are connected to the SAP Landscape Transformation tool through LAN/ WAN. While non-SAP legacy systems are connected through file upload with excel templates pre-configured by SAP. Transformed data will be inserted into SAP S/4HANA Cloud with standard interfaces like BAPI.

36


Lesson: Migration to SAP S/4HANA cloud

Figure 40: SAP S/4HANA Embedded Migration Cockpit: Cloud (file upload)

If you set up a cloud system, there is an implementation cockpit. In this end-to-end migration cockpit you can select "migrate your data". If you click it, the migration tool starts and asks you to identify relevant migration objects. The migration tool automatically checks what kind of business processes you activated. Based on your selection it only shows you the relevant migration objects. The migration tool generates the file templates, so there is no central storage location. With this, we can ensure that you always have the most up-to-date templates for your migration project. Finally, you start and monitor the data migration process. This phase handles value mapping, the error handling, and the productive load into the system. This is a guided procedure.

Figure 41: Key Takeaways for Implementation Scenarios

There are three different implementation scenarios with different starting points and different prerequisites. What might seem as the best scenario at first might not really be the best for the specific customer; therefore, it is necessary to know all the details around the three different implementation scenarios. The Best Practices for data migration can jump-start migration. Data Services with its capabilities is specifically for complex data migration. It can reduce migration costs, especially using Information Steward.


37


Figure 42: Where to Find More Information About S/4HANA and SAP Activate

The figure, Where to Find More Information About S/4HANA and SAP Activate, lists more information sources. On the top left-hand side is the central SAP S/4HANA page. It's a highlevel entry. Then you have the SAP Activate page. This is the central Activate page: sap.com/activate. There is a community page on S/4HANA with a lot of discussions and a lot of additional material that you can use. The bottom right—hand side of the figure shows the SAP Best Practices page where you can find the Data Services content. All SAP Best Practices are stored there. Even for non-SAP S/ 4HANA purposes, you can take a look there as well. LESSON SUMMARY You should now be able to: ●

38



Unit 2 Lesson 5 SAP Activate



SAP Activate

Figure 43: SAP Activate

SAP Activate is the combination of SAP Best Practices, tools, and Methodology to help customers simplify and accelerate the adoption of SAP S/4HANA. There are three main components to SAP Activate, as follows: ●

●

SAP Best Practices - Ready configured business processes optimized and following industry best practices Methodology - SAP guidance to ensure a well-managed and accelerated implementation and continuous optimization


39


●

Guided Configuration - tools to help activate best practices content and make customized adjustments -

New implementations

-

System conversion

-

Landscape Transformation

Figure 44: SAP Activate - Methodology

SAP Activate methodology is the successor of the ASAP and SAP Launch methodologies and offers the following advantages: ●

●

●

Provides one simple, modular, and agile methodology that supports all SAP S/4HANA transition scenarios Provides full support for initial deployments, and provides support after go-live for continuous business innovation Enables co-innovation with customers and is accessible for partners who can add their own content, perhaps to support specific industry or country requirements

●

Figure 45: SAP Activate - The Innovation Adoption Framework (I): Introducing SAP Activate

40


Lesson: SAP Activate

The goal and the business value of SAP Activate is to provide customers with a faster and less service-intensive initial implementation, whether it is in the cloud or on premise. In addition, the goal of SAP Activate is to provide the customer with the ability to innovate and adopt innovations rapidly throughout the entire product lifecycle. Once you have completed an initial implementation of SAP S/4HANA, you can go back later and apply additional innovations from the wealth of SAP S/4HANA new business scenarios or improved business scenarios and implement them. By applying SAP Activate, you put yourself in a position where you can go back and adapt more and more business scenarios and enjoy the benefits of a faster and less service intensive implementation. This leads to a reduced time to value, whether it is for the initial implementation or subsequent implementations, and a reduced total cost of ownership.

Figure 46: SAP Activate Methodology on SAP JAM

SAP Activate methodology is available to end users through the Methodology Jam community that is open to customers and partners, as well as SAP internal users. The landing page contains overview information, latest updates, and key links. From the landing page, users can navigate to a specific methodology phase and explore the key project management deliverables in the phase. If users want more information, they can access the deliverable details that provide a description of the deliverable and appropriate accelerators that help complete the process. In addition to this structure, the Jam space contains collaboration areas. Users can comment and provide feedback on each item in this group, and can start discussions and engage with SAP experts, or share examples with community. To request access to SAP Activate methodology, use this link: http://scn.sap.com/ community/asap-methodology/blog/2015/07/09/sap-activate-methodology-jam-space-we-are-open-come-in


41


Figure 47: Process Modeling & SAP Activate with Solution Manager

SAP Activate is available with Solution Manager 7.2 or higher.

Note: Customers have to do an update if they are not already in the 7.2 version.

●

Customers ask for process models and pre-configuration

●

SAP delivers SAP Activate -

-

-

-

-

●

●

42

SAP delivers content for all S/4HANA editions; all processes are graphically modeled and extendable; SAP delivers new best practice content for each S/4HANA release Customers view process models in the 1content cloud Customers then go into a private cloud (CAL) and adapt SAP processes with SAP Solution Manager 7.2 to customer requirements. New SAP Solution Manager 7.2 process modeling environment optimal for this job Customers then take delta scoping into their live SAP Solution Manager 7.2 and start build phase SAP Solution Manager 7.2 offers the same trial capabilities as SAP S/4HANA

New customers use the SAP Activate pre-configuration to accelerate the build phase All SAP Activate content is available with and fully integrated into SAP Solution Manager 7.2



Figure 48: Best Practices for SAP S4HANA, on Premise Edition

SAP Best Practices for SAP S/4HANA provide ready-to-run digitized analytical and operational business processes that cover the fundamental business processes of an enterprise, often referred to as the baseline. Whether you want to streamline your procure-topay processes, optimize your order to cash flow, or take advantage of simple finance, we provide a pre-configuration for many of your business priorities. Let us look at an example of a new financial implementation. You can use parallel accounting to address multi-national reporting requirements. You do not need to create a standard chart of accounts, it already exists. Best practice for closing books, remaining IFRS compliant, tracking debits and credits, and calculating taxes are all pre-configured in your solution. These business processes are easily integrated with other cloud solutions, such as SuccessFactors Employee Central, or the Ariba Network. SAP Best Practices also guide customers through the migration process to SAP S/4HANA, whether they migrate existing SAP ERP solutions from a non-SAP database or from legacy systems. SAP Best Practices covers integration and migration fundamentals. In summary, whether it is a new implementation, a conversion, or a landscape transformation, you do not start from a blank slate. Instead, SAP Activate gives you sample data, clear guidelines, and step-by-step directions on how to move from your current landscape to your goal. With the next releases of SAP S/4HANA in 2016, we also plan to deliver first SAP Best Practices for Line-of-Business and Industry extensions on top of the baseline, plus additional knowledge and information on integration and extensibility for User Experience, Business Analytics, and for enhancing SAP processes to fit your needs.


43


Figure 49: Best Practices for SAP S4HANA, on Cloud Edition

SAP Best Practices for SAP S/4HANA provides the system and is responsible for all maintenance and upgrade operations. You benefit from the latest innovations by receiving quarterly updates provisioned in your solution automatically. This option may appeal to you if you prefer standardized business processes and if you want to take advantage of fully deployed business scenarios in the cloud for a quick time to value. Currently, SAP offers best practices for all deployment options of SAP S/4HANA, cloud edition, Enterprise edition, Project Services edition, and Marketing edition. Imagine that you are looking for better insight into your customers. With customer analytics in SAP S/4HANA cloud marketing edition, you can identify interests and create a 360° view of people in your ecosystem. Segmentation of contact data and the preparation and execution of campaigns then support you to transform the gained insight to action. You can transform anonymous contacts into high-value customers and brand advocates. If you are a service provider and you want to manage customer projects, SAP Best Practices for SAP S/4HANA cloud project services edition provides an end-to-end process of selling services, managing staffing, recording working times, and creating customer invoices with all necessary details. Note that the available scope of pre-configured processes for SAP S/4HANA, enterprise edition equals the scope of the on-premise baseline. In addition, the solution scope of SAP S/ 4HANA, marketing edition, and project services edition is fully determined by the available SAP Best Practices. As with the on-premise version of SAP S/4HANA, the SAP Best Practices included with the SAP Activate guide you through the migration, integration, and fine-tuning of SAP S/4HANA.

44



Figure 50: Discover and Download SAP Best Practices Content

The figure, Discover and Download SAP Best Practices Content, shows the different ways to discover SAP Best practises.

Figure 51: Base Scope for Best Practices

The ready-to-run business processes delivered with SAP Activate support core industry requirements and cross-enterprise priorities, for on premise as well as for the cloud. This table provides an overview of the business priorities for which we provide coverage with preconfigured processes.


45


SAP Best Practices baseline supports the requirements of 11 core industries, not including industry extensions. These industries are Consumer Products, Wholesale Distribution, Life Sciences, Chemicals, Mill Products & Mining, Automotive, High Tech, Industrial Machinery & Components, Aerospace & Defense, (Engineering, Construction & Operations), and Professional Services. The detailed breakdown of available pre-configured processes by line-of-business or by endto-end solutions is available through the SAP Activate JAM community or in the business scenario recommendation tool. SAP Best Practices for SAP S/4HANA are tailored specifically to accelerate and simplify the adoption of SAP S/4HANA. Processes delivered with SAP Best Practices support core industry requirements and cross enterprise priorities . The following are the key capabilities: manage multiple geographies, divisions, subsidiaries, and ledgers; global and country-specific content; and analytical content included. Why Now, What Is New In the digital economy every company needs to think about digitizing its business to simplify and innovate its business from operations to business models. SAP Activate gives you the freedom to get started quickly with SAP S/4HANA. Using SAP Activate with SAP S/4HANA offers the following benefits: ●

Provides you with the tools needed for an assisted implementation

●

Continuously supports you in the adoption of latest innovations

●

Runs faster, less service intensive initial deployments, in the cloud or on-premise

●

Allows you to use one methodology for any deployment mode and project size

●

Delivers sample organizational and master data as part of the product to start with model companies


46



UNIT 3

New Implementation

Lesson 1 New Implementation Overview

48

Lesson 2 New Implementation to SAP S/4HANA Exercise 1: Upload File with Data Services

52 59

Lesson 3 New Implementation to SAP S/4HANA Cloud Exercise 2: Upload File with SLT

62 75

UNIT OBJECTIVES ●

Explain the intention of scenarion New Implementation to SAP S/4HANA

●

Explain scenarion New Implementation for SAP S/4HANA

●

Explain the cloud scenarion of New Implementation


47

Unit 3 Lesson 1 New Implementation Overview



New Implementation

Figure 52: SAP Activate - Innovations for new implementations (1)

In a new implementation, whether it is in the cloud or on premise, you want to start with planning, either by yourself or with the system implementer of your choice. You can also use SAP global services to support you with the planning of your implementation. In this plan and advisory phase, SAP provides you with a trial that helps you to explore which innovations are available in SAP S/4HANA and which business processes might be of interest to you. You access the cloud trial using a temporary license. The trial focuses on select business processes: finance, in project services, sales, and marketing. If you are interested in the on-premise version of SAP S/4HANA, we also offer a trial, which you can access via the Cloud Appliance Library or on BlueRay. It is a 30-day trial period that offers a full set of end-to-end business processes. A help function guides you through the product and explains the innovations in SAP S/4HANA. During the trial, you are guided through your operating environment. If you are happy with the trial, you are ready to take the next steps in your journey to SAP S/4HANA.

48


Lesson: New Implementation Overview


You start out with a model company. SAP provides you with various model companies for SAP S/4HANA, for example, we provide a model company for marketing, we provide a model company for project services, and we provide a model company for Enterprise Management. Whatever your starting point is, with the Model Company you have a pre-configured environment. The business processes are ready-to-run. You will benefit from processes that are optimized for SAP S/4HANA. The model company contains an enterprise structure or marketing structure, it has predefined master data, and it comes with ready-to-run business processes, including the respective reporting content and the integration processes to adjacent SAP Cloud solutions that are relevant for these business processes. Once you have explored the Model Company, you pursue a fit/gap analysis. Finally, if you are on premise, you can record your gaps in SAP solution manager 7.2.


After the fit/gap analysis, when you know which business processes are relevant for you, you proceed to the next step, where you scope and configure your solution. When you are on premise, you will activate the business processes relevant for you. In the cloud, you can use the Guided configuration capabilities available with SAP S/4HANA. We have introduced a new concept, which we call self-service configuration. Self-service configuration targets business users that can adapt and view basic settings, such as an organizational structure or master data settings, and can configure them through business user centric applications.


49

Unit 3: New Implementation


One of the key issues in a new implementation is the topic of data migration. Data migration is often costly and time consuming. With SAP Activate, the innovation adoption framework for SAP S/4HANA, we have considered the issue of migration. If your starting point is an SAP ERP system, we have performed the source to target mapping, where we provide you with the predefined mappings from SAP ERP to SAP S/4HANA, with SAP Activate to migrate your data to the target business objects in SAP S/4HANA. If your starting point is a non-SAP legacy solution, we provide you with a canonical format and, from that canonical format, SAP provides the mapping to the target business objects in SAP S/4HANA. In addition to providing you with migration content, we also have integration best practices for integration with adjacent SAP cloud solutions, such as SAP Success Factors, SAP Ariba Network, or cloud for customer.


After migration and integration comes the onboarding of users, whether it is key users, who will function in an expert role within the new solution, or end users, who might be casual users. Onboarding of users is time-consuming and resource consuming in any implementation, and is often underestimated, or performed as an afterthought. We provide you with onboarding and learning content for both casual and expert roles. We use role-based learning content and we make sure that we put a particular focus on business users, because their understanding and grasp of the solution is key to acceptance and endorsement of the business. More in-depth content and moderated learning is available on the SAP Learning Hub.

50


Lesson: New Implementation Overview


Finally, as the last step in this new implementation scenario, you can benefit from an SAP Solution Manager integration to provide monitoring and support and operations with the SAP solution manager. The Solution Manager is where you can add your configuration documentation. In the Solution Manager, we provide process models of the best practices that you consume with SAP S/4HANA and project implementation guidance. Following this initial implementation, you can continue to innovate and go back to the model company, perform another fit/gap analysis in your solution, and configure and adapt additional business processes. Activate sets you up for continuous innovation, with the understanding that the world continuously changes. You have the advantage of the innovations that SAP provides with the SAP S/4HANA. LESSON SUMMARY You should now be able to: ●



51

Unit 3 Lesson 2 New Implementation to SAP S/4HANA



New Implementation for on premise edition / HEC

Figure 58: SAP S/4HANA, On-Premise Edition from Discover to Run

Next is the Discover phase of SAP Activate. In this unit, we concentrate on two main topics. First, we see how the customer accesses and activates a virtual appliance with an SAP S/ 4HANA system that is configured for a model company and is ready to run. It includes sample data for the model company. Next, we look at some ideas for jump-starting the set-up of an on-premise system, and see how to access the latest information on SAP Best Practices for implementing SAP S/4HANA.

Figure 59: Preparing for Your Implementation: Available Trial Systems

52


Lesson: New Implementation to SAP S/4HANA

SAP provides trial systems for different needs - for cloud and on-premise editions. Prospects can choose which deployment option they prefer and can then register and access the respective system. One benefit of doing this is that the software is already installed. Trial systems are based on fully configured systems and include sample data based on SAP Best Practices. This allows users to explore predefined business processes that the different SAP S/4HANA editions support. The trial offerings differ in terms of business scope, technical environment, and the length of the trial period. The cloud edition trial runs on a shared environment and focuses on business highlights and user enablement features. The on-premise version covers the full business scope based on end-to-end scenarios. The on-premise trial runs on individual virtual environments, which allows users to make changes and perform a detailed evaluation. SAP includes role-based guided tours or scenario descriptions to help users to navigate through the system, get to know the modern SAP Fiori user experience, and discover the innovations of the new digital core solution of SAP. There is no need to set up individual prototype systems from scratch. There is no obligation to buy the solution. Available Trial Systems ● Dedicated trials for on-premise and cloud ●

Pre-configured trial systems with real-life sample data

●

Cloud edition trial focus: Easy-to-consume business scope highlights and user enablement

●

On-premise edition trial focus: Full business scope with end-to-end scenarios and implementation experience

Figure 60: Preparing for Your Implementation: SAP Best Practices in Trial System

In the trial system, the SAP Activate Best Practices for SAP S/4HANA are configured for a model company. The software is configured to support a variety of business processes. In some areas, the software is also configured to support business processes with certain country-specific requirements. The trial system has a broad coverage of basic settings out of the box: at present, 51 scope items are configured across the main end-to-end solutions such as accounting and financial close, sourcing and contract management, or quality management and compliance. All scope items are fully configured.


53


The software is also designed and configured to support parallel accounting: International Financial Reporting Standards (IFRS) for group and local accounting. Finally, multi-country activation in one client is supported.

Figure 61: Scoping Your Solution with SAP Best Practices in an on-premise project

We provide guidance for some of the activities in the Prepare and Explore phases of the SAP Activate methodology for implementing SAP S/4HANA. The customer uses SAP Best Practices to guide them through the implementation of SAP S/ 4HANA and lay good foundations for their solution. The customer also uses SAP Solution Manager 7.2 to support the implementation and the complete life cycle. We import SAP Best Practices into SAP Solution Manager and load a project plan as a template for the customer's implementation project. We see how we can use this as a basis for working with changes that result from fit / gap evaluations.

Figure 62: Activating SAP Best Practices in Your Solution

We will follow the customer as they start the activation in their development system. The first step is to activate the solution without demonstration data, and aligned with the scope selected earlier. The customer will use SAP Best Practices solution builder for the activation. Note that the approach here can, alternatively, be used for activation of proofs of concept, sandbox systems, or training purposes. We will not cover these alternatives here, but you can apply what you learn here to these other use cases.

54



Figure 63: Preparing the development client for the Realize phase

Activation of the development system occurs in three main steps. The following is an overview of these three steps. 1. Import SAP Best Practices Reference Content. This includes importing the solution scope file and installation file or files. 2. Align scope. This is where we select the scope items that we want to configure and use in the system. 3. Start the activation. The activation writes the application and configuration data of the selected scope into the system tables in your application system. This makes the business content ready for use. We show you how to do this, and give some tips on what to expect with manual steps, and how to handle typical issues. You can always find exact instructions in the most current administration guide for SAP S/ 4HANA On-Premise Edition. You can find this at help.sap.com, under Enterprise Management, SAP S/4HANA.

Figure 64: Adapting SAP Best Practices and Creating Own Processes

Creating new processes happens with the SAP Implementation Guide, transaction SPRO. Customization happens without programming skills and code modifications. Note that you can also design new processes in SAP Solution Manager 7.2 by combining SAP Best Practices


55


process steps. In doing so, you can reuse existing assignments to executables and configuration. The customer creates their own project IMG with the customizing activities relevant to adapting existing, and creating new processes. SAP Activate recommends an agile realization approach. Refer to the SAP Methodology JAM, SAP S/4HANA on-premise edition for more details on this. You can find more information in the course materials.

Figure 65: Migrating Your Data to SAP S/4HANA: Project Jump-Start with SAP Activate

At this point we have made a jump-start into our project because we have done the installation of SAP S/4HANA Appliance, the Scoping, and Fit/Gap-analysis, the scope alignment and activation of the SAP Best Practices in development client, and the system configuration is done. Customers’ Project Jump-Start ● Successful installation of an SAP S/4HANA Appliance in customers data center ●

Scoping and Fit/Gap Analysis based on a model company with SAP Best Practices and SAP Solution Manager 7.2

●

Scope alignment and activation of SAP Best Practices in development client

●

System Configuration

Figure 66: Migrating Your Data to SAP S/4HANA: Rapid Data Migration: Methodology

56



SAP addresses the traditional problems by providing world-class software that removes the need for lines and lines of custom code. SAP provides a specific methodology, including what to do in each step. This methodology is included in our ASAP methodology. SAP provides predefined migration content and rules for understanding the SAP target system, including required validations and mapping. Migration projects always require some consulting. SAP provides expert migration services consulting. This service is delivered by SAP and partners, for example, Cap Gemini and Deloitte. Whether you are a new customer or an existing customer with new plants or business units, SAP can help you to migrate data into an SAP system. Software SAP provides software, primarily SAP Data Services, that enables you to extract, transform, and load (ETL) data and ensure data quality as you migrate it from one system to another. Best Practice Content In addition to software, SAP also provides Best Practice Content. I have always known that we have a Best Practice organization. I worked with them previously on Best Practice content for SAP NetWeaver Process Integration, but I did not understand the depth of the offering. On the Help portal, there is a tab for "Best Practices". The Overview Page says "SAP Business All-in-One". The content for data migration is found under the Cross-Industry Packages. From there, select Data Migration. This site is an excellent source of information for data migration. The Data Migration Best Practices content has everything you need to get started migrating non-SAP data to an SAP system. Content plays a big role in fast development. The content includes the following: ●

Guides to install data services and other components required for the migration

●

Actual content to load that includes jobs to load data into SAP via IDOCs

●

Mapping tools to help you to map the non-SAP data to the IDOC structure and reports

●

IDOC mapping and structures for objects such as material master, vendor and customer masters, pricing, bill of material, cost element, and some receivables content.

Data Migration Service Data migration is more than the software and technical tool-set. You also need a methodology for the project, testing, and ensuring project success. SAP offers a Data Migration Service and an expert consulting community ready to assist. SAP Data Migration Services consist of a framework, templates, methodology, tools, and expertise to analyze, extract, cleanse, validate, upload, and reconcile legacy data into a SAP ERP environment. SAP Data Migration Services provide an information management infrastructure and enables data governance best practices that remain after the project. SAP Data Migration Services extends the content delivered and the software provided with additional templates, a methodology, and a holistic view of how the data migration project fits in with the overall SAP implementation and how to use data management and governance to ensure that data is a strategic asset, enabling successful business process execution. For a full list of EIM available services, see Consulting Service Details. After data is migrated into an SAP system, you need to decide what to do with the source system. You might ask the following questions: ●

Do we keep the source data on the system?

●

Should we archive it?


57


●

Should the previous system be decommissioned to save costs?

There is a good demonstration of a data migration example using data services, available from the service market place, on the page http://service.sap.com/bp-datamigration. To help you decommission systems, SAP offers SAP NetWeaver Information Lifecycle Management. Migrating Data to SAP S/4HANA: Customers Project Jump-Start

Figure 67: Migrating Your Data to SAP S/4HANA: Customers Project Jump-Start

Now, with the help of Rapid Data Migration another milestone is reached in our project: the Data Migration to SAP S/4HANA.

58


Unit 3 Exercise 1 Upload File with Data Services

1. Upload a file using data services.


59

Unit 3 Solution 1 Upload File with Data Services

1. Upload a file using data services. a) Go to the following folder: \\kpstransfer\HANA\SPS10\student\S4H100. b) Double-click the file Migrate Your Data (On Premise Edition).exe and follow the instructions.

60






61

Unit 3 Lesson 3 New Implementation to SAP S/4HANA Cloud



New Implementation for Cloud Edition

Figure 68: Case Study and Overview: Step-by-Step

Step-by-Step ●

●

●

Self-led discovery experience of SAP S/4HANA, cloud edition SAP Learning Hub and the model company. SAP Best Practices and their value in analyzing Fit and Gaps

●

Guided Configuration App for solution personalization, test, and data load

●

SAP S/4HANA Cloud Marketing Edition

●

End-user onboarding and deployment

Note: Self-led discovery experience, cloud edition, Learning Hub, model company, and so on, is available. But no Implementation Guide (IMG) is applicable!

62


Lesson: New Implementation to SAP S/4HANA Cloud

Figure 69: Discovering SAP S/4HANA Online: Case study overview

The discovery phase is fully embedded into the new end-to-end user experience of SAP S/ 4HANA, and marks the starting point for your SAP S/4HANA implementation journey. It embraces all of the tasks, actions, and events, which typically occur until a prospect decides to subscribe to SAP S/4HANA. The Discovery phase starts with the customer's first contact with SAP S/4HANA and ends with the customer's buying decision. It offers a simplified, modern and homogeneous user experience right from the start. Three Major Steps The Discovery phase offers fast and easy access to hands-on-experience through trial at an early point of solution discovery. The three major steps of the Discovery phase are as follows: ●

Discovering and exploring applications online

●

Evaluating applications in trials in the cloud

●

Scoping applications with experts.

This phase concludes with a prospect subscribing to a specifically scoped solution. From the beginning, SAP S/4HANA comes with a new way to experience its applications. As the customers' team of key users learns about SAP S/4HANA, they realize that it does not matter whether they use their desktop, laptop, tablet, or smartphone to access the data; it always looks and feels correct. The responsive user experience does not stop with online information; it is part of the user interaction paradigm of SAP S/4HANA, called SAP Fiori. A guiding principle of the new SAP Business Suite for SAP HANA is to place the user in the center. Responsive user interaction and comprehensive user experience are two aspects of this new SAP paradigm. Another aspect is providing fast and easy access to an SAP S/ 4HANA system, to experience its applications hands-on at an early point of the discovery phase. This is achieved by offering access to a trial environment, where users can register and walk through preconfigured customer-like business processes, using the SAP Fiori user experience - live and in real time on a running system. The trial experience is enriched with interactive guided tours to show users best practices in using the system. Access to further enablement material (such as Getting Started Demos and a context-based user guidance) is also available to complement the overall trial experience.


63


Figure 70: Discovering SAP S/4HANA Online: Choose Your Trial

SAP provides dedicated trial offerings for the cloud and for the on-premise edition, as follows: ●

Pre-configured trial systems with real-life sample data -

Cloud-trial focus Highlights of easy-to-consume business scope and user enablement

-

On-premise edition trial focus Full business scope with end-to-end scenarios and implementation experience

●

Role-based guided tours or scenario descriptions

Prospects can choose and register for the deployment option they prefer, and then register and access the respective environment. Both trials are based on fully configured systems, and include real-life sample data, based on SAP Best Practices. This allows the user to explore predefined scenarios within the different SAP S/4HANA editions. Role-based guided tours or scenario descriptions help users to navigate through the system, get to know the SAP Fiori-based user experience, and discover the innovations of the SAP new digital core solution. The cloud edition trial runs on a shared environment and focusses on business highlights and user enablement features.

64



Figure 71: Discovering SAP S/4HANA Online: Run Your Cloud Trial

The customer now wants to become acquainted with the Professional Services business scope and the available roles in the system to know how the application works. For that purpose, you register for the SAP S/4HANA cloud edition trial. After a short registration, you have access to the cloud-based trial system and can experience the business functions that you are interested in hands on and in a self-led fashion. Cloud Trial Your cloud trial offers the following supports: Your cloud trial offers the following supports: ●

Quick and easy registration

●

Instant logon to the trial system

●

Supporting assets:

●

-

Introduction video

-

Getting started guides

-

Guided tours

-

Sample data

-

Online help

-

Enablement content

-

Contact SAP button

Reminder e-mail before 14-days trial period ends

"Start your Free Trial Now" takes you to the trial registration process. Follow the instructions to walk through the registration. [Register as Bob Serve / UKC Test Company / [email protected]] At the end of the registration, you can go directly to the trial system by logging on with the credentials provided during the registration process. The first thing to do is to open the "Introduction" tile and watch the introductory video, which quickly explains how the trial works and how to best leverage the assets provided within the


65


trial environment. In the "More" section, you find additional valuable material that will help you explore the solution, for example, guides to getting started and training material. As a member of the customer's project team, you are especially interested in the functionality of the SAP S/4HANA system supporting their consulting business. A guided tour for this functional area is available by selecting the "Guided Tours" app. For the project manager role, two different tours are offered. Select the tour called "Create a Project". A tour guide pops up that will walk you through the business process. Follow the instructions given in the tour. [Follow the tour until step 4 (including)]. At any point, you can leave of the guided tour, explore the available apps and functions, and discover the solution on your own. Choose "Close" to end the guided tour. In this self-led mode, you experience additional functionality that might not be part of a guided tour. The sample data provided in the trial system allows you to navigate and fulfill tasks and transactions in the system. If you need help during your journey through the system, additional support is available from the built-in help and enablement content, which can be accessed by choosing the "Help" icon. If you are finished with your trial evaluation and have queries, you can contact SAP. Choose the "Contact SAP" button that appears when you are in the help mode to contact experts at SAP via e-mail. Your regular trial period in the cloud ends after 14 days. You will receive a reminder e-mail containing follow-up information, as well as a feedback questionnaire. When the 14 days have been reached, your trial user will no longer be valid. If you want to extend your trial, contact the support channel mentioned in the registration e-mail.

Figure 72: Preparing SAP S/4HANA Cloud Implementation: SAP Best Practices (1)

The key users are sent the starter system access URL, user, and initial password by e-mail. Based on the contracted scope (green check marks in the figure, Preparing SAP S/4HANA Cloud Implementation: SAP Best Practices (1)), the starter system is activated with demonstration data for the purpose of exploration and fit/gap analysis. In the figure, the customer has pre-selected Prof. Services, Core Finance, Time Management, and Procure-toPay Scope Items. The activated processes, system configuration, and example organization structures, COA, and master data are based on defined SAP Best Practices, so that the users

66



can immediately work with the system and created transactions. Access the SAP Best Practices documentation from the "Manage your Solution App".

Figure 73: Preparing SAP S/4HANA Cloud Implementation: SAP Best Practices (2)

●

To download of all of the related SAP Best Practices documentation, choose SAP Service Market Place → Solution Packages and search for SAP S/4HANA Cloud Enterprise Edition. Download, unzip the file, and start the index page. Now you have full access to the SAP Best Practices reference content.

Figure 74: Preparing for an SAP S/4HANA Cloud Implementation: SAP Best Practices (3)

The SAP Best Practices reference content provides two elements: 1. Key Documentation ( detailed process, master data, and organization data descriptions) to enable you to understand the actual system configuration: ●

Test scripts by scope item

●

Process diagram by scope item

●

Configuration guides by building block

●

Master data uses by master data type

●

Organizational setup of model company


67


●

Forms used

●

Account determination

2. Configuration Capabilities: ●

●

You can select your individual scope items You can have a fully transparent list of configuration building blocks with all related settings

Figure 75: Preparing for an SAP S/4HANA Cloud Implementation: Case Study Overview

●

The next phase is "Explore". The heart of the phase is to conduct Fit/Gap Analysis with a Gap Solution and Configuration Backlog definition. Data Load is also planned in this phase.

Figure 76: Preparing SAP S/4HANA Cloud Implementation: Validation Instead of Blueprinting

Solution Validation versus Traditional Design In a traditional implementation project, the design process starts with the customer's current processes and requirements. The requirements are mapped to business processes, which are then analyzed by the consultant. The consultant proposes a solution based on the requirements, the functionality of the system, and the consultant expertise. Several iterations can occur before an agreement is reached on the final design. This process occurs with some customer enablement of the system processes, but with limited customer access to the system. The output is a blueprint document that represents the customer needs and is accepted by the customer. The process works well in larger implementation; however, it increases implementation costs. The following inefficiencies are inherent to the process:

68



●

●

●

●

●

●

Effort is required by consultants to understand the legacy system. Effort is required for consultants to explain system functionality without having a working system. Effort is spent on requirements that are no longer relevant, because the new processes are different from the customer's current process. There is a potential for rework once the customer begins testing of the solution and further understands the system best practices. Design complexity is increased to meet requirements that have no or diminished importance in the new processes. The customer does not understand the software as an integrated solution, so can overlook potential benefits.

The Design stream within the SAP Activate methodology flips the process over. The design begins with customer self-enablement to familiarize the customer with the system scenarios that are delivered with the system. Once the customer system is available, the key users then demonstrate the scenarios in the starter system using the delivered data, scenario flows, and test scripts. This process allows the customer to understand the best practice of the system quickly and to begin the translation process of how the system can support their business objectives. Benefits of Design Process The customer also has access to the test system and best practice documentation and continues to learn the integrated system processes at their own guidance. During this period, consulting reinforces the customer learning by coaching and providing deeper understanding of the processes. During their exploration, the customer will identify gaps. Consulting is responsible for using their expertise to propose solutions to the gaps within the boundaries of the solution and contracted scope. This design process has the following benefits: ●

●

●

Customer learning is accelerated, because they have hands on access to the best practice scenarios. Consulting effort is reduced by eliminating requirements gathering and documenting. Design rework is reduced, because the customer has experience with the system processes.

●

Designs are more cost efficient.

●

System configuration during the design process can be reused.


69


Figure 77: Preparing for an SAP S/4HANA Cloud Implementation: FIT/GAP Analysis

How does the Fit/GAP Analysis actually work? The key users conduct solution validation workshops scope item by scope item. In these sessions, the participants go through the SAP Best Practices processes in the starter system. In addition, they are prepared with process diagrams, process descriptions, and so on. Scope item by scope item, and screen by screen, the fit is validated. Gaps are documented and prioritized. Ideally, a solution consultant participates in these sessions to evaluate a possible solution and effort. At the end, the final gap list has to be decided and signed off by business.

Figure 78: Preparing SAP S/4HANA Cloud Implementation: Solution and Configuration Specification

Key users then need to describe and document the to-be process. They can personalize some settings in the started system, that is, the organizational model and COA. They can specify what needs to be done with the self-service configuration apps on their own. All other configurations have to be specified by a service consultant within the given boundary condition for SAP S/4HANA.

70



Figure 79: New Implementation for Cloud Edition

●

At this stage: the "Guided Configuration Cockpit" is in use. This is one of the main differences to New Implementation to SAP S/4HANA on premise.

Figure 80: Scoping and Adapting SAP S/4HANA, Cloud: Guided configuration - Functional overview

In the trial phase we have analyzed the gaps and now we have a to-do list. How do you implement it? There is no Implementation Guide IMG, so how do we do these changes? What you see here is the SAP S/4HANA Guided Configuration. In some documentation, you will also see it named as "Implementation Cockpit". It has different features: ●

"Configure Your Solution" This is for initial implementation and continuous innovation adoption. You pick and choose the business processes you identified before. You can even add additional company code or additional terms, for example. This is the new IMG.

●

"Test Your Processes"


71


This is the testing solution. The solution uses your new customizing over all the Fiori apps on all the Fiori transaction screens and runs it as if a tester sits in front of the screen, uses your new customizing, and runs through a process. At a result it gives you a report. ●

"View the Solution Scope" This evaluates activated business processes and country versions. It is important to keep an overview on what was activated because once the system is activated and you have something configured, you would not activate it again. Every change you made in your settings is noted in here.

●

"Migrate Your Data" You see here the embedded Migration Engine for simple data migration. The Migration Cockpit is behind that "Migrate Your Data" button.

●

"Train & Onboard Users" Here you can find for example guided demos and much more onboarding material for new users.

Note: "Manage Your Test Processes" was recently moved to "Test Your Processes".

Figure 81: Scoping and Adapting SAP S/4HANA, Cloud: Guided Configuration - Key for Content Lifecycle Management

Content Lifecycle Management ensures the activation of updated best practice processes that are delivered by SAP without disruption.The Guide Configuration tile which says "View Your Solution" is where you can check what you have and have not activated. This is actually very important for SAP as well because Content Lifecycle Management protects the system against unwanted changes. This means preconfiguration delivered with best practices, personalization you do from a customer point of view, or new process steps and processes that are added by customer or partners. SAP updates the cloud every quarter. Of course, nobody wants to jeopardize all the settings the customer already made, such as overwriting it with a new process. Therefore Content Lifecycle Management tracks these changes, and whenever something new comes in, and personalization is done, or partner best practices are in the system, it is recognized. All the settings you made stay and nothing gets overwritten.

72



Figure 82: Scoping and Adapting SAP S/4HANA, Cloud: Migrate Your Data

The figure, Scoping and Adapting SAP S/4HANA, Cloud: Migrate Your Data, displays the Guided Data Migration. It is integrated into the implementation cockpit, and it proposes the migration objects automatically. Guided Data Migration ● Execute data migration directly out of “Manage your solution” ●

Data migration objects automatically proposed

●

Installed base customers can connect SAP Business Suite system

●

Template-based approach for new customers

Figure 83: New Implementation for Cloud Edition

We discussed the scoping and migration activities with the onboarding of the users; the next steps in a cloud project would be the deploy and run of the system.


73


Figure 84: Testing, Migrating Data, and Preparing for Go-Live: Deploy - Switch to Production Release

As soon as the testing, the setup, and the configuration is done, the customer can request a productive system. The configuration that you did in the development system is tracked. It will be loaded into the production environment, so you do not have to configure it again. All the configuration in the queue system can be transferred to the production system and just get recreated there for a cut-over plan. The data will be migrated into the productive system. So this is something you do again. First you migrate data into the development system for testing purposes. When you switch to the productive system you do another data migration, so the data is not moved from the development system to the production system. Then the customer enables the access for the end users and the end users verify that all the data is complete. There will be a final approval from the stakeholders and then the productive use can start when all users are activated. Switch to Production Release Procedure ● Request the production system. ●

●

74

Request the loading of configuration into the production environment per the cutover plan. Request the loading of production data into the production environment per the cutover plan.

●

Set up access to the production system for end users.

●

Verify that the data load is complete and verify quality.

●

Receive final approval from the stakeholders to begin productive use of the system.

●

Activate users in the system.


Unit 3 Exercise 2 Upload File with SLT

1. Upload a file using SLT.


75

Unit 3 Solution 2 Upload File with SLT

1. Upload a file using SLT. a) Go to the following folder: \\kpstransfer\HANA\SPS10\student\S4H100. b) Double-click the file Migrate Your Data (Cloud Edition).exe and follow the instructions.

76






77


78


UNIT 4

System Conversion

Lesson 1 Introduction

81

Lesson 2 Aspects for Planning a System Conversion

87

Lesson 3 Different Migration Options

95

Lesson 4 Choosing the Right Option

107

Lesson 5 Migration Services

111

Lesson 6 Best Practices Exercise 3: Migration of Cost Elements

115 123

Lesson 7 Example: Custom Code Analysis Exercise 4: Custom Code Review

129 137

UNIT OBJECTIVES ●

Understand the process of System Conversion

●

Understand the aspects of planning a System Conversion

●

Explain different options to migrate the database to HANA

●

Explain to find the right migration option

●

Describe the migration services avaiable


79

Unit 4: System Conversion

●

●

80

Describe the best practices for System Conversion, in general and for minimized downtime in detail Understand the importance for custom code analysis


Unit 4 Lesson 1 Introduction



Introduction

Figure 85: SAP Activate: Innovations for System Conversions

Let us focus on system conversion, another one of the three scenarios for transition to SAP S/4HANA. System conversion has the starting point where you, as a customer, have an existing ERP system, and you want to use your previous investments in the business processes that you already have implemented in ERP. You want to bring them to the new world of SAP S/4HANA, and then, once these business processes are converted to run on SAP S/4HANA, you want to add more innovation. As was the case for new implementation, with system conversion you can experience a trial of SAP S/4HANA and get a good idea of what is included. You can explore the business processes that you eventually might want to adopt on top of your converted SAP S/4HANA system. You have explored the trial and now want to start the system conversion process. What is next? You have to handle the technical preparation steps to get to SAP S/4HANA, so you will check for add-ons and industries using the maintenance planner to ensure compatibility with SAP S/4HANA. A de-installation tool is available for enabled partners and SAP add-ons. Another preparation step is to check for custom code. A custom code check tool identifies scope and data structures and conflicts, based on the simplification database content. Finally, after all of the preparation steps, you run a test conversion. If the test conversion is successful, you perform the actual conversion and the cut over. In the cut over, you use the database migration option from the software update manager. Once the system conversion is complete, you can explore additional innovation on top of your


81


SAP S/4HANA solution. You can add and configure complementary best practices, meaning new business processes that are already ready to run, bringing together the transactional as well as the reporting world of SAP S/4HANA. You can use the SAP solution manager for operations, for monitoring, and for support.

Figure 86: Process Steps from Project Start to Go-Live: "Activation" of Innovation

Generally, a transition to SAP S/4HANA includes innovations in business scenarios. SAP recommends adopting these innovations, but provides compatibility options. Core Data Services provide compatibility for read access (for example, custom code). Classic SAP GUI transactions remain available. Innovations consumed through SAP Fiori UI Integration to other systems remain.

Figure 87: Process Steps from Project Start to Go-Live: Supported start releases

An SAP Business Suite customer can move from different start releases to the SAP S/4HANA On-Premise Edition. Unicode is needed, due to technical restrictions with S/4 Kernel. The SAP S/4HANA, on-premise edition 1511 system conversion supports one-step procedure (Database, SAP NetWeaver, and application transition in one step) for SAP ERP 6.0 EHP x…7 systems. System Conversion requires a Unicode (UC) source system. Non-Unicode source systems require a two-step approach (first move to Unicode then to SAP S/4HANA, onpremise edition 1511).

82


Lesson: Introduction

Figure 88: Process Steps from Project Start to Go-Live: Technical procedure and semantic adaption

We can distinguish between technical and functional or semantic tasks during the system conversion. The technical installation procedure is based on established lifecycle management tools (Maintenance Planner, Software Update Manager (SUM), and Database Migration Option (DMO)). Because SAP S/4HANA is a new product line, and not the successor of SAP Business Suite, the process in SAP S/4HANA is different. Many of the changes are technical in nature and have no, or limited, effect on peoples' work, and, therefore, do not trigger business change management. Such changes are mandatory when converting a system to SAP S/4HANA. Other decisions are of a strategic nature, determining which version of functional support will evolve into the digital era and provide the capabilities demanded from the unstoppable business process innovation. Where those strategic directions demand change management through adoption, SAP keeps the traditional capabilities available as compatibility scope, enabling a technical migration of these processes and providing time for change management as a customer. Adoption Tasks - How SAP Supports the Customer ●

Simplification List for SAP S/4HANA, on-premise edition 1511 To allow our customers a better planning and estimation of their way to SAP S/4HANA, we have created the "Simplification List for SAP S/4HANA, on-premise edition 1511". In this list, we describe, on a functional level, what happens in SAP S/4HANA to individual transactions and solution capabilities. In some cases, we have merged certain functionality with other elements, or reflected it within a new solution or architecture compared to the SAP Business Suite products. For more information, see Simplification List for SAP S/4HANA, on-premise edition 1511: PDF

●

Conversion Pre-Checks are shipped as SAP Notes to customers who want to convert to SAP S/4HANA. Customers can use these pre-checks to find the mandatory steps that they must complete before converting to SAP S/4HANA. The results list the instances that need to be addressed before attempting the conversion process. The checks are run twice again during the conversion process, both times in the Software Update Manager (SUM). The conversion is stopped if errors persist.


83


●

Implement SAP Note 2182725 and all the related notes attached to it. Make sure to use latest version of this note and regularly check for updates of all attached notes. Implement and run these reports on every system (Sandbox, DEV, QA, PROD) that you want to convert to SAP S/4HANA, on-premise edition 1511. Report R_S4_PRE_TRANSITION_CHECKS.

●

Custom Code Checks are based on the Simplification list concept. Before converting to SAP S/4HANA, on-premise edition 1511, you need to check your custom code against the SAP S/4HANA simplifications. These simplifications are loaded into the Custom Code Check Tool. After you run the tool, you obtain a list of instances where your custom code does not comply with the scope and data structure of SAP S/ 4HANA 1511, on-premise edition.

Figure 89: Process Steps from Project Start to Go-Live: Software Update Manager

Custom code checks, maintenance planner, and so on can be done before you start a conversion project. Custom code check could be conducted months before you start the system conversion in a project phase. Because when you start that conversion, you do not want to analyze tens of thousands of lines of code. You want to start the conversion right away. In the figure, Process Steps from Project Start to Go-Live: Software Update Manager, below the dotted line is the start release and on the top is the target release. This means System Conversion is not a system switch. It is more comparable with a switch to a new release. You do all the preparation steps while the system is up. And even during the up time, the target HANA is already available as well as the shadow system. SUM basically prepares the shadow repository, so that many things can be copied over while the system is still up and running. After the preparation phase there is a sort of a modification log. No new programs, no modifications, no adjustments should be made at this point. You should use the system just for daily business. After this is all completed, you start the downtime. This is where the DB migration starts if HANA is not already in place. This means Table replacement, for example. Also, the entries of the tables will be converted into the new tables. The kernel switch will be converted from the old kernel to the S/4HANA kernel. After the system is up again, there is a process called "postprocessing". You still might want to do adjustments, do your user acceptance test, let the first key users on it, and check that everything is okay. Then the customer can make a final backup for recovery. Then you open the system for the business users and continue with the process.

84


Lesson: Introduction

Figure 90: Process Steps from Project Start to Go-Live: Custom Code Check

The Simplification Database To support the customer to detect which custom code needs to be adapted when moving to SAP S/4HANA, on-premise edition, a customer can verify the current custom code based on the offered custom code analysis tools (as part of the NW 7.50). The customer can verify whether the current custom code complies with the SAP S/4HANA data structures and scope. In the context of custom code management, a central component is a data store called "Simplification Item Database" that contains information about the changes that have taken place between the classical Business Suite and SAP S/4HANA. The relevant Custom Code Management Tools are included in SAP NetWeaver 7.50. Note that, in the current phase, the customer needs an NW 7.50 installation to execute the custom code check. Cloud-based code analysis is planned for the future. The development entities adapted in SAP S/4HNA, on-premise edition 1511, are maintained as piece list in the SAP development system, and exported as a file and offered on SAP Service Marketplace. The customer can import the file with the relevant SAP entities into the Simplification Database Custom Code Management Tools. The customer can extract customer code from a source system and create a similar file with this information (see SAP note 2185390 for further details). This custom code extractor file can be imported in the NW7.50 custom code check tool. While executing the Custom Code Analysis Tools on the customer side, the information about the current custom code base are checked against the content of the Simplification Item Database. This custom code information includes modifications and enhancements to SAP code, as well as customer-owned main objects, respective where-used list information, and possibly, available usage information (UPL). As results of this Custom Code analysis, an appropriate analysis result is provided in an ALVtype list (including XLS download opportunities). Besides the pure listing of customers code entities, which do not comply with the SAP S/4HANA data structure and scope, additional information (based on SAP notes) and recommendations will be included in the resulting list. The customer will be able to navigate from a dedicated custom code analysis result to a corresponding SAP Note. The dedicated SAP Notes explains the technical change and how the related custom code needs to be adapted.


85


Based on the individual custom code analysis results and the provided adaption recommendations, the customer can plan and adapt the custom code to comply with the SAP S/4HANA data structures and scope. LESSON SUMMARY You should now be able to: ●

86



Unit 4 Lesson 2 Aspects for Planning a System Conversion



Aspects for Planning a Migration Project

Figure 91: Project Planning Aspects: SAP Data Volume Management (SAP DVM) - migrate only required data

There is a benefit from shorter migration duration due to reduced load size. SAP DVM Work Center in SAP Solution Manager offers special focus on SAP HANA. Use SAP DVM for the following: ●

to monitor and control data growth and to minimize data volume

●

To improve system performance

●

To reduce infrastructure and operation cost

The average reduction potential (based on SAP DVM Services with 900 customer systems) is as follows: ●

50% of data older than two years

●

10% of data even older than 10 years


87


Figure 92: Project Planning Aspects: SAP Data Volume Management - Work Center in SAP Solution Manager

Reorg and Compression ●

Is data compression a good option in my environment?

●

Is the planned table/index reorganization really worthwhile or needed?

●

Expected SAP HANA size

Reduction Potential ●

Manual and automated creation of best practice documents

●

Time based data distribution templates

●

Focus on quick-wins for SAP HANA

Forecast and Simulation ●

Allows forecasting of future system size

●

Considering SAP HANA migration and SAP DVM activities

Plan and Track the Success of DVM Activities ●

Define project KPIs before SAP DVM activities are started

●

Visualize trend on KPIs against overall reduction targets

SAP Data Volume Management (DVM) is included in SAP Solution Manager 7.1 SP12 onwards, available for Enterprise Support customers. For more information, see: http:// www.service.sap.com/dvm. SAP DVM: Additional Tools and Options SAP DVM offers additional tools and options, especially for SAP HANA, as outlined below. We recommend that you begin to work on the reduction of data volume 6 to 12 months before the actual SAP HANA migration. Reorganization and Compression (available for IBM DB/2 UDB for Linux, UNIX, and Windows and Oracle).

88


Lesson: Aspects for Planning a System Conversion

●

Options: Simulate database reorganization or compression; to identify the most suitable reduction method, simulate potential reduction by migrating current any DB to SAP HANA.

●

Results: There is a graphical overview of the potential data volume reductions; statistical information to see how much data you could save.

Forecast and Simulation ●

Options: Simulates the future size of a system by using different parameters (such as moderate archiving approach); simulates cost savings after implementing proposed SAP DVM measures; simulates the potential reduction by migrating current database to SAP HANA.

●

Results: Displays the impact of planned measures (such as data archiving, SAP HANA migration).

●

Reduction Potential

●

Options: Analyzes current system data focused on easy-to-implement reduction potential for SAP HANA (quick-wins); alternatively, calculate a saving potential for selected data based on SAP Best Practice residence times.

●

Results: Provides necessary background information for implementation, and reveals all relevant data reduction methods (deletion, summarization, avoidance, archiving).

Time based Data Distribution ●

Options: Understand the 'Age Footprint' of your system landscape; and quickly make decisions on potential savings.

●

Results: Quick view on data 'maturity' provides necessary background facts for residence time discussions, and helps identify archiving backlogs (such as due to data quality).

●

Improvement Projects

●

Options: Define technical project scope and intended target KPIs (such as future size of a system, application areas, and tables in scope of project).

●

Results: Provides project tracking capabilities and trend analysis, and reveals potential risk areas, which are behind planned progress.


89


Figure 93: Project Planning Aspects: SAP Data Volume Management - Data Archiving as leading measure

It is very important to archive objects and there are programs available for that. Archiving Objects: 99% of the top 10.000 biggest SAP tables across all customer ERP systems are covered with archiving and / or deletion programs. Another aspect of Data Volume Management is Custom Data. Custom Data 33 % of the 100 biggest tables are customer tables. Normally customers store additional data in here, but often nobody cares about cleaning it up or deleting or archiving data from these Ztables. They just grow. Age footprint: 50 % of customers ERP system data (across all industries) is older than two years. Basis data: 22% of data in the system is basis data. This means for example, IDocs, Application Log, Spool, Change Docs, Change Pointer, Workflow…). Even if a IDoc was submitted successfully, like when we use it in the data migration, they are still stored in the IDoc inbound with their data, with their IDoc status, etc., spooling from the printer, pure application log. We can archive files with Hadoop to get the system as small as possible before you start the system conversion.

Figure 94: Project Planning Aspects: Further important aspects and considerations

Check supported platforms, releases, add-ons, and possible restrictions.

90



●

Make sure your product is released on SAP HANA and restrictions do not apply

●

Check if your add-ons and third-party products are supported on SAP HANA For this, see Product Availability Matrix (PAM) for your product at http://service.sap.com/ pam.

●

If not, check if Add-On Deinstallation would be an option (offered for certain add-ons).

●

Not all add-ons are currently supported in the SAP HANA database. Therefore, we recommend that you check this early (for example, by checking table CVERS). For more information, see the following SAP Notes: ●

SAP ERP: SAP Note 1820906

●

SAP CRM: SAP Note 1820903

●

SAP SCM: SAP Note 1821797

●

SAP SRM: SAP Note 1820905

●

SAP NetWeaver AS ABAP 7.4: SAP Note 1826531

●

SAP NetWeaver AS Java 7.4: SAP Note 1850345

●

SAP NetWeaver AS ABAP 7.5: SAP Note 2156130

●

SAP NetWeaver AS Java 7.5: SAP Note 2156543

●

For third-party products, see SAP Notes 1855666 and 1896062. We strongly recommend that all other partner add-on products are certified for SAP HANA.

Procedure for Add-On Deinstallation The new PAM attribute is "Ready for SAP HANA". The following is the procedure for Add-On Deinstallation: ●

●

●

●

●

●

●

Check if Add-On can be deinstalled. System must be up-to-date (for example, system based on SAP NetWeaver 7.0 or higher) - for more information, see SAP Note 2011192. System must be ready (→ verified by SPAM/SAINT checks). Add-On must be released for deinstallation (Add-On-specific SAP Note exists and has been worked through, installation package contains deinstallation marker (otherwise, update required), Add-On must not be required by other installed Add-On). Download SPAM update and update SPAM. Remove what hinders deinstallation (such as open transport requests or usage of parts outside of Add-On). Deinstall Add-On. Add-On can optionally be reinstalled after deinstallation.


91



Sizing gives you a comprehensive output on what kind of hardware you have to have. Scale-up means larger and larger hardware; scale-out means several HANA boxes side by side hosting one schema. It is very important to do hardware provisioning as early as possible.


SAP HANA tailored datacenter integration enables customers to preserve investments in shared storage architecture. SAP Note 1793345 describes several options (greenfield sizing and brownfield sizing, which is quick and easy) that are described in detail in further referenced SAP Notes. The sizing report might be an option if the last run is outdated. The following are the restrictions of entry-level compared to premium models: ●

Only single-node systems supported

●

Only 2-socket servers with at least 8 cores/CPU supported

The usage of own switches might be relevant to reduce cost for scale-out systems.

92



For non-production systems, see http://blogs.saphana.com/2014/08/12/cost-optimizedsap-hana-infrastructure-requirements-for-non-production-usage/. The main differences compared to production system requirements are as follows: ●

RAM at least 128 GB

●

No certified storage mandatory

●

File systems GPFS, NFS or XFS; alsoE5 or E7 CPUs

The SAP HANA HW Configuration Check Tool allows you to check if setup of certified HW components fulfills the planned KPIs (such as storage KPIs, intranode, network KPIs), when you have the hardware ready on which the future SAP HANA system is intended to run. For installation, customer requires SAP HANA installation certification. For more information, see the following: ●

Overview PPT: http://scn.sap.com/docs/DOC-63140

●

FAQ: http://scn.sap.com/docs/DOC-62942


The following procedure is shown in the figure above: ●

●

●

●

Capture the Custom Code Footprint, for example, via Custom Code Lifecycle Management; this provides information about the overall number of Custom Code Objects in all systems and about the usage of these objects. Reduce the scope, for example, via Usage Procedure Logging (providing detailed usage information), ABAP SQL Monitoring, decommission of unused code, using the decommission cockpit within Custom Code Lifecycle Management. Identify the impacted objects, for example, via Custom Development. Management Cockpit, Code Inspector, ABAP Test Cockpit. Focus on those objects that are critical for the business Via SQL Performance Tuning Worklist

SAP Tools The tools offered by SAP include the following:


93


●

●

●

●

●

●

ABAP SQL Monitor (provides full transparency of running SQL statements in a production environment, can run in production due to highly optimized data collection, also before migration to capture aggregated SQL runtime data over longer period of time) - provides dynamic usage data, and allows download of collected data into a file. Usage and Procedure logging (UPL) logs user activity to provide a comprehensive view of what transactions, reports, and function models are being used, and how frequently, without a measurable performance impact (Kernel-based logging); identify unused code. New decommission cockpit within Custom Code Lifecycle Management functionality in SAP Solution Manager (available in SAP Solution Manager 7.1 SP12), helps to identify redundant or obsolete custom code and to decommission objects. ABAP Test Cockpit: static code inspector checks (detecting potential functional issues and performance optimization potential - can be run to prepare a migration (by running a code inspection in a DEV or TST system) and to optimize code after the migration, also by running it in a TST or DEV system). SQL Performance Tuning Worklist (possible to combine SQL Monitor data [via upload of data collection file from SWL Monitor] with result of static code analysis [from ABAP Test Cockpit], creation of ranked worklist for SQL performance tuning - before and after migration). Listed tools available as of SAP NetWeaver 7.02 (SP14) - via ST-PI variant, SQL Monitor also available for lower releases (such as SAP NetWeaver 7.00), decommission cockpit available in SAP Solution Manager 7.1 SP12.

Figure 98: Project Planning Aspects: Example of project plan for classical migration

It might be advisable to reiterate single cycles or to go back from one cycle to an earlier cycle, and to optimize single parameters or options based on the learnings obtained in later phases. Your business department should be involved in tests and simulate "work" with applications running on already migrated test systems. LESSON SUMMARY You should now be able to: ●

94



Unit 4 Lesson 3 Different Migration Options



Different Migration Options

Figure 99: Migration Options & Tools: Example scenario: System Before Upgrade / Migration

The figure, Migration Options & Tools: Example scenario: System Before Upgrade / Migration, is an example scenario. Before the upgrade there is an ECC7.02 system on a MaxDB database. Now the customer wants to update the system to the latest release and then to migrate his database to SAP HANA.

Figure 100: Migration Options & Tools: Different ways to migrate SAP ABAP systems to SAP HANA?


95


There are different opportunities to reach the target to upgrade your ECC system and then mirgrate to SAP HANA. One option is new installation: This can be a greenfield approach or a transformation. The classical migration first upgrades the original system and then migrates the database to SAP HANA. The one-step option combines upgrade and database migration using the Database Migration Option (DMO) option of Software Update Manager (SUM).

Figure 101: Migration Options

First we are looking on requirements for the migration.

Figure 102: Migration Options & Tools: Preparation - single-stack + Unicode required

SAP HANA not supports dual stacks. If you do the DB migration to HANA, only the ABAP stack is supported. If you want to do a System Conversion to SAP S/4HANA, your system has to be on Unicode.

Figure 103: Migration Option A: New Installation + Selective Migration

The first option is to install a new system and then migrate the data to SAP HANA.

96


Lesson: Different Migration Options

Figure 104: Migration Options & Tools: 1. New installation + transformation

Business requirements may indicate that existing solution landscapes have to be changed to fulfill current objectives. This approach integrates Engineering Service Landscape Transformation. Management or SLO consulting services with transition to SAP HANA offering to support deployment of SAP HANA within solution landscape, as a means to address the business requirements. SAP Landscape Transformation Management services offer a variety of options to reduce the effort required to build a targeted solution landscape, including shell copy, carve-out, and consolidation. Shell creation with carve-out options can help to reduce size of the targeted infrastructure. The consolidation option can help to reduce number of total systems within solution landscape. The benefits are as follows: ●

Migrate only specific data (such as open documents and completed processes of last two years) without business disruption.

●

Combine data cleansing, and leave unused master data behind.

●

Introduce new business processes (new general ledger).

●

Harmonize data as part of the migration (chart of account, master data.)

●

Use minimized downtime service (for more information about Near Zero Downtime (NZDT) service, see "best practices") .


97


Figure 105: Migration Options & Tools: 1. New installation + transformation

System Consolidation In addition to value proposition of SAP HANA, reduce TCO and landscape complexity while moving to SAP HANA (for example, system or client merge, client transfer). Selective data migration: ●

●

Agility and flexibility to move just those organizational units of SAP system (for example selected companies or business units), where key value drivers of SAP HANA apply. Focus transition to SAP HANA on some parts of business first, to test-drive and limit potential risk of business disruption.

Figure 106: Migration Option B: Classical Migration

The second option is to use the classical migration: first upgrade the system to the appropriate release and then migrate the database to SAP HANA.

98



Figure 107: Migration Options & Tools: 2. Classical migration: Overview

If the customer wants to move to SAP HANA as database, NOT SAP S/4HANA the Software Provisioning Manager can be used. It is just a technical conversion, there is no big impact on the end user from a functional perspective. It is a basic OS/DB migration.

Figure 108: Migration Options & Tools: 2. Classical migration: Maintain - Plan

SAP has a support page for the Maintenance Planner. The customer selects the target environment and gets back the stack.xml. Stack.xml is provided to the Software Update Manager later on in order to start the System Conversion. Without the stack.xml, you cannot do a System Conversion. If the Maintenace Planner returns with a red light, it is not possible to execute a System Conversion.


99


Figure 109: Migration Options & Tools: 2. Classical migration: Maintain - Perform

As usual for update or upgrade projects, check guides if additional OS or database updates are required; for example, check if the database of the source system is not supported according to the PAM of the target SAP release.

Figure 110: Migration Options & Tools: 2. Classical migration: Migrate - Sequential process illustration (highlevel)

Heterogeneous system copy is offered by the Software Provisioning Manager. The procedure comprises the following: ●

●

●

100

Export into DB-independent load from the source system. Import exported data load, including database-specific conversions, optionally with installation of new system. Optionally, combined with Unicode conversion.



Note: Make sure to always use latest tool versions.

Figure 111: Migration Options & Tools: 2. Classical migration: Migrate - Parallel process illustration (high-level)

Now the customer wants to switch the DB server. Once the installation is started, and while the export is still running on a shared drive, DB load is already imported on the target system. This has the benefit of a smaller business downtime because you don't have to wait until the export is finished.

Figure 112: Migration Options & Tools: 2. Classical migration: Migrate - Process in Software Provisioning Manager

The figure, Migration Options & Tools: 2. Classical migration: Migrate - Process in Software Provisioning Manager, is an overview on the Software Provisioning Manager. This is for the DB migration if you want to do it in separate steps.


101


Figure 113: Migration Options & Tools: 2. Classical migration: Migrate - Process in Software Provisioning Manager

There is an opportunity to split files. This is helpful when you split the packages for the import afterwards. With smaller files this is a better use of your jobs in the system.

Figure 114: Migration Options & Tools: 2. Classical migration: Migrate - Technical details: Involved tools

For more information, see http://scn.sap.com/docs/DOC-34258. R3LDCTL Key objective: make information of source system database tables available for migration tools offline.

102

●

Reads ABAP Dictionary structures from source database.

●

Creates structure (STR) files that describe definition of tables, indexes and views



●

●

Creates database-specific template (TPL) files that contain Data Definition Language (DDL) commands that define data structures. Available via kernel of SAP application server ABAP.

R3SZCHK Key objective: calculate size of target database. ●

Calculates space requirements of ABAP tables and indexes for target database (stored in EXT files) and rough estimation of overall database size (DBSIZE.XML).

●

Available via kernel of SAP application server ABAP.

●

R3ta Table Splitter

●

Key objective: accelerate load by preparing parallel load (optional).

●

●

Can generate multiple WHERE conditions that define work packages (stored in WHR files) for parallel R3load processes. Available via kernel of SAP application server ABAP.

Package Splitter Key objective: splits default packages into smaller parts to reduce overall runtime of export and import. ●

Splits packages using existing structure files (STR + EXT).

●

Default, but can be skipped for small databases.

●

Part of software provisioning manager.

MIGCHECK Key objective: make sure import was successful. ●

●

●

Verifies that import of all packages was at least started and that all objects (tables, views, indexes, primary keys) are successfully created and loaded in database. Optionally, you can perform further checks (such as using Table Checker to very if number of exported rows is same as number of imported rows). Part of software provisioning manager.

MIGTIME (Time Analyzer) Key objective: provide statistics about run-times of load processes (calculates run-time per package). ●

Part of software provisioning manager.


103


Figure 115: Migration Options & Tools: 2. Classical migration: Migrate - Technical Details: Process Flow of Export

In the figure, Migration Options & Tools: 2. Classical migration: Migrate - Technical Details: Process Flow of Export, you can see how the different features would run after another.

Figure 116: Migration Options & Tools: 2. Classical migration: Migrate - Latest improvements

For more information about option to securely store connectivity data in Software Provisioning Manager, see SAP Community Network: http://scn.sap.com/community/itmanagement/alm/software-logistics/blog/2015/04/14/sap-hana-client-software-differentways-to-set-the-connectivity-data. For more information about table comparison with SUM, see SAP Community Network: http://scn.sap.com/community/it-management/alm/software-logistics/blog/2015/07/07/ dmo-table-comparison-and-migtools.

104



Figure 117: Migration Option C: One Step Upgrade + Migration with DMO

The last option around the conversion is the one-step approach. Basically, it is the Software Update Manager (SUM) where you can do DB migration in one step.

Figure 118: Migration Options & Tools: 3. One-step upgrade and migration with DMO of SUM - Overview

Pure in-place migration, only source or target can run at same time (exception: SAP Business Warehouse migration with delta queue cloning)

Figure 119: Migration Options & Tools: 3. One-step upgrade and migration with DMO of SUM - Phases during procedure


105


Benefits of this option are that you have only one maintenance phase (not several). This helps to reduce business downtime (TCO). The in-place migration keeps application server and SAP System ID stable for a lower impact on system landscape and interfaces: only the database server is changed. The original database is kept and can be reactivated as fallback. This reduces the risk, no restore required, more time for testing before cutover. Lower prerequisites for SAP and DB start releases needed. This reduces the total cost of implementation because no additional licenses for traditional database update are needed.

Figure 120: Migration Options & Tools: 3. One-step Upgrade and Migration with DMO of SUM - Benefits

The figure, Migration Options & Tools: 3. One-step Upgrade and Migration with DMO of SUM Benefits, shows the benefits of the one-step upgrade and migration with DMO of SUM. LESSON SUMMARY You should now be able to: ●

106



Unit 4 Lesson 4 Choosing the Right Option



Choosing the Right Option

Figure 121: Choosing the Right Option: Standard recommendation - ABAP systems

DMO of SUM (General Recommendation) In typical use cases, DMO of SUM is the best choice and recommended by the SAP product strategy. It is the standard procedure for migrations to SAP HANA, where you benefit from a simplified migration to SAP HANA with minimized overall project costs and with down-time optimized DMO for demanding SLAs. Classical Migration (Reasonable Alternative) If DMO of SUM does not fit your requirements, consider using classical migration with Software Provisioning Manager (continuously improved for this migration use case). For Java systems, use the classical migration. Choose classical migration over DMO of SUM if, for example, no big bang approach (as offered with DMO) is desired. For certain use cases or customer scenarios, the "Reasonable Alternative" is a useful choice and supported and confirmed by the SAP strategy. New installation + Transformation (Possible Exception) The "Possible Exception" is only useful for specific use cases. It is supported by SAP, but limitations might apply. In addition, there are further migration procedures for special use cases, such as system consolidation or carve-out with SLO Shell Creation.


107


Figure 122: Choosing the Right Option: Possible Technical Requirement Aspects for Selection of Individual Migration Approach

The following questions could support you in the selection of an appropriate migration toolset: ●

What is the SAP release and support package of existing system?

●

What is the Unicode system?

●

Do you plan to rename system ID (SID) of your productive SAP system during migration?

●

●

●

●

●

108

Do you plan to reuse existing application server hardware for target system? Do you want to perform in-place migration? Is the operating system on existing hosts supported according to Product Availability Matrix (PAM) of target SAP release? Is the database of source system supported according to PAM of target SAP release? Do you want to perform a full migration of the complete system, or do you want to migrate only some of the data? Do you expect a significant downtime due to a large database volume?


Lesson: Choosing the Right Option

Figure 123: Choosing the Right Option: Decision Matrix for Typical Scenarios

For more information, see guide End-to-End Implementation Roadmap for SAP NetWeaver AS ABAP available at: http://help.sap.com/nw74/#section7.

Figure 124: Choosing the Right Option: 1st Example for Using the Decision Matrix

In the situation given in the figure, Choosing the Right Option: 1st Example for Using the Decision Matrix, the system would already be on Unicode. Database upgrade is required, Therefore DMO of SUM is used.


109


Figure 125: Choosing the Right Option: 2nd Example for Using the Decision Matrix

In the situation given in the figure, Choosing the Right Option: 2nd Example for Using the Decision Matrix, the system is also on Unicode. This is a selective migration and will be a New Implementation or Landscape Transformation.

Figure 126: Choosing the Right Option: 3rd Example for Using the Decision Matrix

The downtime optimization in the figure, Choosing the Right Option: 3rd Example for Using the Decision Matrix, is valid for the migration of the database to SAP HANA not for the migration to SAP S/4HANA. The DMO of SUM that you use for the conversion of the database to SAP HANA has a downtime optimization feature. For this downtime optimization feature, "Service approach/ NZDT", it uses SAP LT technology. This minimized downtime approach has change pointers writing in a log and as soon as the new database is activated, you have a delta recording. On a cut-over-weekend you can start the re-run of the delta-logs. For SAP S/4HANA, this is not yet possible because the conversion programs cannot run in this delta mode. This is because of the different table structures between ECC and SAP S/ 4HANA. LESSON SUMMARY You should now be able to: ●

110



Unit 4 Lesson 5 Migration Services



Migration Services

Figure 127: SAP HANA Migration Services: Offering from SAP Active Global Support

Consider the following benefits from SAP HANA migration services, based on best practices: ●

One end-to-end methodology – implemented in SAP Solution Manager and SAP Activate

●

Project management – define, drive and control milestones and Q-gates

●

●

●

●

Architecture & infrastructure – define infrastructure and landscape architecture to fulfill requirements of migration as well as operation after Go-Live Migration run along plan – ensure migration tasks are executed along proven plan and approach and based on best practices Performance & scalability – ensure performance, throughput, scalability, availability + define technical architecture and infrastructure Operational readiness – ensure procedures, tools, skills are adequate to run new solution safely + efficiently

SAP Solution Manager Roadmap for Migrations SAP Solution Manager Roadmap for Migrations to SAP database includes the following: ●

Migration tasks for all work areas of a migration project

●

Project management tasks for TQM

●

Quality gate definitions


111


●

Task-related detailed information ("accelerators") such as: -

Checklists, questionnaires supporting run of different tasks

-

Templates for different topics in project

●

Best practice documents (performance, ...) and whitepapers

●

Explanation of appropriate services by phase and task area

●

Knowledge transfer elements and FAQs

●

Reference to further relevant information including the following: -

-

SAP Notes (such as latest information about product options, installation requirements, …) SAP documentation (such as about installation, security, ...)

Figure 128: SAP HANA Migration Services: Offering from SAP Active Global Support and Consulting

The Discovery Workshop is related to the trial version where the customer is still making decisions. In the Innovation Strategy phase with the Business Scenario you can use the trial system and do a fit/gap analysis and iterations. The Target Structure workshop covers: How many systems are needed, which hardware, which sizing, and so on. The Strategic Roadmap is where the customer makes a calculation. When the customer made a decision the next steps are: Migration Planning and Readiness Check. Readiness will run as part of the Maintenance Planner, for at least the technical checks, which tells the customer when to start with the conversion? All these are services provided by SAP or a client partner.

112


Lesson: Migration Services

Figure 129: SAP HANA Migration Services: Rapid deployment solutions - General introduction

With Rapid deployment solutions you can jump-start your project. In SAP Activate, you see Methodology, Guided Configuration, and SAP Best Practices. You don’t see Rapid deployment solutions. The reason for this is that rapid deployment solutions are available, at least this is the branding, for non-S/4HANA! So in BW, Suite on HANA, all these packages are out there; that's also why this rapid data migration packages have this "rapid" upfront in the name. They all tackle non-S/4HANA systems. If we talk about such a bundle for SAP S/4HANA, it's Best Practices. So you won't find the naming "rapid deployment solution" any more. With Fast and Simple, we have a priced service, or the time-to-value, the tools, and the coded assets. This is the Best Practices content that you can import into data services, for example. This is what we mean with content enablement software services, this is the complete package.

Figure 130: SAP HANA Migration Services: Rapid Deployment Solutions - Summary

There are many Rapid Deployment Solutions for different areas as SAP S/4HANA (on premise or cloud) or pure migration to SAP HANA database. There are many rapid deployment solution packages for SAP HANA in place for the following: ●

SAP Business Suite

●

SAP S/4HANA -

On-premise or into SAP Cloud

RDS for SAP HANA migration use standard migration procedures (Database Migration Option of SUM [including downtime optimized DMO] and classical migration using Software Provisioning Manager). These services are optionally enriched by consulting services. You can find additional information on http://service.sap.com/rds.


113



114



Unit 4 Lesson 6 Best Practices


Describe the best practices for System Conversion, in general and for minimized downtime in detail

Best Practices

Figure 131: Best Practices: General (1)

Latest Tools It is really necessary to always use the latest tool versions. ●

●

Right before test cycle, download latest version of SUM, Software Provisioning Manager, R3load, … Then, during running test cycles, avoid short-term changes of used software, if not explicitly requested by SAP support -

SAP HANA revisions

-

SAP kernel

-

Involved tools (SUM, R3load, R3trans, Software Provisioning Manager, …)

S/4HANA is relatively new so there are constant updates to this toolset. Use the latest HANA revision and take the latest SAP kernel as well. Key Performance Indicators Test key performance indicators beforehand, such as the following: ●

●

●

●

Network bandwidth Source DB read performance (SAP Note 1875778, DB-specific settings) – crucial for overall runtime Perform SAP HANA performance check with hardware configuration check tool (SAP Note 1943937) Test disk performance of source DB and primary application server


115


Network bandwidth as a performance indicator is very important. Sometimes it looks like the migration is very slow but in reality it is a network issue DB read performance is crucial for DB export. The export is often one of the most timeconsuming parts of migration. If you suddenly start reading huge amount of data from the database in one go, the database performance slows down because this is not what databases are designed for. There are a lot of settings you can make upfront before you start an export that speed up the database migration from an export perspective. With HANA performance check the customer can proof whether SAP HANA is correctly set up when the hardware is in place.

Figure 132: Best Practices: General (2)

Scope for Table Comparison with SUM ●

Compares contents of tables on target database with table contents on source database

●

Integrated into DMO procedure, but can also be used standalone with classical migration

●

If used, consider to adapt scope of comparison: -

To optimize, skip comparison for repeated test runs, or compare only contents of selected tables (such as important application tables) Comparing table content will extend downtime, so it is not recommended to enable table comparison for a DMO run on a productive system – nevertheless, you may consider running table comparison in a productive run as well, such as for certain tables if it is required to prove that content is identical

Table comparison with SUM compares the contents of tables on the target database with the table contents on the source database, on basis of calculated checksums. It is integrated into the DMO procedure, but can also be used standalone with the classical migration. A prerequisite is that no Unicode conversion has taken place (that is, source and target database are either both Unicode, or both non-Unicode). To optimize the runtime, consider adapting the scope of the comparison, as the more tables that have to be compared, the longer the affected phases will last. You can skip the comparison for test runs, or compare only the contents of selected tables (such as important application tables). For more information, see the section "Table Comparison with SUM" in the "Upgrade Guide DMO for SUM" respective section "Table Comparison with Software Update Manager" in the "System Copy Guide".

116


Lesson: Best Practices

Figure 133: Best Practices: Minimizing downtime - Overview of Available Measures

Delta-queue cloning means a complementary option for classical migration and DMO of SUM, available for SAP BW systems only. The concept is to create a parallel shadow system that gets migrated and intermediate changes are handled with delta queues in the SAP BW source systems. Automated post-copy activities and automated delta queue cloning lead to an overall reliable, simplified, and fast procedure.

Figure 134: Best Practices: Minimizing Downtime - DMO: Benchmarking tool

Benchmarking Tool The benchmarking tool offers the following: ●

Fast and easy method to check and optimize migration speed prior to actual DMO run

●

Select specific tables or use a specific percentage of all tables


117


●

●

You can benchmark export from source system only – or benchmark export and import into SAP HANA Source system may continue to run (usage during uptime): -

Helpful to test export speed of problematic tables in production before migration

-

However, test results will be more accurate, if source system is down

For more information about the benchmarking tool, see http://scn.sap.com/community/itmanagement/alm/software-logistics/blog/2015/07/01/dmo-introducing-thebenchmarking-tool.

Figure 135: Best Practices: Minimizing downtime - DMO

Optimizations of standard DMO are applicable for all application systems supported by DMO (SAP Business Suite, SAP NetWeaver, SAP BW). Recommended Approach ●

First, optimize downtime of standard DMO run. Before DMO run, use the benchmarking tool to learn about possible bottlenecks & optimizations: 1. Find optimal number of R3load processes to match resources of your SAP application server 2. Perform complete run in benchmarking tool with this number of R3load processes to create table duration file 3. Perform run in benchmarking tool with table duration file to optimize table splitting (split calculation based on real migration duration instead on table size) – no manual split of tables, but rely on splitting applied automatically by DMO procedure

●

118

During the DMO run, use real-time monitoring during all steps to check hardware utilization



●

Depending on identified bottlenecks, consider to run DMO on Additional Application Server (such as SAP HANA Standby Node) and further hardware improvements (such as usage of 10 Gigabit network adapters)

Downtime Optimized DMO Only if the recommended approach does not work out and you really face hard and urgent downtime requirements, consider downtime optimized DMO ●

●

●

●

Downtime optimized DMO available on request for SAP Business Suite systems, not supported for SAP BW With downtime optimized DMO, efforts for tests increase considerably Normally, standard DMO suffices, so consider putting extra spending in better hardware instead To avoid fast growth of corresponding delta queue, do not plan activities causing many changes of data on your production system during change recording

To define the number of R3load processes, start the benchmarking tool, select to migrate only a small percentage of the source DB, and raise the number of R3load processes until you reach saturation of either the CPU or the network. For more information about optimizing the standard DMO run and the benchmarking tool, see the DMO guide. For more information about downtime optimized DMO, see http://scn.sap.com/ community/it-management/alm/software-logistics/blog/2014/09/08/dmo-downtimeoptimization-by-migrating-app-tables-during-uptime-preview For SAP BW, see the blog "DMO: optimizing system downtime" in SAP Community Network at: http://scn.sap.com/community/bw-hana/blog/2015/03/17/dmo-optimizing-systemdowntime.

Figure 136: Best Practices: Minimizing downtime - Downtime optimized DMO


119


Uptime and preparation is longer, but the time for migration can be reduced; nevertheless, overall business downtime is determined not only by technical migration, but also by update, which would stay fixed with this procedure.

Figure 137: Best Practices: Minimizing downtime - Classical Migration

Performance Optimization ●

Consider parallel export/import

●

Consider using additional application servers for export

●

Consider using SAP HANA standby node for import

●

After the migration, analyze runtimes, identify bottlenecks and optimization options (number of R3load jobs, table splitting)

Optimization is applicable for all application systems supported by classical migration procedure (SAP Business Suite, SAP NetWeaver, SAP BW). ●

Downtime-minimized capabilities for SUM (for update, upgrade)

●

Usage of additional shadow database with record & replay:

●

-

Available as of SUM 1.0 SP7

-

Applicable for upgrade as part of classical procedure

-

For more information, see SAP Note 1678565

-

Peak after long-tail: rowstore load

Best practice guide available as part of standard SAP HANA system copy guide and is available standalone at: http://scn.sap.com/docs/DOC-47657.

Best Practice Guide for Classical Migration of SAP NetWeaver AS ABAP to SAP HANA ●

120

Offers further information about involved migration tools



●

Provides best practices about performance improving, table splitting, package splitting, …

●

Including example for optimizing runtime

●

Target group: migration experts

Figure 138: Best Practices: Minimizing downtime - Near Zero Downtime service offering

Supported for SAP ERP and SAP CRM, and available on request. The procedure for the downtime-minimized approach for various landscape transformations is as follows: ●

Database triggers capture changes

●

Clone creation and isolation

●

Upgrade (if required) and migrate clone to SAP HANA

●

Perform online delta replay

●

Finalize the delta replay during the business downtime window

Common Drivers The common drivers are as follows: ●

Extensive downtime needed to support the run of the migration

●

Business downtime is limiting factor

●

Risk reduction desired


121


122


Unit 4 Exercise 3 Migration of Cost Elements

During creation of SAP S/4HANA, many processes have been redesigned. The same applies for the master data, for example for the cost elements. In the days of SAP Business Suite, there were separate master data tables for the cost element for the Controlling part of SAP Business Suite. The names of these tables were as follows: ●

CSKA - Cost Elements (Data Dependent on Chart of Accounts) and

●

CSKB - Cost Elements (Data Dependent on Controlling Area).

In S/4HANA, all accounts are now in the same tables as the balance accounts. Those tables are as follows: ●

SKA1 - G/L Account Master (Chart of Accounts)

●

SKB1 - G/L account master (company code)

That means there is a need to migrate these cost elements. The exercises will show you how the migration works. 1. Find the right position of migration activities within “SAP Customizing implementation guide”. Use transaction code SPRO and the open the SAP Reference IMG. 2. Now we need “Old Cost elements”. That means cost elements of SAP Business suite, which are defined in the table CSKA/CSKB. 3. Use transaction code SE16 to check if your cost element is in the CSKA or CSKB tables. 4. Using transaction code FSS0, check whether your S4## account was set up for each company code: 1000, 1010, and 1710. 5. Look at the SKB1 table (remember that your account S4## was not in the table). Migration Secondary Cost Element 1. Start transactionSPRO and then press F5 to open SAP Reference IMG. 2. Execute Se16 and check the entries for your new cost element in tables CSKA and CSKB. 3. Using transaction, FS00 Edit G/L account centrally, check if your cost elements are real S/4 HANA cost elements. 4. Check the case table, SKB1 using transaction SE16.


123

Unit 4 Solution 3 Migration of Cost Elements

During creation of SAP S/4HANA, many processes have been redesigned. The same applies for the master data, for example for the cost elements. In the days of SAP Business Suite, there were separate master data tables for the cost element for the Controlling part of SAP Business Suite. The names of these tables were as follows: ●

CSKA - Cost Elements (Data Dependent on Chart of Accounts) and

●

CSKB - Cost Elements (Data Dependent on Controlling Area).

In S/4HANA, all accounts are now in the same tables as the balance accounts. Those tables are as follows: ●

SKA1 - G/L Account Master (Chart of Accounts)

●

SKB1 - G/L account master (company code)

That means there is a need to migrate these cost elements. The exercises will show you how the migration works. 1. Find the right position of migration activities within “SAP Customizing implementation guide”. Use transaction code SPRO and the open the SAP Reference IMG. a) on the upper left corner of your screen, in the OK-Code field, enter transaction code SPRO. In the second line, you will find the entry: ●

Migration from SAP ERP to SAP Accounting powered by SAP HANA.

b) Choose Migration → Migration cost element. c) Check the description of the activities so that you are clear regarding the following technical background: ●

Check Consistency of G/L Accounts and Cost Elements.

●

Migrate Secondary Cost Elements to Chart of Accounts.

2. Now we need “Old Cost elements”. That means cost elements of SAP Business suite, which are defined in the table CSKA/CSKB. a) We can only simulate this. Use transaction code SA38 and, in the Program field, enter ZS4H100_OLD_SEC. b) Using this program, you will create a secondary SAP Business suite cost element. Enter the following:

124



●

Account number: S4## (## is your group number).

●

Description: S4## old cost element.

3. Use transaction code SE16 to check if your cost element is in the CSKA or CSKB tables. a) Enter transaction code SE16. b) Enter Table Name CSKA. c) In the KSTAR field, enter your cost element S4##. d) Repeat for the CSKB table. e) Check with the following transactions: ●

FSP0 - G/L Account in chart of account and

●

FSS0 - G/L Account in company code

After this task, the trainer will start the migration for all groups. The Enterprise structure of financial area on top is a controlling area. One or more company codes could assign to one controlling area. In our case, Company codes 1000, 1010, and 1710 are assigned to controlling area A000. This means that, after the migration, you should find your S4## account in each of those company codes. 4. Using transaction code FSS0, check whether your S4## account was set up for each company code: 1000, 1010, and 1710. 5. Look at the SKB1 table (remember that your account S4## was not in the table). a) Use transaction code SE16 to display the SKB1 table. You should find 3 entries for your S4## account. b) Who has created these entries? Look in the ERNAM field of this table. Migration Secondary Cost Element 1. Start transactionSPRO and then press F5 to open SAP Reference IMG. a) On the SAP Easy Access screen, enter transactionSPRO and then press F5 to open SAP Reference IMG. b) On the Display IMG screen, choose Migration from SAP ERP to SAP Account SAP Netweaver → Migration → Migration of Cost Elements. c) Choose Migrate Secondary Cost Elements to Chart of Accounts and check the description of its functions. d) Use transaction SA38 to open the ABAP Program Execution screen. Select ZS4H100_OLD_SEC and press F* to execute it. e) On the Create a secondary cost element in the form of business suite screen, in the Account number field , enter S4## (## = your group number), in the Description field, enter your own description. f) 2. Execute Se16 and check the entries for your new cost element in tables CSKA and CSKB.


125


a) On the Data Browser: Initial Screen, in the Table field, enter CSKA. b) On the Data Browser: Table CSKA: Selection Screen, in the KSTAR field, enter S4##. Now the trainer will start the migration for all groups. c) On the Display IMG screen, choose SAP Customizing Implementation Guide → Migration from SAP ERP to SAP Account → Migration → Migrate Secondary Cost Elements. d) On the G/L Account and Cost Element Merge screen, in the Mass Data Run area, note the mass run number. Choose Execute. e) On the Display IMG screen, the trainer will check the status of migration.

Figure 139: Slide 8

f) On the Display Status of G/L Account and Cost Element Merge screen, note the following entries with package key: YCOA1000, YCOA1010, and YCOA1710. YOCA is the technical name for chart of accounts. 1000, 1010, 1710 are the company codes which are connected with the controlling area A000. 3. Using transaction, FS00 Edit G/L account centrally, check if your cost elements are real S/4 HANA cost elements. a) On the Edit G/L Account Company code data screen, in the G/L Account field, enter S4##. b) Choose the pair of glasses icon. c) On the Display G/L Account Company code data screen, choose Internal activity allocation. 4. Check the case table, SKB1 using transaction SE16.

126



a) Use transaction SE16. b) On the Data Browser: Table SKB1: Selection Screen, in the SKANR field, enter S4##. c) Check the table.


127



128

Describe the best practices for System Conversion, in general and for minimized downtime in detail


Unit 4 Lesson 7 Example: Custom Code Analysis


Understand the importance for custom code analysis

Custom Code Review

Figure 140: SAP Business Suite Powered by SAP HANA

The figure, SAP Business Suite Powered by SAP HANA, is based on ABAP 7.4 = the “to-go” release for all SAP HANA based ABAP applications. How can customers smoothly migrate? What has to be done to achieve a Readiness of ABAP on HANA, what can be done to optimize their code for SAP HANA in order to improve their individual business processes? When you plan to migrate to SAP HANA, the amount of custom code in your system will affects the total cost, time, and the quality of the result. In this lesson, you look at the potential impact of that custom code, and discuss how to adjust your custom code so that it performs optimally on SAP HANA. By using the tips and tools mentioned here, you will be able to boost your ROI and smoothen the migration process. Migration of the ABAP Customer Code The migration of the ABAP customer code for SAP HANA can be divided into two main areas:


129


●

Functional modifications of the customer code

●

SQL performance optimization of the customer code

In general, all of the code that runs on your existing platform will continue to run as before on SAP HANA. However, there are three main points on which you must pay special attention: ●

Some parts of the old code might lead to functional issues. For example, if you were using a summarization table in the legacy code, this table might no longer exist. This can happen if you migrate the legacy Business Suite accounting to Smart Finance.

●

●

There might be some old code, which is contrary to some programming rules for good performance. There might be some critical business processes, which should run faster.

In terms of the standard ABAP code, this will generally work, because the migration is based on the requirement of application enhancement pack levels, in combination with the compulsory NetWeaver stack level. We can expect that SAP has replaced potential troublesome code, and even optimized it in several areas. However, as some of the fundamental characteristics of the underlying database change when you replace your legacy database with SAP HANA, the code needs a thorough check. First of all, you need to find and replace any parts of the code that rely on database-specific features, such as native SQL statements, and the use of DB hints in Open SQL statements.

Figure 141: ABAP Code

In general, every ABAP code works in SAP HANA as well. That means, it won't dump. However there is some ABAP coding using special technique properties of an any-database or which use directly access to pool- or cluster tables. This coding should be revised. Certain ABAP statements are not performing very well in a column-based, in-memory database like SAP HANA. Therefore we have to make adjustments to that coding. If you are accessing index information of pool or cluster tables which are gone or replaced, you have to check the coding.

130


Lesson: Example: Custom Code Analysis

Figure 142: Shift in Priorities of Classic Golden SQL Rules for SAP HANA

To illustrate these rules, look at the following example: ●

●

Select* FROM ekko INTO TABLE it_ekko WHERE ebeln = lv_ebeln. Select * FROM ekpo INTO TABLE it_ekpo FOR ALL ENTRIES IN it_ekko WHERE ebeln EQ it_ekko-ebeln.

There are three main problems with these statements: ●

●

●

It triggers two separate round-trips to the database. The second SQL statement may result in unnecessary large result set that may never be used, as there is no check for an empty FOR ALL ENTRIES IN from the first SQL. The complete field list is fetched for both tables, which should only be the case if all fields will be used in the subsequent application logic.

As with the replacement of malfunctioning code in the first chapter, adopting these best practices should not be programmatically challenging. However, the code parts that are worth modifying may be difficult to locate. With this in mind, SAP has extended the previously discussed Code Inspector for this purpose. In the tool, you find analysis of WHERE conditions, buffer bypass checks, nested SELECTs, unsecure FOR ALL ENTRIES checks, and more.


131


Figure 143: Monitoring

Use monitoring and trace tools to measure the usage of ABAP and SQL in your productive system. Possible adaptations of and corrections to ABAP custom code can generally be divided into two main areas: Functional adaptations and SQL performance optimizations. Analysis of the custom code is supported in both areas through static Code Inspector checks to find the affected ABAP code parts. In the case of functional adaptations of custom code, the primary goal is to detect, using checks, ABAP code that relies on specific features of a database and, therefore, needs to be analyzed and, if necessary, adapted. An example of this is native SQL usage in ABAP custom code. Such functional adaptations require, for the most part, clear, local corrections in program code that do not demand a deep knowledge of the application. In the case of SQL performance optimizations, the interaction of various tools and checks is vital for performing the optimization effectively. Here, the new SQL Monitor is used in addition to the new static Code Inspector performance checks and the SQL Performance Tuning Work List. The static performance checks can generate a large number of messages. However, these performance checks are of an indicative nature (for example, a "nestedSELECT" exists). Only in combination with the relevant performance data can these results from static checks be used effectively. By combination with the performance data (from the SQL Monitor) the number of recommended performance corrections is, generally, reduced quite considerably.

132



Figure 144: Code Inspector inside: ABAP Test cockpit (ATC)

A useful tool to help with code migration is the ABAP Code Inspector. With this tool, you can define variants of the elements that you want to analyze. In particular, the following categories will provide good help in identifying problematic code: ●

Critical statements

●

Finds native SQL and DB hints.

●

Use of ADBC Interface

●

Finds native SQL and DB administrative statements.

●

SELECT/OPEN CURSOR without ORDER BY

●

Finds problematic statements where database tables are read without order or sorting before read, search, or delete.

●

Search ABAP Statement Patterns

●

Allows you to search for index specific code.


133


Figure 145: Code Inspector: Initial Screen

To support the process of increasing the quality of the code, the code inspector is part of the ABAP Test Cockpit (ATC). Here, the code quality manager can schedule periodic runs, add quality gates with priorities, and publish the results back to developers. Even if you have no immediate plans to migrate to S/4HANA, this tool is of interest. Putting your programming standards into a benchmarking regime results in better quality and better running business processes. The Initial screen of code inspector has three different sections: ●

Inspection

●

Object Set

●

Check Variant

Figure 146: Useful and Powerful Variants of Code Inspector

134



There are many predefined variants for analysis of the previous coding. The two most useful are the FUNCTIONAL_DB and FUNCTIONAL_DB_ADDITION check variants. FUNCTIONAL_DB Check Variant This check variant contains checks that are regarded as mandatory for the analysis of ABAP custom code as part of an SAP HANA migration. Currently, these are as follows: ●

●

●

●

●

●

●

Location of native SQL and database (DB) hints (messages on DB hints should be regarded as information only, as DB hints are declared on a database-specific basis and usually do not need to be adapted). For native SQL, you must check whether the SQL code can also run on SAP HANA or whether it should be adjusted. Location of ADBC (ABAP Database Connectivity) usages (should be treated in a similar way to native SQL). Location of usages of special ABAP Dictionary function modules that check/provide the existence or technical properties of certain database indexes. On SAP Hana, most of the database indexes are not in use, and these checks are, therefore, usually obsolete. Location of accesses to technical pools or clusters of a pooled or cluster table. As part of an SAP HANA migration, most pooled and cluster tables are converted to transparent tables of the same name. After this step, access to those technical pools or clusters that are no longer used is not necessary. Location of non-robust ABAP code that relies on a non-guaranteed/implicit sorting of certain SQL queries, even though no ORDER BY clause is used. For these incorrect ABAP source code sections, an explicit sorting of the SQL query must be inserted (ORDER BY clause or ABAP SORT).

FUNCTIONAL_DB_ADDITION Check Variant This check variant contains additional checks that are not directly linked with the SAP HANA migration, but experience has shown that they can locate potential functional errors and SQL statements with poor performance. Therefore, the checks in this check variant are not mandatory for the SAP HANA migration, but they are recommended. This check variant currently contains the following checks: ●

●

●

SQL operation without WHERE clause. The semantics of this statement should be checked for changing operations, in particular. SQL operation with the supplement FOR ALL ENTRIES IN , where the code does not ensure that the internal table is always filled. (For an empty internal table the complete WHERE clause of the SQL operation disappears, according to the ABAP documentation.) Check ABAP Dictionary table settings for consistency. In particular, this checks whether table buffer settings have been maintained consistently (performance).

For more information, see SAP Note 1912445.


135


Figure 147: Prepare your Custom Code for SAP HANA Functional Corrections for Existing ABAP Code - Static Checks

Functional Corrections for Existing ABAP Code – Static Checks “Search problematic statement…w/o ORDER BY” check ●

●

●

●

Preferred check to find code which relies on sorted DB content searches for statements like READ BINARY SEARCH, DELETE ADJACENT DUPLICATES, … accessing unsorted DB content Works for transparent and pool/cluster DB tables -

Low false positive ratio

-

“Depooling/Declustering: Search for…w/o ORDER BY” check

Searches for SELECT without ORDER BY but no further analysis of the data flow is done

●

Works only for pool/cluster DB tables (before and after depooling/declustering)

●

High false positive ratio -

●

●

●

Recommendation

Run both checks for your custom code Concentrate on findings (priority 1 and 2) of the “Search problematic statement…w/o ORDER BY” check Treat findings of “Depooling/Declustering: …” check with reduced priority

Everything that was custom-developed you can get checked here. It gives you a lot of possibilities to improve your custom code especially together with the simplification database.

136


Unit 4 Exercise 4 Custom Code Review

This exercise is about to show how you can use the Custom Code Inspection to detect custom code that is not well written for SAP S/4HANA purposes. The purpose of doing this in the legacy SAP system is that customers planning a System Conversion to S4/HANA are able to revise their custom code prior to the real conversion phase. Note that, in this exercise, when the values include ##, replace ## with the number provided by your instructor. 1. Log on to legacy R/3 system ZME. 2. Start the Code Inspector transaction SCI 3. Copy the template inspection S4H100. 4. Configure your own inspection S4H100–## 5. Start your inspection ZS4H100–## 6. Reading the results


137

Unit 4 Solution 4 Custom Code Review

This exercise is about to show how you can use the Custom Code Inspection to detect custom code that is not well written for SAP S/4HANA purposes. The purpose of doing this in the legacy SAP system is that customers planning a System Conversion to S4/HANA are able to revise their custom code prior to the real conversion phase. Note that, in this exercise, when the values include ##, replace ## with the number provided by your instructor. 1. Log on to legacy R/3 system ZME. a) Open SAP Logon b) Double click on the ZME system.

Figure 148: SAP Logon

c) Logon using user S4H100–## and password Welcome1. 2. Start the Code Inspector transaction SCI a) Enter sci in the command field and press ENTER.

Figure 149: Enter transaction code in command field

3. Copy the template inspection S4H100. a) Click on

to toggle from local

to global

.

b) Enter S4H100 in field Name. c) Ensure, that 001 is filled in field Vers. d) Click

138

to copy the template inspection..



Figure 150: Copy the template inspection

4. Configure your own inspection S4H100–## a) On the appearing pop-up select radio button New Inspection. b) Give the new inspection the name S4H100–##. c) Fill field Description with S4H100–## Code inspection. d) Click OKAY

Figure 151: Configure your own inspection

5. Start your inspection ZS4H100–## a) Back on your main inspection screen the name of your new inspection appears in the field Name. Click on

(Change).

Figure 152: Change your inspection

b) The Code Inspector screen appears. Click the execute button to start the code inspection.


139


Figure 153: Start your inspection

c) Now this message should appear at the lower left corner of your screen:

Figure 154: The inspection was succesful

d) The header of your transaction has changed: the green traffic light indicates that this version of the inspection has been executed.

Figure 155: Inspection executed

e) In case you need to run another version click

(Create new version).

6. Reading the results a) To see the result of your current inspection click

(Results). The results screen

turned up.

Figure 156: The results

b) Extend the folder Performance Checks. You should see something similar to this:

140



Figure 157: Performance checks

c) Double click on one of the rows to check what kind of performance problems there are.

Figure 158: A closer look to performance issues

d) Double click on the SELECT * FROM VBAK statement to jump directly to this line of code in the respective program.

Figure 159: ABAP editor

e) You have been forwarded to the ABAP editor. Here the developer would directly be able to change the code so that it fits the requirements of a column based database. (It is not part of the exercise to rewrite the code.)


141



142

Understand the importance for custom code analysis


UNIT 5


Lesson 1 The Content of Landscape Transformation

144

Lesson 2 Central Finance - a deployment option Exercise 5: FI Posting to Central Finance

152 163

UNIT OBJECTIVES ●

Describe the aim of scenario Landscape Transformation

●

Understand the opportunities of a Central Finance approach


143

Unit 5 Lesson 1 The Content of Landscape Transformation




Figure 160: Transition to SAP S/4HANA: Scenario 3 - Landscape transformation

Scenario description: Customers who want to consolidate their landscape or to transform data into a SAP S/4HANA system selectively. The benefits are as follows: ●

●

●

144

Value-based migration: selective data transformation allows a phased approach, focusing the first SAP S/4HANA migration phase on parts of the business with the highest ROI and lowest TCI. Agility: stay on current business processes but move gradually to SAP S/4HANA innovations (Move to SAP S/4HANA at your own pace). TCO reduction: system and landscape consolidation with harmonized and simplified processes and unified master data lead to lower cost of operations.


Lesson: The Content of Landscape Transformation

Figure 161: Transition to SAP S/4HANA: Major elements of deploy phase in transition process

The deploy phase of the transition to SAP S/4HANA consists of three major elements: Preparation, Technical Implementation, and Semantical Adoption. Preparation ●

Preparation steps on start release

●

Analysis of used business processes – mapping to SAP S/4HANA innovations

●

Identify required integration scenarios of target state

●

Run pre-Transformation Checks on source system -

●

Used functionality, supported industries, available add-on, custom code …

Mandatory preparation steps to be executed on source system

●

Technical Implementation ●

“Installation” of SAP S/4HANA -

SAP HANA Database

-

SAP S/4HANA application core

●

Customizing adjustments

●

Adjustment of technical infrastructure

Semantical Adoption ●

Adapt custom code to comply with SAP S/4HANA scope & data structure

●

Adapt business / processes to leverage new SAP S/4HANA innovation functionality (For example, use CDS-based real-time reporting instead of Logistics Information System)

●

Adapt integration scenarios (if applicable)

●

Implement SAP Fiori UIs


145

Unit 5: Landscape Transformation

●

Introduce new SAP S/4HANA innovation scenarios (e.g. advanced planning and simulation features)

Figure 162: High Level Stack Architecture SAP S/4HANA: Logical view

SAP S/4HANA architecture differs from the classical Business Suite architecture. Data structures compatibility to classical Business Suite architecture is provided through Core Data Services (CDS). Please note that SAPGUI for Windows is still available for compatibility reasons.

Figure 163: SAP S/4HANA Architecture: Table consolidation

Simple Data Modemeans the following: ●

4 tables remaining, no redundancies

●

Clear separation of master data from transactional data

●

Reduction of memory footprint

Simple Processes means the following:

146



●

Only one valuation method (Material Ledger) instead of 2 (IM + ML)

●

Throughput Increase means the following: ●

INSERT only on database level

●

No locks for standard price valuation

Figure 164: SAP S/4HANA Landscape Transformation Project(s): Characteristics

In general, characteristics of SAP S/4HANA Landscape Transformation Projects are as follows: ●

●

●

SAP S/4HANA landscape transformation approach has to be set-up as a project with IT and business users involved. CIOs are usually the sponsor and initiates TCO driven Landscape transformation projects. Business responsible usually decide on the scope and timing of a value-based / selective data transformation project.

Special technical considerations are as follows: ●

●

Due to architectural changes in several ERP applications, a preliminary assessment needs to evaluate the readiness for a SAP S/4HANA landscape transformation project. SAP provides predefined "migration content" for dedicated landscape transformation scenarios. However several project-specific configuration steps, technical checks and adjustments are required.


147


Figure 165: Transition to SAP S/4HANA: Required capabilities of a SAP S/4HANA data migration platform

1. Ability to analyze and check readiness of source environment for SAP S/4HANA landscape transformation scenario or scenarios 2. Configuration options to meet customer-specific requirements and system conditions ●

Configuration based on pre-defined transformation content

●

Mapping capabilities and ability to define "transformation rules"

3. Flexible & high-speed data selection and processing ●

●

●

Performance tuning options for data transfer Support of required data transfer methods (such as file upload, posting via standard interfaces or table-based insert) Data validation and reconciliation features

4. Compliance to post processing programs for the semantical adoption to SAP S/4HANA

Figure 166: SAP Landscape Transformation: SAP S/4HANA data migration / landscape transformation platform

The tool SAP Landscape Transformation (SLT) connects your source environment either legacy SAP system or Non-SAP legacy system with SAP S/4HANA target environment. SAP

148



legacy systems can connect to SAP SLT via LAN or WAN. Non-SAP legacy system have to upload their data via file upload to SAP SLT.

Figure 167: SAP S/4HANA Landscape Transformation Scenarios - On Premise: SAP LT enabled solutions

Tailored offerings for selective data migration requirements (for example based on time slice, plant or other objects) can be requested as project solution or service. For the Landscape Transformation scenario to SAP S/4HANA on premise, three different preconfigured solutions exist: Consolidation, Migration of Business Units, and Migration of selected applications (Central Finance)

Figure 168: Possible Consolidation Scenarios

For Landscape Transformation, the possible consolidation scenarios are: Greenfield, Brownfield, and Blackfield. Greenfield ●

Systems to be merged won‘t be in operative use afterwards.

●

A new system with a new organizational structures and processes will be created.

●

In case of a “selective” migration access to source systems for historical information is required.

Brownfield ●

Systems to be merged will nott be in operative use afterwards.

●

A new system with a new organizational structures but existing processes will be created.


149


●

In case of a “selective” migration access to source systems for historical information is required.

Blackfield ●

One system will be identified as “leading” system, others will be merged into that.

●

All existing processes and organizational structures will be adjusted in case of conflicts.

●

In general all data will be migrated.

Figure 169: SAP S/4HANA Landscape Transformation Scenarios - On Premise: Consolidation

Motivation and Typical Use Cases Reduce number of SAP systems by consolidating into one SAP S/4HANA: ●

SAP solutions: ERP, CRM, SRM , SCM, PLM

●

SAP BW consolidation / SAP HCM consolidation

●

TCO reduction and process and data harmonization as additional value proposition for the a SAP S/4HANA business case

Current Scope and Important Considerations Current scope and important considerations are as follows: ●

●

Supporting data transfer from single clients to build-up a multi-client SAP S/4HANA system Post migration activities required to adjust transferred data in SAP S/4HANA system (similar in system conversion)

Note: Migration into an existing SAP S/4HANA system/client is currently not possible.

150



Figure 170: SAP S/4HANA Related Development Roadmap

SAP S/4HANA landscape transformation - Strategy Advisory & Roadmap Service Assess the readiness of source environment for SAP S/4HANA landscape transformation approach. Define SAP S/4HANA landscape transformation roadmap, including recommendations, such as the following: ●

Program / project plan (with effort estimation, timelines)

●

Most suitable technical solution approach (with related prerequisites and constraints)

SAP S/4HANA Landscape Transformation - Implementation Services for Consolidation and Selective Data Transformation Scenarios ●

●

●

●

Analyze and prepare affected source systems (for example, release level, impact of applications in use, need for repository and customizing harmonization, and so on) Determine affected data volume and possible measures for downtime optimization Technical execution (data migration), including testing and verification based on reconciliation lists Cut over and GoLive support




151

Unit 5 Lesson 2 Central Finance - a deployment option



Central Finance

Figure 171: Drivers for Moving to a Central S4/HANA Instance

Signs of Complexity ●

Extractions and transformations

●

Mappings and harmonization

●

Delays, anomalies, inconsistencies

●

Data reconciliation, data validation

●

Report provision (data-to-people)

Business Issue(s)

152

●

Limited transparency

●

Throttled productivity

●

Pro-longed process execution


Lesson: Central Finance - a deployment option

●

Service level challenges

For many customers, finance is complex and not digitally connected. The topic "Central Finance" has a high visibility, which is increasing from SAP internal to client events throughout 2016. Central Finance is the replication-based path (therefore also named "side-car" approach) to carve out specific capabilities together with their posting and master data from the existing ERP landscape. It is important to remember that the term "Central Finance" comes in two contexts, which we need to be clear about. In the context of the deployment option available among others, Central Finance as an approach of replication of posting data is one of these deployment options that shall shorten the path to innovations provided by S/4 HANA and S/4 HANA Finance. In the context of SAP instances in a system landscape diagram, the "Central Finance" system is the target instance, running S/4 HANA and S/4 HANA Finance, on which selected finance, accounting, and business planning scenarios are operated. While essential restrictions exist in Central Finance functions that strongly call for centralizing and harmonizing a specific scope of capabilities on an S/4 HANA Finance instance, the client has reasons to keep the existing ERP landscape running for the remaining scope for the time being.

Figure 172: Key Use Cases for the Central Finance Deployment Option

The figure, Key Use Cases for the Central Finance Deployment Option, show potential scenarios, which can serve as appropriate drivers to suggest and identify the relevance of a Central Finance program. Among them are strategies to assist corporate mergers or acquisition, onboard subsidiaries, Consolidate instances or systems, add the SAP capabilities to full or partially non-SAP ERP landscapes, or start a journey to move capabilities to run in a cloud environment. The figure demonstrates how a driver can lead to a sound suggestion of business use cases or IT use cases.


153


Figure 173: Central Finance as a Catalyst for Business Transformation

Central Finance as a Catalyst for Business Transformation This is a generic example of how a Central Finance program can be positioned: PROBLEM ●

SAP customers with heterogeneous, multi-ERP system landscapes have been facing uphill battles to keep their existing ERP systems up to date and in-sync.

OBJECTIVE ●

Deploying S/4HANA Finance as a ‘central finance’ scenario allows customers to adopt the latest SAP innovations without disrupting their existing ERP systems.

OUTCOME Once financial data is replicated from the source systems onto the central finance system, SAP customers can gain access to the following: ●

Harmonized and consolidated financial and management reporting

●

Integrated transaction processing, planning, and reporting

●

Central process execution like intercompany, disputes, or cash management

The benefits of an S4/HANA Finance instance are advanced real-time business planning, process simplification, a high quality of master data and organizational unit data. Please note that the case-specific list of benefits will depend on applicable use cases and client´s requirements. The baseline of the Central Finance approach consists of three elements: ●

●

●

154

First, the customer is operating multiple ERP systems. Second, the customer has identified a list of business scenarios and master data that shall be consolidated and centralized by its operations. Third, the client has stated a priority to consolidate and simplify those financial processes.



Figure 174: What is Central Finance?

SAP’s S4/HANA Finance innovations can be introduced through technical migration to existing SAP ERP systems or through a non-disruptive, accelerated side-car approach (Central Finance). Please note the potential to reduce effort, risk, and complexity in the "Central Finance" deployment option as compared to a full system upgrade or system consolidation.

Figure 175: Major Benefit from the Universal Journal

The set of capabilities that are supported by Central Finance, and thus can be centralized, simplified, and harmonized there, currently consist of five pillars.


155


1. The first pillar shows posting rules and posting data for New General Ledger (GL) with options for parallel ledgers/accounting standards, special ledgers and document split. 2. The second pillar addresses cost, revenue and profitability analysis and planning. 3. The third pillar addresses management accounting including credit management and related cash & exposure management. 4. The fourth pillar addresses asset accounting, while the fifth pillar addresses the Material Ledger. 5. All five pillars points to SAP Business Partner as master data record compared to Creditor and Debitor records from legacy SAP ERP system.

Figure 176: Universal Journal: Overview of IT Benefits

Central Finance is bringing together the document data and insights for FI, CO. The S/4 HANA Finance system adds OLAP and OLTP processing for Integrated Business Planning instead of a separate planning cycle with data from a Business Warehouse filled in a batch process.

Figure 177: Centralization of Finance Operations: Benefits in Reporting and Process Orchestration

156



Benefits in Reporting and Process Orchestration Cross-system view of customer or vendor account / real-time operational reporting with Fiori user experience

●

●

Key processes managed centrally, executed centrally whenever possible

●

Postings are seamlessly triggered in local FI systems

●

Centralize process know-how in shared service center

●

Harmonized, mapped master data

●

Local logistics processes access local FIN data for consistency

●

●

●

●

Some processes require manual steps for postings in local systems (example: credit memo posting upon dispute resolution) Replication of payments, clearing status, cost differences, discounts, and so on, into central system Reporting-related processes could then be orchestrated or run on centralized data set: cash application, credit exposure calculations, dunning, collections prioritization Mapping of customers/vendors via Central Finance mapping functionality – optional integration with SAP MDG

One major aspect of a Central Finance use case is harmonizing finance operations. This includes A/P (accounts payable) and A/R (accounts receivable) processing, credit management, disputes, and collections. An additional scale of benefits can be reached once the Shared Services Framework (SSF) adds process orchestration and automation, agreeing and managing levels on a simplified UI.

Figure 178: High-Level Architecture of Central Finance Replication Approach

There are three elements of application architecture in Central Finance: the source data in the source systems, the System Landscape Transformation (SLT) as the replication approach, and the S/4 HANA Finance target system.


157


The functional architecture inside Central Finance consists of three elements: the generic Accounting Interface tool, the business mapping for master data, and the generic error correction handling. Central Finance Replication Approach Replication on Transaction-level

●

●

Reconciled Financial data

●

Harmonized Financial Language across multiple systems

●

Existing system remain untouched

Figure 179: Detail-Level Architecture of Central Finance Replication Approach

The initial load is a two-step process. The first step is inside the source system from standard tables to Central Finance tables and then from cFIN tables of the source system to replicated tables in the target system.

158



Figure 180: Central Finance and the Accounting Interface Framework

The Accounting Interface Framework (AIF) tool specifically offers post processing and error handling capabilities as follow-up on validation of the posting and document data replicated. The quality of the post processing and error handling capabilities depends on the quality of the transactional data itself, of their mapping rules, and the related master data. The generic AIF tool also serves data harmonization while keeping the most granular level of line-item details for documents. This is needed when Special Ledger, Document Split, or multiple parallel Accounting Standards are used.

Figure 181: S4/HANA Finance Add-On: New Capabilities for Planning

Besides centralized finance and accounting operations, integrated Business planning is a third, major capability to be mentioned.


159


●

●

●

●

●

●

●

First as a baseline scenario, reporting with SAP Fiori is possible. Second, Rationalization of Data Warehousing can be considered for Reporting, at least reattaching the BW and / or BOBJ Universe from each ERP source system to the Central Finance instance. Third, Unified Platform for Planning is the second approach fully centralized. Fourth, Shared Services with Cloud Applications can be offered once selected scenarios runs in a centralized cloud, e.g. HR, Billing, Procurement, Vendor management or Travel expense management. Fifth, Shared Service Operations add automation and harmonization on AP/AR, Payroll, while these capabilities still need a local log-in into the source systems. Sixth, Central Transactions allows for harmonization and acceleration of specific processes, e.g. for Rebates Calculation, Revenue Recognition, Cost Allocations, PeriodEnd Closing, Assets Management and Cash Management. Seventh, 3rd Party Integration connects 3rd party ERP-vendor functions (partially) exclusively to a Central Finance system rather than to individual SAP ERP systems.

Figure 182: S4/HANA Finance Add-On: UI improvements

The Central Finance story is not only about system capabilities in the area of data replication, validation and correction, but also about User Experience. Reports generated are usable by any UI channel (desktop, mobile) and are rendered using the open HTML5 or SAP-certified SAP UI5 technology. SAP ERP Planning ●

SAP GUI

●

Sequential Planning Process

●

-

Cost Center Plan

-

Project Plan…

-

No direct share of values

Fixed data model

Integrated Business Planning

160

●

HTML5 UI, Analysis for Office

●

Parallel Planning Process



●

HANA Optimized performance

●

Workflow/Workstatus support

●

Real time Actuals

●

Activity Log


161


162


Unit 5 Exercise 5 FI Posting to Central Finance

In our landscape, there are two ERP systems: ●

ZME - Business suite system

●

T39 - SAP S/4HANA system

Both systems are connected using the Central Finance approach. In this exercise, you transfer a financial booking from business suite system to SAP S/4HANA system. The result will be two bookings in both systems, with different booking numbers. Both posting are connected to each other, so it is possible to drill back from the T39 system booking to the ZME system. 1. Log on to system ZME (Business suite) with you user. S4H100–## (## - is your group number).

Figure 183: Central Finance 1

2. Now we will identify this posting in the SAP S/4 system. Log on to system T39 (SAP S/ 4HANA system 1511sp01).


163

Unit 5 Solution 5 FI Posting to Central Finance

In our landscape, there are two ERP systems: ●

ZME - Business suite system

●

T39 - SAP S/4HANA system

Both systems are connected using the Central Finance approach. In this exercise, you transfer a financial booking from business suite system to SAP S/4HANA system. The result will be two bookings in both systems, with different booking numbers. Both posting are connected to each other, so it is possible to drill back from the T39 system booking to the ZME system. 1. Log on to system ZME (Business suite) with you user. S4H100–## (## - is your group number).

Figure 183: Central Finance 1

a) Enter transaction code FB01 POST DOCUMENT via OK-Code. Use the functionality Post with reference.

Figure 184: Slide 2

b) As reference for your own post, use following inputs:

164



Figure 185: Slide 3

c)

Figure 186: Slide 4

d) On the next screen, enter the following: ●

Document date: the date of today

●

Posting date: the date of today

●

Reference: S4H100-## (##- your group number)

●

Doc. Header text: S4H100-## (##- your group number)

Figure 187: Slide 5

e) Press .

Figure 188: Slide 6

f) Press Post

.

The financial content of this booking is a rebooking from one account 400000 to another one, 420000. The account 400000 will be relieved and account 420000 will be debited. The cost center 9030 remains the same. g) Note the posting number.


165


2. Now we will identify this posting in the SAP S/4 system. Log on to system T39 (SAP S/ 4HANA system 1511sp01). a) Enter transaction code FB03 DISPLAY DOCUMENT via OK-Code. Use the function Document list.

Figure 189: Slide 7

b) Enter the following: ●

Posting date:

●

Own document only: Activate this option

Now you should see a document with a unknown document number; is this your document? c) To check, press the button with the magnifier or F2. The “Reference” is the same as you have entered in ZME, so it could be that this posting is triggered from the Business suite system, but we need evidence. d) Press F5 (Display Document header). e) Double-click the Sender Doc. Number field. You enter the ZME system, directly to the original booking with the document number from task 1. f)

Figure 190: Slide 8

166



g)

Figure 191: Slide 9

h)

Figure 192: Slide 10


167


i)


j)


168



k)


l)



169


m)


170






171


172


UNIT 6

SAP Info Sources and Further Courses

Lesson 1 Further Courses and Useful Links

174

UNIT OBJECTIVES ●

Explain the additional learning opportunities about implementation to SAP S/4HANA


173

Unit 6 Lesson 1 Further Courses and Useful Links



Further Courses and Useful Links

Figure 198: Resources: Transition to SAP S/4HANA - Enablement via SAP Learning Hub & classroom

There are a lot of different learning opportunities to get to know how to move to SAP S/ 4HANA. You can learn from scratch about SAP S/4HANA via Learning Room, E-learning, or classroom training. You can study SAP Activate as the methodology for transition to SAP S/ 4HANA on various types of learning and you can deep dive in the transition and implementation with a lot of Learning Rooms, E-learnings, and classroom training. More to come.

174


Lesson: Further Courses and Useful Links

Figure 199: Transition to SAP S/4HANA, On-Premise: Useful links

We gathered some very useful links regarding the System Conversion to SAP S/4HANA and transformed them into QR-Codes on the following slides. Here you can see an overview, structured by the SAP Activate phases.

Figure 200: Transition to SAP S/4HANA, On-Premise: Prepare

Here you can find useful links for the preparation phase for all types of implementation. In this phase it happens often that customers rethink their "obvious" implementation scenario.


175

Unit 6: SAP Info Sources and Further Courses

Figure 201: Transition to SAP S/4HANA, On-Premise: Explore

Here you can find useful links for the Explore phase, for strategy, architecture, and migration planning.

Figure 202: Transition to SAP S/4HANA, On-Premise: Realize / Deploy - Semantically

Here you can find more links for the deploy phase from a semantically point of view. All links are covering aspects around how to convert an existing system.

Figure 203: Transition to SAP S/4HANA, On-Premise: Realize / Deploy - Technical

176


Lesson: Further Courses and Useful Links

Here you can find links for the technical aspects of the deploy phase. There are links to tools like DMO with SUM and the Software Logistic Toolset and much more. LESSON SUMMARY You should now be able to: ●



177

s4h100 en Col04 Ilt

Recommend Documents