Zuviel der Cloud? SAP TechEd 2018

Letzte Woche war es also soweit, die SAP TechEd 2018 in Barcelona hat stattgefunden. Gemeinsam mit Ali, Christian, Peter und Stephan bin ich am Montag nach Barcelona gereist, um mich auf den neuesten Stand des SAP-Portfolios zu bringen. Neben den Lectures waren es sicherlich die Hands-on Sessions, die uns einen guten Eindruck darüber vermitteln sollten, wie die SAP-Produkte technisch funktionieren und wie wir diese zum Vorteil unserer Kunden einsetzen können.

Am Montag, 22.10.2018 flogen wir also von Frankfurt nach Barcelona. Am Spätnachmittag in Barcelona angekommen, konnten wir bequem am Flughafen bereits zur SAP TechEd 2018 einchecken sowie unsere Badges entgegennehmen und von dort mit dem Taxi ins Hotel. Den ersten Abend nutzten wir ausgiebig, um die Stadt zu erkunden und uns bei leckeren Pinchos auszutauschen, welche Sessions wir uns vorgenommen haben.

Tag 1 – Keynote

Am Dienstag um 9.00 Uhr morgens begann die SAP TechEd 2018 in Barcelona mit der SAP Exceutive Keynote „The Opportunity of a Lifetime“, gehalten von Björn Goerke, Chief Technology Officer (CTO) und President SAP Cloud Platform. Björn Goerke stellte in der Keynote, wie bereits bei der letzten SAPPHIRE NOW, die Vision der SAP vom intelligenten Unternehmen vor. Das intelligente Unternehmen besteht aus drei Kernkomponenten: die Intelligent Suite, die Digital Platform und Intelligent Technologies.

SAPs Vision vom intelligenten Unternehmen (Quelle: SAP SE)

Björn Goerke ging daraufhin in einer schön verpackten Show – gespickt mit einigen technischen Highlights – auf die Bestandteile des intelligenten Unternehmens ein. Die Keynote gab uns also einen Vorgeschmack auf das was uns in den kommenden Tagen erwarten würde.

SAP vollzieht den Wandel zur Cloud Company und auch vertrieblich ist es seitens unserer Kunden immer wieder zu hören, dass der SAP Vertrieb nur noch Cloud, Cloud und nochmals Cloud kennt. Aus diesem Grund war es nicht verwunderlich, dass auch der Inhalt der SAP TechEd einen sehr starken Fokus auf die SAP Cloud Plattform hatte. Wir bei FIVE1 folgen jedoch nicht blind der Vision von SAP und empfehlen unseren Kunden nur das, was unserer Meinung nach das Beste für sie ist. Aus diesem Grund war es unsere Pflicht in den kommenden Tagen die vorgestellten Lösungen kritisch zu hinterfragen: Macht das für unsere Kunden Sinn? Ist das Produkt schon so ausgereift, dass wir es unseren Kunden empfehlen können? Welchen Use Case sehen wir für unsere Kunden? Und wie würde sich dieser Use Case rechnen? Wie lässt sich das in die Kunden Systemlandschaft integrieren? Und uns ist natürlich auch klar, dass die Vorträge, Demos und die Übungen in den Hands-on einerseits einfache Beispiele darstellen und nicht unbedingt den Kundenanforderungen aus der realen Welt entsprechen und andererseits auch gut vorbereitet sind, so dass technisch alles einwandfrei funktioniert. Bei all den kritischen Fragen sehen wir auch immer die Möglichkeiten und Chancen für unsere Kunden, die sich durch die neuen Technologien ergeben – getreu dem Titel der Keynote – The Opportunity of a Lifetime. Die Aufzeichnung der kompletten Keynote kann man sich auf Youtube anschauen.

Tag 1 – ABAP in der Cloud

Nach der Keynote nutzte ich zunächst die Zeit bis zu meinem ersten Vortrag zum Networken. Wie auch in den kommenden Tagen gab es ausreichend Zeit um sich mit SAP-Mitarbeitern, Kunden, ehemaligen Kollegen und SAP-Partnern über aktuelle SAP-Themen auf der SAP TechEd auszutauschen.
Nachdem im letzten Jahr ABAP in der Cloud angekündigt wurde, ist dies seit September 2018 allgemein verfügbar. Bedingt durch meine SAP BW Historie, programmiere ich seit Jahren u.a. auch ABAP, so dass meine erste Session die Lecture „Product Overview of SAP Cloud Plattform, ABAP Environment“ war. Nachdem die SAP sich eigentlich jahrelang gegen ABAP in der Cloud sperrte und ABAP immer wieder für Tod erklärt wurde, hat es ABAP nun doch in die Cloud geschafft. SAP begründete dies mit der Anzahl an SAP-Kunden und Partnern mit ABAP Know-How einerseits als auch die Anzahl an ABAP-Installationen sowie den bewährten Einsatz im Unternehmensbereich und zuletzt die Transition von ABAP in die Cloud durch SAP S/4 HANA in der Cloud. Die ABAP Plattform wird als Service in der SAP Cloud Plattform bereitgestellt. Dabei wurde ABAP für die Cloud optimiert, d.h. es ist bspw. nicht möglich mit OPEN DATASET auf das lokale Dateisystem zu zugreifen, wird dies trotzdem versucht, wird ein Syntaxfehler ausgeben und der Code kann nicht aktiviert werden. Des Weiteren können nur offiziell freigegeben APIs verwendet werden, d.h. man kann nicht wie in einem On-Premise ABAP System einfach einen beliebigen Funktionsbaustein wieder verwenden, der nicht von der SAP freigegeben wurde und es dann ggf. nach einem Upgrade zu Problemen kommt – dies wäre in einer Cloud Umgebung undenkbar.
Weiterhin gibt es eine GIT Integration und als Entwicklungsumgebung gibt es ausschließlich ABAP für Eclipse, da es keine Dynpro oder Web Dynpro Anwendungen mehr gibt. Das Web IDE kann ebenfalls nicht verwendet werden. Haupteinsatzzweck von ABAP in der Cloud ist laut Referent Frank Jentsch die Bereitstellung von OData Services oder Freestyle HTTP Services unter Verwendung von Core Data Services (CDS) und dem neuen RESTful ABAP Programming Model.

 

Die Hauptbestandteile der SAP Cloud Platform ABAP Environment (Quelle: SAP SE)

Die Bereitstellung von ABAP in der Cloud dauert derzeit noch 30-40 Minuten. SAP arbeitet daran diese Zeit deutlich zu reduzieren. Anschließend wurden die zwei Szenarien für die ABAP-Cloud vorgestellt. Dies ist einerseits der Side-by-Side Ansatz für ein S/4 in der Cloud, um das S/4 zu erweitern ohne das S/4 anpassen zu müssen. Wie bereits in der Keynote wurde wieder darauf verwiesen –  Keep the core clean.
Der zweite Ansatz ist der Partner side-by-side Apps oder auch als Software as a Service (SaaS), d.h. SAP-Partner stellen ihre Anwendungen über das SAP App Center bereit und SAP-Kunden können diese als Software as a Service (SaaS) aus der SAP Cloud Platform konsumieren.
In der abschließenden Roadmap wird darauf verwiesen, dass in 2019 zusätzlicher Support für Partner – insbesondere die Integration mit dem SAP App Center – geboten wird. ABAP in the cloud ist sicherlich erst am Anfang, aber ich bin mir sicher, dass auf Grund der großen Kundenbasis und der SAP-Partner es hier zeitnah viele Anwendungen geben wird, die in der ABAP Cloud laufen.

Tag 1 – Hands-on Session – SAP Technology Highlights

Die Mittagspause nutzte ich wieder zum Networken und schaute mich auf dem Showfloor um. Dann ging es zu meiner ersten Hands-on Session „SAP Technology Highlights“. Diese Hands-on Sessions war auf 4 Stunden angesetzt und beinhaltete Übungen zu SAP Analytics Cloud, SAP Leonardo Machine Learning Foundation, SAP Data Hub, SAP Cloud Platform ABAP Environment, ABAP Core Data Services, SAP Fiori Launchpad, SAP Screen Personas (bestehende Dynpros und Web Dynpros können mit dieser Technologie vereinfacht werden oder für mobile Endgeräte bereitgestellt werden) und SAP CoPilot (vergleichbar mit Amazons Alexa nur im Enterprise Kontext zu sehen) – also die volle Bandbreite an SAP Technologien. Es ist natürlich utopisch zu glauben, alle Übungen in nur 4 Stunden durcharbeiten zu können. Die Referenten haben berichtet, dass wohl ein Teilnehmer der SAP TechEd in Las Vegas alle Übungen in 9 Stunden in die Nacht hinein durchgearbeitet hat – Respekt. Leider war die Hands-on Session etwas überbucht, so dass ich mir einen Rechner mit einem Basisberater einer anderen Beratungsfirma teilen musste und wir uns am Notebook abwechselten. Ich würde mir wünschen, dass die Veranstalter der SAP TechEd mehr Plätze für die Hands-on anbieten würden. Dieses Problem gibt es nicht erst seit diesem Jahr. Als Teilnehmer kann man sich nur 3 Hands-on fest reservieren und für alle anderen Hands-on Sessions kann man sich anstellen und hoffen, dass es noch einen freien Platz gibt. In der ersten Übung haben wir ein Geo Reporting in der SAP Analytics Cloud erstellt. Dies war für mich nicht wirklich etwas Neues, da wir bereits mit der SAP Analytics Cloud bei der FIVE1 arbeiten.

Als nächstes entschied ich mich für die Übung mit dem SAP Data Hub. SAP Data Hub wurde am 25.09.2017 als neue Lösung in New York von der SAP vorgestellt. SAP Data Hub ist dahingehend interessant, weil es im Kontext von Big Data die Datenintegration, -orchestrierung und -Governance in heterogenen Systemlandschaften ermöglicht. Wenn man wie ich aus der SAP BI Welt kommt, kann man sich das vorstellen wie eine Mischung aus ETL und Prozessketten im Unternehmen über Systemgrenzen hinweg. So kann man bspw. einen Algorithmus auf Daten in einem Hadoop Cluster anwenden, dann das Ergebnis in ein Flatfile schreiben und diese Daten über eine Prozesskette im SAP BW ins SAP BW laden. Dadurch bringt man nicht die Daten zum Algorithmus, sondern den Algorithmus zu den Daten. Lediglich das Ergebnis wird ins SAP BW geladen und damit die strukturierten Daten im BW angereichert. Der SAP Data Hub muss keine Daten halten, kann aber Daten halten. Die Übung griff auch das Internet of Things (IoT) auf, d.h. mehrere Sensoren (Wettersensoren) liefern sekündlich Daten, wie bspw. Temperatur, Luftdruck, relative Luftfeuchtigkeit. Diese Daten werden dann als BLOB in CSV Dateien gespeichert und diese CSV Dateien werden dann in einem Hadoop Cluster geschrieben. Das Ausführen und das Monitoring des Szenarios war ebenfalls Bestandteil der Übung.

Das gerade beschriebene Szenario wird in Data Hub in sogenannte Data Pipelines (oder auch Graph genannt) modelliert. Hierfür stellt Data Hub einen grafischen Editor zur Verfügung. Der Zugriff auf die Daten bzw. Systeme und deren Verarbeitung erfolgt durch sogenannte Operatoren. SAP Data Hub deckt mit den aktuell verfügbaren Operatoren bereits heute ein großes Spektrum ab. Der Fokus liegt auf Big Data Komponenten wie bspw. Hadoop, Cloud Stores, Machine Learning Services und Real-time Messaging Technologien. Laut den Referenten sind aktuell 244 Operatoren verfügbar und es werden täglich mehr werden auf Grund der Weiterentwicklung des Produkts und wachsender Kundenbasis. SAP will auch in Zukunft den nativen Zugriff auf Datenbanken und Geschäftsanwendungen erweitern. Aus diesem Grund wird auch ein Connectivity Framework zur Verfügung gestellt, dass es SAP-Kunden und Partnern erlaubt eigene Operatoren zu entwickeln.

Neben vielen weiteren bietet SAP Data Hub native Konnektivität für die folgenden Quellen:

Data Hub Operators

Auszug von Data Hub Operatoren welche eine native Verbindung ermöglichen (Quelle: SAP SE)

Zur Simulation der Wettersensoren haben wir zunächst einen neuen Operator angelegt, der auf Basis von Java Script jede Sekunde Wetterdaten mit einer Zufallsfunktion liefert. Am Operator selbst konnte man einstellen, dass der Operator mehrfach ausgeführt wird, d.h. wir haben bspw. 3 Wettersensoren, die unterschiedliche Daten liefern. Diese Sensoren haben wir zu einer Sensorengruppe zusammengefasst. Als nächstes haben wir einen CSV Aggregator angelegt, welcher die Daten vom Sensor ins CSV Format überführt und diesen String dann in einem weiteren Operator in einen BLOB (Binary Large Object) konvertiert, so dass die Daten im nächsten Schritt über einen weiteren Operator in ein Hadoop Cluster geschrieben werden können. Diese Operatoren wurden zur Gruppe Datalake Writer zusammengefasst. Zwischen der Sensor Gruppe und dem Datalake Writer wurde ein Multiplexer Operator eingefügt, so dass die Daten von den Sensoren in einem Terminal ausgegeben werden können. Nachdem Datalake Writer wurde ebenfalls ein Terminal Operator verwendet, um überprüfen zu können, ob das Schreiben in das Hadoop Cluster funktioniert hat. Die Datahub Data Pipeline sieht dann wie folgt im grafischen Editor aus.

Datahub Data Pipeline

Datahub Data Pipeline (Quelle: SAP SE)

Anschließend haben wir das ganze ausgeführt und über die Terminal Operatoren bspw. die Wetterdaten in Echtzeit angeschaut und das Schreiben in das Hadoop Cluster geprüft. Außerdem bietet SAP Data Hub Tracing Funktionalitäten zur weiteren Analyse.

Die nächste Übung war rund um SAP Leonardo Machine Learning Foundation und bestand aus zwei Teilen. Teil 1 war eine Demo zu den Services, welche SAP Leonardo zur Verfügung stellt. Hier konnte war die Gesichtserkennung von SAP Leonardo im Fokus. Hierzu wurden Bilder von SAP CEO Bill McDermot und SAP Gründer Hasso Plattner zur Verfügung gestellt. Die Übung hat sehr gut verdeutlicht, wie man die SAP Leonardo Gesichtserkennung verwenden kann und das SAP Gesichtserkennung anbietet und beherrscht. Im zweiten Teil wurde der SAP API Business Hub vorgestellt und aufgezeigt wie einfach es ist SAP Leonardo Machine Learning Foundation Services über den SAP API Business Hub zu konsumieren. Die verwendeten Modelle waren alle vorbereitet und bereits trainiert. Wir haben zum Beispiel verschiedenste Textdateien hochgeladen und die Topic Detection API verwendet, welche dann bspw. Schlüsselwörter im JSON Format zurückgeliefert hat. Ich persönlich fand es etwas schade, dass man „nur Services“ ausgeführt hat und keine Story um die Funktionen erzählt hat. Spannend wäre für mich zu wissen welche Use Cases SAP hier sieht.

Als letzte Übung hat sich mein Sparingspartner für diese Hands-On die Erstellung eines ABAP Core Data Services (CDS) View ausgesucht. Der CDS View gibt eine Liste von Purchase Orders aus. Der CDS View wird dann als OData Service exponiert und abschließend über die Web IDE unter Verwendung der Smart Template App in der SAP Cloud Platform Fiori Launchpad visualisiert. Für mich nicht wirklich etwas Neues, da ich bereits einige Projekte mit CDS Views erfolgreich abgeschlossen habe. Zunächst haben wir den CDS View in ABAP für Eclipse erstellt und bereits im CDS View über entsprechende Annotationen das Verhalten des UI definiert. Der OData Service wird automatisch durch die OData Annotation @OData.publish: true generiert. Als nächstes haben wir im SAP NetWeaver Gateway System den OData Service registriert und aktiviert, so dass der Service von der SAP Cloud Platform konsumiert werden kann. Abschließend haben wir dann eine UI5 Anwendung über die Web IDE und einem Template entwickelt und als Fiori App in der SAP Cloud Platform bereitgestellt. Die folgende Anwendung ist daraus entstanden.

Entwicklung eines ABAP CDS Views und Fiori App in der SAP Cloud Platform

Entwicklung eines ABAP CDS Views und Fiori App in der SAP Cloud Platform (Quelle: SAP SE)

Abgerundet wurde der erste Tag durch die Möglichkeit des Networking am Abend auf der SAP TechEd bei dem ein oder anderen Bier.

 

Tag 2 – Mein Steckenpferd – Unternehmensplanung mit SAP

Der zweite Tag stand voll im Zeichen der Unternehmensplanung. Seit über 10 Jahren bin ich als Berater im Bereich Unternehmensplanung mit SAP unterwegs. In dieser Zeit hat sich auch einiges getan, die Ablösung von SAP Business Planning and Simulation (BPS) durch SAP Business Warehouse Integrated Planning (BW-IP) durch das SAP NetWeaver 7.0 Release, das Zurückholen des Planning Modeler in den ABAP Stack mit dem Release 7.3, die neuen Möglichkeiten mit HANA und dem SAP BW on HANA Release, dem Zukauf von Outlooksoft das heute als SAP Business Planning and Consolidation (SAP BPC) bekannt ist, das neue SAP BPC Embedded als Weiterentwicklung und verbesserte Integration ins SAP BW, das Planning Application Kit (PAK) welches die Nutzung der Performancevorteile von SAP HANA optimiert hat, um nur einige zu nennen. Mit BW/4 HANA und dem SAP BPC 11.0 ist dieses Jahr eine zusätzliche Planungslösung hinzugekommen. Die SAP Analytics Cloud als ein weiteres, neues Produkt der letzten Zeit,  bietet ebenfalls die Möglichkeit der Planung an.

Planung im SAP ERP ist mit dem Embedded BW schon länger möglich – macht aber erst so wirklich Sinn mit einer HANA Datenbank – somit wäre noch SAP S/4 HANA mit dem Embedded BW zu erwähnen. Puh… ich hoffe ich habe nichts vergessen. SAP-Kunden haben also die Qual der Wahl wie man so schön sagt, wenn es um die Planung geht. Wie sieht nun der Königsweg aus? Vor der SAP TechEd musste ich meinen Kunden leider enttäuschen mit der Gegenfrage wie sieht denn Ihre Systemlandschaft aktuell aus und wie soll sie in der Zukunft aussehen? Und nach dem zweiten Tag? Auch hier muss ich leider wieder enttäuschen – es gibt immer noch keinen Königsweg.

Begonnen hatte der Tag mit der Hands-on „Business Planning for connected Enterprises with  SAP Analytics Cloud“. Der Fokus der Hands-on lag also auf der Planung mit der SAP Analytics Cloud (SAC) und bestand aus sechs Teilen. Im ersten Teil sollte eine Verbindung zu einem S/4 HANA System angelegt werden. Leider konnte dieser Teil der Übung auf Grund technischer Probleme nicht vollständig ausgeführt werden. Im zweiten Schritt sollte ein Planungsmodell erstellt werden, dazu wurden Public Dimensions verwendet und weitere Public Dimensions angelegt. Diese Public Dimensions sind vergleichbar mit zentralen Merkmalen im BW wie bspw. die Merkmale 0COSTCENTER, 0COSTELMNT usw. die in mehreren Datenmodellen verwendet werden. Als weitere Public Dimension legte ich den Company Code an. Im dritten Teil sollte eine Data Source zum Beladen der neuen Public Dimension Company Code angelegt werden, um diese mit Stammdaten zu beladen. Leider war dies nicht möglich auf Grund des technischen Problems im ersten Teil. Im vierten Teil sollte eine Data Source zum Beladen des Datenmodells mit Bewegungsdaten angelegt werden, dass allerdings auch nicht möglich war auf Grund der technischen Probleme im ersten Schritt. Im fünften Schritt sollte die Planning Story angelegt werden. Die Anwendungen in der die Daten aus den Modellen visualisiert werden bspw. durch Charts oder Tabellen, werden in der  SAC als Story bezeichnet. Unser Datenmodell hatte auf Grund der technischen Probleme leider keine Daten. Damit alle Teilnehmer die weiteren Übungen durchführen konnten, haben die Referenten die Vorgabe gemacht das Datenmodell inkl. Daten der Referenten zu kopieren. Mit dem kopierten Datenmodell konnte dann die Story angelegt werden.

SAC Planning Story

SAC Planning Story (Quelle: SAP SE)

Bei der Planung in SAC können die Versionen Private oder Public sein. Die eingegebenen Plandaten wurden zunächst in einer privaten Version gespeichert und dann veröffentlicht. Der letzte und sechste Teil war die Retraktion der Plandaten von der SAC zurück in ein S/4 HANA Cloud System. Diesen Teil konnten wir leider auf Grund der technischen Probleme mit dem S/4 HANA Cloud System auch nicht durchführen.

An dieser Stelle sei noch erwähnt, dass aktuell nur die Retraktion in ein S/4 HANA Cloud System in die Tabelle ACDOCP möglich ist. Vielleicht fragen Sie sich an dieser Stelle: Was ist eigentlich die Tabelle ACDOCP? Mit SAP S/4 Finance werden alle Plandaten in der Tabelle ACDOCP als Teil des Universal Ledgers gespeichert. Durch die Vereinfachung („Simple“) des Datenmodells im SAP ERP wird also auch die Retraktion vereinfacht. Nach Rücksprache mit dem Produktmanagement werden zukünftig weitere Ziele für die Retraktion unterstützt werden. Insgesamt fand ich den Aufbau der Hands-on gelungen, allerdings haben die technischen Probleme mit dem S/4 HANA Cloud System es leider nicht möglich gemacht, alles im Detail zu testen. Den Referenten halte ich zu Gute, dass sie sehr schnell Workarounds bereitgestellt haben, so dass man trotz allem einen guten Überblick über die Planung mit der SAC und der möglichen Retraktion in ein S/4 Cloud System bekommen hat. Verbesserungspotential hat derzeit auch noch das UI der SAC, da dieses nicht durchgängig responsiv ist und beispielsweise bei Werthilfen die Schlüssel nicht vollständig angezeigt werden. Hier kann auch die vom Product Management empfohlene Verwendung des Suchfelds keine Abhilfe schaffen. Der Grund hierfür: Wenn ich den Schlüssel schon kenne, warum sollte ich dann die Werthilfe verwenden?

Die nächste Lecture stand auf dem Program „What’s New in SAP Analysis for Microsoft Office?“.  Diese Session war eigentlich nur als Lückenfüller gedacht und hat sich dann doch als interessant herausgestellt. Vieles kannte ich bereits aus meiner täglichen Arbeit mit Analysis for Office. Die Feature Highlights beinhalteten die nachfolgenden Themen.

  • Die flexible Modellierung in Analysis for Office ermöglicht es ad-hoc Filter auf Kennzahlen, eingeschränkte und berechnete Kennzahlen und lokale Hierarchien zu definieren.  Des Weiteren ist es möglich in Tabellen externe Daten via Excel Syntax über VLOOKUP zu kombinieren. Zusammengefasst ist das ad-hoc Reporting deutlich aufgebohrt worden. Das freut sicherlich den Fachbereich.
  • Die Planung mit dem Analysis Plugin auf Basis von BW und BW/4 HANA Data Sources ermöglicht es Planungsanwendungen mit BW-IP, PAK und BPC Embedded Modellen zu realisieren.
  • Die Kommentierung wie aus Excel gewohnt, wurde in einer Demo vorgestellt. Hier hat SAP sicherlich Fortschritte gemacht, allerdings ist die Lösung nicht so umfangreich wie unsere Kommentierungssuite FIVE1 CSX. Es gibt noch einen weiteren Haken an der Sache: das Ganze steht nur SAP BW/4 HANA Kunden zur Verfügung.

Für mich war der spannendste Teil, dass Analysis for Office mit der SAP Analytics Cloud verwendbar ist. In vielen meiner Planungsprojekte, insbesondere der Kostenstellenplanung, ist für viele Kunden Excel ein Must-have. Zunächst kann Analysis for Office auf alle nativen Modelle aus der Cloud zugreifen und diese im Reporting verwenden. Die Planung wird ebenfalls bereits unterstützt mit der Einschränkung, dass nur bereits existierende Daten überschrieben werden und keine neue Zeilen verwendet werden können, wie man es bspw. aus SAP BW-IP kennt. Die aus der ersten Hands-on Session bekannten Private und Public Planversionen können ebenfalls über einen Tab verwaltet werden. Weitere Einschränkungen sind (Stand Juli 2018), dass keine Remote Models unterstützt werden, d.h. native SAC Modelle mit Datenakquisiton. Desweiteren wird das Highlighten von gesperrten Zellen nicht unterstützt und Kommentare aus der SAC werden nicht in Analysis for Office angezeigt. Für die Modelle der SAC gelten außerdem noch die Einschränkungen, dass nur die Standardwährung unterstützt wird analog zum SAC Chart Verhalten. Der Zugriff auf nicht konvertierte Währungen ist ebenfalls nicht möglich analog zu den SAC Tabellen. Die in der SAC definierten Thresholds können ebenfalls nicht verwendet werden, stattdessen kann man als Workaround das Conditional Formatting in Analysis for Office verwenden. Seit dem zweiten Quartal 2018 gibt es auch eine Analysis for Office Edition für die SAP Analytics Cloud, welche für die ausschließlichen SAC Kunden gedacht ist. Wenn also neben der SAC ein BW, BI Plattform, HANA Modelle, EPM oder BPC genutzt wird, dann sollte die Standard Version von Analysis for Office verwendet werden.

Im Anschluss ging es dann gleich weiter zur nächsten Session „Business Content and Planning Applications for SAP Analytics Cloud“.  In dieser kurzen Session wurde der Business Content der SAP für die SAC vorgestellt und in einer Demo gezeigt, wie man den Content in der SAC finden und verwenden kann. Neben dem Business Content der SAP haben auch SAP-Partner die Möglichkeit Content für die SAC zu entwickeln und den SAP-Kunden zur Verfügung zu stellen. Der Business Content bietet den SAP-Kunden wie auch bspw. im BW einen schnellen Start. Wie im BW gilt auch hier: man kann ihn verwenden und ist schneller im Projekt. Alternativ kann man alles selbst erstellen und die Gegebenheiten im Unternehmen exakt modellieren, was meistens länger dauert. Es freute mich zu sehen, dass die SAP einer der Erfolgsfaktoren des BW beibehält und Business Content in der SAC zur Verfügung stellt.

Nachdem Mittagessen hatte ich wieder etwas Zeit zum Networken und dann ging es auch schon weiter mit der nächsten Hands-on „Advanced Planning Features in SAP Analytics Cloud“. In dieser Hands-on sollte der Fokus u.a. auf Planungsfunktionen und -sequenzen gelegt werden, um es mit dem SAP BW-IP Wording zu umschreiben, wie mir das Product Management bereits in der Session am Morgen verraten hat. Das Datenmodell war bereits vorhanden und das Szenario sah auch die Integration zwischen Teilplänen vor. So wurde angedeutet was alle Unternehmen letzten Endes mit der Planung verfolgen: Eine Plan P&L, die sich aus verschiedensten Teilplänen ergeben, die sich wechselseitig beeinflussen.

Der erste Teil sah vor, dass man den Operating Income Report anschaut und auch die Employee Headcounts und Expenses. Dabei stellte man fest, dass in der Southeast Region der USA der Operating Income und die Gross Sales stetig sanken, was durch einen Rückgang des wichtigen Vertriebspersonal zu begründen wäre. Dieser Sachverhalt und den Link von der P&L zu den Personal Expenses sollte man über die Formel in der P&L für die Personal Expenses nachvollziehen.

Im nächsten Teil sollte man feststellen das in Q4 die Headcounts für die Southeast Region rückläufig waren. Natürlich kann es verschiedenste Gründe für sinkende Sales und Operating Income in der Region geben, aber die Kündigungen von führenden Vertriebsmitarbeitern könnte sich auf die Sales auswirken.

Auf Basis dieser Erkenntnisse sollte im nächsten Schritt ein neuer Plan für die Employee Expenses, basierend auf den aktuellen Jahreszahlen, erstellt werden. Dieser Plan wird für das laufende Jahr und das Folgejahr kopiert, um den Plan zu entwickeln. Die Kopierfunktionen wurden mit Formeln realisiert, die mich sehr stark an Fox Formeln erinnerten. Neben den Funktionen zum Kopieren der Ist-Daten, mussten wir auch einige sogenannte data actions erstellen, um die Headcounts neu zu berechnen und um Änderungen in den Employee Expenses zu berücksichtigen.

In der nächsten Übung wurde eine Anwendung mit Kostentreiber für das Personal der Region erstellt. Kostentreiber waren z.B. Durchschnittsgehalt, Steuern, Firmenwagenrate oder Kosten zum Einstellen von Mitarbeitern. Die Änderung der Kostentreiber hat sich wiederum auf die Employe Expenses ausgewirkt. Ebenfalls in diesem Abschnitt wurde eine Verteilungsfunktion der Jahreswerte auf die Monate realisiert, wie man es aus dem Phasing kennt. Außerdem wurde ein Data Locking Tool in dieser Übung vorgestellt, welches zum Öffnen und Sperren von Versionen entlang der Organisationshierarchie verwendet werden kann. Dies ist auch eine Anforderung, die man immer wieder bei den Kunden vorfindet: Daten sollen über eine Anwendung gesperrt und geöffnet werden können. Außerdem wurde noch kurz auf die Formatierungsmöglichkeiten der Story eingegangen, was jedoch nicht im Fokus der Übung war.

Im nächsten Teil wurde gezeigt, wie eine allocation erstellt wird, um die in einer Region gebündelten Marketingkosten auf viele Regionen aufzuteilen. Diese Zuordnung wurde über ein berechnetes Element realisiert, um die Komplexität des Szenarios etwas zu erhöhen. Letzten Endes handelte es sich um eine Verteilungsfunktion auf Basis von Referenzdaten. Die Marketingkosten sollten auf Basis der Sales PY Daten verteilt werden.

In der letzten Übung wurde dann die Verkaufsplanung aufgegriffen. Die Preise wurden auf verschiedenen Hierarchieebenen gespeichert und im Modell wurde eine Ausnahmeaggregation verwendet, um die Berechnungen durchzuführen. Das Hauptziel dieser Aufgabe war jedoch zu zeigen, wie Input Tasks verwendet werden können, damit andere Planer den Plan systematisch aktualisieren können. Hierüber kann man Workflows realisieren ähnlich wie in SAP BPC.

Wow, das war sehr umfangreich und ich muss sagen, die Planung in der SAC kann schon sehr viel. Vieles was man in allen Planungsprojekten benötigt, wurde adressiert. In der realen Welt wird natürlich nicht eine Person in einer Story die Mitarbeiterkosten planen, die Marketingkosten planen und die Verkaufsplanung initiieren. Jedoch muss ich gestehen, dass dies ein wirklich durchdachter Showcase war. Im Anschluss an die Übung war noch Zeit mit dem Produktmanagement Fragen zu klären. Für mich war die Frage, wie eine solche Lösung nun transportiert werden kann und wie der Transport aussieht. Für SAP-Kunden ist eine drei Systemlandschaft eigentlich Standard. Das Produktmanagement meinte, dass es eher so gedacht ist, dass man nur noch ein Produktivsystem hat, weil die Planung in der SAC auch eher für den Fachbereich gedacht ist, so dass die IT nicht involviert ist. Sollte das bedeuten, dass man mit der SAC nur noch eine „Operation am offenen Herzen“ durchführen kann? Zum Glück nicht! Auf weiteres Nachfragen hat uns der Referent gezeigt, wie man die entwickelte Lösung sammeln und dann exportieren kann. Diese kann man dann in einem anderen Tenant importieren. Dass die Planung in SAC ausschließlich ein Fachbereichstool wird, sehe ich nicht. Das hat verschiedene Gründe: Bereits mit BW-IP hat die SAP bspw. versucht den Fox Formel Editor im Fachbereich anzupreisen, jedoch ohne Erfolg. Auch die Retraktion von Plandaten und somit das Mapping in das operative S/4 HANA System sehe ich nicht beim Fachbereich. Auch eine Notwendigkeit einer Mehrsystemlandschaft sehe ich aus mehreren Gründen wie bspw. das Testen der Retraktion bevor fehlerhafte Daten ins operative System retrahiert werden, weil nicht getestet wurde.  Planungsfunktionen, die zur Integration der Teilpläne dienen, ändern Daten in verschiedenen Modellen. Sollte hier ein Fehler gemacht werden, sind gleich mehrere Datenmodelle betroffen.

Außerdem hat SAP und auch wir unseren Kunden in den letzten Jahren immer wieder propagiert,  das SAP BW als Single Point of Truth zu sehen und dies auch auf die Planung im BW übertragen. Dies soll nun alles wieder vergessen werden, wie schon Konrad Adenauer sagte: „Was kümmert mich mein Geschwätz von gestern!“ Den Wunsch der Fachbereiche nach Agilität und Flexibilität kann ich durchaus nachvollziehen. Wer will schon für eine einfache Änderung eines Berichts Tage oder gar Wochen warten? Es gilt den Spagat zu schaffen zwischen Agilität und Flexibilität einerseits und andererseits aber auch Stabilität, Robustheit und Konsistenz durch eine Governance.  Hierzu muss auch die IT mit einbezogen werden. Dies zu erreichen in dem man ein System komplett dem Fachbereich übergibt, halte ich persönlich nicht für den richtigen Weg. Es ist wieder ein Extrem in die andere Richtung. Viel mehr muss dies organisatorisch angegangen werden: So müssen die oft vorhandenen Gräben zwischen IT und Fachbereich beseitigt werden. Man sollte die alten Vorgehensweisen durch neue, agile ersetzen und kurze Wege und schnelle Kommunikation ermöglichen, Overhead durch overengineerte Prozesse wie man sie auch im Solution Manager leider oft vorfindet, vereinfachen, starre Budgets durch agile Budgets ersetzen – kurzum gesagt: es gilt die Zusammenarbeit von Fachbereich und IT zu überdenken – und es nicht nur dabei belässt, sondern dies auch ändert.

Die letzte Lecture an diesem Tag war „Business Planning for Insight-Driven Enterprises“. Diese Lecture war eher eine Power Point Show, jedoch mit einem sehr guten fachlichen Inhalt. Hier wurde herausgestellt, dass im Rahmen der Digitalisierung und der sich immer schneller ändernden Welt, sich auch die Planungsprozesse in den Unternehmen ändern müssen. So kann es bspw. nicht sein, dass wenn im Board Meeting eine Frage gestellt wird à la „Was wäre wenn…“ dies zur Folge hat, dass ganze Abteilungen zwei Wochen lang die Planung anpassen, um die Frage zu beantworten. Schade dass dieser Vortrag so spät am Abend angesetzt war und deshalb sicherlich auch schlecht besucht war. Der Vortrag war alles andere als technisch für eine TechEd, allerdings fand ich diesen sehr gut, um einen Blick auf das Big Picture zu bekommen. Warum wird eigentlich geplant? Und ist es überhaupt sinnvoll zu planen, wenn die Planungsprozesse so lange dauern und viele Mitarbeiter und Ressourcen binden? Keiner im Unternehmen vertraut dem aufgestellten Plan, weil jeder schon weiß dass es neue Erkenntnisse gibt, die sich auf den Plan auswirken. Zudem sind die Plan-Ist-Abweichungen immer so groß, dass niemand dem Plan Glauben schenkt? Und muss wirklich alles von Menschen geplant werden oder kann ein Großteil davon vielleicht bereits heute über Predictive Analytics also Algorithmen genauer prognostiziert werden? Und könnten die freigesetzte Ressourcen dann nicht etwas sinnvolleres machen?  So könnten bspw. die Vertriebsmitarbeiter anstatt Verkaufspläne aufzustellen die Zeit mit den Kunden verbringen.

Abgeschlossen wurde der Tag mit der Abendveranstaltung 4 Clubs | 4 Vibes | 4U.  Mit Shuttle Bussen ging es am Abend zu vier Clubs am Strand von Barcelona. Es gab Finger Food mit Wein und Bier. Das ganze war bis 23 Uhr angesetzt. Ich kannte die Abendveranstaltung von früheren TechEds als Demo Jam. Bei den Demo Jams wurde auf dem Messegelände auf einer Bühne von SAP-Mitarbeitern, Kunden oder Partnern in einer vorgegeben Zeit ziemlich coole Demos mit SAP Kontext vorgestellt. Die TechEd Besucher genossen eine coole Show bei Bier und Finger Food und konnten dann abstimmen wer der Gewinner der Demo Jam ist. Ich persönlich fand diese Art der Abendveranstaltung besser als die Clubs. Die Organisation mit den Shuttle Busen war jedoch gut. Anschließend war ich mit dem FIVE1-Team und ein paar SAP-Kollegen noch auf einen Absacker in der City, um den Tag ausklingen zu lassen.

 

Tag 3 – Road to BW/4 HANA, Muster für den Einsatz von Blockchain, Intuitive Machine Learning , Learning Scenarios with BW/4 HANA

Der letzte Tag startete mit der Lecture „Conversion Paths to SAP BW/4HANA“ oder wie ich es nennen würde die Road to BW/4 HANA.

Conversion Paths to SAP BW/4HANA

Zunächst wurde das BW/4 HANA vorgestellt und erklärt wie das SAP BW/4 HANA vereinfacht wurde im Vergleich zum „alten“ BW.

BW/4HANA vereinfacht das BW

BW/4HANA vereinfacht das BW – ein Überblick (Quelle: SAP SE)

Wie sieht also der Weg für SAP BW Kunden aus? Das kommt auf die Ausgangssituation an.
Es gibt drei Pfade zu BW/4

  • Neue Installation – Green Field Ansatz
  • System Conversion
    • In-place Conversion
    • Remote Conversion
    • Shell Conversion
  • Landscape Transformation

SAP hat hierfür einen Conversion Guide auf der SAP Hilfe bereitgestellt.

Road to BW/4 HANA

Road to BW/4 HANA (Quelle: SAP SE)

Ich will an dieser Stelle nur kurz die 3 Pfade beschreiben ohne zu sehr in die Details einzusteigen.

Der sicherlich einfachste Pfad, ist die Neuinstallation eines BW/4 HANA Systems bspw. für Neukunden. Oder wenn man ein gewachsenes BW System hat, kann man BW/4 HANA als Möglichkeit sehen die Architektur des EDW zu überdenken indem das „alte BW“ parallel betrieben wird und nach und nach geprüft wird, wie die Anwendungen im BW/4 HANA neu aufgebaut werden auf Basis der LSA++ und quasi alte Zöpfe abschneidet und sich somit von „Altlasten“ befreit.

Der zweite Pfad – der Systemkonvertierung kann in drei Arten unterteilt werden.

Die In-Place Conversion sieht vor, dass das komplette System konvertiert wird und die System ID behalten wird. Hierzu muss das System zunächst auf BW 7.5 SP5 on HANA upgegraded werden und dann nach und nach die klassischen Objekte wie bspw. DSO oder Cubes zu HANA optimierten Objekte wie in diesem Fall das Advanced DSO konvertiert werden. Wenn alle klassischen Objekte konvertiert wurden, kann die System Conversion durchgeführt werden.

Die Remote Conversion sieht eine Neuinstallation vor mit einer neuen SID. Dann werden die Datenmodelle transportiert und die Datenflüsse und -modelle angepasst und dann die Daten vom alten BW ins BW/4 HANA System geladen. Dieser Ansatz ist ähnlich der Neuinstallation, jedoch werden die alten Datenmodelle und -flüsse übernommen und angepasst. Im Gegensatz zum Greenfield Ansatz werden die bisherigen Anwendungen übernommen und angepasst, jedoch nicht komplett hinterfragt und ggf. auch „Altlasten“ übernommen. Im Vergleich zur In-Place Conversion wird das Riskio minimiert durch den Parallelbetrieb.

Die Shell Conversion ist ähnlich wie die Remote Conversion mit dem Unterschied, dass keine Daten aus dem alten BW übernommen werden. Stattdessen hat man die Wahl:

  • die Daten aus den original Quellsystemen zu laden
  • die Daten aus dem alten BW System zu laden
  • die Historie zu ignorieren und Neu zu starten

Die folgende Abbildung gibt nochmals einen Überblick.

BW/4 HANA System Conversion

BW/4 HANA System Conversion (Quelle: SAP SE)

Falls Sie Fragen hierzu haben, beraten wir Sie gerne.

 

Blockchain in Industry Scenarios: Understand Patterns and Approaches

Die nächste Lecture sollte mein Blick über den Tellerrand sein „Blockchain in Industry Scenarios: Understand Patterns and Approaches“. Viele kennen die Blockchain durch Bitcoin oder von Gartner Folien als ein weiterer Hype wie die folgende.

Blockchain value laut Gartner

Blockchain value laut Gartner (Quelle: Gartner)

Doch wie sieht der Einsatz von Block Chain in in der Geschäftswelt aus? Diese Lecture sollte Licht ins Dunkle bringen.
Doch zunächst was ist eigentlich eine Blockchain?

Eine Blockchain (auch Block Chain, englisch für Blockkette) ist eine kontinuierlich erweiterbare Liste von Datensätzen, genannt „Blöcke“, welche mittels kryptographischer Verfahren miteinander verkettet sind. Jeder Block enthält dabei typischerweise einen kryptographisch sicheren Hash (Streuwert) des vorhergehenden Blocks, einen Zeitstempel und Transaktionsdaten.

Soweit die Definition von Wikipedia. Ich will an dieser Stelle das Blockchain Konzept nicht im Detail erklären, da dies hier den Rahmen sprengen würde und es auch genügend Quellen im Internet gibt um dieses Thema zu vertiefen.

Für die Blockchain gibt es zwei Deployment Optionen – Public oder Consortium. Public bedeutet eine berechtigungslose Blockchain, d.h. sie ist offen für jeden und jeder kann schreibend/lesen daran teilnehmen – prominenter Vertreter hierfür ist der Bitcoin. Consortium bedeutet das der Zugriff und die Berechtigungen festgelegt ist auf vorab ausgewählte Knoten also Teilnehmer im Netzwerk. In der Geschäftswelt wird in den meisten Fällen die Deployment Option Consortium verwendet, d.h. bestimmte Firmen schließen sich zusammen um die Blockchain zu betreiben.

Für welche Szenarien ist die Blockchain nun in der Geschäftswelt geeignet? SAP hat hier Value Driver identifiziert für den Einsatz von Blockchain in der Geschäftswelt. Die folgende Slide gibt diese wieder.

Quelle: SAP SE

Ok, dann sollte alles klar sein. Natürlich nicht, dies sollte anhand von Use Cases näher erläutert werden, welche SAP bereits als Proof of Concepts umgesetzt hat und/oder schon produktiv genommen hat. Ich will hier nur ein paar Auszüge davon aufführen.

Ein Beispiel war die Region Südtirol, welche die amtlichen Dokumente digitalisieren und somit das Papier loswerden wollte. Die Dokumente werden digitalisiert durch abfotografieren bzw. scannen. Die Dokumente könnten natürlich einfach gefälscht werden bspw. durch Photoshop. Um dies zu verhindern, kommt die Blockchain Technologie zum Einsatz, d.h. für das digitalisierte Dokument wird über eine Hash Funktion ein Hashwert berechnet. Sobald auch nur ein Pixel geändert wird, stimmt der Hashwert nicht mehr. Das Amt bestätigt über Private / Public Key Technologie die Echtheit des Dokuments und speichert den Hashkey mit einem Zeitstempel in der Blockchain. Andere Teilnehmer im Blockchain Netzwerk können dann die Echtheit des Dokuments sowie den Zeitstempel über die Blockchain abfragen. Der Zugriff auf die Blockchain wie bspw. das Hochladen eines Dokuments erfolgt über moderne Fiori Apps oder Apps für unsere Smart Phones. Dieses Szenario kann natürlich auf alle Arten von Dokumenten übertragen werden wie bspw. das Diplom/Bachelor/Master von der Universität.

Ein weiterer Use Case ist die Identifikation und Verifikation von Pharmazeutika. Die Partner im Arzneimittelmarkt müssen die Anforderungen der EU-Richtlinie zum Schutz vor Arzneimittelfälschungen ein System zur Verifikation von Arzneimitteln entwickeln, das es autorisierten Nutzern erlaubt, Verkaufsverpackungen zu identifizieren und festzustellen, ob es sich hierbei um ein Originalprodukt handelt, oder ob der Verdacht einer Produktfälschung vorliegt. Es wird für Apotheken verpflichtend sein, eine solche Prüfung vor Abgabe einer Packung an den Patienten durchzuführen. Die Funktionsweise des Verifikationssystems beruht auf drei Elementen:

  1. Eindeutige Kennzeichnung betroffener Packungen durch den Hersteller
  2. Speicherung der in der Kennzeichnung enthaltenen Information in einer
    Datenbank
  3. Überprüfung der Packung durch die Apotheke über einen Abgleich der auf der
    Packung vorhandenen Daten mit der, in der Datenbank gespeicherten
    Information.

In den USA gibt es ähnlich zur EU-Richtlinie den Drug Quality and Security Act (DQSA). Partner im Arzneimittelmarkt haben sich in den USA zusammengeschlossen, um ein System auf Basis von Blockchain zu entwickeln, das diese Anforderung erfüllt.

Identifikation und Verifikation von Arztneimitteln

Identifikation und Verifikation von Arztneimitteln (Quelle: SAP SE)

Die Hersteller kennzeichnen die betroffenen Verkaufsverpackungen mit einem individuellen maschinenlesbaren Code. Der Code beinhaltet die Produktnummer, die Chargenbezeichnung, das Verfalldatum und eine Seriennummer. Diese Daten erlauben die eindeutige Identifikation jeder einzelnen Packung. Zusätzlich ermöglichen diese Informationen, Großhändlern und Apothekern, ihre logistischen Abläufe zu verbessern. Bevor der Hersteller ein gekennzeichnetes Produkt in den Markt bringt, überträgt er die im Code enthaltene Information an die Blockchain mit einem Zeitstempel, auf die autorisierte Marktpartner ebenfalls zugreifen, um ein Arzneimittel zu identifizieren. Alle Partner können die Historie einer Packung nachvollziehen.

Bevor eine gekennzeichnete Packung an einen Patienten abgegeben werden darf, muss der Apotheker den aufgedruckten Code mit einem entsprechenden Lesegerät auslesen und die gelesene Information mit den Daten vergleichen, die zu dieser Packung in der Blockchain vorliegen. Ist der Abgleich erfolgreich und erlaubt der in der Blockchain gespeicherte Packungsstatus die Abgabe, so kann diese erfolgen.

Mit Bestätigung der Abgabe wird der Packungsstatus auf „Abgegeben“ gesetzt. Diese Statusänderung ist von elementarer Bedeutung für das Funktionieren des Gesamtsystems. Sollte nämlich ein Fälscher versuchen, den Code einer Originalpackung – wiederholt – zu kopieren
und auf diese Weise ein gefälschtes Produkt als scheinbare Originalware in den Markt zu schleusen, so wird dieser Versuch spätestens bei der Überprüfung während des Verkaufsvorgangs in der Apotheke entdeckt. Die Rückmeldung des Systems an die Apotheke wäre in diesem Fall mit der Warnung verbunden, dass eine Packung mit gleicher Identifikation schon früher verkauft wurde, mithin also ein Fälschungsverdacht vorliegt.

Im Folgenden sind ein paar Screenshots der Mobile App zum Scannen der Verpackung zu sehen.

Mobile App zum Prüfen der Echtheit eines Arztneimittels

Mobile App zum Prüfen der Echtheit eines Arzneimittels (Quelle: SAP SE)

Dieses Szenario könnte natürlich auch durch eine zentrale Datenbank realisiert werden. Dies hat jedoch den Nachteil, dass alle Teilnehmer des Arzneimittelmarktes einerseits dem Betreiber dieser zentralen Datenbank wie bspw. einer staatlichen Organisation vertrauen müssen, dass die Daten in der zentralen Datenbank korrekt sind. Gleichzeitig besteht aber mit einer zentralen Datenbank ein viel größeres Risiko, dass die zentrale Instanz die Datenbank für Betrugszwecke selbst manipuliert oder Opfer eines Cyberangriffs wird. Die dezentrale Blockchain macht einen Betrugsversuch beinahe unmöglich, da mehrere Blockchain-Teilnehmer den Betrug bestätigen müssten also auch Opfer eines Cyberangriffs werden müssten. Die dafür notwendigen Ressourcen übersteigen den möglichen Ertrag eines Betrugs – so dass die Blockchain nicht den Betrug selbst versucht zu verhindern, sondern das Konzept der Blockchain durch die dezentrale Organisation macht einen Betrugsversuch unrentabel für Betrüger.

Für mich persönlich ein sehr gelungener Vortrag – vor allem weil nicht nur die Technologie erklärt wurde, sondern anhand von realen Use Cases die Vorteile der Blockchain Technologie veranschaulicht wurde.

Intuitive Machine Learning Scenarios Based on SAP BW/4HANA

Am Nachmittag stand dann für mich meine letzte Session auf dem Programm. Die Hands-on Session „Intuitive Machine Learning Scenarios Based on SAP BW/4HANA“. In dieser Hands-On Session wurde das Zusammenspiel von BW/4 HANA und der SAP Predictive Factory anhand von zwei Übungen vorgestellt. Beide Übungen boten die Möglichkeit das Trainieren von verschiedenen Modellen in der Predictive Factory auszuprobieren.

Die erste Übung basierte auf folgendem Szenario: Ein Online-Shopping-Portal, das Beauty- und Pharma-Produkte zum Verkauf anbietet, sammelte Daten, die die Nutzung und die Aktivitäten im Portal beschreiben. Basierend auf diesen Daten möchten sie vorhersagen, welche Kunden am wahrscheinlichsten abwandern. Um Muster in ihren historischen Daten zu finden, möchten sie ein Klassifizierungsmodell anhand der gesammelten Daten trainieren. Die Übung umfasste dabei zunächst eine Verbindung zum BW/4 HANA Übungssystem im Eclipse BW Modelling Tool (BWMT), um sich dann mit dem bereits existierenden Datenmodell vertraut zu machen. Jede Gruppe hat ein ODS View angelegt, um der Predictive Factory den Zugriff auf die Daten über einem external HANA View zu ermöglichen. In der Predictive Factory haben wir dann ein Classification Model angelegt und dieses anschließend trainiert. Dies wird typischerweise von einem Data Scientist durchgeführt, da hierfür fortgeschrittene Mathematik bzw. Statistik Kenntnisse vorausgesetzt sind, wurde anschließend das Model und die Parameter erklärt. Aus meiner eigenen Erfahrung mit Predictive Analytics weiß ich, dass die Projekte einen iterativen Charakter aufweisen, d.h. man muss die Modelle immer wieder überprüfen und optimieren. Im nächsten Schritt wurde ein Deviation Test durchgeführt und ein erneutes Training des Models durchgeführt. Die Ausführung eines Deviation Test und erneutes Training kann eingeplant werden zur regelmäßigen Ausführung ähnlich einer Prozesskette im BW. Laut Referenten plant man dies bspw. monatlich ein, wenn man weiß, dass jeden Monat neue Daten vom Online-Shop ins BW geladen werden. Die Ergebnisse der Klassifizierung können von der Predictive Factory zurück ins BW/4 geschrieben werden. In unserem Beispiel dient das dazu, um die Kundenabwanderung den Kunden zu zuordnen.

Die zweite Übung fand ich persönlich interessanter, da es darum ging mit der Predictive Factory auf Basis von Ist Produktverkäufen den Forecast zu prognostizieren. Aus meinen Planungsprojekten weiß ich, dass heute hierfür mehrere Vertriebsmitarbeiter meist mehrere Tage eingespannt werden, um einen möglichst genauen Forecast auf Produktebene zu erstellen, weil ganz oft die Produktionsplanung davon abhängt. Aus meinen Workshops weiß ich aber auch, dass ein Großteil der Produkte bspw. saisonalen Verläufen folgt oder einfach jedes Jahr 5% mehr verkauft werden kann, d.h. der Forecast also einer gewissen Logik unterliegt und somit durch einen Algorithmus also vom System erzeugt werden könnte. Dadurch könnten die Vertriebsmitarbeiter sich auf ihre Hauptaufgabe konzentrieren – dem Verkaufen und dem Kundenkontakt.

Die Referenten erwähnten eingangs der Übung, dass die Prognose für Produktverkäufe ziemlich schwierig sein kann, da fast jedes Produkt eine unterschiedliche Saisonalität und andere Einflussfaktoren hat. Daher müssen Kunden für jedes Produkt eine andere Zeitreihe trainieren, was bei manueller Ausführung zeitaufwendig sein kann. In dieser Übung sollte uns gezeigt werden, wie einfach dies sein kann unter Verwendung der segmented time series forecast in der Predictive Factory. Die Übung setzte wieder auf ein bestehendes Datenmodell im BW/4 HANA auf und in der Predictive Factory wurde ein Model für Time Series Forecasting angelegt und trainiert. Das Ergebnis des Modells kann dann wieder zurück ins BW geschrieben werden und bspw. monatlich eingeplant werden, so dass das Model iterativ optimiert wird, wenn bspw. monatlich neue Ist-Daten ins BW geladen werden.

Ich kenne die Skepsis meiner Kunden gegenüber einer „Planung durch das System“. Hier sehe ich jedoch eine Riesenchance für die Kunden indem man beim monatlichen Rolling Forecast einfach die Predictive Factory „mitlaufen“ lässt und die Ergebnisse in einem separaten advanced DSO zurückschreibt. Dann kann man ein Composite Provider über die Advanced DSOs mit den Ist-Daten, Forecast-Daten von den Vertriebsmitarbeitern erfasst und den Forecast Daten von der Predictive Factory angelegt und über einen Abweichungsbericht prüfen, ob die Vertriebsmitarbeiter oder die Predictive Factory einen genaueren Forecast erstellt. Spätestens dann, wenn über einen längeren Zeitraum die Predictive Factory den genaueren Forecast erstellt, gibt es keine Argumente mehr, dass die Vertriebsmitarbeiter mit der Erfassung von Forecast Daten von Produktverkäufen verbringen anstatt mit ihren Kunden.

Den letzten Abend in Barcelona haben wir bei einem gemeinsamen Teamabendessen verbracht und uns über die vergangen Tage ausgetauscht. Wir haben viel gelernt und hatten eine super Zeit in Barcelona.

Heimreise

Am letzten Tag nutzten wir den Vormittag in unserem Hotel, um uns noch einmal auszutauschen über die letzten Tage und die aufgelaufene Arbeit aus dem täglichen Business anzugehen. Kurz vor Mittag fuhren wir dann mit einem Taxi an den Flughafen. Hier hatten wir noch die Möglichkeit ein Mitbringsel für unsere Liebsten zu Hause zu kaufen, die bereits auf uns warteten. Mit etwas Verspätung startete unsere Lufthansa Maschine dann um kurz nach 14 Uhr nach Frankfurt bevor wir unsere letzte Reise für diese Woche mit dem Auto nach Hause antraten.

Fazit

Mein Fazit zur SAP TechEd 2018 in Barcelona ist, dass sich die Reise gelohnt hat: Um eine Pause im täglichen Business einzulegen, um in die Zukunft zu schauen und auch über den Tellerrand hinaus – insbesondere wie SAP sich den Weg zum intelligenten Unternehmen vorstellt und welche Werkzeuge es dafür seinen Kunden zur Verfügung stellt. Einiges funktioniert schon recht gut wie bspw. die CDS Views und die Fiori Apps und haben sicherlich auch noch viel Potential. Manches wie bspw. die Planung in der SAP Analytics Cloud sehe ich noch am Anfang und es muss noch einiges nachgeliefert werden, so dass es die aktuellen Lösungen bei den Kunden ersetzen kann. Hier ist aber anhand der Entwicklungen und den Diskussionen mit dem SAP Product Management zu erkennen, dass SAP dies bereits auf dem Schirm hat und daran arbeitet wie bspw. SAP Analysis for Office für die SAC, so dass auch Reporting und Planung im Excel möglich wird. Die Retraktion in ein On-Premise System wird vermutlich auch über kurz oder lang kommen. Auch die Möglichkeiten von Machine Learning und AI sowie die spannenden Vorträge über Block Chain Use Cases stimmen mich zuversichtlich für die Zukunft – in diesem Sinne – es ist gibt wieder einmal eine Chance ganz vorne mit dabei zu sein. Jetzt gilt es diese zu nutzen!

Getagged mit: , , , , , , , , , , , , , , , , , , , , , , , , ,

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

*