Rendre le travail de maintenance critique mesurable avant de passer à l’échelle
Commencez par le flux qui échoue aujourd’hui — notification, réponse, exécution, documentation — sur vos actifs critiques. La surveillance de l’état n’est ajoutée que là où capteurs et temps d’observation suffisant existent réellement, et la prédiction de panne n’est revendiquée que là où un historique de panne étiqueté existe.
Évaluer mes actifs critiquesParler à un ingénieur productionEst-ce bien le problème que vous devez résoudre ?
- La gestion des pannes fonctionne par appels téléphoniques et tableau blanc, donc le temps de réponse est inconnu.
- Les plans préventifs existent sur papier et glissent discrètement dès que la production est chargée.
- La même panne se répète et personne ne peut le prouver, car l’historique est dans des carnets.
- Les pièces détachées sont trouvées manquantes au moment où le technicien en a besoin.
Interlocuteur principal: Responsable maintenance · Responsable fiabilité · Directeur d’usine · Responsable ingénierie · Responsable excellence opérationnelle
Ce que ce PoC va démontrer
Périmètre pilote recommandé
- Actifs critiques sélectionnés — ceux dont la panne arrête réellement la production.
- Une équipe de maintenance, avec le flux de panne et de notification qu’elle utilise aujourd’hui.
- Plans préventifs, ordres de travail et, le cas échéant, les pièces détachées derrière.
- Hiérarchie des actifs, criticité et l’historique de panne existant.
- Capteurs pour des cas d’usage de surveillance d’état convenus seulement, jamais comme hypothèse générale.
Ce qui fonctionnera pendant le PoC
Comment se déroule ce PoC
Les durées sont typiques, pas garanties. Ce qui allonge un calendrier : données manquantes ou incomplètes, validations de sécurité et de réseau, délais de livraison du matériel, collecte d’échantillons, accès pour l’installation, plan de production, accès à l’environnement de test de l’ERP et le temps dont vos équipes ont besoin pour analyser les résultats.
Aucun arrêt imprévu n’est prévu. Toute fenêtre d’installation ou interruption contrôlée est convenue avec vous à l’avance et planifiée autour de la production.
Comment le succès sera mesuré
| Indicateur | Comment il est défini | D’où vient la valeur | Type |
|---|---|---|---|
| Temps notification-réponse | Temps entre le signalement d’une panne et son acceptation par un technicien, mesuré sur les actifs pilotes. | Données de la plateforme MSF | Opérationnel |
| MTTR | Temps moyen de réparation pour les actifs pilotes durant la période en direct, selon la définition convenue au cadrage. | Données de la plateforme MSF | Opérationnel |
| MTBF de référence | Temps moyen entre pannes établi pour les actifs pilotes — une référence, pas un objectif, sur cette fenêtre d’observation. | Mesure de référence convenue | Opérationnel |
| Taux de travail d’urgence | Part des heures de maintenance consacrées au travail non planifié contre le travail planifié. | Données de la plateforme MSF | Opérationnel |
| Respect du préventif | Part du travail préventif dû réalisé dans sa fenêtre, et le retard accumulé en fin de période. | Données de la plateforme MSF | Opérationnel |
| Complétude de la documentation | Part des ordres de travail fermés avec cause, action et pièces enregistrées plutôt que fermés vides. | Données de la plateforme MSF | Adoption |
| Pannes répétées | Pannes sur le même actif et la même cause dans la période — la preuve qu’une réparation n’a pas tenu. | Données de la plateforme MSF | Opérationnel |
| Délai d’alerte | Uniquement là où des capteurs sont au périmètre : temps entre une alarme d’état et l’événement qu’elle annonçait, avec les fausses alarmes comptées séparément. | Données de capteur, de compteur ou d’équipement | Technique |
Avant toute mise en œuvre, MSF et vos équipes conviennent du mode de calcul de chaque indicateur, de la provenance de la valeur de référence, des données exclues et du résultat qui justifiera une décision de déploiement. Cette page indique ce qui sera mesuré ; les objectifs chiffrés relèvent du périmètre écrit du PoC, pas d’une promesse commerciale.
Ce que vous fournissez
- Hiérarchie des actifs, classement de criticité et l’historique de panne existant, sous quelque forme qu’il existe.
- Plans de maintenance actuels, relevés de compteurs et données de pièces détachées le cas échéant.
- Rôles des techniciens, couverture des postes et les appareils qu’ils utiliseront réellement.
- Règles d’accès et de sécurité pour toute installation de capteur au périmètre.
Qui fait quoi
Meta Smart Factory fournit
- Atelier de cadrage et animation de la définition du périmètre
- Configuration de la solution pour le périmètre convenu
- Travaux d’intégration et de raccordement dans ce périmètre
- Le matériel MSF listé dans la proposition
- Formation des utilisateurs du pilote
- Les définitions d’indicateurs et la méthode de validation
- Suivi des anomalies et support pendant le pilote
- Le rapport final de résultats et la conception du déploiement
- Structure d’actifs configurée, plans préventifs et exécution mobile d’ordres de travail pour l’équipe pilote.
- Une classification honnête des cas d’usage de surveillance d’état que les données disponibles peuvent réellement soutenir.
Vous fournissez
- Un référent métier et un référent technique nommés
- Un accès en temps voulu aux utilisateurs, à la ligne, aux machines et aux systèmes autorisés
- Une description fidèle du processus et des données de base
- Les accès réseau, électriques, de montage et de sécurité
- La documentation ERP, automate et fournisseur, et les experts qui la maîtrisent
- Des échantillons représentatifs ou des données historiques
- La validation du caractère équitable de la référence
- Les retours et la décision de recette
- Des techniciens qui utiliseront le système lors de vraies pannes, pas seulement en formation.
- Tout historique de panne existant — même incomplet, il détermine ce qui peut être affirmé.
Défini dans la proposition écrite
- Panel PC, tablettes, serveurs et serveurs GPU
- Caméras, optiques, éclairages et coffrets
- Lecteurs, imprimantes, équipements RFID, compteurs et capteurs
- Déplacements, installation, transport, droits de douane et travaux électriques locaux
- Si le matériel est loué ou acheté
- Si le montant du PoC est déduit d’un déploiement
Les conditions commerciales, la propriété du matériel, les déplacements, le périmètre d’intégration et toute déduction sur le déploiement sont définis dans la proposition écrite du PoC. Ils ne sont pas identiques pour tous les produits et cette page ne les promet pas.
Ce que vous recevez à la fin
- Un flux de maintenance en direct utilisé par votre équipe sur de vraies pannes.
- Hiérarchie des actifs, criticité et plans préventifs configurés.
- Tableau de bord référence contre pilote sur les définitions de KPI convenues.
- Constats capteurs et évaluation de la référence de données là où la surveillance d’état était au périmètre.
- Rapport de criticité et d’écarts — ce que le pilote n’a pas pu couvrir et pourquoi.
- Plan de déploiement pour les actifs et équipes restants.
Prérequis, exclusions et limites
Ce PoC dépend de
- Disponibilité des techniciens durant la période en direct, y compris sur les postes où les pannes surviennent réellement.
- Pour la surveillance d’état : points de montage capteur sûrs et assez de temps d’observation pour être significatif.
Non inclus dans ce PoC
- Nettoyage des données d’actifs à l’échelle de l’usine et numérisation des enregistrements historiques.
- Approvisionnement en pièces détachées et mise en œuvre d’entrepôt, qui relèvent du PoC WMS.
Là où un historique de panne étiqueté ou des données d’observation suffisantes n’existent pas, ce PoC est positionné comme surveillance d’état, détection d’anomalies et création de référence de données — pas comme prédiction de panne. Une affirmation prédictive sans pannes pour apprendre n’est pas une affirmation, c’est un espoir.
Poursuivre, ajuster ou arrêter : le point de décision
Questions fréquentes
Peut-on prouver la maintenance prédictive dans un PoC ?
Seulement là où il existe assez d’historique de panne étiqueté et une fenêtre d’observation assez longue, et les deux sont vérifiés avant toute promesse. Là où ils manquent, le programme honnête est la surveillance d’état plus la construction de la référence de données qui rendra la prédiction possible plus tard.
Avons-nous besoin de capteurs ?
Pas pour la moitié « flux » de ce PoC, qui concentre la majorité de la valeur mesurable. Les capteurs sont ajoutés pour des cas d’usage de surveillance d’état spécifiques convenus au cadrage, sur des actifs spécifiques, pour une question spécifique.
Notre historique de panne est dans des carnets. Est-ce un blocage ?
Non, et c’est très courant. Cela limite ce qui peut être affirmé sur la prédiction, pas ce qui peut être mesuré sur la réponse, le respect et les pannes répétées. Le PoC démarre l’historique structuré dont une future étape prédictive aurait besoin.
Comment mesurez-vous le MTTR équitablement face à notre chiffre actuel ?
En convenant de la définition au cadrage, y compris ce qui compte comme début, ce qui compte comme fin, et quels arrêts sont exclus. Deux organisations peuvent mesurer le MTTR de trois façons différentes ; la comparaison n’est honnête que si les deux côtés utilisent la même.
Produits et programmes PoC associés
Demander ce Proof of Concept
Décrivez le périmètre que vous avez en tête et nous revenons vers vous avec un plan de PoC écrit : ce qui est raccordé, ce que vous fournissez, comment le succès est mesuré et à quoi ressemble la décision finale.