Hin und wieder kommt es vor, dass wir mit einer Frage seitens unserer Kunden konfrontiert werden, die da lautet "Was ist eigentlich der SAP Standard?", oder "Wie beurteile ich für mein Unternehmen, ob ich im SAP Standard unterwegs bin?" oder, oder, ... So auch vor einigen Wochen im Zuge eines Kundengesprächs.
Das bot mir den Anlass, meine Sicht auf diese Frage einmal schriftlich in diesem Blog darzulegen, in der Hoffnung, viele Kolleginnen und Kollegen und Kunden- und Partner-Angestellte mögen dem Folgen und diese und ähnliche Fragestellungen hiermit beantwortet sehen.
Also, gehen wir es an:
Unter welchen Umständen bewegt sich ein Versorgungsunternehmen im SAP Standard?
Zurückblickend auf über zwanzig Jahre berufliche Praxis bei SAP in diversen Rollen (aber immer in der Versorgungswirtschaft) komme ich zu dem Schluss, dass es zur Beantwortung dieser Frage ein paar Indizien gibt, die jedes für sich und alle in Summe als Gradmesser dafür dienen können, die Antwort auf die Frage mit einer Orientierung zu versehen.
Es geht dabei nicht darum, eine genaue Maßzahl für den Grad der SAP-Standard-Nutzung eines Unternehmens zu ermitteln, es geht um die qualitative Orientierung, ob man sich im oder wenigstens nahe beim Standard bewegt.
Das (Versorgungs-)Unternehmen verwendet SAP Standardsoftware, und natürlich insbesondere unsere Lösung SAP S/4HANA Utilities
Es liegt auf der Hand: Ein Unternehmen, das gänzlich auf SAP Software verzichtet, kann sich nicht innerhalb eines wie auch immer gearteten SAP-Standards bewegen. Was auch auf der Hand liegt: Nicht für alle Anwendungsfälle eines Unternehmens gibt es Software aus dem Hause SAP. Aber eben für vieles.
Aus meiner - zugegeben etwas einseitigen - Perspektive kommt es bei der Bewertung der Fragestellung also darauf an, wieviele der möglichen mit SAP Standard-Software unterstützbaren Unternehmensfunktionen tatsächlich durch Lösungen aus unserem Portfolio bedient werden.
Für die Versorgungsindustrie würde man ergo unterstellen, dass das Unternehmen bei Nutzung von SAP S/4HANA für die industrieagnostischen Kernfunktionen und von SAP S/4HANA Utilities für die industriespezifischen Prozesse schon ganz gut dabei ist.
Dass da noch mehr geht - CX, Reporting, HR ... - versteht sich. Klar ist: je mehr SAP-Flavour, desto besser im Kontext der Fragestellung. Je mehr Lösungen aus dem SAP Produkt-Portfolio in Nutzung sind, desto größer ist die Bewegung des Unternehmens im SAP Standard.
Nun, dieses Indiz ist einfach zu offensichtlich.
Verwendung neuester Releases bzw. regelmäßiges Patchen
Wenn ich im vorherigen Absatz vom "SAP S/4HANA" schreibe, dann hat das etwas mit diesem zweiten Abschnitt zu tun. Natürlich spielt der aktuelle Release-Stand beim Versorgungsunternehmen eine Rolle, wenn man beurteilen will, ob sich das Unternehmen im SAP Standard bewegt.
Zwar sind auch ältere Release-Stände SAP-Standard. Aber wenn es um graduelle Differenziertheit geht, dann eben nicht ein ebenso guter SAP-Standard wie das neueste Release.
Genau hierhin gehört dann natürlich auch die Frage SAP ECC versus SAP S/4HANA. Beides ist SAP Standard. Und dennoch ist es besser sich im SAP S/4HANA bzw. SAP S/4HANA Utilities zu bewegen als im SAP ECC, wenn es um die Beantwortung der obigen Frage geht.
Und es liegt auch auf der Hand, dass ein aktueller Release-Stand nur mit regelmäßigen (und hoffentlich zeitnahem) Einspielen von Support Packages einhergehen muss. Je aktueller die Systeme sind, desto besser im Kontext der Fragestellung.
Und ich schreibe jetzt ganz bewusst hier nichts in Bezug auf ein avisiertes Ende der Wartung älterer Versionen und Releases. Natürlich nicht.
Auch dieses Indiz ist noch recht einfach.
Grad der Modifiziertheit der Standardsoftware
Die meisten Versorgungsunternehmen, die unsere Kunden sind, sind dies seit vielen Jahren. Sie kommen also aus der Zeit der on-premise Installation der SAP Systeme in kunden- oder provider-eigenen Rechenzentren. Eine besondere Eigenschaft der SAP Software dieser Zeit war (und ist) die Möglichkeit als Anwenderunternehmen Veränderungen an der Software vornehmen zu können. (Ich gehe soweit zu behaupten, dass die SE80 in der Kombination mit Entwicklerschlüsseln etwas Historisches darstellt. Aber damit schweife ich ab.)
Diese Möglichkeit eröffnete seinerzeit einen Weg sich als Unternehmen graduell vom SAP Standard zu entfernen, ohne ihn hoffentlich ganz zu verlassen (Dies würde einen Systemzustand voraussetzen, der keine aktive Codezeile mehr kennt, die im Hause SAP geschrieben wurde). Manch einer mag jetzt denken, na ja, sooo schlimm ist das mit den Modifikationen ja nie.
Das mag sein, es geht auch nicht um schlimm oder nicht schlimm. Es geht nur um die Beurteilung der Frage, ist man als Unternehmen im SAP Standard unterwegs, und wenn ja, in welchem Maße. Inwiefern das Maß dann als schlimm oder noch als weniger schlimm empfunden wird, hängt am Betrachter.
Es liegt natürlich auf der Hand, je weniger Modifikationen existieren, desto besser im Kontext der Fragestellung.
Auch einfach, nur manchmal besteht Verwechselungsgefahr, aber das kommt sofort.
EINSCHUB / EXKURSION
Das Ergebnis von Modifizierbarkeit der Standard-Software von SAP wird (leider allzugern und viel zu) häufig mit der Erweiterbarkeit der Lösungen gleichgesetzt oder verwechselt oder einfach nur nicht scharf genug getrennt verstanden. Und auch Eigenentwicklungen kommen terminologisch in diesem Zusammenhang oft unter die Räder
Daher muss ich hier noch einmal unmissverständlich klarstellen. Es gilt
Erweiterung ≠ Modifikation
Modifikation ⊂ Eigenentwicklung
In Worten: Erweiterungen sind keine Modifikationen und vice versa. Und Modifikationen sind eine Teilmenge der Eigenentwicklungen aber Modifikationen sind nicht dasselbe wie Eigenentwicklungen.
Daher hier gern ein paar persönliche Definitionen, die mit voller Absicht sehr einfach gehalten sind:
Erweiterungen sind kundeneigener Code, der das Systemverhalten an Kundenbedürfnisse anpasst und der in dafür seitens SAP vorgesehenen Erweiterungsstellen implementiert wird.
Modifikationen sind (kundeneigener Code und gleichzeitig) Veränderungen des von SAP ausgelieferten Codes, der zu Veränderungen am SAP-Standard-Systemverhalten führt.
Eigenentwicklungen sind auf dem System als Entwicklungsumgebung implementierte größere kundeneigene Software-Lösungen die mit der Zielsetzung vorgenommen werden, im SAP Standard nicht vorhandene Funktionalität zu ermöglichen (Füllung von Lücken im Standard). Sie sind natürlich auch kundeneigener Code.
Insofern sind Modifikationen sehr wohl Eigenentwicklungen (auch sie müssen ja irgendeine Lücke füllen, die nicht gefüllt war, sonst würde man es ja nicht tun), und gleichzeitig sind sie eben nicht dasselbe wie Eigenentwicklungen, denn diese sind in aller Regel genau eines nicht: Modifikationen.
Nutzung vorgesehener Erweiterungsoptionen
Erweiterungsoptionen (ihre Geschichte ist lang und es gibt verschiedene Ausprägungen in Form von Exits, Events, BAdi's ...) sind dafür gedacht und vorgesehen, um regionale oder kundeneigene Anpassungen an das Systemverhalten vornehmen zu können, sie werden auch von Seiten SAP verwendet und durchaus, zum Beispiel für regionale oder lokale Besonderheiten, auch von SAP implementiert. Sie sollen gerade für Anpassungen an Markt- oder eben Kundenbedürfnisse genutzt werden. Insofern sind sie eines gerade nicht: nämlich Modifikationen.
Der Nutzungsgrad vorgesehener Erweiterungsoptionen sagt per se also nichts im Hinblick auf die Fragestellung. Wer konsequent Erweiterungsoptionen nutzt, bekommt also keinen Malus im Sinne des Sich-im-Standard-Bewegens.
Malus könnte gegeben werden, wenn die vorgesehenen Erweiterungsmöglichkeiten in einer Weise genutzt werden, die ihren Daseinszweck missachten (das sollte nur höchst selten der Fall sein - habe ich aber selbst in Kombination mit krudem Customizing selbst mindestens einmal in 20 Jahren gesehen) oder bei denen die Art und Weise der Implementierung der Erweiterung (das Wie!) einem erfahrenen Entwickler aus dem Hause SAP aus ästhetischen Gründen das Fürchten lehren würde - aber ich schweife ab.
Nicht vorgesehene, aber vorhandene Möglichkeiten
Malus sollte es geben, wenn Möglichkeiten der Systemnutzung zur Anwendung kommen, die dafür sorgen das ausgelieferter (und von SAP gewarteter) Code beim Kunden gar nicht durchlaufen wird, weil man dafür gesorgt hat, ganze Applikationsbereiche zu kopieren und in der Applikation statt des Originals die Kopie durchläuft. So schneidet man sich von der Wartung durch SAP ab und muss bei Fehlern seine Kopie selbst warten. So etwas muss natürlich einen Malus im Sinne der Fragestellung geben.
Bei Eigenentwicklungen: Die konkrete Implementierung - das Wie
Ich hatte oben schon angedeutet: die SE80 und die Möglichkeit Eigenentwicklungen vorzunehmen ist in meinen Augen etwas ganz besonderes. Es ermöglicht (Partnern und Kunden), echte Eigenentwicklungen vorzunehmen, also Lücken zu füllen, die im SAP Standard existieren (können). Dies kann notwendig sein, insbesondere wenn es besondere Business Anforderungen gibt, die einzigartig sind und genau aus diesem Grund keinen Einzug in den SAP-Standard erhalten haben.
Dann war es unter SAP ECC (und ist es unter SAP S/4HANA on Prem) möglich, dass SAP System als Plattform zu nutzen und eigene Applikationen zu erstellen. Partner, aber auch Kunden, konnten auf diese Weise sogenannte Addons als ergänzende Software erstellen die auf einem zugrunde liegenden SAP Standard Release lauffähig ist und die als Software-Produkte firmieren.
Selbst bei SAP wurde (und wird) diese Erweiterungs-Fähigkeit genutzt, um Addons bspw. für regionale Anforderungen in das Produkt-Portfolio zu integrieren (zum Beispiel die regulatorischen S/4HANA Addons oder die ältere IDEX-Produktfamilie auf SAP ECC).
Dabei kommt es - wie in vielen anderen Situationen - auf das Wie an. Wie sind die Addons geschrieben? Folgen sie einem sap-standard-nahen Programmiermodell? Nutzen sie analog zu SAP-Standard-Software Parameterisierungs-Fähigkeiten wie man das aus dem SAP Customizing-Leitfaden kennt? etc. pp.
Sauberer Code ist einfacher wartbar als ... nun ja, Sie wissen, was ich meine.
Wenn man über Eigenentwicklungen spricht kommt es auch auf die dann bei Partnern bzw. den Kunden liegende Wartungsverantwortung an.
Hier geht dann darum, ob und inwieweit Prozesse implementiert sind und Werkzeuge verwendet werden, die den Software-Lebenszyklus unterstützen. Nutzt ein Kundenunternehmen Eigenentwicklungen, die sauber entwickelt und mit Software-Lebenszyklus-Prozessen und entsprechenden Werkzeugen gewartet werden, ist im Sinne der Fragestellung kein Punktabzug zu erwarten, aber wehe, wenn nicht. 😉
Eigenentwicklungen/Erweiterungsmöglichkeiten versus "Clean Core"
Heute, mit SAP S/4HANA und SAP S/4HANA Utilities und deren verschiedenen Deployment-Modellen, taucht der Anspruch des "Clean Core" auf und wächst zum Paradigma heran.
Software-Deployments, die identisch für viele Kunden sind, vertragen gemeinhin keine durch Kunden-Code herbeigeführte Verhaltensänderungen für einzelne Kunden. Das Paradigma "Clean Core" schlägt also in Public-Cloud Editionen mit aller Macht zu. Erweiterungen im System durch Code ist unmöglich geworden.
In den Private-Cloud Editionen ist eine gewisse Nachsicht vorhanden, sind doch die einzelnen Deployments in diesen Fällen direkt einem einzelnen Anwenderunternehmen zugeordnet. Das Systemverhalten auf diesen Kunden zuschneidbar zu erhalten, tut dem Ganzen keinen Abbruch. Vorgesehene Erweiterungsmöglichkeiten sind hier also weiterhin vorhanden. Was aber hier dem Paradigma des "Clean Core" ebenfalls folgt, ist der Ausschluss von Eigenentwicklungen auf dem private cloud System. Eigenentwicklungen sollen unter einer Private-Cloud Edition nicht mehr im SAP S/4HANA oder SAP S/4HANA Utilities erfolgen.
Was tun, wenn dennoch Eigenentwicklungen notwendig sind
Sollten mit einer im Einsatz befindlichen private cloud Editionen von SAP S/4HANA und/oder SAP S/4HANA Utilities dennoch Notwendigkeiten für eigene Entwicklungen entstehen, so verbieten wir diese nicht grundsätzlich, sie müssen jedoch - eben anders als bisher - außerhalb von SAP S/4HANA und SAP S/4HANA Utilities erfolgen. Wenn dies unter Zuhilfenahme der SAP Business Transformation Platform erfolgt, ist das Anwenderunternehmen wieder sehr tief im SAP-Standard unterwegs.
Wer heute bei SAP S/4HANA und SAP S/4HANA Utilities immer noch die On-Prem-Edition im Einsatz hat, hat zwar noch alle Freiheiten wie weiter oben beschrieben (also sowohl Erweitern, als auch Eigenentwicklung, sogar Modifikationen sind möglich).
Es liegt mir aber persönlich am Herzen, Ihnen folgendes nahe zu legen
Verfahren Sie doch analog zu jenen Kunden, die eine Private Cloud Edition verwenden
- Packen sie die Gelegenheit beim Schopf und nutzen das "Clean Core" Paradigma zu Ihrem Vorteil:
- Legen Sie Eigenentwicklungen neben das System,
- am Besten natürlich auf die SAP Business Transformation Platform.
- Dann sind sie selbst als On-Prem-Verwender mit einer Architekturvariante analog der Private Cloud immer noch im SAP Standard.
Der Riesenvorteil entsteht dann, wenn sie mit Ihrem On-Prem-System irgendwann einmal doch in eine Private-Cloud-Welt umsteigen wollen. Das ohnehin immer dünne Budget der Zukunft wird sich freuen 😉.
Wer an Diskussion interessiert ist: die Kommentarfunktion im Blog ist genau dafür gemacht.
Wer direkt mit mir in Kontakt treten möchte: Gerne per DM auf LinkedIn an Gerald Galka - Der Utilitiesenthusiast
- SAP Managed Tags:
1 Comment
