Het verkrijgen van de Process Context Graph

De process context graph is één JSON-document dat beschrijft hoe jouw proces daadwerkelijk verloopt, opgebouwd uit het event log van je project: wat een case is, hoe cases starten en eindigen, de stappen en de overdrachten daartussen, de paden die cases volgen, de punten waar ze splitsen en de regels die de splitsing verklaren, wat er misgaat, hoe lang dingen duren en wie wat doet. Elk onderdeel geeft aan op hoeveel data het is gebaseerd.

"Process context graph" is een naam die in de markt wordt gebruikt zonder standaard erachter. Dit is wat mindzie ermee bedoelt: een standaard die wij definiëren, gemaakt van dingen die het project al kan beantwoorden, samengevoegd in één document met een vaste vorm zodat een agent het kan laden en een persoon het kan controleren. Het project kan veel meer beantwoorden dan de graph bevat; Je Eigen Rapporten en JSON gaat daarover.

Twee soorten agents ontmoeten elkaar via de graph. De agent binnenin — de mindzie-agent die in het project draait — bouwt het, wanneer het Process Context Graph-rapport wordt uitgevoerd. Een agent van buitenaf — jouw eigen programmeer-agent, werkend vanaf jouw machine — vraagt het project erom in één oproep. Koppel Je Eigen Agent begeleidt je van niets naar hoe de twee samenwerken.

Waar het voor is

  • Een agent laadt het voordat hij aan jouw proces werkt, zodat hij de echte stapnamen, het normale pad, de beslispunten en de uitzonderingen kent, zonder ze stap voor stap te hoeven ontdekken.
  • Een persoon controleert het. Dezelfde inhoud wordt uitgewerkt als een rapport op het Rapportenscherm, met een proceskaart, een beslissingsmatrix voor elk verklaard besluit, en het bewijs naast elke bewering. De tabelletjes in het rapport en de JSON zijn uit dezelfde data geschreven, zodat ze niet iets anders kunnen zeggen.

Het is een beschrijving en alleen een beschrijving. Het doet geen aanbevelingen en zegt niet wat iemand mag doen.

Het in twee stappen verkrijgen

Stap 1 – Voer het Process Context Graph-rapport één keer uit

Op het scherm: open het project en ga naar het Rapporten-scherm, klik op Rapport aanmaken op de kaart Process Context Graph, en klik vervolgens op Start. Zie Rapporten.

Vanuit je eigen agent: met het project gestart en je data geladen, vindt de agent de kaart en start het:

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 geeft de slug van de job terug, die de volgende twee commando's gebruiken; in een project waar de kaart nog nooit is uitgevoerd is dat process-context-graph. De uitvoering is een AI-taak: hij gebruikt jouw AI-tegoed. Wanneer het klaar is, publiceert het rapport zichzelf op het Rapportenscherm zoals elk ander rapport.

Verwacht wachttijd. Op een log met 1,6 miljoen events en ongeveer 250.000 cases duurde de uitvoering 45 minuten, dus plan tot een uur wanneer je log die omvang heeft. mz jobs status toont running tot het moment dat het done zegt; er is geen tussentijdse voortgang. Jobs in een project draaien één voor één, dus wat er ondertussen wordt gestart, wacht op de afgeronde job.

Het opnieuw draaien publiceert de volgende versie van hetzelfde rapport. De eerdere versie en de JSON blijven precies zoals ze waren.

Stap 2 – Haal de graph op in één oproep

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

Dit schrijft de huidige process context graph van het project als JSON naar het bestand: het nieuwste gepubliceerde document dat de vorm mindzie.process-context-graph noemt. Er wordt niets opnieuw berekend en er wordt geen AI gebruikt – de oproep leest het rapport dat al gepubliceerd is. Ditzelfde document is het bestand process-context-graph.json dat de kaart in het rapport bevat, dus mz reports attachment --slug process-context-graph --name process-context-graph.json geeft exact dezelfde bytes terug.

Als het rapport nooit in dit project is uitgevoerd, weigert de oproep en noemt het de commando's die er één maken (Stap 1). Het start nooit zelfstandig het rapport, want dat zou je AI-tegoed uitgeven zonder dat daar om gevraagd is.

Op Windows voer je dat uit in Command Prompt: Windows PowerShell codeert tekst anders bij gebruik van >. Om het bestand tegen de definitie te controleren, zie Controleer zelf een graph, hieronder. Hoe jouw agent mz en je sleutel krijgt, staat op Koppel Je Eigen Agent.

Hoe een echte eruitziet

De onderstaande graph is gemaakt door de Process Context Graph-kaart op een echte purchase-to-pay log: 1.593.532 events in 251.658 cases, één case per regel in de inkooporder. De JSON is ongeveer 300 KB groot en bevat 44 stappen, 188 overdrachten, 16 varianten, 25 beslispunten, 48 volgregels, 48 uitzonderingen, 4 escalaties, 25 beleidsregels, 20 aannames en 7 open vragen. Hij voldoet aan de definitie aan het einde van deze pagina.

Afgebeeld als afbeelding

De hoofdflow van een echte process context graph, getekend vanuit de JSON

Deze afbeelding is rechtstreeks uit de JSON getekend, met een kort script, om te laten zien wat erin zit. Het toont de stappen en de drukste overdrachten – elk door minimaal 4 procent van de cases genomen – binnen de eigen fases van de graph, met hoeveel cases elk pad volgen en de typische wachttijd. Dikke lijnen zijn de hoofdflow, stippellijnen andere paden, en rode stippellijnen wat de graph aanduidt als uitzonderingen. Lees eruit af: 72 procent van de items eindigt met Clear Invoice, en de langste typische wachttijd is van ontvangst factuur tot het afboeken ervan, 36 dagen.

De JSON, ingekort

Zoals de agent het ontving, met de meeste lijsten teruggebracht tot één item en 14 van de 22 delen weggelaten, zoals de laatste regel zegt. Elke bewering draagt zijn bewijs: hoeveel cases, van hoeveel, hoe gemeten en hoe sterk het is.

{
  "schema": "mindzie.process-context-graph",
  "schema_version": "1.0",
  "source": {
    "data_version": "v0001",
    "log_digest": "4804d5916fc0",
    "case_notion": "één inkooporderregel (inkoopordernummer plus itemnummer)",
    "cases": 251658,
    "events": 1593532,
    "period_start": "2015-03-08",
    "period_end": "2020-04-09",
    "time_basis": "clock"
  },
  "success_criteria": [
    {
      "id": "sc:cleared",
      "statement": "Het item is betaald: de case eindigt met Clear Invoice.",
      "test": "laatste event van de case is Clear Invoice",
      "share_met": 0.7203,
      "evidence": {
        "cases": 181257,
        "of_cases": 251658,
        "share": 0.7203,
        "strength": "counted",
        "method": "directe telling van cases die als laatste event Clear Invoice hebben"
      }
    }
  ],
  "outcomes": [
    {
      "id": "out:clear-invoice",
      "end_activity": "Clear Invoice",
      "kind": "success",
      "cases": 181257,
      "share": 0.7203
    },
    {
      "id": "out:record-invoice-receipt",
      "end_activity": "Record Invoice Receipt",
      "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": "cases met deze overdracht minstens één keer, van cases met de eerste stap; shares van de eerste stap tellen elk bezoek mee"
      }
    }
  ],
  "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": [
            "Spend area is niet Trading & End Products",
            "Orderwaarde (EUR) ligt tussen 502,5 en 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 opgezet door een besluitboom op de overdrachten hier; share geeft aan hoe vaak de volgende stap overeenkwam"
          }
        }
      ],
      "explained": true,
      "evidence": {
        "cases": 477,
        "of_cases": 499,
        "share": 0.6688,
        "strength": "weak",
        "method": "eerste bezoek van de stap per case; regels scoren 67% tegenover 34% van de meest voorkomende volgende stap gokken; verklaard vraagt minstens 10 punten meer"
      }
    }
  ],
  "policies": [
    {
      "id": "pol:create-purchase-order-item-record-goods-receipt-within-30-days",
      "kind": "service_level",
      "statement": "Mogelijk serviceniveau, afgeleid: Create Purchase Order Item -> Record Goods Receipt binnen 30 dagen (88% van 74.809 cases eindigt binnen deze termijn; 8,1% eindigt in het kwartaal net binnen de limiet, 4,0% net erbuiten)",
      "threshold_hours": 720.0,
      "share_met": 0.8839,
      "evidence": {
        "cases": 66126,
        "of_cases": 74809,
        "share": 0.8839,
        "strength": "hypothesis",
        "method": "aandeel positieve wachttijden binnen of onder de limiet; een limiet telt als minstens de helft van de wachttijden eraan voldoet en er tweemaal zoveel in het kwartaal net binnen de limiet vallen als net erbuiten"
      }
    }
  ],
  "...": "en nog 14 delen meer"
}

De onderdelen

Onderdeel Wat het bevat
source Van welke data de graph is opgebouwd: de dataversie, welke log gelezen is, wat een case is, het aantal cases, events en periode, werk- of kloktijd
process Wat één case vertegenwoordigt en waar het proces op lijkt gericht te zijn
success_criteria Hoe een succesvolle case wordt herkend, en het aandeel cases dat aan elke test voldoet
outcomes Alle manieren waarop een case eindigt, met het aantal cases en het aandeel
stages De fasen die een case doorloopt en de activiteiten in elke fase
nodes Eén item per activiteit, plus start en einde: cases, events, herhalingen, de typische tijd naar de volgende stap, rollen
edges Eén item per overdracht: cases, aandeel, de typische wachttijd en de wachttijd van de langzaamste cases
variants Het hoofdpad, toegestane variaties en uitzonderingspaden met minstens één case per honderd
model Een procesmodel dat uit de paden is ontdekt en het aandeel cases dat het accepteert
decisions Elk punt waar cases splitsen: de vertakkingen, en de if-then-regels die de splitsing verklaren, indien aanwezig
sequence_rules Volgorderegels die bijna altijd gelden, met het aandeel cases waar elke regel geldt
exceptions Herhaalde, overgeslagen en stappen in verkeerde volgorde, zeldzame activiteiten en mislukte eindes
escalations Stappen die vooral voorkomen na lange wachttijd of een mislukte poging
policies Tijdsgrenzen waarbinnen de meeste cases blijven, en het aandeel dat daaraan voldoet
roles Welke rollen welke activiteiten uitvoeren, wanneer het log registreert wie het werk deed
object_types, object_relations Soorten objecten en hoe ze zich verhouden, voor een object-gecentreerde log
evidence_levels De vijf labels voor sterkte, elk één keer gedefinieerd
assumptions, open_questions Wat besloten is vóór het werk begon, wat niet gemeten kon worden, en wat een lezer nader zou moeten onderzoeken

Aantallen zijn gehele getallen, aandelen zijn breuken tussen 0 en 1, tijden zijn in uren. Elk onderdeel is aanwezig in elke graph; een lijst zonder inhoud is leeg in plaats van afwezig, en geen waarde is ooit null.

Sommige onderdelen worden door code geteld – een tweede run op dezelfde data geeft hetzelfde resultaat. Andere zijn een interpretatie van de data: wat een case betekent, welke eindes als succes tellen, waar de fasen liggen. Het rapport zegt wat wat is.

Hoe ver je elk onderdeel kunt vertrouwen

Elk onderdeel dat een bewering doet, bevat één evidence object: hoeveel cases het ondersteunt, hoeveel het zou kunnen zijn, het aandeel waar het geldt, hoe het is gemeten – plus een label voor sterkte:

Label Betekenis
counted Een directe telling uit de log
strong Geldt in minstens 95 procent van de toepasselijke cases, en is gebaseerd op minstens 100 cases
moderate Geldt in minstens 80 procent, en is gebaseerd op minstens 30 cases
weak Alles wat minder is
hypothesis Afgeleid uit activiteitsnamen of timing, niet getest als regel

Lees eerst de sterkte: counted is een feit over de log; hypothesis is een idee dat het waard is om te onderzoeken.

De volledige definitie

De vorm is vast en krijgt versies. Dit is versie 1.0, en een document dat eenmaal slaagt, slaagt voor altijd; elke wijziging aan de velden is een nieuwe versie met een eigen schema-bestand.

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

Het schema-bestand is de volledige vorm, als JSON Schema (draft-07) dat elke validator kan lezen. Elke graph wordt gecontroleerd als het rapport wordt gepubliceerd: een rapport waarvan de graph niet de juiste vorm heeft, wordt niet gepubliceerd, en de reden noemt de fout in het onderdeel.

Controleer zelf een graph

Plaats het schema-bestand naast de graph en controleer ze met elke JSON Schema-validator. In Python, sla dit op 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")

en voer het uit:

pip install jsonschema
python check_graph.py

Het print valid, of stopt met het onderdeel dat niet voldoet aan de vorm. Omdat het project elke graph controleert bij publicatie, slaagt een gepubliceerde graph altijd.

Volgende stappen