Ce que la collecte de données d'atelier doit réconcilier
Le TRS semble n'être qu'un simple pourcentage. Il est pourtant constitué de mesures définies indépendamment par plusieurs systèmes.
- Temps de production planifié : le calendrier des équipes, détenu par l'ERP et inconnu de la machine
- Temps d'arrêt et motifs : la machine enregistre son arrêt, mais seul un opérateur ou le système d'exécution manufacturière (MES) sait s'il s'agit d'une panne, d'un changement de série ou d'une pause
- Temps de cycle idéal : la cadence théorique de la pièce, généralement définie dans la gamme opératoire de l'ERP plutôt que sur la machine
- Quantité conforme par rapport à la quantité totale : la machine compte les cycles, et le contrôle qualité détermine quelles pièces sont commercialisables
- L'ordre de fabrication associé : l'ordre de travail en cours à ce moment-là, une information que la machine n'a aucune raison de connaître
Seul l'un de ces cinq éléments provient de la machine. Les autres sont issus des systèmes de gestion, ce qui explique pourquoi un projet de collecte qui s'arrête à la machine produit des chiffres que personne ne peut justifier.
Pourquoi la collecte de données d'atelier produit-elle deux chiffres de TRS ?
Les définitions divergent avant même que le reste ne soit pris en compte. Si le temps de production planifié exclut la maintenance programmée dans un système et l'inclut dans l'autre, le taux de disponibilité différera de plusieurs points sans pour autant que l'un des systèmes ait tort. Il en va de même pour savoir si un arrêt de cinq minutes doit être comptabilisé comme un temps d'arrêt ou comme un micro-arrêt intégré à la performance.
Le décalage temporel creuse encore davantage l'écart. Les données machine arrivent en continu, tandis que les écritures ERP sont saisies lorsqu'un opérateur confirme un ordre de fabrication, souvent à la fin de son poste. Comparer une donnée en temps réel à une donnée confirmée revient à mesurer le délai de reporting autant que la performance. C'est ce délai que le suivi de production en temps réel vise à résoudre au niveau de l'architecture.
L'attribution est le plus discret de ces trois problèmes, mais aussi le plus coûteux. Une production enregistrée sur le mauvais ordre de fabrication donne un total correct au niveau de l'usine, tout en faussant le coût de chaque tâche concernée. C'est ce qui explique pourquoi les chiffres globaux de l'usine semblent cohérents alors que le calcul des coûts par tâche reste peu fiable.
Aucun de ces trois problèmes ne provient des capteurs, c'est pourquoi en acheter davantage ne sert à rien.
Où un chiffre de TRS sous-estimé coûte de l'argent
Le tableau de bord ne tombe pas en panne de manière spectaculaire. Il est simplement ignoré, et les coûts s'accumulent en arrière-plan.
- Réunions consacrées à contester le chiffre : temps perdu à débattre de la validité des données plutôt que de décider des actions à mener
- Projets d'amélioration ciblant la mauvaise perte : si les changements de série sont classés par erreur comme des pannes, le budget de maintenance est dépensé là où le processus de réglage était en cause
- Calcul des coûts par tâche non fiable : une production attribuée au mauvais ordre fausse la marge des deux dossiers
- Planification de la capacité basée sur des taux gonflés : planifier sur la base d'un temps de cycle théorique jamais atteint conduit à des promesses que l'usine ne peut pas tenir
- Dossiers d'investissement au point mort : le remplacement d'une machine justifié par des données de TRS est bloqué lorsque le service financier ne peut pas vérifier la base de référence
Face à un chiffre qui semble erroné, le réflexe est souvent d'en collecter davantage.
Pourquoi la collecte de données en atelier doit fonctionner dans les deux sens
Collecter davantage de données sur le terrain implique plus de capteurs, une granularité plus fine et des intervalles plus courts. Cela améliore la résolution de la partie déjà opérationnelle, mais laisse le désaccord exactement là où il était.
L'autre moitié, c'est le contexte. Un événement d'arrêt ne devient un temps d'arrêt avec une raison que lorsqu'une personne ou un système le classifie. Un comptage de cycles ne devient un comptage de pièces conformes qu'une fois validé par le contrôle qualité. Une quantité produite n'a de sens que lorsqu'elle est associée à l'ordre de fabrication correspondant.
Le véritable besoin est donc bidirectionnel. L'ordre de fabrication, la gamme opératoire et le calendrier des équipes doivent être transmis à l'atelier afin que les données machine puissent être étiquetées au moment de leur production. Le résultat étiqueté doit ensuite être renvoyé à l'ERP pour confirmation. Un projet qui ne fait que remonter des données produira toujours un chiffre sujet à débat.
Trois approches sont tentées pour boucler cette boucle, chacune présentant ses propres limites. Une plateforme de monitoring machine visualise bien le TRS, mais utilise généralement ses propres définitions plutôt que celles de l'ERP. Un MES s'insère correctement entre l'atelier et les systèmes de gestion, mais représente une mise en œuvre lourde, ce que beaucoup d'usines cherchent à différer. La saisie manuelle dans l'ERP en fin de poste reste la pratique la plus courante, générant précisément ce décalage qui rend tout rapprochement impossible.
Comment une plateforme d'intégration permet-elle de réconcilier les données d'atelier ?
Une plateforme d'intégration en tant que service (iPaaS) connecte la couche machine aux systèmes détenant les définitions, à savoir l'ERP pour le calendrier et la gamme, et le contrôle qualité pour le comptage des pièces conformes. Les deux flux transitent par la même couche, permettant au contexte d'atteindre l'atelier et aux confirmations de remonter.
C'est la bidirectionnalité qui transforme un simple flux en véritable intégration. Envoyer l'ordre de fabrication actif vers la machine permet d'étiqueter la production au moment où elle se produit, plutôt que de la reconstruire en fin de poste. Mapper les états machine sur les catégories de temps d'arrêt de l'ERP garantit que la disponibilité repose sur une définition identique des deux côtés. Transférer les données dans un seul sens, c'est s'exposer à avoir deux chiffres différents.
Alumio est une plateforme d'intégration conçue pour fonctionner dans les deux sens, transmettant le contexte vers le bas et les confirmations vers le haut. La plateforme d'intégration Alumio gère cela de quatre manières.
- Contexte transmis à l'atelier : un itinéraire de données piloté par les événements au sein d'Alumio transmet l'ordre de fabrication actif, la gamme et le calendrier des équipes à la couche machine, afin que la production soit étiquetée en temps réel plutôt que reconstruite a posteriori
- Une définition unique appliquée aux deux systèmes : un transformateur de données mappe les états machine sur les mêmes catégories de temps d'arrêt que celles utilisées par l'ERP, garantissant ainsi que la disponibilité signifie la même chose dans les deux systèmes
- Confirmations renvoyées en continu : un itinéraire de données transmet les quantités produites et rebutées dans l'ERP, en les affectant au bon ordre de fabrication au fur et à mesure, ce qui élimine le décalage de fin de poste
- Chaque valeur traçable jusqu'à sa source : des journaux détaillés enregistrent quelle lecture a produit quel chiffre, transformant ainsi un chiffre contesté en une simple vérification plutôt qu'en une réunion
La configuration gère le mappage des états et les flux de retour, tandis que le transformateur de code d'Alumio permet aux développeurs de coder là où ils le préfèrent plutôt que de passer par la configuration. Une seconde ligne devient opérationnelle sur la base de mappages existants, ce qui transforme les données machine atteignant les systèmes d'entreprise en un chiffre plutôt qu'en un simple flux.
Ce qui change avec la collecte de données réconciliées en atelier
La valeur d'un programme de collecte ne se mesure pas au nombre de machines connectées, mais au fait que le directeur d'usine et le directeur financier s'accordent sur un chiffre unique, sans aucune contestation.
Trois rôles se partagent cette responsabilité. Le directeur d'usine est garant du TRS et du plan d'amélioration qui en découle. Le responsable de planification établit ses plannings en fonction des temps de cycle théoriques plutôt que des performances réelles de la ligne. Le contrôleur de gestion, quant à lui, doit calculer le coût de chaque tâche à partir de données de production qui ont pu être attribuées à la mauvaise commande.
Parvenir à un chiffre unique transforme la finalité même des données. Le TRS cesse d'être un simple indicateur d'usine présenté en réunion pour devenir une donnée essentielle au calcul des coûts, à la planification de la capacité et aux dossiers d'investissement. C'est une plateforme d'intégration bidirectionnelle qui permet d'obtenir ce chiffre unique, car les deux parties finissent par le calculer à partir des mêmes définitions. C'est bien plus qu'un simple tableau de bord amélioré.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
