Base de connaissances

Comment construire le business case d'un système d'exploitation d'usine

Équipe DBR77 IRIS8 min de lecture

Écrans DBR77 IRIS : cartes KPI OEE du MES reliées aux rapports enregistrés du générateur, comme les rebuts par poste

Construisez le business case d'un système d'exploitation d'usine à partir de votre propre situation de départ, pas à partir des pourcentages des éditeurs. Mesurez quatre à six pertes sur une ligne pendant quelques semaines, chiffrez chacune d'elles, et calculez quelle part de ces pertes le système doit supprimer pour se payer. Laissez ensuite un pilote sur une ligne montrer s'il y parvient, avant de vous engager pour toute l'usine.

La finance obtient ainsi un chiffre qu'elle peut auditer, et les deux parties sont protégées contre l'échec le plus courant : un dossier construit sur les résultats de quelqu'un d'autre. Ci-dessous : pourquoi la plupart des dossiers échouent, comment mesurer une situation de départ, comment chiffrer chaque perte, le coût complet, le test du seuil de rentabilité et le rôle du pilote.

Pourquoi la plupart des business cases de logiciels d'usine échouent

La plupart des dossiers échouent de l'une de trois façons. Ils recopient les pourcentages de gains d'une brochure, et personne dans l'usine n'y croit. Ils ne comptent que les licences, et le coût réel apparaît plus tard. Ou ils promettent un chiffre sans aucun moyen de le vérifier.

Les travaux de McKinsey sur la fabrication numérique ont montré que les entreprises coincées dans le « purgatoire des pilotes » ne voyaient pas de gains significatifs sur le résultat, et recommandaient de partir de la valeur pour le résultat, et non de la technologie, avec une feuille de route par phases et un business case. Concrètement : commencez par ce que l'usine perd aujourd'hui.

L'endroit où se trouvent ces pertes dans une usine aux outils séparés est traité dans Le coût réel des systèmes cloisonnés et des tableurs dans une usine. Cet article les transforme en dossier.

Barres des valeurs mensuelles : arrêts 33 000 €, ressaisie 5 800 €, coût du système 6 000 €, seuil à 4 h d'arrêt en moins

Étape 1 : mesurer une situation de départ défendable

Choisissez une ligne et mesurez pendant quatre à huit semaines, en complétant à la main si nécessaire. Chaque perte a besoin d'une définition, d'une source et d'un responsable.

PerteComment la mesurerOù se trouvent les données aujourd'huiComment la chiffrer
Arrêts non planifiésHeures par mois, avec les causes d'arrêtDonnées machines, rapports de poste, MESMarge perdue par heure sur le goulot, heures supplémentaires pour rattraper
Rebuts et retouchesUnités ou kg par semaine, par type de défautFormulaires qualité, MES, ERPMatière plus main-d'œuvre plus temps machine
Matière en retard ou manquanteMinutes pendant lesquelles la ligne attend la matièreNotes de poste, journaux de l'entrepôtComme les arrêts, plus le transport express
Ressaisie et rapprochementHeures par semaine passées à recopier des données d'un outil à l'autreDemander aux planificateurs, chefs d'équipe, équipe qualitéCoût horaire chargé
Maintenance en retardOrdres de travail préventifs en retard, pannes répétéesGMAO, tableau blancCoût de réparation, pièces de rechange, arrêts provoqués
Réclamations clientsNombre par trimestre et coût de traitementQualité, ventesAvoirs, tri, transport, commandes perdues

Pour les pertes qualité, la méthode du coût de la qualité de l'ASQ est un cadre utile. Elle sépare les coûts de défaillance en coûts de défaillance internes, pour les défauts trouvés avant que le client ne reçoive le produit, et en coûts de défaillance externes, pour les défauts trouvés après. Comptez les deux séparément.

Les chiffres du secteur servent de contexte, pas de chiffre pour votre dossier. Siemens indique qu'une grande usine moyenne perd 27 heures par mois en arrêts non planifiés. Votre ligne peut être bien au-dessus ou bien en dessous. Seul votre propre chiffre a sa place dans le dossier.

Étape 2 : chiffrer chaque perte, puis tester le seuil de rentabilité

Ne commencez pas par « le système réduira les arrêts de X % ». Commencez par la question que la finance peut vérifier : quelle part des pertes faut-il supprimer pour couvrir le coût ?

Exemple illustratif : une usine en 2x8 mesure une ligne goulot pendant six semaines. Les arrêts non planifiés atteignent en moyenne 22 heures par mois. Chaque heure sur cette ligne représente 1 500 € de marge perdue, donc les arrêts coûtent environ 33 000 € par mois. Les planificateurs et les chefs d'équipe passent 30 heures par semaine à ressaisir des données, à 45 € de l'heure, ce qui ajoute environ 5 800 € par mois. Si le coût mensuel complet du système pour cette ligne est de 6 000 €, il atteint le seuil de rentabilité dès qu'il supprime environ 4 heures d'arrêt par mois, ou une combinaison plus petite d'arrêts et de ressaisie. L'équipe note cela comme objectif du pilote.

Le débat change. Au lieu de discuter de la promesse d'un éditeur, l'équipe se demande : est-il réaliste de supprimer 4 heures sur 22 par mois ? La production peut en juger à partir des causes d'arrêt.

Gardez deux listes séparées. Les économies tangibles se mesurent en argent : arrêts, rebuts, heures supplémentaires, transport. Les bénéfices qualitatifs, comme des audits plus rapides ou une intégration des nouveaux plus facile, vont dans une liste à part et ne s'ajoutent pas au total. Un directeur financier fera davantage confiance au dossier si la liste qualitative est clairement identifiée.

Étape 3 : compter le coût complet

L'abonnement n'est qu'une partie du coût :

  • Logiciel : par module, par site, par utilisateur, selon le modèle de tarification.
  • Mise en œuvre : paramétrage, nettoyage des données de référence, tests.
  • Intégration : ERP, GMAO ou WMS existants, données machines.
  • Matériel : tablettes, scanners, équipements edge, modifications du réseau en atelier.
  • Temps interne : utilisateurs clés, IT/OT, chefs d'équipe pendant la formation. C'est un coût réel, même si aucune facture n'arrive.
  • Conduite du changement : formation, nouvelles routines, accompagnement les premiers mois.

Ne coupez pas ce dernier poste pour faire tenir les chiffres. Selon les recherches de Prosci, les projets avec une excellente conduite du changement avaient environ sept fois plus de chances d'atteindre leurs objectifs que ceux où elle était faible : 88 % contre 13 %.

Étape 4 : faire du pilote la preuve

C'est le pilote qui confirme ou enterre le dossier. Avant son démarrage, mettez-vous d'accord par écrit sur :

  1. La ligne et le périmètre : quels modules, quelles équipes.
  2. Les mesures : les mêmes définitions que pour la situation de départ.
  3. L'objectif : le seuil de rentabilité de l'étape 2, plus un objectif ambitieux.
  4. La date de décision : quand la finance et la production compareront les résultats.
  5. La règle : quel résultat mène à un déploiement plus large, à un deuxième pilote ou à un arrêt.

Si l'usine décide aussi d'un changement d'implantation ou d'un nouvel équipement, testez-le séparément en simulation. Comment construire le business case d'un jumeau numérique traite des décisions d'investissement. Le choix entre éditeurs avant le pilote est traité dans Comment évaluer un système d'exploitation d'usine.

Comment cela fonctionne dans DBR77 IRIS

DBR77 IRIS se prête à un dossier qui commence petit. La tarification se fait par module : le pilote peut couvrir un module sur une ligne, et d'autres modules peuvent être ajoutés plus tard en conservant les données et les configurations. Le prix mensuel comprend l'hébergement, les mises à jour et le support standard. La mise en œuvre, les intégrations sur mesure et les formations premium sont chiffrées à part, donc elles peuvent figurer dès le départ dans la ligne des coûts.

La page tarifs d'IRIS propose un calculateur de retour sur investissement qui demande le nombre de lignes, les heures d'arrêt non planifié par mois, le budget de maintenance et le coût de la qualité. Ses résultats sont des estimations fondées sur des références du secteur : traitez-les comme une première esquisse et remplacez-les par votre situation de départ.

Pendant le pilote, IRIS KPI et l'analyse qualité d'IRIS QMS suivent les mêmes mesures que la situation de départ : OEE, MTBF, MTTR, arrêts planifiés et non planifiés, rendement au premier passage et coût de la non-qualité, avec une vue détaillée de l'usine jusqu'à la ligne, l'équipe et la machine. La comparaison avant et après devient un rapport, pas un débat.

Questions fréquentes

Peut-on utiliser les chiffres de référence des éditeurs dans le dossier ?

Seulement comme contexte. La finance doit voir votre propre situation de départ et un objectif de seuil de rentabilité. Les références d'autres usines décrivent d'autres usines.

Et si nous n'avons aucune donnée de départ ?

Mesurez à la main pendant quatre semaines sur une ligne : heures et causes d'arrêt, quantités de rebuts, heures passées à ressaisir. Des données approximatives qui sont les vôtres valent mieux que des données précises empruntées.

Quel délai de retour sur investissement viser ?

Utilisez le même seuil que celui de votre usine pour les équipements, et jugez-le selon les mêmes règles.

Conclusion

Le business case d'un système d'exploitation d'usine n'a pas besoin de chiffres inventés. Il a besoin d'une situation de départ mesurée sur votre propre ligne, d'une valeur pour chaque perte, d'une liste complète des coûts et d'un seuil de rentabilité qu'un pilote peut confirmer. La finance obtient un chiffre qu'elle peut auditer, et la production un objectif qu'elle peut porter.

Sources