L'entropie des factures : pourquoi les collisions de révision tuent le rendement

Vous pouvez entrer dans l'installation d'un fabricant sous contrat à Guadalajara ou Shenzhen un mardi quelconque et être témoin d'un désastre parfaitement exécuté. La ligne avance, les machines de pick-and-place bourdonnent, et les opérateurs suivent leurs documents de suivi avec précision. Pourtant, à la fin de la ligne, les bacs rouges de rejet se remplissent d'unités qui vibrent physiquement, surchauffent ou refusent simplement de démarrer.

Les opérateurs ne ratent pas l'assemblage ; c'est le système qui échoue à la synchronisation.

Dans un scénario courant, une équipe mécanique émet un ordre de changement d'ingénierie (ECO) pour modifier un dissipateur thermique, l'équipe d'emballage émet un ECO séparé pour de nouveaux inserts en mousse, et l'équipe firmware pousse un patch pour réduire la vitesse des ventilateurs. Si ces trois changements arrivent à l'usine sans lien explicite, le superviseur de ligne les met en œuvre dès qu'ils obtiennent l'approbation. Vous vous retrouvez avec 2 000 unités contenant l'ancien petit dissipateur thermique mais fonctionnant avec le nouveau profil de ventilateur à basse vitesse. Le résultat est une coupure thermique sur le terrain, tout cela parce que la « Date d'effet » sur le changement de firmware était fixée à « Après approbation » tandis que le changement mécanique était fixé à « Épuiser le stock ».

L'ingénierie fonctionne généralement bien. La friction vient du fait de traiter l'ingénierie comme un flux continu alors que la fabrication se fait par instantanés discrets. Lorsque vous traitez une nomenclature (BOM) comme un dépôt logiciel, vous invitez le chaos. Un revert git ne coûte rien. Revenir sur un outil de moulage par injection plastique ou jeter 5 000 circuits imprimés parce que la lettre de révision ne correspondait pas au pochoir est une erreur à six chiffres. La collision de plusieurs ECO lors d'une production programmée est la cause la plus fréquente de perte de rendement « douce ». Vous n'avez pas construit l'unité de manière incorrecte ; vous avez simplement construit la mauvaise unité parce que les calendriers se sont heurtés.

Le piège de la « Dernière Révision »

Il existe une hypothèse dangereuse dans le développement matériel moderne selon laquelle la version « la plus récente » d'un fichier est celle qui doit être construite. Dans un système de gestion du cycle de vie produit (PLM), un fichier peut être « Approuvé » bien avant d'être « Implémenté ». C'est dans cet écart que l'argent disparaît.

Un ingénieur assis dans un bureau à Austin voit que la nouvelle conception de support est approuvée dans le système et suppose que la prochaine unité sortie de la ligne l'aura. Mais l'atelier fonctionne sur un inventaire physique, pas sur un statut numérique. S'il y a 4 000 unités de l'ancien support dans l'entrepôt, la logique par défaut de l'usine est de les utiliser pour éviter le gaspillage. À moins que l'ECO n'impose explicitement une action de « Purge et rebut », la révision « la plus récente » n'existe que sur le serveur, pas sur la ligne.

Cette déconnexion devient mortelle lorsque vous introduisez la « Dérogation de déviation ». Souvent un mal nécessaire dans la gestion de la chaîne d'approvisionnement, une dérogation est une permission formelle de violer temporairement les règles — peut-être pour utiliser un condensateur de substitution en cas de pénurie ou sauter un test cosmétique pour respecter une date d'expédition. Le danger survient lorsque ces dérogations sont traitées comme de la paperasserie administrative plutôt que comme des changements d'ingénierie.

Une dérogation est en fait un ECO temporaire avec une date d'expiration. Si vous autorisez une déviation pour utiliser un composant provenant d'un courtier mais que vous ne liez pas cette déviation à une plage spécifique de numéros de série dans le PLM, vous avez créé une bombe à retardement. Six mois plus tard, lorsque ces composants échoueront, vous ne saurez pas quelles unités les ont. Vous ne pouvez pas rappeler seulement les mauvaises car les données n'existent pas. Sans une porte d'implémentation spécifique, l'usine utilise par défaut ce qui est en stock, et « l'espoir » n'est pas un champ valide dans un journal de traçabilité.

Le firmware est un composant, pas une ambiance

La victime la plus fréquente des collisions de révision est le firmware. Les équipes logicielles sont habituées à l'intégration continue ; elles voient le code comme une entité vivante qui s'améliore avec le temps. La fabrication considère le code comme une pièce, pas différente d'une vis ou d'une résistance. Si le binaire firmware n'a pas un numéro de pièce distinct et une révision contrôlée dans la nomenclature, il n'existe effectivement pas pour l'opérateur de ligne.

Considérez le scénario du « Firmware Fantôme ». Un développeur pousse la version 2.1 dans le dépôt pour corriger un bug critique. Cependant, les programmeurs d'usine flashent le binaire situé dans un dossier spécifique sur le serveur de test. Si le processus ECO n'instruit pas explicitement l'ingénieur de test à valider la nouvelle somme de contrôle et à mettre à jour l'image du programmateur, l'usine continuera à flasher la version 2.0 indéfiniment. Les unités passeront le test fonctionnel car les limites de test n'ont probablement pas été mises à jour pour rechercher la nouvelle chaîne de version non plus.

Il y a ici une tentation de compter sur les mises à jour Over-the-Air (OTA) pour réparer ces désordres plus tard. C'est un béquille dangereuse. L'OTA ne peut pas réparer un appareil qui devient inutilisable immédiatement au démarrage parce que la version du bootloader ne correspond pas à la carte de partition de l'application. De plus, compter sur les mises à jour sur le terrain détruit votre capacité à diagnostiquer les pannes. Si un client appelle le support avec une unité inutilisable, et que votre équipe RMA ne peut pas déterminer à partir du numéro de série quel code a été initialement flashé à l'usine, ils sont à l'aveugle. Ils ne savent pas s'ils poursuivent un défaut matériel ou un bug logiciel. Si le binaire n'a pas de numéro de pièce, il n'existe pas pour l'opérateur de ligne, et cela n'aidera certainement pas votre équipe de support.

La matrice de disposition

Le champ le plus critique de tout ECO n'est pas la description du changement, mais la « Disposition » de l'ancien matériel. C'est ici que la réalité financière du changement est calculée. Lorsque vous introduisez une nouvelle révision, vous devez prendre en compte le matériel dans quatre états : En stock (dans l'entrepôt), En commande (en provenance des fournisseurs), En cours de fabrication (WIP) sur la ligne, et Produits finis (sur le quai).

Pour chaque catégorie, vous devez faire un choix binaire : Utiliser tel quel, Retoucher, Retourner au fournisseur, ou Mettre au rebut. C'est la matrice de disposition. Beaucoup de responsables ingénierie laissent cette section vide ou vague, écrivant des choses comme « Retoucher si possible. » C'est un manquement à leur devoir. « Retoucher » implique des heures de travail, un démontage, un risque de dommage aux autres composants, et un nouveau test. Souvent, le coût du déballage, de l'ouverture, de la dessoudure et du re-flashage d'une unité dépasse la marge du dispositif.

Vous devez faire les calculs. Il est fréquemment moins cher de mettre au rebut $5 000 PCB bruts que de payer trois jours d'arrêt de ligne pendant que les opérateurs tentent une retouche délicate. La retouche est presque toujours une illusion ; la mise au rebut est le prix de la clarté.

Le protocole de rupture nette

Pour arrêter l'hémorragie, vous devez appliquer la « Rupture nette ». Un changement progressif — où les nouvelles révisions sont mélangées dans le bac avec les anciennes révisions — est acceptable uniquement pour les pièces qui sont 100% interchangeables en forme, ajustement et fonction, comme une vis d'un fournisseur différent. Pour tout le reste, vous avez besoin d'une coupure nette.

Cela signifie définir le point de coupure non pas par une date calendaire, qui est glissante, mais par un code de lot spécifique ou un numéro de série. « La révision B commence au SN : 100500. » Cette instruction permet à l'usine de séparer la ligne. Ils peuvent terminer la série de la révision A, nettoyer la ligne, purger l'ancien stock, et commencer la révision B avec une nouvelle configuration.

Cela demande de la discipline. Cela peut signifier retarder une production de deux jours pour attendre l'arrivée des nouvelles pièces plutôt que de fabriquer un monstre « hybride ». Mais ce retard est moins coûteux qu'un rappel. Contrôlez le point de rupture, ou le point de rupture contrôlera votre marge.