Künftige funktionale und technische Änderungen bei Unternehmen durch Simple Finance und Bewertung von SAP S/4 HANA

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

1 Einleitung

2 Grundverständnis der In-Memory-Technologie
2.1 Funktionsweise von In-Memory
2.2 Spaltenorientierte Datenspeicherung
2.3 Kompressionsverfahren

3 Einführung in SAP HANA
3.1 SAP Business Suite powered by SAP HANA
3.2 Allgemeine Konzepte

4 Aktuelle Herausforderungen des Finanzwesens
4.1 Allgemeine Herausforderungen
4.2 Herausforderungen von SAP

5 Innovation durch SAP Simple Finance
5.1 Einführung in Simple Finance
5.2 SAP Simple Finance Architektur
5.3 Entwicklung des SAP Simple Finance Add-Ons
5.4 Schwerpunkte im Central Finance
5.5 Wichtige Innovationen von SAP Simple Finance
5.6 SAP Fiori for SAP Simple Finance Add-On

6 Der Weg zu Simple Finance
6.1 Technische Vorraussetzungen für die Nutzung von Simple Finance
6.2 Bereitstellungsmodelle
6.3 Migrationswege

7 Vorteile von Simple Finance

8 Ausblick zu S/4HANA Enterprise Management

9 Kritische Würdigung

Quellenverzeichnis

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

5.1 Datenmodell

5.2 Universal Journal

5.3 SAP Simple Finance Add-On für SAP Business Suite powered by SAP HANA

5.4 SAP ERP vs. SAP Accounting

5.5 General Ledger

5.6 Anzeige Einzelposten für Sachkonten

6.1 Migrationsoptionen

8.1 Überblick S/4HANA

8.2 S/4HANA Enterprise Management

Tabellenverzeichnis

7.1 SAP Lab-Ergebnisse: Geschäftsprozesse

1 Einleitung

Im Zuge des technologischen Wandels stehen Unternehmen heutzutage vor neuen Einfluss- faktoren 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 und welcher Mehrwert dadurch generiert werden kann. Dabei hat die Einführung neuer Technologien häufig 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.

So stehen Unternehmen oftmals dabei vor der Problemstellung, dass neue Technologien ein unbekanntes Terrain darstellen. So auch bei SAP High Performance Analytic Appliance (HANA) Simple Finance (sFIN) und die damit Verbundene In-Memory-Technologie. Simple Finance ersetzt das klassische FI und CO. Mit dem SAP Finance soll eine Vereinfachung von Datenmodell, Bedienung und Architektur erreicht werden. Daher stellt die Einführung von sFIN ein komplexes Unterfangen dar, bei dem verschiedenen Einflussfaktoren und

Abhängigkeiten innerhalb eines Unternehmens berücksichtigt werden müssen.

Zudem ist vielen Unternehmen der Einfluss dieser Neuerung innerhalb des Finanzbereichs nicht klar. So ist es für das Unternehmen zu empfehlen genau zu betrachten, wie potentielle Kundenszenarios aussehen und diese neu gestaltet werden können. Weiter ist zu erörtern, wo unternehmensspezifischen Herausforderungen sind und wie Schlüsselprozesse optimal ausgerichtet werden können. Hier soll sFIN helfen, um diese Herausforderungen zu lösen.

(Vgl. Mang (2015)).

Diese Arbeit zielt darauf ab, zu erläutern was unter Simple Finance zu verstehen ist und welche funktionalen und technischen Änderungen auf Unternehmen zukommen. Weiter soll umfassend auf die Vor- und Nachteile einer Einführung der sFIN Lösung eingegangen werden. Dabei soll auch berücksichtigt werden, dass nicht alle Vorteile allein auf den Funktionalitäten von Simple Finance beruhen, sondern auch von den Vorteilen einer neuen technischen Architektur und der neuen User Experience, getrieben werden.

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. Darauf aufbauend erfolgt eine Einführung in das Thema SAP HANA. Hierbei soll dem Leser dargelegt werden, was unter HANA zu verstehen ist und welche Anwen- dungen hiermit ermöglicht werden. Im Anschluss werden die aktuellen Herausforderungen innerhalb des Finanzwesen aufgegriffen. Dadurch soll ein Verständnis erzeugt werden welche Faktoren für Simple Finance aus Unternehmenssicht relevant sind. Anschließend wird das Kernthema dieser Arbeit behandelt werden. Hierzu wird dargelegt was Simple Finance ist und welche Vorteile und Innovationen damit realisiert werden können. Weiter werden mögliche Wege der Migration vorgestellt, um Simple Finance verfügbar zu machen.

Folgend wird ein Ausblick in Richtung SAP S/4HANA Enterprise Management gegeben, um darzustellen, welche Neuerungen hiermit erzielt werden sollen. Letztendlich soll eine kritische Würdigung hinsichtlich Simple Finance erfolgen.

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 und 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 u. a.

(2011, S. 209 ff.)). Doch damals erschwerten die mangelnde Zuverlässigkeit des Hauptspei- chers sowie die enormen Kosten eine nachhaltige Verwendung (vgl. Plattner und Zeier (2012, S. 6 f.)). Weiter entstanden damals Probleme durch Hardwarefehler sowie durch Flüchtigkeit des Hauptspeichers (vgl. Lehman und Carey (1987, S. 104 f.)). 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, S. 251 f.)).

Doch durch fortschrittliche Architekturen bei Computern, zu welchen auch Mehrkern- prozessoren, 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 und Zeier (2012, S. 11)).

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

Daher 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 und 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 u. a. (2010, S. 143 ff.)).

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 und Zeier (2012, S. 13 ff.)). Dadurch ist es möglich z. B. Kom- pressionsalgorithmen effizient zu implementieren. Weiter führt dies zu einer signifikanten Reduzierung des Datenvolumens. Es wird hierbei bis zu einem Faktor von zehn gespro- chen (vgl. Werner Sinzig, Kailash R. Sharma (2011, S. 18 ff.)).Somit können auch große Datenmengen effizient gespeichert werden (vgl. Lehner und Piller (2011, S. 57 ff.)).

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. Garcia- Molina und Salem (1992, S. 509 ff.)). 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 und Croft (2014, S. 29)).

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

Informationssysteme, welche IMDB einsetzen, wird es somit ermöglicht, Datenbankabfra- gen sehr viel schneller und effizienter zu verarbeiten. Grund hierfür sind die schnelleren Zugriffszeiten auf den Arbeitsspeicher im Vergleich zum Sekundärspeicher (vgl. DeWitt u. a. (1984, S. 1 ff.)). Weiter sind in IMDM spaltenbasierende Datenstrukturen anzutreffen. Ebenso werden spezielle Kompressionsverfahren eingesetzt, welche die Zugriffszeiten weiter verkürzen.

2.2 Spaltenorientierte Datenspeicherung

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

Traditionell werden wie erwähnt Datensätze in einer traditionellen relationalen DB zeilen- orientiert abgespeichert, wobei eine Zeile einem zusammenhängenden Datensatz entspricht.

Dieser Datensatz besteht dabei aus mehreren Attributen (Spalten). Bei der spaltenorien- tierten Speicherung werden dazu im Vergleich die Werte einer Spalte fortwährend abgelegt (vgl. Klas und Neuhold (2007, S. 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 Online Transaction Processing (OLTP)-Verarbeitung. Bei diesem Ansatz werden primär einzelne Datensätze angefragt und im Anschluss verarbeitet. Im Gegensatz dazu spielt der spaltenorientierte Ansatz in ana-lysierenden 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 und 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 und Zeier (2012, S. 33 ff.)).

Innerhalb der Literatur (vgl. Flaig (2013, S. 14)) werden auch alternative Ansätze zur hinsichtli-cher 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 errei- chen. So wurde eine zeilenorientierte In-Memory-Datenbank von DeWitt u. a. (1984) entwickelt, welche vollständig in Bezug auf OLTP optimiert ist. 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. DeWitt u. a. (1984, S. 1151 ff.)).

Plattner und Zeier (2012) propagieren dabei neben einem rein zeilen- oder spaltenorien- tierten Datenlayout auch eine Mischung aus diesen beiden Ansä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 herzu- stellen. Doch stellt weiter die Fragestellung, welche Attribute spaltenorientiert gespeichert werden sollen, eine neue Herausforderung in diesem Kontext dar (vgl. Plattner und Zeier (2012, 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öglicht werden, daneben ist es auch mög- lich hohe Transaktionsraten bei schreibenden OLTP-Abfragen zu generieren. Insbesondere auf OLTP abgestimmte In-Memory-Datenbanken, unter Verwendung eines zeilenorien- tierten Datenlayout, bilden hingegen die Ausnahme, wobei auch sie nichtsdestotrotz in bestimmten Anwendungsgebieten sinnvoll sein können (vgl. Flaig (2013, S. 14)).

2.3 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 zu einer 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 und Zeier (2012, S. 18)).

Bei der Kompression der Daten ist es möglich unterschiedliche Verfahren anzuwenden.

Ins-besondere 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 ff.)). Bei dieser Methode werden die Spaltenwerte als Integer-Werte abgelegt. Wird nach unterschiedli-chen Werten gesucht oder gar eine „Joint-Operationen“ durchgeführt, so greift der Algorith-mus 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. 143 f.)). 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 u. a. (2010, S. 133)).

3 Einführung in SAP HANA

Folgend soll die Datenbanktechnologie SAP HANA (folgend 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 HANA eine Daten- bank, 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 und Silvia (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, entwi- ckelt. Bevor sich der Name „HANA“ etabliert hat, war die Anwendung in verschiedenen Publikationen auch unter den Bezeichnungen „SanssouciDB“ oder „NewDB“ anzutreffen.

HANA wurde erstmals im Frühling 2010 öffentlich vorgestellt und ab November des besag- ten Jahres eingesetzt (vgl. SAP (2011)). Weiter stellt 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 (2016c)).

HANA kann universell sowohl für OTLP als auch für Online Analytical Processing (OLAP) eingesetzt werden. Dabei kann je nach zu erstellender Tabelle definiert werden, ob diese spalten- oder zeilenorientiert abspeichert werden soll. Darüber hinaus stellt 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 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 (2011, S. 20 ff.)).

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 (2016g)).

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

3.1 SAP Business Suite powered by SAP HANA

Die von HANA betriebene SAP Business Suite bezieht sich auf SAP Business Suite- Anwendungen, die auf einer SAP-HANA-Datenbank laufen. Die SAP Business Suite powered by SAP HANA wurde 2012 eingeführt und verwendet anstelle einer Standard- datenbank die SAP HANA Datenbank. So können SAP Enterprise Ressource Planning (ERP), SAP Customer Relationship Management (CRM), SAP Supply Chain Management (SCM) und SAP Supplier Relationship Management (SRM) migriert werden und auf SAP HANA optimiert betrieben werden. Für jede dieser SAP-Business-Suite-Komponenten bietet SAP dedizierte Optimierungen und funktionale Neuerungen und Verbesserungen (vgl. SAP (2015c, S. 8)). So soll der Begriff „Suite on HANA“ für die Beschreibung im Folgenden gelten.

3.2 Allgemeine Konzepte

OLAP und OLTP werden in einem System ausgeführt. Dies erhöht das Potenzial für inno- vative 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 Daten- bank, die als Code-Pushdown bezeichnet werden. Neu gestaltete End-to-End-Szenarien, die wichtige Geschäftsprozesse beschleunigen, wie bspw. die Material Ressource Planning (MRP) in ERP. Weiter können neue Applikationen eingesetzt werden, die bisher nicht einzusetzen wa-ren. Hierbei liegt der Fokus auf Predictive Maintenance und Service. Ebenso sind nun neue User Experience (UX), wie SAP Fiori Launchpad Anwendungen, möglich (vgl. SAP (2015c, S. 8 ff.)).

4 Aktuelle Herausforderungen des Finanzwesens

Der Finanzbereich in Unternehmen ist von einem tiefgreifenden Strukturwandel erfasst und gerät zunehmend unter Druck, denn insbesondere die Digitalisierung machen ihm das Leben schwer. Die Finanzbereiche stehen vor der Herausforderung, sich optimal und innovativ aufzustellen, um die Chancen zu nutzen bzw. die Risiken zu vermeiden, die mit der Digitalisierung einhergehen. Und damit nicht genug: SAP S4/HANA wird die ERP-Standards ebenfalls verändern. (Vgl. Leichsering (2017)) Nachfolgend sollen daher sowohl allgemeine als auch Herausforderungen speziell für SAP dargestellt werden.

4.1 Allgemeine Herausforderungen

Als wesentlicher Trend wird vor allem die Digitalisierung der Vertriebswege, Bankpro- dukte und Geschäftsprozesse gesehen. Dabei steht vor allem das Thema Vernetzung im Vordergrund. Die voranschreitende Digitalisierung hat zahlreiche Arbeitsplätze verän- dert. Elektronische Abläufe sparen im betrieblichen Alltag Zeit und Kosten. In vielen Finanzabteilungen dominiert aber noch immer das Papier, denn Finanzverantwortliche sind sich unsicher, welche Vor- und Nachteile mit einem papierlosen Büro einhergehen. Gleichzeitig wächst der Handlungsbedarf, denn viele Geschäftspartner sind bereits auf elektronische Rechnungen umgestiegen. Die Globalisierung sorgt dafür, dass es im Finanz- und Rechnungswesen in immer kürzeren Abständen zu Neuregelungen kommt. Das stellt Bilanzbuchhalter und Controller mindestens vor zeitliche Herausforderungen. Daneben entstehen durch die hohe Marktdynamik deutliche Veränderungen in den Markt- und Wettbewerbsstrukturen. Profiteure dieser Entwicklungen sind vor allem IT-Start-Ups, da sie agiler und schneller auf Anforderungen reagieren können, welche ihre Marktanteile zu Lasten der klassischen Anbieter in den kommenden Jahren stark ausbauen werden. (Vgl. Leichsering (2017))

Um in diesem Umfeld die Wettbewerbsfähigkeit zu erhalten, ist es notwendig, das Innova- tionstempo zu erhöhen. Die Dienstleister müssen zwar nicht zu Innovationsführern werden, jedoch sollten sie auf Veränderungen flexibel reagieren und entsprechende Entwicklungen schnell, auch softwaretechnisch, realisieren können. Hierzu kann es nützlich sein die Im- pulse aus anderen Branchen bei der Angebotsgestaltung zu nutzen. Vor allem der Handel sowie Telekommunikationsunternehmen werden im Bezug auf B2B als besonders geeignet erachtet. (Vgl. Korschinowski (2015))

4.2 Herausforderungen von SAP

Da SAP die Module FI und CO als ihr Steckenpferd betrachtet, sind die Herausforde- rungen im Bereich Finance sehr ernst zu nehmen und werden von SAP regelmäßig neu geprüft. Im Folgenden werden wichtige Herausforderungen nach BearingPoint (2015) vor der Einführung von Simple Finance angesprochen.

Viele SAP Benutzer, im Speziellen im Bereich des Managements, müssen auf die Ge- schwindigkeit, welche mit der Digitalisierung im Bereich des Cash-Flow-Managements einhergeht, in Echtzeit reagieren können. Deshalb wird seit geraumer Zeit ein System gefordert, welches Daten in Echtzeit wiedergibt und somit schnellere Reaktionszeiten auf Veränderungen möglich macht.

Durch die geforderte Echtzeitüberwachung der Liquidität bzw. aller Geldflüsse verschwimmt in Unternehmen die Grenze zwischen der klassischen Finanzbuchhaltung und dem Control- ling immer mehr. Informationen über den aktuellen Stand müssen in modernen Firmen in Echtzeit zur Verfügung stehen um strategische Entscheidungen richtig treffen zu können.

Die Komplexität der Daten ist gerade in großen Firmen ein Problem, denn oftmals sind weltweit verteilte Systeme im Einsatz. Daraus resultiert eine große Anzahl an Extraktoren, die alle Daten in ein konsolidiertes Business Warehouse leiten müssen. Auch müssen Daten aus verschiedenen Tabellen konsolidiert werden, um korrekte Finanzberichte zu gewährleisten.

Mit Einzug der mobilen Endgeräte sowie des mobilen Internets in die Arbeitswelt wurden viele Applikationen ständig erreichbar, leider wurde dies von SAP bis jetzt nicht zur Verfügung gestellt. Somit kann bisher unterwegs nicht auf betriebliche Daten zugegriffen werden. Die Wettbewerber von SAP zeichnen sich dabei vor allem durch benutzerfreundliche Technologien sowie innovative Ideen aus und setzen das traditionelle Geschäftsmodell stark unter Druck.

5 Innovation durch SAP Simple Finance

Im Rahmen dieser Arbeit soll SAP Simple Finance add-on for SAP Business Suite powered by SAP HANA betrachtet werden. Dies ist ein neues Produkt der SAP und kein rechtlicher Nachfolger von SAP ERP Finance. Das Simple Finance Add-On für die SAP Business Suite wurde 2014 eingeführt. Weiter basiert Simple Finance auf In-Memory-Technologie von SAP HANA, wodurch es ermöglicht wird essentielle Finanz Prozesse zu optimieren.

Technisch gesehen SAP Simple Finance add-on for SAP Business Suite powered by SAP HANA ein Add-On, welches auf SAP enhancement package 7 für SAP ERP 6.0, laufend auf einer HANA Installation, eingesetzt wird. Einzuordnen ist dies als Alternative zu den klassischen ERP Financials core Applikationen des SAP Enhancement package 7 für SAP ERP 6.0 Da Simple Finance ein eigenständiges Produkt ist, wird es nicht im Rahmen einer Wartungsvereinbarung für SAP ERP zur verfügung gestellt. Es gelten eigenständige Wartungsbedingen (vgl. SAP (2015c)). Folgend soll eine Einführung in Simple Finance gegeben werden, mit anschließender Erläutern der wichtigsten Bestandteile und deren Vorteile.

5.1 Einführung in Simple Finance

SAP Simple Finance basiert auf der Nutzung der SAP HANA Datenbank. Hierbei werden innerhalb von SAP neue Funktionen für das Rechnungswesen, Cash-Management und den Bereich des Business Planning and Consolidation geboten. Weiter vereinfacht Simple Finance die Datenstruktur im Finanzwesen, da Indextabellen und Summentabellen bei vielen wichtigen Tabellen im Finanzwesen wegfallen. Durch die Einführung der SAP Simple Finance Add-on Lösung auf SAP HANA entstehen essentielle Neuerungen in den Bereichen Finance und Datenhaltung, welche es Unternehmen eine stark erweiterte ERP- Nutzung und Auswertung ermöglichen soll. Dabei findet im Accounting die erheblichste Innovation durch das Zusammenlegen von Finanzbuchhaltung und Controlling in ein „Ledger“ statt. Dies ist auf die Verwendung eines multidimensionalen Datenmodells, ohne Einschränkung auf die Anzahl von Dimensionen zurückzuführen. Die SAP HANA Plattform ermöglicht einen wesentlich schnelleren Datenzugriff sowohl beim Berichtsaufruf als auch in den Monatsabschlussjobs wie zum Beispiel bei Kalkulationsläufen oder Abrechnungen.

Die SAP HANA Plattform macht zudem als Single-Point-of-Truth wieder-kehrende und aufwendige Abstimmprozesse zwischen den einzelnen SAP Anwendungen FI, CO, CO-PA,

BPC und BW/BI überflüssig. (Vgl. Tutorials Point (2017))

5.2 SAP Simple Finance Architektur

Ein einfacheres Datenmodell fördert eine deutliche Reduzierung des Data-Footprints und eine schnellere Verarbeitung der Prozesse. Dadurch ist keine Aggregierung der Daten wie bisher nötig. Ebenso entfällt durch die Vorhaltung einer zentralen Datenbasis, die Notwen- digkeit einzelne Datenelemente zu blockieren. Dadurch ergibt sich eine hohe Granularität über alle Prozesse hinweg. Als weiterer Vorteil ist die Konsolidierung der Daten (siehe Abb. 5.1) zu erwähnen, wodurch sich die sogenannte Single-Source-Of-Truth ergibt. Weiter gewinnen die Daten durch die Zusammenführung ein Genauigkeit, wodurch die Qualität des Reportings gesteigert wird (vgl. Deloitte (2016)).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 5.1: Datenmodell

Deloitte (2016)

Universal Journal

Das Universal Journal (siehe Abb. 5.2) verändert die Art, wie Bewegungsdaten in Simple Finance gespeichert werden. Diese Tabelle speichert alle Daten, die zuvor in den Tabellen für die Hauptbuchhaltung, Anlagenbuchhaltung, Controlling und Material-Ledger getrennt abgelegt wurden. Damit entfällt der Datenabgleich zwischen den einzelnen Tabellen der ehemals isolierten Anwendungen und Berichte können über die früheren Modulgrenzen generiert werden. Der große Vorteil dieser Konsolidierung ist die zentrale Datenhaltung über alle an einem Geschäftsprozess beteiligten Beziehungen, die bislang durch die separate Speicherung verloren gegangen sind. Die Geschäftsvorgänge bleiben allerdings unverändert, nur die Speicherung der Belege in einem Datensatz im Universal Journal macht den Unterschied. Für das Berichtswesen werden nun nicht mehr verschiedene Datenquellen herbeigezogen, sondern aus einer einzigen Tabelle namens ACDOCA, der Single Source of Truth, welche verschiedene Aggregationen desselben Datenbestandes anzeigt. Hier kommt auch der Vorteil der spaltenorientierten Speicherung (vgl. hierzu Kapitel 3) zum tragen.

Die Abfrage aus den einzelnen Tabellen ist dadurch wesentlich effizienter. (Vgl. Salmon und Wild (2016))

Abbildung in dieser Leseprobe nicht enthalten

Abb. 5.2: Universal Journal SAP (2015b)

New Asset Accounting

Voraussetzungen für neue Anlagenbuchhaltung nach Chirivella (2016) ist die Enterprise- Aktivierung EA-FIN für FI-AA (neu). In der neuen Anlagenbuchhaltung stehen neue Funktionen zur Verfügung. Die parallele Bewertung/ Rechnungslegung bedeutet eine deutliche Vereinfachung der parallelen Rechnungslegung innerhalb der Ledgerlösung der neuen Hauptbuchhaltung.

Während bisher in der Ledgerlösung das Führen von „Delta-Bewertungsbereichen“ notwen- dig war, entfällt dies nun mit der neuen Business Function FIN_AA_PARALLEL_VAL.

Darüber hinaus entfällt die Einschränkung auf Bewertungsbereich-spezifische Bewegungs- arten bei Einführung der neuen Anlagenbuchhaltung. Auch können Wirtschaftsgüter nach verschiedenen Rechnungslegungsvorschriften bewertet werden. Zum Beispiel muss nach IFRS ist ein Wirtschaftsgut als Anlage aktiviert und nach deutschem Handelsrecht (HGB) muss der entsprechende Betrag als Aufwand gebucht werden. (Vgl. SAP (2014b))

SAP hat sein Finanzmodul nicht neu programmiert, sondern ein Add-On über das Enhan- cement Package 7 (EHP 7) zur Verfügung gestellt, das die Datenbank SAP HANA für das ERP erfordert. Nach SAP (2017d) gab es folgende Versionen:

Simple Finance Add-on V1:

Simple Finance wurde zum ersten Mal als SAP Simple Finance Add-on 1.0 veröffent- licht. Diese Version enthielt einige der neuen Funktionalität für einfachere Administration der Finanzen, es enthielt noch nicht alle vereinfachten Tabellenstrukturen und Fiori- Anwendungen, die mit V2 gekommen sind.

Simple Finance Add-on 1503 / V2:

Zusammen mit der Veröffentlichung von Simple Finance 2.0 nutzte SAP die Gelegenheit, das Produkt umzubenennen, um mit der zukünftigen Cloud-Strategie übereinzustim- men. Simple Finance Add-on 2.0 wurde zu Simple Finance On-Premise Edition 1503.

[...]