SAPERION Blog

Eingangsrechnungsfreigabeprozess

Nun sind wir schon einen großen Schritt weiter. Vor einem Jahr habe ich einen ersten Artikel über die Fallstricke des BPM Round-Trip Engineering berichtet und habe den Ausblick gegeben, dass mit der neuen Version 2.0 der Business Process Modeling Notation (BPMN) die Möglichkeit besteht, die beiden Welten der Prozessdokumentation (Pros und Cons) und -ausführung zusammenzubringen. Ich hatte hier auch behauptet, dass es noch ein paar Jahre dauern wird, bis der Kreis richtig geschlossen wird. Mit diesem Beitrag möchte ich erste Details darstellen, was so alles beachtet werden muss, wenn ein Prozess in einem BPMN-Tool erstellt wird und an eine Workflow Engine, hier SAPERION Workflow, zur Ausführung übergeben werden soll. Und es wird tatsächlich noch etwas brauchen, bis der BPMN-Standard so weit erweitert ist, dass eine Prozessausführung bis ins letzte Bit funktionieren wird.

Wenn ich einen internen Prozess dokumentiere, hilft es mir besonders, wenn ich mir Gedanken darüber mache, wie denn das Gegenstück beim “Kunden” aussieht. Als Argument möchte ich auf die Ideen des Customer Expectation Management hinweisen, wo jeder Kontakt mit dem Kunden ein Moment der Wahrheit ist, sprich wo er mit meinem Service zufrieden sein wird oder aber auch nicht. Ich möchte das Round-Trip Engineering beispielhaft am Eingangsrechnungsprozess, wie in der ersten Grafik gezeigt diskutieren. Erstellt ist diese mit dem Process Designer von Signavio, unserem Kooperationspartner für das Round-Trip Engineering. Das Beispiel ist nicht bis ins Detail ausgearbeitet, da dies für die im Folgenden besprochenen Punkte nicht notwendig ist.

Die Grafik zeigt im oberen Pool den Prozess beim Rechnungsersteller. Die hier in der Aktivität “Rechnung versenden” ausgehende Nachricht ist das auslösende Ereignis für den Start meines Eingangsrechnungsprozesses. Wenn ich nun im Signavio Process Editor zum Diagramm die Funktion “Delivery to SAPERION ” aufrufe, möchte ich, dass auch nur mein Rechnungsprozess und nicht auch der dargestellte zum Rechnungsempfänger an die Workflow Engine übertragen wird. Hier fehlt im BPMN-Standard noch das Flag zur Kennzeichnung. Daher wird es dafür erst einmal eine proprietäre Lösung von Signavio geben.

Bei der Übertragung von Signavio nach SAPERION  finden einige Transformationen statt, da die SAPERION Prozessstruktur (noch) nicht 100% der der BPMN entspricht (als SAPERIOn Workflow spezifiziert wurde, war BPMN noch nicht erfunden) . Nicht transformiert werden müssen der Name des Pools, der zur Prozess-Definition in SAPERION wird. Die Texte innerhalb der Aktivitäten werden zu den Aktivitätsnamen, die Beschreibungen zur Aufgabenbeschreibung. Die Lane-Namen zu den Empfängern, wenn zum BPMN-Attribut Ausführende (Performer) kein Eintrag gemacht wurde. Und genau hier, bei der Bestimmung des Empfängers ist schon ein neuralgischer Punkt erreicht.

SAPERION kennt die Rolle des Besitzers (Owner)  einer Prozessinstanz, die als Empfänger der Aktivität eingetragen werden kann. Da es noch kein Extra-Attribut dafür im Teil der Prozessausführung der BPMN gibt, muss zum Attribut “ausführender” eine Notation verwendet werden, die der Transformer dann korrekt umsetzen kann, sprich hier muss der Standard noch/schon umgangen werden. Als Notation bietet sich an, den Begriff “Owner” in das Feld für die Aktivität (hier: “Rechnung buchen” einzutragen, wenn z.B. der gleiche Bearbeiter wie zur Aktivität “Buchung vorerfassen” als Empfänger adressiert werden soll.

Konfiguration, damit für die Aktivität der aktuelle Besitzer des Instanz der Empfänger wird

Die schwierige Frage ist nun, wie der Besitzers festgelegt wird. SAPERION trägt automatisch als Besitzer einer Prozessinstanz den Startenden ein. Wenn dieser aber ein Automatismus war, wird unterwegs der Besitzer z.B. festgelegt, indem zu einer Aktivität definiert werden kann, dass ab hier der Besitzer der Ausführende (Bearbeiter) der Aktivität wird. Da es es auch hier noch kein passendes BPMN-Attribut gibt, muss nochmals die Verwendung einer Spezial Notation verwendet werden. Entweder man macht dies über eine sogenannte Extension, die in einem eigenen Name Space der BPMN-XML-Datei untergebracht wird, oder man macht dies wieder über einen speziellen Eintrag im Feld “Ausführender”:

Konfiguration, damit der Bearbeiter nach der Bearbeitung Besitzer wird

Das war noch einfach. Eine häufige Anforderung ist die Festlegung, wie denn ein Aktivität an ein Mitglied einer Organisationseinheit (im Falle der BPMN die Lane) verteilt werden sollen. Typische Verteilungen sind im Modulo-Verfahren reihum, nach Last oder indem der Benutzer selbst aus dem Eingangskorb der Organisationseinheit bedienen sollen. Auch hierfür gibt es noch keine BPMN Entsprechungen, so dass nochmals am Standard vorbei gearbeitet werden muss. Also gleich nochmals die Eigenschaft “Ausführender” nutzen:

Konfiguration der manuellen Übernahme einer Aktivität aus dem Gruppenkorb durch den Benutzer

Da bei dieser Aktivität sowohl eine manuelle Verteilung in die Organisation erfolgen soll, als auch der Bearbeiter dann der Besitzer werden soll, müssen die beiden Notationen noch voneinander getrennt werden, so dass der Transformer die passenden Attribute im SAPERION Workflow setzen kann. Für die alternativen Verteilungen bieten sich an “Distribution:workload” und “Distribution:equal”.

Konfiguration der Entscheidung durch den Benutzer, wo es lang gehen soll

SAPERION Workflow bietet nicht nur eine Verzweigung, die durch Auswertung von Parametern, wie im der 1. Grafik gezeit mit “amount > 5000″, durch die Engine geregelt wird. Alternativ geben wir die Verantwortung in die Hände der Benutzer. Ist dieser mit der Bearbeitung seiner Aufgabe fertig, entscheidet er über passende Kontextmenüeinträge, wohin es im Sequenzfluss weitergehen soll. Wir werden dies durch die Transformation so gestalten, dass die Bedingungseigenschaft eines Sequenzfluesses die Syntax “User:hier gehts lang” trägt.

Ein weiteres spannendes Thema ist die Festlegung der Bearbeitungsoberfläche, sprich die Bearbeitungsmaske für die Datenmanipulation, wenn der Bearbeiter in seiner Inbox zu einer ausgewählten Aktivität seine Arbeit beginnen will. Auch ein solches BPMN-Attribut fehlt noch. Als Möglichkeit steht hier das Feld “Script” zur Verfügung, dass wieder mit einer entsprechenden Notation gefüllt werden kann, die der Transformer entsprechend umsetzen muss. SAPERION unterscheidet Masken für den Geschäftsfall (Metadaten der Prozessinstanz), für das Dokument, das mit der Prozessinstanz verknüpft ist, sowie einer Validierungsmaske zu diesem Dokument. Letztere dient zur Plausibilitätsprüfung, sprich ob alle Felder korrekt ausgefüllt sind, wenn zur nächsten Aktivität weitergeleitet werden soll.

Formular für die Bearbeitung eines Dokuments

Diese einfachen Beispiele zeigen schon sehr deutlich, das wir tatsächlich am Anfang stehen, von einem beliebigen Modellierungstool die Prozessmodelle an eine beliebige Workflow Engine zu übertragen. Da es noch eine Reihe von Lücken im Bereich der BPMN-Ausführung gibt, müssen Workarounds beschritten werden, die der Hersteller einer Prozess Engine  in seiner Transformation individuell noch lösen muss.

Ich habe Hersteller gesprochen, die noch den Weg beschreiten, in beiden Editoren Konfigurationen zuzulassen. D.h. die Organisatoren beginne mit ihrem Tool, und nach der Delivery an die Workflow Engine werden die Engine relevanten Eigenschaften noch in dem Editor der Engine hinzu konfiguriert. In diesem Fall wird es richtig schwierig: diese Daten müssen entweder wieder zurück, oder beim nächsten Delivery dürfen die zusätzlichen Daten nicht überschrieben werden. Das mag noch einfach sein, wenn der Ablauf identisch bleibt und nur die Eigenschaften der Elemente geändert werden. Aber was, wenn der Ablauf selbst verändert wird?

Wir verfolgen hier einen anderen Weg. Es sollen möglichst alle SAPERION Workflow-Eigenschaften im Signavio Process Editor eingetragen werden können. Um hier Fehler zu vermeiden, werden nach und nach Nachschlagefunktionen in Signavio zur Verfügung gestellt. So wird ausgewählt werden können, welches Formular oder welches Macro verwendet werden soll. Ebenso soll für den Name der Lane die Liste  Organisationseinheiten angeboten werden. Eine noch in der Analyse befindliche alternative Lösung ist die gemeinsame Verwendung eines LDAP-Verzeichnisses dafür.

Da die SAPERION Workflow Engine noch nicht alle BPMN-Elemente kennt und verarbeiten kann, wird Signavio einen SAPERION-spezifischen  BPMN Stencil-Set zur Verfügung stellen. So kann erreicht werden, dass nur die Elemente verwendet werden, die dann auch korrekt per “Delivery” übertragen werden können. z.B. kennt SAPERION kein komplexes Gateway. Zudem wird ein Plausibilitätscheck prüfen, bestimmte Modellerierungskonventionen eingehalten werden, z.B. ob nur ein Startereignis verwendet wurde. Damit nicht zu viele Elemente ausgeschlossen werden müssen, u.a. um nicht die Dokumentationsstärke zu beschränke, wird der SAPERION Transformer restliche Reduktionen vornehmen. SAPERION kennt derzeit nur ein einfaches Startereignis, d.h. alle anderen Startereignisse werden auf diese reduziert. Zudem werden nicht bekannte Zwischenereignisse gelöscht, aber ohne dass der Sequenzfluss dabei unterbrochen wird. Auch die weiteren beschreibenden Elemente wie z.B. Kommentare und Datenobjekte sowie die Nachrichtenflüsse werden bei der Transformation nicht mitgenommen.

Besonders spannend ist die Frage der Anzeige des Prozesses beim Workflow-Benutzer. SAPERION bietet dem Benutzer die Möglichkeit, zu einer Aktivität in seiner Inbox die grafischen Prozess anzeigen zu lassen. Dabei wird die gerade aktuelle Aktivität markiert, so dass er seine Arbeit im Kontext der anderen betrachten kann. Im Falle des Modellierens mit Signavio ist es wünschenswert, dass der Workflow-Benutzer das Original-Modell geöffnet bekommt. Denn hierin sind doch mehr Informationen erhalten als in dem transformierten Prozess. Dazu muss dann das Datenmodell im SAPERION Workflow noch erweitert werden, damit beim Aufruf des Signavio Process Editor im View-Modus die BPM-Modell-ID sowie die BPMN-Aktivitäts-ID zur Markierung mit übergeben werden können.

BPMN Serialisierung des Prozesses

In der BPMN Serialisierung (XML-basiert)  sind die einzelnen Elemente des BPMN-Modells gut zu erkennen. Angefangen mit der <definitions-id> für das Gesamtdiagramm, über die <process_id> für einen Pool (der Pool-Name steht leider viel weiter unten), bis zur <task name=… id=…> für die Aktivität.

Übrigens wird die BPMN voraussichtlich Konformitätsklassen unterscheiden. SAPERION wird alle Elemente der Klasse SIMPLE können, sowie weitere aus allen anderen 3 Klassen. Die Klassen entsprechen dem Komplexitätsgrad, den Modellierer nutzen wollen oder Process Engines unterstützen können.

Wer sich über den Stand der Entwicklung informieren möchte, kann dies auf unserem Kundenkongress am 28.04.2010 tun. Wir werden hier live zeigen, wie mit dem Signavio Process Editor professionell Geschäftsprozesse dokumentiert werden, per “Delivery” an SAPERION übertragen und mit der Workflow Engine ausgeführt werden kann. Sprechen Sie uns hier direkt an: Torben Schreiter, Geschäftsführer von Signavio, und Dr. Martin Bartonitz, Product Manager Workflow bei SAPERION.

Ergänzung am 24.03.2010.  Herr Hermann fragte nach, wie wir das in SAPERION mit der Bestimmung des Ausführenden machen, wenn wir keine Lanes habe. Sehen sie meine Antwort dazu auch unten. Ich möchte dazu noch unseren Dialog zeigen, indem die Empfängerbestimmung einer Aktivität erfolgt:

Empfängerbestimmung in SAPERION

Im Falle des “Vorbestimmt” öffnet sich eine weiterer Dialog, in dem über die Navigation durch die Benutzerhierarchie die Organisationseinheit ausgewählt wird.

Und zum Schluss noch der Ausblick auf den Satz an BPMN-Elementen und Konstrukten, die SAPERION Workflow mit der nächsten voraussichtlich unterstützen wird:

Überblick der SAPERION-BPMN-Elemente

Und noch etwas für den Gourmet: BPMN kann auch durch den Magen gehen, wie folgt

Kochrezept: Coq au Vin

Ergänzung vom 02.09.2010:

Es gibt inzwischen eine Fortsetzung mit weiteren Sreenshots. Nun bietet im Signavio Process Editor Nachschlagewerte für SAPERION-spezifische Steuerungswerte an. Siehe dazu den Post SAPERION und Signavio auf dem Weg zum BPM Round-Trip Engineering (2)