Die Planung der Einführung von SAP S/4HANA Enterprise Management mithilfe einer strategischen Roadmap


Projektarbeit, 2016

45 Seiten, Note: 1,6


Leseprobe

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1 Einleitung

2 Grundverständnis der In-Memory Technologie
2.1 Funktionsweise von In-Memory
2.1.1 Spaltenorientierte Datenspeicherung
2.1.2 Kompressionsverfahren

3 Einführung in SAP HANA
3.1 SAP HANA Architektur
3.2 SAP Business Suite powered by SAP HANA
3.3 S/4HANA Enterprise Management
3.4 SAP Fiori
3.5 Bereitstellungsoptionen von S/4HANA
3.6 Migrationswege
3.7 Was SAP HANA verspricht

4 Roadmapping innerhalb des Projektmanagements
4.1 Projektmanagement
4.2 Das idealtypische Phasenmodell
4.3 Einführung in das Roadmapping
4.3.1 Stand der Wissenschaft
4.3.2 Klassifizierung von Roadmaps
4.4 Einordnung der Roadmap in das Phasenmodell

5 Auswirkung von IMDM auf Geschäftsprozesse

6 Praktischer Ansatz einer HANA-Roadmap

7 Kritische Würdigung

Anhang

Literaturverzeichnis

Abbildungsverzeichnis

Abbildung 1: Aufbau SCOS

Abbildung 2: Aufbau MCOD

Abbildung 3: Aufbau MCOS

Abbildung 4: Aufbau MDC

Abbildung 5: Virtualisierung

Abbildung 6: Überblick S/4HANA

Abbildung 7: Bereitstellungsmodelle für S/4HANA

Abbildung 8: S/4HANA Enterprise Manaement

Abbildung 9: Entscheidungsmatrix und Migrationspfade

Abbildung 10: Idealtypisches Phasenmodel

Abbildung 11: Roadmap nach Phaal

Abbildung 12: Phasenmodel HANA-Roadmap

Abbildung 13: Enterprise Performance In-Memory Circle

Abbildung 14: S/4HANA On-Premise Edition – vereinfacht

Abbildung 15: Mögliche Transformationpfade

Tabellenverzeichnis

Tabelle 1: SAP Lab-Ergebnisse: Geschäftsprozesse

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

Im Zuge des technologischen Wandels stehen Unternehmen heutzutage vor neuen Einflussfaktoren und damit verbundenen Herausforderungen. So beeinflusst dies die Entwicklung eines Unternehmens erheblich, umgekehrt jedoch kann ein Unternehmen oftmals nur auf diese Einflussfaktoren reagieren. Dabei nimmt eine wohl überlegte Strategie hinsichtlich der Investition in neue Technologien eine Schlüsselrolle ein. Unternehmen sehen sich der Frage gegenüber, in welche Technologie wann investiert werden soll. Dabei hat die Einführung neuer Technologien in der Regel großen Einfluss auf das gesamte Unternehmen und dessen Prozesse. Daher müssen hierfür vor allem die Chancen und Risiken einer solchen Investition analysiert und bewertet werden.

Häufig stehen Unternehmen dabei vor der Problemstellung, dass neue Technologien ein unbekanntes Terrain darstellen. So auch S/4HANA und die damit Verbundene In-Memory-Technologie. Weiter stellt die Einführung von S/4HANA ein komplexes Unterfangen dar, bei dem verschiedenen Einflussfaktoren und Abhängigkeiten innerhalb eines Unternehmens berücksichtigt werden müssen.

Um diese Herausforderung zu lösen besteht die Möglichkeit der Entwicklung einer spezifischen Roadmap. In diesem Zusammenhang wird auch häufig von einer Vorstudie gesprochen. Primär liegt der Fokus hierbei darauf eine realistische Durchführung der Problembearbeitung zu erörtern. Weiter zielt die Roadmap darauf ab, für den weiteren Verlauf des Projekts entscheidende Weichen zu stellen oder festzustellen, dass das Projekt nicht weiter verfolgt werden soll.

Vorerst wird dem Leser eine kurze Einführung in das Grundverständnis der In-Memory-Technologie gegeben und grundlegende Begrifflichkeiten des In-Memory-Datamanagements erläutert. Weiter erfolgt eine Einführung in das Thema SAP HANA. Unter diesem Thema soll dem Leser dargelegt werden, was SAP HANA ist und welche Anwendungen hiermit ermöglicht werden. Im Anschluss daran wird das Thema Roadmapping behandelt. Hierbei erfolgen eine Klassifizierung und eine sachlogische Zuordnung von Roadmaps im Kontext der Projektmanagements. Nachfolgend wird eine HANA-Roadmap als Praxisbeispiel eingeführt. Dies soll den Leser künftig in die Lage versetzen die Terminologie Rund um das Thema Roadmaps im S/4HANA Kontext zu verstehen. Letztendlich erfolgt eine kritische Würdigung des hinsichtlich des Roadmappings und S/4HANA.

2 Grundverständnis der In-Memory Technologie

Durch eine In-Memory Datenbank wird eine Datenbank (DB) beschrieben, welche darauf abzielt den gesamten Datenbestand innerhalb des Arbeitsspeichers permanent vorzuhalten, so dass dieser die Daten verarbeiten kann (vgl. Garcia-Molina/Salem 1992, S.509).

Die Idee bzw. der Grundgedanke von In-Memory-Data-Management (IMDM) ist allerdings nicht neu, da dieser Ansatz bereits in den 1980er Jahren aufgegriffen wurde (vgl. Loos 2012, 209 ff.). Doch damals erschwerten die mangelnde Zuverlässigkeit des Hauptspeichers sowie die enormen Kosten eine nachhaltige Verwendung (vgl. Plattner/Zeier 2011, S.6-7). Weiter entstanden damals Probleme durch Hardwarefehler sowie durch Flüchtigkeit des Hauptspeichers (vgl. Lehmann/Carey 1987, S.104-105). So bestand nicht die Möglichkeit, mehrere Prozessoren auf effektive Weise zu nutzen. Ebenso war es nicht möglich große Speicherbereiche zu adressieren(vgl. Eich 1989, 251 ff.).

Doch durch fortschrittliche Architekturen bei Computern, zu welchen auch Mehrkernprozessoren, 64-Bit-Technologie und günstige Arbeitsspeichermengen mit entsprechender Größe zählen, ist die sinnvolle Umsetzung dieses theoretischen Konzepts möglich geworden (vgl. Plattner/Zeier 2011. S.11).

Somit wird es mittlerweile ermöglicht große In-Memory-DB mit Arbeitsspeicherkapazitäten, welche im Terabyte-Bereich einzuordnen sind, zu realisieren (vgl. Kemper, Neumann 2011, S. 196).

So ist gegen Mitte des letzten Jahrzehnts dieser Ansatz von Datenbanksystemen wieder in den Fokus gerückt. Es können nun mit Hilfe von Memory-Datenbanken zeitkritische Analysen und Auswertungen auf Basis sehr großer Datenbestände schneller als je zuvor erstellt werden (vgl. Mattern/Croft 2014, S.2). In traditionellen DB-Systemen hat sich das Konzept einer zeilenorientierten Organisation der Daten etabliert. Hierbei werden die Attributwerte eines Datensatzes nebeneinander angeordnet (vgl. Krueger et al. 2010, S.143-158).

Anwendungen des IMDM setzen primär eine spaltenorientierte Speicherung der Daten ein. Hier werden die Attributwerte des Datensatzes untereinander auf benachbarte Blöcke verteilt (vgl. Plattner/Zeier 2011, S.13 ff.). Dadurch es möglich z.B. Kompressionsalgorithmen effizient zu implementieren. Weiter führt dies zu einer signifikanten Reduzierung des Datenvolumens. Es wird hierbei bis zu einem Faktor von zehn gesprochen (vgl. Sinzig/Sharma 2011, S.18-23).Somit können auch große Datenmengen effizient gespeichert werden (Thiele et al. 2011, S.57-68).

2.1 Funktionsweise von In-Memory

Wie Eingangs beschrieben verwendet IMDM im Vergleich zu traditionellen DB-Systemen den Arbeitsspeicher zur Datenspeicherung anstelle von Festplattenlaufwerken (vgl. (vgl. Garcia-Molina / Salem 1992, S.509-511). Das theoretische Grundprinzip von In-Memory-DB beruht darauf, in den Hauptspeicher zu schreiben und bei Lesevorgängen auf Daten aus dem Hauptspeicher zuzugreifen (vgl. Mattern/Croft 2014, S.29).

Zwar existieren bei IMDB neben den im Arbeitsspeicher vorgehaltenen Daten noch weitere Daten im Sekundärspeicher, diese werden aber ausschließlich aus Sicherungs- und Wiederherstellungsgründen zur Verfügung gestellt (vgl. Garcia-Molina 1992, S-512).

Informationssysteme, welche IMDB einsetzen, wird es somit ermöglicht, Datenbankabfragen sehr viel schneller und effizienter zu verarbeiten. Grund hierfür sind die schnelleren Zugriffszeiten auf den Arbeitsspeicher im Vergleich zum Sekundärspeicher (vgl. Dewitt et al. 1984, S.1-8). Weiter sind in IMDM spaltenbasierende Datenstrukturen anzutreffen. Ebenso werden spezielle Kompressionsverfahren eingesetzt, welche die Zugriffszeiten weiter verkürzen (vgl. Maier / Scheffler 2011, S.116).

2.1.1 Spaltenorientierte Datenspeicherung

Der Begriff der spaltenorientierten Datenbank beschreibt die Funktionsweise, wie Daten auf dem zu verwendenden persistenten Speichermedium abgelegt werden (Bösswetter 2010).

Traditionell werden wie erwähnt Datensätze in einer traditionellen relationalen DB zeilenorientiert abgespeichert, wobei eine Zeile einem zusammenhängenden Datensatz entspricht. Dieser Datensatz besteht dabei aus mehreren Attributen (Spalten). Bei der spaltenorientierten Speicherung werden dazu im Vergleich die Werte einer Spalte fortwährend abgelegt (vgl. Abadi/Boncz/Harizopoulos 2009, 1664-1665).

Der zeilenorientierte Ansatz lässt sich dabei mit dem spaltenorientierten Ansatz vergleichen: Eine Speicherung in zeilenorientierter Form ist von Vorteil für die OLTP (Online Transaction Processing)- Verarbeitung. Bei diesem Ansatz werden primär einzelne Datensätze angefragt und im Anschluss verarbeitet. Im Gegensatz dazu spielt der spaltenorientierte Ansatz in analysierenden Applikationen seine Vorteile aus. Dies begründet sich darin, dass diese Anwendungen hauptsächlich eine größere Datenmenge anfragen. Auf diesen Daten erfolgt dann eine Berechnung, oftmals statistisch (vgl. Mattern/Croft 2014, S.132) Darüber hinaus hat spaltenorientierte Speicherung insbesondere bei breiten Tabellen einen relevanten Vorteil, wenn in der Anfrage nur wenige Attribute benötigt werden. Weiter lässt sich eine Kompression in zeilenorientierten DB-Systemen nur sehr aufwendig durchführen. Das ist darauf zurückzuführen, dass in einem Datensatz häufig Werte mit vielen verschiedenen Datentypen gespeichert sind. Doch die spaltenorientierte Speicherung der Daten wiederum ordnet sehr ähnlichen Werte eine Spalte auch physisch beieinander. Somit bietet dies einen guten Ansatz für die Kompression (vgl. Plattner/Zeier 2011, S.33-35).

Innerhalb der Literatur (vgl. Flaig 2013, S.14) werden auch alternative Ansätze zur hinsichtlicher der Datenorganisation in InMemory-Datenbanken erwähnt. Diese Ansätze haben u. a. das Ziel noch eine noch höhere Performanz bei OLTP-Abfragen zu erreichen. So wurde eine zeilenorientierte In-Memory-Datenbank von Stonebraker et al. (2007) entwickelt, welche vollständig in Bezug auf OLTP optimiert. Somit ist es möglich OLTP-Transaktionsraten zu erreichen, welche bis um den Faktor 82 höher sind als bei einer konventionellen Datenbank. Weiter ist in diesem Zusammenhang zu beachten, dass eine derart spezialisierte In-Memory-Datenbank ausschließlich für ihren Einsatzzweck, also OLTP vorgesehen ist. Daher kann Datenbank nicht für komplexe analytische Abfragen eingesetzt werden (vgl. Stonebraker et al. 2007, S.1151, 1153).

Plattner/Zeier (2011) propagieren dabei neben einem rein zeilen- oder spaltenorientierten Datenlayout auch eine Mischung aus diesen beiden Ansatätzen. Ein solches hybrides Datenlayout basiert dabei auf einer vertikalen Partitionierung der Tabellen. Im Vergleich zu der spaltenorientierten Datenorganisation werden hier allerdings nicht die kompletten Datenbanktabellen spaltenweise zerlegt, sondern in separate Spalten (Attribute) aus den Tabellen gelöst und als zusammenhängende Einheiten gespeichert. Die übrigen Attribute werden schließlich analog zur zeilenorientierten Datenorganisation, tupelweise auf dem Datenspeicher hinterlegt. Unter Verwendung dieses hybriden Datenlayouts wird darauf abgezielt, einen Kompromiss zwischen transaktionalen und analytischen Abfragen herzustellen. Doch stellt weiter die Fragestellung, welche Attribute spaltenorientiert gespeichert werden sollen, eine neue Herausforderung in diesem Kontext dar(vgl. Plattner/Zeier 2011, S. 75 ff.).

So lässt sich abschließend festhalten, dass die meisten In-Memory-Datenbanken auf einer spaltenorientierten Datenspeicherung basieren. Dadurch können nicht nur eine sehr schnelle Ausführung komplexer analytischer Abfragen ermöglichtwerden, daneben ist es auch möglich hohe Transaktionsraten bei schreibenden OLTP-Abfragen zu generieren. Insbesondere auf OLTP abgestimme In-Memory-Datenbanken, unter Verwendung eines zeilenorientierten Datenlayout, bilden hingegen die Ausnahme, wobei auch sie nichtsdesttrotz in bestimmten Anwendungsgebieten sinnvoll sein können (vgl. Flaig 2013, S.14).

2.1.2 Kompressionsverfahren

Als einen großen Vorteil der spaltenorientierten Speicherung kann die Möglichkeit der effektiven Kompression angesehen werden. Dadurch soll weniger Speicherplatz auf dem zu verwendenden Speichermedium benötigt werden. Dabei wird in der Literatur von einem Faktor bis zu zwanzig berichtet, um welchen eine komprimierte spaltenorientierte DB im Vergleich zueiner zeilenorientierten Datenbank, welche unkompliziert ist, kleiner ist (vgl. Plattner 2009, S.5)

Es besteht zwar auch die Möglichkeit in zeilenorientierten DB gleichermaßen Kompressionen umzusetzen, diese sind allerdings weniger effizient. Weiter ist festzustellen, dass eine Kompression der Daten sich zum einen positiv auf den benötigten Speicherplatz auswirkt und zum anderen auch durchaus einen positiven Einfluss auf die Geschwindigkeit der Verarbeitung der DB hat (vgl. Plattner/Zeier 2011, S.18).

Bei der Kompression der Daten ist es möglich unterschiedliche Verfahren anzuwenden. Insbesondere die Lexikon-basierte Kompression ist häufig unter Verwendung. So werden im Rahmen dieses Ansatzes alle unterschiedlichen Werte einer Spalte bzw. eines Attributs in ein Lexikon abgespeichert. Dieser werden dann mit einer eindeutigen ID abgespeichert. Bei SAP HANA kommt z.B. „dictionary encoding“ zum Einsatz (vgl. Müller 2013, S.143-146). Bei dieser Methode werden die Spaltenwerte als Integer-Werte abgelegt. Wird nach unterschiedlichen Werten gesucht oder gar eine „Joint-Operationen“ durchgeführt, so greift der Algorithmus auf die besagten Werte zu. Dadurch ist es möglich, Abfragen wesentlich schneller und effizienter durchzuführen im Vergleich dazu wenn es sich hierbei um Strings handeln würde. Daraus resultiert, dass die abgefragten Werte schneller durch den Arbeitsspeicher an den Prozessor weitergereicht werden können (vgl. Müller 2013, S.143f.).

Weitere Verfahren zur Kompression, die im Rahmen dieser Arbeit jedoch nicht näher betrachtet werden, sind das „Run Length Encoding“ sowie das „Bit Vector Encoding“ (vgl. Krueger 2010, S.133).

3 Einführung in SAP HANA

Folgend soll die Datenbanktechnologie HANA eingeführt werden. Diese Technologie wurde von dem deutschen Softwarekonzern SAP SE entwickelt und vertrieben. HANA ist das Akronym für High Performance Analytic Appliance. Weiter kann HANA als Zusammenwirken von neuer Technologie, welche sich aus Hardware und Software zusammensetzt, verstanden werden. Einfach beschrieben ist SAP HANA eine Datenbank, Hardware und Lösung gleichermaßen. „SAP HANA ist eine In-Memory-Datenbank, aber keine Anwendung. Und obwohl sie keine Lösung an sich ist, ist SAP HANA eine Technologie, die Lösungen ermöglicht“ (vgl. Berg/Penny 2015, S.175).

Die HANA-Architektur wurde 2008 von der SAP in Kooperation mit dem Hasso-Plattner-Institut und der Stanford University, für die Analysen von große Daten in Echtzeit, entwickelt. Bevor sich der Name „HANA“ etabliert hat, war die Anwendung in verschiedenen Publikationen auch unter den Bezeichnungen „SanssouciDB“ oder „NewDB“ anzutreffen (vgl. Kurzdim 2011). SAP HANA wurde erstmals im Frühling 2010 öffentlich vorgestellt und ab November des besagten Jahres eingesetzt (vgl. SAP 2011a). Weiter stellt SAP HANA eine der ersten Plattformen für das Datenmanagement, die Transaktionen und Analysen auf einer einzigen, singulären Datenkopie im Hauptspeicher verarbeitet, dar (vgl. SAP 2016a).

HANA kann universell sowohl für OTLP als auch für OLAP (Online Analytical Processing) eingesetzt werden. Dabei kann je nach zu erstellender Tabelle definiert werden, ob diese spalten- oder zeilenorientiert abspeichert werden soll.

Darüber hinaus stellt SAP HANA eine Importschnittstelle für Massendaten bereit. Dabei kann es sich etwa um BigData handeln, welche mittels Stapelverarbeitung (Batch) importiert werden können. Zudem bietet SAP HANA eine integrierte Schnittstelle zum OpenSource Statistikpaket R; so dass in der Datenbank selbst umfangreiche und komplexe Statistikberechnungen, auch im multivariaten Bereich, vorgenommen werden können (vgl. Kleis 2012, S.20-26).

Aufgrund der Integration des MapReduce-Programmiermodells in die HANA-DB wird es ermöglicht, Vorgänge von SQL-Abfragen und Analytik zu parallelisieren. Dies führt zu einer weiteren Beschleunigung der Verarbeitung.

Zusammenfassend soll unter SAP HANA folgendes verstanden werden:

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

Zu Deutsch: SAP HANA ist eine moderne, integrierte Datenbank und Plattform, die on-premise oder in der Cloud implementiert werden kann.

3.1 SAP HANA Architektur

Technische Bereitstellungsoptionen für SAP HANA

Die technischen Bereitstellungsoptionen legen fest, wie SAP-HANA-Systeme, Hosts für SAP-HANA-Systeme und Anwendungen auf SAP HANA eingesetzt werden können. Nachfolgend soll dem Leser einen Überblick die potentiellen Möglichkeiten der HANA Architektur gegegeben werden. Diese Überblick erfolgt auf Basis der SAP HANA Master Guides (vgl. SAP 2016c).

Single Application on One SAP HANA System

Eine einzelne Anwendung auf einem SAP-HANA-System wird auch als Single Component on One System (SCOS) bezeichnet. Um die verschiedenen anderen Optionen für die technische Bereitstellung besser beschreiben zu können, ist es sinnvoll, zuerst den einfachen, unkomplizierten Ansatz zur Implementierung einer Anwendung auf einem SAP-HANA-System darzustellen. Dies ist für Vergleichszwecke nützlich. In dieser Konfiguration läuft eine einzelne Anwendung in einem einzigen Schema in einer einzigen SAP-HANA-Datenbank als Teil eines SAP-HANA-Systems. Dies ist ein einfaches Szenario, das für alle Szenarien uneingeschränkt unterstützt wird.

Abbildung in dieser Leseprobe nicht enthalten

Abb.1: Aufbau SCOS (vgl. SAP 2016c, S.27)

Multiple Applications on One SAP HANA System

Mehrere Anwendungen auf einem SAP-HANA-System werden auch als Multiple Components on One Database (MCOD) bezeichnet. Die technische Bereitstellungsart MCOD bezieht sich auf ein Szenario, in dem mehr als nur eine Anwendung oder eine Komponente auf einem SAP-HANA-System ausgeführt wird. Diese Bereitstellungsart ist mit Einschränkungen für HANA- produktiv-Systeme verfügbar.

Abbildung in dieser Leseprobe nicht enthalten

Abb.2: Aufbau MCOD (vgl. SAP 2016c, S.28)

Multiple SAP HANA Systems on One Host

Mehrere SAP-HANA-Systeme die sich auf einem Host befinden werden auch als Multiple Components on One System (MCOS) beschrieben. SAP unterstützt die Ausführung mehrerer SAP HANA Systeme (SIDs) auf einem einzigen HANA Host. Dies ist allerdings auf Single-Host / Scale-up-Szenarien beschränkt. Weiter muss erwähnt werden, dass Multi-SID erhebliche Aufmerksamkeit erfordert. Dies ist auf detaillierte Aufgaben im Zusammenhang mit der Systemadministration und dem Performance-Management zurückzuführen.

Abbildung in dieser Leseprobe nicht enthalten

Abb.3: Aufbau MCOS (vgl. SAP 2016c, S.29)

SAP HANA Multitenant Database Containers

Es ist möglich SAP HANA zu installieren, um Multitenant-Datenbank-Container (MDC) zu unterstützen. Ein HANA-System, das im Multitenant-Modus installiert ist, kann mehr als einen multitenant Datenbankcontainer enthalten. Ansonsten handelt es sich um ein Einzelbehältersystem. Einzelbehältersysteme können in Mehrbehältersysteme umgewandelt werden.

Ein System mit mehreren Containern hat immer genau eine Systemdatenbank, die für die zentrale Systemadministration verwendet wird, und eine beliebige Anzahl von Multitenant-Datenbankcontainern (einschließlich Null), auch Tenant-Datenbanken genannt. Ein HANA-System, das im Multitenant-Modus installiert ist, wird durch eine einzige System-ID (SID) identifiziert. Datenbanken werden durch eine SID und einen Datenbanknamen identifiziert. Aus Sicht der Verwaltung unterscheidet man zwischen den auf der Systemebene und den auf Datenbankebene durchgeführten Aufgaben.

Alle Datenbanken in einem Multitenant-System teilen sich dieselbe Installation der Datenbanksystemsoftware, die gleichen Rechenressourcen und dieselbe Systemverwaltung. Jedoch ist jede Datenbank in sich abgeschlossen und vollständig isoliert mit ihrem eigenen Datensatz von Datenbankbenutzern, einem eigenen Datenbankkatalog sowie Repository.

Abbildung in dieser Leseprobe nicht enthalten

Abb.4: Aufbau MDC (vgl. SAP 2016c, S. 26)

SAP HANA Virtualisierung

Der technische Einsatztyp SAP HANA mit Virtualisierung bezieht sich auf das Szenario, in dem eine oder mehrere SAP-HANA-Datenbank-SIDs auf einer oder mehreren virtuellen Maschinen auf der SAP HANA-Serverhardware bereitgestellt werden.

Abbildung in dieser Leseprobe nicht enthalten

Abb.5: Virtualisierung (vgl. SAP 2016c, S. 32)

3.2 SAP Business Suite powered by SAP HANA

Die von SAP HANA betriebene SAP Business Suite bezieht sich auf SAP Business Suite-Anwendungen, die auf einer SAP-HANA-Datenbank laufen. SAP ERP, SAP CRM, SAP SCM und SAP SRM wurden migriert und für SAP HANA optimiert. Für jede dieser SAP-Business-Suite-Komponenten bietet SAP dedizierte Optimierungen und funktionale Neuerungen und Verbesserungen (vgl. SAP 2015a, S.8). So soll der Begriff „Suite on HANA“ für die Beschreibung im Folgenden gelten.

Allgemeine Konzepte

OLAP und OLTP werden in einem System ausgeführt. Dies erhöht das Potenzial für innovative Anwendungen und innovative Geschäftsprozesse und bietet die Möglichkeit, mehrere produktive SAP Business Suite-Systeme in einem System zu konsolidieren. Verbesserte Gesamtreaktionszeiten für bestehende Transaktionen und gesamte Geschäftsprozesse durch allgemeine Performanceverbesserung der zugrundeliegenden HANA-Datenbank. Weitere Verbesserungen durch eingebettete Abfrage- und Verarbeitungsfunktionen auf der Datenbank, die als Code-Pushdown bezeichnet werden. Neu gestaltete End-to-End-Szenarien, die wichtige Geschäftsprozesse beschleunigen, wie bspw. die Materialbedarfsplanung (MRP) in ERP. Weiter können neue Applikationen eingesetzt werden, die bisher nicht einzusetzen waren. Hierbei liegt der Fokus auf Predictive Maintenance und Service. Ebenso sind nun neue User Experiences (UX), wie SAP Fiori Launchpad Anwendungen, möglich (vgl. SAP 2015a, S.8 ff.)

3.3 S/4HANA Enterprise Management

Zu Beginn war SAP HANA nur als Appliance verfügbar. Inzwischen wurde SAP HANA allerdings zu einer universellen Plattform für alle SAP-Geschäftsanwendungen weiterentwickelt. So werden die Geschäftsanwendungen durch In-Memory-Technologie unterstützt. SAP HANA kann auch auf kundeneigener Hardware installiert werden oder in der Cloud liegen (vgl. SAP 2013a). Im Januar 2013 wurde durch die SAP veröffentlicht, dass die Kernanwendungen der SAP Business Suite nun auf Basis von HANA verfügbar sein sollen (vgl. SAP 2013b).

Im Jahre 2015 stellte SAP mit SAP Business Suite 4 SAP HANA (SAP S/4HANA) das erste vollständige Produkt vor, welches komplett auf dem vereinfachten Datenmodell von SAP HANA beruht (vgl. SAP 2015c).

Ein weiterer essentieller Meilenstein in der Umsetzung dieser Strategie von HANA, ist die SAP Business Suite 4 SAP HANA kurz: SAP S/4HANA, welche Anfang 2015 von der SAP vorgestellt wurde. Sie wird als Lösungssuite der nächsten Generation beschrieben, welche vollständig auf SAP HANA basiert. Das „S“ am Anfang steht für „Simple“ und meint damit die Vereinfachung der gesamten Systemarchitektur, der Programmstruktur und des Datenmodells (vgl. SAP 2015c). Seit der Umstellung vom R/2- auf das R/3-System stellt S/4HANA die bisher größte Innovation der SAP dar. Diese Suite ist eine Integration in einem einheitlichen Produktportfolio von unterschiedlichsten Ansätzen, Technologien und Innovationen (vgl. Matzer/Karlstetter 2015).

SAP S/4HANA ermöglicht eine signifikante Vereinfachung im Sinne von Akzeptanz, Datenmodell, User Experience, Entscheidungsfindung, Geschäftsprozesse und –Modelle. Weiter vereinfacht S/4HANA Innovationen rund um das Internet der Dinge, Big Data, Geschäftsnetzwerke und „Mobile First“-Ansätze, die Unternehmen in der digitalen und vernetzten Welt helfen, ihre Geschäftsabläufe zu vereinfachen.

Abbildung in dieser Leseprobe nicht enthalten

Abb.6: Überblick S/4HANA (vgl. SAP 2015c)

Mit SAP S/4HANA folgt die SAP drei Prämissen (vgl. Matzer/Karlstetter 2015):

1. Real Time: Unterstützung von Simulationen und Vorhersagen

2. Networked: Integration mit Ariba und anderer Cloud-Software der SAP

3. Simple: Reduktion von Komplexität und Erhöhung der Nutzerfreundlichkeit

Weiter zielt SAP S/4HANA darauf ab, bestehende Geschäftsmodelle und Prozesse wesentlich zu vereinfachen. So gehört es auch zum Verständnis von SAP, dass zukünftige Lösungen schnell implementiert werden können. Weiter soll das System gem. der aufgenommen Anforderungen vernetzt (online) und auf Basis von Vorlagen (hier: Best Practices) konfiguriert werden können (hier: Guided Configuration). Darüber hinaus ermöglicht SAP Fiori durch eine HTML5-basierte Benutzeroberfläche die Umsetzung von Personalisierung, nebst Ausführung von Anwendungen (hier: Apps) auf nahezu allen Endgeräten (vgl. SAP 2015c).

SAP S/4HANA ist in zwei Bereitstellungsvarianten verfügbar. Neben der Cloud-Version, die öffentlich bereitgestellt wird, bietet SAP auch eine On-Premise-Variante an, um alle Kundengruppen bedienen zu können (vgl. SAP 2015d)

Abbildung in dieser Leseprobe nicht enthalten

Abb.7: Bereitstellungsmodelle für S/4HANA (vgl. Wagner/Mathäß 2016, S.7)

Dies bedeutet, dass die SAP den Fokus nicht von herkömmlichen Produktvariationen abwendet, sondern auch diese weiterentwickelt. Den Umstieg von der SAP Business Suite auf SAP S/4HANA unterstützt SAP ungeachtet der Tatsache, ob die bisherigen Lösungen beim Kunden bereits auf SAP HANA laufen (vgl. SAP 2015e).

Je nach Ausgangspunkt des Kunden fallen Kosten für die SAP-HANA-Lizenz und die SAP S/4HANA-Code-Line an. Im Cloud-Modell wird die Lizenz in der zu entrichtenden monatlichen Subskription enthalten sein (vgl. SAP 2015d).

SAP positioniert die Anwendungssuite S/4HANA Enterprise Management damit als Plattform für die sogenannte „Digitale Transformation“ in den Unternehmen und bezeichnet sie als „digitalen Kern“ (vgl. SAP 2015e).

Weiter werden nun die in der Business Suite S/4HANA – bisher auf die Finanzprozesse beschränkten – Prozesse vervollständigt. So ist es nun möglich Prozesse und deren durchgängige Nutzung in den Unternehmensbereichen Marketing, Vertrieb, Beschaffung, Fertigung, Logistik, Service, Finanzwesen, Personalwesen, Forschung und Entwicklung abzudecken (vgl. IT-Onlinemagazin 2015).

Insbesondere die Kernfunktionen einer Unternehmenssoftware sollen nun in einem überarbeiteten SAP S/4HANA Enterprise Management inkludiert sein. Bei der Überarbeitung handelt es sich primär um eine Vereinfachung für den Nutzer. Daneben gab es auch eine technologische Überarbeitung. So wurden unter anderem Aggregate-Tabellen und Redundanzen im Finanzwesen und in Produktion, Supply Chain und Materialwirtschaft entfernt. Somit spricht SAP hierbei über eine Reduzierung des „digitalen Footprints“ (vgl. IT-Onlinemagazin 2015).

Abbildung in dieser Leseprobe nicht enthalten

Abb.8: S/4HANA Enterprise Manaement (vgl. SAP 2016f)

SAP S/4HANA Enterprise Management wird On-Premise- und als Cloud-Lösungen zur Verfügung gestellt. Nachdem im Februar 2015 SAP S/4HANA bereitgestellt wurde, gibt es ab November 2015 das erste „goße“ SAP-HANA Release. Dieses Release enthält Vereinfachungen für alle Fachbereiche im ERP-Kontext. In diesem Kontext wird von den folgenden Fachbereichen gesprochen: Materialwirtschaft, Produktion und Beschaffung sowie Vertrieb und Planung. Somit sind nun durch das neue Release die Bereiche eines „normalen“ ERP innerhalb von SAP S/4HANA Enterprise Management in einer neuen simplifizierten Version abgebildet (siehe hierzu Abb.8). Nicht in diesem Release enthalten sind Lösungen zu den Bereichen Arbeits-, Gesundheits und Umweltschutz (Environment, Health and Safety) sowie einige Funktionalitäten für das Qualitätsmanagement, die im Rahmen zukünftiger Releases eingeführt werden (vgl. SAP 2015f) . Diese Anwendungssuite basiert natürlich auf der In-Memory Datenbank SAP HANA und nutzt als rollenbasierte Bedienoberfläche SAP Fiori (vgl. SAP 2015d).

3.4 SAP Fiori

SAP Fiori ist ein Produktportfolio bestehend aus unterschiedlichen SAP-Anwendungen, welche eine geräteunabhängige Benutzerschnittstelle ist. So werden durch SAP Fiori die am häufigsten verwenden Funktionen der SAP Business Suite, mobile- und Desktop-Anwendungen, bereitgestellt (vgl. SAP 2015f).

Technisch gesehen handelt es sich bei den Apps aus der SAP-Fiori-Sammlung um Browser-Anwendungen, die auf der SAP-eigenen Version der Auszeichnungssprache HTML5 (SAPUI5) basieren und alle gängigen Betriebssystemplattformen und Browser unterstützen (vgl. Schaffry 2014). Mit SAP Fiori können SAP-Anwender alle Aufgaben rollenbasiert, prozessbezogen und komfortabel in einer einzigen modernen Benutzeroberfläche erledigen, auf der Transaktionen aus verschiedenen Anwendungen der SAP Business Suite zusammengeführt werden. Das ist ein großer Vorteil, da bspw. ein Vertriebsmitarbeiter auf Datensätze aus SAP-CRM zugreifen kann, wenn er einen Kunden kontaktieren will, Aufträge hingegen in SAP ERP erfasst werden sollen. Somit vergrößert SAP Fiori die Bedienbarkeit von SAP-Systemen, derzeit bietet SAP 1013 verschiedene Apps an (vgl. SAP 2016d).

3.5 Bereitstellungsoptionen von S/4HANA

SAP S/4HANA wird als On-Premise-, Cloud- und Hybrid-Implementierung bereitgestellt. Dadurch sollen die Kunden von SAP genau die Lösung nutzen können, welche am besten zu ihren individuellen Bedürfnissen passt. Dabei definieren SAP-Kunden traditionell ihr „Kerngeschäft“ oder „Kernprozesse“, in den Bereichen in denen sie sich von ihren Wettbewerbern unterscheiden, um einen Wettbewerbsvorteil generieren zu können. Diese Bereiche werden häufig in einer Systemumgebung vor Ort gehalten, in der die Kunden maximale Flexibilität erfordern und somit alle Konfigurationsmöglichkeiten anbieten.

[...]

Ende der Leseprobe aus 45 Seiten

Details

Titel
Die Planung der Einführung von SAP S/4HANA Enterprise Management mithilfe einer strategischen Roadmap
Hochschule
Duale Hochschule Baden-Württemberg, Ravensburg, früher: Berufsakademie Ravensburg  (Business Informatics)
Note
1,6
Autor
Jahr
2016
Seiten
45
Katalognummer
V355544
ISBN (eBook)
9783668419933
ISBN (Buch)
9783668419940
Dateigröße
1056 KB
Sprache
Deutsch
Schlagworte
SAP, S4HANA, HANA, Fiori, Roadmap, IT-Roadmap, Phaal, Projektmanagement, Strategie, Enterprise Management, S4HANA Enterprise Managemen, Business Suite, In-Memory, HANA-Roadmap
Arbeit zitieren
Timo Günter (Autor), 2016, Die Planung der Einführung von SAP S/4HANA Enterprise Management mithilfe einer strategischen Roadmap, München, GRIN Verlag, https://www.grin.com/document/355544

Kommentare

  • Noch keine Kommentare.
Im eBook lesen
Titel: Die Planung der Einführung von SAP S/4HANA Enterprise Management mithilfe einer strategischen Roadmap



Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden