Points clés
Un pilote OEE doit répondre à une seule question : cela fonctionnera-t-il ici ? Trop de pilotes échouent, non pas parce que le logiciel est mauvais, mais parce que personne n'a défini à quoi ressemblait le succès. Définissez cela dès le départ et le pilote vous donnera un oui ou un non clair.
Décidez à l'avance ce que le pilote doit prouver : capturer automatiquement des données fiables, mettre en évidence des pertes que l'équipe ne voyait pas, ou générer une amélioration mesurable sur la ligne. Écrivez ces critères de réussite avant la mise en service, afin que le résultat soit un fait, pas un débat.
Choisissez une seule ligne qui reflète vos conditions réelles, de préférence une qui présente des pertes significatives à identifier, pas la meilleure ni la pire. Un pilote représentatif vous dira ce qu'un déploiement plus large livrera réellement.
Enregistrez la performance actuelle de la ligne avant le pilote, afin de pouvoir démontrer le changement. Fixez une période claire, assez longue pour capter les véritables tendances mais assez courte pour conserver l'élan. Un pilote sans durée déraille ; un pilote limité rend un verdict.
Le pilote vit ou meurt selon l'engagement des opérateurs et des superviseurs. Impliquez-les dans la configuration, expliquez l'utilité des données, et précisez qu'il s'agit d'un outil pour identifier les pertes, pas pour contrôler le personnel. L'adhésion fait la différence entre des données riches issues du pilote et un écran ignoré.
Une usine pilote l'OEE sur une ligne représentative, fixe une fenêtre de quatre semaines, établit la disponibilité actuelle comme référence, et définit le succès comme la capture des micro-arrêts que l'équipe ne peut pas actuellement voir et l'action sur le principal d'entre eux.
Dès la deuxième semaine, la capture automatisée révèle un court arrêt récurrent que personne n'avait consigné; le corriger fait monter la performance de la ligne. Le succès était évident parce qu'il avait été défini dès le premier jour.
Un pilote est la façon la plus sûre de prouver que l'OEE en temps réel apportera un retour avant un engagement à l'échelle de l'usine. Des critères clairs transforment un essai en preuve. Réservez une démo Fabrico pour définir le périmètre d'un pilote OEE ciblé sur l'une de vos lignes.
Bien concevoir la conception d'un pilote de logiciel de fabrication détermine si un déploiement réussit.
Assez longtemps pour capter de véritables schémas de production, souvent quelques semaines, mais avec une durée limitée pour rester concentré. Un pilote sans limite perd son élan et n'aboutit jamais à un verdict.
Absence de critères de réussite définis et faible adoption. Si personne n'a convenu de ce que signifie le succès, ou si l'équipe ne s'engage pas, même de bonnes données ne mènent nulle part.
Les pilotes de logiciels OEE sans critères de réussite préalablement définis aboutissent presque toujours à des conclusions ambiguës.
Le fournisseur est satisfait parce que rien n'a échoué de façon catastrophique; l'équipe informatique est sceptique parce que l'intégration a pris plus de temps que prévu; le responsable de production est prudemment optimiste parce que les données ont l'air à peu près correctes; et le directeur d'usine n'est pas sûr que les chiffres justifient l'achat.
Sans accord sur ce à quoi ressemble le succès avant le lancement du pilote, chaque partie prenante évalue le pilote à travers le prisme de ses propres préoccupations, et la discussion post-pilote devient un débat sur la question de savoir si les préoccupations ont été suffisamment traitées plutôt qu'une évaluation objective de la conformité aux critères.
Des critères de réussite préalablement définis transforment la conversation post-pilote d'une approche subjective à une approche objective.
Lorsque l'équipe d'évaluation a convenu avant le pilote que « le succès exige une précision de collecte des données supérieure à 95 % pour au moins 80 % des postes surveillés », la discussion post-pilote porte sur la question de savoir si ce seuil a été atteint
et non sur la question de savoir si une précision de 93 % est suffisante.
Cette précision met mal à l'aise les fournisseurs qui préfèrent des critères plus vagues, ce qui est en soi révélateur: les fournisseurs qui s'opposent à des critères de réussite précis sont moins confiants dans leur capacité à les atteindre que ceux qui participent constructivement à la définition de seuils mesurables.
Le processus de définition des critères de réussite impose aussi un alignement organisationnel avant le démarrage du pilote.
Les différentes parties prenantes ont des définitions du succès différentes, l'informatique veut la conformité en matière de sécurité, les opérations veulent la précision des données, la finance veut des preuves de ROI, et le directeur d'usine veut l'adoption par les opérateurs.
Faire apparaître ces différentes définitions avant le pilote et les concilier dans un document de critères partagé garantit que le pilote génère des preuves sur toutes les dimensions des parties prenantes, pas seulement sur celles que le responsable de l'équipe d'évaluation juge les plus importantes.
Catégorie 1, Précision de la collecte des données: Définissez l'écart acceptable entre les relevés de la plateforme OEE et vos sources de données existantes (compteurs de production, registres de poste) pour les comptes de production, la durée des arrêts et les comptes de rebut qualité.
Un seuil de départ raisonnable est ±3 % pour les comptes de production et ±5 minutes par poste pour la durée des arrêts. Précisez combien de postes doivent respecter ce seuil (par ex., 85 % des postes sur la période pilote) et ce qui constitue une défaillance de collecte des données nécessitant une enquête.
Catégorie 2, Adoption par les opérateurs: Définissez le taux minimal de catégorisation des arrêts (pourcentage d'événements d'arrêt catégorisés par les opérateurs dans une fenêtre temporelle définie) qui indique que l'interface opérateur est fonctionnelle. Un seuil pratique de départ est une catégorisation de 75 % ou plus dans les 2 heures.
Précisez également l'investissement de formation acceptable: si les opérateurs nécessitent plus de 4 heures de formation initiale pour utiliser correctement le système, cela constitue un signal d'utilisabilité à documenter comme échec du critère, même si les taux de catégorisation sont atteints.
Catégorie 3, Fiabilité de l'intégration: Si l'intégration ERP ou GMAO (CMMS) est incluse dans le périmètre du pilote, définissez le taux de succès requis pour les transferts de données.
Le minimum acceptable est que 99 % des confirmations d'ordres de production soient transférées correctement dans le SLA défini (par ex., dans les 15 minutes suivant la fin du poste). Précisez comment les échecs d'intégration sont détectés et signalés, et quel est l'engagement de délai de réponse du fournisseur en cas d'échec d'intégration.
Catégorie 4, Performance du système: Définissez la latence maximale acceptable pour que les données de production apparaissent dans le tableau de bord OEE après un événement réel (2 minutes maximum est typique), et la disponibilité minimale du système pendant les heures de production prévues (minimum 99,5 %).
Précisez comment les temps d'arrêt sont mesurés, depuis le système de supervision du fournisseur ou depuis des horodatages vérifiés de manière indépendante, afin d'éviter les litiges sur la satisfaction des critères.
Catégorie 5, Utilisabilité des rapports et des analyses: Définissez les rapports spécifiques qui doivent être générés avec succès pendant le pilote sans assistance du fournisseur, par exemple, un Pareto des temps d'arrêt sur 30 jours par équipement, une tendance OEE semaine après semaine par ligne, et une comparaison de performance par poste.
Si l'équipe d'évaluation ne peut pas générer ces rapports de manière autonome d'ici la semaine 3 du pilote, cela indique un problème d'utilisabilité ou de configuration qui doit être résolu avant le déploiement complet.
Catégorie 6, Preuves de ROI: Pour les pilotes d'une durée suffisante, définissez quelles améliorations de la performance de production on s'attend à voir dans les données OEE grâce à la visibilité apportée par le logiciel de supervision.
Ce critère est plus difficile à spécifier rigoureusement dans un pilote de 30 jours (l'attribution causale est délicate), mais même des preuves qualitatives, actions d'amélioration spécifiques entreprises sur la base des insights OEE et qui n'auraient pas été prises sans ces données, peuvent être documentées et incluses dans la recommandation go/no-go.
Le processus de validation (go/no-go) d'un pilote OEE doit impliquer les mêmes parties prenantes qui ont défini les critères de réussite, pas seulement le responsable de l'équipe d'évaluation.
Planifiez la réunion de revue post-pilote avant le début du pilote, et exigez que chaque partie prenante apporte une évaluation écrite des critères relevant de son domaine (l'informatique évalue les critères de sécurité et d'intégration les opérations évaluent l'exactitude des données et l'adoption par les opérateurs
la finance évalue les coûts et les éléments probants du retour sur investissement). Cet engagement préalable à fournir des évaluations écrites empêche les parties prenantes d'assister à la réunion de revue sans avoir réalisé le travail d'évaluation.
L'ordre du jour de la réunion post-pilote doit couvrir: les résultats de l'évaluation des critères (go/no-go pour chaque critère et la base de preuves) les points ouverts (critères non entièrement satisfaits, avec les engagements du fournisseur et les calendriers de résolution)
l'évaluation de la performance du fournisseur (qualité de la mise en œuvre, réactivité et qualité du support pendant le pilote) et une recommandation.
La recommandation doit être l'un des trois résultats suivants: go (tous les critères remplis, procéder au déploiement complet); go avec conditions (la plupart des critères remplis, des questions spécifiques nécessitent une résolution contractuelle avant l'engagement de déploiement complet); ou no-go (critères critiques non satisfaits, soit changement de fournisseur requis soit remise à plat fondamentale des exigences).
Documentez la décision post-pilote et la base de preuves dans un rapport de conclusion du pilote écrit, partagé avec toutes les parties prenantes et conservé dans le dossier du projet.
Cette documentation protège l'équipe d'évaluation si le déploiement rencontre des problèmes ultérieurement, elle démontre que la décision a été prise sur la base de critères objectifs et de preuves documentées, et non sur des relations avec le fournisseur ou une évaluation incomplète.
Elle fournit également au fournisseur un brief clair sur ce qui doit être amélioré avant ou pendant le déploiement complet, ce qui augmente la probabilité de succès du déploiement complet.
Connexion
Blog
