|
W 2019 roku, na hali produkcyjnej pod Wrocławiem, kierownik zmiany z dumą pokazał mi nową instrukcję TPM.
„Mieliśmy problem z zacinającą się maszyną pakującą. Wprowadziliśmy standard: co dwie godziny operator musi ją przedmuchać sprężonym powietrzem. Problem rozwiązany”.
Trzy miesiące później maszyna stanęła na dobre, a koszt naprawy wyniósł kilkadziesiąt tysięcy złotych.
Większość firm rozwiązuje problemy tak, jakby brała tabletkę przeciwbólową na złamaną nogę. Ból znika na chwilę, więc ogłaszamy sukces. Zespoły wdrażają działania naprawcze, które w rzeczywistości są tylko maskowaniem objawów. I właśnie dlatego te same awarie, błędy jakościowe i opóźnienia wracają ze zdwojoną siłą.
Właściwe pytanie nie brzmi: jak szybko potrafimy ugasić pożar.
Właściwe pytanie brzmi: dlaczego w ogóle pozwalamy, żeby pożar wybuchł.
I tu jest sedno: dopóki nie nauczysz się odróżniać objawu od przyczyny źródłowej, będziesz tylko strażakiem we własnej firmie.
Wspomniana maszyna pakująca była wąskim gardłem całego procesu. Przedmuchiwanie jej co dwie godziny faktycznie sprawiało, że czujniki optyczne przestawały wariować. Operatorzy byli zadowoleni, bo maszyna działała. Kierownictwo było zadowolone, bo wskaźnik OEE na chwilę wzrósł.
Ale na Gembie tam, gdzie procesy naprawdę działają zadaliśmy inne pytanie. Dlaczego w ogóle musimy przedmuchiwać tę maszynę?
Zeszliśmy do poziomu procesu.
Okazało się, że pył, który osiadał na czujnikach, pochodził z kartonów gorszej jakości, które dział zakupów zaczął zamawiać miesiąc wcześniej, żeby zaoszczędzić 5 groszy na sztuce.
Ta „oszczędność” kosztowała firmę nie tylko czas operatora (15 minut co dwie godziny), ale ostatecznie doprowadziła do zatarcia głównego łożyska maszyny, w które wnikał ten sam pył.
Dlaczego to zadziałało w ten sposób? Bo zatrzymaliśmy się na pierwszym „dlaczego”.
W Lean mówimy o Root Cause Analysis (Analizie Przyczyn Źródłowych).
Objaw to to, co widzisz (maszyna staje).
Bezpośrednia przyczyna to to, co wywołało objaw (zabrudzony czujnik). Jednak przyczyna źródłowa to proces, który na to pozwolił (zmiana dostawcy bez testów jakościowych). Jeśli usuniesz tylko bezpośrednią przyczynę, problem wróci w innej formie.
To brzmi jak: wystarczy zadać pięć razy „dlaczego” i po sprawie. Ale w praktyce, bez standardu, 5 Why zamienia się w szukanie winnego. Zamiast pytać „dlaczego proces zawiódł”, pytamy „kto to zepsuł”. I tu pojawia się sceptyk, który mówi: „Nie mamy czasu na filozofowanie, musimy produkować”.
Ma rację, ale produkcja z ukrytą wadą to nie produkcja, to generowanie strat.
Sztuka rozwiązywania problemów nie polega na wypełnianiu skomplikowanych formularzy. Polega na zmianie sposobu myślenia.
Oto co możesz zrobić od jutra, żeby przestać leczyć objawy:
→ Krok 1. Zdefiniuj problem w liczbach. Zanim zaczniesz szukać rozwiązania, opisz problem. Zamiast „maszyna się psuje”, napisz „maszyna X zatrzymuje się średnio 4 razy na zmianę, co powoduje 60 minut przestoju”.
→ Krok 2. Idź na Gembę. Nie rozwiązuj problemów zza biurka. Idź tam, gdzie problem występuje. Zobacz go na własne oczy. Porozmawiaj z operatorem, ale nie pytaj go, co się zepsuło. Zapytaj, jak wygląda standardowa praca.
→ Krok 3. Oddziel człowieka od problemu. Kiedy robisz 5 Why, nigdy nie kończ na „błąd operatora”. Błąd człowieka to objaw złego procesu, braku szkolenia lub niejasnego standardu.
→ Krok 4. Wdróż standard, nie tylko poprawkę. Jeśli znalazłeś przyczynę źródłową i ją usunąłeś, zaktualizuj instrukcję pracy. Jeśli tego nie zrobisz, nowy pracownik popełni ten sam błąd.
Porządek to skutek dobrego procesu, nie jego przyczyna. Jeśli Twój proces rozwiązywania problemów opiera się na łataniu dziur, zawsze będziesz miał dziurawe wiadro.
P.S. Piszę ten artykuł to po analizie kolejnego raportu 8D u klienta, w którym w rubryce „przyczyna źródłowa” wpisano „nieuwaga pracownika”. Zmiana tego jednego nawyku myślowego to najtrudniejsza, ale najbardziej opłacalna część transformacji. | 
