Chaque démo fournisseur montre un tableau de bord avec une jauge de TRS. C’est la partie facile. Les parties difficiles sont en amont et en aval du tableau de bord : obtenir un vrai signal d’arrêt et de comptage sur une presse de 1998 et une ligne de conditionnement de 2024 avec le même produit, obtenir des opérateurs qu’ils classent les arrêts dans les 15 secondes qui précèdent un redémarrage, et obtenir de la production et de la maintenance qu’elles agissent sur le Pareto chaque semaine. Un système qui échoue sur l’un des trois produit un bel écran et aucune amélioration du TRS. Ce guide est organisé autour de ces trois points de défaillance, et la grille note les fournisseurs dessus.
Ce que vous recevez
- Le guide d’achat (PDF, 5 pages) : les cinq catégories de solutions et où chacune échoue (manuel, historian, module MES, suivi de production dédié, plateforme IIoT), faire ou acheter tranché honnêtement, les 10 domaines d’exigences et leurs pondérations par défaut, les quatre méthodes de capture des données et leurs compromis, les modèles de tarification et le TCO 3 ans, un processus d’évaluation en sept étapes, neuf signaux d’alerte, et à quoi ressemble un déploiement qui marche.
- La grille RFP (Excel) : 51 exigences en 10 catégories, chacune avec une priorité indispensable / important / souhaitable, une méthode « comment vérifier » et une note de 0 à 5 pour jusqu’à 3 fournisseurs ; une feuille Pondérations ; une Synthèse avec scores par catégorie, score global pondéré, échecs sur indispensables, exclusion, rang et graphique ; une feuille TCO 3 ans par fournisseur avec coût par machine ; un Plan pilote avec 7 critères de succès à coller dans la proposition du fournisseur ; et un script d’appel aux références.
Les 10 domaines d’exigences et ce que protègent les indispensables
| Domaine | Poids par défaut | Indispensables |
|---|---|---|
| Capture des données et connectivité | 20 % | Arrêts et comptages sans modification automate, résolution à la seconde, aucune perte en cas de coupure réseau |
| Indicateurs et analyses | 15 % | Votre modèle de temps, pas celui du fournisseur ; descente du Pareto aux événements |
| Expérience opérateur | 15 % | Saisie de la cause en moins de 15 secondes à la machine |
| Arrêts et codes d’arrêt | 10 % | Arbre à 3 niveaux configurable avec attributs planifié / non planifié et six grandes pertes |
| Intégration et API | 10 % | API ouverte et documentée |
| Déploiement, sécurité, informatique | 10 % | Architecture réseau sortante uniquement ; vous possédez les données |
| Alertes et workflows | 5 % | |
| Fournisseur et services | 5 % | Références contactables ; un pilote avec critères de succès écrits |
| Tarification et TCO | 5 % | Total 3 ans par écrit |
| Passage à l’échelle et multi-sites | 5 % |
Quinze exigences sont marquées « indispensable ». Un fournisseur noté 0 ou 1 sur l’une d’elles est exclu quel que soit le total pondéré. Cela empêche une couche d’analyse soignée de compenser une méthode de capture qui ne fonctionnera pas sur un tiers de vos machines.
Le processus d’évaluation qui fonctionne
- Inventaire des machines et contraintes de capture (1 semaine) : âge, automate, accès automate, changements de série.
- Exigences et pondérations (1 semaine) : grille adaptée, indispensables confirmés avec production, maintenance et informatique.
- Liste longue vers liste courte sur documents (2 semaines) : documentation API et architecture sécurité lues avant toute démo.
- Démo scénarisée sur vos données (1 semaine) : votre modèle de temps, votre arbre de codes, une coupure réseau, une descente dans le Pareto.
- Pilote sur 2 à 3 machines (4 à 6 semaines) : noté sur les 7 critères de succès.
- Appels références et TCO (1 semaine) : deux références par finaliste, feuille TCO remplie.
- Décision et plan de déploiement (1 semaine) : machines par mois, un arbre, une définition des indicateurs.
À qui s’adresse ce pack
Aux directeurs d’usine et des opérations qui lancent une sélection de logiciel TRS ou de suivi machine, aux responsables amélioration continue et méthodes qui rédigent les exigences, et aux équipes IT / OT qui veulent que les questions de sécurité et d’intégration soient posées avant le contrat. Il complète notre page TRG : définition, calcul et différence avec le TRS et le modèle de suivi des arrêts.
Téléchargez le guide et la grille
Remplissez le formulaire et les deux fichiers vous sont envoyés par e-mail.
POC Gratuit
Une note sur la neutralité
La grille est écrite pour être juste avec les cinq catégories de solutions : un module MES ou une plateforme IIoT qui satisfait les indispensables sur la capture et l’expérience opérateur est noté comme n’importe quelle autre solution. TEEPTRAK est un système de suivi de production dédié avec une capture par capteur qui fonctionne sans modification automate, et nous acceptons volontiers d’être notés sur les mêmes 51 lignes. Sur les 450+ usines que nous avons équipées, le schéma d’un déploiement réussi est constant : capture validée sur chaque type de machine dans les deux premières semaines, opérateurs classant les arrêts dès la troisième semaine, première revue de Pareto avant la fin du pilote. Un cas documenté, Hutchinson, a fait passer son TRS de 47 % à 72 % une fois les pertes visibles et traitées dans l’ordre.
À lire aussi : les critères pour choisir un logiciel de suivi TRS et TRS, TRG, TRE : quel indicateur piloter.
Questions fréquentes
Que doit contenir un cahier des charges pour un logiciel de suivi de production ou de TRS ?
Dix domaines d’exigences : capture des données et connectivité, indicateurs et analyses, expérience opérateur, arrêts et codes d’arrêt, alertes et workflows, intégration et API, déploiement et sécurité, fournisseur et services, tarification et TCO, passage à l’échelle et multi-sites. La grille livre 51 exigences réparties dessus, chacune avec une priorité, une méthode de vérification et une note de 0 à 5 par fournisseur.
Comment le score pondéré est-il calculé ?
Chaque exigence a un poids de priorité (indispensable 3, important 2, souhaitable 1) et une note fournisseur de 0 à 5. Le score de catégorie est la somme pondérée divisée par le maximum pondéré ; le score global applique vos poids de catégorie (par défaut : capture 20 %, indicateurs 15 %, expérience opérateur 15 %, codes d’arrêt 10 %, intégration 10 %, sécurité 10 %, le reste 5 % chacun). Un indispensable noté 0 ou 1 exclut le fournisseur quel que soit le total.
Combien de temps doit durer un pilote et quels sont les critères de succès ?
Quatre à six semaines sur 2 à 3 machines, dont une machine ancienne sans accès automate. Sept critères : détection des arrêts au-dessus de 98 % vs observation, comptage à 2 % près du manuel, plus de 90 % des arrêts classés par les opérateurs dans l’équipe, TRS à la main à 1 point près du système, revue de Pareto tenue en semaine 3 avec deux actions lancées, saisie de la cause en moins de 15 secondes, revue sécurité IT et OT close.
Faut-il développer son propre tableau de bord TRS plutôt qu’acheter ?
Développer quand toutes les machines exposent des données, que vous avez une équipe logicielle interne et que le périmètre est des tableaux de bord, pas l’interaction opérateur. Acheter quand le parc est hétérogène, que les opérateurs doivent classer les arrêts à la machine et que plusieurs usines ont besoin d’une définition unique. La réponse la plus fréquente est hybride : acheter la couche capture et opérateur, garder la BI et l’intégration ERP en interne via une API ouverte. Le guide contient une section pour estimer honnêtement l’option développement.
0 commentaires