BPM-basierende Prozessmodellierung

Wie Geschäfts- und IT-Prozesse harmonieren

Elena Luccone arbeitet dort als BPMSystem- Consultant.
Eileen Hildebrand ist BPM-Consultant bei der Materna GmbH in Dortmund.
Zehn Kriterien können darüber entscheiden, ob die Anforderungen der Fachbereiche und die Umsetzung durch die IT überhaupt zusammenpassen.

Kern der Geschäftsprozessanalyse sind die fachlichen Anforderungen der Fachabteilungen. Klassischerweise verfassen die Beteiligten ihre Wünsche an die zu modellierenden Geschäftsprozesse in natürlicher Sprache, unterstützt durch Bilder oder Skizzen.

Foto: S.John, Fotolia.com

Dieser etablierte Ansatz führt in der Praxis oft zu Missverständnissen, und im Lauf der Zeit stellt er ein Fehlerrisiko dar. Formulieren die Beteiligten ihre Anforderungen nicht alle nach denselben Regeln, gibt es zu viel Raum für Interpretationen: Sachverhalte und Abhängigkeiten werden dann oft nicht eindeutig genug beschrieben.

Die BPM-basierende Prozessmodellierung zielt folglich darauf ab, dass alle Beteiligten dieselbe Sprache sprechen. Dabei sind alle durch die Modelle abzubildenden Informationen für die spätere Implementierung von IT-Systemen von Bedeutung. Auch das Prozessmodell ist für die IT wichtig - spätestens dann, wenn der Fachprozess ausgeführt werden soll.

Der wichtigste Erfolgsfaktor eines BPM-Projekts ist aus diesem Grund das gemeinsame Verständnis vom Geschäftsprozess-Ablauf und vom Verhalten eines IT-Systems. Die nachfolgenden zehn Tipps können den Unternehmen helfen, dieses gemeinsame Verständnis zu gewinnen und aufrechtzuerhalten.

1. Verborgene Schätze gemeinsam heben: Prozessanalyse mit BPMN

Business Process Model and Notation, kurz BPMN, ist eine global standardisierte Sprache für die Modellierung von Geschäftsprozessen - und damit ein wichtiger Baustein für die erfolgreiche Zusammenarbeit zwischen Fach- und IT-Abteilung. Die Mächtigkeit der aktuellen Version BPMN 2.0 ermöglicht es, auch komplexe fachliche Zusammenhänge vollständig und korrekt darzustellen. BPMN 2.0 erfüllt damit die Anforderung der IT nach Präzision.

Dennoch sind einige Anforderungen nicht aus dem BPMN-Modell ablesbar und müssen beispielsweise als Text beschrieben werden. Dazu zählen vor allem die nichtfunktionalen Anforderungen wie Performance.

Ein BPM-Vorhaben beginnt selten "auf der grünen Wiese". Meist existieren bereits Beschreibungen der fachlichen Zusammenhänge in Textform. Soweit möglich, dienen diese als Startpunkt der Modellierung mittels BPMN. Erfahrungsgemäß deckt schon dieser erste Schritt die vorhandenen Lücken in den bisherigen Anforderungen auf. Die Rücksprache mit der Fachseite oder das Testen des vorhandenen Systems vervollständigt die Prozessabläufe weiter.

2. Wir kennen dich schon: Konventionen und Muster

Die Verwendung von Konventionen - für die grafische Darstellung wie für die Modellierung selbst - trägt entscheidend dazu bei, den Einstieg in die BPMN-Welt zu erleichtern. Die Definition fachlicher Muster sorgt zudem für höheren Wiedererkennungswert.

Fachliche Muster sowie viele Konventionen sind projektspezifisch beziehungsweise werden auf die fachlichen Besonderheiten eines IT-Systems abgestimmt. Schaffen IT- und Fachseite die BPMN-Modelle gemeinsam, beispielsweise im Rahmen von Workshops, lassen sich grundlegende Konventionen vereinheitlichen. Auch spezifische Konventionen und fachliche Muster sollten Schritt für Schritt gemeinsam erarbeitet werden.

3. Was können wir wiederverwenden? - Der Serviceschnitt

Oft beginnen BPM-Projekte mit der Eingrenzung des richtigen Serviceschnitts. Ist die Granularität der Prozessschritte zu grob, sind die Services später nicht optimal wiederverwendbar; sie lassen sich schlechter auswerten und gewähren weniger Einsicht in den Prozess. Sind die Schritte zu feingranular, leidet die Performance darunter.

Sinnvoll ist es, vorhandene Software als eigenständige Services zu betrachten, die die Fachseite im Prozessmodell verwendet. Ist keine Software vorhanden, orientieren sich die Services an den von der Fachseite modellierten Aktivitäten. Fach- und IT-Seite sollten immer in engem Dialog stehen.

4. Es gibt jemanden, der weiß, wie das geht: Competence-Center

Es empfiehlt sich, ein zentrales BPM-Competence-Center im Unternehmen zu definieren, das alle Anforderungen für den Umgang mit BPM und BPMN sammelt. So ist ein homogener Einsatz von Methoden und Konventionen gewährleistet.

Neue Projekte oder Bereiche profitieren damit sofort von dem gesammelten Wissen. Unternehmensweite BPM-Vorgaben und -Standards lassen sich besser einhalten.

5. Klein anfangen und alle mitnehmen: Der Pilot

Unternehmen unterschätzen häufig die Auswirkungen von BPM: Beim Geschäftsprozess-Management geht es nicht nur um Werkzeuge und Technik. BPM ist vielmehr eine Philosophie der Transparenz und Offenheit, an die viele Unternehmen erst her-angeführt werden müssen.

Des Weiteren erfordert BPM die Zusammenarbeit über Bereichsgrenzen hinweg. Das stößt bei Fach- und IT-Abteilungen eher auf Unbehagen. Einer der Gründe dafür ist die Angst, das eigene Hoheitsgebiet aufzugeben.

Daher ist es sinvoll, mit einem BPM-Piloten zu starten. So sammeln alle Beteiligten technische Erfahrungen und motivieren mit positiven Rückmeldungen andere Abteilungen. Für den Einstieg sind nicht etwa einfache, unkritische Prozesse am besten, sondern ein Kernprozess, an dem Verbesserungen gut sichtbar und messbar sind.

6. Vom Prozess zur Anwendung: Die Umsetzung

Grundlage für die technische Ausführung von Prozessen sind vollständige und korrekte fachliche Modelle, die dann mit technischen Details angereichert werden. Die Fachseite muss ihre Modelle auch in ihrer technischen Umsetzung wiedererkennen. Aus technischen Gründen notwendige Änderungen am Modell müssen mit der Fachseite besprochen werden. Für die Umsetzung in Software definiert die IT-Seite Datenmodell, Benutzeroberflächen und Anbindung von ausführbarem Code wie etwa Web-Services.

In diesem Zusammenhang ist der Begriff "Zero Coding" weit verbreitet. Fälschlicherweise wird angenommen, dass sich die bestehenden Komponenten einfach zusammenstecken ließen - ohne viel Aufwand. Die Realität sieht aber anders aus.

Jeder Web-Service und jede gekapselte Funktion müssen implementiert werden. Wizards unterstützen die Entwickler bei der Erstellung von Services und Benutzeroberflächen, doch die Komplexität der fachlichen Anforderungen übersteigt häufig die Möglichkeiten eines Wizards. Auch wenn vorhandene Software einsetzbar ist oder Geschäftsregeln durch Services implementierbar sind, bedarf die Umsetzung der Prozesse eines tiefen technischen Verständnisses - und einiger Zeit. Zu Zeitersparnissen führt BPM in späteren Phasen, sprich: bei Änderungen an den Prozessen.

7. Es läuft und ist sichtbar: Betrieb und Überwachung

Dank BPMN existiert ein Modell, das sowohl Fachseite als auch IT verstehen. Wird es in einer Process Engine umgesetzt, ist der Geschäftsprozess in Test und Betrieb wiedererkennbar. Mit Hilfe von "Marken" werden beim fachlichen Testen die unterschiedlichen Wege im Prozess durchlaufen. Dabei aufgetretene Probleme lassen sich anschließend mit der Fachseite besprechen - und beheben.

Prozessdaten aus zurückliegenden Zeiträumen werden auf herkömmliche Weise ausgewertet. Für die Echtzeitüberwachung bieten die Hersteller von BPM-Suiten ebenfalls eine Reihe von Möglichkeiten an: Beobachtbar sind sowohl einzelne Prozessinstanzen als auch die Daten aller laufenden Instanzen. Dashboards stellen beispielsweise die Echtzeitdaten nach dem Ampelsystem dar; Fach- und IT-Seite können dann bei Problemen sofort reagieren.

8. Das geht noch besser: Optimierung und Änderung

Ein Geschäftsprozess oder eine Software werden einmal erstellt, aber im Lauf der Nutzungszeit mehrfach geändert. Daher haben Änderungen den größten Anteil am Entwicklungsaufwand. Durch ein gemeinsames Prozessmodell und die Verwendung von Regelservices lassen sich Optimierungspotenziale leichter identifizieren.

9. Wie war das noch mal? - Die Dokumentation

Auch wenn BPMN ein besseres Verständnis der Geschäftsprozesse anbietet, stellen Prozessmodelle keine ausreichende Dokumentation dar. IT- und Fachseite müssen festhalten, wie die Anforderungen an Geschäftsprozesse und Services umgesetzt wurden. Gerade bei BPM ist es wichtig, die Konzepte, die Methodik und die Abweichungen vom Standardvorgehen aufzuschreiben. So bleiben einmal getroffene Entscheidungen auch nach längerer Zeit noch nachvollzieh- und überprüfbar.

10. Der Weg von A nach B: Die fachliche Migration

Zur technischen Migration gehören das Wechseln vom bestehenden System in die BPM-Welt und das Ausrollen neuer Softwareversionen mittels BPM-Methoden. Im Rahmen der fachlichen Migration werden die Modelle fortentwickelt - zu einer neuen Phase im Prozesslebenszyklus.

Meist verlangt die Fachseite, dass sich im Notfall jederzeit in einen Prozess eingreifen lässt. Es ist aber nicht immer sinnvoll oder möglich, diese Anforderung umzusetzen. Auch deshalb müssen Fachseite und IT dasselbe Verständnis hinsichtlich des Vorgehens in der BPM-Methodik haben. (qua)