Keine schlechte Idee! Wer fit ist, ist meistens auch attraktiver. Man muss dafür naturgemäß einiges tun und das ist in der SAP-Community häufig mit höheren Lizenzgebühren verbunden.
Das eigene System mit dem Solution Manager fit zu gestalten gelingt nur bedingt, wenn man Standard-Support-Kunde ist. Die dürfen nur einen Bruchteil der SolMan-Funktionen nutzen, womit die Fitness auf der Strecke bleibt.
Enterprise-Support-Kunden haben es besser, die dürfen sämtliche SolMan-Tricks anwenden und erreichen damit wahrscheinlich maximale Innovationsfitness. Auch EhPs (SAP Enhancement Packages) sind gut geeignet für ein ERP-Fitnessprogramm – jedoch nicht immer kostenfrei!
Besonders achtsam sollten SAP-Bestandskunden mit den neuen Funktionen rund um MDM/MDG im Stammdatenmanagement umgehen (Master Data Management und Master Data Governance). Hier gibt es einige Einstellungen, die im Gegensatz zur gelebten Praxis sehr wohl lizenzpflichtig werden können.
Die DSAG/SAP-Wege zur Innovationsfitness sind somit verschlungen und herausfordernd, wahrscheinlich aber ein gutes Geschäft für beide Organisationen. Matthias Kneissl, Geschäftsführer von Q-Partners und intimer Kenner aller SAP-Community-Trends, stand nach den DSAG-Technologietagen E-3 Chefredakteur Peter Färbinger für kritische Fragen zur Verfügung.
Peter Färbinger: Zwei Tage DSAG-Technologietage in Mannheim gemäß dem Motto „Wege zur Innovationsfitness“. Was ist Ihr Fazit, was waren die Schwerpunktthemen?
Matthias Kneissl: Wesentlich für die SAP-Community ist wohl das Thema Hana und In-memory Computing. Nachdem nun auch Hana für die ERP Business Suite freigegeben ist, werden auch alle anderen SAP-Produkte nach und nach umgestellt.
Neben Hana ist natürlich auch Mobilität ein großes Thema für SAP-Bestandskunden. Mit der In-memory-Computing-Technologie und der Mobilisierung von Geschäftsprozessen wächst zusammen, was zusammengehört. Gleichzeitig gewinnen auch die Betriebskonzepte für diese Themen an Bedeutung.
Färbinger: Das heißt also, alle Kunden werden sich umstellen und neu orientieren müssen. Wie beurteilen Sie das, was auf uns zukommt?
Kneissl: SAP betont, dass die Umstellung von NetWeaver auf Hana größer sein wird als der Übergang von R/3 zu NetWeaver. Die Herausforderungen sind zahlreich, angefangen bei der Infrastruktur, an die spezielle Anforderungen gestellt werden.
Das beginnt bereits damit, dass in Zukunft zusätzlich zu einer Zentralinstanz ein Applikationsserver installiert und betrieben werden muss. Parallel dazu ziehen mit dem neuen NetWeaver Stack 7.4 auch neue Technologien in die SAP-Welt ein. Der Workbench Editor, Transaktion SE80, wird in Zukunft weitestgehend mit Eclipse abgebildet.
Färbinger: Also gibt es viel Neues zu lernen?
Kneissl: Ja, passend dazu hat SAP auch gleich eine Schulung für ABAP-Entwickler aufgelegt, um sich mit den neuen Tools vertraut zu machen. Diese neuen Werkzeuge sind notwendig, da auch die kundeneigenen Entwicklungen auf das neue Paradigma Hana angepasst werden müssen.
In-memory Computing ist natürlich nur dann effizient, wenn das Coding so optimiert wird, dass ein Großteil der Berechnung auf dem Datenbankserver stattfindet.
Färbinger: Kann das ein Problem werden?
Kneissl: Hier sehe ich viele kundeneigene Reports und Entwicklungen, die für die neue Technologie angepasst werden müssen, da diese zum Teil ineffizient entwickelt sind und ein Großteil der Berechnungen mit mehrfachen Loops durch interne Tabellen auf dem Applikationsserver stattfindet. Derartige Codings profitieren zunächst von einer Umstellung der Datenbank auf Hana natürlich nicht.
Färbinger: Wie muss sich ein SAP-Bestandskunde eine Umstellung auf ERP mit Hana als Datenbank eigentlich vorstellen?
Kneissl: Interessierte Kunden müssen zunächst ihr SAP-System auf ERP 6.0 EhP6 aktualisieren. Unicode ist natürlich eine zwingende Voraussetzung für den Einsatz der HanaDB.
Nur von diesem Softwarestand aus kann eine Umstellung erfolgen. Im Anschluss daran erfolgt eine Datenbankmigration. Selbstredend ist natürlich, das SAP Coding für die neue Datenbanktechnologie mit dem NetWeaver Stack 7.4 anzupassen.
Für das kundeneigene Coding gilt dies nicht – mit dem neuen ABAP Editor auf Basis von Eclipse können Entwickler ineffiziente Programmabläufe identifizieren und adaptieren.
Man darf jedoch nicht vergessen, dass kundenindividuelle Reports nicht ohne größere Aufwände neu entwickelt werden können. Oftmals fehlt die Dokumentation oder ergibt sich nur aus dem Coding. Tests müssen ebenfalls neu erfolgen.
Färbinger: Ist da in den vergangenen Jahren einiges falsch gelaufen?
Kneissl: In der Softwaretechnologie geht man davon aus, dass Coding degradiert, also regelmäßig auf einen aktuellen Stand gebracht werden muss. Viele Kunden haben in der Vergangenheit aber eher in Hardware, schnellere CPUs und neue Rechnergenerationen investiert anstatt in die Überholung und Re-Implementierung von kundeneigenen Entwicklungen.
Gleichzeitig gilt es die ABAP-Entwickler für die neue Technologie zu schulen und auf die neuen Entwicklungsrichtlinien aufmerksam zu machen.
Färbinger: Was können Sie vom Sorgenkind der Community, dem Solution Manager, berichten?
Kneissl: Im SolMan-Umfeld gab es wenig Neues. Die Support Package Stacks, die in den vergangenen Monaten seitens der SAP auf den Markt kamen, müssen nun von den Kunden angenommen werden. Es gibt sicherlich noch viele, die auf den Solution Manager 7.0 aufsetzen und noch kein Upgrade geplant haben, obwohl Ende 2013 die Wartung ausläuft.
Färbinger: Ist das Neue besser?
Kneissl: Der Solution Manager 7.1 bietet mit aktuellen Support Packages auch die notwendigen Betriebskonzepte, um die neuen Technologien effizient zu überwachen. Schade ist jedoch, dass viele neue Funktionen in der Version 7.1 ausschließlich SAP-Enterprise-Support-Kunden vorbehalten bleiben.
Färbinger: Gibt es ein Beispiel?
Kneissl: So ist aktuell die neue Monitoring und Alerting Infrastructure, MAI, für Standard-Support-Kunden nicht verfügbar. Dies bedingt, dass ein PI- oder BusinessObjects-Monitoring durch den SolMan nur eingeschränkt verfügbar ist.
Kunden mit Standard Support müssen daher auch im Solution Manager 7.1 aus lizenzrechtlichen Gründen weiter auf ein klassisches CCMS-Monitoring mit Autoreaktionsmethoden setzen.
Auch im Change Request Management, ChaRM, müssen Standard-Support-Kunden einige Abstriche hinnehmen und auf Retrofit oder die Verwaltung von Non-SAP Changes verzichten.
Färbinger: Klar, dass die SAP hier wieder einmal versucht, Standard-Support-Kunden im Regen stehen zu lassen. Wie werden denn die neuen SAP-Themen durch die Community wahrgenommen?
Kneissl: Das Thema Hana hat sich noch nicht flächendeckend herumgesprochen. Ich erinnere mich an eine Teilnehmerin in einer Session, die mich gefragt hat, ob es sich bei Hana um ein Betriebssystem handelt.
Die Technologie spricht für sich, nicht umsonst würden wir als Beratungshaus bereits auf Hana setzen und für uns selbst ERP auf Basis der HanaDB einführen. Es ist natürlich nun eine große Aufgabe für SAP, die Kunden umfassend zu informieren, sodass diese das notwendige Know-how haben, um einen Betrieb sicherstellen zu können.
Färbinger: Wie sieht denn die künftige Frontend-Strategie aus, werden Kunden immer noch mit den gleichen, altbackenen und unhandlichen Oberflächen geplagt?
Kneissl: Nein, die Frontend-Strategie ändert sich, insbesondere auch mit dem Thema Mobile. SAP setzt weitgehend auf HTML5 mit dem SAPUI5 Development Framework. Ziel ist es, Oberflächen generisch für verschiedene Endgeräte und Applikationen zu entwickeln – Internet Explorer, iPhone, Android, iPad.
Der NetWeaver Business Client ist der strategische Nachfolger von SAPGUI, da er die Zugriffe auf Frontend-Technologien wie die klassische ABAP-Oberfläche, WebDynpros und HTML-Oberflächen vereint. Gleichzeitig können dem Benutzer einer klassischen Transaktion über die sogenannten Sidepanels analytische Informationen zur Verfügung gestellt werden.
Vor Hana war dies noch undenkbar. Ein klassisches Beispiel ist hierfür etwa, die Umsatzstatistik eines Kunden im Sidepanel zu sehen, während in der VA01 ein Kundenauftrag erfasst wird.
Färbinger: Die altbackene ABAP-Oberfläche mit SAPGui wird also durch neue Technologien ersetzt. Wie sollten sich nun SAP-Kunden strategisch in Hinblick auf Frontend-Entwicklung ausrichten?
Kneissl: Generell sollte bei größeren Entwicklungsprojekten stets geprüft werden, mit welchen Frontends die Funktionalität verwendet werden soll. Die ABAP-Oberfläche mit den klassischen Dynpros war jedoch immer in der Entwicklung limitiert und die Entwicklungsaufwände standen noch nie im Verhältnis zum Nutzen.
Mit WebDynpro für ABAP und dem darauf basierenden Floor Plan Manager (FPM) stellt SAP eine Technologie bereit, die webfähig ist, aber auch in der Entwicklung als schwergewichtig und aufwändig gilt.
Für Transaktionen, die von Gelegenheitsbenutzern, gegebenenfalls auch auf unterschiedlichen Frontends verwendet werden, sollte auf HTML5 mit dem SAPUI Development Toolkit gesetzt werden.
Färbinger: Die SAP ist nicht unbedingt für schnelle Patch-Zyklen bekannt. Gerade die HTML-Technologie wandelt sich rasend schnell. Besitzen wir hier eine neue Technologie, auf die wir in den nächsten 20 Jahren in der aktuellen Art und Weise setzen müssen?
Kneissl: No, no es así. SAP proporcionará SAPUI5 como su propio componente adicional para la importación a través de SAINT. A diferencia del clásico ciclo de parches, las actualizaciones se planifican trimestralmente.
So können auch Kunden, die ihren Support Package Stack nur verhalten aktualisieren, weil sie intensive Tests fürchten, dennoch auf eine aktuelle Oberflächentechnologie setzen.
Färbinger: Herzlichen Dank für das Gespräch.
DE
EN
ES
