Les démonstrations de logiciels OEE sont des expériences scénarisées. Les fournisseurs montrent leur plateforme sous son meilleur jour, avec des données propres préchargées, des scénarios de production idéaux et des environnements de démonstration où chaque fonctionnalité fonctionne parfaitement.
Ce qu'ils ne montrent pas, ce sont la façon dont le système gère les conditions réelles et chaotiques: l'opérateur qui oublie de clôturer un événement d'arrêt, l'automate programmable industriel (API) qui envoie des signaux d'état ambigus
la série de production qui chevauche un changement d'équipe, ou le rapport qui nécessite de combiner des données provenant de trois lignes différentes ayant des structures de produit distinctes.
L'écart entre les performances montrées en démonstration et les performances réelles est la source la plus fréquente de regrets chez les acheteurs de logiciels OEE.
Les industriels qui achètent sur la foi de démonstrations soignées sans tester les cas limites découvrent souvent après la mise en œuvre que le système traite leurs scénarios de production spécifiques différemment de ce que la démo laissait entendre.
Pour réduire cet écart, apportez vos propres scénarios aux démonstrations, exigez que les fournisseurs montrent comment leur système gère les cas limites et les flux de travail spécifiques à votre usine, et non les cas idéaux pour lesquels leur environnement de démonstration est conçu.
Structurer votre évaluation des démonstrations autour d'une liste de contrôle fixe de scénarios rend également la comparaison des fournisseurs plus fiable.
Si chaque fournisseur démontre les mêmes 25 scénarios, vous pouvez comparer leurs approches côte à côte plutôt que de comparer la fonctionnalité « gestion des arrêts » d'un fournisseur à la fonction « analyse des pertes » d'un autre, présentée avec des données et des flux de travail différents.
La liste de contrôle impose une cohérence de comparaison qui, autrement, exigerait des évaluateurs expérimentés qu'ils la maintiennent manuellement sur plusieurs sessions.
Scénarios de collecte de données: (1) Montrer comment un changement d'état de machine est capturé sans action de l'opérateur, démontrer la chaîne du signal PLC vers l'état OEE en temps réel.
(2) Montrer ce qui se passe lorsqu'un signal PLC est ambigu ou qu'un capteur se déconnecte brièvement, comment le système gère-t-il les lacunes de données ? (3) Démontrer qu'un opérateur ajoute une raison d'arrêt 2 heures après l'événement, la catégorisation rétroactive est-elle possible, et existe-t-il une piste d'audit ?
(4) Montrer une production traversant minuit, comment le système gère-t-il les frontières de quart ? (5) Démontrer un changement de produit qui prend 90 minutes, le changement est-il suivi séparément du temps d'arrêt pour panne ?
Scénarios de calcul de l'OEE: (6) Montrer l'OEE d'une ligne produisant deux produits avec des temps de cycle différents au cours du même quart, comment les objectifs par produit sont-ils gérés ?
(7) Montrer comment la maintenance planifiée pendant les heures de production affecte la Disponibilité, est-elle exclue du calcul de l'OEE ou affichée comme temps d'arrêt planifié ? (8) Démontrer le calcul du taux de qualité, d'où proviennent les données de rebut, et comment le retravail est-il géré séparément des déchets ?
(9) Montrer ce qui se passe si le score OEE d'un quart est de 0 %, le système gère-t-il les cas limites sans erreurs ? (10) Démontrer l'agrégation de l'OEE sur trois lignes ayant des horaires de quart différents, comment l'OEE multi-lignes est-elle calculée ?
Scénarios de reporting et d'utilisabilité: (11) Montrer un Pareto des causes d'arrêt pour les 30 derniers jours, peut-il être filtré par quart, produit et catégorie d'équipement ? (12) Démontrer la création d'un rapport personnalisé, combien de temps faut-il pour créer un nouveau rapport à partir de zéro sans l'aide du fournisseur ?
(13) Montrer l'application mobile sur un appareil réel dans la salle, est-ce une application native ou une vue web mobile ? (14) Démontrer le déclenchement d'une alerte et sa réception par un superviseur, quelle est la latence réelle ?
(15) Montrer une exportation massive de données de 12 mois d'arrêts, combien de temps cela prend-il et dans quel format est-ce fourni ? Scénarios d'intégration et d'administration: (16) Montrer une démo en direct du système OEE recevant des données d'un PLC de test via OPC‑UA, pas une simulation, une connexion réelle.
(17) Démontrer la création d'une nouvelle configuration de ligne de production sans intervention du fournisseur, quelle est la complexité de la configuration ? (18) Montrer comment un nouvel utilisateur est créé et assigné à une ligne et à un rôle spécifiques. (19) Démontrer la configuration de l'authentification unique pour votre fournisseur d'identité.
(20) Montrer comment une liste de codes causes d'arrêt est mise à jour lorsque la taxonomie change. (21) Montrer le système fonctionnant pendant une coupure réseau simulée, la mise en tampon en périphérie fonctionne-t-elle ? (22) Démontrer l'API, effectuer un appel API en direct devant vous pour extraire les dernières 24 heures de données OEE.
(23) Montrer l'aspect du système après 2 ans de données, y a-t-il une dégradation des performances ? (24) Demander au fournisseur de vous montrer un ticket de support client des 6 derniers mois et comment il a été résolu.
(25) Montrer le processus de mise à niveau, comment les nouvelles versions sont-elles déployées et quel temps d'arrêt est requis ?
Envoyez la liste de contrôle des 25 scénarios aux fournisseurs une semaine avant la démonstration et demandez-leur de se préparer à démontrer chacun de ces scénarios.
Surveillez attentivement leur réaction, les fournisseurs qui rechignent sur des scénarios spécifiques (« nous ne pouvons pas montrer cela dans un environnement de démonstration ») signalent une lacune de capacité. Les fournisseurs qui relèvent le défi et se présentent préparés ont davantage confiance dans les performances réelles de leur plateforme.
Pendant la démonstration, notez chaque scénario sur une échelle simple de 0 à 2: 0 (non démontré ou capacité non disponible), 1 (démontré avec des réserves importantes ou des contournements), 2 (démontré de façon claire et crédible).
Prenez des notes sur les preuves spécifiques pour chaque note, ce que le fournisseur a montré, les limitations mentionnées et les questions de suivi. Cette prise de notes crée un enregistrement d'évaluation de la démonstration qui peut être partagé avec les membres de l'équipe d'évaluation qui n'ont pas pu assister à la session complète.
Après la démonstration, faites un suivi pour tout scénario qui n'a pas été démontré en demandant une réponse écrite, demandant au fournisseur de documenter par écrit comment son système traite le scénario spécifique.
Les réponses écrites aux lacunes constatées lors de la démonstration créent des points de référence contractuels: si un fournisseur affirme par écrit que son système gère un scénario d'une certaine façon, et que cela ne fonctionne pas ainsi après la mise en production, vous disposez d'une documentation de la fausse déclaration.
Cette documentation incite également l'équipe commerciale du fournisseur à privilégier l'exactitude plutôt que l'optimisme, ce qui tend à améliorer la fiabilité de leurs réponses.
Connexion
Blog
