Modèle de demande de propositions (RFP) pour logiciel OEE : 47 exigences et une matrice d'évaluation pondérée

Une demande de propositions (RFP) pour un logiciel OEE remplit deux fonctions: elle oblige les fournisseurs à répondre à vos exigences spécifiques plutôt qu'à leur discours standard, et elle crée une base structurée pour comparer les réponses entre fournisseurs.

De nombreux fabricants envoient des RFP OEE mal structurés, soit trop génériques (demandant « capacité de calcul OEE » sans préciser la granularité requise), soit trop prescriptifs (spécifiant une architecture technique qui limite les réponses aux fournisseurs ayant construit leur plateforme d'une certaine façon).

La bonne structure de RFP est axée sur les exigences: quels résultats vous attendez, et non la manière dont le fournisseur doit les fournir.

Un RFP efficace pour un logiciel OEE comporte sept sections. Premièrement, une présentation de l'entreprise et de l'usine qui fournit aux fournisseurs un contexte sur votre environnement de production (secteur, nombre de lignes, types de machines, infrastructure informatique existante, système ERP). Deuxièmement, la définition du périmètre couvrant les sites et zones de production concernés par le déploiement initial et ceux pouvant être ajoutés ultérieurement.

Troisièmement, les exigences fonctionnelles organisées par catégorie (collecte des données, calcul de l'OEE, reporting, intégrations, accès mobile, alertes). Quatrièmement, les exigences techniques couvrant l'architecture de déploiement, la sécurité, les standards d'intégration et l'exportation des données. Cinquièmement, les exigences d'implémentation et de support incluant l'approche d'implémentation, la formation et les attentes en matière de SLA.

Sixièmement, les exigences commerciales couvrant le modèle de tarification, les conditions contractuelles et la structure de licence. Septièmement, les exigences relatives aux clients de référence demandant des références dans votre secteur et dans la fourchette de taille d'usine.

La section des exigences fonctionnelles est celle où la plupart des fabricants sous-spécifient. Les exigences génériques comme « capacité à suivre les temps d'arrêt » sont peu informatives, tout fournisseur d'OEE prétend pouvoir le faire.

Des exigences spécifiques telles que « le système doit capturer automatiquement les événements d'arrêt via un signal d'automate (PLC) sans saisie manuelle par l'opérateur, les classer en au moins 3 niveaux hiérarchiques, et permettre une reclassification rétrospective dans les 24 heures » obligent les fournisseurs à décrire leur capacité réelle plutôt qu'à affirmer une conformité générique.

Rédiger des exigences avec ce niveau de précision nécessite de la préparation, soit de la part d'utilisateurs internes qui savent ce que le système actuel ne fait pas, soit d'un consultant en implémentation OEE qui a vu plusieurs systèmes en production.

Organiser les exigences de la RFP en catégories facilite l'évaluation. Les exigences de collecte de données doivent couvrir: la détection automatisée de l'état des machines via PLC/OPC‑UA une hiérarchie configurable des causes d'arrêt (minimum 3 niveaux) un flux de travail d'accusé de réception des arrêts par l'opérateur

la collecte des comptages de production à partir des signaux machines la capture des rejets qualité au point de production la catégorisation des états de changement de série et de maintenance planifiée la configuration des plannings d'équipes et la prise en charge des productions multi‑produits avec des objectifs de temps de cycle par produit.

Exigences de calcul de l'OEE: calcul de l'OEE conforme à la norme ISO 22400 méthodologie de calcul configurable (OEE « world‑class » vs OEE « practical » vs OEE « theoretical ») calcul et affichage des sous‑métriques disponibilité, performance et qualité agrégation par quart, quotidienne, hebdomadaire et mensuelle

calculs de consolidation par ligne, zone et usine calcul de l'OEE en temps réel (et pas seulement en fin de quart) taux de qualité au premier passage distinct du taux de qualité global et calcul des tendances historiques sur au moins 24 mois.

Exigences de reporting et d'analytique: tableau de bord configurable par rôle utilisateur analyse de Pareto des causes d'arrêt par durée et fréquence graphique en cascade de l'OEE (arbre des pertes montrant les composantes disponibilité, performance et qualité) rapports de comparaison de quarts benchmarking des lignes entre sites livraison de rapports planifiés par e‑mail

export des données brutes en CSV/Excel et accès API pour intégration aux outils BI.

Exigences d'intégration: client OPC‑UA; intégration des ordres de production SAP/Oracle/D365 (si applicable); déclenchement d'ordre de travail du GMAO sur événement d'arrêt; authentification unique (SSO) via SAML 2.0 ou OIDC; et transfert de données chiffré via HTTPS.

Exigences mobiles et d'alerte : application mobile iOS et Android ; alerte en temps réel au superviseur de quart en cas d'arrêt dépassant un seuil ; notification push quotidienne récapitulative de l'OEE ; et mode hors ligne avec synchronisation des données lors de la reconnexion.

Une matrice de notation pondérée convertit les réponses aux RFP en scores comparables qui reflètent les priorités de votre organisation. La pondération doit refléter l'importance relative de chaque catégorie d'exigences pour votre situation spécifique, un fabricant avec des intégrations SAP complexes devrait pondérer la capacité d'intégration plus fortement qu'un fabricant utilisant un ERP autonome

tandis qu'une usine souffrant d'une mauvaise discipline de saisie des données par les opérateurs devrait accorder plus de poids à la collecte de données automatisée qu'à la flexibilité des rapports.

Structure de pondération typique pour un fabricant du mid-market: capacité de collecte des données (25 %), la base sans laquelle les données OEE sont peu fiables calcul OEE et analyses (20 %), la valeur principale fournie intégration ERP/GMAO (CMMS) (20 %), la connexion aux systèmes existants

mise en œuvre et support (15 %), le risque de livraison rapports et tableaux de bord (10 %), l'expérience utilisateur conditions commerciales (10 %), le coût total de possession.

Dans chaque catégorie, les exigences individuelles sont notées de 0 à 3 (0 = non pris en charge, 1 = prévu dans la feuille de route, 2 = pris en charge avec configuration, 3 = pris en charge nativement/prêt à l'emploi) et le score de la catégorie est la moyenne pondérée des scores des exigences individuelles.

Au-delà du score quantitatif, présélectionnez des fournisseurs pour une démonstration structurée avant de prendre une décision finale. Les réponses aux RFP décrivent la capacité; les démonstrations révèlent l'utilisabilité.

Le meilleur logiciel OEE pour votre usine est celui que vos opérateurs utiliseront réellement et correctement, ce qui nécessite d'évaluer l'interface opérateur dans le contexte de votre environnement de production spécifique, avec vos types de machines, vos cadences d'équipe et votre flux de saisie des données.

Pesez l'évaluation de la démonstration séparément du score RFP et combinez les deux dans votre recommandation finale aux parties prenantes de la direction.