Entropia faktur: dlaczego kolizje rewizji zabijają wydajność

Możesz wejść do zakładu producenta kontraktowego w Guadalajarze lub Shenzhen w dowolny wtorek i być świadkiem perfekcyjnie przeprowadzonej katastrofy. Linia działa, maszyny pick-and-place szumią, a operatorzy precyzyjnie realizują swoje dokumenty podróżne. A jednak na końcu linii czerwone pojemniki na odrzucone jednostki zapełniają się urządzeniami, które fizycznie grzechoczą, przegrzewają się lub po prostu odmawiają uruchomienia.

Operatorzy nie zawodzą w montażu; system zawodzi w synchronizacji.

W jednym z powszechnych scenariuszy zespół mechaniczny wydaje Zlecenie Zmiany Inżynieryjnej (ECO) w celu modyfikacji radiatora, zespół opakowań wydaje osobne ECO na nowe wkładki piankowe, a zespół oprogramowania układowego wypuszcza poprawkę obniżającą prędkości wentylatorów. Jeśli te trzy zmiany trafiają do fabryki bez wyraźnego powiązania, kierownik linii wdraża je w miarę zatwierdzania. Kończy się na 2000 jednostkach zawierających stary, mały radiator, ale działających z nowym profilem wentylatora o niskiej prędkości. Efektem jest termiczne wyłączenie w terenie, wszystko dlatego, że „Data Skuteczności” zmiany oprogramowania układowego była ustawiona na „Po zatwierdzeniu”, podczas gdy zmiana mechaniczna była ustawiona na „Wyczerpanie zapasów”.

Inżynieria zwykle działa dobrze. Tarcie pojawia się, gdy traktuje się inżynierię jako ciągły przepływ, podczas gdy produkcja odbywa się w dyskretnych migawkach. Traktując listę materiałów (BOM) jak repozytorium oprogramowania, zapraszasz chaos. Cofnięcie zmian w git nic nie kosztuje. Cofnięcie narzędzia formy wtryskowej lub złomowanie 5000 płytek drukowanych, ponieważ litera rewizji nie pasowała do szablonu, to błąd wart sześciocyfrową kwotę. Kolizja wielu ECO podczas zaplanowanej produkcji jest najczęstszą przyczyną „miękkiej” utraty wydajności. Nie zbudowałeś jednostki źle; po prostu zbudowałeś niewłaściwą jednostkę, ponieważ terminy się zderzyły.

Pułapka „Najnowszej Rewizji”

W nowoczesnym rozwoju sprzętu istnieje niebezpieczne założenie, że „najnowsza” wersja pliku to ta, którą należy zbudować. W systemie zarządzania cyklem życia produktu (PLM) plik może być „zatwierdzony” długo przed jego „wdrożeniem”. To właśnie ta luka pochłania pieniądze.

Inżynier siedzący w biurze w Austin widzi, że nowy projekt uchwytu jest zatwierdzony w systemie i zakłada, że następna jednostka z linii go będzie miała. Ale podłoga fabryczna działa na podstawie fizycznego zapasu, a nie statusu cyfrowego. Jeśli w magazynie jest 4000 jednostek starego uchwytu, domyślna logika fabryki to ich wykorzystanie, aby uniknąć marnotrawstwa. Jeśli ECO nie wymusza wyraźnie akcji „Oczyszczenia i złomowania”, „najnowsza” rewizja istnieje tylko na serwerze, a nie na linii.

To rozłączenie staje się śmiertelne, gdy wprowadzasz „Zwolnienie od Odchylenia”. Często konieczne zło w zarządzaniu łańcuchem dostaw, zwolnienie to formalne pozwolenie na tymczasowe złamanie zasad — być może na użycie zastępczego kondensatora podczas niedoboru lub pominięcie testu kosmetycznego, aby dotrzymać terminu wysyłki. Niebezpieczeństwo pojawia się, gdy te zwolnienia są traktowane jako papierkowa robota administracyjna, a nie zmiany inżynieryjne.

Zwolnienie jest w praktyce tymczasowym ECO z datą wygaśnięcia. Jeśli autoryzujesz odchylenie na użycie komponentu pochodzącego od pośrednika, ale nie powiążesz tego odchylenia z konkretnym zakresem numerów seryjnych w PLM, stworzyłeś bombę zegarową. Po sześciu miesiącach, gdy te komponenty zawiodą, nie będziesz wiedział, które jednostki je mają. Nie możesz wycofać tylko wadliwych, ponieważ dane nie istnieją. Bez konkretnej bramki wdrożeniowej fabryka domyślnie używa tego, co jest na półce, a „nadzieja” nie jest ważnym polem w dzienniku śledzenia.

Oprogramowanie układowe to komponent, a nie klimat

Najczęstszą ofiarą kolizji rewizji jest oprogramowanie układowe. Zespoły programistyczne są przyzwyczajone do ciągłej integracji; postrzegają kod jako żywą, rozwijającą się istotę, która z czasem się poprawia. Produkcja traktuje kod jak część, nie różniącą się od śruby czy rezystora. Jeśli binarka oprogramowania układowego nie ma wyraźnego numeru części i rewizji kontrolowanej w BOM, dla operatora linii praktycznie nie istnieje.

Rozważ scenariusz „Phantom Firmware”. Programista przesyła wersję 2.1 do repozytorium, aby naprawić krytyczny błąd. Jednak programiści fabryczni wgrywają binarkę znajdującą się w określonym folderze na serwerze testowym. Jeśli proces ECO nie instruuje wyraźnie inżyniera testów, aby zweryfikował nową sumę kontrolną i zaktualizował obraz programatora, fabryka będzie nadal wgrywać wersję 2.0 w nieskończoność. Jednostki przejdą test funkcjonalny, ponieważ limity testu prawdopodobnie nie zostały zaktualizowane, aby szukać nowego ciągu wersji.

Istnieje pokusa, aby polegać na aktualizacjach Over-the-Air (OTA), aby naprawić te problemy później. To niebezpieczne oparcie. OTA nie może naprawić urządzenia, które ulega uszkodzeniu natychmiast po uruchomieniu, ponieważ wersja bootloadera nie pasuje do mapy partycji aplikacji. Ponadto poleganie na aktualizacjach w terenie niszczy zdolność diagnozowania awarii. Jeśli klient zadzwoni do wsparcia z uszkodzonym urządzeniem, a zespół RMA nie może na podstawie numeru seryjnego określić, jaki kod został pierwotnie wgrany w fabryce, działają na ślepo. Nie wiedzą, czy ścigają defekt sprzętowy, czy błąd oprogramowania. Jeśli binarka nie ma numeru części, nie istnieje dla operatora linii, a na pewno nie pomoże twojemu zespołowi wsparcia.

Macierz dyspozycji

Najważniejszym polem w każdym ECO nie jest opis zmiany, lecz „Dyspozycja” starego materiału. To tutaj obliczana jest finansowa rzeczywistość zmiany. Wprowadzając nową rewizję, musisz uwzględnić materiał w czterech stanach: na stanie (w magazynie), w zamówieniu (w drodze od dostawców), WIP (praca w toku na linii) oraz wyroby gotowe (na dokach).

Dla każdej kategorii musisz podjąć binarną decyzję: użyć tak jak jest, przerobić, zwrócić do dostawcy lub złomować. To jest macierz dyspozycji. Wielu kierowników inżynieryjnych pozostawia tę sekcję pustą lub niejasną, pisząc rzeczy typu „Przerób, jeśli to możliwe.” To zaniedbanie obowiązków. „Przerób” oznacza godziny pracy, demontaż, potencjalne uszkodzenia innych komponentów i ponowne testowanie. Często koszt rozpakowania, otwarcia, odlutowania i ponownego wgrania jednostki przekracza marżę urządzenia.

Musisz wykonać obliczenia. Często taniej jest złomować $5 000 surowych PCB niż płacić za trzy dni przestoju linii, podczas gdy operatorzy próbują delikatnej przeróbki. Przeróbka to prawie zawsze fantazja; złom to cena jasności.

Protokół czystego zerwania

Aby zatrzymać straty, musisz wymusić „Czyste Przerwanie”. Zmiana stopniowa — gdzie nowe rewizje są mieszane w pojemniku ze starymi — jest dopuszczalna tylko dla części, które są 100% wymienne pod względem formy, dopasowania i funkcji, jak śruba od innego dostawcy. Dla wszystkiego innego potrzebujesz twardego cięcia.

Oznacza to określenie punktu cięcia nie według daty kalendarzowej, która jest niepewna, lecz według konkretnego kodu partii lub numeru seryjnego. „Rewizja B zaczyna się od SN: 100500.” Ta instrukcja pozwala fabryce oddzielić linię. Mogą dokończyć serię Rewizji A, oczyścić linię, usunąć stary zapas i rozpocząć Rewizję B z nową konfiguracją.

Wymaga to dyscypliny. Może oznaczać opóźnienie budowy o dwa dni, aby poczekać na nowe części, zamiast budować „hybrydowego” potwora. Ale to opóźnienie jest tańsze niż wycofanie produktu. Kontroluj punkt przerwania, albo punkt przerwania będzie kontrolować twoją marżę.