Die Entropie von Rechnungen: Warum Revisionskollisionen den Ertrag töten

Man kann an einem beliebigen Dienstag eine Vertragsfertigungsanlage in Guadalajara oder Shenzhen betreten und eine perfekt ausgeführte Katastrophe beobachten. Die Linie läuft, die Bestückungsautomaten summen, und die Bediener folgen ihren Arbeitsanweisungen mit Präzision. Doch am Ende der Linie füllen sich die roten Ausschussbehälter mit Einheiten, die physisch klappern, überhitzen oder sich einfach weigern zu starten.

Die Bediener versagen nicht bei der Montage; das System versagt bei der Synchronisation.

In einem häufigen Szenario gibt ein mechanisches Team eine Engineering Change Order (ECO) zur Änderung eines Kühlkörpers heraus, das Verpackungsteam gibt eine separate ECO für neue Schaumstoffeinlagen heraus, und das Firmware-Team bringt einen Patch heraus, um die Lüftergeschwindigkeiten zu senken. Wenn diese drei Änderungen ohne explizite Verknüpfung in der Fabrik ankommen, setzt der Linienleiter sie um, sobald sie genehmigt sind. Am Ende hat man 2.000 Einheiten mit dem alten, kleinen Kühlkörper, die aber das neue, langsame Lüfterprofil verwenden. Das Ergebnis ist ein thermischer Abschaltvorgang im Feld, nur weil das „Wirksamkeitsdatum“ der Firmware-Änderung auf „Nach Genehmigung“ gesetzt war, während die mechanische Änderung auf „Bestand aufbrauchen“ gesetzt wurde.

Die Technik funktioniert normalerweise gut. Die Reibung entsteht dadurch, dass Technik als kontinuierlicher Fluss behandelt wird, während die Fertigung in diskreten Momentaufnahmen stattfindet. Wenn man eine Stückliste (BOM) wie ein Software-Repository behandelt, lädt man das Chaos ein. Ein git revert kostet nichts. Das Zurücksetzen eines Spritzgusswerkzeugs oder das Verschrotten von 5.000 Leiterplatten, weil der Revisionsbuchstabe nicht mit der Schablone übereinstimmte, ist ein Fehler im sechsstelligen Bereich. Die Kollision mehrerer ECOs während eines geplanten Builds ist die häufigste Ursache für „weichen“ Ausschuss. Man hat die Einheit nicht falsch gebaut; man hat einfach die falsche Einheit gebaut, weil Zeitpläne kollidierten.

Die Falle der „Letzten Revision“

Es gibt eine gefährliche Annahme in der modernen Hardwareentwicklung, dass die „neueste“ Version einer Datei diejenige ist, die gebaut werden sollte. In einem Product Lifecycle Management (PLM)-System kann eine Datei lange vor ihrer „Implementierung“ „Genehmigt“ sein. Diese Lücke ist der Ort, an dem das Geld verschwindet.

Ein Ingenieur in einem Büro in Austin sieht, dass das neue Halterungsdesign im System genehmigt ist, und geht davon aus, dass die nächste Einheit von der Linie es haben wird. Aber die Fabrik arbeitet mit physischem Bestand, nicht mit digitalem Status. Wenn 4.000 Einheiten der alten Halterung im Lager sind, ist die Standardlogik der Fabrik, diese aufzubrauchen, um Verschwendung zu vermeiden. Wenn die ECO nicht ausdrücklich eine „Reinigung und Verschrottung“ erzwingt, existiert die „neueste“ Revision nur auf dem Server, nicht auf der Linie.

Diese Diskrepanz wird tödlich, wenn man die „Abweichungsgenehmigung“ einführt. Oft ein notwendiges Übel im Lieferkettenmanagement, ist eine Genehmigung die formelle Erlaubnis, vorübergehend die Regeln zu brechen – vielleicht um während eines Mangels einen Ersatzkondensator zu verwenden oder einen kosmetischen Test zu überspringen, um eine Versandfrist einzuhalten. Die Gefahr entsteht, wenn diese Genehmigungen als Verwaltungsunterlagen und nicht als technische Änderungen behandelt werden.

Eine Genehmigung ist effektiv eine temporäre ECO mit Ablaufdatum. Wenn Sie eine Abweichung zur Verwendung eines über einen Broker bezogenen Bauteils autorisieren, diese Abweichung aber nicht mit einem bestimmten Seriennummernbereich im PLM verknüpfen, haben Sie eine Zeitbombe geschaffen. Sechs Monate später, wenn diese Bauteile ausfallen, wissen Sie nicht, welche Einheiten betroffen sind. Sie können nicht nur die fehlerhaften zurückrufen, weil die Daten nicht existieren. Ohne ein spezifisches Implementierungstor verwendet die Fabrik standardmäßig, was auf Lager ist, und „Hoffnung“ ist kein gültiges Feld in einem Rückverfolgbarkeitsprotokoll.

Firmware ist eine Komponente, kein Gefühl

Das häufigste Opfer von Revisionskollisionen ist die Firmware. Softwareteams sind an kontinuierliche Integration gewöhnt; sie sehen Code als lebendiges, atmendes Wesen, das sich im Laufe der Zeit verbessert. Die Fertigung sieht Code als Teil, nicht anders als eine Schraube oder einen Widerstand. Wenn die Firmware-Binärdatei keine eindeutige Teilenummer und keine Revision in der Stückliste hat, existiert sie für den Linienbediener effektiv nicht.

Betrachten Sie das Szenario „Phantom-Firmware“. Ein Entwickler lädt Version 2.1 in das Repository, um einen kritischen Fehler zu beheben. Die Fabrikprogrammierer flashen jedoch die Binärdatei, die sich in einem bestimmten Ordner auf dem Testserver befindet. Wenn der ECO-Prozess den Testingenieur nicht ausdrücklich anweist, die neue Prüfsumme zu validieren und das Programmierbild zu aktualisieren, wird die Fabrik für immer Version 2.0 flashen. Die Einheiten bestehen den Funktionstest, da die Testgrenzen wahrscheinlich auch nicht aktualisiert wurden, um nach dem neuen Versionsstring zu suchen.

Es besteht die Versuchung, sich auf Over-the-Air (OTA)-Updates zu verlassen, um diese Probleme später zu beheben. Dies ist eine gefährliche Krücke. OTA kann ein Gerät nicht reparieren, das sofort beim Start unbrauchbar wird, weil die Bootloader-Version nicht mit der Anwendungspartitionskarte übereinstimmt. Außerdem zerstört die Abhängigkeit von Feldupdates Ihre Fähigkeit, Fehler zu diagnostizieren. Wenn ein Kunde den Support mit einer unbrauchbaren Einheit anruft und Ihr RMA-Team anhand der Seriennummer nicht feststellen kann, welcher Code ursprünglich in der Fabrik geflasht wurde, arbeiten sie blind. Sie wissen nicht, ob sie einem Hardwaredefekt oder einem Softwarefehler nachjagen. Wenn die Binärdatei keine Teilenummer hat, existiert sie für den Linienbediener nicht und hilft Ihrem Support-Team sicherlich nicht.

Die Dispositionsmatrix

Das kritischste Feld bei jedem ECO ist nicht die Beschreibung der Änderung, sondern die „Disposition“ des alten Materials. Hier wird die finanzielle Realität der Änderung berechnet. Wenn Sie eine neue Revision einführen, müssen Sie das Material in vier Zuständen berücksichtigen: Lagerbestand (im Lager), Bestellung (eingehend von Lieferanten), WIP (Work in Process auf der Linie) und Fertigwaren (am Dock liegend).

Für jede Kategorie müssen Sie eine binäre Entscheidung treffen: Wie besehen verwenden, Nacharbeit, Rückgabe an den Lieferanten oder Verschrottung. Dies ist die Dispositionsmatrix. Viele Engineering-Manager lassen diesen Abschnitt leer oder vage und schreiben Dinge wie „Nacharbeit wenn möglich“. Das ist eine Pflichtverletzung. „Nacharbeit“ bedeutet Arbeitsstunden, Zerlegen, potenzielle Beschädigung anderer Komponenten und erneutes Testen. Oft übersteigen die Kosten für Auspacken, Öffnen, Entlöten und erneutes Flashen einer Einheit die Marge des Geräts.

Sie müssen die Rechnung machen. Es ist häufig billiger, $5.000 Roh-PCBs zu verschrotten, als drei Tage Stillstand der Linie zu bezahlen, während Bediener eine empfindliche Nacharbeit versuchen. Nacharbeit ist fast immer eine Fantasie; Verschrottung ist der Preis für Klarheit.

Das Protokoll des sauberen Bruchs

Um das Bluten zu stoppen, müssen Sie den „sauberen Schnitt“ durchsetzen. Eine rollierende Änderung – bei der neue Revisionen mit alten Revisionen im Behälter gemischt werden – ist nur für Teile akzeptabel, die 100% in Form, Passform und Funktion austauschbar sind, wie eine Schraube von einem anderen Lieferanten. Für alles andere benötigen Sie einen harten Schnitt.

Das bedeutet, den Einschnittspunkt nicht nach einem Kalenderdatum zu definieren, das schwammig ist, sondern nach einem spezifischen Loscode oder einer Seriennummer. „Revision B beginnt bei SN: 100500.“ Diese Anweisung ermöglicht es der Fabrik, die Linie zu trennen. Sie können den Lauf von Revision A beenden, die Linie räumen, den alten Bestand aussondern und Revision B mit einer frischen Einrichtung beginnen.

Es erfordert Disziplin. Es könnte bedeuten, einen Bau um zwei Tage zu verzögern, um auf die neuen Teile zu warten, anstatt ein „hybrides“ Monster zu bauen. Aber diese Verzögerung ist billiger als ein Rückruf. Kontrollieren Sie den Einschnittspunkt, oder der Einschnittspunkt kontrolliert Ihre Marge.