Un tableau de bord n’est pas de la numérisation

L’un des aboutissements les plus fréquents de la numérisation industrielle et énergétique est un tableau de bord spectaculaire. Les compteurs sont raccordés, les données arrivent, les courbes bougent et, lors de la réception du projet, chacun regarde le grand écran avec satisfaction.

Puis, quelques semaines plus tard, on s’aperçoit que le fonctionnement de l’entreprise n’a, pour l’essentiel, pas changé du tout.

Les pannes sont toujours signalées par téléphone. Les écarts de consommation d’énergie, quelqu’un les remarque de temps en temps. Les tâches sont attribuées par e-mail. Le résultat de l’intervention n’est pas relié à l’événement d’origine. Et le tableau de bord devient peu à peu un fond d’écran coûteux.

Cela ne veut pas dire que la visualisation soit inutile. Un bon tableau de bord est important. Simplement, ce n’est pas la numérisation elle-même, mais l’une de ses interfaces.

Le graphique répond, si quelqu’un pose la bonne question

Un tableau de bord est par nature un outil passif. Il présente des informations à celui qui l’ouvre, sait ce qu’il cherche, interprète correctement ce qu’il voit, puis dispose du temps et du droit d’agir.

Cela fait beaucoup de conditions à la fois.

Si la puissance absorbée par un système de refroidissement augmente lentement, le graphique peut montrer la tendance. Mais, à lui seul, il ne détermine pas :

• à partir de quel écart une valeur doit être considérée comme anormale ;
• à quel état de fonctionnement il faut la rapporter ;
• qui est responsable de l’analyse ;
• dans quel délai il faut réagir ;
• ce qui se passe si aucune mesure n’est prise ;
• comment mesurer si l’intervention a été efficace.

Le tableau de bord rend le problème visible. C’est au système opérationnel de le traiter.

La vraie chaîne : de la mesure à un processus bouclé

Dans une solution numérique mature, la chaîne ne s’arrête pas au graphique :

mesure → interprétation → événement → décision → tâche → exécution → vérification.

Prenons un exemple simple. Un sous-compteur indique que la consommation de base nocturne d’une zone de production est restée au-dessus de sa valeur habituelle trois jours de suite.

Un tableau de bord peut l’afficher. Un système opérationnel, en revanche :

1. compare la valeur à la valeur de référence (baseline) de la période et de l’état de fonctionnement correspondants ;
2. crée un événement ;
3. y associe le site et les équipements concernés ;
4. prévient le responsable ;
5. ouvre une tâche ou un bon de travail ;
6. consigne le résultat de l’analyse et de l’intervention ;
7. vérifie par une nouvelle mesure si la consommation de base est revenue à la normale ;
8. chiffre la surconsommation évitée.

On ne parle plus ici d’affichage de données, mais d’un processus d’exploitation exécutable numériquement.

Sans responsable, la donnée ne vaut rien

L’une des questions les plus importantes, et pourtant régulièrement oubliée, est la suivante : à qui appartient l’événement ?

L’alarme peut être la plus précise du monde : si le message arrive dans une boîte partagée, ou si dix personnes le reçoivent en même temps dans l’espoir que quelqu’un réagira, personne ne s’en charge. Or un signal sans responsable finit généralement par devenir du bruit.

Dans un bon processus, on peut définir :

• le responsable de l’événement ;
• la règle d’escalade ;
• le délai de réponse ;
• la documentation requise ;
• la condition de clôture ;
• les modalités d’approbation et de contrôle a posteriori.

C’est à ce stade que la donnée OT rencontre le fonctionnement de l’entreprise.

Le contexte compte plus que la résolution du graphique

Une consommation de 20 kW peut être normale ou anormale. Tout dépend de la machine concernée, de l’état de production, de l’équipe en poste, de la température extérieure et de l’historique.

C’est pourquoi la donnée doit être reliée aux objets réels de l’entreprise : équipement, lieu, centre de coûts, client, contrat, événement de maintenance ou ordre de fabrication.

Sans ce lien, le système stocke beaucoup de données mais produit peu de connaissance.

Le modèle commun de données et de processus d’OrigSmart comble précisément ce fossé. La donnée de mesure ne reste pas une série temporelle isolée : elle s’inscrit dans l’environnement physique et métier. Le même événement peut ainsi apparaître pour l’exploitant technique, le responsable énergie, la finance et la direction – pour chaque rôle, sous la forme dont il a besoin pour sa propre décision.

Un bon tableau de bord est conçu pour l’action

Un tableau de bord est utile lorsqu’il ne cherche pas à tout montrer à la fois, mais qu’il aide à décider.

Celui qui doit intervenir immédiatement n’a pas besoin de la même vue que celui qui analyse les coûts mensuels. L’exploitant a besoin de l’état actuel, des priorités et de l’action concrète à mener. La direction a besoin de tendances, de risques, d’écarts et de l’impact métier. Le technicien de maintenance a besoin de l’historique de l’équipement, des documents associés et d’un bon de travail qu’il peut clôturer.

Chez OrigSmart, le tableau de bord n’est donc pas un produit à part entière. C’est une fenêtre adaptée à chaque rôle, au sein du même système qui gère aussi la donnée source, l’événement, les droits d’accès et le processus exécutable.

La mesure de la numérisation n’est pas le nombre d’écrans

Le succès d’un projet ne se mesure pas au nombre de graphiques créés, mais par exemple à des critères tels que :

• de combien le temps de réaction a été réduit ;
• combien d’événements ont reçu un responsable et ont été clôturés ;
• si les arrêts non planifiés ont diminué ;
• si des économies d’énergie ou de coûts peuvent être démontrées ;
• si une étape manuelle de collecte de données ou de coordination a disparu ;
• si l’auditabilité s’est améliorée ;
• si une boucle de rétroaction automatique a été mise en place.

C’est pourquoi OrigSmart ne commence pas, même pour un pilote classique, par couvrir toute l’entreprise de tableaux de bord. Nous partons d’une source de données définie, d’un problème concret et d’un critère de réussite mesurable. Le pilote peut bien sûr comporter un tableau de bord et des alertes, mais il doit aussi déboucher sur au moins une action traçable.

Car la donnée crée de la valeur lorsqu’elle change quelque chose dans le fonctionnement.

Sources

• OrigSmart – Système d’exploitation d’entreprise basé sur le web
• NIST SP 800-82 Rev. 3 – Guide to Operational Technology Security