Mar
19
2010

SAPERION und Signavio auf dem Weg zum BPM Round-Trip Engineering

Eingangsrechnungsfreigabeprozess

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.

Empfänger ist Besitzer

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:

manuelle Verteilung

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

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

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

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

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

Ü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

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)

Ergänzung vom 24.11.2010:

Wir haben es heute in die BPMN Supporter Liste der Object Management Group – OMG – geschaft. Die OMG ist der Hort, an dem die Spezifikation des Standards für die grafische Darstellung für Geschäftsprozesse, die Business Process Model and Notation – BPMN – erarbeitet wird.

Wie an der Liste leicht zu erkennen ist, befinden wir uns nun in guter Gesellschaft bekannter Hersteller von Modellierungswerkzeugen als auch BPM Suiten. Wir sind hier bisher der einzige ECM Hersteller, der sich geoutet hat.

Ergänzung vom 24.12.2010:

Nun auch eine Geschichte rund um das Thema BPM Round-Trip und die Mehrwerte mit dem SAPERION Process Editor powered by Signavio.

Ergänzung vom 22.05.2012:

Das folgende Bild zeigt das Zusammenspiel von Signavio und SAPERION. Signavio liest über einen Web-Service (Classic Connector) Nachschlagewerte für die ergänzenden SAPERION Attribute im Modeler. Mit dem Deployment wird das BPMN 2.0 XML-File zusammen mit einem Image des Prozesses ebenfalls via Web-Service an den Transformer übertragen. Dieser Mapped die BPMN 2.0 Elemente mit ihren Attributen auf die der SAPERION Prozess-Definition. Die deployten Prozesse sind direkt ausführbar und müsse nicht mehr in SAPERION nachgearbeitet werden. Am SAPERION Client steht dem Anwender die gleiche Prozess-Grafik wie in Signavio zur Orientierung zur Verfügung.

 

Zusammenspiel von Signavio und SAPERION

Zusammenspiel von Signavio und SAPERION

Post to Twitter Post to Delicious Post to Digg Post to Facebook Post to MySpace

Download PDF
Written by Dr. Martin Bartonitz in: deutsch,language | Tags: , , , ,

10 Comments »

  • Dr. Martin Bartonitz

    Und gleich noch ein schöner Überblick, warum es noch etwas länger braucht, um die Brücke zwischen den Prozessanalysten/-dokumentaristen hin zu den IT-Engineers, die die Prozessausführung verantworten müssen, konfliktfrei schlagen zu können:
    http://www.kurze-prozesse.de/2010/03/19/eignet-sich-bpmn-fur-das-business/

    Comment | 20 March 2010
  • Hallo Martin,

    wow, vielen Dank für den Post. Es kommst selten vor dass ein Vendor so offen über seine aktuellen Entwicklungen spricht. Hoffen wir, dass das Beispiel Schule macht. Und mehr “harte Fakten” und weniger “weiche Versprechen” publiziert werden. Am Ende bringt das alle weiter.

    VG Jakob

    Comment | 20 March 2010
  • Norbert Weißenberg

    Hallo Herr Bartonitz,

    ich fand den Post auch sehr informativ und richtungsweisend. Vielleicht können die als fehlend ermittelten Attribute noch in den BPMN 2.0-Standardisierungsprozess einfliessen?

    Eine Frage noch: Datenfluss wird SAPERION zunächst nicht unterstützen? Auch Lanes sind im Überblick-Diagramm nicht enthalten?

    Viele Grüße,
    Norbert

    Comment | 22 March 2010
  • Dr. Martin Bartonitz

    Hallo Herr Weißenberg,
    da wir noch kein Mitglied der OMG sind, haben wir noch keinen Einfluss auf den Standard. Wir prüfen aktuell, ob wir mit machen sollten.
    Für SAPERION ist der Datenfluss innerhalb eines Prozesses derzeit nicht interessant, da immer sämtliche Instanz-Daten bei jeder Aktivität zur Verfügung stehen.
    Da unser ProcessDesigner immer nur einen Prozess in der Arbeitsoberfläche zu modellieren erlaubt, können wir auf den Pool verzichten. Auch die Lane werden wir erst einmal nicht direkt anbieten. Indirekt kann man dies tun, indem einfach Kästchen gemalt werden. Diese haben aber keine Prozessattribute, also wären sie maximal ein Visualisierungsworkaround.
    Wer daher Wert auf Pools und Lanes legt, fährt dann gut mit dem Process Editor von Signavio.
    VG, Martin Bartonitz

    Comment | 22 March 2010
  • Christian Hrach

    Hallo Herr Dr. Bartonitz,

    Nachdem Sie bei Ihrem Gastvortrag in der Lehrveranstaltung Geschäftsprozessmanagement im letzten Dezember schon erste Aspekte des integrierten BPM Round-Trips vorgestellt hatten bin ich schon sehr gespannt, was Sie uns im nächsten Wintersemester zu den bis dahin erreichten Fortschritten präsentieren werden.

    VG, Christian Hrach

    Comment | 25 March 2010
  • Hallo Herr Dr. Bartonitz,

    wirklich ein sehr interessanter Artikel.
    Wenn Sie innerhalb des SAPERION ProcessDesigners keine Unterstützung für Lanes anbieten, wie lösen Sie dann die Prozessintegration von Rollen und deren Berechtigungen?

    Beste Grüße
    Manuel Hermann

    Comment | 25 March 2010
  • Dr. Martin Bartonitz

    Hallo Herr Hermann,
    da die Art und Weise der Bestimmung des Empfängers in der Regel nicht so trivial dargestellt werden kann, wie dies mit der Lane in der BPMN geschieht, stellen wir einen relativ umfangreichen Konfigurationsdialog zu Verfügung.
    Empfängerbestimmung in SAPERION
    Beispiele:
    1. Die einfachste Variante: es wir eine Organisationseinheit ausgewählt, das entspricht einer Lane. Wir legen des Weiteren fest, ob das Work Item von einem Mitglied der Organisationseinheit manuell aus dem Korb übernommen werden soll, oder ob nach Auslastung oder reihum automatisch verteilt werden soll (gibt es so in BPMN nicht)
    2. Rolle Vorgesetzter: Aktivität soll vom nächst höheren Vorgesetzten des vorherigen Bearbeiters empfangen werden (gibt es im BPMN nicht)
    3. Der Besitzer der Workflow-Instanz soll Empfänger werden, vergleiche Bild oben mit “Owner” (gibt es so im BPMN nicht)
    4. Der Empfänger soll aus einer Matrix in Bezug auf Kundentyp, Produktklasse, Kostenstelle und Betrag ausgewählt werden. Hierzu kann ein Script hinterlegt werden, das auf Basis der Instanzdaten den Empfänger bestimmt (siehe Thema Rule Engine)(gibt es so in BPMN nicht)
    5. Der vorherige Bearbeiter soll im Augenblick seiner Weiterleitung den Empfänger der nächsten Aktivität selbst bestimmen, da er am Besten weiß, wer das sein sollte (alternative für das Auswerten per Macro: Das Wissen des Experten ist gefragt)
    Sie sehen, dass die Lange zwar ein schönes Konstrukt ist, um einen Prozes übersichtlich zu dokumentieren, aber das Leben ist doch komplexer als das einfache Bildchen. Daher ist das BPM Round-Trip Engineering auch keine einfaches Thema und ich spreche nicht umsetzt von einem steinigen Weg, den wir alle noch zu gehen haben, bis das rund wird.
    Viele Grüße, Martin Bartonitz

    Comment | 25 March 2010
  • Hallo Herr Dr. Bartonitz,

    danke für die umfassende Erläuterung. Das ist in der Tat eine hohe Flexibilität. Wobei der Punkt 4. eventuell über ein Komplexes Gateway modelliert werden könnte, ohne hier Details zu kennen.

    Beste Grüße
    Manuel Hermann

    Comment | 26 March 2010
  • Dr. Martin Bartonitz

    In einer aktuellen Studie des BPM-Labors der Fachhochschule Koblenz haben nur ca. 40 der befragten Umsetzer von BPM-Projekten fachliche und technische Modelle miteinander verknüpft. Weitere Aspekte sind hier nachzulesen:
    http://www.kurze-prozesse.de/2009/11/30/bpm-gewinnt-in-der-krise-in-15-jahren-aktueller-denn-je/comment-page-1/

    Comment | 31 March 2010
  • Dr. Martin Bartonitz

    Dass der Weg tatsächlich steinig werden wir, zeigt dieser schöner Beitrag. Hier wurde ein BPMN Diagramm im Editor der itp Commerce erstellt und in IBM’s Blueprint (Lombardi) und ARISalign eingelesen. Zwar auf Basis von XDPL und nicht BPMN 2.0 Serialisierung, aber schaun wir mal:
    http://antiamba.blogspot.com/2010/05/bpmn-can-bring-death-to-your-process.html

    Comment | 6 May 2010

RSS feed for comments on this post. TrackBack URL

Leave a comment


× five = 20

Theme: TheBuckmaker.com Web Templates | Bankwechsel Umschuldung, Iplexx IT Solutions