Points clés
Brève réponse : La plupart des projets IIoT ne tiennent pas leurs promesses parce qu'ils négligent les bases. Une liste de contrôle en 12 points impose de clarifier le périmètre, le cas d'usage, la qualité des données, la sécurité, l'intégration et la responsabilité avant de signer un contrat. La démarche fait passer la question de « la technologie peut-elle fonctionner ? » à « le changement opérationnel aura-t-il lieu ? ». Cette dernière est plus difficile et plus importante. Voir aussi Qualité des données de l'atelier.
Clarté du cas d'usage (point 1). Beaucoup de projets commencent par « on a besoin d'IIoT » sans décision spécifique que les données permettront d'améliorer. Le fournisseur livre des données ; la valeur n'apparaît jamais.
Qualité des données (point 4). Les capteurs sont installés ; les données circulent ; personne ne vérifie l'exactitude. Les analyses en aval construites sur de mauvaises données échouent.
Plan d'adoption (point 9). Tableaux de bord déployés ; personne ne change de comportement. La valeur n'apparaît jamais.
Responsable opérationnel (point 10). Le projet vit dans l'IT ; les opérations ne portent pas le résultat. Dérive.
Trois modes d'échec fréquents :
1. Approche « technologie d'abord ». « Déployons l'IIoT. » Le résultat n'est jamais spécifié.
2. Pilote qui ne passe pas à l'échelle. Le pilote fonctionne ; la montée en charge révèle des problèmes d'architecture.
3. Écart d'adoption. Les données existent ; les comportements ne changent pas.
La liste de contrôle force à traiter chacun de ces points en amont.
Les fournisseurs prennent typiquement en charge :
Les clients doivent gérer :
La plupart des échecs se situent du côté des responsabilités client. Le fournisseur a livré ; le client n'a pas réalisé les tâches nécessaires.
Les pilotes réussissent parce que tout le monde y prête attention. La montée en charge échoue parce que l'attention se dissipe.
Planifiez la montée en charge dès la phase pilote. Faites du plan de montée en charge un critère de réussite du pilote.
1. Négliger la définition du cas d'usage. Cause d'échec la plus fréquente.
2. Pas de plan de qualité des données. Mauvaises données en aval.
3. Pas de responsable opérationnel. Une propriété limitée à l'IT produit des tableaux de bord que personne n'utilise.
4. Succès du pilote ≠ succès à l'échelle. Il faut un plan explicite de montée en charge.
Avant de signer le contrat fournisseur, parcourez les 12 points. Si l'un d'eux est flou ou absent, traitez-le avant de vous engager. La plupart des sites constatent qu'appliquer la liste de contrôle retarde le projet (car des problèmes réels apparaissent) ou l'annule (car le cas d'usage n'est pas réel). Les deux résultats sont préférables à une signature suivie d'un échec.
Une plateforme OEE moderne s'intègre aux sources de données IIoT, fournit la mesure des résultats (OEE, MTBF, coût) et prend en charge les workflows axés sur l'adoption qui rendent l'IIoT rentable.
Le module OEE de Fabrico s'intègre aux données IIoT, fournit la mesure des résultats et prend en charge les workflows opérateurs et de management qui transforment les données IIoT en changements opérationnels.
Découvrez comment Fabrico capture cela automatiquement — découvrez l'OEE pour la fabrication ou réservez une démo.
La définition du cas d'usage est omise, la qualité des données est faible et il n'y a pas de plan d'adoption : ce sont les principales causes.
Les opérations, avec le soutien de l'IT et de l'ingénierie.
3 à 6 mois en général. Moins de 3 mois ne permet pas de saisir la variabilité du monde réel.
Après que la qualité des données est prouvée et que les cas d'usage sont clairs. Le ML sur de mauvaises données échoue.
Le responsable opérationnel. Sans responsabilité explicite, le projet dérive.
Connexion
Blog
