Mit S/4HANA zurück zum SAP Standard? – mit Ingo Biermann

…zum Anschauen

YOUTUBE-CHANNEL abonnieren: https://www.youtube.com/c/Rz10De_ms

…zum Hören

Für unterwegs – den Podcast abonnieren: https://rz10.de/podcast

…zum Lesen

Was ist der SAP Standard überhaupt?

Typische Beraterantwort: Es kommt drauf an! Es gibt verschiedene Definitionen vom SAP Standard. SAP ist Standardsoftware. Die Unternehmen versprechen sich davon, nicht alles von der Pike auf selbst entwickeln zu müssen, sondern auf Best Practices zurückgreifen zu können. Da geht es dann schon los und wird irgendwo unklar.

Als Standard gilt unter anderem der Standard im eigenen Unternehmen. Ein größeres Unternehmen oder ein Konzern hat vielleicht einen Standard, wie dort gewisse Dinge im SAP abgebildet werden wie beispielsweise ein Bestellanforderungsprozess. Der soll im gesamten Unternehmen gleich laufen. Da ist nicht unbedingt ein SAP-SE-Standard aus Walldorf, sondern der Standard, wie das Unternehmen es im SAP-System gerne machen möchte.

Dann gibt es den SAP Standard, wie er ausgeliefert wird. Darunter fallen alle Möglichkeiten, die man im SAP-System erzeugen kann, nur rein mit Customizing. Beispiele für solche Konfigurationsmöglichkeiten sind: Welche Auftragsarten es gibt und was die für Auswirkungen auf den jeweiligen Beleg haben. Welche Konditionen sind darin möglich? Alles Konfigurationsmöglichkeiten, die SAP bei der Entwicklung dieses entsprechenden Moduls sich vorgenommen hat. Solange jedoch nichts programmiert wird, befinde ich mich im SAP Standard.

Die Best Practices gibt es bei der SAP auch zum Herunterladen.

SAP hat später Best Practices veröffentlicht. Die sind eine Art Untermenge von diesen Kombinationsmöglichkeiten ohne Programmieren. Also eine Empfehlung, wenn ihr das machen wollt, was vielleicht alle machen: Wie solltet ihr das tun? Wie kann man den Bestellanforderungsprozess umsetzen? Die Best Practices gibt es bei der SAP auch zum Herunterladen. Man dann danach recherchieren und sich durchklicken und den Best Practice für S/4HANA Cloud für das ERP finden und sich anschauen. Was dann als eine besondere Einschränkung des SAP-Standards vielleicht für einen passend ist.

Dadurch ergeben sich drei Definitionsvarianten des SAP Standard: Das, was SAP ausliefert. Das, was man anpassen kann – ohne dass man irgendwas ändert. Und das, was SAP vielleicht auch mal an Kombinationen von Einstellungen gibt, quasi die Empfehlung des Hauses.

Was ist der Nichtstandard und wieso wollen Unternehmen (zurück) zum SAP Standard?

Der Nichtstandard ist, jeweils von allen drei Definitionsvarianten, die Abweichung davon. Also entweder, ich habe unheimlich viele Sonderlocken “dranprogrammiert”. Oder Schnittstellen zu Systemen, dass ein Prozessteil außerhalb läuft und wieder zurückkommt. Oder viel unterschiedliche Add-Ons von Drittherstellen. Das wäre auch Nicht-am-SAP-Standard-sein.

 Zum Problem wird das, wenn man es übertrieben hat

Der Nichtstandard ist im ersten Moment immer super, weil man sich so individuell anpassen konnte. Das ist natürlich auch der Grund für den Erfolg vom R/3, vom ERP und auch von S/4HANA, dass es die Möglichkeit gibt. Zum Problem wird das, wenn man es übertrieben hat und jedes Mal eine Erweiterung dranprogrammiert hat. Das führt dann zu schwieriger Wartbarkeit. Kosten erhöhen sich, um das System am Laufen zu halten. Bei der nächsten Erweiterung muss man alle Erweiterungen von davor wieder mitbenutzen. Dann das Thema Update, Upgrade: Bin ich da noch konform?

Für die einzelne Erweiterung will man eigentlich nicht beim SAP Standard sein. In der Gesamtsicht und aus Perspektive der Architektur und Strategie wäre man lieber wieder beim Standard und hätte nicht so viele Programmierungen.

Einheitlichkeit spricht für den SAP Standard

Es gibt gute Gründe, wieso man zum Standard will: Weil der Betrieb des Systems und die Datenqualität dann besser laufen. So ist es dann mit diesem Teil Entwicklung und Programmierung. Der Teil, dass man unternehmensweit standardisiert sein will, liegt auch schon auf der Hand: Denn wenn Abteilung 1 und Konzern/Unternehmen 2 da irgendwie anders vorgehen, wird der Support viel komplizierter. Passen diese Prozesse am Ende zusammen? Auch ein Grund, warum ich eine Standardisierung haben möchte: Einheitlichkeit.

Zum SAP Standard, damit wir auf S/4HANA gehen können. Wie hängt das zusammen?

Im ersten Moment hängt es aus einer IT-Strategie-Sicht gar nicht zusammen. Selbstverständlich kann ich ein Projekt ausrufen, »Zurück zum SAP-Standard!« Wir bauen Sachen zurück, die wir mal als Wildwuchs haben. Das ist ein schönes Projekt. Das ist nicht aus der Luft gefriffen, sondern aufgrund von Schmerzen wie Wartbarkeit, Daten nicht vergleichbar und so weiter. Genug Schmerz aufgebaut, um so ein Projekt zu machen.

Damit bekommen wir zur Hälfte ein bisschen die Berechtigung dafür, das zu machen.

Das S/4HANA-Migrationsprojekt wird relativ häufig benutzt als Vehikel, um zu sagen, zurück zum Standard ist jetzt eine hervorragende Idee, denn wir müssen ja sowieso an das System. Wir müssen ein paar Prozesse anschauen. Wir machen eine Migration. In diesem Zuge nehmen wir verschiedene Sachen mit auf den Zettel. Zurück zum Standard ist ein Ziel unseres S/4HANA-Projekts. Damit bekommen wir zur Hälfte ein bisschen die Berechtigung dafür, das zu machen. Und zur anderen Hälfte, natürlich, mit S/4HANA kommen auch neue Standards und Prozesse. Es macht in gewisser Weise dann Sinn, das zu machen. Aber es ist nicht hundertprozentig zwingend, ein Prozess-Redesign oder eine Art »Zurück zum Standard« zu machen.

Was bringt S/4HANA für Möglichkeiten?

Viele interessante Features sind mit S/4HANA neu und möglich. Darunter fällt zum Beispiel Embedded Analytics. Also die Möglichkeit, operatives Reporting auf den Daten mit richtiger Performance und einem extra dafür vorgesehenen Datenmodell direkt in S/4HANA zu machen. Dann nutze ich in S/4HANA diesen Standardmechanismus und obendrauf die von SAP ausgelieferten Standard Reports für Embedded Analytics – die analytischen Apps und die vorgefertigten Queries.

Solche Auswertungen auf Embedded Analytics in S/4HANA zu heben, was vorher im ERP nicht möglich war, wäre genauso ein Beispiel. Der programmierte Report funktioniert (in der Regel) auch in S/4HANA und es ist deswegen nicht zwingend, da auf diesen anderen Standard zurückzugehen.

Wie finde ich heraus, was geht und was nicht?

In der Vorbereitung des S/4HANA-Migrationsprojekts stellt man fest: Prozessoptimierung ist eines unserer Ziele. Wir wollen nicht nur so schnell wie möglich durch. Dann eine Phase einzuplanen, in der man Prozessanalyse und Process Mining macht. Mit den Ergebnissen dann eine Schwerpunktsetzung in den Gap-Workshops zu machen.

Ein Fit würde bedeuten, mit der zukünftigen Lösung zufrieden zu sein.

Bei einer Fit-Gap-Analyse schaue ich auf mein jetziges ERP-System. Ich schaue mir an, was macht S/4HANA daraus? Ein Fit würde bedeuten, mit der zukünftigen Lösung zufrieden zu sein. Vielleicht kann ich da meinen individuellen Prozess weiterverwenden. Oder der Standardprozess ist weiterhin ein Standardprozess und ich kann das weiter nutzen, ohne dass ich dort was tun muss. Ein Gap ist, was man nicht haben möchte. Zum Beispiel: »Da hatte ich ja direkt auf die Kreditoren geschrieben und für den Geschäftspartner ist das jetzt nicht mehr möglich«. Dann habe ich einen Gap gefunden und muss dafür eine Lösung suchen.

Process Mining kann mir außerdem dabei helfen, Prozesse zu finden, die optimierbar sind. Und Nuancen zu finden, die ich in meinen bestehenden Prozessen nicht sauber abgedeckt habe. Das gibt es in verschiedenen Abstufungen. Allein der S/4HANA Readiness Check, den jeder kostenfrei durchführen kann, hat so ein paar Ansatzpunkte. Dabei werden aufgrund der Usage-Statistik zum Beispiel Fiori-Apps vorgeschlagen.

Wie kann ich mich selber schlau machen?

Das Austesten und Vorführen der Fiori-Standard-Apps ist relativ einfach möglich. Auch in nicht S/4HANA-SAP-Systemen gibt es bereits Fiori-Apps, wenn es erst einmal um die Oberfläche geht. Die Schritte, die man da machen kann: Sich in der Library von der SAP einige relevante Fiori-Apps raussuchen. Dann customizen, damit sie auf dem Launchpad erscheinen. Dann dem Fachbereich mal geben zum Ausprobieren.

In einem halbtägigen Workshop erhält man mal einen Einblick, welche Schritte zu machen sind

Diese Schritte sind vergleichsweise einfach und funktionieren am Besten auf einem unabhängigen Sandbox-Spielsystem. Von der mindsquare aus bieten wir wahlweise auch unseren Crashkurs Fiori Standard Apps an. In einem halbtägigen Workshop erhält man mal einen Einblick, welche Schritte zu machen sind, um einfach mal so ein paar SAP-Fiori-Standard-Apps anzuschauen. Daran sieht man eigentlich, wie kompliziert – oder auch nicht – das ist.

Fazit

Mit S/4HANA zurück zum Standard geht nicht von alleine, es ist kein Automatismus. Man muss auch tatsächlich wollen und es auf die Agenda setzen. Dennoch kann S/4HANA dabei helfen, weil nun auch mehr Features da sind im Vergleich zu vor zehn Jahren.

Man kann auch zum SAP-Standard zurückkehren, ohne auf S/4HANA zu gehen, wenn ich das will. Mit Fit-/Gap-Analysen finde ich bei einem anstehenden Projekt heraus, wie weit ich von meinem Zielzustand entfernt bin. Dabei kann Process Mining mir helfen, Dinge zu finden, bei denen es sich besonders wichtig ist Chancen und Risiken abzuwägen. Und um vielleicht auch Sachen zu finden, die ich in meinen bestehenden Prozessen noch gar nicht so richtig sauber abgedeckt habe.

Und es hilft die ehrliche Einschätzung, dass man an manchen Stellen auch ein bisschen ausprobieren muss und sich am Besten die Sache selber ansieht, ob das neue System, der “neue Standard”, an diesen Stellen erstrebenswert ist.

Danke an Ingo Biermann für das Gespräch. Mit Ingo Biermann vernetzen: linkedin |  xing

Wenn Sie Fragen oder Beratungsbedarf zu dem Thema haben, schreiben Sie uns gerne eine Mail an info@rz10.de. Zum Thema S/4HANA haben wir auch viele Webinare und Schulungen.