Serie
Geschäftsprozessmanagement in Wirtschaft und Verwaltung: Teil 2
Vorgehen im Geschäftsprozessmanagement

Norbert Gronau

Wer eine Methode vorschlägt, soll nach Meinung des Autors auch angeben, wie diese Methode genutzt werden soll. Daher ist es unverständlich, dass in vielen auch handbuchartigen Werken über Geschäftsprozessmanagement (GPM) keine Vorgehensweise für das Geschäftsprozessmanagement als ganzes angegeben wird. Auch die Propagandisten des Business Process Reengineering, Michael Hammer und James Champy, geben nur sehr dürre Hinweise auf das Vorgehen. Zahlreiche Quellen konzentrieren sich auf die Modellierung, die aber nur einen Teil des Geschäftsprozessmanagements umfasst oder machen gleich gar keine Aussagen zum Vorgehen. Daher werden in diesem Beitrag mehrere Vorgehensmodelle für das Geschäftsprozessmanagement ausführlicher beschrieben und daraus dann eine aggregierte Empfehlung erstellt. Abschließend wird das RAIL-Modell des GPM dargestellt. Vorgehensmodellen kommt die Aufgabe zu, die Wirklichkeit mit ihren für den Sachverhalt wesentlichen Größen, Abhängigkeiten und Vorgängen vereinfacht abzubilden. Vorgehensmodelle umfassen somit Informationen über die zeitliche und logische Reihenfolge der Aufgaben sowie Angaben zu den Zielen einzelner Aktivitäten und den dabei anzuwendenden Methoden.

Anforderungen an Vorgehensmodelle
An Vorgehensmodelle sind eine Reihe von Anforderungen zu stellen. So sollen in einem Vorgehensmodell für das Geschäftsprozessmanagement die Aspekte Organisation, Technik und Mensch gleichmäßig betont werden, da der Erfolg des Geschäftsprozessmanagements nur eintritt, wenn alle drei Dimensionen angemessen berücksichtigt werden.
Um eine echte Hilfestellung bei der Durchführung eines Projektes darzustellen, ist das Vorgehensmodell hinreichend zu detaillieren. Zwischen den einzelnen Aufgaben bzw. Phasen sollten Möglichkeiten der Rückkopplung bestehen, um Entscheidungssituationen explizit darstellen zu können und ein nochmaliges Durchlaufen vorgelagerter Phasen zu ermöglichen. Unabdingbar ist die Berücksichtigung aller Phasen im Vorgehensmodell und nicht etwa nur der Analysephase.
Besonders wichtig ist schließlich die Anpassbarkeit des Vorgehensmodells an unterschiedliche Organisationsmerkmale wie Größe oder Branche. Ebenso gehört zur Anpassbarkeit die Fähigkeit, sich an veränderte Umgebungsbedingungen während des Projektes anzupassen.

Das ARIS House of Business Engineering
Ende der 1990er Jahre stellte August-Wilhelm Scheer sein ARIS-House of Business Engineering vor, eine integrierte Darstellung von Prozessmanagementmethoden und -werkzeugen sowie den damals gerade aufkommenden ERP-Systemen, allen voran das damals R/3 genannte ERP-System der SAP AG.
Das ARIS - House of Business Engineering stellt nach Ansicht von Scheer einen Bezugsrahmen zum Management von Geschäftsprozessen dar, der von der organisatorischen Gestaltung über die technische Automatisierung bis zur kontinuierlichen Verbesserung reicht. Scheer orientierte sich dabei an der Arbeitsplanung in der Industrie zur Vorbereitung der Fertigung eines Produktes.
Das Konzept besteht aus vier aufeinander aufbauenden Ebenen. Auf der obersten Ebene  Prozessgestaltung werden die Geschäftsprozesse modelliert. Die zweite Ebene bildet die Planung und Steuerung der laufenden Geschäftsprozesse aus der Sicht des für den Geschäftsprozess Verantwortlichen (Business Process Owner) ab. Auf der dritten Ebene seines Konzeptes hat Scheer die Workflowsteuerung angesiedelt, die die Prozessdefinition der ersten Ebene und die Ressourcensteuerung der zweiten Ebene mit den eingesetzten Informationssystemen verbindet.
Die vierte Ebene umfasst die Anwendungssysteme, in die der Prozess abgebildet wurde. Dabei unterscheidet Scheer in Standardsoftware, Komponenten (heute würden diese als Software as a Service bezeichnet), Geschäftsobjekten und Applets. 

Geschäftsprozessmanagement als Engineeringprojekt 
Rosenkranz hat ein lineares Modell eines Geschäftsprozessmanagementprojektes als Engineeringprozess entwickelt. Er sieht den Projektablauf als Zusammenfassung von Aktivitäten, die fast immer in GPM-Projekten vorkommen. Rosenkranz warnt vor "Paralyse durch Analyse", wenn Aktivitäten ohne Vision für die Zukunft ausgeführt werden. Bemerkenswert an dem ansonsten nicht weiter ausgeführten Modell ist die eindeutige Zuordnung von Rollen zu den einzelnen Aktivitäten. Eine wichtige Rolle spielt dabei das EM-Team (Erhebung und Modellierung). Allerdings erwähnt Rosenkranz nicht, welche Anforderungen an die Mitglieder des EM-Teams gestellt werden. Immerhin ist eine Schulungsphase vorgesehen. 
Die Anpassbarkeit des Modells, das sich eher auf die Sollprozessgestaltung fokussiert, ist hoch, da es sich generisch auf Projekte aller Art und Größe bezieht - Rückkopplungen sind auf einzelne Aktivitäten in bestimmten Phasen beschränkt

Das Vorgehensmodell der Systemanalyse
Das von Frank und Gronau entwickelte Vorgehensmodell der Systemanalyse im Unternehmen zur Veränderung von Geschäftsprozessen unterscheidet die Phasen Projektbegründung, Istanalyse, Sollkonzept, Entwicklung und Integration (Abb. 1). 


Bild 1: Vorgehensmodell der Systemanalyse

Entwickelt wurde das Vorgehensmodell der Systemanalyse nicht für die vollständige Neuentwicklung isolierter Informationssysteme, sondern für die problemorientierte Untersuchung organisatorischer und informationeller Systeme. Die Vorschläge zur Beseitigung von Schwachstellen, die im Rahmen dieser Analysen aufgedeckt wurden, sollen nicht ausschließlich Anwendungssysteme beinhalten und an vorrangiger Stelle die Bedürfnisse und Anforderungen der unmittelbaren Benutzer (Partizipation) berücksichtigen. Insofern folgt dieses Vorgehensmodell dem ganzheitlichen Ansatz der Systemtheorie.
Die erste Phase des Vorgehensmodells umfasst alle Aktivitäten zur Initialisierung eines Projektes. Sie führt zur Erteilung eines Projektauftrages. Wesentliche Aufgaben dieser Phase sind die Zielanalyse, die Abgrenzung des zu untersuchenden Systems sowie die Prüfung der rechtlich vorgeschriebenen Maßnahmen zur Mitbestimmung.
Die Istanalyse ist eine der wichtigsten Phasen der Systemanalyse. Alle Vorschläge des späteren Sollkonzeptes zu organisatorischen und technischen Veränderungen basieren auf den Ergebnissen dieses Projektteils.Aus diesem Grund ist eine ausreichend intensive Istanalyse vorzusehen und gegenüber den Auftraggebern entsprechend zu begründen.
Der Systemanalytiker wird die Istaufnahme anhand der Dokumentationen gründlich aus verschiedenen Blickwinkeln analysieren, um die vorhandenen Potenziale zu erkennen. Organisatorische Schwachstellen ergeben sich aus aufbau- oder ablauforganisatorischen Festlegungen oder deren Fehlen, z.B. das Fehlen einer klaren Vertretungsregelung im Urlaubs- bzw. Krankheitsfall. Informationelle Schwachstellen ergeben sich aus einem unzureichenden, unterbrochenen oder sehr lang dauerndem Informationsfluss. Sie sind häufig eng mit organisatorischen Schwachstellen verbunden. Typische informationelle Schwachstellen sind z. B. Medienbrüche, die erzwingen, dass eine bereits per Computer erfasste Information nochmals eingegeben werden muss. Technische Schwachstellen beschreiben Unzulänglichkeiten in der technischen Ausstattung des untersuchten Betriebsbereiches.
Aufgabe der Sollkonzeptphase ist es, ein neues oder verändertes System vorzuschlagen, um die im Rahmen der Istaufnahme ermittelten Schwachstellen ganz oder teilweise zu beseitigen. Die einzelnen Vorschläge des Sollkonzeptes werden hinsichtlich ihrer Realisierungsdauer und ihrer finanziellen Auswirkungen bewertet. Dabei sollen auch die Vorteile bei der Realisierung dieser Vorschläge beschrieben, wenngleich eine Quantifizierung in den meisten Fällen nicht möglich ist. In weiteren Phasen erfolgen Eigenentwicklung bzw. Auswahl und Einführung von Standardsoftware. In diesen beiden Phasen greift das Vorgehensmodell der Systemanalyse jedoch auf anderweitig vorhandene Literatur zum Software Engineering bzw. zu Standardsoftware zurück, auf deren Darstellung hier verzichtet werden kann.

Das 7FE-Konzept
John Jeston und Johan Nelis haben aus ihrer Erfahrung als Berater und Implementierer ein Framework für die Durchführung von Geschäftsprozessmanagement-Projekten entwickelt, welches sie als 7FE Project Framework bezeichnen. Es besteht aus zehn Phasen, die in vier Gruppen angeordnet sind (Grundlagen, Erkenntnisse und Lösungen, Erfüllung und Zukunft, auf englisch foundations, findings and solutions, fulfillment und future, daher 4F) und die auf drei so genannten Essentials basieren, nämlich Leadership, Projektmanagement, und auf Menschen bezogenes Change Management (3E).


Bild 2: Das 7FE-Konzept

Jeston und Nelis weisen darauf hin, dass den drei grundlegenden Orientierungen ("Essentials"), die sie ihrem Framework zugefügt haben, eine erhebliche Bedeutung zukommt. Es handelt sich dabei um das Projektmanagement, das personenbezogene Change Management und den Punkt Leadership.
Projektmanagement ist unabdingbar, weil Komplexität und Projektrisiken so viel höher sind und jederzeit die Gefahr besteht, dass errechnete Nutzeneffekte von der Organisation nicht erreicht werden. 
Der menschliche Aspekt ist wichtig, weil zahlreiche GPM-Projekte in der Vergangenheit gerade an der Vernachlässigung dieses Themas gescheitert sind.
Schließlich müssen alle Veränderungsprojekte die ausdrückliche Rückendeckung des (Top-)Managements haben, um erfolgreich zu sein. Diese Verantwortung darf auch nicht während des Projektes nach unten delegiert werden. 

Die HORUS-Methode
Ein umfassendes Vorgehensmodelll zur Anwendung von Prozessmodellierungstechniken im Kontext einer organisatorischen Veränderung hat die Horus Software GmbH entwickelt. Primäres Ziel der Methode ist das Sammeln und Strukturieren fachlicher Anforderungen sowie die Erstellung eines umfassenden Geschäftsprozessmodells unter Berücksichtigung des Prozessumfelds. Prozessverbesserungen und Durchsetzung des Prozesses liegen außerhalb des Definitionsbereichs der Methode. Die Horus-Methode besteht aus vier Phasen (Abb. 3).


Bild 3: Ablauf der HORUS-Methode 

In der Phase der Projektvorbereitung wird festgelegt, welcher Teil der Organisation untersucht werden soll und welcher Budget- und Zeitrahmen dafür zur Verfügung steht. Zudem werden die mit dem Projekt verbundenen Ziele dargestellt und der angestrebte wirtschaftliche und strategische Nutzen genannt. 
In der Phase "Von der Mission zum Architekturmodell" wird zunächst eine Kontextanalyse durchgeführt. Dazu werden die externen Einflussfaktoren analysiert, die Auswirkungen auf das in der Analyse betrachtete System haben. Diese Auswirkungen werden bewertet. Im Rahmen der Kontextanalyse wird auch das Leistungsportfolio des betrachteten Systems definiert. Dies sind die Produkte und Dienstleistungen, die die Wertschöpfung des Unternehmens ausmachen. Als dritter Teil der Kontextanalyse erfolgt eine Zieldefinition, bei der Ziele aus der Mission des Unternehmens auf das zu untersuchende Teilsystem heruntergebrochen werden. Zweiter Teilschritt dieser Phase ist eine SWOT-Analyse, die die Stärken, Schwächen, Bedrohungen und Chancen des betrachteten Unternehmensbereichs darstellt. Diese bilden die Ausgangsbasis für eine sich anschließende Strategieanalyse, die aus den Aufgaben Strategiedefinition, Leistungsindikatorenanalyse und Risikoanalyse besteht. Im vierten Schritt wird die Unternehmensarchitektur modelliert. Dieses Modell zeigt die wichtigsten wertschöpfenden Geschäftsprozesse des Untersuchungsbereichs sowie Führungs- und Unterstützungsprozesse wie Buchhaltung oder Administration. Abschließend für diese Phase wird ein Design der Systemarchitektur vorgenommen. Dieses grobe Design dient nach Ansicht der Autoren vor allem der Schätzung der Anschaffungs- und Implementierungskosten sowie des Betriebsaufwandes. 
In der zweiten inhaltlichen Phase werden die vorhandenen Geschäftsprozesse modelliert. Dies bezeichnen die Autoren als Analyse, die mit der Strukturanalyse beginnt, in der geschäftsprozessübergreifende Objekte und Geschäftsregeln definiert werden. Die Autoren begründen diesen Schritt mit der Notwendigkeit, eindeutige Referenzen auf Geschäftsobjekte und Regeln jenseits von verbalen Beschreibungen zu schaffen. Objekte sind z.B. Aufträge, während Geschäftsregeln Entscheidungen semiformal darstellen. An die Strukturanalyse schließt sich die Ablaufanalyse an, die Ereignisse und Anwendungsfälle modelliert und im Kontext darstellt.

Der BPM-Cycle
Dumas et. al (2013) sehen die Aufgabe des Geschäftsprozessmanagements in einem zyklischen Zusammenhang und nennen ihr Vorgehensmodell daher BPM Life Cycle (Abb. 4).


Bild 4: Vorgehensmodell BPM Life Cycle

Der BPM Life Cycle besteht aus fünf zyklisch wiederkehrenden Phasen nach einer initialen Prozessdefinition. Diese basiert auf einem im Geschäftsablauf vorkommenden Problem, das in einer sog. Prozessarchitektur, einem Gesamtbild der in einer Organisation vorkommenden Prozesse eingeordnet wird. Daran schließt sich die Phase „Process Discovery“ an, die eine Ist-Modellierung des zu untersuchenden Prozesses vornimmt. Anschließend wird der so dargestellte Prozess in der Phase „Process Analysis“ auf Probleme untersucht, die nach Möglichkeit durch Prozesskennzahlen quantifiziert werden sollten.
Die folgende Phase „Process Redesign“ identifiziert die zur Lösung der Probleme erforderlichen Veränderungen im Prozessablauf. Dazu werden verschiedene Änderungsvorschläge generiert und die sich bei deren Realisierung ergebenden Prozesskennzahlen (z.B. Durchlaufzeit) verglichen. Das ausgewählte Sollprozessmodell wird dann in der Phase „Process implementation“ umgesetzt. Dazu muss die Organisation durch Change Management verändert und der Prozessablauf optimiert werden.
Der BPM Life Cycle von Dumas et. al. versteht sich ausdrücklich als Anleitung für die Automatisierung von Prozessen und liefert keine Ansatzpunkte für das Change Management. Die abschließende Phase „Process Monitoring and Execution“ befasst sich mit der Sammlung und Auswertung von Prozesskennzahlen, um Engpässe, wiederkehrende Fehler und Abweichungen zu identifizieren. Deren Auftreten bedingt dann einen erneuten Durchlauf durch den BPM Life Cycle.

Vergleich der vorgestellten Ansätze
Eine vergleichende Gegenüberstellung der neun vorgestellten Vorgehensmodelle für das Geschäftsprozessmanagement zeigt, dass keiner der beschriebenen Ansätze alle Anforderungen, die an ein zeitgemäßes Vorgehensmodell gestellt werden, erfüllt. Neben dem Modell von Frank u.a. schneidet nur das HORUS-Modell überhaupt akzeptabel ab. Die anderen Modelle weisen neben der in Tab. 1 dargestellten Gesamteinschätzung teilweise skurrile Defizite auf. 
So weist das weithin genutzte Modell von Scheer (1998) keinerlei Bezüge zu Change Management auf, also der Überführung einer Ist-Organisation in eine Soll-Organisation unter Einbeziehung der Mitarbeiter. Mit den angegebenen rein technischen Maßnahmen lässt sich das nicht bewältigen. Das Modell von Rosenkranz (2002) erfasst bereits Schwachstellen, bevor überhaupt mit der Datenerhebung begonnen wird - in der Realität entpuppen sich häufig andere Schwachstellen als sehr viel schwerwiegender als diejenigen, mit denen das Projekt begonnen wurde.


Tab. 1: Vergleich von GPM-Vorgehensmodellen

Das aus der Praxis eines internationalen Elektrokonzerns heraus entwickelte Modell von Schmelzer und Sesselmann (2010) verzichtet sogar auf eine Differenzierung zwischen Konzept und Implementierung. Ebenso fragwürdig ist es, warum diese Autoren vorschlagen, ausgerechnet in der Phase der Optimierung der neu eingeführten Prozesse ein Business Process Reengineering vorzunehmen, also den kompletten Neuaufwurf eines Geschäftsprozesses. Auch die ansonsten vorbildliche Horus-Methode differenziert zwar in gleich drei projektvorbereitende Phasen, fasst dann aber unter dem Begriff Nutzung die Aufgaben Konzeptbildung, Umsetzung und Begleitung des Produktivbetriebs zusammen.
Der Vergleich der vorhandenen Vorgehensmodelle zeigt, dass zahlreiche Unzulänglichkeiten noch ausgeräumt werden müssen. Diese liegen insbesondere in den Aspekten der Anpassbarkeit, der Sicherstellung einer Rückkopplung zu vorgelagerten Phasen und in der gleichmäßigen Berücksichtigung von menschlichen, organisatorischen und technischen Einflussfaktoren. Diese Aspekte werden durch das RAIL-Vorgehensmodell des Geschäftsprozessmanagements sichergestellt, das im folgenden Abschnitt vorgestellt wird.

Das RAIL-Modell
Ausgehend von den Unzulänglichkeiten der in den vorigen Abschnitten beschriebenen Vorgehensmodelle für das Geschäftsprozessmanagement und auf der Basis der langjährigen Erfahrungen mit dem Vorgehensmodell der Systemanalyse wurde das RAIL-Modell entwickelt.
Die Buchstaben RAIL setzen sich aus den vier wesentlichen Anforderungen Robustheit, Anpassbarkeit, Integrationsfähigkeit und Lasttauglichkeit zusammen. Die Einstiegsebene ist in Abb. 5 dargestellt.


Bild 5: Einstiegsebene des RAIL-Modells für das Geschäftsprozessmanagement.

Das Vorgehensmodell besteht auf der Einstiegsebene aus fünf Phasen und zwei parallel zu allen Phasen angeordnete Querschnittsaufgaben. Die Phasen bilden das prinzipiell sequentielle, aber rückgekoppelte Vorgehen im Projekt ab, während die Querschnittsaufgaben sich um den Projektcharakter (Projektsteuerung) bzw. um die Überführung der Projektergebnisse in die Organisation (Change Management) kümmern. Jede Phase steht in Beziehung zu bestimmten Aufgaben der Querschnittsbereiche, deren Erfüllung z.B. durch Checklisten sichergestellt werden kann. Das Vorgehen bei Rail ist in Anlehnung an Krallmann als iterativ, heuristisch und rückgekoppelt zu bezeichnen. Es folgt einer projektorientierten Sichtweise und enthält daher keine Regelkreise, die eine ständige Überprüfung der Geschäftsprozesse auf Effizienz sicherstellen. Die Einrichtung dieses Überprüfungsprozesses ist Aufgabe des General Management
Die Schienenmetapher wurde auch aus dem Grund gewählt, weil die Phasen als Schwellen und die Querschnittsaufgaben als Schienen angesehen werden können. Im realen Gleisbau kommt den Verbindungselementen zwischen Schienen und Schwellen eine entscheidende Bedeutung zu. Diese Elemente entscheiden, ob das Projekt zur Veränderung der Geschäftsprozesse "wie auf Schienen läuft" oder "entgleist", also ohne Ergebnis endet und dabei hohen Schaden anrichtet.
In der Praxisversion des RAIL-Vorgehensmodells ist jedes Verbindungselement mit einer Checkliste verknüpft. Eine Bearbeitung der Checkliste ermöglicht ein Tailoring der folgenden Projektphase und eine Überprüfung der bisher erzielten Ergebnisse.

Teil 3 in der nächsten Online-Ausgabe: Vorgehen bei der Istanalyse