KNOWMODELS BPMN, Geschäftsregeln und der freie Wille Eine etwas andere Sichtweise auf Modelle Markus Schacher, 29. Mai 2015 In diesem Artikel behaupte ich, dass die BPMN Notation (Business Process Model and Notation) der OMG ein eigenes Symbol für den freien Willen beinhaltet. Indem ich Prozessmodelle mit dem freien Willen in Bezug bringe, erkläre ich, warum in der Praxis oft eine grosse Diskrepanz zwischen Prozessen, wie sie definiert wurden, und wie diese Prozesse von Menschen tatsächlich befolgt werden, besteht. Zudem zeige ich den Zusammenhang zwischen dem freien Willen, Geschäftsprozessmodellen sowie strukturellen und operativen Geschäftsregeln auf, wie sie die OMG Spezifikation SBVR (Semantics of Business Vocabulary and Business Rules) definiert. Ein einfacher Geschäftsprozess Ein Geschäftsprozessmodell ist eine "definierte Menge von Geschäftsaktivitäten, welche die Schritte darstellen, die notwendig sind um ein fachliches Ziel zu erreichen. Dies beinhaltet den Informationsfluss sowie auch deren Verwendung" [BPMN]. Das folgende Fragment eines Geschäftsprozesses illustriert die Ausgangslage für die weiteren Überlegungen: Sachbearbeiter Kreditantrag Kreditwürdigkeit bestimmen gut schlecht Kreditwürdigkeit? problematisch Vertrag erstellen Kunde informieren detaillierte Analyse durchführen akzeptiert abgelehnt weiter Abbildung 1: Ein einfacher Geschäftsprozess Stellen wir uns basierend auf diesem einfachen Geschäftsprozess ein konkretes Szenario vor: Tom Müller ist ein Kredit-Sachbearbeiter in einer Bank dessen Freund Peter Huber einen Kredit beantragt. Tom erhält Peter's Kreditantrag und bestimmt seine Kreditwürdigkeit. Dies tut er beispielsweise aufgrund einer Entscheidungstabelle, in der verschiedene Kriterien wie das monatliche Einkommen, das Geschlecht, der Zivilstand und weitere berücksichtigt werden und die daraus festlegt, wie der Antrag zu klassifizieren ist. Unglücklicherweise ergibt sich das Ergebnis "problematisch". Da Peter Tom's Freund und ein wichtiger Kunde der Bank ist, entscheidet sich Tom nicht wie vorgesehen eine detaillierte Analyse durchzuführen, sondern den Antrag zu akzeptieren und stellt einen Vertrag für Peter aus. Was passiert hier? Beim Entscheidungssymbol hat sich Tom bewusst gegen die Empfehlung gemäss der Entscheidungstabelle zur Bestimmung der Kreditwürdigkeit entschieden. Er ist der Meinung, dass er gute Gründe dafür hat und geht das Risiko ein, gegen den vorgeschriebenen Prozess zu verstossen. Ist dies gut oder schlecht? Wie auch immer, beim Entscheidungssymbol kam Tom's freier Wille zur Anwendung. 2015, KnowGravity Inc. Seite 1
Deontische Modelle An Menschen gerichtete Geschäftsprozessmodelle, wie das oben eingeführte Beispiel, werden in der Praxis oft als eine Art "Empfehlung" interpretiert. Sie mögen eine starke Empfehlung sein, aber sie bleiben eine Empfehlung, welche immer durch die Ausführungsverantwortlichen bewusst ignoriert bzw. verletzt werden kann. Normalerweise sind sich die Verantwortlichen über die Konsequenzen einer solchen Verletzung bewusst. Diese Konsequenzen resultieren aus der Durchsetzung dieser Vorschrift: in einem Unternehmen können beispielsweise Mitarbeiter, welche Vorschriften nicht beachten, verwarnt, sanktioniert oder im Wiederholungsfall gar entlassen werden. Es gibt eine spezielle Variante der formalen Logik, die sich mit dieser Art von Modellen befasst: die deontische Logik. Die deontische Logik führt drei spezifische Operatoren ein, welche die Bedeutung von Sätzen beeinflusst: Es ist obligatorisch, dass <eine Aussage> Es ist verboten, dass <eine Aussage> Es ist erlaubt, dass <eine Aussage> Die OMG Spezifikation "Semantics of Business Vocabulary and Business Rules" [SBVR] verwendet die deontische Logik um eine spezielle Art von Geschäftsregeln zu formalisieren: "operative Regeln", manchmal auch "Verhaltensregeln" genannt. Operative Regeln sind Vorschriften, die ausdrücken, was erlaubt ist und was nicht. Des Weiteren sind operative Regeln in SBVR eng mit ihrem "Durchsetzungsgrad" verbunden eine explizite Formulierung, wie die Befolgung dieser Regeln durchgesetzt wird. Als Beispiele schlägt SBVR die folgenden Durchsetzungsgrade vor: Strikte Durchsetzung: Bei Verletzung der Regel kommt immer eine Strafe zur Anwendung. Aufgeschobene Durchsetzung: Die Befolgung der Regel wird strikt durchgesetzt, allerdings kann dies verzögert sein, bis Ressourcen mit den notwendigen Fähigkeiten zur Verfügung stehen. Vorgängige Autorisierung: Die Regel wird durchgesetzt, allerdings sind Ausnahmen möglich, falls diese vorgängig autorisiert wurden. Nachträgliche Rechtfertigung: Wird die Regel verletzt und kann diese Verletzung nachträglich nicht gerechtfertigt werden, kommt eine Strafe zur Anwendung. Mit Begründung: Die Regel darf verletzt werden, allerdings muss eine solche Verletzung begründet werden. Empfehlung: Die Regel stellt eine reine Empfehlung dar, die nicht durchgesetzt wird. In unserem Beispiel könnte "Nachträgliche Rechtfertigung" der angebrachte Durchsetzungsgrad für die Kreditwürdigkeitsentscheidung sein; in anderen Fällen kommen andere Durchsetzungsgrade zur Anwendung. Deontische Aussagen geben Raum für den freien Willen: sie geben dem Ausführenden die Freiheit und Flexibilität in der Befolgung einer Vorschrift. Der freie Wille ist eng mit der Motivation des Ausführenden verknüpft, d.h. mit seinen Zielen. Diese Ziele können seine persönlichen Ziele sein, aber auch die Absicht ausdrücken, Ziele des Unternehmens zu verfolgen. Diese Ziele sind es wiederum, die einen Verantwortlichen dazu bringen können, entgegen Empfehlungen zu handeln und sich dadurch mögliche Konsequenzen einzuhandeln. Ich habe zwar das Entscheidungssymbol von BPMN dazu verwendet, um das Konzept deontischer Aussagen einzuführen. Bei einem zweiten Blick auf das Prozessmodell wird jedoch schnell klar, dass sich praktisch jedes Modellelement deontisch interpretieren lassen kann. Beispielsweise kann die Aktion "Kreditwürdigkeit bestimmen" als Verpflichtung verstanden werden, nach Eingang eines Kreditantrags die Kreditwürdigkeit des Antragstellers zu bestimmen. Aus diesem Grund ist es hilfreich, die deontische Bedeutung der Elemente eines Geschäftsprozesses klar zu deklarieren: Sind es Verpflichtungen, sind es Erlaubnisse oder sind es gar Verbote? Wo Menschen in einem Geschäftsprozess involviert sind, ist es zudem sinnvoll, den entsprechenden Durchsetzungsgrad explizit zu machen. 2015, KnowGravity Inc. Seite 2
Wissen und Entscheidungen In unserem einfachen Prozessmodell gibt es noch eine weitere interessante Aktivität: "Kreditwürdigkeit bestimmen". Wie bereits erwähnt ist diese Aktivität mittels einer Entscheidungstabelle beschrieben, in der verschiedene Kriterien wie der gewünschte Betrag, das monatliche Einkommen, das Geschlecht, der Zivilstand und weitere berücksichtigt werden. Daraus werden die dann drei möglichen Einstufungen "gut", "schlecht" und "problematisch" abgeleitet. Eine Entscheidungstabelle ist eine Menge von Regeln, welche in SBVR als "Strukturelle Regeln", manchmal auch "Definitionsregeln" bezeichnet werden. Strukturelle Regeln definieren, wie verschiedene Aussagen zueinander in Beziehung stehen, beispielsweise wie sich die Aussage "die Kreditwürdigkeit ist 'problematisch'" aus Aussagen wie "das Geschlecht ist 'männlich'", "das monatliche Einkommen ist 5000" sowie weiteren ergibt. Im Gegensatz zu den operativen Regeln können strukturelle Regeln nicht verletzt werden sie sind einfach Wissen, welches bei der Herleitung neuer Information aus bereits vorhandener Information angewandt werden kann. Zusammenfassend lässt sich nun der gesamte Beispielprozess in die folgenden vier Teilschritte aufgliedern: Als erstes nimmt der Sachbearbeiter einen Kreditantrag vom Antragsteller entgegen. Dann führt er die Aktivität "Kreditwürdigkeit bestimmen" aus. Dies ist eine "Wissensaktivität", da sie durch das Anwenden von Wissen in Form einer Menge struktureller Regeln die Kreditwürdigkeit des Kunden bestimmt. Das Ergebnis dieser Wissensaktivität fliesst dann in die Entscheidung "Kreditwürdigkeit?" ein, welche die darauf folgende Aktivität festlegt. Abhängig vom Ergebnis dieser Entscheidung wird der Sachbearbeiter dann eine der drei Aktivitäten "Vertrag erstellen", "Kunde informieren" oder "detaillierte Analyse durchführen" ausführen. Interessanterweise lassen sich diese vier Teilschritte einfach auf ein Muster abbilden, welches Robert Kowalski im Zusammenhang mit seiner Arbeit zu "motivierten Agenten" entwickelt hat, d.h. Agenten, die einen freien Willen zeigen (siehe [Kowalski]). Dieses Muster ist aus den vier Stufen "wahrnehmen" (entspricht ), "denken" (entspricht ), "entscheiden" (entspricht ) und "handeln" (entspricht ): Agent denken entscheiden wahrnehmen handeln externe Welt Abbildung 2: Der Agenten-Zyklus nach Kowalski In Kowalski's Muster findet der freie Wille in der "entscheiden"-stufe statt, welche der Entscheidung "Kreditwürdigkeit?" unseres einfachen Beispiels entspricht. Übrigens: Unter "Agent" versteht Kowalski sowohl menschliche Agenten als auch nicht-menschliche Agenten wie IT-Systeme. 2015, KnowGravity Inc. Seite 3
IT-Systeme und der freie Wille Was passiert, wenn ein solcher einfacher Geschäftsprozess mittels konventioneller Prozessautomatisierung oder einem Workflow-Management-System implementiert wird? Ein solches System wird blind den Vorgaben des Prozesses folgen, d.h. es wird immer entsprechend der evaluierten Kreditwürdigkeit handeln. Diese Art von IT- Systemen zeigt bestimmt keine Art von freiem Willen. Auf der anderen Seite könnte ein IT-System zur Prozessautomatisierung Ziel-orientiert arbeiten, es könnte verschiedene konkurrierende Taktiken zur Erreichung seiner Ziele in Betracht ziehen und dann diejenige auswählen, von denen es glaubt, dass sie am ehesten zum Ziel führt. Mit anderen Worten: es könnte eine Art freien Willen zeigen. Ein solches zielorientiertes Geschäftsprozessmanagementsystems ist beispielsweise das kommerziell erhältliche "LSPS" von Whitestein Technologies [Whitestein]. Seitenblick: Ähnliche Überlegungen lassen sich aber nicht nur bezüglich der Laufzeit eines IT-Systems, sondern auch über die Entwicklungszeit eines solchen Systems anstellen. Die Anforderungen an ein IT-System können als Menge deontischer Regeln aufgefasst werden: Verpflichtungen, Erlaubnisse oder gar Verbote bezüglich der Funktionalitäten des zukünftigen IT-Systems. Es liegt dann in der Kompetenz des Requirements Engineers, zusammen mit dem Auftraggeber und dem Projektleiter zu bestimmen, welche dieser Anforderungen realisiert werden und welche nicht. Der Entscheid, eine obligatorische Anforderung nicht zu realisieren hat üblicherweise Konsequenzen oder gar Risiken zur Folge, die sorgfältig gegenüber dem Nutzen, gewissen Realisierungsaufwand einzusparen, abgewogen werden müssen. Dieser Prozess wird dann als "Anforderungspriorisierung" bezeichnet. Zusammenfassung Wenn Geschäftsprozesse gestaltet werden (z.b. mittels BPMN), ist eine explizite Unterscheidung zwischen "Wissensaktivitäten", welche die Grundlagen für Entscheidungen liefern, und den eigentlichen Entscheidungen sehr zu empfehlen. Wissensaktivitäten lassen sich beispielsweise mittels Entscheidungstabellen oder strukturellen Regeln nach SBVR spezifizieren. Entscheidungen (sowie die Reihenfolge auszuführender Aktivitäten) stellen deontische Vorschriften dar, welche dem freien Willen des Ausführenden unterlegen sind. Sie entsprechen operativen Regeln, welche einen (potentiell expliziten) Durchsetzungsgrad erfordern. Werden solche Entscheidungen auf der Basis operativer Regeln in Form von vollautomatisierten, zielorientierten Geschäftsprozessen realisiert, so führt dies zu einer gänzlich neuen Stufe von Flexibilität von IT-Systemen. Referenzen [BPMN] Object Management Group: Business Process Model and Notation (version 2.0), pas/2013-03- 04/ISO/IEC 19510:2013(E), März 2013 [Kowalski] Robert Kowalski: Computational Logic and Human Thinking How to be Artificially Intelligent, Cambridge University Press, 2011 [SBVR] Object Management Group: Semantics of Business Vocabulary and Business Rules (version 1.2), formal/2013-11-04, November 2013 [Whitestein] Whitestein Technologies: Living Systems Process Suite, http://www.whitestein.com/products/processsuite 2015, KnowGravity Inc. Seite 4
Über den Autor Markus Schacher (markus.schacher@knowgravity.com) ist Mitbegründer und KnowBody von KnowGravity Inc. (www.knowgravity.com), einem kleinen aber feinem Beratungsunternehmen mit Sitz in Zürich (Schweiz), welches sich auf modellbasiertes Engineering spezialisiert hat. Als Trainer hat Markus bereits 1997 die ersten öffentlichen UML-Kurse in der Schweiz durchgeführt und hat als Berater vielen grossen Projekten geholfen modellbasierte Techniken einzuführen und nutzbringend anzuwenden. Heute ist er als aktives Mitglied der Object Management Group (OMG) in die Entwicklung verschiedener Modellierungssprachen involviert, beispielsweise dem "Business Motivation Model" (BMM), "Semantics of Business Vocabulary and Business Rules" (SBVR), sowie dem "UML Testing Profile" (UTP). Er ist Ko-Autor dreier Bücher zu den Themen Geschäftsregeln, SysML sowie operationellen Risiken und ist häufiger Präsentator auf internationalen Konferenzen. 2015, KnowGravity Inc. Seite 5