Prof. Dr. Thomas Allweyer
Hochschule Kaiserslautern
thomas@allweyer.de
Bibliographische Information der Deutschen Nationalbibliothek:
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliographie. Detaillierte bibliographische Daten sind im Internet über http://dnb.d-nb.de abrufbar.
Alle in diesem Buch genannten Marken und Produktnamen unterliegen warenzeichen-, marken- oder patentrechtlichem Schutz bzw. sind Warenzeichen oder eingetragene Warenzeichen der jeweiligen Inhaber. Die Wiedergabe von Marken, Produktnamen, Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften.
© 2014 Thomas Allweyer
Herstellung und Verlag: BOD – Books on Demand, Norderstedt
ISBN: 978-3-7357-4791-4
Business Process Management-Systeme (BPMS) setzen sich in der Praxis zunehmend als Plattformen für die IT-Unterstützung von Geschäftsprozessen durch. Wer sich mit modernen Konzepten betriebswirtschaftlicher Software auseinandersetzt, muss wissen, wie ein BPMS funktioniert und was es leisten kann.
Die bisher zu diesem Thema vorhandene Literatur beschäftigt sich entweder mit einzelnen Aspekten aus eher theoretischer Sicht, oder sie wendet sich an erfahrene Software-Architekten und IT-Manager, die bereits über umfassende Vorkenntnisse verfügen. Demgegenüber strebt das vorliegende Buch an, einen fundierten Einstieg in das Thema zu ermöglichen und die relevanten Konzepte in ihrem Zusammenspiel zu vermitteln. Es wird also nicht nur thematisiert, wie Prozesse modelliert und die Modelle zur Ausführung gebracht werden. Schließlich erfordert eine Software zur Prozessunterstützung neben den Prozessmodellen auch Daten, Regeln, Anwendungslogik, Benutzungsoberflächen, Rollenkonzepte sowie die Integration anderer Systeme und die Anbindung externer Geschäftspartner. Diese Aspekte werden daher ebenso behandelt.
Vielfach wird kritisiert, dass herkömmliche BPMS mit ihren recht starr vordefinierten Ablaufreihenfolgen nicht für alle Arten von Prozessen geeignet sind. Insbesondere bei wissens- und kommunikationsintensiven Prozessen stoßen sie an ihre Grenzen. Andererseits verfügen die meisten Unternehmen nach wie vor über sehr viele stark strukturierte, standardisierbare und zum Großteil automatisierbare Prozesse. Ohne standardisierte Prozesse wäre es vielfach nicht möglich, große Mengen an Produkten und Dienstleistungen schnell und kostengünstig zu erstellen. Das riesige Potenzial zur BPMS-Unterstützung der hierfür erforderlichen Prozesse ist bislang nur zu einem recht geringen Teil ausgeschöpft.
Selbstverständlich werden BPMS auch weiterentwickelt und um neue Ansätze ergänzt. Beispiele für aktuell diskutierte Entwicklungen sind „Adaptive Case Management“ (ACM) für wissensintensive, nicht genau vorherbestimmbare Prozesse, und „Social BPM“, das die Konzepte sozialer Netzwerke für das Prozessmanagement nutzen möchte. Wer diese, zum Teil in Abgrenzung des herkömmlichen BPMS-Ansatzes entwickelten Konzepte beurteilen möchte, muss zunächst einmal verstehen, wie ein BPMS überhaupt funktioniert. Hinzu kommt, dass das Prinzip heutiger BPMS recht weit entwickelt und etabliert ist, wohingegen sich die Entwicklung von Adaptive Case Management und Social BPM noch stark im Fluss befindet. In vielen Fällen sind auch Kombinationen neuer Konzepte mit dem herkömmlichen BPMS-Ansatz sinnvoll.
Aus diesen Gründen konzentriert sich die vorliegende Einführung auf die eigentlichen BPMS-Grundlagen, wie sie sich in vergleichbarer Form als Basiskomponenten in fast allen BPM-Systemen finden. Im letzten Kapitel wird erläutert, welche neuen Ansätze und aktuelle Entwicklungen es im Bereich der BPM-Technologien gibt, und wie diese mit den im Buch beschriebenen Basiskonzepten zusammenhängen.
Der Fokus des Buchs liegt auf der Modellierung, Entwicklung und Ausführung BPMS-basierter Anwendungen zur Prozessunterstützung. Nicht behandelt werden dagegen die für das Funktionieren eines BPMS erforderlichen Basistechnologien und Infrastrukturkomponenten, wie z. B. Web Server, Verzeichnisdienste, ESBs (Enterprise Service Bus) oder für die Sicherheit erforderliche Komponenten.
Genauso wie man Programmieren nicht durch das bloße Lesen eines Lehrbuchs lernen kann, gelangt man erst dann zu einem tieferen Verständnis von BPMS, wenn man selbst ausführbare Prozessmodelle entwickelt und ablaufen lässt. Daher wurden die praktischen Beispiele in diesem Buch mit dem Open Source-System „Bonita BPM“ entwickelt. Unter community.bonitasoft.com kann die Community Edition dieses Systems kostenfrei heruntergeladen werden. Es lässt sich mit geringem Aufwand auf handelsüblichen PCs mit den gängigen Betriebssystemen installieren. Der Einstieg ist recht einfach und intuitiv. Es ist daher sehr gut für die ersten Schritte mit einem BPMS geeignet. Gleichzeitig handelt es sich um ein vollwertiges System, das bei einer Reihe von Firmen im produktiven Einsatz ist.
Mit der Verwendung von Bonita BPM soll keine allgemeine Empfehlung für dieses System ausgesprochen werden. So wurde eine ganze Reihe von Eigenschaften nicht untersucht, die für einen produktiven Einsatz wichtig sind, wie z. B. Performance, Skalierbarkeit, Sicherheit etc.
Zum Erlernen gibt es neben Bonita auch eine ganze Reihe weiterer Systeme, die man problemlos herunterladen und kostenlos nutzen kann, wie z. B. die Open Source-Entwicklungen Activiti, camunda BPM oder jBPM. Auch kommerzielle Systeme bieten z. T. kostenfreie Community-Editionen an oder ermöglichen die zeitlich unbeschränkte Evaluation. Beispiele sind Bizagi, Intalio, Oracle oder Processmaker. In manchen Fällen ist die Zahl der Benutzer oder der Prozesse beschränkt, was für das Erlernen der Entwicklung von BPMS-basierten Anwendungen aber kein Hindernis ist. Neben Bonita wird in diesem Buch auch ein kleines mit Intalio realisiertes Beispiel verwendet, um die Kommunikation zwischen unterschiedlichen Prozessen und BPM-Systemen zu demonstrieren.
Ansonsten wurden sämtliche Beispiele mit der Community Edition von Bonita BPM (Version 6.3) entwickelt. Sie können auf der Website zum Buch heruntergeladen werden:
www.kurze-prozesse.de/bpms-buch
Beim Entwickeln der in diesem Buch vorgestellten Beispiele wurde auch festgestellt, dass zumindest in der kostenfreien Community Edition eine ganze Reihe wünschenswerter Features nicht vorhanden sind. Aus didaktischer Sicht ist dies manchmal sogar ein Vorteil. Wenn man sich etwa überlegen muss, wie man das Verhalten eines nicht unterstützten Modellierungskonstrukts auf anderem Wege erreichen kann, lernt man oft wesentlich mehr, als wenn man einfach einen vorgefertigten Modellierungsbaustein verwendet.
Das Buch richtet sich an Einsteiger in die Thematik. Ein gewisses Grundwissen über Informatik wird aber dennoch vorausgesetzt. Der Leser sollte beispielsweise wissen, was eine Variable ist, oder wofür man eine Datenbank einsetzt. An einigen Stellen ist es erforderlich, Programmcode zu nutzen. Bonita verwendet hierfür die Sprache Groovy, eine Erweiterung von Java. Java- oder Groovy-Kenntnisse sind daher von Vorteil, aber für das Verständnis des Buches nicht unbedingt erforderlich. Wer jedoch die auf der Website verfügbaren Beispiele selbst weiterentwickeln will, wird sich früher oder später mit Java auseinandersetzen müssen.
Prozessmodelle im Buch sind in BPMN erstellt, Datenmodelle in UML. Die verwendeten Konstrukte werden dabei jeweils erläutert, sodass Vorkenntnisse dieser Notationen nicht unbedingt erforderlich sind.
Zwar unterscheiden sich die BPMS unterschiedlicher Hersteller, doch finden sich typische Konzepte und Fragestellungen in ähnlicher Form bei allen Systemen. Daher eignet sich das Buch auch für Leser, die mit einem anderen BPMS arbeiten. Da Bonita keine Serverinstallation benötigt, lässt es sich leicht zusätzlich als Lern- und Experimentiersystem installieren. Sehr lehrreich dürfte es außerdem sein, die vorgestellten Beispiele mit einem anderen System umzusetzen. Der Autor freut sich über Weiterentwicklungen, Modifikationen und Portierungen auf andere Systeme und veröffentlicht gerne Erfahrungsberichte und Beispiele auf der Website zum Buch.
Abbildung 1 zeigt einen einfachen Prozess zur Angebotserstellung. An diesem Prozess wird die grundlegende Arbeitsweise eines Business Process Management-Systems (BPMS) illustriert.
Es sind zwei Rollen beteiligt: Ein Verkäufer und ein technischer Vertriebsmitarbeiter. Der Verkäufer startet den Prozess. Er erfasst zunächst eine ihm vorliegende Anfrage eines Kunden. Als Nächstes arbeitet der technische Vertriebsmitarbeiter das Angebot inhaltlich aus. Dann kalkuliert der Verkäufer das Angebot.
Der folgende, durch eine Raute dargestellte, exklusive Gateway verzweigt zu drei alternativen Fällen: Wenn das Angebot komplett ist, wird es versandt. Hat sich hingegen herausgestellt, dass die angefragte Leistung nicht machbar ist, so versendet der Verkäufer eine Absage. In beiden Fällen ist der Prozess danach beendet.
Die dritte Möglichkeit besteht darin, dass eine Überarbeitung erforderlich ist. Dann überarbeitet der technische Vertriebsmitarbeiter das Angebot, und es geht wieder mit dem Kalkulieren des Angebots weiter.
Ein solcher Angebotserstellungsprozess findet sich in Firmen mit etwas komplexeren technischen Produkten. So muss bei einem Hersteller von Unternehmenssoftware zunächst ein Experte die für die speziellen Bedürfnisse eines Kunden erforderlichen Software-Komponenten und Lizenzen zusammenstellen, bevor ein Verkäufer auf dieser Grundlage das eigentliche Angebot erstellt.
Abbildung 1: Ein einfacher Angebotserstellungsprozess
Die Darstellung gemäß BPMN (Business Process Model and Notation) dürfte mit Hilfe der obigen Beschreibung leicht verständlich sein. Im vorliegenden Buch werden erklärungsbedürftige BPMN-Konstrukte bei ihrem ersten Auftreten kurz erläutert. Eine Einführung in den kompletten BPMN-Standard findet sich in Allweyer 2009.
Welche Möglichkeiten gibt es, den beschriebenen Prozess mit Hilfe von Informationstechnik zu unterstützen?
Das Angebot wird mit Hilfe einer Textverarbeitung oder einer Tabellenkalkulation erstellt und per E-Mail oder über ein gemeinsam genutztes Verzeichnis auf einem Server ausgetauscht. Der Versand von Angeboten und Absagen kann ebenfalls über E-Mail oder klassisch per Brief oder Fax erfolgen. Können die Mitarbeiter auf geeignete Dokumentvorlagen zugreifen, so wird ihnen die Arbeit erleichtert.
In sehr einfachen Fällen ist diese Arbeitsweise durchaus geeignet. Sie ist simpel, benötigt keine große Vorbereitung und kann flexibel geändert werden.
Bei Prozessen, die sehr häufig durchgeführt werden und viele Arbeitsschritte und Mitarbeiter umfassen, ist dies hingegen keine gute Lösung. So lässt sich beispielsweise nicht sicherstellen, dass der vorgegebene Ablauf immer korrekt eingehalten wird. Außerdem ist es schwierig, die Nachfrage eines Kunden nach dem aktuellen Bearbeitungsstand seiner Anfrage zu beantworten. Auch können leicht Fehler passieren, wenn etwa eine E-Mail übersehen oder die Kundenadresse falsch abgeschrieben wird.
Fragt der Geschäftsführer nach, wie viele Angebote an welche Kunden versandt wurden oder wie lange ein Kunde auf ein Angebot warten muss, so ist es sehr mühsam, diese Informationen herauszusuchen.
Fast alle Unternehmen haben heute betriebliche Standardsoftware im Einsatz. So unterstützen Systeme für das Enterprise Resource Planning (ERP) alle wichtigen betrieblichen Funktionen, wie z. B. Finanzen, Vertrieb, Produktion und Personalmanagement. Ein wesentlicher Vorteil dieser Systeme ist die einheitliche Datenbasis über alle Funktionen hinweg. So greifen etwa alle Benutzer auf dieselben Kundendaten zu.
Meist enthalten ERP-Systeme auch Funktionen, mit denen man Angebote erstellen und verwalten kann. Daher liegt es nahe, den beschriebenen Prozess mit einem solchen System zu unterstützen. Allerdings gehört es nicht zu den typischen Eigenschaften herkömmlicher ERP-Systeme, Gesamtabläufe aktiv zu steuern. So kann man zwar die einzelnen Aktivitäten mit Hilfe eines ERP-Systems durchführen, doch müssen sich die Mitarbeiter selbst darum kümmern, dass die Aktivitäten in der richtigen Reihenfolge bearbeitet werden und dass nichts vergessen wird.
Moderne ERP-Systeme verfügen oftmals bereits über Workflow-Komponenten, die eine aktive Prozess-Steuerung ermöglichen. Damit enthalten sie zumindest einige Eigenschaften eines typischen BPMS, wie sie im Laufe dieses Buches erläutert werden.
Manche Aktivitäten in einem Prozess erfordern jedoch auch spezielle Funktionalitäten, die nicht von einem ERP-System angeboten werden. So könnten etwa für die Ausarbeitung des Angebots technische Berechnungen erforderlich sein. Daher müssen manche Aktivitäten außerhalb des Standardsystems durchgeführt werden, etwa mit einer speziellen Software oder wiederum mit einer einfachen Tabellenkalkulation. Werden die Daten manuell übertragen, bedeutet dies hohen Aufwand und kann leicht zu Fehlern führen. Überträgt man die Daten elektronisch über Schnittstellen, so müssen die passenden Schnittstellen häufig erst entwickelt werden. Prozessänderungen erfordern dann häufig auch eine mühsame und langwierige Änderung der Schnittstellen.
Betriebliche Standardsoftware bietet eine Reihe von Vorteilen für den betrachteten Prozess. Dadurch, dass man mit einer gemeinsamen Datenbasis arbeitet, werden Inkonsistenzen und Fehler reduziert. Auch sinkt der Arbeitsaufwand, weil man beispielsweise nicht mehr die Kundendaten in ein Angebotsdokument kopieren muss. Die Frage des Geschäftsführers nach der Zahl der Angebote, die an bestimmte Kunden versandt wurden, kann man nun wesentlich leichter beantworten. Schließlich liegen jetzt alle Angebote in einer gemeinsamen Datenbank und können leicht in dem ERP-System durchsucht werden.
Die Frage nach der Dauer einer Angebotserstellung lässt sich hingegen immer noch nicht so einfach beantworten. Auch wird durch ein ERP-System nicht sichergestellt, dass der vorgegebene Prozess eingehalten wird.
Dennoch spielen ERP- und ähnliche Systeme aufgrund der genannten Vorteile für viele Geschäftsprozesse eine wichtige Rolle. Auch wenn man ein BPMS verwendet, werden daher häufig solche Systeme integriert.
Die bisher genannten Varianten – Office und E-Mail bzw. betriebliche Standardsoftware – haben den Nachteil, dass der Kontrollfluss, d. h. die eigentliche Ablauflogik, von den IT-Systemen nicht berücksichtigt wird. Eine entsprechende Ablaufsteuerung lässt sich aber mit herkömmlichen Technologien und Programmiersprachen, wie z. B. Java oder C#, implementieren.
Man kann z. B. ein Webformular gestalten, in dem ein Verkäufer die Daten einer Anfrage eintragen kann. Drückt er auf „Absenden“, so schickt das Programm automatisch eine E-Mail an den technischen Vertriebsmitarbeiter. Diese E-Mail enthält einen Link zu einer Webseite, auf der die technischen Details des Angebots eingetragen werden können, usw. Auch die im Modell vorhandene Verzweigung lässt sich mit Hilfe der jedem Programmierer vertrauten „if… then… else…“-Anweisung implementieren.
Die Benutzungsoberfläche sowie die Anwendungslogik und die Datenhaltung in einer Datenbank lassen sich exakt auf die Anforderungen des betreffenden Prozesses abstimmen. Damit fällt das Problem der unterschiedlichen Systeme und der manuellen Übertragung von Daten weg.
Hat man es nur mit einzelnen, kleineren Prozessen zu tun, die sich praktisch nicht ändern, ist es durchaus überlegenswert, eine solch individuelle Lösung zu entwickeln. Gehen die Wünsche aber über eine ganz simple Ablaufsteuerung hinaus, so wird die Programmierung einer individuellen Lösung schnell sehr aufwändig. Möchte man beispielsweise nachvollziehen können, an welcher Stelle sich ein bestimmtes Angebot befindet, oder benötigt man Statistiken über abgewickelte Prozesse, so muss man vieles programmieren, was ein BPMS bereits als Standard mitbringt.
Ein typisches Problem bei der klassischen Anwendungsentwicklung ist zudem die Umsetzung der fachlichen Anforderungen in die Implementierung. Fachabteilungen und Software-Entwickler nutzen meist ganz verschiedene Darstellungsformen für Prozesse und andere wichtige Aspekte. Verständnisprobleme und Fehlinterpretationen sind nicht selten; und oftmals wird erst am fertigen System festgestellt, dass wichtige fachliche Aspekte nicht richtig umgesetzt sind.
Besonders problematisch ist eine hart programmierte Ablaufsteuerung vor allem dann, wenn Prozesse häufig geändert werden müssen. Jede Änderung bedeutet eine Überarbeitung des Programms und das Erstellen und Installieren eines neuen Software-Release. Die Dauer typischer Release-Zyklen für eigenentwickelte Software in Unternehmen beträgt mehrere Monate. Auch wenn sie klein sind, können Prozessänderungen in solchen Fällen erst nach Monaten implementiert werden. Oftmals verzichtet man wegen des Aufwandes komplett auf die Änderung des Prozesses. Die Prozesse sind dann „fest zementiert“, worunter natürlich die Flexibilität des Unternehmens leidet.
Die Ausführung von Prozessen mit Hilfe eines BPMS ist das Thema dieses Buches und wird daher im folgenden Unterkapitel genauer erläutert.
Ohne bereits auf technische Details einzugehen wird zunächst die grundlegende Arbeitsweise eines Business Process Management- oder Workflow Management-Systems betrachtet.
Die Begriffe „Business Process Management-System“ (BPMS) und „Workflow Management-System“ (WFMS) werden nicht ganz einheitlich verwendet, beide umfassen jedoch als zentrales Element eine Komponente zur Prozessausführung. In manchen Veröffentlichungen steht die Abkürzung BPMS auch für „Business Process Management Suite“. Damit soll ausgedrückt werden, dass die entsprechende Software noch zusätzliche Komponenten umfasst. Eine solche „BPM-Suite“ enthält aber immer ein „BPM-System“ als Kernkomponente. Im vorliegenden Buch wird daher durchgängig die Bezeichnung „Business Process Management-System“ verwendet, kurz BPM-System oder BPMS.
Abbildung 2 stellt die wichtigsten Komponenten eines BPMS dar. Im Zentrum steht eine Process Engine, die für die Abarbeitung der Prozesse zuständig ist. Zunächst modelliert aber ein Prozess-Entwickler den jeweiligen Ablauf. Typischerweise erstellt er ein BPMN-Modell wie das in Abbildung 1. Die Process Engine benötigt aber noch mehr Informationen als nur die im grafischen Modell enthaltene Ablaufreihenfolge. Es muss u. a. auch definiert werden, welche Daten bearbeitet und welche Dialoge für die einzelnen Aktivitäten aufgerufen werden sollen. Eine komplette Prozessdefinition enthält also das mit einer Reihe von Zusatzinformationen angereicherte Prozessmodell. Daher ist in der Abbildung nicht nur vom Modellieren, sondern auch vom Entwickeln eines Prozesses die Rede. Abbildung 3 zeigt die Modellierungs- und Entwicklungsumgebung „Bonita BPM Studio“.
Abbildung 2: Wichtige Komponenten eines BPMS
Abbildung 3: Modellierungs- und Entwicklungsumgebung „Bonita BPM Studio“
Die fertig gestellte Prozessdefinition wird auf den Process Engine-Server hochgeladen. Anschließend ist der Prozess zur Ausführung bereit. Die Prozessbeteiligten, wie Verkäufer oder technischer Vertriebsmitarbeiter, greifen über ein Prozessportal auf das BPMS zu. Hier können sie einerseits die Prozessbearbeitung starten, andererseits die ihnen zugeordneten Arbeitsschritte durchführen. Jedes Mal, wenn ein Arbeitsschritt beendet ist, leitet die Process Engine den Vorgang an den nächsten Prozessbeteiligten weiter.
Ein Prozess kann sehr oft durchgeführt werden. So wird der Angebotserstellungsprozess jedes Mal neu gestartet, wenn eine Kundenanfrage eintrifft. In der Process Engine wird hierfür jeweils eine neue Prozessinstanz angelegt. Eine Instanz des Angebotserstellungsprozesses enthält alle Informationen, die mit der Erstellung eines bestimmten Angebots zusammenhängen. Die einzelnen Prozessinstanzen werden unabhängig voneinander abgearbeitet und können sich jeweils in einem anderen Bearbeitungsstand befinden.
Abbildung 4: Prozessdefinition und Prozessinstanzen
In Abbildung 4 sind drei Instanzen dieses Prozesses gestartet worden. Jede Prozessinstanz enthält eine Reihe von Daten. Hierbei kann es sich um Daten handeln, die von der Process Engine automatisch erfasst werden, wie z. B. Startdatum und -zeitpunkt, oder welcher Verkäufer den Prozess gestartet hat. Um die Prozessinstanzen zu unterscheiden, erhält jede Prozessinstanz eine eindeutige Nummer als Identifizierer. Außerdem wird jeweils gespeichert, an welcher Stelle sich die Prozessbearbeitung gerade befindet.
Die meisten BPMS enthalten ein Prozessportal, auf das über einen Web-Browser zugegriffen wird. Die Prozessbeteiligten können darin Prozesse starten und die einzelnen Prozess-Schritte bearbeiten. In Abbildung 5 ist das Bonita BPM Portal zu sehen. Eingeloggt ist die Verkäuferin Lara Lauer. In der linken Spalte unter „Aufgaben“ befindet sich die „Inbox“ von Frau Lauer, auch als Taskliste oder Aufgabenliste bezeichnet. Ähnlich wie im Posteingang eines E-Mail-Programmes werden hier diejenigen Arbeitsschritte aufgelistet, die die eingeloggte Benutzerin in den laufenden Prozessinstanzen als nächstes durchführen kann. Die Einträge in dieser Liste werden von der Process Engine erstellt. Hat der technische Vertriebsmitarbeiter in einer Prozessinstanz den Schritt „Angebot ausarbeiten“ fertig bearbeitet, so erzeugt die Process Engine in den Verkäufer-Tasklisten einen Eintrag für den nächsten Arbeitsschritt „Angebot kalkulieren“. In Abbildung 5 enthält die Taskliste mehrere Einträge für diesen Arbeitsschritt, die jeweils zu verschiedenen Prozessinstanzen gehören.
Abbildung 5: Prozessportal von Bonita
Auf der rechten Seite werden einige Informationen zu der ausgewählten Aufgabe angezeigt. So sieht man z. B., wer bereits welche Aufgaben an dieser Prozessinstanz durchgeführt hat. Über den Button „Machen Sie es“, kann die Verkäuferin den Eintrag öffnen. Sie bekommt dann den Dialog zur Bearbeitung dieser Aufgabe angezeigt (Abbildung 6). Dieser Dialog, der für diesen Beispielprozess sehr einfach gehalten ist, enthält bereits einige Daten, die in vorangegangenen Arbeitsschritten erfasst wurden.
Die Verkäuferin kann nun den Preis und weitere Angaben ergänzen und schließlich über die Schaltflächen am unteren Rand bestimmen, wie weiter verfahren werden soll:
Abbildung 6: Dialog für den Arbeitsschritt „Angebot kalkulieren“
Abbildung 7: Administrationsportal
Sie kann das Angebot absenden, den Vorgang zur Überarbeitung zurückgeben oder eine Absage senden. Durch Drücken der gewünschten Schaltfläche wird anschließend an der im Prozessmodell (Abbildung 1) modellierten Verzweigung der betreffende Ausgang gewählt.
Neben dem Portal der gewöhnlichen Benutzer, die als Prozessbeteiligte mit dem BPMS arbeiten, gibt es auch eine Portalsicht für Administratoren. Sie können beispielsweise Prozessdefinitionen hochladen, Prozessinstanzen nachverfolgen sowie Benutzer und Rollen verwalten. In Abbildung 7 sind im mittleren Bereich alle Prozesse aufgelistet, die momentan auf der Process Engine zur Verfügung stehen und ausgeführt werden können. Neben dem bereits betrachteten Angebotserstellungsprozess finden sich dort beispielsweise Prozesse für die Bewerberauswahl und für die Einstellung neuer Mitarbeiter. Das, was auf dem Server installiert ist, sind streng genommen keine Prozesse, sondern Anwendungen oder Applikationen zur Unterstützung von Prozessen, die z. B. auch menschliche Tätigkeiten umfassen. In Bonita BPM wird daher anstelle von Prozessen von „Apps“ gesprochen.
Es wurde bereits erwähnt, dass für die Ausführung eines Prozesses nicht nur das Prozessmodell erforderlich ist, sondern noch eine Reihe weiterer Angaben benötigt werden. Häufig benötigte Informationen sind (Abbildung 8):
Abbildung 8: Erforderliche Zusatzinformationen zur Ausführung eines Prozesses
Beispielsweise könnten in einem Prozess Bestellungen aus einem System ausgelesen und später in einem anderen System gespeichert werden. Das erste System verwendet für die Bestellmenge ein Attribut „Stückzahl“. Dieses Attribut enthält die bestellte Menge als ganze Zahl. Das zweite System kann auch mit ganz anderen Mengeneinheiten umgehen. Es verwendet daher zwei Attribute: „Menge“ und „Mengeneinheit“. Die Menge wird dabei als Dezimalzahl mit zwei Nachkommastellen angegeben, für die Mengeneinheit wird ein Text verwendet, wobei vorgegebene Kürzel zu verwenden sind. In diesem Beispiel muss daher ein Mapping definiert werden, das beispielsweise die Angabe
Stückzahl: 23
des ersten Systems in die Attributwerte
Menge: 23.00
Mengeneinheit: „Stueck“
des zweiten Systems umwandelt. Bei einem solchen Mapping muss es sich nicht ausschließlich um reine Zuordnungen und Typkonvertierungen handeln. Es können beispielsweise auch Umrechnungen erforderlich sein.
Daten-Mappings werden unter anderem im Zusammenhang mit dem Aufruf anderer Prozesse in Abschnitt 3.4 und dem Versand von Nachrichten in Abschnitt 3.6 erläutert.