Wer beschäftigt sich mit BPMN und warum?

Die Teilnehmer der Seminare lassen sich grob in drei Gruppen einteilen. Bei der ersten Gruppe handelt es sich um Prozessmanager, die eine geeignete Notation suchen, die als unternehmensweiter Standard eingesetzt werden kann. Zumeist gibt es bereits Erfahrungen mit verschiedenen anderen Notationen, die aber nur an einzelnen Stellen eingesetzt worden sind. Im Sinne einer durchgängigen Modellierung soll nun eine einheitliche Notation gefunden werden, die möglichst von Business und IT gemeinsam verwendet werden soll. Oftmals leiden bislang eingesetzte Notationen auch unter Akzeptanzproblemen bei den Mitarbeitern, die in der Vergangenheit von riesigen, nicht immer realitätsnahen “Prozesstapeten” abgeschreckt wurden. Zwar liegt es häufig nicht an der Notation, sondern an den Modellierern, wenn derart unübersichtliche und eigentlich nicht verwendbare Modelle entstehen, doch ermöglicht es eine neue Notation, die nocht nicht mit schlechten Erfahrungen der Mitarbeiter belastet ist, eine bessere Akzeptanz für neue Initiativen zu gewinnen. Unabhängig von der neu ausgewählten Notation ist es natürlich wichtig, die bisherigen Fehler nun zu vermeiden. Die Verwendung der BPMN schützt noch nicht vor schlechter Modellierung.

Die zweite Gruppe von Teilnehmern stammt aus internen Beratungsabteilungen großer Konzerne. Hier werden bisher oftmals unterschiedliche Notationen eingesetzt. Oft gibt der interne Kunde Tools und Methoden vor, oder die aus Anwendern und Beratern gebildeten Projektteams entscheiden selbst, wie sie Prozesse und Anforderungen dokumentieren. Die Berater möchten ihre Methodenkompetenz verbessern und ihre Kunden beim Aufbau eines durchgängigen Prozessmanagements unterstützen. Hierzu benötigen sie geeignete Vorgehensweisen und einheitliche Notationen, die nicht nur im Rahmen von Einzelprojekten einsetzen lassen.

Die dritte Gruppe von BPMN-Interessenten kommt aus den IT-Abteilungen. Angesichts zunehmender Anforderungen an die IT, Business-Anforderungen schnell umzusetzen und konkret nachweisbaren Nutzen für das Business zu schaffen, sind sie daran interessiert, die Anforderungsermittlung durch eine gemeinsame Sprache mit dem Business zu verbessern. Außerdem beschäftigen sie sich zunehmend mit SOA-Projekten und setzten hierbei auch Process Engines ein. Da in diesem Bereich die BPMN eine große Rolle spielt, fragen sich die IT-Abteilungen, wie fachliche Prozessmodelle in ausführbare Prozessbeschreibungen umgesetzt werden können.

Wie wird die Eignung der BPMN eingeschätzt?

Praktisch alle Teilnehmer äußerten sich positiv über die BPMN. Die Art der Prozessdartstellung durch die BPMN-Grundkonstrukte wird als angenehm und gut verständlich empfunden. Dies gilt für Business-orientierte Teilnehmer ebenso wie für Mitarbeiter aus der IT. Auch die Besonderheiten der BPMN, wie die Verwendung verschiedener Typen von Ereignissen und die Modellierung des Nachrichtenaustauschs zwischen verschiedenen Prozessbeteiligten wird als interessant und nützlich angesehen. Interessanterweise äußerten sich IT-Vertreter skeptisch über das Verständnis dieser erweiterten Konstrukte seitens der Fachmodellierer, wohingegen diese in den Seminaren zumeist keine großen Probleme hatten, diese Konzepte zu verstehen und anzuwenden.

Kaum ein Teilnehmer konnte sich vorstellen, die noch spezielleren BPMN-Konstrukte wie z. B. Exceptions oder Transaktionen einzusetzen – es sei denn im Rahmen der Modellierung ausführbarer Prozesse für eine konkrete Process Engine.

Meist wurde die Erwartung geäußert, zunächst mit den grundlegenden Elementen zu beginnen, wie Aktivitäten, Sequenzfluss, Gateways, Pools und Bahnen. Auch oder gerade weil sich diese Elemente kaum von herkömmlichen, einfachen Flussdiagrammen unterscheiden, wird hierfür eine hohe Akzeptanz erwartet. Der Vorteil der BPMN ist in diesem Fall einfach die Tatsache, dass es sich um einen Standard handelt. Dadurch ist einerseits die Bedeutung der jeweiligen Elemente recht klar definiert, andererseits wird Wildwuchs in der Modellierung verhindert.

Für den Einsatz der BPMN zur fachlichen Prozessmodellierung wird insbesondere noche eine gute Integration mit anderen Modellierungssichten (z. B. Organigramme, Daten- oder Fachbegriffsmodelle, Anwendungssystemlandschaften) vermisst. Hier weisen aktuelle BPMN-Tools ebenfalls Defizite auf: Tools zur Unternehmensmodellierung mit unterschiedlichen, miteinander integrierten Sichten bieten bislang oft keine komplette Umsetzung der BPMN. Auf der anderen Seite gibt es hervorragende Tools zur spezifikationskonformen BPMN-Modellierung, die aber meist keine Integration anderer Sichten ermöglichen.

Prinzipiell bestätigen die Erfahrungen aus den Seminaren, dass sich die BPMN als gemeinsame Prozess-Sprache für Business und IT eignet. Allerdings beseitigt alleine die Nutzung einer gemeinsamen Sprache noch nicht die Möglichkeit, sich misszuverstehen. Das ist nicht anders als mit natürlichen Sprachen: Auch wenn zwei Menschen Deutsch sprechen, ist noch nicht sichergestellt, dass der eine versteht, was der andere sagen will.

Auf Grundlage des beschriebenen Seminars ist mittlerweile ein kleines Büchlein entstanden, bislang die einzige BPMN-Einführung in deutscher Sprache (Infos zum Buch).

Dem Modell zufolge findet die Preisbildung für Schweine als Wechselspiel zwischen übermäßigen Investitionen (steigendes Angebot, das zu fallenden Preisen führt) und übermäßigen Desinvestitionen (sinkende Produktionskapazitäten, die zu steigender Nachfrage führen) statt. Da sich die Angebots- und Nachfrageseite durch Versuch und Irrtum einander nähern und am Ende ein Preis zustande kommt, der keine Erwartungen mehr enttäuscht, gleicht der Zyklus einem Pendel, das immer schwächer ausschlägt und irgendwann zur Ruhe kommt.

Zwar gilt dieses Modell in den Wirtschaftswissenschaften inzwischen als teilweise überholt (siehe auch das nicht weniger unterhaltsame “Saure-Gurken-Problem”). Das Prinzip des Einpendelns lässt sich jedoch in ähnlicher Form vorrangig in solchen Märkten beobachten, die von Visionen, Erwartungen, Enttäuschungen und Skeptizismus geprägt sind.

In der letzten Zeit wurden wir mit der Vision ausgestattet, dass uns BPM in Kombination mit SOA in die Lage versetzen wird, auf der Business-Ebene Prozesse zu gestalten, und diese auf Knopfdruck in der IT abbilden (ausführen, automatisieren), überwachen und steuern zu können. Dank nicht-proprietärer Methoden wie BPMN und BPEL sollte diese Vision Vendor-unabhängig funktionieren. Es entstand die Erwartung, dass wir in Kürze mit den entsprechenden Tools versorgt werden, um diese Vision Wirklichkeit werden zu lassen. Und tatsächlich, es traten Hersteller auf den Plan, die (zumindest im Marketing-Material) glaubhaft versicherten, die entsprechende Lösung anbieten zu können. Jedoch führten die ersten Praxisprojekte zu Enttäuschungen, die sich u.a. auf Defizite in der Organisation, in der Kompetenz, aber natürlich auch in den Tools zurückführen lassen. Im Ergebnis hat das gebrannte Kind natürlich Angst vorm Feuer, und die Skepsis ist emotional verankert.

Auf den ersten Blick stellt sich jetzt eine einfache Kernfrage: Ist die Vision in der Sache verfehlt, oder existieren Defizite in der Realisierung, die abgebaut werden können? Um diese Frage dreht sich die aktuelle Diskussion, und sie ist geprägt von zwei Fraktionen, nämlich denen, die dringend etwas verkaufen wollen, und denen, die sich dazu berufen fühlen, genau dies zu verhindern (manchmal, nicht immer, weil sie etwas anderes verkaufen wollen).

Auf den zweiten Blick, und diesen möchte ich vertreten, stellt sich – völlig unabhängig davon – die Frage, ob die Vision überhaupt vollständig realisiert werden muss, um faktische Vorteile zu generieren. Im Grunde geht es doch nur darum, einige Methoden und Tools zu entwickeln, um informationszentrierte Prozesse besser (einfacher, schneller und flexibler) realisieren und betreiben zu können. Dafür ist es doch gar nicht zwingend erforderlich, einen Prozess vom Anfang bis zum Ende und von Top bis Down durch das Business so modellieren zu lassen, das eine Engine das Modell sofort verwerten kann. Es reicht völlig, für bestimmte Aspekte im Prozess neue Konfigurationsmöglichkeiten bereit zu stellen, für deren Handhabung man kein Programmierer sein muss. Das Business Rules Management geht genau in diese Richtung, und wer mir erzählen will, Business Rules hätten mit BPM nichts zu tun, hat entweder noch nie ein Prozessmodell mit Verzweigung gesehen (Business), oder eine if-then-Abfrage gebaut (IT). Für diesen Zweck (die abgestufte Automatisierung, nicht das BRM) ist die BPMN eine absolut praxistaugliche Methode, wobei auch ich den Mehrwert des Mappings auf BPEL in der derzeitigen Form sehr infrage stellen würde.

Und SOA, die heilige Kuh der IT-Architekten, kann als eigenständige Methode völlig unabhängig von BPM natürlich ganz fantastisch funktionieren. Das Problem bei SOA ist einfach nur, dass der Begriff inzwischen für alles und jeden herhalten muss (Prof. Dr. Robert Winter aus St. Gallen bemerkte, in Anspielung auf den OOP-Hype vor 20 Jahren, unlängst, dass seine Katze inzwischen ebenfalls service-orientiert sei). Es gibt eben das SOA-Paradigma auf der reinen Software-Ebene, und es gibt bestimmte Aspekte des Paradigmas, die in Kombination mit BPM in der Entwicklung und im Betrieb einer IT-Architektur bestimmte Vorteile generieren können (aber nicht müssen). Der vorgenannte Professor hat mit seiner Differenzierung des Begriffes (SOA auf Software-Ebene, auf Prozessebene, und auf der Agilitätsebene dazwischen) einen meines Erachtens extrem wichtigen Beitrag geleistet, um die diversen Meinungen ein wenig sortieren zu können. Und es ist halt so, dass wir auf der Software-Ebene inzwischen schon ziemlich weit sind in Bezug auf unser Verständnis, “wie es funktioniert”, auf der Agilitätsebene hingegen immer noch im Sandkasten spielen, und von der Prozessebene noch träumen dürfen. Das muss man bedenken, aber es ist kein Drama.

Die Essenz:

Ich kann aus dem Stand heraus eine ganze Reihe von Vorteilen aufzählen, die sich – hier und jetzt – mit Prozessautomatisierung bzw. einer BPM/SOA-Kombination realisieren lassen. Das sind keine weltbewegenden Dinge, aber sie schaffen Mehrwert, und sie sind auch heute schon mit vertretbaren finanziellen Aufwänden realisierbar – ich weiß das, weil ich es getan habe. Ich glaube, wir können uns Schritt für Schritt unserer Vision annähern, wo es aktuellen Mehrwert bietet, und solche Schritte vermeiden, die nicht praktikabel sind. Und sollte sich auf unserem Weg herauskristallisieren, dass unsere Vision in der jetzigen Form gar nicht sinnvoll ist, dann kann auch diese nachgebessert werden.

Der Begriff “Learning by Doing” stammt von Robert Baden-Powell, dem Gründer der Pfadfinderbewegung. Dort werden 15-jährige Gruppenleiter mit 3-8 Gleichaltrigen, für die sie Verantwortung tragen, auf mehrwöchige Großfahrten ins Ausland geschickt. Trotz fehlender Erwachsener gibt es weder Alkohol- noch Drogenexzesse (zumindest keine schlimmen), und der Weg durch die Wildnis wird mit Wagemut, Karte und Kompass bewältigt. Ich habe nie wieder in so kurzer Zeit so viel gelernt, wie in meiner Zeit als Pfadfinder.

Was wir meiner Ansicht nach für BPM-SOA brauchen ist die richtige Einstellung sowie die Kompetenz, mit “Karte und Kompass” umzugehen. Dann werden uns weder blinde Euphorie noch Schwarzmalerei daran hindern, fatale Fehler zu vermeiden und echte Chancen zu ergreifen.

Traditionell wird Geschäftsprozessmanagement als Management-Disziplin verstanden, die Unternehmen bei der kontinuierliche Verwaltung ihrer operativen Geschäftsprozesse unterstützt. Daneben wird BPM aber auch als Technologie zur Beschreibung, Steuerung, Ausführung und Überwachung von Prozessen, inkl. der Einbindung von Mensch und Maschine, im Sinne von Workflow einerseits und Systemintegration andererseits gesehen. Die Umsetzung von grafisch modellierten Geschäftsprozessen in ausführbaren Code in Form eines automatisierten Prozesses stellt hierbei die größte Herausforderung dar.
Der Grundgedanke einer SOA verspricht durch die Bereitstellung von Standards auch den entsprechenden Technologieplattformen Nutzen. Im Rahmen einer SOA sind im Wesentlichen zwei Ebenen zu unterscheiden: Die erste Ebene dient dazu, Services durch die Basisapplikationen bereitzustellen. Die zweite Ebene unterstützt die Konsumierung von Services, im Weiteren auch Service-Orchestrierung genannt. Gerade bei der zweiten Ebene spielen BPM Technologiekomponenten zur Umsetzung von End-To-End Geschäftsprozessen eine zentrale Rolle.

SOA Technologieplattformen bieten umfangreiche Funktionalitäten für die technische Bereitstellung von Services. Der effiziente Einsatz von BPM Technologiekomponenten ist allerdings wesentlich von der Bereitstellung semantisch integrierter und betriebswirtschaftlich eindeutig definierter Services abhängig. Mit ihrer Hilfe sollen End-To-End Geschäftsprozesse flexibel orchestriert werden. Die schnelle und einfache Orchestrierung von Services aus unterschiedlichen heterogenen Systemen funktioniert nur, wenn der abgebenden und der konsumierenden Applikation dieselbe semantische Struktur zugrunde liegt. Voraussetzung dafür ist, dass auch die involvierten Stakeholder aus Business und IT das gleiche Verständnis dieser semantischen Struktur haben.

Welche Rolle spielen nun Modellierungssprachen wie die Business Process Execution Language (WS-BPEL) oder die Business Process Modeling Notation (BPMN) im Rahmen von BPM Technologiekomponenten? Die Möglichkeit, modellbasiert Applikationen zu erstellen, unterstützt zum einen die von einer SOA propagierte schnelle und flexible Änderung von Geschäftsprozessen, zum anderen aber auch die Dokumentation und das Monitoring dieser Geschäftsprozesse. Mit BPEL lässt sich ein Prozess beschreiben und der dadurch erzeugte Workflow anschließend in einer BPEL-Engine automatisiert ausführen. BPEL hat jedoch zwei wesentliche Nachteile: die mangelnde Unterstützung bei der Ausführung von Prozessschritten durch den Menschen und die fehlende Möglichkeit, Geschäftsprozessmodelle End-To-End abzubilden. Die Nutzung von BPEL-Modellen zur Dokumentation von Geschäftsprozessen und damit als gemeinsame Sprache für Business und IT ist daher sehr eingeschränkt.
Diese beiden Schwachpunkte werden durch den BPMN Standard, eine Spezifikation der Object Management Group (OMG), teilweise ausgeglichen. Die BPMN Notation bietet eine einheitliche Sprache für eine klare, vollständige und effiziente Darstellung von Geschäftsprozessen, die es erlaubt, sowohl menschliche Interaktion als auch automatisierte System-Interaktionen zu modellieren. Durch die Nutzung einer entsprechenden BPM Engine besteht die Möglichkeit, automatisiert ausführbaren Code zu erstellen. Im Gegensatz zu BPEL bietet BPMN eine Notation, die von allen gleichermaßen verstanden wird, von Geschäftsprozess- wie auch von IT-Experten.

An dieser Stelle darf nicht vergessen werden, dass der Einsatz und der Erfolg von BPMN Technologien wesentlich von dem zur Verfügung gestellten betriebswirtschaftlichen Inhalt abhängt. Notwendig sind demnach vor allem betriebswirtschaftlich und semantisch korrekt beschriebene Services aber auch vordefinierte Prozessmodelle. SOA Plattformen müssen hierbei die einheitliche Nutzung von betriebswirtschaftlichem Inhalt und BPM-Funktionalitäten einheitlich und integriert unterstützen.

Insgesamt betrachtet bleibt zu sagen, dass SOA eine hervorragende technische Grundlage ist, um BPM im Unternehmen umzusetzen.