Une preuve de concept (POC) pour un logiciel OEE a un seul objectif: réduire le risque que le système que vous achetez ne fonctionne pas comme le fournisseur l'a promis dans votre environnement de production spécifique.
Un POC bien conçu répond aux trois questions auxquelles les réponses aux appels d'offres et les démonstrations ne peuvent répondre: le logiciel collecte-t-il les données avec précision depuis vos machines et vos automates programmables industriels (API) spécifiques ?
Calcule-t-il l'OEE d'une manière qui correspond à la compréhension de la performance par votre équipe de production ? Et vos opérateurs peuvent-ils l'utiliser sans un support intensif et permanent ?
L'erreur la plus courante lors d'un POC est de le rendre trop étendu.
Les fabricants qui tentent de piloter un logiciel OEE sur plusieurs lignes, plusieurs équipes et plusieurs types de produits dans une fenêtre de 30 jours obtiennent des résultats non concluants, trop de variables, trop de travail d'installation et pas assez de temps pour atteindre une qualité de données stable.
Un POC ciblé sur 1 à 3 lignes de production, couvrant 2 à 3 semaines de production stable après une période de mise en place d'une semaine, fournit des preuves plus fiables qu'un pilote tentaculaire qui n'atteint jamais un état stable.
Définissez la portée du POC par écrit avant son lancement. Le document de portée devrait préciser: quelles lignes sont concernées quelle méthode de collecte des données sera utilisée (intégration API, retrofit de capteurs ou solution manuelle de secours) quel volume de production et quel mix de produits sont attendus pendant la période du POC
quelles intégrations ERP et GMAO seront actives durant le POC (le cas échéant) et quel support fournisseur est garanti pendant la fenêtre du POC. Un fournisseur qui refuse de s'engager sur un document de portée écrit avant le démarrage du POC est susceptible de redéfinir la portée après sa conclusion.
La mesure du POC doit couvrir quatre dimensions: la précision de la collecte des données, la fiabilité du calcul de l'OEE, l'adoption par les opérateurs et les performances du système.
La précision de la collecte des données est la plus importante: comparez les relevés de la plateforme OEE à vos sources de données existantes (compteurs de production, journaux de poste, système SCADA) pour les mêmes quarts de travail.
Une divergence de plus de 2-3 % dans les comptages de production ou de plus de 5 minutes par quart dans la durée des arrêts suggère un problème de configuration de la collecte des données qui compromettra la confiance dans les données OEE après le déploiement complet.
La fiabilité du calcul de l'OEE s'évalue en rapprochant les scores OEE de la plateforme avec des calculs manuels effectués sur les mêmes données brutes. Choisissez 5-10 quarts de travail répartis sur la période du POC, extrayez les données brutes, calculez l'OEE manuellement et comparez au résultat de la plateforme.
Les différences doivent pouvoir s'expliquer par des choix de méthodologie documentés (la façon dont les arrêts planifiés sont traités, la manière dont les micro-arrêts sont classés), des écarts inexpliqués indiquent un problème de logique de calcul dans la plateforme qui provoquera des problèmes de crédibilité persistants auprès des responsables de production qui connaissent bien leurs lignes.
La mesure de l'adoption par les opérateurs durant un POC de 30 jours se concentre sur la conformité à la catégorisation des arrêts: quel pourcentage des événements d'arrêt a été catégorisé par les opérateurs (plutôt que laissés "non catégorisés"), et combien de temps après les événements la catégorisation a-t-elle eu lieu ?
Un objectif de plus de 80 % de taux de catégorisation dans les 2 heures suivant l'événement est un repère raisonnable pour le POC. En dessous de cela, le système produira des analyses de Pareto dominées par les arrêts "non catégorisés", ce qui va à l'encontre de l'objectif principal du logiciel.
Si les taux de catégorisation sont faibles pendant le POC, diagnostiquez si la cause est la complexité de l'interface opérateur, une formation insuffisante ou une liste de causes d'arrêt inadaptée, et testez si le fournisseur peut résoudre la cause profonde pendant la fenêtre du POC.
La décision d'autoriser ou d'arrêter (go/no‑go) pour un POC d'un logiciel OEE doit reposer sur des critères prédéfinis convenus avant le démarrage du POC, et non sur une évaluation a posteriori de la qualité de la relation avec le fournisseur.
Définissez les critères de validation comme des seuils mesurables: précision de la collecte des données dans ±3 % de la valeur réelle pour plus de 90 % des quarts taux de catégorisation des arrêts opérateur supérieur à 75 % au moins un transfert de données vers l'ERP effectué avec succès (si dans le périmètre)
aucun événement de perte de données pendant la production normale et disponibilité du système (taux de disponibilité) supérieure à 99 %.
La décision de refus (no‑go) doit également être explicite. Si la précision de la collecte des données est insuffisante sur plus de 20 % des quarts, ou si le système nécessite plus de 2 heures d'assistance du fournisseur par semaine pour maintenir un fonctionnement stable
ou si les opérateurs évitent délibérément d'utiliser le système malgré la formation, ce sont des signes que la plateforme présente un problème d'adéquation fondamental avec votre environnement qu'un déploiement prolongé est peu susceptible de résoudre.
Entre un go clair et un no‑go net, la plupart des POC aboutissent à une « validation sous conditions », le système fonctionne de manière acceptable mais des problèmes spécifiques doivent être résolus avant le déploiement complet.
Documentez ces conditions de manière explicite dans le rapport de conclusion du POC: quels problèmes ont été identifiés, ce que le fournisseur s'est engagé à faire à leur sujet, et à quelle date.
Transformer ces conditions en engagements contractuels dans l'accord d'achat fait passer la validation conditionnelle à une décision protégée, si les conditions ne sont pas remplies, vous disposez de motifs de remédiation ou de sortie.
Sans cette documentation, les problèmes conditionnels ont tendance à perdurer après l'achat parce que l'urgence du fournisseur à les résoudre disparaît une fois le contrat signé.
Connexion
Blog
