Fabryki zapominają, co już rozwiązały
Analiza przyczyn źródłowych z AI w produkcji opłaca się tylko wtedy, gdy zamkniętą sprawę da się odnaleźć. Oto co o tym decyduje.
Co naprawdę zmienia analiza przyczyn źródłowych z AI w produkcji
Analiza przyczyn źródłowych z AI w produkcji to wykorzystanie modelu, który pomaga inżynierowi przejść od wady do jej przyczyny i utrzymać całą sprawę w jednym zapisie. Nie wybiera przyczyny. Skraca dwie najwolniejsze części pracy, opis problemu i przeszukanie tego, co już próbowano, oraz decyduje, czy zakończoną sprawę da się wykorzystać ponownie.
Ta ostatnia część to ta, na podstawie której nikt nie kupuje. Jest też jedyną, której wartość się kumuluje.
Flota się uczy. Zakład odkłada do archiwum.
Dwa tygodnie temu nadzorowana jazda autonomiczna została dopuszczona na słoweńskie drogi. Był to szósty rynek w Unii Europejskiej, który ją zatwierdził.
Ten system nie doszedł do tego przez zmianę nazwy ani dlatego, że jeden model był sprytniejszy od poprzedniego. Doszedł do tego, bo flota odsyła dane. Każdy przejechany kilometr staje się czymś, co następna wersja może odczytać.
A teraz proszę stanąć w zakładzie i patrzeć, jak ta sama wada zostaje rozwiązana po raz trzeci.
Inżynieria nie jest gorsza. Ludzie nie są gorsi. Różnica polega na tym, co każda ze stron może zachować.
System jazdy zapisuje swoje doświadczenie w formie, z której następna wersja może skorzystać. Dział jakości zapisuje swoje doświadczenie w raporcie. Raport zostaje odłożony, podpisany i zarchiwizowany. Kolejny inżynier, który trafi na tę samą ścianę, zwykle nie wie, że raport istnieje, albo nie potrafi go znaleźć. Nauka kończy się na osobie, która wykonała pracę.
Raport zbudowano po to, by go podpisać
Wystarczy otworzyć dowolne archiwum 8D, a wzorzec jest ten sam. Raporty są kompletne. Są też nieczytelne jako dane.
Opis problemu to proza. Dowody leżą w załączniku. Działanie to jedno zdanie. Nazwa pliku to numer i data. Nic w nim nie odpowiada na pytanie, które naprawdę zadaje nowy inżynier, a które nigdy nie brzmi “pokaż mi raport 2024-118”, lecz zawsze “czy coś podobnego zdarzyło się już na tej maszynie”.
To nie jest brak dyscypliny. Formularz 8D zaprojektowano, by udowodnić klientowi, że problem został obsłużony. Nigdy nie projektowano go z myślą o tym, że przeczyta go następna sprawa.
Oto ta sama praca widziana dwa razy.
| Odłożony raport | Zapis sprawy do ponownego użycia | |
|---|---|---|
| Pisany dla | klienta i podpisu | następnego inżyniera |
| Opis problemu | proza, często krótsza niż trzy linijki | ustrukturyzowany, z tym, czym problem jest, a czym nie jest |
| Dowody | załączniki obok pliku | przypięte do przyczyny, którą potwierdzają lub wykluczają |
| Wyszukiwany po | numerze raportu i dacie | objawie, części, maszynie, kroku procesu |
| Weryfikacja | pole daty, często puste | zamknięta pętla, skuteczna lub nie |
| Wartość po zamknięciu | dowód, że sprawę obsłużono | dane wejściowe do następnej sprawy |
Ta tabela to cały argument. Obie kolumny opisują te same godziny pracy tych samych ludzi. Tylko jedną z nich da się wykorzystać ponownie.
Co zmierzyliśmy
Od stycznia do marca 2026 roku przeprowadziliśmy w ten sposób dziesięć reklamacji klientów ze słoweńskimi producentami, z pomiarem u ośmiu z nich. W tej próbie wszystko, co powstało podczas rozwiązywania, pozostało przypięte do sprawy i dało się potem odnaleźć: definicja problemu, wykluczone przyczyny, dowody i weryfikacja.
Źródło: próba pilotażowa, 10 reklamacji, słoweńscy producenci, od stycznia do marca 2026 roku, pomiar u 8 producentów.
To mała próba i mówimy o tym otwarcie. Wystarcza, by pokazać mechanizm, ale nie, by obiecać konkretną liczbę zakładowi, którego nigdy nie widzieliśmy.
Laptop
Zanim to wszystko się zaczęło, siedziałem przed laptopem, na którym było ponad 20 lat pracy jednego inżyniera. Za tydzień odchodził z firmy.
Każdy rozwiązany problem i każda nieudana próba leżały w plikach, które tylko on umiał odczytać. Nazwy folderów, które coś znaczyły dla niego. Arkusze bez wiersza nagłówka. Zdjęcia z nazwami plików z aparatu.
Nikt inny w tym budynku nie mógłby ich otworzyć i wiedzieć, co robić dalej. Firma jeszcze nie straciła tej wiedzy. Nigdy jej nie miała.
Narzędzie, które szybciej doprowadza zakład do przyczyny i zostawia za sobą ten sam stos plików, przesunęło problem, a nie go rozwiązało.
Co sprawdzić w poniedziałek
Proszę wyciągnąć ostatnią zamkniętą sprawę i przeprowadzić trzy kontrole, w tej kolejności.
Jeden. Poprosić kogoś, kto nad nią nie pracował, żeby ją znalazł, wychodząc od objawu i niczego więcej. Dać mu pięć minut.
Dwa. Przeczytać D2, opis problemu. Jeśli jest krótszy niż trzy linijki, sprawę zamknięto na podstawie domysłu, który okazał się trafny.
Trzy. Znaleźć datę weryfikacji. Jeśli pole jest puste, a raport zamknięty, pętla nigdy się nie zamknęła.
Jeśli sprawa nie przejdzie żadnej z trzech kontroli, następne wystąpienie tej wady będzie kosztować tyle samo co pierwsze. To cały koszt zapisu, którego nie da się odczytać.
Więcej na galileon.si
Źródła
- Slovenia clears Tesla’s FSD driver assistance, opublikowano 7 September 2026. AOL, za Reutersem
- Tesla FSD (Supervised) approved in Slovenia, its sixth EU market, 7 September 2026. We Talk Tesla