Bezpiecznik w garażu wybija Ci trzeci raz w tym miesiącu. Wchodzisz do skrzynki, podnosisz pstryczek, światło wraca, wracasz do roboty. Działa? Działa. Rozwiązałeś problem? No właśnie. Podniesienie pstryczka to zwykły reset. A różnica między resetem...
Bezpiecznik w garażu wybija Ci trzeci raz w tym miesiącu. Wchodzisz do skrzynki, podnosisz pstryczek, światło wraca, wracasz do roboty. Działa? Działa. Rozwiązałeś problem?
No właśnie.
Podniesienie pstryczka to zwykły reset. A różnica między resetem a realnym rozwiązaniem to przepaść. Na Twojej hali produkcyjnej wygląda to identycznie, maszyna staje, operator chwilę się zastanawia, robi restart i cyk, jedzie dalej. Na koniec zmiany nikt nic nie wie, sytuacja sama wróciła do „normy”. I tak co drugi dzień, przez pół roku, aż w końcu komuś puszczą nerwy, usiądzie z Excelem albo jakimś AI-em i policzy te wszystkie „chwilki”, wyjdzie mu, że linia przez miesiąc stała łącznie dwie zmiany.
Nie będę Ci tutaj tłumaczył, jak wypełnić raport 8D ani jak narysować diagram Ishikawy. Tego jest w internecie na pęczki, a porządnie i po kolei przerabiamy to w szkoleniu. Chcę się pochylić nad pytaniem, które słyszałem na hali zbyt wiele razy:
Po co mi w ogóle te całe systemy, skoro ja wiem, co się zepsuło, i umiem to naprawić?
I wiesz co? To jest bardzo dobre pytanie i zasługuje na poważną odpowiedź.
- Naprawiać umie każdy, różnica między resetem a rozwiązaniem
- Powód pierwszy: Twój mózg to fatalny analityk przyczyn
- Powód drugi: organizacja bez narzędzi nie ma pamięci
- Powód trzeci: wspólny język, zanim klient go wymusi
- Powód czwarty: matematyka, czyli argument dla Twojego szefa
- Uczciwość: czego narzędzia NIE załatwią
Naprawiać umie każdy
Zacznijmy od postawienia sprawy jasno. Ludzie na produkcji naprawdę umieją naprawiać. Utrzymanie ruchu wymieni siłownik, ustawiacz skoryguje parametry, operator wyczyści czujniki i wszystko wróci do normy. Jeżeli ktoś Ci mówi, że bez formularza A3 nikt na hali nie potrafi nic zrobić, to kłamie.
Problem niestety polega na czymś innym. Samo naprawianie odpowiada na pytanie „co się zepsuło”, a rozwiązywanie problemów odpowiada na pytanie „dlaczego się zepsuło i co zrobić, żeby się nie zepsuło znowu”. Pierwsze przywraca stan sprzed awarii, drugie zmienia proces tak, żeby stan sprzed awarii był na tyle stabilny, aby ta już nie wróciła.
Wracamy do bezpiecznika. Możesz go podnosić do końca życia, ba! Możesz go nawet wymienić na mocniejszy! Z tym, że to będzie moment w którym „naprawa” zrobi się bardzo niebezpieczna, bo być może na tym obwodzie wisi coś, co za chwilę zacznie grzać przewody w ścianie (Nigdy tego nie rób, to po prostu przykład głupoty!). Dopiero jak usiądziesz i sprawdzisz, co właściwie jest podpięte do tego obwodu, kiedy dokładnie wybija i co się wtedy dzieje w garażu, dopiero wtedy masz szansę odkryć, że pstryczek leci zawsze wtedy, gdy lodówka rusza z kompresorem w momencie, w którym pracuje spawarka. I że rozwiązaniem nie jest ani podnoszenie pstryczka, ani mocniejszy bezpiecznik, tylko rozdzielenie obwodów.
No i tutaj dochodzimy do meritum, no bo popatrz. Zebrałeś dane (kiedy wybija), poszukałeś korelacji (co wtedy pracuje), postawiłeś hipotezę i ją sprawdziłeś. Gratulacje, właśnie zrobiłeś analizę przyczyny źródłowej. Bez formularza, bez szkolenia, na własnym garażu. Narzędzia problem solvingu nie są niczym więcej niż spisaniem tego sposobu myślenia w formie, która nie pozwala Ci pójść na skróty.
No i tu dochodzimy do sedna, bo w sumie po co spisywać coś, co przecież „każdy, na chłopski rozum, robi sam z siebie”?
Powód pierwszy: Twój mózg to fatalny analityk przyczyn
Przykra wiadomość, niestety nie robi. Ja też nie robię, Ty też nie robisz. Mózg inżyniera po czternastu latach na produkcji jest wytrenowany w błyskawicznym dopasowywaniu wzorców, widzisz defekt i w głowie od razu masz odpowiedź, bo „to samo było w 2019″ – a to było już prawie dekadę temu (WTF?!). Ta intuicja jest bezcenna, ale jednocześnie jest Twoim największym wrogiem. Pierwsza hipoteza, która przychodzi do głowy lubi zamknąć Ci oczy na wszystko dookoła. A tutaj tak naprawdę cała analiza powinna się rozpocząć.
Najczęstszy objaw tej choroby znasz doskonale, „to na pewno monter”. Wina człowieka jest zawsze najwygodniejszą przyczyną, bo nie wymaga grzebania w procesie, dokumentacji ani we własnych decyzjach projektowych. Przeszkolimy, uczulimy, dopiszemy punkt do instrukcji i temat zamknięty (Cyk i pora na CS’a). Do zobaczyska!
Narzędzia typu 5 Why czy Ishikawa nie są mądrzejsze od Ciebie. One robią jedną jedyną rzecz, zmuszają Cię do zwolnienia w momencie, w którym każdy instynkt każe Ci przyspieszyć. Zadanie piątego „dlaczego” boli, bo przy trzecim już masz wygodną odpowiedź. Rozrysowanie wszystkich gałęzi diagramu boli, bo przecież „wiadomo, że to materiał”. Ale to właśnie w tych bolesnych, pozornie zbędnych krokach siedzą przyczyny, których nie widać na pierwszy rzut oka.
Powód drugi: organizacja bez narzędzi nie ma pamięci
Wyobraź sobie, że macie w zakładzie Pana Zenka z utrzymania ruchu. Pan Zenek pracuje dwadzieścia lat i wie wszystko. Wie, że prasa numer trzy nie lubi poniedziałków, że przy tym jednym produkcie trzeba podnieść temperaturę o pięć stopni, bo inaczej sypie defektami, i że czujnik na stacji siódmej trzeba przecierać co zmianę, choć nikt nie wie dlaczego.
A teraz wyobraź sobie, że Pan Zenek odchodzi na emeryturę.
Cała ta wiedza, dwadzieścia lat rozwiązanych problemów, wychodzi z zakładu razem z nim. Każdy z tych problemów był tylko i wyłącznie w jego głowie, więc wasza organizacja będzie je rozwiązywać od nowa, płacąc za to drugi raz pełną cenę, przestojami, brakami, nerwami, a w rezultacie realnymi pieniędzmi!
Wypełniony raport 8D czy A3 wydaje się biurokracją dokładnie do momentu, w którym nowy inżynier procesu dostaje defekt, wpisuje go w archiwum i znajduje analizę sprzed czterech lat. (Ba, dzisiaj to se zmapujcie wszystkie 8D czy A3 jakimś LLM-em to nawet szukać nie trzeba będzie) Z przyczyną, z działaniami, z weryfikacją skuteczności. Godzina czytania zamiast trzech tygodni odkrywania koła na nowo. Dokumentacja z problem solvingu to jest pamięć długoterminowa Twojej organizacji. Firmy, które jej nie budują, są skazane na wieczne rozwiązywanie tych samych problemów, tylko za każdym razem przez inne osoby.
Powód trzeci: wspólny język, zanim klient go wymusi
Jeżeli pracujesz w automotive, to dobrze wiesz, że pytanie „czy używać 8D” jest czysto teoretyczne. Przy pierwszej poważnej reklamacji klient zażąda raportu 8D i nie będzie go interesowało, czy Wasza firma „wierzy” w tę metodykę. Pytanie brzmi tylko, czy pierwszy raz w życiu będziecie go tworzyć z oddechem klienta na karku i z zegarem tykającym nad głową, czy będzie to dla Was drobnostka.
Ale z drugiej strony sprawa jest głębsza niż wymagania klienta. Ustrukturyzowana metoda daje wam wspólny język. Kiedy jakość, utrzymanie ruchu, produkcja i technolog siadają nad problemem bez żadnej struktury, każdy przynosi swoją wersję wydarzeń i spotkanie zamienia się w ustalanie, kto zawinił (tak zwane 5 who). Kiedy siadają nad wspólnym formularzem, rozmowa leci według planu, co się stało, co wiemy na pewno, co jest hipotezą, kto co sprawdza do kiedy. Formularz nie rozwiązuje problemu, ale usuwa tarcie między działami, bo wszyscy patrzą na proces, a nie na siebie nawzajem.
Powód czwarty: matematyka, czyli argument dla Twojego szefa
Na koniec argument, który najlepiej działa na zarządzających. Problem powracający to koszt cykliczny. Płacisz za niego co tydzień, co miesiąc, w nokach, przestojach, nadgodzinach i sortowaniu. Porządna analiza przyczyny źródłowej to koszt jednorazowy. Kilka godzin zespołu, czasem jakaś próba, czasem drobna inwestycja w oprzyrządowanie.
Policz to kiedyś dla jednego z powracających cały czas problemów, takiego, o którym wszyscy wiedzą, wszyscy przywykli i nikogo on już nawet nie rusza. Weź koszt braków i przestojów z ostatnich sześciu miesięcy i zestaw z szacowanym kosztem porządnego rozwiązania. Ten rachunek prawie zawsze wychodzi na korzyść rozwiązania, a mimo to problem żyje, bo koszt cykliczny jest rozsmarowany po budżecie tak cienko, że nikt go nie widzi w całości. Narzędzia problem solvingu, przez sam fakt rejestrowania problemów, sklejają ten rozsmarowany koszt w jedną liczbę. A jedna liczba na slajdzie potrafi odblokować budżet, o który prosiłeś od roku.
Uczciwość: czego narzędzia NIE załatwią
Żebyśmy się dobrze zrozumieli, bo nie chcę tutaj mydlić Ci oczu, że formularz zbawi Ciebie i Twoją fabrykę.
Narzędzie nie zastąpi myślenia. Raport 8D wypełniony „bo musieliśmy” z przyczyną źródłową wpisaną w kwadrans przed wysyłką do klienta, jest gorszy niż brak raportu, bo tworzy iluzję, że problem został przeanalizowany. No i zamyka temat, który powinien zostać otwarty. Widziałem takie raporty. Pewnie Ty też. Sekcja root cause: błąd operatora, działanie: przeprowadzono szkolenie. To jest pudrowanie gó**a, a nie analiza.
Narzędzie nie zadziała też w kulturze polowania na winnych. Jeżeli w Twojej firmie zgłoszenie problemu kończy się szukaniem nazwiska, to ludzie przestaną zgłaszać problemy i żadna metodyka tego nie przeskoczy. To jest chyba najważniejszy punkt całego artykułu.
Zamiast zakończenia
Wróćmy ostatni raz do garażu. Pstryczek bezpiecznika możesz podnosić w nieskończoność i przez większość czasu nic złego się nie stanie. Narzędzia problem solvingu istnieją dla tego jednego razu, kiedy zamiast wybić bezpiecznik, stopi Ci się przewód w ścianie.
Pozdrawiam Łukasz Szyndrowski
Źródła i przypisy
- Grafika „widzenie tunelowe”: samatters.com — Understanding Stress Part 5: Tunnel Vision
- Szkolenie z rozwiązywania problemów (8D, 5 Why, Ishikawa): zgodniezprocesem.pro
