Suche
Ein Blick hinter die Kulissen der Enterprise BPM Alliance

Enterprise BPM Methodik 2.0

Christian Weiss, Dirk Slama, Kim Nena Duggen, Torsten Winterberg
business-process-management

© Shutterstock / Tashatuvango

„Wer am Fluss wohnt, versteht die Fische“, so ein chinesisches Sprichwort. Wer also mit Prozessen arbeitet, versteht sich auf Prozessmanagement und dessen Herausforderungen. So entstand die Enterprise BPM Alliance – ein Verein, der auf Altbewährtes und praktische Erfahrungen ebenso wie auf den Open-Source-Gedanken bei der Weiterentwicklung seiner Methodik setzt. Lesen Sie im Folgenden, wie das Business Process Management Framework 2.0 funktioniert und wer dahintersteckt.

Sobald ein Unternehmen eine bestimmte Größe und Reife erreicht hat, kommt es scheinbar zu einigen immer wiederkehrenden Problemen. Joseph Schumpeter hat daraus die Konsequenz gezogen, dass jede ökonomische Entwicklung auf dem Prozess der schöpferischen Zerstörung aufbaut. Durch eine Neukombination von erfolgreichen neuen Produktionsfaktoren werden alte Strukturen verdrängt und schließlich zerstört.

Auch heute erfolgreiche Unternehmen müssen sich daher damit auseinandersetzen, wie sie mit kontinuierlicher Veränderung am besten umgehen. Dies gilt auch für theoretisch stabilere Branchen wie beispielsweise Versicherungen oder Banken. Sich ständig ändernde regulatorische Anforderungen, kontinuierliche Erweiterung der Multikanalarchitekturen, Optimierungsdruck, Out- und Re-Sourcing führen zu ständigen Veränderungen. Und wenn dann noch Zeit ist, sollen neue Produkte und neue Produktionsprozesse eingeführt werden etc.

Dagegen stehen die typischen Probleme, die große Organisationen immer haben werden, trotz stetig neuer Managementkonzepte und Organisationsformen. Dazu gehören insbesondere:

  • Organisatorische Silos mit dazugehörigen Anwendungssilos: Die innere Gravitation in großen Organisationen wird immer wieder zu solchen Strukturen führen.
  • Heterogene, organisch gewachsene Anwendungslandschaften: Trotz Cloud und Co. wird uns dieses Phänomen aufgrund der kontinuierlichen Technologieinnovation immer begleiten.
  • Extrem hohe Komplexität: Die inhärente Komplexität einzelner Unternehmensanwendungen sowie der organisch gewachsenen Anwendungslandschaften lässt ein zentrales Management von Abhängigkeiten nicht mehr zu.
  • Schwieriges IT/Business Alignment: Der benötigte hohe Spezialisierungsgrad in der IT wird immer dazu führen, dass die Abstimmung mit den Fachexperten und Endnutzern problematisch bleiben wird.

Natürlich sind diese Erkenntnisse nicht neu. Daher wurden in den letzten Jahrzehnten diverse Ansätze entwickelt, um mit diesen Problemen umzugehen:

  • Agile: Agile Entwicklungsmethoden sind in diesem Kontext wahrscheinlich eine der wichtigsten Neuerungen des letzten Jahrzehnts; insbesondere da der agile Ansatz Stabilität und Kontinuität in dynamischen Umfeldern bringt.
  • BPM (Business Process Management): BPM hilft, Geschäftsprozesse zu strukturieren und zu optimieren.
  • SOA (serviceorientierte Architekturen): SOA bringt Ordnung in heterogene Anwendungslandschaften durch Schaffung von wiederverwendbaren, fachlichen Softwarekomponenten mit klar definierten Schnittstellen.
  • EAM (Enterprise Architecture Management): EAM gibt dem CIO-Office eine planerische Perspektive oberhalb der SOA, um komplexe Anwendungsportfolios managen zu können.
  • Managed Evolution: Managed Evolution ist ein IT-Management Ansatz, um Investitionen zwischen Schaffung von direktem Geschäftsnutzen und den notwendigen strategischen Investitionen in IT-Effizienz auszusteuern.

Fast jeder dieser Ansätze hat im Laufe seiner Entwicklung auch problematische Phasen durchgemacht, die zu viel Kritik führten. Im Bereich BPM hatten wir in den 80er-Jahren die berühmt berüchtigten ARIS-Wandtapeten: Gigantische Prozessdokumentationen, die nie operative Relevanz erlangten. Im Bereich SOA gab es Tendenzen der Überstandardisierung und zu stark zentralistischer SOA-Governance. Im Bereich EAM haben sicherlich einige Metamodellierungsenthusiasten den Ruf, keinen Bezug mehr zur IT-Realität zu haben. Und auch im agilen Umfeld streiten sich heute noch Methodikfundamentalisten und selbsternannte Pragmatiker über den besten Ansatz. Vielleicht mit Ausnahme von Agile wird auch keiner der hier genannten Ansätze heute mehr als „sexy“ angesehen. Ein Grund dafür ist sicherlich, dass jeder dieser Ansätze versucht, extrem schwierige Probleme zu lösen, die sowohl in technischer, organisatorischer wie unternehmenspolitischer Hinsicht nie perfekt lösbar sein werden. Außerdem färben sicherlich die negativen Emotionen, die in diesen Konfliktfeldern zwangsweise aufkommen, irgendwann auf die Lösungsmaßnahmen ab („Shooting the messenger“-Syndrom).

Da die hier beschriebenen Problembereiche allerdings immer aktuell bleiben und sich viele von uns zwangsweise auch in den nächsten Jahrzehnten mit ihnen beschäftigen müssen, erscheint es umso wichtiger, den hier entstandenen Methodenwerkzeugkasten kontinuierlich anzupassen und zu optimieren.

Wozu eine BPM-Methodik?

BPM spielt im Kontext der oben beschriebenen Ansätze eine besondere Rolle. Einerseits ist BPM gerade für die Firmen relevant, die aus der Start-up-Phase herausgewachsen sind und nun ihre Prozesse optimieren müssen. Zusätzlich baut BPM auf anderen Konzepten auf, insbesondere SOA. Wie wir aber gelernt haben, ist der Einsatz von BPM und verwandter Ansätze nicht trivial. Eine BPM-Methodik könnte hier helfen. Dokumentation der Erfahrung von BPM-Anwendern helfen, Fehlentwicklungen in zukünftigen Projekten zu vermeiden. Die Schaffung eines gemeinsamen Verständnisses hilft mit dem Alignment von Business und IT. Einbindung bzw. Abgrenzung von neuen Konzepten wie z.B. Adaptive Case Management (ACM) und SOA-Microservices stellt die Aktualität sicher. Projektleiter erhalten einen konkreten Leitfaden zur Umsetzung. Lösungsarchitekten können ihre Lösungsarchitekturen besser in den Projektkontext einbinden. Abhängigkeiten zu anderen Projekten können besser gehandhabt werden. Projektrisiken lassen sich durch Verwendung von Best Practices vermindern.

Die Entwicklung einer solchen BPM-Methodik hat also viele Vorteile. Eine Organisation, die sich mit der Entwicklung einer solchen BPM-Methodik beschäftigt, ist die Enterprise BPM Alliance e.V., die im Folgenden vorgestellt wird.

Wer ist die EBPM Alliance?

Der Verein wurde 2013 in einem Zusammenschluss von BPM-Anwendern ins Leben gerufen, um der gemeinsamen Überzeugung Rechnung zu tragen, nach der strukturierte und effiziente Business-Process-Management-Vorhaben immer auch an einer guten Vorgehensmethodik orientiert sind. Das Kernstück der Alliance liegt somit in der gemeinsamen Weiterentwicklung der offenen BPM-Methodik, dem Business Process Management Framework (BPMF). Zu den Mitgliedern zählen aktuell neben einigen privaten und freiberuflichen BPM-Enthusiasten die Firmen oose Innovative Informatik, Holisticon, Opitz Consulting, innoQ, Operational Risk Solutions und HCL.

Neben der Methodik als gemeinsamer Sprache und Best-of der Erfahrungen der Mitglieder fördert der Verein den Austausch zwischen BPM-Anwendern in offenen Diskussionen, bei Konferenzen, in Workshopformaten mit Experten und auf Austauschplattformen. Methodik und Austausch zusammengenommen sollen das gemeinsame Lernen und die Weiterentwicklung einer tragfähigen und praxisorientierten Methodik fördern.

Grundlage des BPMF bildet das Buch „Enterprise BPM – Erfolgsrezepte für unternehmensweites Prozessmanagement“ [1] von den Autoren Dirk Slama und Ralph Nelius. Die dort beschriebene Methodik wird durch die Öffnung für weitere BPM-Anwender und -Experten nun gemeinsam weiterentwickelt und beispielsweise um agiles BPM und Adaptive Case Management erweitert.

Aufbau des BPMF 2.0 und adressierte Projektarten

Die allermeisten Prozessoptimierungen setzen die Durchführung von Projekten voraus. Die effiziente Durchführung von BPM-Projekten ist dabei Grundlage für eine Verbesserung auf der Businessseite. Der Begriff BPM-Projekt wird in der Praxis mit sehr unterschiedlichen Bedeutungen aufgeladen. Grund genug für uns, hier etwas nachzuschärfen.

Abb. 1: Klassifizierung von BPM-Projekten

Abb. 1: Klassifizierung von BPM-Projekten

Abbildung 1 unterscheidet BPM-Projekte nach dem Grad der Automation sowie nach dem Ausmaß von Veränderungen und spannt damit vier Quadranten auf. Zum einen unterscheiden wir reine Organisationsprojekte, bei denen IT-Lösungen keine signifikante Rolle spielen bzw. zunächst nicht im Fokus stehen. Das können zum Beispiel Verbesserungen rein manueller Abläufe oder die komplette Neugestaltung von Kernprozessen sein. Auf der anderen Seite können BPM-Projekte auch reine IT-Projekte sein, bei denen die Organisation weniger im Fokus steht. Und hinsichtlich des Veränderungsgrads lassen sich BPM-Projekte klassifizieren in solche, die eher ein niedriges Ausmaß haben und andere, die stark an den Strukturen und Abläufen rütteln.

So ganz trennscharf ist diese Unterteilung in der Praxis natürlich nicht, denn IT- und Organisationsprojekte haben fast immer Wechselwirkungen. Und die Unterscheidung zwischen hohem und niedrigem Ausmaß an Veränderung ist keinesfalls absolut zu sehen, sondern eher stufenlos. Dennoch hilft die Simplifizierung dabei, zu erklären, worauf sich das BPMF fokussiert und worauf nicht.

Wenn wir von BPM-Projekten sprechen, meinen wir BPM-Automationsprojekte mit einer Process Engine, die eher als IT-Projekte zu charakterisieren sind und unten rechts angesiedelt wären, allerdings mit einigen Ausläufern in die drei übrigen Quadranten. Meistens erfordert die Einführung einer neuen BPM-Automationslösung auch entsprechende Anpassungen von Arbeitsabläufen bei den betroffenen Fachbereichen, und oft genug werden damit auch Siloanwendungen integriert oder zumindest Systembrüche überbrückt. Je nach Ausmaß dieser Anpassungen können dabei auch strukturelle Änderungen von Verantwortlichkeiten notwendig und sinnvoll sein.

Oft ist es so, dass Anpassungen von Arbeitsabläufen oder Veränderungen in der Organisationsstruktur auf der Businessseite von einem parallel zum IT-Vorhaben als eigenständiges Projekt begleitet oder zumindest als Teilprojekt gefahren werden. Wohlwissend, dass diese Begleitung auf der Businessseite einen erfolgskritischen Teil eines Gesamtprojekts darstellt, konzentriert sich das BPMF auf den IT-Teil des BPM-Projekts.

Enterprise- und Projektlevel

BPM-Projekte finden in der Regel nicht isoliert statt. Sie werden parallel zu vielen anderen Projekten durchgeführt und haben immer einen Kontext, nämlich das Unternehmen, in dem sie stattfinden. Sie werden als einmaliges Vorhaben aus der Linienorganisation initiiert, werden im Rahmen eines Portfolio-Managements priorisiert, manifestieren einen Teil der Unternehmensstrategie, haben Standards und Guidelines als Rahmen, verändern die Enterprise-Architektur und werden am Ende in die Verantwortung der Linienorganisation übergeben, die sich um den weiteren Lifecycle zu kümmern hat.

Genau an dieser Nahtstelle macht das BPMF 2.0 eine weitere wichtige Unterteilung: Es unterscheidet den Enterprise-Level vom Level des Projekts als solches und gliedert das BPMF 2.0 damit in zwei Teile.

Während sich die Methodikinhalte des Projektlevels auf ein einzelnes BPM-Projekt beziehen, beschreibt der Enterprise-Level, wie eine BPM-Initiative auf Unternehmensebene umgesetzt werden kann. Eine solche Initiative wird natürlich immer unterschiedliche Schwerpunkte haben, beispielsweise den Aufbau eines BPM Competence Centers, die Durchführung eines konkreten Transformationsprogrammes oder den Aufbau einer Prozessorganisation im Unternehmen. Abbildung 2 zeigt die wesentlichen Elemente des Enterprise-Levels.

Abb. 2: Enterprise-Level im BPMF 2.0

Abb. 2: Enterprise-Level im BPMF 2.0

Abhängig von den Schwerpunkten muss die Strategie der BPM-Initiative angepasst werden, vom Business Case bis zur Einführungsstrategie. Häufig werden als Teil einer BPM-Strategie mehrere Projekte zu einem Programm zusammengefasst. In diesem Falle ist es notwendig, dass die Projekte gemäß den Prinzipien einer planvollen Evolution durchgeführt und von einem darauf ausgerichteten Programmmanagement flankiert werden. Das Enterprise-Architektur-Management setzt die strategische Bebauungsplanung um, die die Grundlage für effiziente Transformation einer komplexen Prozess- und Anwendungslandschaft ist. Das BPM-Lifecycle-Management beschreibt, wie der Lebenszyklus der verschiedenen BPM-Artefakte projektübergreifend gesteuert werden kann. Die BPM-Organisation beschreibt den Aufbau einer effizienten Organisation für verschiedene Arten von BPM-Initiativen. Die Bereitstellung einer BPM-Plattform ist die Grundlage für die Umsetzung der BPM-Projekte. Standards und Richtlinien schaffen einen strukturellen Ordnungsrahmen für die BPM-Initiative, der einen wichtigen Beitrag für die planvolle Evolution leistet.

Auch wenn diese Elemente in jeder BPM-Initiative bedacht werden müssen, konzentrieren wir uns in diesem Artikel ausschließlich auf den Projektlevel.

Das Idealprojekt

Jede Methodik, die sich dem Anspruch hingibt, für alle möglichen Arten von Projekten allumfassend geeignet zu sein, wird schnell unverständlich oder so abstrakt, dass sie einem Orientierungssuchenden kaum konkrete Unterstützung geben kann. Das BPMF 2.0 versucht einen anderen Weg, indem es möglichst minimalistisch daherkommt und viele Aspekte explizit ausklammert (etwa die Anteile der Organisation eines BPM-Projekts oder den Enterprise-Level, wenn man nur auf den Projektlevel schaut).

Das BPMF 2.0 trifft daher auch Annahmen über ein idealisiertes BPM-Projekt und schließt somit diejenigen Projekte aus, die ganz anders gelagert sind. Sicher lassen sich dennoch viele Elemente des BPMF auf ähnliche BPM-Projekte anwenden, aber eben unter Umständen nur mit mentaler Transferleistung.

Wir gehen bei Projekten, für die sich das BPMF 2.0 besonders eignet, von folgenden Rahmenbedingungen aus:

Prozesse oder Cases sinnvoll: Manche Unternehmen hegen lediglich eine Vermutung, ein BPM-Projekt mit einer Process Engine könne ihr Problem lösen. Nicht selten stellt sich bei näherer Betrachtung heraus, dass dies gar nicht sinnvoll ist; zum Beispiel, wenn der Wunsch besteht, Maskenabläufe mit einer Process Engine zu steuern, einen technischen Build-Prozess oder triviale Wenn-dann-Reaktionen auf Ereignisse usw. abzubilden. Das ist zwar nicht unmöglich, denn man kann in der Tat viel mit dieser Technologie steuern. Richtig sinnvoll entfaltet sie ihre Stärke aber vor allem dann, wenn folgende Kriterien erfüllt sind (je mehr, desto eher):

  • Wenn es sich um eher unternehmensindividuelle und vor allem fachlich geprägte Prozesse oder Cases mit hoher Wertschöpfung oder Alleinstellung handelt,
  • die Prozesse oder Cases eher komplex sind,
  • die Prozesse oder Cases eher länger laufen,
  • mehrere verschiedene Benutzer bzw. Rollen arbeitsteilig zu koordinieren sind,
  • oder wenn eine größere Zahl von Nachbarsystemen zu integrieren ist.

Betroffene Prozesse müssen bekannt sein: In einigen Fällen treffen wir Situationen an, in denen Unternehmen Probleme mit diversen Prozessen haben. Dann geht die Archäologiearbeit los, um herauszufinden, wo das Problem genau liegt und welche Prozessteile konkret betroffen sind. Diese Arbeit des Identifizierens eines geeigneten Ansatzpunktes klammert das BPMF 2.0 aus und setzt stattdessen voraus, dass das Unternehmen bereits relativ klare Vorstellungen davon hat, welche Prozesse oder Teile davon es für eine Automatisierung mit einer Process Engine vorsieht.

BPMN/CMMN als Modellierungssprache: Ebenso unterstellen wir, dass die Untersuchung einer geeigneten Modellierungssprache nicht Bestandteil des Projekts ist. Stattdessen unterstellen wir konkret die Verwendung von BPMN 2.0 ggf. in Kombination mit CMMN.

Keine Ausbildung von Projektteilnehmern: In einigen Projekten ist es notwendig, betroffene Projektteilnehmer vorab oder während des Projekts mit Know-how über die Technologie bzw. die eingesetzten Modellierungssprachen zu versorgen. Das betrifft z.B. die Fachbereiche, damit sie die erstellten grafischen Modelle interpretieren können. Auch das ist nicht Bestandteil der Methodik.

Einsatz einer Process Engine: Ebenso gehen wir im Idealszenario davon aus, dass eine Process Engine zum Einsatz kommt. Es soll also nicht um eine Grundsatzdiskussion gehen, ob man eine Process Engine nimmt oder nicht, und ebenso wenig behandelt die Methodik die Evaluation einer konkreten Toolkette.

Verwendung einer Servicearchitektur: Ein häufig anzutreffendes Architekturszenario im Kontext von Process Engines ist die Benutzung von Services vielfältiger Couleur. Wir unterstellen, dass das betroffene Unternehmen eine grundsätzliche Architekturentscheidung getroffen hat, mit Services zu arbeiten (Serviceorientierung) und auch, dass dies sinnvoll ist.

Was das BPMF nicht betrachtet

Zu alledem gibt es eine Reihe von Aspekten, die ebenfalls explizit nicht Bestandteil der Methodik sind:

  • Projektmanagement und -planung: Zu jedem Projekt gehört ein gewisses Maß an Planung und Management (ja, auch bei agilen Projekten). Das geht schon mit der Auftragsklärung des Projekts los, setzt sich bei der laufenden Aktualisierung von Plänen fort und endet mit dem sauberen Abschluss. Dazu kommt die Vertretung des Projekts nach außen, das Identifizieren und Eliminieren von Hindernissen, ggf. Restrukturierung der Projektorganisation, Koordination von Zulieferleistungen und einiges mehr. All diese Tätigkeiten braucht jedes Projekt auf irgendeine Weise, deswegen gehen wir in der Methodik nicht explizit darauf ein.
  • Beschreibung von Scrum als Rahmenwerk: Wir setzen voraus, dass das Projekt agil nach Scrum durchgeführt wird. Die Methodik geht dabei nicht auf die einschlägig bekannten Grundlagen zu Scrum ein, sondern setzt Kenntnisse über die Begrifflichkeit als selbstverständlich voraus.
  • Rollout und Betrieb: Jedes agile BPM-Projekt hat zum Ziel, eher früher als später in Betrieb genommen zu werden. Alles, was für den Rollout und den anschließenden laufenden Betrieb der produzierten IT-Lösung an Aktivitäten notwendig ist, klammert die Methodik ebenfalls aus.

Zusammenfassend kann man also sagen: Die Methodik fokussiert auf die Tätigkeiten, die in einem agilen BPM-Projekt nach Scrum im Rahmen der Disziplinen Analyse, Design und technische Umsetzung mit einer modernen Process Engine unter Verwendung von BPMN 2.0 und CMMN nötig sind.

BPM und Case Management

Für die Entwicklung geeigneter Lösungsszenarien ist es wichtig, verschiedene Klassen von Prozessen zu betrachten. Das Spektrum möglicher Prozessarten ist sehr breit. Einige Prozesse sind extrem strukturiert und haben eine hohe Wiederholungsrate, andere sind sehr unstrukturiert und vom Ablauf her jeweils hoch individuell. Drei typische Klassen von Prozessen sind Straight Through Processing (STP) bzw. die „Dunkelverarbeitung“, entscheidungsintensive Prozesse sowie das Case Management (Abb. 3).

Abb. 3: Prozessklassifizierung nach Forrester

Abb. 3: Prozessklassifizierung nach Forrester

STP beispielsweise zeichnet sich durch einen hohen Strukturierungsgrad, hohes Automatisierungspotenzial und oft durch strenge regulatorische Auflagen aus.

Entscheidungsintensive Prozesse haben häufig einen hohen Anteil von Hellverarbeitung, d. h. sie basieren auf Entscheidungen, die von Mitarbeitern kontextsensitiv oder sogar intuitiv getroffen werden müssen bzw. auf Basis von Regeln, die sich nur schwer formalisieren lassen. Beispiele für entscheidungsintensive Prozesse beinhalten Kundenserviceprozesse, die Personalsuche oder auch den Order-to-Cash-Prozess.

Case Management ist das genaue Gegenstück zum STP: Es zeichnet sich dadurch aus, dass die Prozesse sehr dynamisch sind, häufig Ad-hoc-Aufgaben und zumeist recht individuelle Lösungswege beinhalten, die sinnvoll nur durch das Zutun von Wissensarbeitern (Knowledge Worker) gestaltet werden können.

Während man die Modellierung von purem STP üblicherweise mit BPMN 2.0 vornimmt, kommt für die Modellierung zunehmend CMMN ins Spiel, je weiter sich das zu erschaffende Lösungsszenario nach rechts bewegt. Das BPMF 2.0 hat den Anspruch, alle drei Prozessklassen abzudecken.

Die neun Methodikaspekte

In einem typischen BPM-Projekt muss in der Regel eine immer wiederkehrende Menge von BPM-spezifischen Aspekten adressiert werden. Das BPMF 2.0 definiert hierzu in seinem Projektlevel neun Methodikaspekte (Abb. 4).

Abb. 4: BPMF-2.0-Überblick

Abb. 4: BPMF-2.0-Überblick

Die Erfahrung zeigt ebenso, dass man aus zwei Blickwinkeln auf diese Methodikaspekte schauen kann: Zum einen aus einer Prozessperspektive und zum anderen aus einer Serviceperspektive. Wir sagen bewusst nicht fachliche oder technische Perspektive, denn sowohl in der einen als auch der anderen Perspektive spielen jeweils fachliche und technische Belange eine Rolle. Beide Blickwinkel gehen in der Praxis Hand in Hand und stehen gleichberechtigt nebeneinander. Konsequenterweise ist die Anordnung der neun Methodikaspekte kein Zufall, sondern stellt ein Methodentandem aus prozessorientierter Analyse und Design (POAD) sowie serviceorientierter Analyse und Design (SOAD) dar (Abb. 5).

Abb. 5: Methodentandem POAD/SOAD

Abb. 5: Methodentandem POAD/SOAD

Das Hauptartefakt, in dem die Fäden der Prozessperspektive zusammenlaufen, ist das Prozessmodell (Aspekt-Prozess-Modellierung). Es beschreibt geschäftliche Abläufe, Ereignisse, Aktivitäten, Prozessflüsse, Case-Zustände und Konnektoren, die von der zu erstellenden BPM-Lösung umgesetzt werden. Das Prozessmodell verknüpft auch die Aspekte Rollen/Organisation, Taskmanagement, Business Rules (Geschäftsregeln), Monitoring/Reporting und SOA-Komponenten. Das Hauptartefakt, in dem die Fäden der Serviceperspektive zusammenlaufen, ist die SOA-Map aus dem Aspekt SOA-Komponenten. Die SOA-Map beschreibt die Lösungsarchitektur in Form von fachlichen Komponenten und Services, die miteinander gekoppelt sind und Daten austauschen. Die SOA-Map verknüpft außerdem die restlichen Aspekte User Interface, Business Objects/Backend und Infrastruktur/Technik.

Die Aktivitäten in Methodikaspekten

Das BPMF 2.0 beschreibt jeden der neun Methodikaspekte durch jeweils zwei Abschnitte: Im ersten Abschnitt „Grundlagen“ wird ein Überblick über den Methodikaspekt gegeben. Der Leser findet darin die theoretische Basis, die er benötigt, um die nachfolgenden Abschnitte sowie den Sinn des Aspekts zu verstehen.

Der zweite Abschnitt enthält den eigentlichen Kern des Aspekts, nämlich die einzelnen Aktivitäten, die in einem typischen BPM-Projekt für diesen Aspekt wichtig sind. Jede Aktivität ist hinreichend beschrieben und soweit notwendig mit beispielhaften Artefakten versehen. Beispielsweise gibt es im Methodik-Aspekt Prozessmodellierung eine Aktivität namens „Prozessdurchstiche definieren“, die erläutert, wie man auf Basis eines vorher definierten Prozess-Scopes diejenigen Ausschnitte definiert, die dabei helfen, möglichst frühzeitig zu klären, wo grundlegende fachliche und technische Entscheidungen zu treffen sind.

Das Vorgehensmodell im BPMF 2.0

Die Durchführung eines BPM-Projekts nach einem Wasserfallmodell ist denkbar ungeeignet, um die Komplexität und die Dynamik im Umfeld von Geschäftsprozessen zu beherrschen. Zu viele Annahmen müssen im Vorfeld getroffen werden, Fehler und Missverständnisse sind vorprogrammiert, und es besteht ein hohes Risiko, dass erst sehr spät erkannt wird, dass das Modell nicht den Anforderungen der Realität entspricht oder die Implementierung fehlerhaft ist. Auf geänderte oder neue Erkenntnisse, seien sie intern oder extern, kann dann nicht mehr oder nur noch schwer reagiert werden.

Mehr noch: Als kontinuierlicher Verbesserungsprozess, den ein Business Process Management ja darstellt, ist es aus unserer Sicht beinahe fahrlässig, das Projektvorgehen nicht auch entsprechend agil zu gestalten. Aus unseren Praxiserfahrungen haben wir ein passendes Vorgehensmodell entwickelt. Es basiert zwar im Wesentlichen auf Scrum, macht aber in Bezug auf BPM-Projekte einige wichtige Ergänzungen.

Jedes Projekt hat Phasen im Sinne von zeitlichen Abschnitten, in denen sich grundlegend etwas im Projekt ändert. Das gilt auch für agile Projekte. Nur mit dem Unterschied, dass diese Phasen nicht nach Disziplinen wie Analyse-Design-Umsetzung-Test benannt sind. Speziell bezogen auf agile BPM-Projekte definiert das BPMF 2.0 ein Phasenmodell wie in Abbildung 6 gezeigt. Dieses Modell basiert darauf, nach einer kurz gehaltenen Grundlagenphase möglichst schnell in die iterativ-inkrementelle Umsetzung überzugehen.

Abb. 6: Phasenmodell im BPMF 2.0

Abb. 6: Phasenmodell im BPMF 2.0

Grundlagenphase: In der Grundlagenphase werden die drei wichtigen (oder notwendigen) Blickwinkel auf das Projekt (fachlich, technisch und Management) miteinander kombiniert, um einen robusten Projektfokus zu gewährleisten. Aus der Projektvision wird ein grober Überblick der relevanten und beteiligten Prozesse erarbeitet. Dabei wird ein Big Picture in Form von strategischen Prozessmodellen erstellt sowie ein erster Architekturentwurf erarbeitet, worüber alle Projektbeteiligten ein gemeinsames Bild über den Projektkontext erhalten. Die grundlegenden Anforderungen werden in dieser Phase als Epics und User Stories formuliert und in einer Story-Landkarte eingeordnet. Bei der Formulierung der User Stories wird darauf geachtet, dass jede fachlich genau beschreibt, was getan werden soll, und grundlegende Akzeptanzkriterien enthält. Für die Auslieferungen des Produkts wird ein erster Releaseplan erstellt.

Die Grundlagenphase wird in einer festen Forschungs-Timebox durchgeführt. Diese sollte möglichst kurz gehalten werden, um zeitnah mit der Umsetzung beginnen zu können. Die Projektorganisation ist hier noch sehr schlank und besteht aus einem Pilotteam.

Wachstumsphase: Auf die Grundlagenphase folgt die iterativ-inkrementelle Umsetzung innerhalb der Wachstumsphase. Ziel der Wachstumsphase ist, die technischen, prozessualen und organisatorischen Risiken einzudämmen. Der Fokus in dieser Phase liegt also weniger auf der Schaffung von konsequent priorisiertem Geschäftswert, sondern darauf, alle großen Herausforderungen so früh wie möglich zu kennen, zu adressieren und darüber Stabilität in die angedachte Lösung zu bekommen. Die fachlich-konzeptionelle Modellierung und die Implementierung werden daher von spezialisierten Challenge-Teams vorgenommen. Die Arbeitsweise dabei erfolgt in versetzten Sprints, da naturgemäß in dieser Phase der Aufwand für grundlegende Klärungen mehr zeitlichen Vorlauf benötigt als zu einer späteren Phase, wo sich technische und fachliche Architektur stabilisiert haben. Konkret bedeutet das: Ein Konzeptionsteam leistet Konzeptionsarbeit und hat dabei einen Sprint Vorlauf vor dem Implementierungsteam.

Wichtig sind dabei die räumliche Nähe der Teams und ein stetiges, wechselseitiges Feedback. Ziel der Wachstumsphase ist es, den Prozessdurchstich zu schaffen, d. h. die grundlegenden Prozesse soweit stabil zu gestalten, dass der konzeptionelle Vorlauf sukzessive abgebaut werden kann. Die Priorisierung aller Arbeiten orientiert sich dabei vor allem an den Projektrisiken, seien sie technisch, fachlich oder soziologisch.

In der Wachstumsphase durchläuft jede User Story erst die Modellierung, indem die genaue fachliche Spezifikation erarbeitet wird. Hierzu zählen die operativen BPMN-Prozessmodelle, Spezifikation der Geschäftslogik, Use Cases sowie Vorgaben für die Benutzungsoberflächen. Die Domänen- und Softwaremodelle werden verfeinert, die Services in der Servicelandkarte verortet. Darüber hinaus werden die Akzeptanzkriterien ausformuliert und die erste Dokumentation erarbeitet. Während der Modellierung findet die Detaillierung der User Story statt, sodass gegebenenfalls Teile als neue Stories für die Anforderungsliste geschrieben werden. Hier zeigt sich der Vorteil eines iterativ-inkrementellen Vorgehens: Oft werden erst bei der eigentlichen fachlichen Ausarbeitung neue Aufgaben identifiziert, die anschließend priorisiert in den folgenden Sprints bearbeitet werden können.

Die Artefakte des Modellierungssprints bilden die fachlichen Grundlagen für die Implementierung und werden für die technische Realisierung der User Story verwendet. Das Ergebnis der Implementierungssprints ist die lauffähige Software.

Reifungsphase

Nachdem die wesentlichen Prozesse grundlegend umgesetzt sind und ein Durchstich erreicht ist, geht das Projekt in eine Reifungsphase über. Ziel dieser Phase ist es, das System Stück für Stück zur kompletten Lösung auszubauen. Bei der Umsetzung von Anforderungen wird nun auf die Erzeugung von Geschäftswert fokussiert. Auch hier wird weiterhin iterativ-inkrementell vorgegangen, jedoch kann (und sollte) die Trennung von Modellierung und Implementierung in versetzten Sprints jetzt aufgelöst werden. Ein oder mehrere interdisziplinäre Featureteams arbeiten nun in geschlossenen Iterationen, um das Produkt featurebasiert weiterzuentwickeln (z. B. Entwicklung weiterer Prozessvarianten oder Automatisierungs- und Optimierungsvorhaben). Dies ist jetzt möglich, weil die grundlegenden Unklarheiten beseitigt sind und sich die Kommunikationsstrukturen eingependelt haben. Dadurch ist der zeitlich benötigte Vorlauf zur Klärung von Anforderungen geringer und kann innerhalb desselben Sprints erfolgen, in dem auch die Umsetzung erfolgt.

Strikte Regeln, wann die Wachstumsphase in die Reifungsphase übergeht, gibt es nicht. Am ehesten lässt sich das Ende der Wachstumsphase daran festmachen, dass die wichtigsten Projektrisiken ausreichend adressiert sind und/oder dass das Produkt einen grundlegenden Funktionsumfang erreicht hat, der einen Einsatz im produktiven Betrieb erlauben würde. Ein weiterer Indikator ist, dass sich der konzeptionelle Vorlauf soweit reduziert hat, dass die versetzen Sprints wie auch die Teams zusammengeführt werden können.

Die Einkaufslisten

Die Beschreibungen der Aktivitäten in jedem der neun Methodikaspekte sind eher universell gehalten. In der Praxis ist es allerdings so, dass eine Aktivität mit unterschiedlicher Schwerpunktsetzung und Ausprägung stattfindet, je nachdem, wie weit das Projekt zeitlich und inhaltlich fortgeschritten ist. Beispielsweise wird man sich im Methodikaspekt „Rollen/Organisation“ bei der Aktivität „Rollen mit Berechtigungen versehen“ am Anfang des Projekts (in der Wachstumsphase) eher darauf konzentrieren, dass das Berechtigungskonzept prinzipiell funktioniert, während man im fortgeschrittenen Stadium des Projekts (in der Reifungsphase) den Fokus darauf legt, z. B. mithilfe von destruktiven Tests zu gewährleisten, dass das Berechtigungskonzept fehlerfrei umgesetzt wird.

Das Vorgehensmodell des BPMF 2.0 enthält daher zum einen für jeden Methodikaspekt eine tabellenartige Zuordnung seiner Aktivitäten zu den jeweiligen Phasen. Vergleichbar mit einer Einkaufsliste, die man in einen Laden mitnimmt, hat der Leser damit einen guten Überblick in der Hand, welche Aufgaben jetzt wichtig sind, um ein BPM-Projekt erfolgreich durchzuführen.

Ein Ausschnitt aus dem Methodikaspekt Prozessmodellierung sieht in etwa wie folgt aus:

Grundlagenphase:

  • Prozessüberblick für Scope erstellen
  • Gegebenenfalls Ist-Prozessinhalte grob skizzieren
  • Soll-Prozessinhalte grob skizzieren
  • Grundsatzentscheidung bzgl. Case-Anteil treffen
  • Prozessdurchstich(e) definieren

Wachstumsphase:

  • Prozessdurchstich(e) fachlich modellieren

Wachstums- und Reifungsphase:

  • Prozessmodelle vervollständigen
  • Prozessmodelle ausführbar machen

Einige Aktivitäten können eindeutig einer Phase zugeordnet werden, weil sie nur dort den größten Sinn entfalten, beispielsweise ist es sinnlos, den Prozess-Scope erst am Ende des Projekts zu definieren. Andere Aktivitäten kommen aber auch in mehreren Phasen vor, z. B. die Vervollständigung von Prozessmodellen oder Ausschnitten davon. Aus diesem Grund beschreibt das Vorgehensmodell neben der Zuordnung von Aktivitäten zu Phasen zum anderen auch, inwiefern sich die Aktivitäten je nach Phase unterschiedlich ausgestalten lassen.

Ausblick: Wie funktioniert die Weiterentwicklung des BPMF 2.0?

Wie Eingangs dargestellt, basiert das BPMF 2.0 in seinen Grundlagen auf dem Buch „Enterprise BPM“. Die Alliance hat die Nutzungsrechte an der Methodik von den Autoren erworben, die natürlich auch weiterhin aktiv an der Weiterentwicklung der Methodik beteiligt sind. 2014 fand eine Reihe von Workshops statt, in denen das bestehende Material gesichtet und auf seine Tauglichkeit im Hinblick insbesondere auch auf agiles Projektvorgehen beleuchtet wurde. Dabei hat sich schnell herauskristallisiert, dass der Mehrwert des BPMF 2.0 darin bestehen wird, eine möglichst prägnante und kurz gefasste Anleitung für alle BPM-Anwender im oben beschriebenen Sinne zu liefern, deren Inhalte von der deutschen BPM-Community mit vielen und langjährigen BPM-Experten im Konsens mitgetragen und vor allem auch aktiv proklamiert werden. 2015 läuft daher eine lange Serie von Workshops, in denen die neun einzelnen Methodikaspekte diskutiert werden, mit dem Ziel, einen Konsens aus den praktischen Erfahrungen aller Teilnehmer (aus den unterschiedlichsten Kontexten und Firmen) zu erzeugen. Dabei sind einige Teilnehmer stabil und werden durch jeweils wechselnde Experten zu größeren Teams ergänzt. Erklärtes Ziel ist es, dass die gesamte Enterprise BPM Alliance mit allen ihren Protagonisten anschließend guten Gewissens ihr Okay für die Version 2.0 des BPMF geben kann und die Erkenntnisse im Alliance-Wiki in Projekten, Trainings und Coachings weitergibt.

Fazit

Wir glauben, dass BPM in all seinen Facetten einen wesentlichen Beitrag zum Unternehmenserfolg leisten kann. Eine gute BPM-Methodik sorgt dafür, dass BPM-Vorhaben strukturiert und effizient umgesetzt werden. Ebenso wie die Bedeutung von BPM-Vorhaben zunimmt, sollte auch die Güte der Vorgehensmethodik wachsen und dem aktuellen Stand der Erkenntnisse entsprechen. Insbesondere die Weiterentwicklungen im Bereich der agilen Vorgehensmodelle sind hier zu nennen, die wir mit der Enterprise BPM Alliance vorantreiben wollen. Wir sind ein unabhängiger Zusammenschluss von BPM-Anwendern und verfolgen das Ziel, unsere praktischen Erfahrungen in einer offenen BPM-Methodik – dem Business Process Management Framework (BPMF) – zu bündeln, an der sich Menschen bei der Durchführung von BPM-Vorhaben orientieren können. Grundlage des BPMF bildet das Buch „Enterprise BPM“. Darin sind bereits eine ganze Reihe von Erkenntnissen konserviert, die aus konkreten BPM-Umsetzungsprojekten wie auch aus projektübergreifenden, meistens unternehmensweiten BPM-Initiativen stammen. Das in dem Buch beschriebene BPM-Framework wollen wir gemeinsam weiter ausbauen und für die Praxis besser nutzbar machen.

Aufmacherbild: Orange Business Processes Button via Shutterstock / Urheberrecht: Tashatuvango

Verwandte Themen:

Geschrieben von
Christian Weiss

Christian Weiss ist Managing Consultant bei Holisticon AG und berät und betreut BPM/SOA-Projekte. Dabei liegen ihm die Einführung flinker, automatisierter Geschäftsprozesse und agiler Praktiken sehr am Herzen. Seine Ideen und Erfahrungen sind in einige Fachbücher geflossen. Außerdem ist er Vorstandsmitglied und Mitgründer der Enterprise BPM Alliance.

Dirk Slama

Dirk Slama ist Director of Business Development bei Bosch Software Innovations (SI). Mit mehr als zwanzig Jahren Erfahrung in sehr großen IT- und Change-Projekten im Umfeld SOA, BPM, M2M und zuletzt IoT und internationaler Arbeitserfahrung spricht er regelmäßig auf Konferenzen und ist Mitautor von vier Büchern. Außerdem ist er Vorstandsvorsitzender und Mitgründer der Enterprise BPM Alliance.

Kim Nena Duggen

Kim Nena Duggen ist als Vorstand und Trainerin/Beraterin in den Bereichen Unternehmensarchitektur, Geschäftsprozessmanagement, Requirements Engineering und Soft-Skills bei der Firma oose Innovative Informatik eG tätig. Außerdem ist sie Vorstandsmitglied und Mitgründerin der Enterprise BPM Alliance sowie Konferenzspeakerin und Autorin von Fachbeiträgen.

Torsten Winterberg

Torsten Winterberg analysiert für das Projekthaus OPITZ CONSULTING im Business Development & Innovation Team Trends und Technologien, um innovative Lösungen mit Kundenwert liefern zu können. Als Mitglied des Leitungsteams des SOA/BPM Competence Centers erarbeitet er Kundenlösungen im Bereich von Integration und Prozessautomatisierung und ist außerdem Mitgründer der Enterprise BPM Alliance.

Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: