BPM-Komponenten

Die Liste der Bausteine rund um die BPM-Technologie ist umfangreich und kaum in einem einzelnen Produkt zu finden. Die Hersteller von sogenannten BPM-Suites setzen unterschiedliche Schwerpunkte, die sich i. d. R. aus der Historie ihrer Produkte ergeben. In der gleichen Weise wie einstige EAI-Werkzeuge zur Integration von Backend-Systemen Prozessfunktionalität hinzugewinnen, bewegen sich auch Produkte aus den Bereichen Prozessmodellierung oder Enterprise-Content-Management Jahr für Jahr stärker in Richtung eines durchgängigen Business-Process-Management.

Der erste Abschnitt dieses Kapitels „Phasen im BPM“ beschreibt die Zusammenhänge der für das BPM erforderlichen Infrastrukturkomponenten in Referenz auf den zuvor aufgezeigten Regelkreis. Dabei ist zwischen erforderlichen und optionalen Komponenten zu unterscheiden.

Der zweite Abschnitt dieses Kapitels „Logische Bausteine für BPM im Detail“ stellt die einzelnen Komponenten und ihre Bausteine kurz vor, um ein Verständnis für die Bedeutung und den Einsatzbereich sowie angrenzende Aufgabenfelder zu ermöglichen.

Phasen im BPM

Ausgehend von den Aufgaben des BPM-Regelkreises lassen sich für jede Phase Infrastrukturkomponenten und Bausteine identifizieren, die diese unterstützen bzw. für die Durchführung der Aufgaben erforderlich sind.

Phase 1: Modellieren/Simulieren

So benötigen die Modellierung und Simulation zunächst eine Übersicht der Prozesse, sogenannte Prozesslandkarten, um die relevanten Prozesse und ihre Aufgaben zu identifizieren. Zudem sollten Ziele für die Modellierung bekannt sein. Werden solche nicht definiert, ist es unwahrscheinlich, dass die Modellierung einen sinnvollen Output erzeugt. Als Ergebnis entstehen die Prozessmodelle.
Optional lassen sich die geschaffenen Prozessmodelle mithilfe geeigneter Infrastrukturen auch publizieren. Dies kann den nicht mit der Prozessmodellierung beschäftigten Mitarbeitern zur Orientierung dienen. Die Simulationsergebnisse können so in einer großen Gruppe diskutiert werden, es werden zusätzliche Anregungen erfasst.

Abbildung 3: BPM-Kontext

Ein bereits vorhandenes Unternehmensmodell kann ebenfalls hilfreicher Input für diese Phase sein. Es enthält zumeist Informationen über Verrechnungseinheiten und Informationsobjekte. Dies kann die Arbeit der Prozessmodellierer vereinfachen. Sollte ein solches Modell noch nicht existieren, bietet die Modellierung eine gute Grundlage, um ein solches sukzessive zu erschaffen.

Phase 2: Implementieren

Die Implementierung sorgt für die Bereitstellung der in den Prozessmodellen spezifizierten Aufgabenträger – der Durchführungsebene. Dabei sind für die automatisierten Aufgabenträger im Idealfall nur Services aus den Corporate-Service-Repository zu benutzen. Es kann aber auch sein, dass diese erst noch zu entwickeln und bereitzustellen sind. Typischerweise gilt gleiches für die in den Prozessen definierten Benutzeroberflächen, den sogenannten Forms oder Human-Workflow-Unterstützungen. Hierzu erweitert und gestaltet die Realisierung die vorhandene Integrationsinfrastruktur sowie andere Elemente der Ausführungsinfrastruktur.

Phase 3: Ausführen

Die Ausführung der standardmäßig in BPEL definierten Prozesse erfolgt mithilfe einer Service-Orchestration-Engine. Die Engine achtet auf die regelkonforme Ausführung der Prozesse, versorgt die Monitoring-Infrastruktur mit den erforderlichen Informationen und überwacht den Prozessstatus jeder einzelnen Prozessinstanz.

Ein weiteres Element der Ausführung sind Prozessportale oder Human-Workflow-Interfaces. Dabei handelt es sich um zumeist webbasierte Schnittstellen, die einem Menschen Zugriff auf die einzelnen Prozessinstanzen (Prozessportale) oder die Nutzdaten geben. Werden menschliche Ressourcen sogar in den Prozessablauf eingebunden, spricht man üblicherweise von Human-Workflow. Da auch hier eine ganze Menge technischer Funktionalität gebündelt ist, gelten beide als essenzielle Komponenten einer Ausführungsinfrastruktur, werden jedoch gelegentlich auch unter dem Begriff Portal gebündelt.

Weiterhin gibt es noch optional spezialisierte Komponenten wie Business-Rules-Engines und Complex-Event-Processing-Infrastructures. Beide Komponenten unterstützen die Automatisierung von Prozessen, indem sie das Verhalten bzw. die Entscheidungsfindung in den Prozessen flexibilisieren.

Phase 4: Überwachen/Monitoring

Auch die Überwachung bzw. das Monitoring wird mit spezifischen Komponenten unterstützt. Im Wesentlichen ist dies eine Infrastruktur, die Informationen aus der Ausführungsinfrastruktur bezieht und diese aufbereitet und präsentiert. Dabei kommen Dashboards zum Einsatz, die auch nicht technischen Benutzern mithilfe grafischer Gestaltungselemente wie Ampeln, Charts oder Maps Informationen über den gegenwärtigen Ausführungsstatus von Prozessbündeln, Arbeitspaketen oder einzelnen Prozessinstanzen geben können. Je nach Bedarf können die Informationen auch in bestehende BI-Infrastrukturen überführt oder mithilfe eigener Visualisierungskomponenten den Benutzern zugänglich gemacht werden.

Zentral für jede Monitoring-Infrastruktur ist, dass sie Prozess- und Audit-Logs unterstützt.

Angrenzende Systeme

BPM steht natürlich nicht alleine im Unternehmenskontext. Neben den primär wertschöpfenden Aufgaben interagiert BPM sehr eng mit zwei Disziplinen: Der Unternehmensentwicklung bzw. dem Enterprise-Architecture-Management, falls ein solches vorhanden ist, und der Software-Entwicklung. Folgende Abbildung gibt die Zusammenhänge wieder.

Geschäftsentwicklung

Die Geschäftsentwicklung setzt den Rahmen für die gezielte Entwicklung von Fertigkeiten und Fähigkeiten des Unternehmens. Dabei übernimmt u. a. das Enterprise-Architecture-Management eine zentrale Funktion bezüglich der Identifikation und dem Design von Kompetenzen entlang der Wertschöpfungskette bzw. den Prozessen. Es liegt auf der Hand, dass die in 3.1.2 beschriebene Realisierung nicht allein aufgrund des guten Geschäftsszenarios (Business-Case) umzusetzen ist. Es ist auch mit dem gesamten Aktionsportfolio und der Ressourcenplanung sowie der angestrebten Kompetenzentwicklung abzustimmen. Daher obliegt es der Geschäftsentwicklung die Ziele an das BPM zu definieren, d. h. festzulegen in welchen Prozessen welche Veränderungen zu erreichen sein sollten.

Analog ist die Geschäftsentwicklung auch der Nutznießer des BPM. Durch den Informationsfluss aus dem BPM kann die Geschäftsentwicklung kostengünstig detaillierte Kenntnis über den tatsächlichen Status und Bedarf in den Prozessen erlangen.

Software-Entwicklungsprozess

So wie das BPM auf die Steuerung bzw. Zielvorgabe angewiesen ist, benötigt es die Realisierung bzw. Implementierung der designten Prozesse. Zwar wird bei der Orchestrierung von Services in neuen Prozessen typischerweise der Implementierungscode direkt generiert, allerdings unterliegt die Entwicklung bzw. das Re-Design von Services dem traditionellen Entwicklungsprozess im Unternehmen. In den meisten Fällen wird zusätzliche Informations- und Dienstbereitstellung erforderlich sein. Daher ist das BPM mit dem bestehenden Software-Entwicklungsprozess eng zu verzahnen. Die Herausforderung ist, die goldene Mitte und das optimale Zusammenspiel zwischen BPM und traditioneller Software-Entwicklung zu finden. Dies gilt insbesondere in den Bereichen Anforderungs-, Architektur-, Application-Lifecycle- sowie Test-Management. Der Hauptfokus liegt auf der Vereinheitlichung von Prozess- und allgemeinen Anforderungen, der Durchgängigkeit der Traceability von den Anforderungen bzw. Prozessmodellen bis hin zum Code sowie auf der einheitlichen Architektursicht auf Daten, Services und Prozesse.

Logische Bausteine für BPM im Detail

Im Folgenden wird jeder einzelne Baustein mit seiner Zielsetzung beschrieben. Auch der konkrete Nutzen wird verdeutlicht. Die Architekten unter den Lesern werden Anknüpfungspunkte zu aktuellen Standards wie der Modellierungssprache BPMN erkennen.

Abbildung 5: Logische BPM-Bausteine und deren Zusammenhang

Logische Bausteine für BPM – Modellierung/Simulation

Unternehmensmodelle

Nicht ohne Grund steht das Modell des Unternehmens an erster Stelle, wenn es um Bausteine für BPM geht. BPM ist in der Weise mit einer SOA-Initiative vergleichbar, als sein Erfolg ebenfalls an der Verbindung zur Unternehmensarchitektur hängt. Alleine als technologische Neuerung („technisches BPM“, Prozessautomatisierung) wird ein positiver Return-on-Invest schwierig einzustellen sein. Bei BPM wird die enge Verzahnung zwischen Fachkonzepten und der technischen Umsetzung noch offensichtlicher („new BPM“): Prozesse, welche die Dynamik eines Unternehmens beschreiben, bauen auf diversen semantischen Modellen auf. Dazu gehören die Geschäftsobjekte, die Organisationsstruktur und das Domänenmodell. Dies sind die ersten Bausteine für die Umsetzung von Business-Process-Management. In einem SOA-Repository werden diese miteinander vernetzt.

Baustein: Unternehmensorganisation

Die Organisationsstruktur des Unternehmens findet sich auch in den Geschäftsprozessen wieder. In Form eines Organigramms dokumentiert es Verantwortungsbereiche und Rollen, die im Rahmen von Geschäftsprozessen verwendet werden. In der BPMN spiegeln sich die Rollen in den Konstrukten Pool und Lane wider. Bei der Verwendung eines existierenden Organigramms ist allerdings Vorsicht geboten! Bei der Einführung von Geschäftsprozessmanagement geschieht häufig eine Umstrukturierung von einer vertikalen (mit einem Schwerpunkt auf Funktionen und Abteilungen) zu einer horizontalen Organisation (mit einem Schwerpunkt auf durchgängigen Geschäftsprozessen). Möglicherweise werden Rollen also besser am abstrakten Domänenmodell des Unternehmens festgemacht (siehe nächster Baustein).

Baustein: Domänenmodell

Ein Domänenmodell beschreibt die funktionalen Bereiche eines Unternehmens unabhängig von der Organisationsstruktur. Abstrakte Bereiche markieren funktionale Zusammenhänge wie beispielsweise Customer-Relationship-Management, Human-Resources oder Supply-Management. Dieses hierarchische Modell kann bis auf Service-Ebene verfeinert werden, spielt also auch bei der Strukturierung der SOA-Landschaft eine wesentliche Rolle. Läuft ein Prozess domänenübergreifend ab, so wird dies mit BPMN-Mitteln analog zur Unternehmensorganisation mittels unterschiedlicher Pools und Lanes abgebildet. Auch hierbei werden Verantwortungsbereiche zugewiesen und innerhalb von Workflows ausgewertet. Das Domänenmodell muss also ebenfalls im gleichen Repository wie die Prozesse gepflegt werden.

Baustein: Geschäftsobjektmodell

Die Menge der Geschäftsobjekte (Business Entities) des Unternehmens definiert eine gemeinsame Sprache über alle Fachabteilungen und IT-Systeme. Vergleichbar mit globalen Datentypen legen diese Objekte die Wertebereiche und Datenstrukturen fest, die in den Geschäftsprozessen verwendet werden. Ein Geschäftsobjektmodell (Business-Object-Model) definiert daneben auch die Beziehungen zwischen den Objekten. Der Fokus dabei liegt auf einer gemeinsamen Sprache (Wertebereiche, Attributnamen und definitionen). Eine mögliche Vernetzung der Objekte endet spätestens an der Domänengrenze. Verwendet jede Fachabteilung und letztlich auch jedes IT-System die gleichen Konzepte, so werden Reibungsverluste und doppelte Arbeit vermieden. Die Datenstrukturen, welche ein Prozess von Service zu Service weiterreicht, müssen nicht umständlich transformiert werden. Die Erstellung eines Geschäftsobjektmodells kann in großen Unternehmen eine aufwändige Angelegenheit sein. Es findet sich typischerweise in einem UML-Repository wieder. Das Modell entwickelt sich permanent weiter und sorgt so für eine erhöhte Komplexität beim Change-Management. Idealerweise ist es daher gemeinsam mit den Prozessbeschreibungen im gleichen Repository abgelegt und aus Konsistenzgründen sind sie miteinander vernetzt. In der Prozessbeschreibungssprache BPMN ist kein Notationselement explizit für diese Vernetzung vorgesehen, was den Herstellern der BPM-Produkte Spielraum für innovative Erweiterungen lässt.

Prozessmodellierung

Die Prozessmodellierung scheint auf den ersten Blick die Kernaufgabe des Geschäftsprozessmanagements zu sein. Doch spiegelt sie nur eine von zwei Seiten wider, nämlich die Betrachtung der Effizienz der Arbeitsprozesse. Zuvor gilt es, die Effektivität, d. h. die Ziele der Geschäftsprozesse genauer zu untersuchen. Wenn auch hier nicht explizit als Baustein für BPM aufgeführt, so startet BPM zunächst mit der Vereinbarung der Prozessstrategie. Werkzeuge dafür können Balanced Scorecards und Strategy-Maps sein. Aus dem Abgleich zwischen den strategischen Zielen und der Analyse der Ist-Situation leitet sich die Begründung für das Geschäftsprozessmanagement ab. Daraufhin erst folgt die Ausarbeitung eines Prozessmodells.

Baustein: Prozessmodell

Das Prozessmodell eines Unternehmens bildet den Kern des Geschäftsprozessmanagements. In einem Prozessmodell werden Geschäftsprozesse und Teilprozesse überschneidungsfrei und vollständig abgebildet. Es ist hierarchisch aufgebaut und besteht aus mehreren Ebenen von unterschiedlichem Abstraktionsgrad. Die oberste Ebene definiert wenige Prozessgruppen oder Kernprozesse, die unterste Ebene enthält von Menschen oder Maschinen ausführbare Arbeitsschritte. Häufig besteht eine Diskrepanz zwischen den abstrakten Prozessdefinitionen und der Realität im Unternehmensalltag. Die technischen Ebenen des Prozessmodells sind häufig, wenn überhaupt automatisiert, unabhängig von einem Process-Repository in unterschiedlichen IT-Produkten implementiert und verwaltet. Standardisierungsbemühungen und Produktentwicklungen leisten nach und nach eine bessere Integration von fachlichen Modellen und IT-technischer Umsetzung. Der BPMN-Standard spielt hierbei eine wesentliche Rolle.

Das Prozessmodell ist auf die in der Prozessstrategie festgelegten Ziele hin ausgerichtet und bringt dementsprechend Geschäftsobjekte, Rollen, Verantwortungsbereiche, Teilprozesse und Services miteinander in Beziehung. Die Prozesse können sowohl interne Organisationsprozesse als auch extern (durch Kunden) angestoßene Geschäftsprozesse sein. Für beide Typen existieren branchenspezifische Referenzmodelle. Die Bereitstellung eines passenden Referenzmodells durch eine BPM Suite kann eine Unterstützung bei der Entwicklung eines eigenen Modells sein.

Baustein: Prozesslandkarte

Aufgrund der hierarchischen Struktur des Prozessmodells gehen zum Teil die Zusammenhänge verloren. Die Kenntnis über Abhängigkeiten, die auf dem Transfer von Leistungen und Informationen zwischen Geschäftsprozessen beruhen, ist für das Verständnis, die Steuerung und die Optimierung der Prozesse sehr nützlich. Mit sogenannten Prozesslandkarten kann man sich einen Überblick über die Beziehungen und Übergabepunkte zwischen Prozessen verschaffen. Dies hilft dazu, Leistungsvereinbarungen zu treffen und Messpunkte einzurichten. Auch externe Partner, z. B. Lieferanten, können hier mit einbezogen werden. Dieses Werkzeug hilft Missverständnisse vermeiden und Koordinationsaufwand reduzieren. Ein Zusammenspiel zwischen Prozesslandkarten und Prozessmodellen ist derzeit noch nicht State-of-the-Art, wird aber sicherlich nicht mehr lange auf sich warten lassen.

Baustein: Prozesssimulation

Bei der Modellierung eines Prozesses sind diverse Ressourcen im Spiel, die zeitliche Implikationen auf den Verlauf des Prozesses haben. Statistische Effekte und Nebenläufigkeiten erzeugen eine Unsicherheit über den tatsächlichen Ablauf und die Skalierbarkeit des Prozesses. Um ein besseres Gefühl für Einführungen oder Änderungen von Prozessen bzw. Prozessautomatisierungen zu bekommen, ist es überaus hilfreich, wenn die BPM Suite eine Simulationsfunktion bietet. Auf Basis von Wahrscheinlichkeiten und Laufzeiten kann damit im Vorhinein der Bedarf an Personal oder Ressourcen abgeschätzt werden.
Baustein: Kennzahlendefinition

Prozesse haben Ziele. Gute Ziele sollten messbar sein. Somit ergeben sich Kennzahlen, die eine Prozessgüte beschreiben können. Beispielsweise lässt sich die Anzahl getätigter Outbound-Calls ins Verhältnis zu den dabei erhaltenen Bestellungen setzen. Hieraus ist gegebenenfalls ein Rückschluss auf die Effektivität des Call-for-Cash-Prozesses ableitbar. Diese und andere Kennzahlen sollten entweder im Zuge der Prozessmodellierung oder aber als Vorgabe aus der beauftragenden Unternehmenseinheit kommen. Gegen diese Zahlen wird die Ausführung im Monitoring berichten.

Baustein: Dokumentation

Prozessdokumentation ist sowohl als Arbeitsanweisung als auch als vertragliche Grundlage für IT-Lieferanten sowie zur Wartung der Prozessautomatisierung ein notwendiges Artefakt. Die durch Prozessautomatisierung erhoffte Flexibilität führt gegebenenfalls zu häufigen Änderungen, welche manuell aufwändig in die Dokumentation eingepflegt werden müssen. Eine automatische Generierung von Prozessdokumentation aus den angereicherten Modellen ist daher zwingend erforderlich. Eine BPM Suite sollte sowohl druckbare als auch online einsehbare Dokumentation erzeugen. In diesem Zusammenhang wären auch Prozessportale zu nennen, über die sich die Mitarbeiter jederzeit über den aktuellen Stand der Prozessdefinition informieren können. Der BPMN-Standard bietet hierfür eine geeignete Sprache, die auch in Fachabteilungen relativ gut verstanden wird.

Logische Bausteine für BPM – Implementierung

Zum einen bieten BPM-Suites Werkzeuge für die direkte Code-Generierung aus Prozessmodellen, die Services aus dem SOA-Repository orchestrieren. Zum anderen gehören zu dieser BPM-Infrastrukturkategorie Tools, die beliebig tief auch in Richtung Implementierung und Integration der von den Prozessen benötigten Services gehen. Die erste Art setzt das Vorhandensein der im Prozess verwendeten Services voraus, die durch die IT-Abteilung einem Business-Analysten zur Verfügung gestellt werden, so dass aus dem Prozessmodell direkt lauffähiger Code entsteht. Bei der zweiten Art von sogenannten IT-Modellierungstools handelt es sich um Komplettwerkzeuge, die neben der Prozessmodellierung (z. B. in BPEL) auch die Daten- und Services-Spezifikation, deren Implementierung bzw. Integration sowie das GUI-Design der IT-Abteilung ermöglichen. Üblicherweise verfügen diese IT-Tools über Schnittstellen für den standardisierten Austausch von Prozessmodellen mit den rein fachlichen Prozessmodellierungstools. Der Abschnitt „BPM-Vorgehen aus Implementierungssicht“ widmet sich ausführlich der Implementierungsseite, sodass dies hier nicht weiter detailliert wird.

Logische Bausteine für BPM – Ausführungsinfrastruktur

Integrationsinfrastruktur

Als Laufzeitumgebung für automatisierte Geschäftsprozesse sind uns seit einigen Jahren der BPEL-Standard und darauf basierende Produkte bekannt. Der Trend deutet darauf hin, dass ausführbare BPMN-Modelle gegenüber BPEL deutlich zunehmen werden. Traditionell werden bereits – ohne ein qualifiziertes Management – automatisierte Prozessketten mittels bewährter Technologie realisiert. Was in den neunziger Jahren als „message-oriented Middleware“ begann, wurde um einen reichen Strauß an integrativer und steuernder Funktionalität ergänzt, sodass in großen Unternehmen heutzutage bereits ein verhältnismäßig großer Automatisierungsgrad vorherrscht. Diese Bausteine werden auch in Zukunft einen wichtigen Platz im Rahmen einer Prozessarchitektur einnehmen.

Baustein: Message-oriented Middleware (MOM)

Eine typische Eigenschaft von Geschäftsprozessen ist ihre zeitliche Ausdehnung sowie häufige Wartephasen während der Ausführung der Teilschritte oder von Batch-Prozessen. Dieser Asynchronität und langen Prozessdauer werden Queueing-Systeme gerecht, welche Nachrichten transaktionssicher von Prozessschritt zu Prozessschritt transportieren und auch mit zeitlich nicht planbaren Ereignissen gut umgehen können. Häufig sind IT-Systeme, beispielsweise ERP-Systeme, auch nicht in der Lage, synchrone Anfragen zeitnah und skalierbar zu beantworten. Die sogenannte message-oriented Middleware hat also auch integrativen Charakter. Sie ist aus komplexen IT-Umgebungen nicht mehr wegzudenken.

Baustein: Enterprise-Service-Bus

Die Vorteile asynchroner Kommunikation durch Queueing-Systeme reichen alleine nicht aus, um die proprietären oder älteren Backend-Systeme zu integrieren. Daher hat sich zu Beginn des vergangenen Jahrzehnts unter dem Titel Enterprise-Application-Integration (EAI) eine neue Kategorie von Produkten entwickelt, die darauf spezialisiert ist, offene Systeme, welche kein Standardprotokoll sprechen, über Adaptoren, Fassaden und Gateways in Prozessflüsse einzubinden. In der Entwicklung hin zur Service-Orientierung spielte die Idee der Entkopplung zwischen Service-Nehmer und Service-Geber eine immer größere Rolle. Die Middleware wurde daher um die Funktionalitäten der Nachrichtentransformation zur fachlichen Entkopplung und des Routings zur technischen Entkopplung erweitert. Unter dem neuen Begriff Enterprise Service Bus (ESB) entstand so eine immer mächtigere Kategorie von Middleware-Produkten. Eine typische Ergänzung wäre noch eine Service-Registry, mit deren Hilfe das Routing von Nachrichten technisch noch etwas generischer gestaltet werden kann. Der Baustein Enterprise-Service-Bus kann auch noch viele weitere Aufgaben wie beispielsweise Policy-Enforcement, Security etc. übernehmen. In Ergänzung zu BPM-Suites übernimmt er im Wesentlichen das Vermitteln von Nachrichten über eine Queueing-Infrastruktur sowie die Integration von Systemen ohne standardisierte Zugangsprotokolle.

Baustein: SOA-Repository

Einer der Grundgedanken von SOA und BPM ist die Transparenz über IT-Funktionen und ihre Abhängigkeiten. Aus dieser Transparenz sollen solche Vorteile erwachsen wie Konsistenz, Wiederverwendung, Messbarkeit und Änderbarkeit. Nach dem Prinzip eines Baukastens sollen sich dann Services in Prozessen nutzen lassen. Das bedeutet aber auch, dass sich die Granularität und Menge an zu verwaltenden Elementen ändert und die Komplexität der Abhängigkeiten wächst. Man bedenke nur die Versionierung von Services bei ständiger Weiterentwicklung der IT-Umgebung. Wenn dann noch sekundäre Anforderungen wie Zugriffskontrolle, Revisionssicherheit und weitere Compliance-Checks ins Spiel kommen, wird schnell deutlich, dass eine „einfache“ Verwendung von Services innerhalb von Prozessen auch effizient verwaltet werden muss. Der Kontrolle einer Wiederverwendung geht außerdem eine Strukturierung in Form von Ontologien, Metamodellen, Verantwortungsbereichen und den Beziehungen zur Systemlandschaft voraus.

All dies führt zu der Erkenntnis, dass die Verwaltung von Prozessen und Services ein ganzes Ökosystem, also ein komplexes System aus Rahmenbedingungen, erfordert. Angefangen mit einem hierarchischen Unternehmensmodell, welches die Verantwortungsbereiche absteckt, über ein Objektmodell, welches ein gemeinsames Austauschformat für Geschäftsobjekte definiert, bis hin zu den Artefakten der Systemlandschaft, welche als Basis für Deployment-Modelle dienen, sind Prozesse und Services eingebettet in ein Geflecht von Daten aus unterschiedlichsten Arbeitsbereichen. Idealerweise sind diese Daten in einem einzigen Repository vereint und entsprechend eng miteinander vernetzt. Auf diese Weise lassen sich Inkonsistenzen vermeiden. Diesem Anspruch gehorchen moderne SOA-(Service-)Repositorys. Viele Produkte können auch Daten wie BPEL- oder SCA-Beschreibungen interpretieren und die enthaltenen Abhängigkeiten komfortabel visualisieren. Gut vernetzte SOA Repositories unterstützen somit das „Baukastenprinzip“ von Prozessen und Services, indem sie Chaos durch Ordnung ersetzen. Mit ihrer Hilfe wird transparent, welche Prozesse welche Services (und damit welche IT-Systeme) benutzen und in welchen Prozessen sich Service-Änderungen auswirken. Sie unterstützen damit also das Change-Management und das Incident Management. Lassen sie sich auch noch in Laufzeitdaten-Repositories integrieren, so entsteht ein umfassendes Bild über Bedeutung und Wert eines Service oder (Teil-)prozesses. In großen Unternehmen mit einer Service-orientiert ausgerichteten IT-Umgebung kann ein SOA Repository somit einen wertvollen Beitrag leisten.

Baustein: Service Registry

Die Bausteine SOA-Repository und Service-Registry hängen eng miteinander zusammen. Teilweise werden die entsprechenden Produkte als eine Einheit angeboten. Während das SOA-Repository ein Management-Werkzeug darstellt, dem ein Wissensnetz zugrunde liegt, kann man eine Service-Registry als technische Sicht auf ein solches Wissensnetz ansehen. Im Repository finden sich u. a. ganze Dokumente, während Registrys über Netzwerkadressen und weitere technische Informationen Auskunft geben. Die für Registries hauptsächlich relevante Metapher „White Pages“ wird durch die Einbettung von technischen Informationen der Services in Taxonomien ergänzt. Auf diese Weise lassen sich Services auch über ihre Einordnung in Organisationsstrukturen, Sicherheitsrelevanz, Service-Typ usw. finden und ihre Adressen und Policys abfragen. Repositorys werden vor allem durch Menschen bedient, Registrys per API von Maschinen bzw. Software befragt. Relevante Zugriffsprotokolle für Registries sind UDDI (Universal Description, Discovery and Integration) und JAXR (Java API for XML Registries) sowie Representational-State-Transfer(REST)-basierte oder proprietäre Protokolle.

Prozessautomatisierung

Die Effizienz im Business-Process-Management kommt aus der Automatisierung der modellierten Prozesse. Dabei können nun auch menschliche Arbeitsschritte enthalten sein, ohne ihren Ausführungskontext abzugeben (Human Workflow).

Baustein: Service-Orchestrierung

Unter dem Begriff Service-Orchestrierung versteht man die Verknüpfung disjunkter Service-Schnittstellen im Rahmen einer automatisierten Aufrufkette (Ausführungslogik). Darin drückt sich der Mehrwert einer serviceorientierten IT-Landschaft aus: Existierende Services lassen sich relativ einfach in neue Prozesse einbinden. Die aktuelle Standardsprache für die Beschreibung einer solchen Aufrufkette ist die Business-Process-Execution-Language (BPEL). Sie ist darauf ausgelegt, die Benutzung von Web-Service-Schnittstellen in einem gesteuerten Ablauf zu beschreiben. BPEL-konforme Produkte, sogenannte BPEL-Engines (oder allgemeiner Process-Engines), dienen als Ausführungsplattform. Als sehr technische Sprache ist BPEL nicht für die Anforderungsanalyse gemeinsam mit dem Fachbereich geeignet. Ein typisches Vorgehen ist die Modellierung mittels Business-Process-Modeling-Notation (BPMN) und die anschließende Abbildung in „ausführbares“ BPEL. Mit der Version 2.0 der BPMN wird nun eine direkte Ausführbarkeit ohne BPEL angestrebt. Zu einer Process-Engine sollte parallel auch eine Service-Registry gehören, um die in den Prozessbeschreibungen verwendeten abstrakten Service-Namen in physikalische Adressen der Services umzuwandeln.

Der Wert der Service-Orchestrierung liegt in der vereinfachten technischen Anbindung existierender Services im Rahmen lang laufender Transaktionen. Daneben kann hiermit eine Brücke zwischen fachlichen Modellen und technischer Implementierung entstehen. Um eine wirklich praktikable technische Umsetzung der Prozessbeschreibungen zu erreichen, müssen die Hersteller von BPM-Suites ihre Produkte aber mit Möglichkeiten zur Datentransformation und Integration von Altsystemen anreichern. BPMN alleine ist zu abstrakt. Auch der Umgang mit Transaktionen, Service-Registry und weiteren laufzeitrelevanten Funktionen gehen über die Semantik von BPMN-Beschreibungen hinaus und stellen wichtige Produktkriterien dar.

Baustein: Workflow-Management

In der Anfangszeit der technischen Prozessautomatisierung waren rein maschinell automatisierte Prozesse und menschliche Workflows noch getrennt. Die Einbindung menschlicher Arbeitsschritte wurde von dem BPEL-Standard auch nicht unterstützt. Auf eine Initiative der Firmen IBM und SAP hin wurde der Standard daher um BPEL4People erweitert, um diese Lücke zu schließen. Auch BPMN sieht die Beschreibung menschlicher Arbeitsschritte vor. Das auf Mitarbeiter ausgerichtete Workflow-Management ist hier als eigener Baustein aufgeführt, da es sich dabei um ein komplexes Konzept handelt, was sich auch in Form umfangreicher Produkte widerspiegelt. Zum Workflow-Management gehört eine Benutzungsschnittstelle – häufig eine webbasierte Schnittstelle sowie die Integration von E-Mail- und Dokumentenmanagementsystemen. Auf Menschen ausgerichtete Funktionen wie Benutzerrechte, Vertreterregelungen, Visualisierung der Prozessabläufe, Berichtswesen etc. rechtfertigen auch hier wieder eine eigene Kategorie von IT-Produkten. Dennoch wachsen durch Service-Orientierung Workflow-Management- und BPM-Produkte zu einer Einheit zusammen. Diese Durchgängigkeit erhöht die Effizienz der Wertschöpfungskette.

Baustein: Technisches Policy-Enforcement

Besonders im Rahmen der Mehrfachverwendung von SOA-Services durch unterschiedliche Service-Nutzer aus unterschiedlichen Prozessen wird eine Kontrolle und Restriktion dieser Nutzung notwendig. Zugriffsbeschränkung aus Sicherheitsgründen oder zur Einhaltung von vertraglich festgelegten Mengengerüsten (Quality of Service) bilden einen Kontrollaspekt, der technisch realisiert werden muss. Teilweise bieten ESB-Produkte solche Funktionalitäten. Häufig handelt es sich aber noch um spezialisierte Produkte. Security und andere Policys werden oft als Störfaktoren gesehen, tragen sie doch zur eigentlichen Wertschöpfung eines automatisierten Geschäftsprozesses nicht direkt bei. Der Wert dieses Bausteins orientiert sich also maßgeblich an der Strenge der im Unternehmen relevanten Sicherheitsanforderungen und Compliance. Für einen im Rahmen von BPM automatisierten Prozess verursacht dieser Baustein einen erhöhten Aufwand durch Anwendung von Sicherheitszertifikaten oder durch spezielle Fehlerbehandlung bei QoS-Verletzung. Aufgrund der hohen Umsetzungskosten sind solche Policys höchstens an Domänengrenzen, besonders aber bei der Kommunikation mit externen Partnern (B2B) sinnvoll einzusetzen.

Baustein: Mashups

Sogenannte Mashups sind leichtgewichtige Ansätze, um rasch neue Anwendungen (Teilprozesse) aus bestehenden Services zu bauen. Web-2.0-Technologien wie REST, SOAP, RSS, ATOM und JavaScript erlauben im Rahmen von Webportalen die Kombination bestehender Inhalte und erweitern so die Wertschöpfung einzelner, bislang unabhängiger Dienste. Charakteristisch ist die Vermeidung von Programmierung zugunsten von Drag’n‘Drop. Wenn Schnelligkeit in der Umsetzung wichtiger ist als die individuelle Anpassung bestehender Dienste, dann bieten Mashups eine weitere Automatisierung und Anreicherung der Wertschöpfungskette zu einem guten Preis-Leistungs-Verhältnis. Zu beachten ist beim Einsatz von Mashups, dass klare Regeln für die Erstellung aus Sicht der Gesamtarchitektur notwendig sind, um ein neues, unkontrolliertes Anwendungswachstum zu vermeiden. Mashups können als optionaler Baustein eingestuft werden.

Optionale Erweiterung zur Flexibilisierung von Prozessen

Darunter versteht man alle Maßnahmen, die zu weiterer Flexibilisierung, Dynamisierung und Agilität von BPM beitragen. Es handelt sich um eine fortgeschrittene Reifephase der BPM-Anwendung, wo der Nutzen aus den Komponenten maximiert wird.

Baustein: Business-Rule-Management

Business-Rule-Management-Systems (BRMS) können eine nützliche Ergänzung zu BPM-Systemen sein. Ihre Hauptaufgabe liegt in der Ermittlung von höherwertigen Ergebnisdaten aus verschiedenen Eingangswerten mittels komplexer Geschäftsregelwerke. Tarifberechnung, Rabattregelung, Bewertung von Kreditwürdigkeit sind einige Beispiele solcher komplexer Herleitungen. Geschäftsregeln können komplizierte Prozessmodelle vereinfachen, da ihre Ausdruckskraft durch die Nähe zur natürlichen Sprache („wenn, und/oder, dann“) höher und kompakter ist als eine komplizierte Verknüpfung von Aktivitäten in einem BPMN-Diagramm. In diesem Fall werden in sich geschlossene oder mehrfach vorkommende Teilprozesse durch je eine einzelne Aktivität ersetzt, die eine Berechnung auf Basis von Geschäftsregeln vornimmt. Dabei wird ein konkretes Regelwerk beispielsweise als Web-Service in einem BRMS angeboten und im Prozessablauf aufgerufen. Geschäftsregeln bzw. BRMS befinden sich also auf einer detaillierteren Ebene unterhalb der Prozesse bzw. BPM-Systeme.
Wann sich der Einsatz eines BRMS lohnt, ist nicht leicht festzulegen. Man sollte über ein BRMS nachdenken, wenn häufig eine Änderung von Geschäftsregeln stattfindet, ohne dass sich der eigentliche Prozessablauf ändert. Die Regelwerke führen häufig zu einer Datenverdichtung, d. h. der Berechnung weniger Ergebnisse auf Basis vieler Eingangsdaten. Dies dient häufig als Vorlage für einen Entscheidungsknoten in BPMN. Sie werden typischerweise bei Einschätzungen (Scoring) angewendet, z. B. zur Beurteilung der Bonität oder des Verhaltens eines Kunden. Ein weiteres Beispiel sind Berechnungen auf Basis konkurrierender Geschäftsregeln, z. B. Bedingungen für eine Rabattregelung.

Baustein: Complex-Event-Processing (CEP)

Im weitesten Sinne gehören die Systeme für das Complex-Event-Processing (CEP) zu dem Bereich Business-Intelligence. Es handelt sich um eine weitere Kategorie von Produkten, die Prozessdaten verarbeitet und mittels Mustern oder Regeln entsprechende Analysen erlauben. Im Gegensatz zum Data-Warehouse (und Data-Mining), welches prinzipiell auf historischen Daten arbeitet, erheben CEP-Systeme den Anspruch, direkt zur Laufzeit auf bestimmte Ereignisse reagieren zu können. Ein beliebtes Beispiel aus dem Finanzdienstleistungsbereich ist die Detektion von Kreditkartenbetrug auf Basis inkonsistenten oder technisch unmöglichen Kundenverhaltens, z. B. mehrfache Benutzung einer Kreditkarte am selben Tag auf unterschiedlichen Kontinenten. In diesem Sinne können auch CEP-Systeme das BPM unterstützen.

Baustein: Dynamische Policys

Analog zum Konzept des dynamischen ESB-Routing kann man die Anwendung von dynamischen Policys bei der Service-Orchestrierung sehen. Allerdings handelt es sich hier um fachlich bestimmte und verwaltete Policys, die sich am Prozesskontext, dem Dateninhalt und der -quelle, der Nutzergruppe und weiteren fachlichen Rahmenbedingungen (oft als Contract zusammengefasst) orientieren. Die Anwendung von diesen fachlichen Policys erlaubt die Auswahl des passenden Service aus einer Menge gleichgearteter Services, jedoch mit unterschiedlicher Ausprägung, z. B. länderspezifischer Realisierung. Dadurch wird die oft angestrebte allgemeine Nutzung eines Referenzprozesses mit Varianten möglich, wobei die statische Bedingungsmodellierung (if-then-else) in eine einfache Sequenz überführt und durch die dynamische Auswahl während der Laufzeit realisiert wird.

Logische Bausteine für BPM – Monitoring/Prozessüberwachung

Eine Modellierung und anschließende Automatisierung von Geschäftsprozessen nimmt selten gleich zu Anfang eine ideale Gestalt an. Auch später folgende Prozessänderungen bringen immer wieder neue Elemente ins Spiel, die ihre Wirksamkeit hinsichtlich Effizienz und Effektivität erst beweisen müssen.

Erreicht der Prozessablauf das gewünschte Ergebnis zu den gewünschten Bedingungen?

Entspricht die Realität der Simulation aus der Modellierungsphase?

Sind alle Ausnahmefälle und Fehlerfälle in der Automatisierung korrekt abgedeckt?

Diese und weitere Fragen können mittels Prozessüberwachung beantwortet werden. Dazu gehört sowohl die Definition der entsprechenden Kennzahlen wie auch die nachgelagerte Beobachtung der tatsächlichen Abläufe.

Kennzahlenerhebung

Die während der Modellierungsphase identifizierten Kennzahlen sollten zur Laufzeit auch automatisiert überprüft werden können. Dazu gehören Prozesszeiten (Laufzeiten von Aktivitäten) und Mengen (Anzahl der abgearbeiteten Aktivitäten), die zur Berechnung der Prozesskosten herangezogen werden können. Kennzahlen können in Bezug auf einzelne Prozessschritte interessant sein (feingranular) oder auch im Kontext der Kernprozesse des Unternehmens (grobgranular). Sollte eine BPM-Suite die entsprechende Funktionalität zum Aufsammeln solcher Metadaten nicht selbst mitbringen, so finden sich dazu diverse spezialisierte Produkte. Alternativ können bei der Modellierung auch explizit Datensätze angelegt und in ein Data-Warehouse überführt werden. Mit der Beobachtung bestimmter Kennzahlen lassen sich Aussagen über Effizienz und Effektivität der Prozesse tätigen. Sie bilden somit die Grundlage für die Prozessoptimierung oder Entscheidungen über das Prozessmodell.

Baustein: Audit-Log

Änderungen an den Geschäftsprozessen haben eine direkte Auswirkung auf die geschäftliche Tätigkeit des Unternehmens. Fehler, die auf dieser Ebene gemacht werden, wirken sich besonders schnell und gegebenenfalls schwerwiegend aus. Daher ist eine Qualitätssicherung bei der Modellierung und der Umsetzung von Prozessänderungen unabdingbar. Doch auch die Nachverfolgbarkeit von Änderungsaktivitäten gewinnt an Bedeutung. Die Informationen darüber, wer wann was entschieden oder geändert bzw. in der produktiven Laufzeitumgebung installiert hat, müssen zum Zweck der Revision stets nachvollziehbar sein. Auch eine entsprechende Versionierung sämtlicher bei der Prozessautomatisierung betroffener Artefakte gehört zum Lifecycle-Management der Prozesse dazu. Die Protokollierung solcher Änderungen geschieht in einem sogenannten Audit-Log. Wenn der Audit-Log auch nicht direkt zur Wertschöpfung beiträgt, so ist er doch aus rechtlichen Gründen und zur Unterstützung der Wartungsaktivitäten ein wichtiger Baustein von BPM-Suites.

Baustein: Process-Log

Während der Audit-Log die Änderungen an den Prozessdefinitionen protokolliert, werden im Process-Log die Transaktionen in den tatsächlichen Prozessinstanzen aufgezeichnet. Hier geht es um ganz konkrete Leistungen für ganz konkrete Kunden. Der Hauptnutzen dieses Protokolls liegt in der Nachvollziehbarkeit des Prozessablaufs im Einzelfall. Verlangt ein Kunde Auskunft über den Fortschritt seiner Bestellung, so gibt der Process-Log darüber Auskunft. Eine BPM Suite ohne entsprechende Protokoll-Funktionalität ist undenkbar. Die Produkte unterscheiden sich aber in dem Komfort der Darstellung und der Interaktionsmöglichkeit. So sollte es beispielsweise möglich sein, die Prozessdaten zur Laufzeit zu ändern, um auf unvorhergesehene Zwischenfälle reagieren zu können. Eine grafische Illustration des Prozessablaufs gehört dabei zum Marktstandard. Neben dem genannten Alltagsbeispiel dient der Process Log auch zur Unterstützung beim fachlichen Problem-Management und beim technischen Availability-Management.

Visualisierung

Die Geschäftsprozessautomatisierung findet nicht vollautomatisch statt. Alle Aspekte von der Modellierung bis zur Optimierung sind mit menschlichen Aktivitäten verknüpft, erfordern also entsprechende Benutzerschnittstellen. Drei solcher Schnittstellen sollen hier als direkt an der Wertschöpfung durch Prozessautomatisierung beteiligte Bausteine hervorgehoben werden.

Baustein: Prozessportal

Jeder Mitarbeiter in einem großen Unternehmen kennt den Effekt: Es existieren Prozessbeschreibungen, Rollen- und Organisationsbeschreibungen, die langsam vor sich hin altern und mit der Realität nur noch teilweise übereinstimmen. Damit verlieren sie ihren Wert. Damit das mit BPM nicht ebenso geschieht, ist es mehr als sinnvoll, die Prozessbeschreibungen stets aktuell zu präsentieren, und zwar in einer Weise, die in Fachabteilungen verstanden und akzeptiert wird. BPMN-Modelle sollten also gleichzeitig mit der Installation ihrer Automatisierung in der IT für Mitarbeiter der Fachbereiche sichtbar sein, typischerweise integriert im Intranet. Dies ist ein wichtiger Baustein für das erhoffte Business-IT-Alignment.

Darüber hinaus kann ein Prozessportal je nach zugrundeliegendem BPM-Produkt auch gleichzeitig einen Einblick in konkrete Prozessinstanzen erlauben und so die Auskunftsfähigkeit der Mitarbeiter gegenüber den Kunden erhöhen. Die Integration von Prozessüberwachung und Visualisierung im Prozessportal wird schnell als Mehrwert wahrgenommen.

Baustein: Workflow-Portal

Neben dem Einblick in automatisierte Prozesse ist auch die Integration der Mitarbeiter durch Benachrichtigungen und interaktive Formulare ein großer Mehrwert (Human Workflow). Sowohl das Werkzeug E-Mail, als auch Webanwendungen leisten hier eine komfortable Mensch-Maschine-Schnittstelle. Rollenbasierte Zuweisung von Arbeitsschritten, zeitgesteuerte Benachrichtigungen und übersichtliche Präsentation von Auftragsdaten erhöhen die Effizienz der menschlichen Arbeit und entlasten von Routinetätigkeiten wie Ablage und Weiterleitung. Eine solche Workflow-Unterstützung ist idealerweise im Baustein Prozessportal integriert. Siehe Baustein Workflow-Management für weitere Details.

Baustein: Elektronische Formulare

Beim Übergang von einer manuellen in eine automatisierte Prozesslandschaft sind Anforderungen für die Übernahme der exakten Formularstruktur und des Layouts keine Seltenheit. Tools für elektronische Formularrealisierung bieten die Möglichkeit einer Übertragung des Papierformulars in eine E-Form mit den erweiterten Fähigkeiten zur elektronische Signatur, Validierungs- und Präsentationslogik. Durch die nahtlose Integration von E-Formularen in die Prozessausführung in Abhängigkeit von den Daten- und Service-Modellen wird hier eine klare Trennung zwischen Prozess- und GUI-Logik realisiert.

Baustein: Dashboard

In Fachbereichsabteilungen, besonders aber im Management, besteht der Wunsch nach schnell erfassbaren Übersichten und Berichten, welche den positiven oder negativen Verlauf der geschäftlichen Tätigkeit transparent machen. Nichts ist frustrierender für einen Entscheider, wenn er aus der Unmenge von Daten in einem ERP-System keine Aussage über den Erfolg seines Verantwortungsbereichs herauslesen kann. Vergleichbar mit Business-Intelligence können die Ergebnisse von Prozessabläufen in einem Dashboard grafisch und tabellarisch visualisiert werden. Aussagen über erfolgreiche und abgebrochene Aufträge, Laufzeiten und Kosten verhelfen zu einer Transparenz über Qualität und Quantität der Prozesslandschaft.

Zu den Auswahlkriterien einer BPM-Suite sollte auch die Exportierbarkeit der genannten Übersichten in Form von Dokumenten gehören. Prozessberichte (Reports) sollten als PDF verschickt, als Grafik präsentiert, als Tabelle weiterverarbeitet werden können. Entsprechende Exportfunktionen leisten im Rahmen eines Dashboards also einen zusätzlichen Mehrwert.

Weiter zum nächsten Artikel „Das BPM-Vorgehen aus Geschäftsperspektive“

Wie fanden Sie diesen Artikel?:

Autor(en) dieses Artikels

Kai-Uwe Schäfer, Kai-Uwe Schäfer IT Beratung

Co-Autor(en) dieses Artikels

Jan Thielscher, EACG GmbH - Plamen Kiradjiev, IBM Deutschland GmbH - Frank Joecks, Accelsis Technologies GmbH - Dr. Dietmar Durek, IDS Scheer AG - Klaus Grieger, cimt objects ag - Maik Schacht, BASF IT Services GmbH - Thomas Schuster, FZI Forschungszentrum Informatik

Download

Unsere Leitfäden stehen Ihnen auch zum Download zur Verfügung. Um unseren Downloadbereich zu nutzen, registrieren Sie sich bitte.
Hier registrieren

Suchformular

Sie sind hier