Demander une démo
Zenith · Automatisation

Un moteur de règles incapable de dire quelle règle s’est déclenchée, c’est une humeur.

L’automatisation de Zenith est conçue pour être lue avant qu’on lui fasse confiance. Les tables de décision répondent par des lignes que vous pouvez montrer du doigt. Les flux de travail sont publiés en versions figées et numérotées, et une exécution en cours se termine selon les règles avec lesquelles elle a commencé. Les modèles nomment chaque variable qu’ils n’ont pas pu remplir. Et là où le moteur n’exécute pas encore quelque chose, l’écran le dit clairement.

Demander une démo Ce que vous pouvez créer
Bilingue FR / EN · Multisite · WCAG 2.2 AA
La première correspondance l’emporte
Et la réponse nomme la ligne qui a décidé, par sa position
Versionné comme une loi
Un flux de travail publié est figé, et une exécution se termine selon les règles avec lesquelles elle a commencé
13 erreurs nommées
Chaque vérification structurelle pointe vers son propre nœud — « flux de travail invalide », c’est un produit qui abandonne
FR · EN
Chaque libellé, indication, état vide et refus, dans les deux langues
Ce que vous créez

Six choses qu’une personne met par écrit

L’automatisation fait ses preuves dans les mois qui suivent sa mise en place, quand une autre personne doit comprendre pourquoi elle a fait ce qu’elle a fait. Chaque interface ici est conçue pour cette deuxième conversation plutôt que pour le premier après-midi.

01

Tables de décision

Des règles en lignes, lues de haut en bas. La première ligne dont toutes les conditions sont remplies décide, et les lignes suivantes ne sont pas consultées — c’est ce qui rend la table vérifiable.

02

Flux de travail

Un graphique visuel de neuf types de nœuds — début, processus, approbation, décision, affectation, automatisation, notification, attente, fin — chacun avec une clé d’étape comme P2 ou D1 qui reste stable une fois attribuée.

03

Modèles de notification

Les mots que l’automatisation envoie, gérés par les administrateurs plutôt que par les développeurs, en français et en anglais dès la première frappe.

04

La boîte de réception

Ce que le système avait à vous dire — rendu au moment de l’envoi selon l’état des registres à ce moment-là : chaque entrée est un dossier plutôt qu’une requête en direct qui se réécrit.

05

Versions

La publication prend un instantané figé et numéroté et laisse l’ébauche exactement telle qu’elle était. Publier, c’est prendre un instantané, pas passer la main.

06

Simulation

Demandez à une table ce qu’elle déciderait, et parcourez un graphique avec des données d’exemple — avant de confier un vrai trafic à l’un ou à l’autre.

Tables de décision

« Pourquoi cette demande est-elle sortie Urgente? »

Cette question mérite exactement une réponse, et une table de décision est la forme qui la donne : les lignes se lisent de haut en bas, la première dont toutes les conditions sont remplies décide, et la décision nomme la ligne qui l’a prise. Des règles qu’un planificateur peut lire sans programmeur, et contester sans réunion.

  • La réponse nomme sa ligne — « décidé par la ligne 2 », ou « aucune ligne ne correspond, la valeur par défaut a répondu », ou simplement « aucune décision » quand il n’y a ni l’un ni l’autre.
  • L’ordre est la règle; déplacer une ligne est donc une décision — les lignes se déplacent avec des flèches plutôt qu’en glissant au petit bonheur, parce que l’ordre est le sens.
  • Une nouvelle ligne correspond à tout — visiblement trop large, elle est donc modifiée plutôt qu’oubliée discrètement au milieu de la table.
  • Les réponses proviennent d’un ensemble fermé — une ligne ne peut pas inventer un résultat que personne n’a listé; c’est ainsi que « Urgent » et « urgent » cessent d’être deux priorités.
Versionné comme une loi

Une approbation commencée sous la v1 se termine sous la v1

Changer les règles en cours de route, c’est ainsi qu’une approbation que personne n’a donnée est consignée comme donnée. Un flux de travail, c’est donc deux choses qui partagent un nom : une ébauche, la seule tête modifiable, et une liste de versions, chacune figée au moment de sa publication. L’éditeur ne touche que l’ébauche; une exécution ne fait référence qu’à un numéro de version.

  • La publication ne touche aucune exécution — la nouvelle version est écrite et la liste des exécutions n’est pas touchée du tout : la garantie est structurelle plutôt qu’une promesse faite lors d’une revue de code.
  • Le lien est sur la ligne — « Publié v2 · 2 toujours en cours sur la v1 », c’est la règle énoncée comme un fait, là où la personne qui décide de publier la lira.
  • Publier une ébauche inchangée est refusé — une version qui ne change rien gonfle les numéros de version, et la prochaine personne qui lit « v7 » mérite de croire que sept décisions ont été prises.
  • Une nouvelle tentative relance la même étape sur la même version liée — jamais une plus récente, la seule chose qu’une automatisation ne doit jamais improviser.
Avant de pouvoir publier

« Flux de travail invalide », c’est un produit qui abandonne

Treize vérifications structurelles sont exécutées sur le graphique de l’ébauche, et chaque constatation pointe vers le nœud qui a échoué, en une phrase. Les erreurs bloquent la publication. Les avertissements, non — parce que la différence entre « ceci ne peut pas fonctionner » et « ceci va probablement agacer quelqu’un » vaut la peine d’être conservée.

  • Une approbation sans approbateur ne peut pas être publiée — ce n’est pas un flux de travail avec une lacune; c’est une barrière maintenue ouverte qui a l’air d’une barrière.
  • Une seule entrée — deux nœuds Début, ce sont deux affirmations sur le point de départ du processus, et un moteur d’exécution ne pourrait en honorer qu’une, en silence.
  • Chaque sortie de décision est étiquetée — un diagramme qui ne peut pas dire ce qui va où est une image plutôt qu’une conception.
  • Supprimer un nœud supprime ses connecteurs — un fil qui ne mène nulle part est pire qu’une boîte manquante.
Les mots qu’il envoie

Une notification qui devine apprend à tout le monde à se méfier de toutes les notifications

Un modèle est modifié par un administrateur et lu par un monteur à deux heures du matin, et entre les deux se trouve un moteur de rendu. Quand une variable ne peut pas être résolue — mal tapée, ou demandant un champ que l’événement ne transporte pas —, les options honnêtes sont de le dire ou de deviner. Zenith le dit, nommément, avant même que le modèle soit utilisé.

  • Les variables non résolues restent visibles dans le texte — laissées sous la forme {{approver.name}} plutôt qu’effacées en silence, pour que personne n’envoie une phrase trouée.
  • L’aperçu est rendu à partir de vrais dossiers — l’auteur voit « La génératrice de secours ne démarre pas à l’essai », pas {{workOrder.summary}}. C’est la différence entre vérifier un modèle et y croire.
  • Chaque événement offre un ensemble fermé de variables — ce qu’un bon de travail peut offrir, ce qu’une alerte de stock peut offrir, listé plutôt que deviné de mémoire.
  • Le français et l’anglais dès la première frappe — l’objet et le corps sont des champs par langue, pas une passe de traduction ajoutée après que quelqu’un s’est plaint.
Où se trouve la ligne

Ce qui s’exécute, et ce qui est mis par écrit

L’automatisation est la partie d’un système de maintenance le plus souvent vendue comme terminée et livrée sous forme de diagramme. Zenith trace la ligne là où son propre code la trace : ce qu’une personne crée est construit et vérifiable aujourd’hui, et ce qui s’exécute sans surveillance appartient à la phase serveur — chaque écran concerné le disant clairement plutôt que dans une note de bas de page.

Dit tout haut, à l’écran

Le produit vous dit où il s’arrête

La plupart des modules d’automatisation sont achetés sur la foi d’une démo du concepteur, et découverts au quatrième mois. Celui-ci affiche la limite au bas de la page à laquelle elle s’applique — la question « est-ce que ça s’exécute vraiment? » trouve donc sa réponse avant le bon de commande, pas après.

  • Le simulateur est au conditionnel, et c’est voulu — rien n’est créé, envoyé ni réservé, et chaque note qu’il écrit commence par le mot « aurait ».
  • L’écran des exécutions porte sa propre mise en garde — « le moteur qui exécute réellement les étapes relève de la moitié serveur » figure sous le tableau, en permanence, pas dans une note de version.
  • C’est le transport qui manque, pas le modèle — la boîte de réception est déjà la surface de livraison, rendue et horodatée; quand le répartiteur arrivera, il enverra par cette même porte.
  • Rien n’est déguisé en produit fini — une étape d’automatisation qui ne fait encore rien est une erreur qui bloque la publication, pas une boîte qui reste là à avoir l’air compétente.
Et le reste

Tout ce qui entoure la règle

Sept choses à surveiller

Un bon de travail créé, terminé ou fermé; une demande soumise; une alerte d’état déclenchée; un stock sous le point de commande; un bon de commande émis. Une liste fermée, délibérément — un événement est un contrat, pas un souhait en texte libre.

Des identifiants d’étape qu’on peut prononcer

P1, D2, A1 — numérotés dans le flux de travail et stables une fois attribués, pour qu’une conversation sur « la deuxième approbation » ait un nom que les deux personnes reconnaissent.

L’algorithme, dessiné honnêtement

Une pastille de début pour le déclencheur, un losange pour chaque contrôle avec son « non » qui part vers Arrêt, une boîte pour chaque étape qui fait du travail. Les branches que le moteur ne peut pas prendre ne sont pas dessinées — une plus jolie image d’un autre produit n’aide personne.

La lecture est un horodatage

Pas un indicateur. « Quand l’ont-ils vue? » est la question que pose toute analyse après coup d’une notification — et lire deux fois est refusé, parce que le premier horodatage est le fait.

Les échecs portent leur raison

Un échec sans raison n’est pas un échec, c’est un mystère — la raison est donc obligatoire, et elle figure sur la ligne à côté de l’exécution qui s’est arrêtée.

Des mots qui appartiennent aux gens

Les modèles sont modifiés par les administrateurs, pas livrés dans une version du logiciel. Renommez n’importe quoi dans votre vocabulaire et chaque titre suit — jamais ce sur quoi un filtre s’appuie.

Une version veut toujours dire une décision

Une ébauche inchangée ne peut pas être publiée : un numéro de version n’est donc jamais gonflé par quelqu’un qui clique pour être sûr.

Les boucles sont signalées, pas exécutées

Le simulateur parcourt le graphique et s’arrête dès qu’il revient dans un nœud déjà visité, en le nommant — plutôt que de tourner en rond en silence pour le compte de quelqu’un.

Deux langues, jusqu’au bout

Chaque libellé, indication, état vide, blocage et refus existe en français et en anglais — y compris la phrase qui vous dit qu’un flux de travail ne peut pas encore être publié.

Des fondations d’entreprise

Une automatisation que vous pouvez transmettre

La personne qui a mis en place votre automatisation partira. Tout ici est conçu pour la personne qui en héritera — celle qui devra expliquer, cinq ans plus tard, pourquoi le système a fait ce qu’il a fait un mardi dont personne ne se souvient.

Créé, puis figé

Une ébauche se modifie librement; une version est un instantané que rien ne peut modifier après coup, et chaque exécution nomme la version sous laquelle elle vit.

Les refus nomment leur propre étape

Rien n’est rejeté comme « invalide ». Chaque blocage dit quelle étape, quel champ et ce qui manque : la correction est évidente plutôt qu’une chasse au trésor.

Bilingue dès sa conception

Parité complète en-CA / fr-CA sur chaque écran, indication, état vide et refus — les pluriels gérés correctement, pas par concaténation.

Accessible à tous

WCAG 2.2 AA comme règle de conception : de vrais onglets sémantiques, des états annoncés en mots, et un focus qui se déplace vers le champ visé par une erreur.

Conçu en fonction de ISO 55000 · Gestion d’actifs EN 13306 · Terminologie de la maintenance WCAG 2.2 AA
Les questions que l’on nous pose vraiment

Avant de réserver la démo

Peut-il envoyer un rapport tous les lundis matin?
Les rapports selon une récurrence sont le travail du planificateur de rapports , et il fait exactement cela — configuration saisie, récurrence quotidienne, hebdomadaire, mensuelle ou annuelle, et envoi par courriel à partir d’un processus en arrière-plan sur votre serveur. Ce pour quoi le module d’automatisation n’a pas de déclencheurs temporels, ce sont les flux de travail et les règles : chacun de ses sept déclencheurs est un événement, quelque chose qui s’est produit dans un registre. Il n’y a pas de « quatre heures après cette étape » ni de flux de travail récurrent; ils arriveront avec la phase serveur.
Envoie-t-il des courriels?
Les notifications sont livrées aujourd’hui dans une boîte de réception intégrée à l’application, rendues au moment de l’envoi et horodatées au moment de leur lecture. L’envoi de courriels et de textos relève de la moitié serveur — et le modèle est déjà prêt : les modèles comportent un canal, les objets et les corps existent dans les deux langues, et la boîte de réception est la surface de livraison. Ce qui manque, c’est le transport, pas la conception. Quand le répartiteur arrivera, il enverra par la même porte.
Une règle peut-elle se déclencher automatiquement sur le trafic réel?
Les tables de décision sont créées, simulées et débattues aujourd’hui; le déclenchement sur le trafic réel relève de la phase serveur. Cet ordre est délibéré. La table est la partie qui doit être juste en premier — un moteur de règles incapable de dire quelle règle s’est déclenchée est une humeur, et une table que personne n’a interrogée est une règle que personne ne devrait appliquer à de vraies demandes.
Que peut surveiller un flux de travail?
Sept événements de registre : un bon de travail créé, terminé ou fermé; une demande de service soumise; une alerte d’état déclenchée; un stock qui passe sous le point de commande; un bon de commande émis. La liste est fermée délibérément — un événement est un contrat avec ce qui l’émet, pas un souhait en texte libre, et un flux de travail qui surveille quelque chose que rien n’émet est un flux qui ne s’exécute jamais et ne dit jamais pourquoi.
Qu’arrive-t-il aux approbations en cours quand nous modifions un flux de travail?
Rien du tout, et c’est justement le but. Une exécution porte le numéro de la version sous laquelle elle a commencé, et la publication écrit une nouvelle version sans toucher à la liste des exécutions. Une approbation commencée sous la v1 se termine selon les règles de la v1 — parce que changer les règles en cours de route, c’est exactement ainsi qu’une approbation que personne n’a donnée est consignée comme donnée.
Y a-t-il un suivi des NS et une escalade?
Pas encore. Des définitions de NS peuvent être jointes à une étape d’approbation dans le concepteur, et le validateur vous avertit quand une étape n’en a pas — « elle peut attendre indéfiniment sans rien dire » — mais le moteur de NS lui-même relève de la phase serveur. Il n’y a ni compte à rebours, ni escalade après N heures, ni rappels automatiques dans cette version. L’avertissement existe justement pour que personne ne suppose le contraire pendant la conception.
Peut-on créer des branches, ou exécuter deux chemins à la fois?
Des branches, oui : un nœud de décision a besoin d’au moins deux chemins de sortie, chacun devant être étiqueté, sinon le flux de travail ne sera pas publié. Les chemins parallèles et les boucles ne sont pas pris en charge — une boucle est détectée et signalée nommément plutôt qu’exécutée. L’ancien moteur d’exécution linéaire en dessous n’a qu’une voie, et le diagramme de l’algorithme la dessine ainsi délibérément : une image de branches que le moteur ne peut pas prendre serait une plus jolie image d’un autre produit.
Une étape peut-elle être assignée à une personne précise?
Les étapes sont assignées à un groupe — un groupe fonctionnel ou un rôle d’approbation — plutôt qu’à une personne, et une étape de processus sans groupe déclenche un avertissement : « la file de personne ne la contiendra ». L’assignation par personne, avec l’approbation, le refus et la réassignation, appartient au moteur d’exécution qui arrive avec la phase serveur.
Qu’est-ce qui empêche un flux de travail à moitié construit d’être mis en service?
Un contrôle de publication avec des blocages nommés. Une approbation qui ne nomme aucun approbateur, une décision avec moins de deux sorties, un chemin non étiqueté, une notification sans modèle, une étape d’automatisation qui ne fait encore rien, un nœud que rien ne peut atteindre, un nœud sans issue — chacun est une erreur qui pointe vers son propre nœud et refuse. Une barrière maintenue ouverte a l’air d’une barrière; c’est précisément le défaut que cela empêche.
Peut-on tester un flux de travail avant de le publier?
Oui, et le test est délibérément impuissant. Le simulateur parcourt l’ébauche avec des données d’exemple et indique le chemin que suivrait un dossier et ce que ferait chaque étape — chaque note commençant par le mot « aurait ». Rien n’est créé, envoyé ni réservé. C’est la phrase dont un concepteur a besoin avant d’oser publier, plutôt qu’un essai à blanc avec des effets secondaires.
À qui appartient la formulation d’une notification?
À vous. Les modèles sont modifiés par les administrateurs plutôt que livrés dans une version du logiciel, avec l’objet et le corps conservés séparément pour le français et l’anglais. Chaque événement publie les variables qu’il peut offrir — le code et le résumé d’un bon de travail, le compteur et le relevé d’une alerte, la quantité disponible d’une pièce — et l’aperçu est rendu à partir de vrais dossiers : l’auteur lit donc la phrase exacte qu’un technicien recevra à deux heures du matin.
Comment cela s’intègre-t-il au reste de Zenith?
Les définitions vivent dans la couche plateforme, pas dans les écrans d’automatisation : les bons de travail, les achats et les plans de maintenance peuvent tous faire référence à un flux de travail, une règle ou un modèle sans qu’un module en importe un autre. C’est la même séparation qui permet à la page d’une machine d’afficher ses règles d’état sans que le module des actifs ait à savoir ce qu’est une règle d’état — et c’est pourquoi ajouter plus tard un événement ou une source est un ajout plutôt qu’un changement structurel.
Voyez-le sur une règle dont vous débattez déjà

Apportez la règle que personne ne peut expliquer.

Chaque organisation en a une — la priorité fixée par une règle que quelqu’un a écrite en 2019, ou l’approbation qui se déclenche pour des raisons que trois personnes décrivent de trois façons. Mettez-la par écrit avec nous sous forme de table, nous lui demanderons ce qu’elle déciderait, devant vous, et elle nommera la ligne qui a répondu.

Demander une démo Parler à notre équipe
Zenith · Automatisation Fait partie de la plateforme Zenith d’opérations de maintenance et d’actifs

Les normes sont citées uniquement par numéro, titre et portée. Les publications CSA et ULC sont payantes — lisez la norme elle-même avant de bâtir un programme de conformité sur un résumé.