Réduire les coûts de fabrication : ne résolvez pas deux fois le même problème

La réduction des coûts en fabrication est souvent vue comme une course permanente à la nouvelle idée. Mais il vaut la peine de s'arrêter d'abord sur une question : une entreprise a-t-elle vraiment besoin d'une nouvelle solution à chaque fois, ou passe-t-elle le plus clair de son temps à résoudre à nouveau un problème qu'un autre ingénieur ou une autre usine a déjà résolu ?

Chaque usine résout le même problème en repartant de zéro

Quand le prix des matières premières augmente, le bureau d'études cherche un matériau de substitution. Quand le coût de la main-d'œuvre augmente, la production cherche à réduire l'effectif d'une étape. Quand le temps de cycle est trop élevé, les ingénieurs s'installent pour améliorer la machine ou le process. Quand le taux de rebut augmente, la qualité et la production partent en quête de la cause. Chacune de ces actions est nécessaire et juste — le problème n'est pas qu'il faille les faire, c'est que presque à chaque fois, on repart de zéro : analyser l'état actuel, trouver la cause, brainstormer, tester, évaluer, et seulement ensuite déployer.

Pourtant, ce type de problème se répète bien plus souvent qu'on ne le croit, et la plupart ont déjà été traversés par quelqu'un. Un ingénieur d'usinage a un jour raccourci le temps de cycle d'une pièce en changeant l'ordre des étapes d'usinage. Une autre usine a un jour réduit le rebut matière sur le même type de produit en changeant la façon d'imbriquer les découpes sur la tôle. Un ingénieur maintenance a un jour passé des semaines à trouver la vraie cause d'un arrêt de ligne récurrent. Rien de rare — cela arrive dans la plupart des usines, presque chaque semaine, sauf que ça n'arrive jamais deux fois au même endroit au même moment.

Les solutions ne manquent pas — elles sont enfermées, éparpillées partout

Le savoir sur la réduction des coûts en fabrication n'est pas rare. Il est simplement fragmenté. Une partie est dans la tête de l'ingénieur qui a fait le travail lui-même. Une partie tient dans un seul fichier Excel sur l'ordinateur de celui qui l'a écrit. Une partie se trouve dans un rapport Kaizen enregistré sous un nom du type `Kaizen_Final_2024_v3.xlsx` — quelques années plus tard, presque personne ne se souvient de son contenu, et celui qui l'ouvre ne peut même pas être sûr que c'est bien la version finale. Le reste est dispersé dans des e-mails, des plans, des devis fournisseurs, des comptes-rendus de réunion, et surtout dans la mémoire orale de ceux qui sont dans l'usine depuis assez longtemps.

Une entreprise peut détenir une immense quantité de savoir sur la réduction des coûts — sans avoir la capacité de retrouver le bon morceau au bon moment. Un ingénieur démissionne ou change de service, et la solution part avec lui. Le savoir n'est pas détruit, mais il échappe à la portée de celui qui en aura besoin ensuite.

La question qu'il faut changer

La question courante face à un problème de coût est : « Quelle idée puis-je trouver pour ça ? » La question qu'il vaut la peine de poser d'abord est différente : « Ce problème a-t-il déjà été résolu par quelqu'un ? »

La différence entre ces deux questions n'est pas mince. La première repart de zéro — réanalyser, retester, refaire des erreurs qu'un autre a peut-être déjà faites. La seconde part d'un point déjà étayé : si un problème similaire a déjà été résolu et le résultat mesuré, l'ingénieur a un endroit où chercher avant de réfléchir seul, et un endroit où comparer avant de faire confiance à sa propre approche. Cela ne veut pas dire copier intégralement la solution d'un autre — les conditions réelles de chaque usine diffèrent toujours. Cela veut dire ne pas avoir à réinventer un savoir que quelqu'un d'autre a déjà payé en temps et en argent.

Costdown n'est pas une bibliothèque de contenu

Une bibliothèque de contenu peut répondre à « dix façons de réduire le coût du soudage ». Mais un ingénieur face à un problème réel n'a pas besoin d'un article générique — il a besoin d'une réponse à sa situation précise.

Supposons qu'un ingénieur produise des châssis en tube d'acier, que le temps de soudage actuel soit d'environ 50 secondes par pièce, avec deux opérateurs, quelques milliers de pièces par jour, et qu'il veuille réduire le coût de main-d'œuvre de cette étape. La question n'est alors pas « comment souder plus vite » en général, mais « quelqu'un a-t-il déjà résolu un problème dans des conditions à peu près similaires, et quel résultat a-t-il mesuré ». (Les chiffres ici ne servent qu'à illustrer une situation — ce ne sont pas les données d'un projet précis.)

C'est exactement la frontière entre deux choses qu'on confond facilement : le contenu aide le lecteur à comprendre un concept ; les données structurées aident quelqu'un à trouver, comparer et réutiliser la solution qui correspond à ses propres conditions. Costdown est bâti pour la seconde. Il ne remplace ni la lecture ni la réflexion propre de l'ingénieur — il existe une étape plus tôt, au moment qui décide si l'ingénieur doit ou non repartir de zéro.

Une solution ne devrait pas mourir avec celui qui l'a créée

Costdown repose sur un postulat : une solution de réduction de coût prouvée ne devrait pas disparaître avec le projet, avec le fichier Excel, ou avec l'ingénieur qui l'a créée. Un projet de réduction de coût réussi devrait devenir une donnée structurée — une donnée qu'on peut trouver, qu'on peut comparer, et ce qui a été prouvé devrait pouvoir être réutilisé pour le prochain problème.

Une usine résout un problème. Une autre usine n'a pas besoin de repartir de zéro.