Bewertung von MRP-Live in S/4HANA Enterprise Management

Inhaltsverzeichnis

1 Einleitung

2 Einführung in die Materialbedarfsplanung
2.1 Material Requirements Planning
2.2 Potential von MRP

3 Grundverständnis der In-Memory Technologie
3.1 Funktionsweise von In-Memory
3.2 Kompressionsverfahren

4 SAP HANA
4.1 SAP Business Suite powered by SAP HANA
4.2 S/4HANA Enterprise Management
4.3 SAP Fiori
4.4 Bereitstellungsoptionen
4.5 Migrationswege
4.6 Was SAP HANA verspricht

5 SAP Supply Chain
5.1 Datenhaltung unter SAP S/4 HANA im Bereich Logistik
5.2 Fiori Logistics Apps
5.3 User spezifische Varianten
5.4 Überwachen von Materialknappheit

6 MRP-Live

7 MRP-Live – Technische Voraussetzungen

8 MRP-Live - Customizing-Einstellungen
8.1 Customizing Einstellung
8.2 PP-Material Master
8.3 Simplification in PP-Material Master MRP Felder
8.4 Customizing für MRP Live Apps

9 MRP-Live – MRP-Cockpit
9.1 Grundeinstellungen
9.1.1 Einstellungen in den Überwachungs-/Monitor-Apps
9.1.2 Einstellungen in den Manage-Apps
9.2 Überblick über die Apps des MRP-Cockpits
9.3 Die wichtigsten Apps des MRP-Cockpits näher betrachtet
9.3.1 Materialdeckung ermitteln (engl. „Monitor Material Coverage“)
9.3.2 Materialdeckung prüfen (engl. „Manage Material Coverage“)
9.3.3 Ungedeckte interne Bedarfe ermitteln (engl. „Monitor Internal Requirements“)
9.3.4 Ungedeckte interne Bedarfe prüfen (engl. „Manage Internal Requirements“)
9.3.5 Ungedeckte externe Bedarfe ermitteln (engl. Monitor External Requirements)
9.3.6 Ungedeckte externe Bedarfe prüfen (engl. Manage External Requirements)
9.3.7 Ermitteln Produktionsaufträge (engl. Monitor Production Orders or Process Orders)
9.3.8 Prüfen Produktionsaufträgen (engl. Manage Production Orders or Process Orders)
9.3.9 MRP-Lauf einplanen (engl. „Schedule MRP Run“)
9.3.10 MRP-Kennzahlen anzeigen (engl. „Display MRP key figures“)

10 Der Tagesablauf eines Disponenten mit MRP-Live
10.1 Gesamtplanung mit S/4HANA in MRP-Live
10.2 Ermittlung der ungedeckten internen Bedarfe
10.3 Überwachen von Fertigungs- oder Prozessaufträgen

11 MRP ERP – Die Komponente PP-MRP
11.1 Funktionsumfang
11.1.1 Unterstützte Dispositionsverfahren in SAP PP-MRP
11.1.2 Unterstützte Losgrößenverfahren in SAP PP-MRP
11.2 Planungsablauf
11.2.1 MD01 Einstiegsbilds - Steuerungsparameter
11.3 MRP ERP – Ablauflogik in BPMN 2.0
11.4 MRP ERP Transaktionscodes

12 Veränderungen MRP ERP zu MRP-Live
12.1 Prozesstechnische Veränderungen:
12.2 Systemtechnische Veränderungen

13 Kritische Würdigung

14 Anhang
14.1 BPMN Diagramm Traditioneller MRP-Lauf
14.2 BPMN MRP-Live
14.3 User Story eines Disponenten visualisiert
14.4 FAQ
14.5 Quellen

1 Einleitung

SAP S/4 HANA – The Next Big Thing. So wirbt das Unternehmen SAP mit seinem neuen Produkt. Doch was kann SAP S/4 HANA wirklich leisten? Viele Unternehmen beschäftigt das Thema sehr. Durch aktuelle Themen, wie z.B. Big Data oder Echtzeit Daten, kommen herkömmliche Systeme, wie das SAP ERP-System, an Ihre grenzen. Dieses Semesterprojekt beschäftigt sich mit dem Produkt SAP S/4 HANA Enterprise Management. Da es sich bei S/4HANA um ein komplett neues Produkt handelt, ist zu erkennen, dass einzelne Funktionsbereiche verändert haben. So gibt es auch innerhalb des Logistikbereichs, von S/4HANA neue Innovationen durch den letzten Release der On-Premise Version 1610. Eine der Innovationen ist die beschleunigte Materialbedarfsplanung, welche unter dem Begriff MRP-Live in diese Arbeit eingeführt werden soll. Da die Materialbedarfsplanung im Bereich der Logistik einen kleinen und standardisierten Bereich der operativen Planung darstellt. Findet diese Form der Planung Anwendung in vielen verschiedenen produzierenden Unternehmungen. Daher stehen heutzutage viele Unternehmen im Rahmen der Einführung von S/4HANA vor der Fragestellung, von welchen Veränderungen sie betroffen sind und welches Potential sich für sie dahinter verbirgt. Um dies zu beantworten zielt diese Arbeit darauf ab, aufzuzeigen welche Veränderungen mit S/4HANA einhergehen. Dabei wird liegt der Fokus auf der Materialbedarfsplanung innerhalb des Bereichs der Logistik.

Dazu wird im Folgenden zunächst ein Überblick über die Materialbedarfsplanung gegeben. Darauf folgend werden die Grundlagen der In Memory Technologie eingeführt und anschließend das Produkt S/4HANA Enterprise Management. Weiter wird der Schwerpunkt MRP-Live bearbeitet. Hierbei erfolgt einen Vergleich gegenüber dem klassischen MRP-Lauf. Für ein besseres Verständnis des Leser wird die Ablauflogik von MRP-Live mithilfe von BPMN visualisiert und beschrieben. Abschließend erfolgt eine kritische Würdigung von S/4HANA mit Schwerpunkt auf MRP-Live.

2 Einführung in die Materialbedarfsplanung

Im Rahmen der Unterstützung von Produktionsplanung und Lagerhaltung wird ein Kontrollsystem verwendet, das System der Materialbedarfsplanung oder engl. Material Requirements Planning (MRP). MRP wurde Anfang der 1960er Jahre in USA als eine computerisierte Abbildung für die Planung von Materialbestellungen entwickelt. Es ist ein Steuerungssystem, das darauf abzielt einen ausreichenden Lagerbestand vorzuhalten und dabei sicherzustellen, dass die benötigen Materialien bei Bedarf zur Verfügung stehen. Weiter findet MRP Anwendung bei der Verwendung von unterschiedlichen Materiellen, welche sich in komplexen Stücklisten befinden (vgl. Kurbel, 2013, S. 19ff.).

2.1 Material Requirements Planning

Orlicky publizierte 1975 diese Technik in seinem Buch. Zwar wurde die Systematik der Materialbedarfsplanung bereits vor seiner Veröffentlichung durchgeführt worden. Allerdings bekundete Orlickly, dass mit Hilfe eines Computers eine umfangreiche Durchführung der Technik möglich wäre, mit der eine effektive Planung von Bestandsveränderungen möglich sei (vgl. Browne et al, 1988, S.89).

Gleichzeitig zählen zu den wichtigsten Zielen eines MRP-Systems:

- Die Sicherstellung der Verfügbarkeit von Materiellen, Halbfertigwaren und Fertigwaren für die geplante Produktion und die Lieferung an den Kunden,
- Das niedrigstmögliche Niveau des Lagerbestandes pflegen,
- Planung der Fertigungsaktivitäten, der Lieferpläne sowie der Einkaufsaktivitäten.

Weiter eignet sich MRP besonders gut dazu um Einstellungen in der Fertigung zu tätigen, wo sich die Nachfrage nach vielen verschiedenen Bestandteilen in Abhängigkeit von externen Anforderungen darstellt (vgl. Adam, 1998, S.597-606).

Der Ausgangspunkt der Materialbedarfsplanung ist die erwartete Nachfrage für das zu ausstehende finale Produkt. Weiter zielt ein MRP-System darauf ab, dass innerhalb eines mehrstufigen Produktionssystems, die Menge aller Güter zu bestimmen, welche aus unterschiedlichen oder gleichen Materiellen innerhalb eines Planungshorizonts zu produzieren sind, damit die Durchlaufterminierung für die zusammenpassenden Produktion und Beschaffung durchgeführt werden kann. Für die Entwicklung eines umfangreichen Produktion- und Beschaffungszeitplan, sind bestimmte statische und dynamische Informationen von essentieller Bedeutung. Zu den statischen Informationen zählen zum einen die Stückliste (engl. Bill of Material/BOM) und zum anderen die prognostizierte Auftragszeit für die Produktion oder die Bestellung von Materialien innerhalb der Stückliste. Dynamischen Daten beschreiben hingegen Daten, welche eine zeitorientierte Anforderung besitzen, bspw. bei zu erwartenden Aufträgen, welche noch nicht eingegangen sind aber den Lagerbestand beeinflussen werden (vgl. Heisig, 2002, S. 7).

Nach Wallace und Kremzar sucht MRP Antworten auf die folgenden Fragen:

- Was soll hergestellt werden?
- Wie setzt sich der Lagerbestand zusammen?
- Welches Material wird benötigt?
- Welches Material soll vorgehalten werden?

Diese Fragen werden als universale Fertigungsgleichung bezeichnet. Diese Logik findet Industrieübergreifend Anwendung. Durch MRP soll versucht werden diese universale Fertigungsgleichung aufzulösen.

Zu Beginn hatten MRP-Systeme nur die Funktion, die Berechnung für die Planung zu vereinfachen. Solche einfachen Systeme, welche ausschließlich simple Auftragsplanungen innerhalb der Hauptproduktionsprogrammplanung durchführten bildeten die Grundlage der heutigen MRP II- und ERP-Systeme.

2.2 Potential von MRP

Der Einsatz der Materialbedarfsplanung ist dann sinnvoll, wenn die Unternehmung ihren Materialfluss optimieren möchte. Dies gilt sowohl für interne Warenbewegungen als auch für die Fremdbeschaffung. Insbesondere ist empfohlen genau dann ein solches System dann einzusetzen, wenn kontinuierlich Probleme bei der Terminierung der Lieferungen auftreten.

Die Materialbedarfsplanung innerhalb von SAP bietet der Unternehmung eine Reihe an Vorteilen. Einige der wichtigsten Vorteile ist die Unterstützung bei der Reduzierung von Lagerbeständen und die damit verbundenen Transportkosten. Ferner können die effizientesten Losgrößen Sicherheitsbestände bestimmt werden. Ebenso ist sind die durch das System erzeugten Informationen für andere Unternehmensbereiche nützlich. Allerdings haben auch MRP-Systeme auch einige Nachteile. MRP-Systeme basieren auf exakt eingegebenen Informationen. Probleme können allerdings aufgrund von falsch eingegeben Informationen auftreten. So könnten falsche Bestellmengen verspätete Lieferungen auftreten. Somit ist es unerlässlich Mitarbeiter entsprechend zu schulen. Daher ist Akzeptanz der Mitarbeiter im Rahmen der Materialbedarfsplanung von großer Bedeutung. Es ist wichtig, dass die Geschäftsprozesse mit dem System abgestimmt werden und Schlüsselpersonen frühzeitig identifiziert werden, um Hemmungen bei diesen Personen abzubauen.

Die bereitgestellten Methoden können als Ergänzung zu bestehenden Beschaffungskonzepten eingesetzt werden.

3 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).

3.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).

3.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).

4 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.

4.1 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.)

4.2 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

Überblick S/4HANA (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

Bereitstellungsoptionen S/4HANA

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

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).

4.3 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.

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.

4.4 Bereitstellungsoptionen

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. In diesem Fall wäre die SAP-S/4HANA-On-Premise-Edition die zu empfehlende Lösung. In anderen Geschäftsfeldern, in denen eine Differenzierung unwesentlich ist, aber eine hohe Standardisierung erforderlich ist, wäre es ideal für Kunden, die branchenweit besten Praktiken der SAP zu übernehmen. Dies wäre durch die SAP S/4HANA, Cloud Edition möglich, da diese Lösung von Anfang an Best Practices zur Verfügung stellt und die TCO reduziert (vgl. Wagner/Mathäß 2016, S.3).

Für Cloud-Lösungen ist üblicherweise eine Subskription nötig, dies kann als eine Art Abonnement verstanden werden. In der Subskription sind Kostenelemente wie das Applikationsmanagement, die Infrastruktur und die Nutzung der Software enthalten. Weiter können SAP-Kunden auch ihre On-Premise-Lizenzen nutzen, um S/4HANA einzusetzen. Daneben muss die SAP HANA-Datenbank wie jede andere Datenbank auch lizensiert werden (vgl. SAP 2015d).

SAP S/4HANA, On-Premise edition

Mit der SAP S/4HANA, On-Premise Edition wird das System lokal bei dem Kunden vor Ort installiert. Im Hinblick auf Funktionen, Branchen und Sprachen bietet die On-Premise-Edition von S/4HANA bereits eine ebenso umfangreiche Abdeckung wie bspw. Die SAP R/3 Business Suite. Innerhalb dieses Lösungsumfangs bietet S/4HANA zukunftsweisende Vereinfachungen, etwa durch das bereits verfügbare Lösungspaket Simple Finance (mit SAP Accounting powered by SAP HANA), sowie einer geplanten Anbindung an SuccessFactors Employee Central und an das Ariba-Netzwerk. Die On-Premise-Edition soll jährliche Innovationszyklen bieten, in denen Innovationspakete (Innovation Packages) ausgeliefert werden. Das nächste Innovationspaket ist Ende 2015 geplant (vgl. Wagner/Mathäß 2016, S.4).

SAP S/4HANA, cloud edition

SAP S/4HANA, Cloud-Edition, ist als Software as a Service erhältlich (vgl. SAP 2016e). Die Cloud-Edition von SAP S/4HANA deckt bereits bestimmte Geschäftsszenarien im Marketing und in der Dienstleistungsbranche (Professional Services) ab und unterstützt darüber hinaus auch die grundlegenden Szenarien für eine cloudbasierte, digitale Steuerung von Geschäftsprozessen wie Finanz- und Rechnungswesen, Controlling, Beschaffung, Vertrieb, Fertigung, Instandhaltung, Projektsystem und Management des Produktlebenszyklus sowie Ariba-Netzwerk, SAP hybris Marketing, Field Glass. Derzeit sind drei Angebote als Teil der Cloud-Edition von SAP S/4HANA verfügbar: (vgl. Wagner/Mathäß 2016, S.4):

Die Marketing-Version von SAP S/4HANA – für den Geschäftsbereich Marketing

Die Cloud-Project-Services-Version von SAP S/4HANA – für die Dienstleistungsbranche

Die Cloud-Enterprise-Version von SAP S/4HANA – für den kompletten ERP-Umfang

Die Cloud-Edition soll vierteljährliche Innovationszyklen bieten (vgl. SAP 2016f).

4.5 Migrationswege

Ein Wechsel auf S/4HANA ist kein Einzelprojekt wie ein Upgrade oder eine Datenbankmigration, dieser Wechsel bezieht vielmehr die gesamte IT-Systemlandschaft mit in diesen Prozess ein. Daher empfiehlt es sich die Transformation immer von der gewünschten zukünftigen SAP-Ziel-Architektur aus zu betrachten. So macht diese Herangehensweise es für Anwender zumeist einfacher: Insbesondere wenn die Umstellung auf S/4HANA ganzheitlich vollzogen wird, bietet dies im Vergleich zu einer reinen Migration auf SAP HANA die Chance, oftmals komplexe und heterogene IT-Landschaften zu eliminieren und somit die Grundlage für einfachere, schlankere Prozesse zu bieten (vgl. SAP 2016g).

So werden im Rahmen der Umstellung auf S/4HANA drei Wege genannt, die veranschaulichen sollen, was hiermit möglich ist und wie der gewünscht Soll-Zustand erreicht werden kann. Dazu werden im Folgenden drei Umstellungsmöglichkeiten auf S/4HANA beschrieben.

Neuinstallation

Dieses Scenario zielt auf Neukunden ab oder auch auf Bestandskunden, welche von vorne beginnen wollen. Dabei starten sie mit einer Neuinstallation von S/4HANA und migrieren ihre Stamm- und Transaktionsdaten mittels der integrierten Datenmanagement‑ und Datenqualitäts‑Tools (vgl. SAP 2016f). Bei diesem Weg wird das S/4HANA-System implementiert, und die Stamm- und Transaktionsdaten werden aus dem Legacy-System migriert. Abhängig von der ausgewählten S/4HANA-Edition und den detaillierten Kundenanforderungen wird die SAP-Landschaftstransformation (SAP SLT) oder die SAP Data Services-Technologie für die erforderliche Datenmigration verwendet (vgl. Wagner/Mathäß 2016 S.10).

System Konvertierung

Dieses Szenario konzentriert sich auf bereits bestehende SAP Business Suite-Kunden, die ihr aktuelles System auf S/4HANA umstellen wollen (vgl. Wagner / Mathäß 2016 S.8). Technisch gesehen findet die System Konvertierung zu SAP S/4HANA hinsichtlich Customizing, Entwicklung, Daten, Berechtigungen und Schnittstellen unter Beibehaltung der System ID statt. Es besteht die Möglichkeit bei ERP 6.0 EhP0, ohne Upgrade auf ein höheres Enhancement Pack (EhP) direkt auf SAP S/4HANA zu wechseln. Zudem wird vorausgesetzt, dass das System bereits ein Unicode System ist. Grund hierfür ist der SAP NetWeaver 7.50, welcher ausschließlich Unicode Systeme unterstützt. Ist dies nicht der Fall muss vor der System-Konvertierung auf S/4HANA eine vorgelagerte Unicode-Konvertierung durchgeführt werden (vgl. SAP 2016h). Diese Voraussetzung ist auch im Rahmen der Transformation der Systemlandschaft zu beachten.

Transformation der Systemlandschaft

Dieses Szenario konzentriert sich auf bereits bestehende SAP Business Suite-Kunden, die ihre aktuellen Systeme- oder Systemlandschaft in ein S/4HANA-System (oder Systemlandschaft) transformieren möchten. Dieses Szenario umfasst komplexere Migrationsszenarien (vgl. SAP 2016f). Dies ist in der Regel eher ein Migrationsprojekt als eine technische Umstellung, mit dem Ziel die neue Softwarearchitektur einzuführen. So beinhaltet dieser Weg in der Regel ein Migrationsprojekt mit den Anforderungen der Zusammenführung von mehreren Systeme zu einem globalen System oder mit der Migration selektiver Teile eines Systems (z. B. Unternehmensbereich, Organisationseinheiten in ein gemeinsames Zielsystem (vgl. Wagner/Mathäß 2016, S.8 f.))

Szenarien für Migration auf S/4HANA

Wie auch schon bei der Business Suite stehen Unternehmen die drei genannten Varianten für einen Wechsel auf SAP S/4HANA offen. Bei der Bewertung, welcher Weg der richtige ist, ist die bereits erwähnte Ziel-Architektur von hoher Relevanz. So kann eine Umstellung auf S/4HANA bspw. direkt geschehen. Hier wird von einer sog. Ein-Schritt-Migration gesprochen. Alternativ dazu besteht auch die Möglichkeit die bestehende SAP Business Suite auf die HANA Datenbank zu heben und zu betreiben. Im nächsten Schritt wird dann von der Business Suite auf HANA zu S/4HANA umgestellt. Dabei spricht macht von der sog. Zwei-Schritt-Migration.

Für SAP-Kunden, die bereits mit SAP ERP 6.0 (ab EhP 0) arbeiten, ist ein direkter Wechsel auf SAP S/4HANA mit einer System-Konvertierung möglich. Um den richtigen Weg hin zu S/4HANA zu erleichtern wird von der SAP folgende Entscheidungsmatrix angeboten, dass die Entscheidung erleichtern soll, wie auf S/4HANA umzustellen ist (vgl. SAP 2016h).

4.6 Was SAP HANA verspricht

Doch was genau sind die Vorteile von S/4HANA Enterprise Management? Im Rahmen von SAP HANA wird von der SAP eine Reihe an Vorteilen genannt. Diese Vorteile werden innerhalb des folgenden Abschnitts zusammengefasst dargestellt. Dazu wurden die analysierten Verbesserungspotentiale in drei Kategorien klassifiziert. Somit soll es dem Leser ermöglicht werden zu verstehen, was SAP HANA in den Bereichen der funktionalen Verbesserung, schnellerer Geschäftsprozesse und Kosteneinsparung verspricht.

Funktionale Verbesserungen

Als ein signifikanter Vorteil wird die Funktionalität in S/4HANA beschrieben, wodurch aktuelle Informationen aus Finanzwesen, Controlling und Non-SAP-Systemen in Echtzeit zur Verfügung gestellt werden können. Weiter werden die Simulation neuer Geschäftsmodelle sowie die veränderten Prozesse aus Finanzsicht genannt, welche dem Kunden eine bessere Planung ermöglichen sollen. Die Materialbedarfsplanung in Echtzeit wird ebenfalls als großer Vorteil beschrieben. So soll dies laut SAP zu einer abteilungsübergreifenden Transparenz und generellen Optimierung des Prozesses an sich führen. Daneben werden noch eine verbesserte Liefertreue durch die Verbesserung der Transparenz entlang der Lieferkette sowie eine Losgröße von Eins aufgrund von kundenindividuell gefertigten Produkten, die nur einmal hergestellt werden, genannt. Weiter beschreibt SAP, dass Kunden durch die Echtzeit-Verarbeitung mit SAP HANA, z.B. eine optimierte Transparenz bzgl. Bestand und Materialfluss und eine bessere Reaktionsfähigkeit bei Fertigungsaufträgen im Rahmen des Prozessablaufs, erzielen können. Ebenso besteht nun die Möglichkeit bei operativen Entscheidungen durch einfachere Simulation von Lieferalternativen unterstützt zu werden (vgl. SAP 2015c).

Schnellere Geschäftsprozesse

Hierbei handelt es sich um veröffentlichte SAP Lab-Ergebnisse, welche 2013 auf der ASUG Konferenz in den USA vorgestellt wurden (vgl. ASUG 2013). In diesem Testscenario wurden zwei Systeme verwendet und miteinander verglichen. Dabei handelt es sich zum einen um das System: SAP R/3 Business Suite auf einer HANA-Datenbank und zum anderen um SAP R/3 Business Suite auf AnyDB. Die Ergebnisse können wie folgt klassifiziert werden.

Mit der Verfügbarkeit von S/4HANA Manufacturing, Supply Chain, Sourcing und Procurement im Oktober 2016 sollen nach SAP-Angaben weitere Möglichkeiten hinzukommen (vgl. ASUG 2016).

Potentielle TCO-Einsparungen auf Basis des FORRESTER-Reports für die Anwendungen von SAP BW und SAP ERP sowie eigens entwickelte Anwendungen

Die SAP HANA-Plattform verändert die Kostenbetrachtung durch Vereinfachung und Unterstützung von verschiedenen Anwendungsfällen. So wird im Forrester-Report (2014) von folgendem Einsparpotential gesprochen: Einsparungen von 70%+ an Softwarekosten aufgrund des Wegfalls von ETL und Middleware. Weiter wird ein Einsparpotential von 15%+ an Hardwarekosten erwähnt. Als Grund hierfür wird die reduzierte Anzahl an Servern genannt, welche benötigt werden. Ebenfalls ist die reduzierte Speichermenge aufgrund von IMDM ein weiterer Treiber für die Kostensenkung. Zusätzlich dazu wird von einem Einsparpotential von 20%+ in dem Bereich Betrieb und Entwicklung gesprochen. Dies sei auf eine reduzierte Zeit für die Administration der Datenbanken und der Server zurückzuführen (vgl. Zeier 2015).

Kostenreduzierung

Basierend auf dem zusammengesetzten Gesamtkostenmodell profitierte die Beispielorganisation von folgenden Vorteilen (dies stellt eine Zusammenfassung der befragten Unternehmen dar) (vgl. Forrester 2014):

Reduzierung der Hardwarekosten durch vereinfachten Data-Footprint, weniger komplexe System-Landschaften und einfachere Einrichtung des Systems. Durch die Umstellung auf die SAP-HANA-Plattform können die Kunden aufgrund der Datenkompression das benötigte Server- und Storagevolumen senken sowie durch die Funktionalität der SAP HANA-Software Effizienzgewinne erzielen.

Niedrigere Softwarekosten durch vereinfachten Data-Footprint, weniger komplexe System-Landschaften und einfachere Einrichtung des Systems . Die SAP HANA-Plattform ermöglicht ebenfalls eine Reduzierung und Eliminierung von vielen Softwareprodukten wie bspw. ETL, Datenreplikation, Management und andere Middleware-Software. Darüber hinaus verfügt die SAP HANA-Plattform über erweiterte Analysemöglichkeiten wie Text-, Geo- und Prognosemethoden als Teil ihres Plattform-Angebots, welche ohne zusätzliche Lizenz bereitgestellt werden.

Schnellere Entwicklungszeit durch einfachere Anwendungsentwicklungen sowie der vereinfachten User Experience. Alle Befragten gaben einen schnelleren, effizienteren Anwendungsentwicklungsprozess aufgrund der Automatisierung und Minimierung der Komplexität an, was für sie wiederum eine Verringerung der Betriebszeit ermöglichte.

Erhöhte Produktivität für Administratoren aufgrund einer einfacheren Administration und Betrieb. Durch die Vereinfachung der Umgebung durch die SAP HANA-Plattform können Kunden den Aufwand für die Verwaltung von Datenbanken und Servern sowie die damit verbundene erforderliche Verwaltungszeit reduzieren.

Abschließend soll ein dieser Stelle angemerkt sein, dass die meisten genannten Verbesserungen selbst durch die SAP genannte Verbesserungen handelt. Daher ist dem Leser zu empfehlen diese erwähnten SAP-Benchmarks durchaus kritisch zu hinterfragen. Dass S/4HANA großes Potential hat ist offensichtlich. Dennoch wird es empfohlen jede Problemstellung individuell zu analysieren und anschließend zu bewerten, in welchen Bereichen das meiste Verbesserungspotential für die jeweilige Organisation liegt.

5 SAP Supply Chain

In SAP S/4HANA sind mittlerweile die Finanz- und Logistikprozesse integriert und miteinander verzahnt nutzbar. Welche Vorteile haben Anwender, wenn sie S/4HANA und seine Echtzeitmöglichkeiten nutzen wollen? Welche Praxisbeispiele gibt es für Supply Chain, Logistik und Planung? Hierzu soll im Folgenden soll eine sachlogische Abgrenzung hin zu MRP-Live erfolgen. Grundsätzlich ist MRP-Live innerhalb von S/4HANA Enterprise Management 1610 in dem Bereich von SAP S/4HANA Supply Chain einzuordnen.

Materialbedarfsplanung: Die Materialbedarfsplanung kann Disponenten helfen, die Balance zwischen Teileverfügbarkeit und Kapitalbindung im Lager zu erreichen. Hilfsmittel sind die Signalisierung kritischer Bestände, Simulationen, grafische SAP Fiori Darstellungen und systemseitige Vorschläge.

Zu SAP S/4HANA Supply Chain, dem logistischen S/4HANA Kern, gehören die Produktionsplanung, die Bestandsführung, das Warehouse-Management und optional die Produktions- und Feinplanung (PP/DS) und die neu programmierte Verfügbarkeitsprüfung (Advanced Available to Promise).

Die Anlage von Kundenaufträgen erfolgt im Modul SAP S/4HANA Sales, während alle Beschaffungsprozesse im Modul SAP S/4HANA Sourcing and Procurement implementiert sind.

Lines of Business mit Fokus auf Supply Chain

Technische Vorteile: SAP S/4HANA Supply Chain

Bekanntermaßen ist das Datenmodell von SAP S/4HANA neu, wodurch auch im Logistikmodul der „digitale Fußabdruck“, also der Speicherbedarf in der Datenbank, nach Angaben von SAP auf weniger als ein Zehntel reduziert werden kann. Das wird möglich, weil man auf Aggregate und Indizes verzichten und diese bei Bedarf zur Echtzeit schnell erzeugen kann.

Mit SAP S/4HANA sind zudem parallele Buchungen möglich. Bisher musste man auf den Abschluss der vorhergehenden Buchung warten, da SAP und andere IT-Systeme für diesen kurzen Zeitraum der Transaktion gesperrt waren. Mit S/4HANA soll sich in den Finanz- und Logistikprozessen ein vergleichbarer Durchsatz mit kürzeren Durchlaufzeiten und bei geringerem Speicherbedarf realisieren lassen.

5.1 Datenhaltung unter SAP S/4 HANA im Bereich Logistik

Die neue Datenhaltung unter SAP S/4 HANA ist eine große Veränderung im Vergleich zum SAP R/3 System. Im Folgenden wird genau aufgezeigt, was sich im Bereich SAP S/4 HANA Enterprise Management genau verändert hat.

Abbildung in dieser Leseprobe nicht enthalten

Verändertes Datenmodell

Wie in Abbildung 1 zu sehen ist sind die Tabellen unter SAP S/4 HANA neu strukturiert worden.

In SAP S/4 HANA sind keine Aggregate mehr enthalten, d.h. dass keine Verbindungen von Elementen mehr vorhanden sind. Durch das vereinfachte Datenmodell enthält das System nur Transaktionen. Wenn Summen benötigt werden, wie z.B. Inventur Ebene, werden diese in Echtzeit berechnet und on-fly bereitgestellt.

Ein Beispiel für die Änderung des Datenmodells, wäre die unter SAP R/3 vorhandene Tabelle MARA. Unter SAP R/3 enthält die Tabelle MARA Aggregate für Bestände. Unter SAP S/4 HANA existiert diese Tabelle nicht mehr. Sollen jetzt die Bestände unter SAP S/4 HANA angezeigt werden, so wird nur die MSEG NEW sowie die Master Data dazu benötigt und die Aggregate werden berechnet und ausgegeben. Dies ist nur ein Beispiel, so sind unter SAP S/4 HANA noch viele weitere Aggregate und Indizes verschwunden. Unter SAP S/4 HANA sind alle benötigten Transaktionen in der Tabelle MSEG New vorhanden und Aggregate werden bei Bedarf erzeugt.

Durch das neue vereinfachte Datenmodel liegen keine Daten mehr redundant ab. Hierdurch wird eine geringere Menge an Daten, als auch an Speicherplatz benötigt. Ein weiterer großer Vorteil liegt in der einfacheren Logik in der Datenbank, sowie das Schreiben und Lesen der Daten.

5.2 Fiori Logistics Apps

Aktuell werden in der SAP App Libary 21 Fiori Apps für PP-FIO-MRP auf S/4HANA 1610 FPS01 zur Verfügung gestellt (Stand: 18.04.2017)

Korrespondierende Fiori-Apps

Abbildung in dieser Leseprobe nicht enthalten

Tab.1: Fiori Apps mit Fokus auf MRP-Live

5.3 User spezifische Varianten

SAP stellt verschiedene User Varianten zur Verfügung.

Benutzerspezifische Varianten können je nach Bedarf angelegt werden. Diese Varianten können auf der Homepage als Fliesen angezeigt werden.t

Abbildung in dieser Leseprobe nicht enthalten

Darstellung von SAP Fiori

5.4 Überwachen von Materialknappheit

Überwachen Sie Materialknappheit in einem ausgewählten Verantwortungsbereich.

Personalisierte Varianten können mit ausgewählten Mangelmaterialien, Zeithorizonten und Filtern erstellt werden.

Abbildung in dieser Leseprobe nicht enthalten

Überwachen von Materialknappheit

6 MRP-Live

Heute müssen Produktionsplaner sicherstellen, dass ein Material verfügbar ist, sobald dies benötigt wird. Die Materialbedarfsplanung (MRP) ist Produktionsplanern bei dieser Aufgabe behilflich. Der Materialbedarfsplanungslauf in SAP ermittelt erwartete Unterdeckungen und erstellt Planaufträge, Bestellanforderungen oder Lieferplaneinteilungen, um die erwarteten Unterdeckungen abzudecken. Für ein Material liegt eine Unterdeckung vor, wenn das Material der bedarfsgesteuerten Planung unterliegt und die Gesamtmenge der Materialbedarfe (Kundenaufträge, Umlagerungsbedarfe, Produktionsbedarfe und Prognosebedarfe) bis zu einem bestimmten Zeitpunkt die Gesamtmenge der Materialzugänge (Bestand, Fertigungsaufträge, Bestellungen, Lieferplaneinteilungen, fixierte Planaufträge und fixierte Bestellanforderungen) übersteigt.

SAP S/4HANA stellt MRP Live bereit, dies ist ein für SAP HANA optimierter Materialbedarfsplanungslauf. MRP Live liest Materialzugänge und -bedarfe, berechnet Unterdeckungen und erstellt Planaufträge und Bestellanforderungen in einer Datenbankprozedur. Das hat den Vorteil, dass sich dadurch die Datenmenge verringert, die vom Datenbankserver auf den Anwendungsserver und wieder zurück kopiert werden muss, wodurch wiederum die Performance beträchtlich verbessert wird. MRP Live bietet einige zusätzliche Vorteile, z.B. folgende:

- Die Definition des Planungsumfangs gestaltet sich flexibler. MRP Live ermöglicht Ihnen Folgendes: die Planung einer Gruppe von Materialien mit allen Komponenten; die Planung von Materialien, für die ein bestimmter Produktionsplaner verantwortlich ist, oder die werksübergreifende Planung eines einzelnen Materials.
- Wenn ein Material von einem Werk in ein anderes übertragen wird, ist der Umlagerungsbedarf im Entnahmewerk erst nach der Planung im Empfangswerk bekannt. MRP Live ermittelt die Reihenfolge, in der die Materialien über mehrere Werke geplant werden müssen.
- MRP Live bildet eine Voraussetzung für die zukünftige Produktionsplanungs- und Feinterminierungs-PP/DS-Lösung in SAP S/4HANA

Die klassische MRP steht weiterhin als Übergangslösung zur Verfügung, welche derzeit zum Anlegen von Dispositionslisten verwendet werden muss.

Geschäftsprozess-bezogene Informationen

MRP Live unterscheidet sich in den folgenden Aspekten von der klassischen MRP:

- MRP Live schreibt keine Dispositionslisten.
- Die mehrstufige Kundeneinzelplanung (Transaktion MD50) ist nicht für SAP HANA optimiert.
- Die Projekteinzelplanung (Transaktion MD51) ist nicht für SAP HANA optimiert.
- Das Erstellungskennzeichen für Bestellanforderungen ist in MRP Live nicht verfügbar. MRP Live legt immer dann Bestellanforderungen an, wenn das Material fremdbeschafft wird.
- Das Erstellungskennzeichen für Lieferplaneinteilungen ist in MRP Live nicht verfügbar. MRP Live legt immer dann Lieferplaneinteilungen an, wenn ein gültiger Lieferplan vorhanden ist.

Dispositionslisten

Dispositionslisten waren zur Prüfung des Materialbedarfsplanungsergebnisses vorgesehen. Dispositionslisten wurden zum schnellen Auffinden problematischer Materialen verwendet. Bei Dispositionslisten handelt es sich um Snapshots der Materialbereitstellungs- und -bedarfssituation zum Zeitpunkt des letzten Materialbedarfsplanungslaufs. Der Snapshot ist oft veraltet. Mit SAP HANA können Bedarfs-/Bestandslisten mit sehr hoher Geschwindigkeit gelesen werden. Die MRP-Apps ermitteln problematische Materialien in Echtzeit. In SAP S/4HANA besteht keine Notwendigkeit für veraltete Dispositionslisten.

Planung einzelner Kundeneinzelfertigungsaufträge und -projekte

Bei der mehrstufigen Kundeneinzelplanung handelte es sich lediglich um eine Performancemaßnahme. Anstatt aller Planungsabschnitte plante das System nur ein ausgewählter Planungsabschnitt. Dank der Geschwindigkeit von SAP HANA ist die Unterstützung dieser Performancemaßnahme nun nicht mehr erforderlich. Dies sorgt außerdem für eine Vereinfachung des Materialbedarfsplanungslaufs.

7 MRP-Live – Technische Voraussetzungen

MRP live läuft nur unter ECC 6.0 mit EHP7/Support pack 01 oder auf SAP HANA ECC 6.0 mit EHP6.

Zu aktivierende Business Function: LOG_PPH_MDPSX_READ

Technischer Gebrauch: SAP APPL 616 und SAP APPL 617

MRP live erfordert exklusive Nummernkreise für folgende Objekte. Diese Nummernkreise sind nicht für andere Objekte zu verwenden.

- Purchase Requisitions(BANF)
- Planned Orders(PLAF)
- Material reservation/dependent requirements(RESB)
- Planungseinträge sind in der Tabelle MDVM verfügbar, existieren aber nicht in DBVM. Die OM0F-Transaktion ist auszuführen, um Planungseinträge in die Tabelle DBVM zu migrieren.

Es muss sichergestellt werden, dass keine Summenbedarfe im System vorhanden sind. Es kann auf folgende Weise überprüft werden ob Summenbedarfe im System vorhanden sind.

Transaktion SE16 à Tabelle VBBS

Wenn in dieser Tabelle keine Einträge vorhanden sind, gibt es keine Summenbedarfe im System. Andernfalls müssen diese bereinigt werden.

BAdIs werden nicht mehr unterstützt. Bei Materialien mit BAdIs muss das System gezwungen werden, den klassischen MRP Lauf zu verwenden. Dies kann über die Transaktion MD_MRP_FORCE_CLASSIC vorgenommen werden.

8 MRP-Live - Customizing-Einstellungen

Im Folgenden werden die wichtigsten Customizing Schritte aufgezeigt um MRP Live on HANA verwenden zu können. Zunächst muss die Materialbedarfsplanung im Materialstamm gesetzt werden. Durch dieses Kennzeichen im Materialstamm, wird gesteuert welche Bedarfsplanung durchgeführt wird.

8.1 Customizing Einstellung

Transaktion MD01N pflegen

Die Transaktion MD01N muss in der Tabelle PPH_HANA_ACTIVE aktiviert und gepflegt werden. Dadurch kann die HANA Datenbank verwendet werden. Zudem muss im Benutzerprofil der Benutzerparameter HANA_ACCESS = 02 gepflegt sein, dies erfolgt über die Transaktion SU03.

MRP Area definieren

Die MRP Area wird unter folgendem Pfad definiert:

Production à Material Requirements Planing à Master Data à MRP Areas à Define MRP Areas

In der unteren Abbildung ist die Transaktion zu sehen, mit den schon definierten MRP Areas.

Abbildung in dieser Leseprobe nicht enthalten

MRP Area definieren

MRP-Areas I

Für jeden Subcontractor muss in der SPRO eine MRP Area hinterlegt sein. Dies ist in der unteren Abbildung zu sehen.

Abbildung in dieser Leseprobe nicht enthalten

Subcontractor – MRP Area

MRP-Areas II

Planung auf Lager Ebene

SAP S/4HANA MRP plant nur auf Plan- und Dispositionsbereichsebene. Planung auf Lager-Ebene ist nicht verfügbar in SAP S / 4HANA. Um die Lager Ebene von der Planung auszuschließen muss das Kennzeichen ND im Dispobereich des Materials gesetzt werden (Transaktion MM03). Um Lager Ebenen separat zu planen muss das Kennzeichen VB verwendet werden.

MRP aktivieren und Planungsdatei einrichten

Anderst als unter SAP ERP sind unter SAP HANA alle Anlagen für einen MRP Lauf standardmäßig relevant und aktiv. Technisch betrachtet heißt das folgendes:

T001 W-BEDPL = X

In der Tabelle T001 ist im Feld W-BEDPL automatisch das Zeichen gesetzt. Diese Flags können aber in der Transaktion OMDU manuell eingestellt werden.

Die Planungsdatei kann unter folgenden Pfad definiert werden.

Abbildung in dieser Leseprobe nicht enthalten

Pfad Planungsdatei definieren

8.2 PP-Material Master

Material Master ist ein zentrales Business-Objekt, auf das alle Business-Funktionen zugreifen können.

Das Material Master verwendete, eine 18-stellige Zeichenfeldläng, welche die Anforderung aus dem Business einschränkte.

Ab SAP S/4HANA 1511 wird eine Materialnummer mit 40 Zeichen unterstützt. Die entsprechenden verwandten SAP-Entwicklungsentitäten (Domänen, Strukturen, Tabellentypen und transparenten Tabellen, externe und interne Schnittstellen, Benutzeroberflächen usw.) wurden entsprechend angepasst.

[...]