SAP-Partner pmc America auf dem Weg zu Steampunk und BTP: Der Weg ist das Ziel

Mit pmc America President und CEO Heiko Edelmann führte E3-Chefredakteur Peter Färbinger das nachfolgende Interview. pmc bietet End-to-End-Softwarelösungen, die Lean-Prinzipien unterstützen und es Unternehmen ermöglichen, ihre Geschäftsprozesse sofort zu verbessern und Wettbewerbsvorteile zu erzielen. pmc maximiert den Geschäftserfolg durch eine Kombination aus spezialisierten Beratern, Methoden, SW-Werkzeugen und einem umfassenden Portfolio an Unternehmenssoftwarelösungen für die Automobil- und Fertigungsindustrie.

Diese Angebote decken alle Phasen des Lebenszyklus einer Softwarelösung ab, von der Planung über die Erstellung, das Customizing bis hin zum Betrieb. Die Lösungen und Dienstleistungen von pmc verbessern nachweislich die Effizienz, Rentabilität und Anpassungsfähigkeit von Unternehmen.

Peter M. Färbinger: Sehr geehrter Herr Edelmann, mit welchen Sprachen und IT-Werkzeugen haben Sie für SAP-Bestandskunden in der Vergangenheit notwendige Anpassung, Erweiterung und Modifikationen durchgeführt?

Heiko Edelmann, pmc President und CEO: Hallo Herr Färbinger, vorab vielen Dank für die Möglichkeit, über das E3-Magazin unsere langjährige SAP-Einführungs- und Entwicklungserfahrung in der Automobilindustrie mit unseren Peers und Ihren Lesern teilen zu dürfen. Da unser Hauptfokus die weltweite Automobilzulieferindustrie ist, haben wir entsprechend viele High-Performance-Add-ons im Bereich Kundenprozesse, EDI-Prozesslogik für Kundenprozesse, RF-Scanning-Automatisierung, Labeling und End-User Effectiveness und Optimierung entwickelt – daher kommt lediglich eine Handvoll Werkzeuge infrage. Die Prämisse ist immer die gleiche – Add-ons, die direkt im SAP laufen, werden mit SAP-Standard-Tools entwickelt, um die bestmögliche Performance und ein risikofreies Update und Upgrade – da modifikationsfrei – zu bieten. Daher haben wir uns auf die folgenden Tools spezialisiert, um das Bestmögliche für ECC-, On-prem-, Private- und Public-Cloud-Kunden einzuführen: Abap, Abap RAP, also RESTful Application Programming, UI5, sprich Fiori, PDF und ITS mobile. Mit diesen Tools kann man problemlos 90 Prozent der Anforderungen abdecken.

Färbinger: Somit entstanden auch viele Abap-Modifikationen im Z-Namensraum. Geht dieses Intellectual Property bei einer S/4-Conversion verloren?

Edelmann: Generell sehen wir relativ viele Entwicklungen bei unseren ERP/ECC-Bestandskunden, die man eher nicht konvertieren sollte. Viele dieser Entwicklungen sind eigentlich nun nicht mehr aktuell, da sich interne Geschäftsprozesse weiterentwickelt haben oder eben die SAP-Software nun etliche Funktionalitäten mehr bietet. Daher ist es enorm wichtig zu unterscheiden, welche Entwicklung tatsächlich noch IP darstellt oder bereits Legacy-Code ist, den man eigentlich nicht mehr haben möchte.

Färbinger: Und was ist mit dem wahren Intellectual Property?

Edelmann: Bezüglich IP-Verlust bei einer Migration: Da muss man zwischen der Private und Public Cloud unterscheiden. Bei der Migration von SAP ERP/ECC zur Private Cloud geht eigentlich keinerlei IP verloren – SAPs Migrationstool ist da wirklich top und man benötigt lediglich einige Änderungen im Code und dann läuft das astrein wieder in der privaten Cloud.

Färbinger: Und in der Public Cloud?

Edelmann: Mit der Public Cloud sieht es da etwas anders aus, da die darunterliegende Entwicklungsplattform, CAP oder RAP, eben ganz anders aufgebaut ist. Ich würde diese Migration mehr als eine Evolution betiteln. Wir nehmen alle Konzepte unserer Softwarelösungen und wenden das Abap-RAP-Entwicklungsmodell an, Abap RESTful Application Programming – das heißt, wir können Codeteile eins zu eins rüberkopieren, aber es bleibt eben eine Neuentwicklung. Da wir bereits seit über einem Jahr in der Public Cloud entwickeln, ist das für uns jetzt eher eine Selbstverständlichkeit geworden; auch wenn es zugegeben ein sehr großer Paradigmenwechsel für uns war. Aber der schluss­endliche Benefit ist ein zukünftiges ERP-System, das nahezu Custom-Code-frei ist und dennoch Zusatzfunktionen bietet – das heißt, für uns erstmals sehr schmerzhaft war, aber für unsere Kunden kreiert dies einen langfristigen Benefit.

Färbinger: Wie werden Sie als SAP-Partner zukünftig Modifikationen in einem S/4-System durchführen? Mit welchen Sprachen und Werkzeugen?

Edelmann: Wir werden nach wie vor unserer DNA treu bleiben und hauptsächlich die Abap und neue Abap-Sprache verwenden, wie das erwähnte Abap RAP. Es ist möglich, unsere bestehende Abap-Software-Engineers auf Abap RAP umzuschulen, wenngleich dies auch nicht das Einfachste ist. Neue Einstellungen haben bei uns hauptsächlich Web-Entwicklungs­hintergrund, der es einfacher macht, die Abap-RAP-Konzeption zu verstehen und anzuwenden.

Färbinger: Sie fahren also zweigleisig?

Edelmann: Ja, S/4 Hana On-prem und Pri­vate Cloud mit Abap und BTP, also klassisches Abap, Abap RAP und UI 5; S/4 Hana Public Cloud mit Abap RAP in der Public Cloud, also Embedded Steampunk und auf BTP, Business Technology Platform, mit Steampunk. Für die Public Cloud haben wir einen pragmatischen Ansatz: BTP und Steampunk sind unsere Go-to-Plattform, für High-Performance-Funktionalitäten gehen wir den Weg des Embedded Steampunk.

Färbinger: Was sind die Herausforderungen und gilt es bei Ihrer Arbeit zwischen On-prem und Cloud zu unterscheiden?

Edelmann: Es sind wirklich zwei unterschiedliche Welten, auch wenn das darunterliegende ERP ähnliche Funktionen und Front-Ends hat. Da wir als pmc America ein sogenanntes Hybridmodell verfolgen – das heißt, wir erwarten, dass unsere zukünftigen Kunden eventuell ein On-prem- und ein Public-Cloud-ERP einsetzen werden –, müssen die Softwarelösungen so konzipiert werden, dass diese entweder in einem hybriden oder reinem Public-Cloud-Modell laufen können. Keiner unserer Kunden wird zwei verschiedene EDI-Lösungen von uns akzeptieren, nur weil er eine hybride ERP-Landschaft hat. Das heißt, wir machen uns viele Gedanken und führen Whiteboard-Sessions mit Software-Engineers und -Beratern durch, bevor wir auch nur eine Zeile Code entwickeln – das gibt dem Thema Design Thinking nochmals eine ganz andere Gewichtung und Bedeutung.

Färbinger: In welchen Industrien sind Sie tätig und was sind die typischen Modifikationswünsche der SAP-Bestandskunden?

Edelmann: Unsere Kunden kommen hauptsächlich aus der weltweiten Automobil­zulieferindustrie mit Schwerpunkt North America und Europa. Für die Zulieferindustrie spielt die Kundenzufriedenheit eine ausgesprochen große Rolle. Daher sind die meisten Modifikationswünsche im Bereich der Kunden-Supply-Chain. Was meinen wir damit? Viele Kunden haben ihre Prozesse mithilfe von IT derart verbessert, um mehr und mehr das ultimative Ziel „Losgröße 1“ zu erreichen. Das heißt dann für unsere Kunden, dass die OEM-Kundenbedarfe zwar nach wie vor per EDI übermittelt werden, aber die darunterliegenden Prozesse und Stammdaten derart komplex werden, dass da ein erheblicher Bedarf an Softwarelösungen entsteht.

Färbinger: Wo gelten diese Herausforderungen?

Edelmann: Das zieht sich dann relativ schnell bis in die Produktion – von Planung bis Exekution – und die dafür benötigten RF-Scanning- und Labeling-Funktionen. Das kann derartige Ausmaße annehmen, dass es da unterschiedliche Prozesse von Warenempfänger zu Warenempfänger gibt. Jede Optimierung bei einem OEM-Kunden hat sofortigen Entwicklungsbedarf bei den darunterliegenden Zulieferern zur Folge – wir sehen das ganz extrem bei den japanischen OEMs Honda und Toyota.

Färbinger: Inwieweit ist die SAP-Vorgabe eines Clean Core eine Herausforderung oder auch hilfreich?

Edelmann: Der Clean Core ist definitiv ein technische Herausforderung und gleichzeitig eine Kundennotwendigkeit, wenn man nicht alle zehn bis fünfzehn Jahre ein massives ERP-Projekt stemmen möchte. Die technische Herausforderung ist mehr oder minder, dass man nicht mehr einfach draufloslegen kann und programmiert. Das fängt bereits damit an, dass der SAP-Berater ein gewisses Fachwissen mitbringen muss, damit die Anforderungen genau verstanden werden, um dem Entwicklungsteam genaue Vorgaben zu machen. Diese Vorgaben müssen vom Entwicklungsteam in kleine Bausteine geteilt werden, damit das in das neue Abap RAP, also Steampunk, hineinpasst.

Färbinger: Ein Paradigmenwechsel?

Edelmann: Die alten Zeiten von ungenauen Spezifikationen und einfach Drauflosprogrammieren mit einer halbwegs ausgebildeten Entwicklertruppe, die lediglich „Code kann“, gehören der Vergangenheit an! Es bedarf eines Umdenkens – Beratung muss Entwicklung verstehen und umkehrt, das heißt, der Skill-Set von beiden Seiten muss sich ändern. Wir nennen das „Business Process Consulting“, die Prozesse müssen verstanden und überdacht werden, damit diese Sinn für den Enduser machen und entsprechend umgesetzt werden können.

Färbinger: Wie gestaltet sich der Datenzugriff auf Hana? Nutzen Sie APIs, SQL-Befehle oder auch Hana-SQL-Spracherweiterungen und Function Calls?

Edelmann: Daten sind das A und O jedes ERP-Systems – ohne Daten keine Prozesse. Das ist natürlich in einer Public-Cloud-­Umgebung ein wundes Thema, da Daten sofort mit Security in Verbindung gebracht werden. Da ist es natürlich nur logisch, dass es momentan nicht ganz so einfach ist, an Stamm- und Bewegungsdaten zu kommen. Wir benutzen momentan freigegebene APIs oder unsere eigenen APIs, um an diese Daten für unsere Softwarelösungen auf der BTP zu gelangen. Die Anzahl der freigebenden CDS Views wächst auch ständig; das gibt einem eine weitere Möglichkeit, an entsprechende Daten zu gelangen.

Färbinger: Gibt es Alternativen?

Edelmann: Ja, da dies bei Weitem nicht ausreicht, haben wir als Ausweg „Custom Business Objects“ – also eigene Kundentabellen – kreiert, die besondere Stammdaten beinhalten, die in noch nicht freigegebenen Tabellen sind. Das bedeutet zwar momentan doppelte Stammdatenwartung; wenn aber richtig programmiert wurde, kann man das relativ einfach später ändern, wenn die Tabellen freigegeben sind. Ich sehe das als eine natürliche Evolution und vergleiche das mit der Situation in R/3 und ERP/ECC, als jede Menge Tabellen und Funktionen hinzukamen und Kundenprogramme entsprechend geändert werden mussten. Es geht eben auf das vorige Thema zurück, dass man nicht mehr blindlings drauflosprogrammieren kann.

Färbinger: Wie würden Sie subjektiv die Funktion der SAP Business Technology Platform einordnen? Ein Hilfsmittel für den S/4-Erfolg oder eine langfristige SAP-Strategie?

Edelmann: Da habe ich eine klare Meinung dazu! Definitiv eine langfristige SAP-Strategie. Ohne ein Tool wie BTP wäre das Ziel Clean Core einfach nicht zu erreichen. SAP selbst nutzt die BTP für spezifische Lösungen, wie Gutschriftverfahren oder Packmittelverwaltung. Ich denke, das Besondere an der BTP ist die relativ einfache Integration mit Public und Private Cloud. Die BTP wird auch nicht mehr als „eierlegende Wollmilchsau“ dargestellt. Es gab mal einen Zeitpunkt, da sah es so aus – zumindest für mich –, dass die BTP mit Microsoft-Azure-Funktionen konkurrieren wollte. Das scheint nicht mehr der Fall zu sein; wir nutzen Azure-­Logic-Apps zusammen mit der BTP und Public Cloud. Die Abap-RAP-Umgebung tut ihr Übriges, damit die BTP ein sehr starkes, einfach integrierbares Entwicklungstool für ihre Kunden bereitstellt.

Färbinger: Kann das Embedded Abap – Steampunk – auf der BTP ein ähnlicher Erfolg werden wie Abap unter R/3 und ECC?

Edelmann: Wir entwickeln seit gut elf Monaten mit Steampunk und Embedded Steampunk. Wie es meine Natur ist, war ich da schon etwas kritisch, ob das alles reibungslos funktioniert. Wir hatten definitiv unsere Anfangsschwierigkeiten – aber wie vorher gesagt waren die mehr oder minder mehr auf der Beratungsseite, die Anforderungen in klaren Entwicklungsschritten darzustellen. Die Entwicklungsteams hatten am Anfang mit Abap RAP „zu kämpfen“, da es eine sehr restriktive Sprache ist. Je mehr wir jedoch unser existierendes Softwareportfolio konvertiert haben, umso einfacher wurde es dann auch – jetzt, nach fast einem Jahr Entwicklung, muss ich sagen, dass sich unsere Teams daran gewöhnt haben und es eigentlich keine Überraschungen mehr gibt oder sich die Frage gestellt wird: Warum geht das denn hier nicht, geht doch in S/4? Es war definitiv eine sehr steile Lernkurve, aber wenn man einmal da ist, ist es „Entwickeln wie früher“.

Färbinger: Wird es ein ähnlicher Erfolg wie R/3 Abap und ERP/ECC – ganz ehrlich?

Edelmann: Das hängt zu 100 Prozent von den SAP-Partnern ab, ob diese willig sind, den Schritt zu gehen, den wir gegangen sind! Es startet mit einem Umdenken auf der Beratungsseite – wenn das geschieht, ist meine Meinung: Ja, es wird ein ähnlicher Erfolg.

Färbinger: Können Sie einschätzen, ob BTP eine Heimat für S/4-Modifikationen sein wird oder etwa die Plattform für ein Composable ERP, also einen S/4-Nachfolger?

Edelmann: Das ist schwer abzuschätzen – aber die Kristallkugel in meinem Büro sagt eher nein. Dazu ist das Thema „gesamtheitliche, integrierte und automatisierte ERP-­Geschäftsprozesse“ einfach zu kompliziert, dass man diese einfach mal auf der BTP replizieren kann. Ich sehe BTP für die Heimat von kundenspezifischem IP. Kunden, die ERP einführen, weil sie einen Mehrwert und Differentiator gegenüber ihren Konkurrenten generieren möchten, können ihr IP, ihre „Secret Sauce“, wie es so schön im Amerikanischen heißt, auf der BTP, weg von den Augen ihrer Konkurrenten, bauen und jederzeit erweitern.

Danke für das Gespräch.

Wenn Sie das Interview im pdf-Format lesen möchten, können Sie es unter folgendem Link herunterladen:

PDF (auf English)