Treats contract employees equally with SAP Labs

Planning the introduction of SAP S / 4HANA Enterprise Management using a strategic roadmap

Table of Contents

List of figures

List of tables

List of abbreviations

1 Introduction

2 Basic understanding of in-memory technology
2.1 How in-memory works
2.1.1 Column-oriented data storage
2.1.2 Compression method

3 Introduction to SAP HANA
3.1 SAP HANA architecture
3.2 SAP Business Suite powered by SAP HANA
3.3 S / 4HANA Enterprise Management
3.4 SAP Fiori
3.5 S / 4HANA deployment options
3.6 Migration routes
3.7 What SAP HANA promises

4 Roadmapping within project management
4.1 Project management
4.2 The ideal-typical phase model
4.3 Introduction to roadmapping
4.3.1 State of the art
4.3.2 Classification of roadmaps
4.4 Classification of the roadmap in the phase model

5 Impact of IMDM on business processes

6 Practical Approach to a HANA Roadmap

7 Critical Appreciation



List of figures

Figure 1: Structure of the SCOS

Figure 2: Structure of the MCOD

Figure 3: Structure of the MCOS

Figure 4: Structure of the MDC

Figure 5: Virtualization

Figure 6: Overview of S / 4HANA

Figure 7: Deployment models for S / 4HANA

Figure 8: S / 4HANA Enterprise Management

Figure 9: Decision matrix and migration paths

Figure 10: Ideal-typical phase model

Figure 11: Roadmap to Phaal

Figure 12: HANA roadmap phase model

Figure 13: Enterprise Performance In-Memory Circle

Figure 14: S / 4HANA On-Premise Edition - simplified

Figure 15: Possible transformation paths

List of tables

Table 1: SAP Lab Results: Business Processes

List of abbreviations

Figure not included in this excerpt

1 Introduction

In the course of technological change, companies nowadays are faced with new influencing factors and the challenges associated with them. This significantly influences the development of a company, but conversely, a company can often only react to these influencing factors. A well-considered strategy for investing in new technologies plays a key role here. Companies are faced with the question of which technology should be invested in and when. The introduction of new technologies usually has a major impact on the entire company and its processes. Therefore, above all the opportunities and risks of such an investment must be analyzed and evaluated.

Companies are often faced with the problem that new technologies represent unknown territory. So also S / 4HANA and the associated in-memory technology. Furthermore, the introduction of S / 4HANA is a complex undertaking in which various influencing factors and dependencies within a company have to be taken into account.

To solve this challenge there is the possibility of developing a specific roadmap. In this context, one often speaks of a preliminary study. The focus here is primarily on discussing a realistic implementation of the problem processing. The roadmap also aims to set the course for the further course of the project or to determine that the project should no longer be pursued.

First of all, the reader is given a brief introduction to the basic understanding of in-memory technology and the basic terminology of in-memory data management is explained. There is also an introduction to the topic of SAP HANA. This topic is intended to explain to the reader what SAP HANA is and which applications are made possible with it. This is followed by the topic of roadmapping. A classification and a logical assignment of roadmaps are carried out in the context of project management. A HANA roadmap is introduced below as a practical example. This should enable the reader to understand the terminology around the topic of roadmaps in the S / 4HANA context. Ultimately, there is a critical assessment of the roadmapping and S / 4HANA.

2 Basic understanding of in-memory technology

An in-memory database describes a database (DB) which aims to permanently hold the entire database within the main memory so that it can process the data (cf. Garcia-Molina / Salem 1992, p.509).

The idea or the basic idea of ​​in-memory data management (IMDM) is not new, however, since this approach was already taken up in the 1980s (cf. Loos 2012, 209 ff.). But at that time, the lack of reliability of the main memory and the enormous costs made sustainable use difficult (see Plattner / Zeier 2011, pp.6-7). Problems also arose at that time due to hardware errors and the volatility of the main memory (cf. Lehmann / Carey 1987, pp.104-105). There was no way to use multiple processors effectively. It was also not possible to address large memory areas (cf. Eich 1989, 251 ff.).

However, through progressive computer architectures, which also include multi-core processors, 64-bit technology and inexpensive amounts of RAM with the appropriate size, the practical implementation of this theoretical concept has become possible (see Plattner / Zeier 2011. p.11).

This means that it is now possible to realize large in-memory DBs with working memory capacities that can be classified in the terabyte range (cf. Kemper, Neumann 2011, p. 196).

Towards the middle of the last decade, this approach of database systems came back into focus. With the help of memory databases, time-critical analyzes and evaluations based on very large databases can now be created faster than ever before (cf. Mattern / Croft 2014, p.2). The concept of a line-oriented organization of the data has established itself in traditional DB systems. The attribute values ​​of a data record are arranged next to one another (cf. Krueger et al. 2010, pp.143-158).

IMDM applications primarily use column-oriented storage of the data. Here the attribute values ​​of the data set are distributed among one another to neighboring blocks (see Plattner / Zeier 2011, p.13 ff.). This makes it possible, for example, to efficiently implement compression algorithms. This also leads to a significant reduction in the volume of data. Up to a factor of ten is used here (see Sinzig / Sharma 2011, pp. 18-23), meaning that even large amounts of data can be saved efficiently (Thiele et al. 2011, pp. 57-68).

2.1 How in-memory works

As described at the beginning, compared to traditional DB systems, IMDM uses the main memory for data storage instead of hard disk drives (cf. (cf. Garcia-Molina / Salem 1992, p.509-511). The theoretical basic principle of in-memory DB is based on this to write to the main memory and to access data from the main memory during read processes (cf. Mattern / Croft 2014, p.29).

In addition to the data stored in the main memory, IMDB also has additional data in the secondary memory, but these are only made available for backup and restoration reasons (cf. Garcia-Molina 1992, S-512).

Information systems that use IMDB are thus enabled to process database queries much faster and more efficiently. The reason for this is the faster access times to the main memory compared to the secondary memory (cf. Dewitt et al. 1984, pp.1-8). Column-based data structures can also be found in IMDM. Special compression methods are also used, which further shorten the access times (cf. Maier / Scheffler 2011, p.116).

2.1.1 Column-oriented data storage

The term column-oriented database describes how data is stored on the persistent storage medium to be used (Bösswetter 2010).

Traditionally, as mentioned, data records are stored in a traditional relational DB in a line-oriented manner, with one line corresponding to a coherent data record. This data record consists of several attributes (columns). In the case of column-oriented storage, the values ​​of a column are continuously stored in comparison (cf. Abadi / Boncz / Harizopoulos 2009, 1664-1665).

The line-oriented approach can be compared with the column-oriented approach: Saving in line-oriented form is advantageous for OLTP (Online Transaction Processing) processing. With this approach, individual data records are primarily requested and then processed. In contrast, the column-oriented approach shows its advantages in analyzing applications. This is due to the fact that these applications mainly request a larger amount of data. A calculation is then made on this data, often statistically (cf. Mattern / Croft 2014, p.132). In addition, column-oriented storage has a relevant advantage, especially with wide tables, if only a few attributes are required in the query. Furthermore, compression in line-oriented DB systems can only be carried out with great effort. This is due to the fact that a data set often contains values ​​with many different data types. But the column-oriented storage of the data, in turn, physically arranges very similar values ​​in a column. Thus, this offers a good approach for compression (see Plattner / Zeier 2011, pp.33-35).

In the literature (see Flaig 2013, p.14), alternative approaches to the organization of data in InMemory databases are also mentioned. These approaches have inter alia. the goal of achieving an even higher performance with OLTP queries. A line-oriented in-memory database was developed by Stonebraker et al. (2007) developed which are completely optimized with regard to OLTP. This makes it possible to achieve OLTP transaction rates that are up to a factor of 82 higher than with a conventional database. It should also be noted in this context that such a specialized in-memory database is intended exclusively for its purpose, i.e. OLTP. Therefore, the database cannot be used for complex analytical queries (cf. Stonebraker et al. 2007, p.1151, 1153).

Plattner / Zeier (2011) propagate a mixture of these two approaches in addition to a purely line or column-oriented data layout. Such a hybrid data layout is based on a vertical partitioning of the tables. In comparison to the column-oriented data organization, however, the complete database tables are not broken down into columns, but are separated from the tables in separate columns (attributes) and stored as coherent units. The other attributes are finally stored in tuples on the data memory analogous to the line-oriented data organization. Using this hybrid data layout, the aim is to compromise between transactional and analytical queries. However, the question of which attributes should be stored column-oriented represents a new challenge in this context (cf. Plattner / Zeier 2011, p. 75 ff.).

In conclusion, it can be stated that most in-memory databases are based on column-oriented data storage. This not only enables very fast execution of complex analytical queries, it is also possible to generate high transaction rates for writing OLTP queries. In-memory databases that are specifically tailored to OLTP, using a line-oriented data layout, are the exception, although they can nonetheless be useful in certain areas of application (cf. Flaig 2013, p.14).

2.1.2 Compression method

The possibility of effective compression can be seen as a great advantage of column-oriented storage. As a result, less storage space should be required on the storage medium to be used. The literature reports a factor of up to twenty, by which a compressed column-oriented database is smaller compared to a row-oriented database, which is uncomplicated (see Plattner 2009, p.5)

There is also the possibility of implementing compressions in line-oriented DBs, but these are less efficient. It should also be noted that compression of the data has a positive effect on the required storage space on the one hand and also has a positive influence on the speed of processing the DB on the other hand (see Plattner / Zeier 2011, p.18).

When compressing the data, it is possible to use different methods. Lexicon-based compression in particular is frequently used. In the context of this approach, all the different values ​​of a column or an attribute are stored in a lexicon. These are then saved with a unique ID. With SAP HANA, for example, "dictionary encoding" is used (cf. Müller 2013, pp.143-146). With this method, the column values ​​are stored as integer values. If different values ​​are searched for or if a “joint operation” is carried out, the algorithm accesses the said values. This makes it possible to carry out queries much faster and more efficiently compared to if these were strings. As a result, the queried values ​​can be passed on to the processor more quickly through the main memory (cf. Müller 2013, pp.143f.).

Further compression methods, which are not considered in detail in this thesis, are “Run Length Encoding” and “Bit Vector Encoding” (cf. Krueger 2010, p.133).

3 Introduction to SAP HANA

In the following, the HANA database technology will be introduced. This technology was developed and sold by the German software group SAP SE. HANA is the acronym for High Performance Analytic Appliance. Furthermore, HANA can be understood as the interaction of new technology, which is composed of hardware and software. In simple terms, SAP HANA is a database, hardware and solution in equal measure. “SAP HANA is an in-memory database, but not an application. And although it is not a solution in itself, SAP HANA is a technology that enables solutions ”(cf. Berg / Penny 2015, p.175).

The HANA architecture was developed in 2008 by SAP in cooperation with the Hasso Plattner Institute and Stanford University for the analysis of large data in real time. Before the name “HANA” was established, it was used in various publications under the names “SanssouciDB” or “NewDB” (cf. Kurzdim 2011). SAP HANA was first presented to the public in spring 2010 and was used from November of that year (see SAP 2011a). Furthermore, SAP HANA is one of the first platforms for data management that processes transactions and analyzes on a single, singular data copy in the main memory (see SAP 2016a).

HANA can be used universally for both OTLP and OLAP (Online Analytical Processing). Depending on the table to be created, it can be defined whether it is to be saved column-oriented or row-oriented.

In addition, SAP HANA provides an import interface for mass data. This can be big data, for example, which can be imported using batch processing. In addition, SAP HANA offers an integrated interface to the open source statistics package R; so that extensive and complex statistical calculations, even in the multivariate area, can be carried out in the database itself (cf. Kleis 2012, pp.20-26).

Due to the integration of the MapReduce programming model into the HANA-DB, it is possible to parallelize processes of SQL queries and analytics. This leads to a further acceleration of the processing.

In summary, the following should be understood under SAP HANA:

"SAP HANA is a modern, in-memory database and platform that is deployable on-premise or in the cloud." (See SAP 2016b).

In other words: SAP HANA is a modern, integrated database and platform that can be implemented on-premise or in the cloud.

3.1 SAP HANA architecture

Technical deployment options for SAP HANA

The technical deployment options determine how SAP HANA systems, hosts for SAP HANA systems and applications on SAP HANA can be used. The following is intended to give the reader an overview of the potential possibilities of the HANA architecture. This overview is based on the SAP HANA Master Guides (see SAP 2016c).

Single application on one SAP HANA system

A single application on a SAP HANA system is also known as a Single Component on One System (SCOS). To better describe the various other options for technical deployment, it makes sense to first outline the simple, straightforward approach to implementing an application on a SAP HANA system. This is useful for comparison purposes. In this configuration, a single application runs in a single schema in a single SAP HANA database as part of a SAP HANA system. This is a simple scenario that is fully supported for all scenarios.

Figure not included in this excerpt

Fig.1: Structure of SCOS (see SAP 2016c, page 27)

Multiple Applications on One SAP HANA System

Multiple applications on a SAP HANA system are also known as Multiple Components on One Database (MCOD). The technical deployment type MCOD refers to a scenario in which more than one application or component is running on a SAP HANA system. This type of provision is available with restrictions for HANA productive systems.

Figure not included in this excerpt

Fig.2: Structure of the MCOD (see SAP 2016c, page 28)

Multiple SAP HANA Systems on One Host

Several SAP HANA systems that are located on a host are also described as Multiple Components on One System (MCOS). SAP supports the execution of multiple SAP HANA systems (SIDs) on a single HANA host. However, this is limited to single host / scale-up scenarios. It should also be mentioned that Multi-SID requires considerable attention. This is due to detailed tasks related to system administration and performance management.

Figure not included in this excerpt

Fig.3: MCOS structure (see SAP 2016c, page 29)

SAP HANA Multitenant Database Containers

It is possible to install SAP HANA to support multitenant database containers (MDC). A HANA system installed in multitenant mode can contain more than one multitenant database container. Otherwise it is a single container system. Single container systems can be converted into multiple container systems.

A system with several containers always has exactly one system database, which is used for central system administration, and any number of multitenant database containers (including zero), also called tenant databases. A HANA system installed in multitenant mode is identified by a single system ID (SID). Databases are identified by a SID and a database name. From the point of view of administration, a distinction is made between the tasks carried out at the system level and those carried out at the database level.

All databases in a multitenant system share the same installation of the database system software, the same computing resources and the same system administration. However, each database is self-contained and completely isolated with its own set of database users, its own database catalog and repository.

Figure not included in this excerpt

Fig. 4: Structure of the MDC (see SAP 2016c, p. 26)

SAP HANA virtualization

The technical deployment type SAP HANA with virtualization refers to the scenario in which one or more SAP HANA database SIDs are provided on one or more virtual machines on the SAP HANA server hardware.

Figure not included in this excerpt

Fig.5: Virtualization (see SAP 2016c, p. 32)

3.2 SAP Business Suite powered by SAP HANA

The SAP Business Suite operated by SAP HANA refers to SAP Business Suite applications that run on a SAP HANA database. SAP ERP, SAP CRM, SAP SCM and SAP SRM were migrated and optimized for SAP HANA. For each of these SAP Business Suite components, SAP offers dedicated optimizations and functional innovations and improvements (see SAP 2015a, page 8). The term “Suite on HANA” is intended to apply to the description below.

General concepts

OLAP and OLTP are carried out in one system. This increases the potential for innovative applications and innovative business processes and offers the possibility of consolidating several productive SAP Business Suite systems in one system. Improved overall reaction times for existing transactions and entire business processes through general performance improvement of the underlying HANA database. Further improvements through embedded query and processing capabilities on the database called code pushdown. Newly designed end-to-end scenarios that accelerate important business processes, such as material requirements planning (MRP) in ERP. In addition, new applications can be used that were previously not available. The focus here is on predictive maintenance and service. New User Experiences (UX), such as SAP Fiori Launchpad applications, are now also possible (see SAP 2015a, p.8 ff.)

3.3 S / 4HANA Enterprise Management

At the beginning, SAP HANA was only available as an appliance. In the meantime, however, SAP HANA has been further developed into a universal platform for all SAP business applications. The business applications are supported by in-memory technology. SAP HANA can also be installed on the customer's own hardware or in the cloud (see SAP 2013a). In January 2013, SAP published that the core applications of the SAP Business Suite should now be available on the basis of HANA (see SAP 2013b).

In 2015, SAP presented SAP Business Suite 4 SAP HANA (SAP S / 4HANA), the first complete product based entirely on the simplified data model of SAP HANA (see SAP 2015c).

Another essential milestone in the implementation of this HANA strategy is the SAP Business Suite 4 SAP HANA for short: SAP S / 4HANA, which was presented by SAP at the beginning of 2015. It is described as a next-generation solution suite, which is based entirely on SAP HANA. The "S" at the beginning stands for "Simple" and means the simplification of the entire system architecture, the program structure and the data model (see SAP 2015c). Since the switch from the R / 2 to the R / 3 system, S / 4HANA has represented the greatest innovation of SAP so far. This suite is an integration in a uniform product portfolio of different approaches, technologies and innovations (cf. Matzer / Karlstetter 2015 ).

SAP S / 4HANA enables a significant simplification in terms of acceptance, data model, user experience, decision-making, business processes and models. S / 4HANA further simplifies innovations relating to the Internet of Things, Big Data, business networks and “Mobile First” approaches that help companies in the digital and networked world to simplify their business processes.

Figure not included in this excerpt

Fig. 6: Overview of S / 4HANA (see SAP 2015c)

With SAP S / 4HANA, SAP follows three premises (see Matzer / Karlstetter 2015):

1. Real Time: Support of simulations and predictions

2. Networked: Integration with Ariba and other SAP cloud software

3. Simple: Reduction of complexity and increase in user-friendliness

Furthermore, SAP S / 4HANA aims to significantly simplify existing business models and processes. It is part of SAP's understanding that future solutions can be implemented quickly. Furthermore, the system should be networked (online) and configured on the basis of templates (here: Best Practices) in accordance with the requirements recorded (here: Guided Configuration). In addition, through an HTML5-based user interface, SAP Fiori enables the implementation of personalization, as well as the execution of applications (here: apps) on almost all end devices (see SAP 2015c).

SAP S / 4HANA is available in two deployment variants. In addition to the cloud version, which is made publicly available, SAP also offers an on-premise version in order to be able to serve all customer groups (see SAP 2015d)

Figure not included in this excerpt

Fig.7: Provision models for S / 4HANA (see Wagner / Mathäß 2016, page 7)

This means that SAP is not turning the focus away from conventional product variations, but is also developing them further. SAP supports the switch from the SAP Business Suite to SAP S / 4HANA regardless of whether the customer's previous solutions are already running on SAP HANA (see SAP 2015e).

Depending on the customer's starting point, there are costs for the SAP HANA license and the SAP S / 4HANA code line. In the cloud model, the license will be included in the monthly subscription to be paid (see SAP 2015d).

SAP is positioning the S / 4HANA Enterprise Management application suite as a platform for the so-called "digital transformation" in companies and designating it as the "digital core" (see SAP 2015e).

In addition, the processes in the S / 4HANA Business Suite - previously limited to financial processes - are now being completed. It is now possible to cover processes and their continuous use in the corporate areas of marketing, sales, procurement, manufacturing, logistics, service, finance, human resources, research and development (see IT online magazine 2015).

In particular, the core functions of corporate software are now to be included in a revised SAP S / 4HANA Enterprise Management. The revision is primarily a simplification for the user. There was also a technological revision. Among other things, aggregate tables and redundancies in finance and production, supply chain and materials management have been removed. SAP is talking about reducing the “digital footprint” (see IT online magazine 2015).

Figure not included in this excerpt

Fig.8: S / 4HANA Enterprise Management (see SAP 2016f)

SAP S / 4HANA Enterprise Management is provided on-premise and as cloud solutions. After SAP S / 4HANA was made available in February 2015, the first "great" SAP HANA release will be available from November 2015. This release contains simplifications for all departments in the ERP context. In this context, the following specialist areas are spoken of: materials management, production and procurement, as well as sales and planning. Thus, with the new release, the areas of a "normal" ERP within SAP S / 4HANA Enterprise Management are now mapped in a new, simplified version (see Fig. 8). This release does not include solutions for the areas of occupational health and safety and environmental protection (Environment, Health and Safety) as well as some functionalities for quality management that will be introduced as part of future releases (see SAP 2015f) . This application suite is of course based on the in-memory database SAP HANA and uses SAP Fiori as a role-based user interface (see SAP 2015d).

3.4 SAP Fiori

SAP Fiori is a product portfolio consisting of different SAP applications, which is a device-independent user interface. SAP Fiori provides the most frequently used functions of the SAP Business Suite, mobile and desktop applications (see SAP 2015f).

From a technical point of view, the apps from the SAP Fiori collection are browser applications that are based on SAP's own version of the HTML5 markup language (SAPUI5) and support all common operating system platforms and browsers (cf. Schaffry 2014). With SAP Fiori, SAP users can complete all tasks in a role-based, process-related and convenient way in a single modern user interface, on which transactions from various applications of the SAP Business Suite are merged. This is a great advantage because, for example, a sales employee can access data records from SAP CRM if he wants to contact a customer, whereas orders are to be recorded in SAP ERP. Thus, SAP Fiori increases the usability of SAP systems, currently SAP 1013 offers different apps (see SAP 2016d).

3.5 S / 4HANA deployment options

SAP S / 4HANA is provided as an on-premise, cloud and hybrid implementation. This should enable SAP customers to use exactly the solution that best suits their individual needs. SAP customers traditionally define their “core business” or “core processes” in the areas in which they differ from their competitors in order to generate a competitive advantage. These areas are often kept on-site in a system environment in which customers require maximum flexibility and thus offer all configuration options.


End of the reading sample from 45 pages