Was Schwedenmöbel mit der End-to-End Prozessmodellierung gemeinsam haben


Eigentlich kennen die meisten von uns diese Situation. Wir stehen vor einem frisch ausgepackten Karton eines bestimmten Möbelhauses und betrachten die Einzelteile. Meistens wundert man sich ein bisschen dabei, wie all diese Komponenten zusammengehören sollen, um am Ende den gewünschten Schrank/Tisch/Stuhl zu ergeben. Aber zum Glück gibt es ja die Anleitung, die uns Schritt für Schritt erklärt, was zu tun ist. Genau diese Anleitung ist auch der Punkt, an dem ein End-to-End Prozessmodell ansetzt. Denn auch dieses hat das Ziel, Arbeitsabläufe schrittweise zu erklären. Mit einem bestimmten Ziel vor Augen. Eine solche Dokumentation zielt darauf ab, allen Prozessbeteiligten die Zusammenhänge verständlich und transparent zu erläutern. Soweit klingt das plausibel.

Doch so viel sei verraten, bei der End-to-End Prozessmodellierung scheiden sich die Geister. Generell gilt schließlich, dass die Granularität der Darstellung von Prozessen sehr umstritten ist. Während den Vertretern der klassischen IT eine sinnvolle Listung der technischen Objekte genügt, sind die meisten Fachbereichsmitarbeiter ganz anderer Ansicht. Für sie ist die klare Abbildung der unterschiedlichen Prozessabläufe vor allem aus betriebswirtschaftlicher Sicht wichtig.

Wer hat demnach Recht? Die Antwort ist wie so oft: „Beide“ und „Es kommt darauf an.“

Denn jede dieser Darstellungsformen ist für sich gesehen sinnvoll. Abhängig vom jeweiligen Einsatzszenario. Und genau hier liegen sowohl das Problem dieser Diskussion als auch seine Lösung. Weil ein Ansatz, der beiden Seiten gerecht werden kann, den Grundstock für das klassische IT / Business-Alignment bilden kann. Also die gemeinsame strategische Ausrichtung der beiden Diskussionspartner. Insofern stellt die Solution Documentation Funktionalität im SAP Solution Manager schon immer eine solide Möglichkeit dar, genau dies zu tun. Wenngleich nicht unter den geeigneten organisatorischen wie technischen Voraussetzungen. Man denke nur an die Beschränkung der Prozessmodellhierarchie auf drei Hierarchiestufen. Doch spätestens mit dem Übergang auf den SAP Solution Manager 7.2 wird dieses Problem bekanntlich aufgehoben sein.

Die richtige Vorgehensweise, um eine sinnvoll nutzbare Dokumentation der genutzten Prozesse zu erhalten, ist im Folgenden skizziert. Sie umfasst im Wesentlichen die folgenden fünf Arbeitsschritte:

Technische Basis schaffen Systemlandschaft aufbauen
Libraries generieren
Systemnutzung identifizieren  

Nutzungsanalyse durchführen

Kernprozesse definieren

Prozessmodellhierarchie aufbauen Scratch oder Template
Anpassung an individuelle Abläufe und Funktionen
Graphisches Prozessmodell gestalten Arbeitsabläufe mit Querverbindungen

Rollen- und Systemverteilung

Weiterführende Funktionalitäten aktivieren Usage Scenarios planen und aktivieren
Rückfluss auf die Ausgestaltung der Solution Documentation

Aber wie sieht sie aus, die richtige Solution Documentation? Handelt es sich dabei eher um eine modulare Business Process Hierarchy oder ein workflow-orientiertes Grafikmodell? Auch hier entscheidet letztendlich die Zielsetzung über die Ausgestaltung. Sowohl die Priorisierung der Bestandteile als auch der Detaillierungsgrad müssen daran ausgerichtet werden, ob die Prozessdokumentation nun Monitoringzwecken dient oder verwendet werden soll im Rahmen von Test Management oder Change Management. Daher genügt auch hier keine einfache Antwort. Schließlich unterscheiden sich die Anforderungen bspw. schon im Rahmen des Test Managements, Je nachdem, ob technisch orientierte Regressionstests oder Integrationstests inklusive Rollenverteilung durchgeführt werden sollen.

PM Order Diagram

PM Order Diagram

 

 

KPI Prozess

KPI Prozess

 

 

Allen gemeinsam ist der Bedarf einer fundierten und breit gestreuten Informationsbasis. Zur Verbindung standardisierter Informationen mit der kundenbezogenen Nutzungssituation und individueller Systemanpassungen. Eine Abstimmung, die durchaus vergleichbar ist mit dem Aufbauen von Fertigmöbeln und dem anschließenden Einpassen in die eigenen vier Wände. Denn die Definition einer Solution Documentation sollte niemals Selbstzweck sein sondern zielgerichtet durchgeführt werden. Nur dann zahlt sich der Aufwand auch wirklich aus.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

16 − 15 =