Système andon ou logiciel TRS (OEE) : lequel acheter en premier ?

Vous savez que la ligne perd du temps. Reste à savoir quel outil acheter en premier : un système andon pour appeler de l'aide, ou un logiciel TRS pour mesurer les pertes. Les deux sont vendus comme le remède aux arrêts, et les deux tombent sur la même ligne budgétaire.

Ce guide s'adresse aux directeurs d'usine, aux responsables amélioration continue et aux responsables méthodes qui doivent trancher : à quoi sert chaque outil, quand chacun passe en premier, comment ils partagent leurs données et ce qu'une intervention lente coûte en disponibilité.

Nous vendons Fabrico, une plateforme cloud de TRS (OEE) et de MES léger : lisez donc ce guide comme le point de vue d'un éditeur, et vérifiez nos affirmations comme celles de n'importe quel éditeur.

Système andon ou logiciel TRS : deux missions différentes

Un andon est un appel à l'aide. Toyota le décrit simplement : « Lorsqu'un équipement s'arrête, l'andon (tableau d'affichage des problèmes) s'allume pour signaler l'anomalie aux opérateurs » (Toyota Production System, EN, traduction libre). Le Lean Enterprise Institute ajoute le point qui compte pour l'acheteur : « Le numéro allumé appelle une réponse rapide du chef d'équipe » (lexique du LEI, andon, EN, traduction libre). Toute la valeur de l'andon se joue dans les minutes qui suivent l'apparition d'un problème.

Le logiciel TRS travaille sur une horloge plus longue. Il enregistre quand la ligne a tourné, quand elle s'est arrêtée et pourquoi, et combien de pièces bonnes sont sorties, puis il classe les pertes par ligne, par poste et par cause. Sa valeur apparaît au fil des semaines de données, lors de la revue des pertes.

Les deux ne sont donc pas concurrents. L'un raccourcit l'arrêt en cours. L'autre vous dit quels arrêts éliminer pour de bon. Le choix porte sur l'ordre, pas sur un gagnant.

Pour aller plus loin sur chacun, consultez nos pages associées : les systèmes andon en production explique le fonctionnement d'un andon, et logiciel TRS (OEE) détaille ce qu'il faut attendre d'un outil de mesure.

Andon d'abord, logiciel TRS d'abord, ou les deux

Choisissez d'abord un système andon si :

• Les opérateurs disent attendre un mécanicien, un contrôle qualité ou de la matière, et personne ne sait dire combien de temps.
• Les problèmes de sécurité ou de qualité exigent quelqu'un sur la ligne en quelques minutes, pas à la prochaine réunion.
• Vous connaissez déjà vos principales pertes, et la lenteur des interventions en fait partie.

Choisissez d'abord un logiciel TRS si :

• Vous ne savez pas classer vos pertes, ou chaque service les classe différemment.
• Les arrêts sont notés sur papier, en retard ou pas du tout, et une grande partie n'a pas de motif.
• Vous prévoyez des chantiers d'amélioration et avez besoin d'une situation de référence pour les évaluer.
• L'essentiel du temps d'arrêt vient de longues pannes ou de changements de format, pas de l'attente d'aide.

Faites les deux si :

• Les attentes sont longues et vous manquez aussi de données de pertes. Faites alors écrire les deux outils dans un seul registre des arrêts, pour qu'un appel et un arrêt soient le même événement, et non deux enregistrements qui ne se croisent jamais.
• Vous utilisez déjà un andon sans aucune mesure derrière. Ajoutez un logiciel TRS et enregistrez le temps de réponse comme une ventilation à l'intérieur de l'enregistrement de l'arrêt.

Une règle simple : si vous pouvez citer, chiffres à l'appui, vos trois principales pertes, le manque se situe probablement dans la réponse. Sinon, commencez par mesurer. Les chiffres vous diront si un circuit d'appel plus rapide en vaut la peine.

Vous voulez voir données d'arrêt, motifs et alertes fonctionner ensemble ? Demandez une démo et apportez la liste de vos postes de travail.

Comment l'andon et le logiciel TRS partagent leurs données

Un appel andon et un arrêt TRS sont souvent le même événement vu de deux côtés. L'andon voit « aide demandée au poste 4, mécanicien ». L'enregistrement TRS voit « ligne arrêtée 14 minutes, motif : bourrage ». Reliez-les et vous obtenez ce qu'aucun des deux n'a seul : combien de ces 14 minutes étaient de l'attente, et combien de la réparation.

La méthode TRS (OEE) de R.C. Hansen trace la même frontière. Le temps de réparation court à partir de l'arrivée du mécanicien. Le temps de remise en service court de la fin de la production jusqu'à la reprise de la production, et inclut la décision, l'appel et le déplacement. La disponibilité compte la totalité du temps de remise en service : l'attente y est donc déjà incluse.

Trois règles gardent les données partagées fiables :

• Pas de double comptage. L'attente d'aide n'est pas une nouvelle catégorie de perte. C'est une ventilation à l'intérieur de l'arrêt, sous la même cause. Ajoutez-la une seconde fois par-dessus et vos pertes dépassent 100 %.
• Les mêmes mots dans les deux listes. Si les types d'appel andon et les motifs d'arrêt portent les mêmes noms, vous les reliez sans table de correspondance.
• Une seule horloge. Les deux systèmes doivent utiliser la même source de temps, pour qu'un appel à 10 h 02 et un arrêt à 10 h 02 coïncident.

La recherche sur les systèmes lean intelligents traite l'andon comme un élément d'un flux de données plus large. Un article paru dans la revue Sensors décrit une architecture où « les opérateurs peuvent déclencher manuellement différents types de boutons SLAE-ABOX selon l'anomalie du poste, afin d'exécuter les fonctions Andon correspondantes », avec des appels équipe, qualité et équipement comme types distincts (Ma, Wang et Zhao, Sensors, 2017, EN, traduction libre). Ce sont ces appels typés qui facilitent le rapprochement avec les motifs d'arrêt.

Notre guide associé sur l'andon digital intégré aux plateformes MES et TRS détaille la traçabilité des données, et la matrice d'escalade des arrêts précise qui est appelé et quand. Cette page s'en tient à l'ordre d'achat.

Ce qu'une intervention lente coûte en disponibilité : exemple chiffré

Voici un poste sur une ligne, avec des chiffres choisis pour montrer le calcul. Exemple illustratif, données fictives.

• Poste de 480 minutes avec une pause de 30 minutes et sans équipe de relève. La pause est exclue : le temps de production planifié est donc de 450 minutes.
• Un changement de format planifié de 30 minutes.
• 10 arrêts qui demandent une intervention. Chacun attend la bonne personne pendant 6 minutes, puis demande 8 minutes de réparation.
• Cadence idéale de 60 unités par minute. Performance de 85 % et qualité de 98 %, identiques dans les deux cas.

Avant. Le temps d'arrêt est de 10 x (6 + 8) = 140 minutes. Le temps de marche est de 450 moins 30 moins 140, soit 280 minutes. La disponibilité est de 280 / 450 = 62,2 %. Le TRS est de 0,622 x 0,85 x 0,98 = 51,8 %.

Après un circuit d'appel plus rapide. L'attente tombe à 2 minutes par arrêt et la réparation reste à 8. Le temps d'arrêt est de 10 x (2 + 8) = 100 minutes. Le temps de marche est de 320 minutes. La disponibilité est de 320 / 450 = 71,1 %. Le TRS est de 0,711 x 0,85 x 0,98 = 59,2 %.

Vérifiez-le d'une deuxième façon, à partir des pièces bonnes. Avant : 280 x 60 x 0,85 x 0,98 = 13 994 pièces bonnes. À la cadence idéale, cela représente 233,2 minutes de production parfaite, et 233,2 / 450 = 51,8 %, soit le même TRS. Après : 15 994 pièces bonnes, environ 2 000 de plus par poste avec la même machine et les mêmes réparations.

Les pertes et le TRS doivent totaliser 100 %. Dans le cas « avant », c'est bien le cas :

51,8 + 6,7 + 13,3 + 17,8 + 9,3 + 1,1 = 100,0 %. L'attente représente 60 des 140 minutes d'arrêt : ici, 43 % du temps d'arrêt est de l'attente, pas de la réparation. C'est ce chiffre que l'andon attaque et qu'un outil TRS peut montrer. Pour la méthode complète, consultez notre page sur le calcul du TRS (OEE).

Deux mises en garde. Les unités supplémentaires ne deviennent de l'argent que si cette ligne est le goulot et que vous pouvez vendre la production : valorisez donc les minutes au goulot. Et votre propre répartition peut être différente : si l'attente pèse peu et que le problème est la réparation, un circuit d'appel plus rapide aide peu.

Mesurez d'abord votre part d'attente. Avant d'acheter l'un ou l'autre, notez pendant une semaine l'heure d'appel et l'heure d'arrivée pour les arrêts qui demandent une intervention, même sur papier. En règle empirique, pas comme référence : si l'attente dépasse environ un tiers du temps d'arrêt, le circuit d'appel est votre premier levier. Si elle est faible, commencez par les données de pertes.

Checklist : huit questions à poser avant d'acheter l'un ou l'autre

Posez-les à tout éditeur, et à votre propre équipe. Elles valent pour les outils andon, les logiciels TRS et les plateformes qui affirment faire les deux.

1. Un enregistrement d'arrêt conserve-t-il l'attente et la réparation comme des durées distinctes, sous une seule cause ?
2. Les types d'appel andon et les motifs d'arrêt peuvent-ils partager une seule liste ?
3. Qui reçoit une alerte, par quel canal, et que se passe-t-il si personne ne répond ?
4. D'où vient le signal d'arrêt : de la machine, d'un capteur, d'une personne ou d'un comptage par caméra ?
5. Comment un opérateur saisit-il un motif, et combien d'appuis cela demande-t-il sur la ligne ?
6. Pouvez-vous voir le temps de réponse par poste, par ligne et par type d'appel, et pas seulement une moyenne ?
7. Comment les données sortent-elles du système : API, webhooks, export de fichiers ?
8. Qui, chez nous, est responsable de la réponse à un appel, et qui pilote la revue hebdomadaire des pertes ?

La dernière question s'adresse à votre équipe. Un andon auquel personne ne répond apprend aux gens à ne plus le déclencher. Un rapport TRS que personne ne revoit devient un simple écran au mur.

Si vous comparez des produits, nos guides d'achat vont plus loin : logiciels d'andon digital, logiciels TRS (OEE) comparés, logiciels de suivi machine et logiciels de management quotidien.

La place de Fabrico

Fabrico est un logiciel TRS (OEE) et MES léger. Voici ce qu'il fait aujourd'hui, et ce qu'il ne fait pas.

• Arrêts et comptages proviennent de l'automate (PLC) de la ligne, ou d'un boîtier IoT Fabrico avec capteurs externes sur les machines plus anciennes. L'opérateur saisit le motif d'arrêt sur une tablette ou un téléphone.
• Les pertes s'affichent par cause d'arrêt et en valeur financière : la revue hebdomadaire part donc de la perte la plus lourde.
• Alertes : la présentation du produit mentionne des notifications push, in-app et par e-mail, avec des règles qui définissent qui est prévenu de quoi.
• Sortie des données : une API REST, des webhooks et un export Excel ou CSV, pour que les données d'arrêt puissent cohabiter avec un andon que vous utilisez déjà.
• Module caméra : des caméras IA (en option) comptent la production aux postes manuels ou sur les machines sans signal exploitable. La vidéo est diffusée à la demande, sans être stockée dans la configuration standard. Voir le module de vision par ordinateur.

Si vous avez besoin de colonnes lumineuses, de boutons d'appel ou de niveaux d'escalade, demandez pendant la démo comment les alertes et les appels andon sont gérés, et testez-le sur un appel réel. La détection des arrêts par caméra est sur la feuille de route : ce n'est pas une fonctionnalité actuelle.

Si votre plan est de mesurer d'abord et d'ajouter plus tard un circuit d'appel plus rapide, notre page sur le MES léger montre comment les éléments s'articulent dans un seul système. Pour les lignes de produits de grande consommation (PGC) avec conditionnement manuel, consultez la vision par ordinateur pour l'industrie des PGC.

Les questions que posent ensuite les acheteurs

Un logiciel TRS peut-il remplacer un système andon ?

Pas à lui seul. Le logiciel TRS vous dit après coup où le temps est passé. Un andon amène la bonne personne sur la ligne maintenant. Certains outils TRS et MES légers envoient des alertes quand une ligne s'arrête, ce qui couvre une partie du rôle de l'andon. Vérifiez que l'alerte atteint assez vite une personne nommément désignée, et que quelqu'un est responsable de la réponse.

Le temps de réponse fait-il partie de la disponibilité du TRS ?

Oui. L'attente d'aide a lieu pendant que la ligne est arrêtée : elle fait donc partie du temps d'arrêt de cet arrêt. Suivez-la comme une ventilation de l'arrêt, entre attente et réparation, et non comme une perte distincte. Si vous l'ajoutez une seconde fois par-dessus, vous comptez deux fois les mêmes minutes.

Les appels andon et les motifs d'arrêt TRS doivent-ils utiliser la même liste ?

Utilisez une seule liste quand c'est possible. Si le type d'appel andon est mécanicien, qualité ou matière, et que la liste des motifs d'arrêt utilise les mêmes mots, les deux jeux de données se relient sans table de correspondance. Gardez la liste andon courte, car les opérateurs y choisissent sous pression.

Lequel est rentabilisé le plus vite ?

Cela dépend de l'endroit où partent vos minutes. Si les longues attentes pèsent lourd dans le temps d'arrêt, un circuit d'appel plus rapide libère vite du temps. Si vous ne savez pas où partent les minutes, le logiciel TRS passe en premier, car on ne peut pas classer ce que l'on ne mesure pas. Faites le calcul avec vos propres données de poste, pas avec une moyenne d'éditeur.

Comment Fabrico gère-t-il les appels andon et les alertes ?

La présentation du produit Fabrico mentionne des notifications push, in-app et par e-mail, avec des règles qui définissent qui est prévenu de quoi. Si vous avez besoin de colonnes lumineuses, de boutons d'appel ou de niveaux d'escalade, demandez pendant la démo comment les alertes et les appels andon sont gérés, et testez-le sur un appel réel.

Faut-il du nouveau matériel pour l'un ou l'autre ?

Pas toujours. Un andon de base peut être un bouton ou un écran de tablette. Le logiciel TRS a besoin d'un signal de marche et d'un comptage venant de la machine, via un automate (PLC), un capteur ou un compteur. Aux postes manuels, une personne ou un comptage par caméra peut combler le manque.

Vous voulez voir arrêts, motifs et alertes sur une ligne comme la vôtre ? Demandez une démo.