Obtenir le Graphe de Contexte de Processus

Le graphe de contexte de processus est un document JSON unique qui décrit comment votre processus fonctionne réellement, construit à partir du journal d’événements de votre projet : ce qu’est un cas, comment les cas commencent et se terminent, les étapes et les transferts entre elles, les chemins empruntés par les cas, les points où ils se divisent et les règles qui expliquent cette division, ce qui ne va pas, combien de temps les choses prennent, et qui fait quoi. Chaque partie indique sur combien de données elle repose.

« Graphe de contexte de processus » est un nom utilisé sur le marché sans norme derrière. Voici ce que mindzie entend par là : un format par défaut que nous définissons, constitué d’éléments auxquels le projet peut déjà répondre, rassemblés dans un document d’une forme fixe afin qu’un agent puisse le charger et qu’une personne puisse le vérifier. Le projet peut répondre à bien plus que ce que contient le graphe ; Vos propres rapports et JSON porte sur cela.

Deux types d’agents se retrouvent autour du graphe. L’agent interne - l’agent mindzie qui s’exécute dans le projet - le construit lorsque le rapport Process Context Graph est lancé. Un agent externe - votre propre agent codé, fonctionnant depuis votre machine - le demande au projet en un seul appel. Connectez votre propre agent vous guide depuis zéro, avec une illustration de leur intégration.

À quoi ça sert

  • Un agent le charge avant d’intervenir sur votre processus, pour qu’il connaisse les vrais noms des étapes, le chemin normal, les points de décision et les exceptions, sans devoir les découvrir question par question.
  • Une personne le vérifie. Le même contenu est publié sous forme de rapport dans l’écran Rapports, avec une carte du processus, une table de décisions pour chaque décision expliquée, et la preuve à côté de chaque affirmation. Les tableaux du rapport et le JSON sont générés à partir des mêmes données, donc les deux ne peuvent pas contenir d’informations divergentes.

C’est une description et uniquement une description. Il ne recommande rien, et ne dit pas ce que quiconque est autorisé à faire.

L’obtenir en deux étapes

Étape 1 - Exécuter une fois le rapport Process Context Graph

À l’écran : ouvrez l’écran Rapports du projet, cliquez sur Créer un rapport sur la carte Process Context Graph, puis cliquez sur Démarrer. Voir Rapports.

Depuis votre propre agent : avec le projet démarré et vos données chargées, l’agent trouve la carte et la lance :

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 répond avec le slug du job, que les deux commandes suivantes utilisent ; sur un projet où la carte n’a jamais été lancée, c’est process-context-graph. L’exécution est un job IA : il utilise les crédits IA de votre projet. À la fin, le rapport est publié sur l’écran Rapports comme les autres.

Prévoyez un délai. Sur un journal de 1,6 million d’événements et environ 250 000 cas, l’exécution a pris 45 minutes, donc prévoyez jusqu’à une heure pour un journal de cette taille. mz jobs status affiche running jusqu’au moment où il affiche done ; il n’y a pas de progression intermédiaire. Les jobs d’un projet s’exécutent un à un, donc tout autre lancement en attente patiente.

Une exécution ultérieure publie la version suivante du même rapport. L’ancienne version et son JSON restent exactement inchangés.

Étape 2 - Récupérer le graphe en un seul appel

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

Cela écrit le graphe de contexte de processus actuel du projet dans un fichier JSON : le document publié le plus récent nommé mindzie.process-context-graph. Rien n’est recalculé et aucune IA n’est utilisée - l’appel lit le rapport déjà publié. Le même document est aussi le fichier process-context-graph.json attaché au rapport de la carte, donc mz reports attachment --slug process-context-graph --name process-context-graph.json renvoie exactement les mêmes octets.

Si le rapport n’a jamais été exécuté dans ce projet, l’appel refuse et indique les commandes pour en produire un (Étape 1). Il ne lance jamais lui-même l’exécution, car cela consommerait vos crédits IA sans votre demande.

Sous Windows, exécutez cette commande dans l’Invite de commandes : PowerShell re-encode le texte envoyé dans un fichier avec >. Pour vérifier le fichier par rapport à la définition, voir Vérifier un graphe vous-même ci-dessous. La manière dont votre agent obtient mz et sa clé se trouve dans Connectez votre propre agent.

À quoi ressemble un vrai graphe

Le graphe ci-dessous a été produit par la carte Process Context Graph sur un journal réel achat-à-paiement : 1 593 532 événements dans 251 658 cas, un cas par ligne d’ordre d’achat. Son JSON fait environ 300 Ko et contient 44 étapes, 188 transferts, 16 variantes, 25 points de décision, 48 règles de séquence, 48 exceptions, 4 escalades, 25 politiques, 20 hypothèses et 7 questions ouvertes. Il respecte la définition donnée en fin de page.

Représenté en image

Le flux principal d’un vrai graphe de contexte de processus, dessiné à partir de son JSON

Cette image est tirée directement du JSON, par un script court, pour montrer ce qu’il contient. Elle montre les étapes et les transferts les plus fréquentés - chacun emprunté par au moins 4 % des cas - dans les propres phases du graphe, avec le nombre de cas empruntant chaque transfert et le temps d’attente typique. Les lignes épaisses représentent le flux principal, les lignes en pointillés d’autres chemins, et les lignes rouges en pointillés ce que le graphe identifie comme exceptions. On lit par exemple : 72 % des articles se terminent avec « Nettoyer la facture », et le temps d’attente typique le plus long est celui entre la réception de la facture et son règlement, 36 jours.

Le JSON, abrégé

Comme l’agent l’a reçu, avec la plupart des listes réduites à une entrée et 14 des 22 parties laissées de côté, comme l’indique la dernière ligne. Chaque affirmation porte sa preuve : combien de cas, sur combien, comment cela a été mesuré, et son niveau de fiabilité.

{
  "schema": "mindzie.process-context-graph",
  "schema_version": "1.0",
  "source": {
    "data_version": "v0001",
    "log_digest": "4804d5916fc0",
    "case_notion": "une ligne d’article de commande d’achat (numéro de commande d’achat plus numéro d’article)",
    "cases": 251658,
    "events": 1593532,
    "period_start": "2015-03-08",
    "period_end": "2020-04-09",
    "time_basis": "clock"
  },
  "success_criteria": [
    {
      "id": "sc:cleared",
      "statement": "L’article est payé : le cas se termine par Nettoyer la facture.",
      "test": "dernier événement du cas est Nettoyer la facture",
      "share_met": 0.7203,
      "evidence": {
        "cases": 181257,
        "of_cases": 251658,
        "share": 0.7203,
        "strength": "counted",
        "method": "compte direct des cas dont le dernier événement est Nettoyer la facture"
      }
    }
  ],
  "outcomes": [
    {
      "id": "out:clear-invoice",
      "end_activity": "Nettoyer la facture",
      "kind": "success",
      "cases": 181257,
      "share": 0.7203
    },
    {
      "id": "out:record-invoice-receipt",
      "end_activity": "Enregistrer la réception de la facture",
      "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": "cas ayant ce transfert au moins une fois, sur cas avec la première étape ; parts comptent chaque visite de la première étape"
      }
    }
  ],
  "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": [
            "La zone de dépense n’est pas Trading & End Products",
            "Valeur de la commande (EUR) est au-dessus de 502,5 et jusqu’à 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": "règle issue d’un arbre de décision sur les transferts comptés ici ; la part indique la fréquence de correspondance avec l’étape suivante"
          }
        }
      ],
      "explained": true,
      "evidence": {
        "cases": 477,
        "of_cases": 499,
        "share": 0.6688,
        "strength": "weak",
        "method": "première visite de l’étape dans chaque cas ; les règles obtenues font 67 % contre 34 % en devinant toujours l’étape suivante la plus fréquente ; expliqué nécessite au moins 10 points d’écart"
      }
    }
  ],
  "policies": [
    {
      "id": "pol:create-purchase-order-item-record-goods-receipt-within-30-days",
      "kind": "service_level",
      "statement": "Niveau de service possible, déduit : Créer un article commande -> Enregistrer la réception des marchandises sous 30 jours (88 % des 74 809 cas terminent dans ce délai ; 8,1 % dans le quart du délai juste à l’intérieur, 4,0 % juste en dehors)",
      "threshold_hours": 720.0,
      "share_met": 0.8839,
      "evidence": {
        "cases": 66126,
        "of_cases": 74809,
        "share": 0.8839,
        "strength": "hypothesis",
        "method": "part des temps d’attente positifs à ou en dessous de la limite ; une limite compte quand au moins la moitié des temps l’atteignent et deux fois plus tombent dans le quart juste à l’intérieur que juste à l’extérieur"
      }
    }
  ],
  "...": "et 14 autres parties"
}

Les parties

Partie Ce qu’elle contient
source Les données dont le graphe a été construit : version des données, journal lu, ce qu’est un cas, cas, événements et période, temps effectif ou horloge
process Ce que représente un cas, et à quoi semble servir le processus
success_criteria Comment un cas réussi est reconnu, et la part des cas qui passe chaque test
outcomes Chaque façon dont un cas se termine, avec ses cas et sa part
stages Les phases traversées par un cas, et les activités dans chaque phase
nodes Une entrée par activité, plus le début et la fin : cas, événements, répétitions, temps typique vers étape suivante, rôles
edges Une entrée par transfert : cas, part, attente typique et attente des cas les plus longs
variants Le chemin principal, les variations autorisées, et les chemins d’exception comptant au moins un cas sur cent
model Un modèle de processus découvert depuis les chemins, et la part de cas qu’il accepte
decisions Chaque point de division des cas : branches et règles if-then qui expliquent cette division, si certaines existent
sequence_rules Règles d’ordre qui tiennent presque toujours, avec la part de cas où chacune tient
exceptions Étapes répétées, sautées et hors ordre, activités rares et fins ratées
escalations Étapes qui apparaissent surtout après une longue attente ou une tentative échouée
policies Limites de temps respectées par la majorité des cas, et la part qui y satisfait
roles Quels rôles font quelles activités, quand le journal enregistre qui a fait le travail
object_types, object_relations Les types d’objets et leurs relations, pour un journal centré sur les objets
evidence_levels Les cinq niveaux de fiabilité, chacun défini une fois
assumptions, open_questions Ce qui a été décidé avant de commencer, ce qui n’a pas pu être mesuré, et ce que le lecteur doit investiguer

Les comptes sont des nombres entiers, les parts des fractions de 0 à 1, et les temps sont en heures. Chaque partie est présente dans chaque graphe ; une liste sans élément est vide plutôt qu’absente, et aucune valeur n’est jamais nulle.

Certaines parties sont comptées par code - une seconde exécution sur les mêmes données donne le même nombre. D’autres sont une lecture des données : ce que représente un cas, quels aboutissements comptent comme un succès, où sont les phases. Le rapport dit quelle partie est de quel type.

Jusqu’où faire confiance à chaque partie

Chaque partie qui fait une affirmation porte un objet evidence - combien de cas elle couvre, combien elle pourrait concerner, la part où elle tient, la méthode de mesure - et un label de force :

Label Signification
counted Compte direct du journal
strong Tient dans au moins 95 % des cas concernés, reposant sur au minimum 100 cas
moderate Tient dans au moins 80 %, reposant sur au moins 30 cas
weak Tout ce qui est en dessous
hypothesis Déduit des noms d’activités ou du timing, non testé comme règle

Lisez d’abord la force : counted est un fait tiré du journal ; hypothesis est une idée à vérifier.

La définition complète

La forme est fixe et versionnée. Ceci est la version 1.0, et un document qui réussit une fois réussit pour toujours ; toute modification des champs correspond à une nouvelle version avec son propre fichier de schéma.

Télécharger mindzie.process-context-graph-1.0.schema.json

Le fichier de schéma est la forme complète, sous forme de JSON Schema (draft-07) lu par tout validateur. Chaque graphe est vérifié contre lui lors de la publication du rapport : un rapport dont le graphe ne correspond pas à la forme n’est pas publié, et la raison cite la partie et ce qui ne va pas.

Vérifier un graphe vous-même

Placez le fichier de schéma à côté du graphe et vérifiez l’un par rapport à l’autre avec n’importe quel validateur JSON Schema. En Python, enregistrez ceci comme 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")

et lancez-le :

pip install jsonschema
python check_graph.py

Il affiche valid ou s’arrête sur la partie qui ne correspond pas. Comme le projet vérifie chaque graphe lors de la publication, un graphe publié passe toujours.

Suite