Geschäftsprozesse sind das Herz des Unternehmens. Sie organisieren das Chaos. Sie unterliegen beständiger Anpassung an geänderte Kundenbedürfnisse. Sie sorgen für Spaß an der Arbeit - oder für Frust, wenn sie nicht richtig funktionieren. Ihre Performance ist messbar, und durch ihre Optimierung kann ein Unternehmen viel Geld sparen (dazu mehr im RealBlog zum Thema „Process Mining). Grund genug also, sich ganz prinzipiell intensiver mit ihnen zu beschäftigen. Theoretisch ist dies unzweifelhaft, aber wie sieht´s damit in der Praxis aus? Schwierig, würde ich sagen. Viel zu präsent sind in der Ecke verstaubte Orga-Handbücher und Aris-Modelle, die schon 2 Wochen nach ihrer Erstellung überholt sind. Größere Unternehmen leisten sich schon mal eine Abteilung „Prozeßorganisation“, nur um dort all diejenigen Themen auszuparken, die woanders nicht reinpassen. Kein Wunder also, daß selbst die Existenz eines solchen Unternehmensbereiches kein Garant für ein existierendes und vor allem aktuelles Geschäftsprozeßmodell ist. Der Laden läuft ja – irgendwie – warum sollte man sich also kümmern?

Das Problem ist nur: die Geschäftsprozesse leben. Sie werden täglich genutzt. Sie werden angepaßt, geändert, erweitert. Neue Funktionalitäten und Abläufe werden benötigt, Prozesse entlang der Wertschöpfungskette verknüpft. Und da das alles meist IT-gestützt abläuft, schlagen diese Themen relativ rasch bei der IT auf. Hier schraubt dann jemand eine Erweiterung dran; dort fixt jemand einen Fehler durch Anpassungen im Customizing. Und alle paar Wochen werden Change Requests in Form von Releases eingespielt. Pflichtgemäß stellt sich hier die Frage nach der Dokumentation… …und trifft auf das reale Leben im Unternehmensalltag: Dokumentation ist Glückssache. „Musste schnell gehen…“, „weiß schon, was ich wo getan habe“ sind noch die einfachsten Ausreden. Und wenn dann noch unterschiedliche Parteien mit unterschiedlichen Aufgaben am Start sind (bspw. bei externer Application Maintenance), wird´s ganz bunt, sprich die Dokumentation von Prozeßveränderungen, wird, sofern sie überhaupt erfolgt, zu einer dezentralen Veranstaltung, bei der niemand das große Ganze mehr kennt. Im Ergebnis versumpfen die Geschäftsprozesse, Wildwuchs gewinnt Raum, und die Sache wird zunehmend undurchsichtig. Ganz wie beim häuslichen Garten, den man auf Jahre hin ohne Pflege der Natur überlässt. An ein Durchkommen ist irgendwann nicht mehr zu denken. Wenn wir ehrlich sind, ist das die Realität bei vielen Unternehmen. Höchste Zeit also, den Laden einmal gründlich zu entrümpeln.

Doch warum gerade im Kontext einer S/4HANA-Transformation?

 Meine Gegenfrage: wenn nicht dann, wann sonst? Ob Greenfield- oder Brownfield-Herangehensweise macht keinen Unterschied: der Wechsel von SAP ECC (oder irgendeinem anderen ERP-System) nach S/4HANA ist definitiv KEIN Wechsel auf ein neues Release. S/4HANA ist eine komplett neue Softwaregeneration, die auf die Anforderungen des technologischen Wandels in Form der Digitalisierung und Automatisierung aller Geschäftsbereiche abgestimmt ist. Für die SAP war dies der Anlaß, die Software von Altlasten zu befreien, quasi die Hütte aufzuräumen. Und wenn das schon für SAP galt, dann sollte es noch vielmehr für all diejenigen Unternehmen gelten, die ihre Software im Laufe der Jahre hoch individualisiert und in manchen Fällen bis zur Unkenntlichkeit entstellt haben. Wer also jetzt kurz vor dem Wechsel nach S/4HANA die Chance verpaßt, die eigenen „hysterisch gewachsenen“ Geschäftsprozesse auf eine neue Grundlage zu stellen, dem wird sie sich in den nächsten 15-20 Jahren kaum mehr oder nur unter großen Schmerzen bieten – mal ganz abgesehen von dem Aufwand, den der hohe Individualisierungsgrad bei der eigentlichen Transformation mit sich bringt. Darum plädieren wir dafür, den Wechsel nach S/4HANA nicht als rein technische Angelegenheit zu betrachten, sondern als eine wirklich gute Gelegenheit, „alte Zöpfe abzuschneiden“ und das Unternehmen in Bezug auf die Geschäftsprozesse fit für die Zukunft zu machen. Damit steigt zwar der Zeitbedarf für eine Transformation, aber dieses Investment lohnt und wird uns von vielen Kunden als die einzig richtige Vorgehensweise zurückgespiegelt. Alles andere (das wären dann die Möglichkeiten 1 + 2 der nachfolgenden Abbildung) ist aus unserer Sicht zu kurz gesprungen.

Wie bereits erwähnt dienen Geschäftsprozesse als Ordnungsrahmen für die unternehmerische Tätigkeit. Sie sind, um ein anderes Bild zu wählen, das „Adersystem“, durch das der Datenstrom pulsiert, der ein Unternehmen erst zu einem lebendigen Organismus macht. Genau deshalb legen wir im Kontext unserer Realtransform®-Transformationsmethodik so großen Wert auf ein möglichst aktuelles Prozeßmodell. Das ist der Fixpunkt, an dem sich die meisten für eine Transformation notwendigen Maßnahmen orientieren müssen, und zwar völlig unabhängig davon, ob es sich um ein Greenfield- oder Brownfield-Vorgehen handelt. Nur wer hier schon wirklich à jour ist, d.h. seine Hausaufgaben in der Zeit davor gemacht hat, braucht hier weniger Zeit und Aufwand reinzustecken. Aber das haben die wenigsten der mir bekannten Unternehmen.

Hinzu kommt ein weiterer, vielfach noch nicht bekannter Punkt. SAP bezeichnet S/4HANA als „digitalen Kern“, den man idealerweise stabil halten sollte. Gleichzeitig öffnet sich die SAP für die schöne neue Welt der Cloud-Technologien über klar definierte Integrationspunkte in die eigene Software-Suite (SAP Cloud Platform). Mithin sind nun Geschäftsprozesse denkbar, die in früheren Softwaregenerationen nahezu undenkbar gewesen wären, was insbes. bei der Digitalisierung enorm wichtig wird. Gleichzeitig bietet sich aber auch die Möglichkeit der Entkopplung komplexer, bislang im SAP ECC vorgenommener Kundenlösungen vom „digitalen Kern“, indem man sie über die SAP Cloud Platform oder andere vergleichbare Lösungen (MS Azure, Google Cloud, AWS) orchestriert. Zugegeben, das wäre dann der ganz große Wurf, den sich die meisten Unternehmen, die vor einem Transformationsvorhaben stehen, alleine schon aus zeitlichen Überlegungen nicht trauen. Aber es wäre die richtige, weil in die Zukunft gerichtete Vorgehensweise.

Nachdem wir nun den Finger in die Wunde gelegt und zugegeben auch etwas darin herumgebohrt haben, stellt sich die Frage, wie man sich dem Thema „Geschäftsprozesse und deren Modellierung“ zu nähern. Grundsätzlich gibt es dazu zwei Herangehensweisen: 

• Ist ein Geschäftsprozeßmodell bereits vorhanden, kann man zunächst darauf aufsetzen. Hier spielen folgende Fragen eine Rolle: Wie ist der struktuelle Aufbau? Welche Ebenen existieren? An welchen Stellen und auf welchen Ebenen liegt welche Form der Dokumentation? Wie aktuell ist das Modell? Wieviel „Zukunft“ ist bereits darin enthalten? Wie sind die Zuständigkeiten (RACI) geregelt, und auf welcher Ebene? Wie mappt das Geschäftsprozeßmodell gegen generische Ansätze für die Branche/für das Segment?
• Fehlt es gänzlich oder ist es nur rudimentär vorhanden, muß neu aufgesetzt werden, an besten entlang eines geeigneten Referenzmodells und ggf. auch, sofern diese geeignet sind, unter Nutzung von sog. „Best Practices“, wie sie bspw. die SAP über den SAP Solution Manager verfügbar macht, oder entlang der „Model Company“ der SAP. Der vorausgelieferte Content kann dabei beliebig um eigene Geschäftsprozesse oder -elemente erweitert werden. Allerdings ist auch hier ein vorab definierter struktureller Aufbau dringend erforderlich.

Seit wenigen Jahren gibt es nun noch eine weitere Herangehensweise, die unter dem Buzzword „Process Mining“ bekannt geworden ist. Hiermit kann eine bestehende Systemlandschaft sozusagen „automatisch vermessen“ und kartografiert werden. Process Mining nutzt Datenbank-bezogene Informationen, um daraus abzuleiten, wie ein Prozeß wirklich läuft. Die Ergebnisse sind zumeist verblüffend, bringen sie doch das ganze „kreative Chaos“ ans Licht, indem die unterschiedlichen Varianten, in denen ein Prozeß im Ist abläuft, transparent dargestellt werden. Hieraus lassen sich unmittelbar die Handlungsfelder für die Überarbeitung der Geschäftsprozesse ableiten. Process Mining eröffnet darüber hinaus völlig neue Möglichkeiten für eine kontinuierliche Prozeßverbesserung. Aber dazu mehr Informationen in einem separaten Blogbeitrag.