Poka-yoke dla wiedzy: dlaczego FMEA pozostaje pusta

Przed laty pewien inżynier odmówił wpisania do FMEA tego, co wiedział.

Powiedział dlaczego, głośno, na spotkaniu. Spisanie tej wiedzy obniżyłoby jego własną wartość w firmie.

Jego odpowiedź była uczciwsza niż formularz, który trzymałem w ręku.

Zachęta, której nikt nie projektuje

Niemal w każdym zakładzie jest ktoś, do kogo dzwoni się, gdy staje konkretna maszyna. Jego wiedzy nie ma w żadnym dokumencie. Wszyscy o tym wiedzą i nikt tego nie naprawia.

Firma nagradza go za to, że wie to, czego inni nie wiedzą. Potem prosi go, żeby to spisał. Prosi go, by zmniejszył powód, dla którego się do niego dzwoni.

Eliyahu Goldratt ujął ten mechanizm w jednym zdaniu: powiedz mi, jak mnie mierzysz, a powiem ci, jak się zachowam. Tego inżyniera mierzy się tym, co tylko on potrafi rozwiązać. Zachowuje się dokładnie tak, jak się go mierzy.

Zwykłą odpowiedzią jest przypomnienie, szablon albo szkolenie. Wszystkie trzy zakładają, że problemem jest uwaga. Nie jest.

Co naprawdę powiedział Shingo

Shigeo Shingo wyznaczył granicę, którą większość działów jakości wciąż zaciera. Oddzielił błąd od wady. Ludzie popełniają błędy. Błąd staje się wadą dopiero wtedy, gdy nic go po drodze nie zatrzyma.

Jego wnioskiem nie było proszenie ludzi, by bardziej uważali. Uważność nie jest kontrolą. Zaprojektował krok tak, żeby błędnej czynności nie dało się dokończyć: gniazdo, które przyjmuje część tylko w jednej orientacji, przyrząd, który nie zamknie się, gdy brakuje podkładki.

Sens poka-yoke polega na usunięciu zależności od ludzkiej uwagi dokładnie w chwili, w której najłatwiej o jej brak.

Proszę spojrzeć w ten sam sposób na swoją FMEA. Jeśli dokument wypełnia się tylko wtedy, gdy ktoś o nim pamięta, czuje się hojny i ma wolną godzinę, system zależy od uwagi. Nie ma żadnej kontroli.

Dlaczego FMEA w Excelu umiera dwa razy

FMEA w arkuszu kalkulacyjnym zawodzi w dwóch osobnych miejscach, a drugie z nich wyjaśnia, dlaczego tak wiele z nich jest wypełnionych po brzegi, a i tak nikomu nie pomaga.

Zawodzi przy zapisie. Wpisywanie do niej to osobna czynność, po zakończeniu właściwej pracy. Konkuruje z kolejną reklamacją. Nie ma terminu, którego ktokolwiek by pilnował. Wypełnia się więc nierówno, głównie przez tych, którzy mają najmniej do stracenia.

Zawodzi przy odnajdywaniu. Nawet zapisane wiersze trudno potem odnaleźć. Inżynier, który potrzebuje ich pół roku później, nie wie, że plik istnieje, nie może przeszukać jego dwunastu wersji na SharePoincie i nie wie, która była aktualna. Wiedza jest więc zapisana w teorii i utracona w praktyce.

Ta druga porażka wyjaśnia, dlaczego zdania “wszystko już dokumentujemy” i “ten sam problem rozwiązujemy dwa razy w roku” są jednocześnie prawdziwe w tym samym zakładzie.

Co musi robić zabezpieczenie wiedzy

Jeśli uwaga nie jest kontrolą, muszą być spełnione cztery warunki. Żaden z nich nie dotyczy oprogramowania.

Zapis musi być produktem ubocznym pracy. Wiedza zostaje zapisana, bo sprawa została zamknięta, a nie dlatego, że ktoś o to poprosił po fakcie. Jeśli istnieje osobny krok, będą wyjątki, a wyjątki stają się regułą.

Zapis musi wskazywać swoje źródło. Przyczyna bez dokumentu, partii czy pomiaru, które za nią stoją, to opinia w ładnym formacie. Kolejny inżynier musi móc ją sprawdzić, a nie jej ufać.

Odnajdywanie musi następować w chwili potrzeby. Nie na żądanie, nie po wyszukiwaniu. Gdy opisuje się podobny problem, to, czego się już nauczono, musi przyjść razem z nim.

Osoba, która pisze, nie może płacić za pisanie. To ten warunek decyduje, czy trzy pozostałe w ogóle zadziałają. Jeśli dzielenie się wiedzą kosztuje status, system będzie omijany, choćby był najlepszy.

Co to daje

Właśnie to budujemy w Galileon. Nie miejsce na dokumenty i nie kolejny formularz. System, w którym każda zamknięta sprawa zasila następną.

Co to daje inżynierowi, zmierzone na naszej własnej próbie pilotażowej 10 reklamacji klientów u słoweńskich producentów, od stycznia do marca 2026 roku:

• Krok działań korygujących skraca się z trzech dni spotkań do około trzydziestu sekund na pierwszą propozycję, bo propozycje pochodzą z działań, które już zadziałały przy potwierdzonych przyczynach.
• Krok opisu problemu daje mniej więcej trzy razy więcej użytecznych podpowiedzi niż pusty szablon, bo zaczyna od podobnych przypadków zamiast od pustej strony.
• Pełna identyfikowalność od reklamacji klienta do działania zapobiegawczego, więc pytanie audytora “proszę pokazać, jak Państwo do tego doszli” ma odpowiedź, która już istnieje.

Czego inżynier nie robi: nie wypełnia bazy wiedzy. Zapis powstaje, bo sprawa została zamknięta.

Co zostaje przy inżynierze

Agenci będą zbierać dane tak, jak dziś zbierają je ludzie, i będzie ich znacznie więcej niż teraz. Ostatni krok nadal należy do człowieka.

Osąd, który się nie przesuwa, to myślenie analityczne i krytyczne, a widać go w czterech decyzjach:

• co nie należy do tego problemu
• co jest szumem, a co sygnałem
• gdzie interpretacja jest błędna
• które dane trzeba zebrać ponownie, na większej próbie

Im więcej danych, tym cenniejsza jest decyzja, które z nich naprawdę mówią coś o problemie.

Granica, którą warto wyznaczyć

Istnieje wersja tego wszystkiego, w której każda firma buduje własne narzędzie. Kod jest dziś tani, więc powstają rzeczy, które powinny zostać odrzucone, a efektem jest produkt z wieloma funkcjami i bez serca włożonego w którąkolwiek z nich.

Pytanie, które warto zadać, zanim to się zacznie, brzmi: która część jest naprawdę Państwa domeną, a którą lepiej zostawić ludziom, którzy zajmują się nią na co dzień, mają znacznie więcej danych i dostarczą coś lepszego niż wewnętrzne MVP?

Odpowiedź należy do Państwa. Warto jej udzielić świadomie, a nie siłą rozpędu.

Więcej na galileon.si

• Dwa lata na opisanie jednej wady: czego akcja przywoławcza Toyoty uczy o definiowaniu problemu - co dzieje się wcześniej, gdy problem nigdy nie zostaje opisany na tyle dobrze, by analiza się trzymała.
• Jak działa SolveR
• Bezpieczeństwo danych

Źródła

• Shigeo Shingo, Zero Quality Control: Source Inspection and the Poka-Yoke System, Productivity Press, 1986. Strona wydawcy
• Eliyahu M. Goldratt, o pomiarze i zachowaniu. Goldratt Consulting