BOM w Excelu — dług techniczny z numerami części
BOM w arkuszu nie jest problemem dokumentacyjnym. To moment, w którym firma traci źródło prawdy o produkcie, a rachunek przychodzi w zakupach i serwisie.
BOM_final_v7_NEW_corrected_Marek.xlsx
To nie jest nazwa pliku. To log zmian, który nikt nie miał odwagi nazwać po imieniu. Siedem wersji, dwa dopiski “final”, jedno imię w środku, bo w pewnym momencie łatwiej było dopisać, kto ostatni to ruszał, niż ustalić, która wersja obowiązuje.
BOM w Excelu nie jest problemem dokumentacyjnym. Problem zaczyna się wtedy, gdy ktoś na podstawie tego pliku podejmuje decyzję, której nie da się cofnąć: zamawia część, uruchamia produkcję, wysyła serwisanta.
BOM to mapa tożsamości produktu, nie lista zakupowa
Dla zakupów BOM wygląda jak lista rzeczy do zamówienia. Dla produkcji jak instrukcja montażu. Dla serwisu jak spis części zamiennych. Wszyscy mają rację. I wszyscy widzą tylko swój fragment.
Naprawdę BOM odpowiada na jedno pytanie: czym ten produkt jest, dokładnie, co do numeru części i rewizji. Nie “mniej więcej co”, tylko dokładnie co, bo w hardware+software tolerancja, obudowa, firmware i zasilanie są ze sobą powiązane fizycznie, nie tylko na papierze. Zmiana jednego numeru części potrafi przesunąć termikę, zmienić certyfikację albo złamać kompatybilność z firmware’em, który nikt nie planował aktualizować.
Jeśli ta mapa nie ma jednego właściciela i jednej obowiązującej wersji, każdy dział rysuje własną. Rozjazd nie jest widoczny na co dzień: pliki się otwierają, liczby się zgadzają, projekt jedzie dalej. Widać go dopiero wtedy, gdy dwie wersje mapy muszą się spotkać w jednym fizycznym urządzeniu.
Cztery sposoby, w jakie Excel zaczyna kłamać
Nie chodzi o to, że arkusza nigdy nie da się zdyscyplinować. Excel w kontrolowanym repozytorium, z historią wersji i jasnym właścicielem, potrafi działać porządnie. Chodzi o to, że w większości firm nikt tego nie robi, a jeszcze rzadziej ktoś to sprawdza. Sam plik nie ma mechanizmu, który wymusiłby jedną wersję prawdy: nie ma locka rewizji, nie ma workflow zatwierdzania zmiany, nie ma alertu, że ktoś inny już to zmienił. To dokładnie te funkcje, które standard zarządzania konfiguracją ANSI/EIA-649 wymienia jako podstawę: identyfikacja, kontrola zmian, ewidencja statusu (po angielsku status accounting) i audyt. Bez świadomej dyscypliny arkusz żadnej z nich nie realizuje sam z siebie. Stąd cztery powtarzalne awarie.
Dwa działy mają dwie różne wersje. Inżynieria pracuje na najnowszej rewizji, bo właśnie poprawiła błąd. Zakupy zamawiają z wersji sprzed dwóch tygodni, bo nikt im nie wysłał nowej. Obie strony są przekonane, że mają rację, i formalnie mają, każda dla swojego pliku.
Dostawca zmienia komponent pod tym samym numerem. Numer katalogowy się zgadza, fizyczna wersja komponentu nie. Producent zmienia coś w środku bez zmiany numeru, bo dla niego to nieistotna korekta. Dla Twojego produktu to inna tolerancja, inny pobór prądu albo inny wymiar montażowy.
Produkcja zamawia “prawie to samo”. Brakuje komponentu na magazynie. Ktoś podstawia zamiennik o tej samej wartości nominalnej, bo “zawsze tak robili”. W arkuszu nic się nie zmienia, nikt nie edytował pliku, więc formalnie BOM się zgadza. Fizycznie produkt zszedł z linii już w innej konfiguracji, niż ta, którą testowano.
Serwis nie wie, która część pasuje. Urządzenie wraca po ośmiu miesiącach. Serwisant otwiera aktualny BOM i zamawia to, co tam widzi. Ale produkt zszedł z linii w innej konfiguracji niż ta, która dziś jest w pliku, bo między wysyłką a dzisiaj arkusz zdążył się zmienić bez śladu, która wersja trafiła do którego egzemplarza.
Koszt, który rośnie w milczeniu
Żaden z tych czterech scenariuszy nie boli od razu. Boli później, i to nieproporcjonalnie mocniej.
Analiza NASA i INCOSE z 2004 roku, oparta na rzeczywistych projektach hardware+software (satelita, samolot, statek kosmiczny), policzyła, o ile drożej kosztuje naprawa błędu w zależności od etapu, na którym go wykryto. Błąd złapany w fazie integracji i testów kosztuje 21 do 78 razy więcej niż złapany na etapie wymagań. Błąd, który wycieka do pola, do klienta, kosztuje od 29 do ponad 1500 razy więcej. To dane z projektów lotniczych i kosmicznych, nie z typowej firmy produkującej sterowniki czy czujniki, ale sam mechanizm (im później wykryjesz błąd, tym drożej kosztuje jego cofnięcie) nie jest specyfiką rakiet.
Potwierdza go z innej strony analiza AFIT z 2022 roku na 2434 realnych kontraktach obronnych USA: rzeczywista rezerwa budżetowa na zmiany inżynieryjne okazała się wyższa niż branżowa reguła kciuka (10% w fazie developmentu, 5% w produkcji i utrzymaniu). Realnie było to 13,25% w developmencie, 5,5% w produkcji i z powrotem w górę do 13,5% w fazie eksploatacji, gdy produkt jest już w polu. Faza developmentu jest droga z innych powodów, generuje z natury dużo zmian, ale dla produkcji i pola kierunek jest ten sam co w danych NASA: zmiana zrobiona, gdy produkt jest już u klienta, kosztuje więcej niż ta sama zmiana zrobiona na etapie produkcji.
To nie jest problem skali jednej firmy. Badanie Arena Solutions na 405 firmach produktowych (dostawcy systemu PLM, więc traktuj to jako kierunek, nie dziesiąte części procenta) pokazało, że prawie połowa z nich prowadzi BOM w arkuszu albo bez żadnego systemu. Wśród tych, które nie mają BOM połączonego z bazą dostawców, ponad połowa zgłasza opóźnienia produktu, a nieco mniej zamówienie złej części jako bezpośrednią konsekwencję.
Znana w branży “reguła 1-10-100” (błąd kosztuje 1x w projektowaniu, 10x w produkcji, 100x po wysyłce) krąży od lat jako skrót myślowy. Jej źródłem są wewnętrzne materiały szkoleniowe IBM z 1981 roku, nie badanie recenzowane. Kierunek się zgadza. Konkretne mnożniki lepiej czerpać z NASA i AFIT, nie z korporacyjnego sloganu.
Rezystor, który zmienił produkt
Produkt przeszedł pełne testy kwalifikacyjne. Konfiguracja zatwierdzona, dokumentacja zamknięta, seria ruszyła do produkcji.
Kilka miesięcy później zaopatrzenie zamówiło alternatywny rezystor: ta sama wartość nominalna, inny producent, inne parametry termiczne, których karta katalogowa nie eksponowała na pierwszej stronie. Nikt nie podjął złej decyzji świadomie. Dystrybutor oznaczył go jako zamiennik, a dział zakupów od lat zamawiał komponenty według tej samej logiki: ta sama wartość, ten sam package, kupuj taniej, jeśli się da.
Wewnętrzny numer części w BOM się nie zmienił. Formalnie to wciąż ta sama pozycja. Nikt nie zgłosił zmiany, więc nikt nie miał powodu zaktualizować rewizji ani poprosić inżyniera o zatwierdzenie. Operacyjnie produkt zszedł z linii w konfiguracji, której nikt nie testował w warunkach docelowych, a proces, który miał to złapać, nie miał się od czego odbić, bo formalnie nic się nie wydarzyło. Różnica ujawniła się dopiero w polu, przy podwyższonej temperaturze otoczenia, w reklamacjach, które support przez tydzień próbował powiązać z czymkolwiek innym niż komponent uznawany za “ten sam”.
Lesson learned: “zamiennik” w karcie katalogowej dystrybutora i “zamiennik” w kontekście przetestowanej konfiguracji produktu to dwa różne słowa, które przypadkiem się tak samo piszą. Jedno dotyczy komponentu osobno. Drugie dotyczy systemu, w którym ten komponent pracuje razem z resztą. BOM, który nie rozróżnia tych dwóch znaczeń, nie chroni przed niczym, nawet gdy nikt go formalnie nie złamał.
Minimalny standard przed launch
Dobry BOM odpowiada na pytania, zanim ktoś je zada w kryzysie: kto jest jego właścicielem, która wersja jest aktualna, co wolno podstawić zamiast czego i kto to zatwierdził. Nie trzeba do tego wdrażać PLM w tydzień przed premierą. Trzeba wymusić dyscyplinę, którą da się utrzymać nawet w arkuszu.
Osiem punktów, które powinny być jasne, zanim produkt wyjdzie z fabryki:
- jedna osoba (owner) odpowiada za to, która wersja jest obowiązująca
- każda zmiana ma datę, autora i powód w historii rewizji, nie tylko nowy numer w nazwie pliku
- lista dopuszczonych zamienników jest jawna, nie żyje w pamięci działu zakupów
- zmiana komponentu wymaga zatwierdzenia inżynieryjnego, nie tylko dostępności na magazynie
- wiadomo, które certyfikaty są powiązane z którą konfiguracją
- serwis ma dostęp do BOM zgodnego z tym, co faktycznie wyjechało z fabryki, nie z tym, co jest aktualne dziś
- komponenty zbliżające się do końca życia (EOL) są oznaczone, zanim znikną z rynku bez ostrzeżenia
- to, co widzi produkcja w systemie zamówień, zgadza się z tym, co widzi inżynieria w BOM
Przy kilku produktach i jednym zakładzie ta dyscyplina utrzyma się w arkuszu. Przy kilkudziesięciu SKU, kilku lokalizacjach i rotującym zespole zakupowym sam Excel przestanie wystarczać, ale to, co tu opisuję, jest warunkiem wstępnym każdego systemu, który go kiedyś zastąpi, nie jego zamiennikiem. Firma, która nie potrafi utrzymać tej dyscypliny w arkuszu, nie utrzyma jej też w PLM. Zapłaci tylko więcej za to samo bagno.
BOM żyje w Excelu, a produkt ma trafić do produkcji albo do serwisu w polu? Zanim zaczniesz skalować, sprawdź jedną rzecz: czy wszyscy w firmie pracują na tym samym pliku, i czy odpowiedź na to pytanie jest komuś znana z pewnością, czy tylko z założenia.
Jeśli odpowiedzią jest założenie, masz już dług techniczny z numerem części. Prędzej czy później ktoś go zamówi.
Jeśli Twój BOM żyje w arkuszu, a produkt rośnie szybciej niż dyscyplina wokół jego wersji, sprawdźmy to, zanim zrobi to klient.