Entscheidungstabellen

Zweck

Die Entscheidungstabelle erfasst eine einzelne, atomare und wiederholbare Entscheidung als vollständige Menge von Bedingung-Aktion-Regeln. Atomar heisst, dass bei jedem Durchlauf ein einziges Ergebnis gewählt wird, aus einer im Voraus festgelegten Menge; wiederholbar, dass sich dieselbe Entscheidung vielfach über unterschiedliche Daten stellt. Wo eine in Fliesstext geschriebene Vorgabe ihre Regeln über Absätze verstreut und es der lesenden Person überlässt zu prüfen, ob sie alle Fälle abdecken, ordnet die Tabelle sie in einem Raster, in dem sich Vollständigkeit und Konsistenz ablesen lassen.

Ihr eigener Wert beruht auf zwei Eigenschaften, die konstruktionsbedingt überprüfbar werden. Die Vollständigkeit: Für n binäre Bedingungen zählt das Raster 2ⁿ Kombinationen, und man sieht sofort, ob eine fehlt. Die Konsistenz: Zwei Regeln können für dieselben Eingaben keine widersprüchlichen Ergebnisse vorschreiben, ohne dass der Konflikt ins Auge springt. Das macht die Tabelle zum Ergebnis, das man derjenigen Stelle übergibt, die die Entscheidung automatisiert oder prüft: Eine Regel-Engine führt sie unverändert aus, eine Testperson leitet daraus ihre Fälle ab, eine Prüfperson bestätigt, dass keine Situation ohne Antwort bleibt. Bei Regeln in Fliesstext werden diese drei Prüfungen von Hand gemacht und übersehen; bei der Tabelle werden sie durch Lesen gemacht.

Das Ergebnis ist die ausgefüllte Tabelle selbst: die Bedingungen und ihre möglichen Werte, die jeder Kombination zugeordnete Aktion, eine Regel pro Zeile, die deklarierte Hit Policy und die Garantie, dass jede Kombination gültiger Eingaben unter die Zahl von Regeln fällt, die die Policy zulässt. Eine Tabelle ohne deklarierte Hit Policy ist mehrdeutig, sobald zwei Regeln auf dieselbe Eingabe zutreffen können. Eine Tabelle, deren Vollständigkeit man nicht kontrolliert hat, lässt die von ihr nicht vorgesehenen Fälle stillschweigend durch.

Anwendung

Wann einsetzen

• Atomare Entscheidung mit einzigem Ergebnis: ein einziges Ergebnis aus einer festen Menge, gesteuert durch eine beherrschbare Menge von Bedingungen, die sich kombinieren.
• Vollständigkeit oder Konsistenz nachzuweisen: Das 2ⁿ-Raster zeigt, dass kein Fall vergessen oder zweimal behandelt wird, was Regeln in Fliesstext nicht zeigen.
• Regeln, die der Automatisierung zu übergeben sind: Eine Regel-Engine oder eine DMN-Plattform führt die Tabelle ohne Umschreiben aus.
• Flache Bedingungen, die sich frei kombinieren: Die meisten Bedingungen zählen in den meisten Fällen, und die Tabelle bleibt kompakt, wo ein Baum seine Unteräste wiederholen würde.
• Eine regulierte, tarifliche oder weiterleitende Entscheidung, die zu prüfen oder zu testen ist: Das vollständige Raster ist zugleich Testgrundlage und Prüfspur.

Wann nicht einsetzen

• Zahlreiche und stark hierarchische Bedingungen: Wenn eine Bedingung nur auf bestimmten Pfaden zählt, explodiert das 2ⁿ-Raster und liest sich schlecht, besser ein Entscheidungsbaum.
• Nicht atomare Entscheidung, die sich in Teilentscheidungen zerlegt: von anderen Entscheidungen und Wissensquellen gespeist, sie zuerst mit einem Entscheidungsanforderungsdiagramm abbilden und jedes Blatt seine eigene Tabelle sein lassen.
• Verhaltensregeln oder kontextabhängiges Urteil: Eine feste Menge von Bedingungen erzwingt eine falsche Genauigkeit, die Regel in natürlicher Sprache dokumentieren, bei Bedarf über die Geschäftsregelanalyse.

Beschreibung

Anatomie: Bedingungen, Einträge, Aktionen, Regeln

Vier Elemente bilden eine Entscheidungstabelle. Die Bedingungen sind die Eingaben der Entscheidung, jede an ein bestimmtes Datenelement gebunden: der Wohnsitz der antragstellenden Person, das Bestehen eines Vertrags, die Höhe eines Einkommens. Die Bedingungseinträge sind die Werte, die jede Bedingung annehmen kann: zwei boolesche Werte, ja und nein, in einer Tabelle mit begrenzten Einträgen (limited-entry); Werte, Bereiche oder Ausdrücke in einer Tabelle mit erweiterten Einträgen (extended-entry). Die Aktionen, oder Ergebnisse, sind das, was die Entscheidung erzeugt, eine je Regel unter einer Unique-Policy. Die Regeln schliesslich sind der Kern der Tabelle: Jede ist eine vollständige Kombination von Bedingungseinträgen, der eine Aktion zugeordnet ist, und jede belegt eine Zeile. Die Ausrichtung, bei der jede Regel eine Zeile und jede Bedingung eine Spalte ist, ist jene, die die OMG standardmässig wählt; die klassische Ausrichtung, jede Regel eine Spalte, trägt dieselbe Information, und die Wahl zwischen beiden ist eine Frage der Lesbarkeit.

Begrenzte und erweiterte Einträge

Die Unterscheidung zwischen den beiden Formen entscheidet über die Schwierigkeit der Kontrolle. Eine Tabelle mit begrenzten Einträgen trägt nur boolesche Werte und don't-cares, und ihre Vollständigkeit ist eine exakte Rechnung, 2ⁿ. Eine Tabelle mit erweiterten Einträgen trägt Werte und Bereiche, kompakter, aber ihre Vollständigkeit hängt davon ab, wie die Bereiche aneinander anschliessen, und dort nisten sich die Lücken ein. Eine Entscheidung auf binäre Bedingungen zurückzuführen, auch um den Preis, ihre Zahl zu vervielfachen, ist oft das, was die Vollständigkeit auf einen Blick kontrollierbar macht statt durch eine Prüfung der Grenzen.

Die Tabelle aufbauen

1. Die Entscheidung und ihre Menge von Ergebnissen festlegen
   Die Entscheidung als eindeutige Aussage schreiben und die möglichen Aktionen auflisten.
2. Die Bedingungen auflisten und für jede ihre möglichen Werte
   Allein jene, die das Ergebnis kippen lassen.
3. Die Hit Policy wählen und auf die Tabelle schreiben
   Unique standardmässig, solange keine gewollte Überschneidung etwas anderes verlangt.
4. Die Kombinationen aufzählen
   2ⁿ für n binäre Bedingungen, mehr, sobald eine Bedingung mehr als zwei Werte annimmt.
5. Jeder Kombination ein Ergebnis zuweisen
   Hier liest sich die Absicht der Regel, und es ist der einzige Schritt, der Urteil verlangt.
6. Vollständigkeit und Konsistenz prüfen
   Die 2ⁿ Kombinationen sind abgedeckt, kein Widerspruch, keine Überschneidung unter Unique.
7. Die Redundanzen über die don't-cares zusammenfassen
   Ohne eine echte Unterscheidung zu verdecken.

Die Vollständigkeit: die 2ⁿ Kombinationen

Die Vollständigkeit ist die am besten lehrbare Eigenschaft der Technik und die am mechanischsten zu kontrollierende. Jede binäre Bedingung verdoppelt die Zahl der Kombinationen: eine Bedingung ergibt zwei, zwei ergeben vier, und n binäre Bedingungen ergeben 2ⁿ. Eine Tabelle mit begrenzten Einträgen ist vollständig, wenn ihre Regeln, aufgefaltet, diese 2ⁿ Kombinationen abdecken, ohne eine zu vergessen oder doppelt zu zählen. Die Kontrolle ist eine Addition, und eine Addition wird nicht dem Urteil überlassen.

Der Fallstrick verlagert sich auf die Tabellen mit erweiterten Einträgen, wo die Zellen Bereiche statt boolescher Werte tragen. Grenzen, die von einem Bereich zum nächsten verrutschen oder sich überschneiden, hinterlassen stille Lücken. Eine Regel, die „Betrag grösser als ein Schwellenwert“ behandelt, und eine andere „Betrag kleiner oder gleich diesem selben Schwellenwert“ schliessen sauber aneinander an; aber ein Schwellenwert, geschrieben „grösser als 18“ auf einem Betragsband und „grösser als 21“ auf dem Nachbarband, lässt einen ganzen Bereich ohne Regel, und die Entscheidung scheitert, ohne dass es jemand gewollt hätte. Es ist ein Grenzfehler, „grösser als“ gesetzt für „grösser oder gleich“, oder ein Schwellenwert, der sich von Band zu Band verschiebt, und es ist die häufigste Art, wie eine Tabelle, die vollständig scheint, es nicht ist.

Die Konsistenz und das Zusammenfassen über die don't-cares

Die Konsistenz verlangt, dass zwei Regeln für dieselben Eingaben nie widersprüchliche Ergebnisse vorschreiben. Unter einer Unique-Policy ist jede Überschneidung ein Konstruktionsfehler, da die Policy verspricht, dass höchstens eine Regel zutrifft.

Eine vollständige Tabelle von 2ⁿ Regeln ist meist redundant, weil das Ergebnis nicht immer von allen Bedingungen abhängt. Wo das Ergebnis gleich ist, welchen Wert eine Bedingung auch annimmt, ersetzt man diese Zelle durch einen don't-care, mit einem Bindestrich markiert, und fasst die Zeilen zusammen, die dieser Wert unterschied. Eine vollständige Tabelle von acht Zeilen fasst sich gewöhnlich auf drei oder vier zusammen. Das Zusammenfassen verliert keine Abdeckung, solange der Bindestrich ehrlich ist. Dort liegt der Fallstrick: ein zu schnell gesetzter Bindestrich verdeckt eine echte Unterscheidung und lässt die Tabelle für die Hälfte der Fälle, die er abdeckt, etwas Falsches sagen. Einen Bindestrich setzt man nur dort, wo das Ergebnis für jeden Wert der Bedingung dasselbe bleibt, und die Kontrolle besteht darin, den Bindestrich gedanklich aufzufalten und zu prüfen, dass das Ergebnis für jeden dieser Werte hält.

Die Hit Policies

Wenn mehrere Regeln auf dieselbe Eingabe zutreffen können, muss man sagen, welche den Vorrang hat, und das ist die Aufgabe der Hit Policy, die die OMG als Buchstaben in die linke obere Ecke der Tabelle setzt. Die Policy Unique (U) ist die erste, die man lehrt: Höchstens eine Regel trifft auf jede Eingabe zu, und jede Überschneidung ist ein Fehler. Sie macht die Tabelle überprüfbar, weil sie die Mehrdeutigkeit verbietet.

Die anderen Policies dienen Tabellen, in denen die Überschneidung gewollt ist. Any (A): mehrere Regeln treffen zu, geben aber alle dasselbe Ergebnis. Priority (P): mehrere treffen mit unterschiedlichen Ergebnissen zu, und das Ergebnis, das in einer deklarierten Prioritätsordnung am höchsten steht, gewinnt. First (F): die erste Regel, die in der Zeilenreihenfolge zutrifft, gewinnt, wobei die Lesereihenfolge dann Bedeutung trägt. Collect (C): die Tabelle gibt alle zutreffenden Ergebnisse zurück, gegebenenfalls aggregiert durch eine Summe, ein Minimum, ein Maximum oder eine Anzahl. Eine Tabelle, die keine Policy deklariert, ist mehrdeutig, sobald zwei Regeln zutreffen können, und die lesende Person weiss nicht, ob die Auslassung ein Fehler oder eine Wahl ist.

Tabelle, Baum und Anforderungsdiagramm

Drei Techniken der Entscheidungsmodellierung ähneln einander so sehr, dass man sie verwechselt, und die Grenze entscheidet über die richtige Wahl. Man nimmt eine Tabelle, wenn die Entscheidung atomar ist und man Vollständigkeit und Konsistenz auf einen Blick überprüfbar haben will: Das 2ⁿ-Raster ist vollständig und wird durch eine Addition kontrolliert. Man nimmt einen Entscheidungsbaum, wenn die Bedingungen hierarchisch sind und ausdünnen, wenn eine Bedingung nicht auf allen Pfaden zählt, wie bei einer Segmentierung: Eine flache Tabelle würde dort ganze Unteräste wiederholen. Man nimmt ein Entscheidungsanforderungsdiagramm, wenn die Entscheidung nicht atomar ist: Sie zerlegt sich in ein Netz von Teilentscheidungen, Eingabedaten und Wissensquellen, und jede Blatt-Teilentscheidung ist selbst eine Tabelle oder ein Baum. Tabelle und Baum sind zwei Notationen ein und derselben atomaren Entscheidung; das Anforderungsdiagramm ist die Ebene darüber, die mehrere davon organisiert.

Was die Tabelle scheitern lässt

Ein Grenzfehler

„Grösser als“ geschrieben für „grösser oder gleich“, oder ein Schwellenwert, der von einem Band zum nächsten verrutscht, lässt eine Eingabe in keiner Regel oder in zweien.

Ein zu schnell gesetzter don't-care

Ein Bindestrich, der eine echte Unterscheidung verdeckt, lässt die Tabelle für die Hälfte der Fälle, die er abdeckt, etwas Falsches sagen.

Eine nicht deklarierte Hit Policy

Die Tabelle bleibt stumm darüber, was geschieht, wenn zwei Regeln zutreffen, und jede lesende Person nimmt ihre eigene an.

Bedingungen, die nicht unabhängig sind

Zwei Bedingungen, die eine Einschränkung verbindet, wobei die eine die andere impliziert, erzeugen unmögliche Kombinationen, die man ausfüllen zu müssen glaubt, obwohl es sie nicht gibt.

Eine Verhaltensregel, in eine definitorische Tabelle geschoben

Eine Urteilsregel in ein Raster zu zwingen, gibt ihr eine falsche Genauigkeit, die sie nicht hat.

Eine Tabelle, die mit der von ihr kodierten Vorgabe aus dem Takt geraten ist

Eine Regel ändert sich in der Verordnung und nicht in der Tabelle, und die Tabelle lügt stillschweigend bis zum nächsten Audit.

KI-Betrachtungen

Der erste nützliche Einsatz ist das Verfassen eines ersten Entwurfs von Regeln aus einem Vorgaben- oder Verordnungstext. Ein Sprachmodell, dem man eine Richtlinie in Fliesstext gibt, zieht daraus eine Liste von Kandidatenbedingungen und Regelzeilen, was die mühsame Hälfte der Vorbereitung ist. Der zweite Einsatz ist eine Kontrolle, noch bevor die Tabelle existiert: dem Modell eine in natürlicher Sprache geschriebene Regelmenge geben und es bitten, die nicht abgedeckten Kombinationen und die scheinbaren Widersprüche zu melden. Der dritte verlängert das Zusammenfassen: die Regeln aufspüren, in denen eine Bedingung das Ergebnis nicht ändert, also die Kandidaten-don't-cares und die redundanten Zeilen.

Was die KI nicht kann, liegt in der Natur der Aufgabe. Die Vollständigkeit des Rasters ist mechanisch, 2ⁿ ist eine Rechnung; die Richtigkeit der Regeln gegenüber der Wirklichkeit ist menschlich. Ein Modell weiss nicht, ob eine Regel der Absicht der Vorgabe oder des Gesetzestextes treu ist, den sie kodiert. Es weiss auch nicht, wie es eine Grenze wählen soll: „grösser als“ oder „grösser oder gleich“ für einen Einkommensschwellenwert zu schreiben, ist eine fachliche Entscheidung, oft in einer Verordnung festgehalten. Und es weiss nicht, welche Folge es an jedes Ergebnis knüpfen soll, was der Kern der Entscheidung ist. Die KI zeichnet die Tabelle; die analysierende Person verantwortet ihre Richtigkeit.

Der Datenschutz schliesst das Thema, sobald die Tabelle Personen betrifft. Eine mit realen Fällen gefüllte Anspruchstabelle enthält Personendaten im Sinne des revidierten Datenschutzgesetzes (revDSG), Einkommen, Situationen, Status. Sie wird nicht in ein öffentliches Modell eingefügt, und die Unterstützung erfolgt auf einem Werkzeug, dessen Datenbearbeitung beherrscht ist, oder auf einer Tabelle, deren sensible Werte durch Bedingungssymbole ersetzt wurden.

Beispiele

Eine Entscheidung über den Anspruch auf eine kantonale Berufsbildungsbeihilfe wird auf drei binären Bedingungen getroffen: die antragstellende Person hat Wohnsitz im Kanton, ein Lehrvertrag ist unterzeichnet, das Haushaltseinkommen liegt unter der Obergrenze, auf CHF 60'000 festgelegt. Die Beihilfe wird nur gewährt, wenn alle drei erfüllt sind. Zwei Eigenschaften machen die Technik aus. Die Vollständigkeit: drei binäre Bedingungen ergeben 2³ = 8 Kombinationen, alle abgedeckt. Das Zusammenfassen über die don't-cares: Die vollständige Tabelle von acht Zeilen liest sich in vieren, denn sobald eine Bedingung genügt, um die Beihilfe abzulehnen, zählen die folgenden nicht mehr. Regel 1 lehnt jede antragstellende Person ohne Wohnsitz ab, unabhängig von Vertrag und Einkommen, was ihre zwei Bindestriche sagen, und diese eine Zeile deckt 1 × 2 × 2 = 4 der acht Kombinationen ab. Regel 2 deckt 2 ab, die Regeln 3 und 4 je eine, also 4 + 2 + 1 + 1 = 8: das Zusammenfassen hat nichts verloren. Die Hit Policy ist Unique, mit U in der linken oberen Ecke markiert, und man prüft, dass sie hält, wobei die vier Regeln sich paarweise ausschliessen, sodass jede Eingabe unter genau eine Regel fällt. Die Reihenfolge der Zeilen hat keine Bedeutung für das Ergebnis, weil die Regeln sich nicht überschneiden; das wäre falsch unter einer First-Policy, wo die Tabelle die erste erfüllte Zeile zurückgäbe und wo die Reihenfolge Bedeutung trüge.

Visualisierungen

Das Ergebnis der Technik ist eine Tabelle. Die von der Ergebnisspalte getrennten Bedingungsspalten zeigen die Bedingung-Aktion-Struktur auf einen Blick. Die in einer Spalte ausgerichteten Bindestriche machen das Zusammenfassen sichtbar: Man sieht, welche Bedingungen aufhören zu zählen und wo. Die Policy-Marke in der linken oberen Ecke sagt, wie eine mögliche Überschneidung zu lesen ist, eine Information, ohne die die Tabelle mehrdeutig wäre.

Die zusammengefasste Form ist jene, die man zeigt, weil sie jene ist, die man liest. Die vollständige Form von 2ⁿ Zeilen besteht nur für die Dauer der Kontrolle: Sie beweist, dass nichts vergessen ist, und die zusammengefasste Form dient dann dazu, schnell zu entscheiden.

Aufwand

Werkzeuge

Die Tabellenkalkulation (Excel, Google Sheets) ist das Werkzeug des Alltags. Eine Zeile je Kombination ergibt die Vollständigkeit von der Konstruktion her, eine Spalte je Bedingung hält die Struktur, und eine Formel kontrolliert die Grenzen oder zählt die Zeilen. In ihr denkt man die Tabelle; der Sinn der Regeln bleibt Sache der analysierenden Person.

Die DMN-Modellierungswerkzeuge (Camunda Modeler, Trisotech, SAP Signavio, Sparx EA, Drools und seine KIE-Suite) sind die Stufe darüber. Sie kennen die Hit Policies, melden die nicht abgedeckten Kombinationen sowie die Überschneidungen und erzeugen eine ausführbare Tabelle statt eines blossen Dokuments. Dort validiert und führt man eine Tabelle aus, die für die Automatisierung bestimmt ist.

Die Regel-Engines und Systeme zur Verwaltung von Geschäftsregeln (BRMS) führen die Tabelle in Echtzeit aus, auf den Produktionsdaten, sobald sie validiert wurde. Die Tabelle hört dann auf, ein Analyseergebnis zu sein, und wird zu einer Komponente des Systems.

Das Whiteboard bleibt das Werkzeug der anfänglichen Erhebung, solange die Bedingungen und ihre Werte noch diskutiert werden. Die praktische Regel fasst sich in einem Satz: die Tabellenkalkulation zum Denken, das DMN-Werkzeug zum Validieren und Ausführen.

Quellen

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.17 Decision Modelling: die Definition der Entscheidungstabelle, ihre Anatomie aus Bedingungen und Aktionen, der Gebrauch der leeren oder don't-care-Zellen und die Stärken und Grenzen der Entscheidungsmodellierung.
• Object Management Group, Decision Model and Notation (DMN), Clause 8 (Decision Table): die normierte Notation, die Standardausrichtung, bei der jede Regel eine Zeile ist, die Policy-Marke in der linken oberen Ecke und die Hit Policies Unique, Any, Priority, First und Collect.
• ISTQB, Certified Tester Foundation Level Syllabus, Decision Table Testing: die Vollständigkeit, die Konsistenz und die Beseitigung der Redundanzen als Disziplin des Testentwurfs, darunter die Ableitung der Testfälle aus den Kombinationen von Bedingungen.