Den Prozesskontextgraphen erhalten

Der Prozesskontextgraph ist ein JSON-Dokument, das beschreibt, wie Ihr Prozess tatsächlich abläuft. Er wird aus dem Ereignisprotokoll Ihres Projekts erstellt: was ein Fall ist, wie Fälle starten und enden, die Schritte und Übergaben dazwischen, die Pfade, die Fälle nehmen, die Stellen, an denen sie sich verzweigen, und die Regeln, die die Verzweigung erklären, was schief geht, wie lange Dinge dauern und wer was tut. Jeder Teil gibt an, auf wie vielen Daten er basiert.

„Prozesskontextgraph“ ist ein Begriff, den der Markt ohne Standard verwendet. So versteht mindzie ihn: ein von uns definierter Standard, hergestellt aus Dingen, die das Projekt schon beantworten kann, in einem Dokument mit festgelegter Form, damit ein Agent es laden und eine Person überprüfen kann. Das Projekt kann weit mehr beantworten, als der Graph enthält; Ihre eigenen Berichte und JSON behandelt das.

Zwei Arten von Agenten arbeiten mit dem Graphen. Der Agent im Inneren – der mindzie-Agent, der im Projekt läuft – baut ihn auf, wenn der Bericht Prozesskontextgraph ausgeführt wird. Ein Agent von außen – Ihr eigener programmierter Agent, der von Ihrem Rechner aus arbeitet – fragt das Projekt in einem einzigen Aufruf danach ab. Verbinden Sie Ihren eigenen Agenten führt Sie von Grund auf durch den Prozess mit dem Bild, wie die beiden zusammenpassen.

Wozu er dient

  • Ein Agent lädt ihn, bevor er an Ihrem Prozess arbeitet, damit er die echten Schrittbezeichnungen, den normalen Pfad, die Entscheidungspunkte und Ausnahmen kennt, ohne sie eine nach der anderen entdecken zu müssen.
  • Eine Person überprüft ihn. Der gleiche Inhalt wird als Bericht auf dem Berichtsbildschirm ausgegeben, mit einer Prozesskarte, einer Entscheidungstabelle für jede erklärte Entscheidung und dem Beleg neben jeder Aussage. Die Tabellen des Berichts und das JSON werden aus denselben Daten geschrieben, sodass beide keine widersprüchlichen Aussagen machen können.

Er ist eine Beschreibung und nur eine Beschreibung. Er empfiehlt nichts, und er sagt nicht, was jemand tun darf.

Holen Sie ihn in zwei Schritten

Schritt 1 – Führen Sie den Bericht Prozesskontextgraph einmal aus

Am Bildschirm: Öffnen Sie den Berichte-Bildschirm Ihres Projekts, klicken Sie auf Bericht erstellen auf der Karte Prozesskontextgraph und dann auf Starten. Siehe Berichte.

Von Ihrem eigenen Agenten: mit gestartetem Projekt und geladenen Daten findet der Agent die Karte und startet sie:

mz reports cards
mz jobs create-agent --card process-context-graph
mz jobs run --slug process-context-graph
mz jobs status --slug process-context-graph

mz jobs create-agent --card gibt den Job-Slug zurück, den die nächsten zwei Befehle verwenden; auf einem Projekt, in dem die Karte noch nie ausgeführt wurde, ist das process-context-graph. Der Lauf ist ein KI-Job: Er verbraucht Ihre KI-Credits des Projekts. Nach dem Ende veröffentlicht sich der Bericht selbst auf dem Berichtsbildschirm wie jeder andere.

Rechnen Sie mit Wartezeit. Bei einem Protokoll mit 1,6 Millionen Ereignissen und etwa 250.000 Fällen dauerte der Lauf 45 Minuten, planen Sie also bis zu einer Stunde für ein Protokoll dieser Größe ein. mz jobs status zeigt running bis zu dem Moment, an dem es done meldet; dazwischen gibt es keinen Fortschritt. Jobs im Projekt laufen nacheinander, alles weitere wartet darauf.

Eine erneute Ausführung später veröffentlicht die nächste Version desselben Berichts. Die frühere Version und ihr JSON bleiben genau wie zuvor.

Schritt 2 – Rufen Sie den Graphen in einem Aufruf ab

mz reports context-graph > process-context-graph.json

Das schreibt den aktuellen Prozesskontextgraphen des Projekts als JSON in die Datei: das neueste veröffentlichte Dokument mit der Form mindzie.process-context-graph. Es wird nichts erneut berechnet und keine KI genutzt – der Aufruf liest den Bericht, der bereits veröffentlicht ist. Dasselbe Dokument ist die Datei process-context-graph.json, die der Bericht der Karte trägt, sodass mz reports attachment --slug process-context-graph --name process-context-graph.json genau dieselben Bytes zurückgibt.

Wenn der Bericht in diesem Projekt noch nie ausgeführt wurde, lehnt der Aufruf ab und nennt die Befehle, die einen Bericht erzeugen (Schritt 1). Es startet nie selbstständig den Lauf, da sonst Ihre KI-Credits unaufgefordert verbraucht würden.

Unter Windows führen Sie das im Eingabeaufforderungsfenster aus: Windows PowerShell kodiert Text, der mit > in eine Datei geschrieben wird, neu. Um die Datei mit der Definition zu prüfen, siehe Prüfen Sie einen Graphen selbst weiter unten. Wie Ihr Agent mz und seinen Schlüssel erhält, steht unter Verbinden Sie Ihren eigenen Agenten.

Wie ein echter aussieht

Der untenstehende Graph wurde von der Karte Prozesskontextgraph aus einem realen Purchase-to-Pay-Protokoll erzeugt: 1.593.532 Ereignisse in 251.658 Fällen, ein Fall pro Bestellungsposten. Sein JSON ist etwa 300 KB groß und enthält 44 Schritte, 188 Übergaben, 16 Varianten, 25 Entscheidungspunkte, 48 Reihenfolgeregeln, 48 Ausnahmen, 4 Eskalationen, 25 Regelwerke, 20 Annahmen und 7 offene Fragen. Er besteht die Definition am Ende dieser Seite.

Als Bild gezeichnet

Der Hauptfluss eines echten Prozesskontextgraphen, aus dessen JSON gezeichnet

Dieses Bild wurde direkt aus dem JSON von einem kurzen Skript gezeichnet, um zu zeigen, was darin enthalten ist. Es zeigt die Schritte und die verkehrsreichsten Übergaben – jeweils von mindestens 4 Prozent der Fälle genommen – in den eigenen Phasen des Graphen, mit der Anzahl der Fälle pro Übergabe sowie der typischen Wartezeit. Dicke Linien sind der Hauptfluss, gestrichelte andere Pfade und rote gestrichelte Linien markieren die im Graphen als Ausnahmen gekennzeichneten. Daraus ist abzulesen: 72 Prozent der Positionen enden mit Rechnung begleichen, und die längste typische Wartezeit liegt zwischen Rechnungseingang und Begleichung davon, 36 Tage.

Das JSON, verkürzt

Wie der Agent es empfing, mit meist nur einem Eintrag pro Liste und 14 von 22 Teilen weggelassen, wie die letzte Zeile angibt. Jede Aussage trägt ihren Beleg: wie viele Fälle von wie vielen, wie gemessen und wie stark.

{
  "schema": "mindzie.process-context-graph",
  "schema_version": "1.0",
  "source": {
    "data_version": "v0001",
    "log_digest": "4804d5916fc0",
    "case_notion": "ein Bestellungsposten (Bestellnummer plus Postennummer)",
    "cases": 251658,
    "events": 1593532,
    "period_start": "2015-03-08",
    "period_end": "2020-04-09",
    "time_basis": "clock"
  },
  "success_criteria": [
    {
      "id": "sc:cleared",
      "statement": "Der Posten ist bezahlt: Der Fall endet mit Rechnung begleichen.",
      "test": "letztes Ereignis des Falls ist Rechnung begleichen",
      "share_met": 0.7203,
      "evidence": {
        "cases": 181257,
        "of_cases": 251658,
        "share": 0.7203,
        "strength": "counted",
        "method": "direkte Zählung der Fälle, deren letztes Ereignis Rechnung begleichen ist"
      }
    }
  ],
  "outcomes": [
    {
      "id": "out:clear-invoice",
      "end_activity": "Rechnung begleichen",
      "kind": "success",
      "cases": 181257,
      "share": 0.7203
    },
    {
      "id": "out:record-invoice-receipt",
      "end_activity": "Rechnungseingang erfassen",
      "kind": "open",
      "cases": 23089,
      "share": 0.0917
    }
  ],
  "edges": [
    {
      "id": "edge:record-invoice-receipt>clear-invoice",
      "from": "act:record-invoice-receipt",
      "to": "act:clear-invoice",
      "kind": "normal",
      "cases": 132667,
      "share_of_from": 0.6575,
      "median_wait_hours": 865.617,
      "slow_wait_hours": 2479.663,
      "evidence": {
        "cases": 132667,
        "of_cases": 211303,
        "share": 0.6279,
        "strength": "counted",
        "method": "Fälle mit dieser Übergabe mindestens einmal, von Fällen mit dem ersten Schritt; Anteile des ersten Schritts zählen jeden Besuch"
      }
    }
  ],
  "decisions": [
    {
      "id": "dec:block-purchase-order-item",
      "at": "act:block-purchase-order-item",
      "branches": [
        {
          "to": "end",
          "cases": 163,
          "share": 0.3417
        },
        {
          "to": "act:delete-purchase-order-item",
          "cases": 131,
          "share": 0.2746
        },
        {
          "to": "act:reactivate-purchase-order-item",
          "cases": 111,
          "share": 0.2327
        },
        {
          "to": "act:change-quantity",
          "cases": 72,
          "share": 0.1509
        }
      ],
      "baseline_share": 0.3417,
      "rules": [
        {
          "id": "rule:block-purchase-order-item-1",
          "when": [
            "Ausgabenkategorie ist nicht Handel & Endprodukte",
            "Bestellwert (EUR) liegt über 502,5 und bis 2884,5"
          ],
          "then": "act:delete-purchase-order-item",
          "cases": 113,
          "holds": 0.708,
          "evidence": {
            "cases": 80,
            "of_cases": 113,
            "share": 0.708,
            "strength": "weak",
            "method": "Regel gefunden mit einem Entscheidungsbaum auf den hier gezählten Übergaben; Anteil zeigt, wie oft der nächste Schritt passte"
          }
        }
      ],
      "explained": true,
      "evidence": {
        "cases": 477,
        "of_cases": 499,
        "share": 0.6688,
        "strength": "weak",
        "method": "Erster Besuch des Schritts in jedem Fall; Regeln erreichen 67% gegen 34% vom häufigsten nächsten Schritt raten; erklärt braucht mindestens 10 Punkte Unterschied"
      }
    }
  ],
  "policies": [
    {
      "id": "pol:create-purchase-order-item-record-goods-receipt-within-30-days",
      "kind": "service_level",
      "statement": "Möglicher Service-Level, abgeleitet: Bestellungsposten erstellen -> Wareneingang erfassen innerhalb von 30 Tagen (88% von 74.809 Fällen beenden diesen Schritt; 8,1% innerhalb des letzten Viertels der Grenze, 4,0% knapp darüber)",
      "threshold_hours": 720.0,
      "share_met": 0.8839,
      "evidence": {
        "cases": 66126,
        "of_cases": 74809,
        "share": 0.8839,
        "strength": "hypothesis",
        "method": "Anteil positiver Wartezeiten, die unter der Grenze liegen; Grenze zählt, wenn mindestens die Hälfte der Wartezeiten sie einhalten und doppelt so viele in das letzte Viertel der Grenze fallen als knapp darüber"
      }
    }
  ],
  "...": "und 14 weitere Teile"
}

Die Teile

Teil Was er enthält
source Welche Daten der Graph verwendet: Datenversion, gelesenes Protokoll, was ein Fall ist, Fälle, Ereignisse, Zeitraum, Arbeits- oder Echtzeit
process Was ein Fall darstellt und wofür der Prozess zu sein scheint
success_criteria Wie ein erfolgreicher Fall erkannt wird und welcher Anteil der Fälle jeden Test besteht
outcomes Alle möglichen Enden eines Falls mit Anzahl und Anteil der Fälle
stages Die Phasen, durch die ein Fall läuft, und die Aktivitäten in jeder Phase
nodes Ein Eintrag pro Aktivität plus Start und Ende: Fälle, Ereignisse, Wiederholungen, typische Zeit zum nächsten Schritt, Rollen
edges Ein Eintrag pro Übergabe: Fälle, Anteil, typische Wartezeit und Wartezeit der langsamsten Fälle
variants Der Hauptpfad, zulässige Abweichungen und Ausnahmepfade mit mindestens einem Fall pro hundert
model Ein Prozessmodell aus den Pfaden entdeckt und der Anteil der Fälle, die es akzeptiert
decisions Jeder Punkt, an dem sich Fälle verzweigen: Äste und die wenn-dann-Regeln, die die Verzwei-fung erklären, falls vorhanden
sequence_rules Reihenfolgeregeln, die fast immer gelten, mit dem Anteil der Fälle, in denen sie gelten
exceptions Wiederholte, übersprungene und außerhalb der Reihenfolge auftretende Schritte, seltene Aktivitäten und gescheiterte Enden
escalations Schritte, die hauptsächlich nach langer Wartezeit oder einem fehlgeschlagenen Versuch auftreten
policies Zeitlimits, die die meisten Fälle einhalten, und der Anteil, der jedes einhält
roles Welche Rollen welche Aktivitäten ausführen, falls das Protokoll aufzeichnet, wer gearbeitet hat
object_types, object_relations Welche Arten von Objekten es gibt und wie sie zusammenhängen, für ein objektzentriertes Protokoll
evidence_levels Die fünf Stärkebewertungen, jeweils einmal definiert
assumptions, open_questions Was vor Beginn der Arbeit entschieden wurde, was nicht messbar war und was ein Leser überprüfen sollte

Anzahlen sind ganze Zahlen, Anteile Bruchteile von 0 bis 1, Zeiten in Stunden. Jeder Teil ist in jedem Graphen vorhanden; eine Liste ohne Inhalte ist leer statt nicht vorhanden, und kein Wert ist jemals null.

Manche Teile werden durch Code gezählt – ein zweiter Lauf mit denselben Daten ergibt dieselbe Zahl. Andere sind eine Auswertung der Daten: was ein Fall repräsentiert, welche Enden als Erfolg zählen, wo die Phasen sind. Der Bericht sagt, welcher Teil welches ist.

Wie weit man jedem Teil vertrauen kann

Jeder Teil, der eine Aussage trifft, trägt genau ein evidence-Objekt – wie viele Fälle ihn stützen, wie viele er anwenden könnte, der Anteil der Fälle, bei denen er gilt, wie gemessen – und ein Stärkelabel:

Label Bedeutung
counted Direkte Zählung aus dem Protokoll
strong Gilt in mindestens 95 Prozent der Fälle, die es betrifft und basiert auf mindestens 100 Fällen
moderate Gilt in mindestens 80 Prozent und basiert auf mindestens 30 Fällen
weak Alles darunter
hypothesis Abgeleitet aus Aktivitätsnamen oder Zeit, nicht als Regel getestet

Lesen Sie zuerst die Stärke: counted ist eine Tatsache aus dem Protokoll; hypothesis ist eine Idee, die sich lohnt zu überprüfen.

Die vollständige Definition

Die Form ist festgelegt und versioniert. Dies ist Version 1.0, und ein Dokument, das einmal besteht, besteht für immer; jede Änderung der Felder ist eine neue Version mit einer eigenen Schema-Datei.

mindzie.process-context-graph-1.0.schema.json herunterladen

Die Schema-Datei enthält die gesamte Form als JSON Schema (Entwurf-07), das jeder Validator lesen kann. Jeder Graph wird beim Veröffentlichen seines Berichts damit geprüft: Ein Bericht, dessen Graph die Form nicht hat, wird nicht veröffentlicht; die Begründung nennt den Teil und beschreibt das Problem.

Prüfen Sie einen Graphen selbst

Legen Sie die Schema-Datei neben den Graphen und prüfen Sie ihn mit jedem JSON Schema Validator. In Python speichern Sie dazu das Folgende als check_graph.py:

import json

import jsonschema

with open("process-context-graph.json", encoding="utf-8") as file:
    graph = json.load(file)
with open("mindzie.process-context-graph-1.0.schema.json", encoding="utf-8") as file:
    schema = json.load(file)

jsonschema.validate(graph, schema)
print("valid")

und führen es aus:

pip install jsonschema
python check_graph.py

Es gibt valid aus oder stoppt mit dem Teil, der nicht der Form entspricht. Da das Projekt jeden Graphen beim Veröffentlichen prüft, besteht ein veröffentlichter Graph immer die Prüfung.

Weiter