Metodologia Problem Solving cz. 1, Definiowanie problemu

Zwykło się przyjmować, że istotą rozwiązania problemu jest zrozumienie przyczyny źródłowej jego występowania. I tak, częściowo jest to stwierdzenie prawdziwe, ponieważ określenie właściwej przyczyny źródłowej doprowadzi do dobru odpowiednich działań korygujących. Te z kolei spowodują usunięcie przyczyny źródłowej występowania problemu, co ostatecznie pozwoli na usprawnienie funkcjonowania procesów.

Niestety, w swojej karierze zaobserwowałem również, że bardzo często bagatelizuje się kwestię związaną z odpowiednim zrozumieniem i opisaniem samego problemu, z którym przychodziło się mierzyć różnym zespołom. Jeśli nawet analizę wykonano przy zastosowaniu znanych metod i narzędzi rozwiązywania problemów, to okazywało się, że ostatecznie problem nie był eliminowany. Co stało za takim stanem rzeczy? Wbrew pozorom odpowiedź okazywała się zaskakująco prosta. Nadmierne skupienie uwagi jedynie na definiowaniu przyczyn źródłowych, a nie zrozumieniu istoty problemu, prowadziło do sytuacji, w której problem nie był faktycznie rozwiązywany. 

Za taki stan rzeczy odpowiadała sekwencja wykonywanych czynności podczas prowadzonej analizy problemu. Jeśli nawet zaplanowane działania korygujące faktycznie nastawione były na eliminację przyczyn źródłowych występowania problemu, o tyle same przyczyny nie były właściwie zdefiniowane, a dokładniej mówiąc: nie były związane z faktycznie występującym problemem. Sytuacja taka jest skutkiem braku właściwego zrozumienia, co jest faktycznie problemem.  

Od czego zacząć analizę problemu?

Jak zaprezentowano na grafice po lewej stronie, pierwszym etapem  podejmowanym w procesie analizy problemu jest krok mający na celu zdefiniowanie problemu. I na nim będzie skupiała się nasza uwaga w dalszej części artykułu. Nie będzie to jednak jedynie jego zatytułowanie, ale również dokładne opisanie i zrozumienie. Na tej podstawie będziemy mogli zdefiniować również odpowiednie zasoby niezbędne do przeprowadzenia dalszych etapów analizy problemu. W tym oczywiście mówimy o zasobach ludzkich – posługując się bardziej przyjaznym językiem, członków zespołu. Ci będą potrzebni zarówno do zapewnienia odpowiednich informacji i danych płynących z procesów, jak i do skoordynowania działań w dalszym etapie prowadzenia analizy Problem Solving. Wiemy zatem, że określenie zespołu jest efektem zrozumienia problemu, przejdźmy więc do praktycznego przedstawienia sposobu prowadzenia analizy problemów.  W tym celu posłużę się rzeczywistymi przykładami, które pozwolą na łatwiejsze zrozumienie, jak poszczególne etapy opisania problemu będą prowadzone. Posłując się przykładem, przedstawię również, w jaki sposób skutecznie zastosować jedno z bardziej przydatnych narzędzi, które wspomaga zarówno sam proces opisania problemu, jak i jego właściwego zrozumienia.

Zrozumienie problemu

„Firma X, otrzymała 4 lipca bieżącego roku informację pochodzącą od klienta, zgłoszenie dotyczące problemów z partią wyrobów dostarczonych do firmy Y. W zgłoszeniu reklamacyjnym zaznaczono, że partia wyrobów dostarczona do 25 czerwca miała nieczytelne kody, uniemożliwiające zarejestrowanie wyrobu w systemie, a co za tym idzie brak możliwości procesowania komponentów w procesie produkcyjnym firmy Y. Na podstawie zleconej akcji sortowania klient – firma Y – odkrył, że wspomnianą wadą obciążone jest 10% dostarczonych wyrobów. W związku z powyższym, firma Y zdecydowała się wprowadzić również kontrolę następnej dostawy z 2 lipca, w której wykryto kolejne 15% niezgodnych części. Według firmy Y obie dostarczone partie wyrobów pochodziły z tego samego okresu produkcyjnego firmy X, 22 czerwca br.”

Analizując ten przykład, można dostrzec, co jest problemem. Ale czy faktycznie tak jest? Czy otrzymanie reklamacji na nieczytelny kod jest problemem? Czy jest nim fakt, że klient nie może zarejestrować produktów w swoim systemie? A może problem jest ukryty gdzieś głębiej? Czy informacja o tym, co jest problemem, to wszystko, na co powinniśmy zwrócić uwagę? 

A co, gdybyśmy zamiast zadawania pytania „czy?” wprowadzili w to miejsce narzędzie 5W2H, które wspomaga proces definiowania problemów? Spróbujmy więc wykorzystać dobrodziejstwo tego narzędzia, rozkładając tym samym nasz przykład na czynniki pierwsze.

What? (1W) – Co jest problemem? W naszym przykładzie problemem dla firmy X z pewnością będzie fakt otrzymania reklamacji od klienta. Jednakże opisując problem, musimy spojrzeć oczami klienta, czy to wewnętrznego, czy zewnętrznego. I o ile dla samego klienta, firmy Y, faktycznie problemem będzie brak możliwości rejestracji wyrobów, to z punktu widzenia prowadzonej analizy problemem są nieczytelne kody na wyrobach dostarczonych z naszej firmy. Sam brak możliwości zarejestrowania wyrobów przez firmę Y w tym konkretnym przykładzie będzie natomiast skutkiem, który będziemy opisywać przy wykorzystaniu kolejnego – drugiego już Why?

Why? (2W) – Dlaczego jest to problem? Skoro wiemy, co jest problemem, musimy zrozumieć, dlaczego dla firmy Y jest to problem. Wczytując się w nasz przykład, łatwo możemy dostrzec, że problem nieczytelnych kodów prowadzi do braku możliwości zarejestrowania części w systemie, a w efekcie braku możliwości procesowania komponentów. Z punktu widzenia klienta możemy również odczytać przekaz, że sytuacja ta może doprowadzić do zatrzymania procesu u klienta, z tytułu braku części lub też ograniczenia wydajności jego procesów. Jest to o tyle istotne, że warto zaraz po zakończeniu definiowania istoty problemu skontaktować się z klientem w celu wypracowania odpowiedniego systemu dalszego postępowania, który pozwoli na uzupełnienie braków oraz zabezpieczenie procesu klienta.

Who? (3W) – Kto zgłosił / Kto znalazł? W tym przypadku jasne jest, że problem dotyczy klienta, firmę Y, która podniosła problem do poziomu reklamacji. W przypadku, kiedy problem będzie jednej organizacji, wówczas odpowiednio zaznaczamy obszary lub procesy, które są dotknięte problemem. Where? (4W) – Gdzie powstał? Jest to jedno z najistotniejszych pytań, dla którego odpowiedź pozwala nam na określenie obszaru dalszej analizy. Z omawianego przykładu wiemy, że problem powstał w firmie X i został on wygenerowany na obszarze / linii / maszynie odpowiedzialnej za znakowanie wyrobu. Jeśli jesteśmy w stanie określić w łatwy sposób, która to była maszyna, to jesteśmy w stanie szybko zareagować. W przeciwnym razie wymagane jest zdefiniowanie zespołu, który nie tylko dostarczy nam właściwych danych  z procesu, ale również odpowiednich informacji na temat funkcjonowania samego procesu, tego, czy były awarie, zmiany wprowadzane w procesie itp., czyli wszystko to, co przyda się na etapie definiowania przyczyn źródłowych.  Dlatego też warto w tym przypadku zaangażować do współpracy zarówno właściciela danego procesu, którego problem dotyczy, jak i wszystkie funkcje wspierające (inż. procesu, technologa, inż. jakości itp.) oraz pracowników pracujących na danym obszarze / maszynie.  When? (5W) – Kiedy problem wystąpił? Kiedy został zgłoszony? W tym przypadku warto odnieść się do obu dat, jeśli mówimy o reklamacji. Pozwoli to na uszczegółowienie okresu i wielkości partii wyrobów, która może być potencjalnie dotknięta problemem. Dodatkowo pozwoli nam też na uszczegółowienie danych, jakie potrzebujemy zgromadzić z procesu, aby dowiedzieć się, co może być potencjalną przyczyną w dalszym procesie analizy. Dzięki temu ograniczymy chaos informacyjny oraz nie będziemy marnować czasu na przeszukiwanie szerszego okna procesowego.

Posługując się naszym przykładem, wiemy, że problem został zgłoszony 4 lipca, natomiast został wykryty w partiach dostarczonych do klienta 25 czerwca i 2 lipca. Wiemy też, że problem dotyczy partii wyprodukowanej przez firmę X 22 czerwca. Na podstawie tych danych wiemy już, że problem może dotyczyć wszystkich wyrobów, które były produkowane od 22 czerwca do 4 lipca, a punktem zapalnym była produkcja z 22 czerwca. 

Czy kolejność poszczególnych elementów 5W ma znaczenie? Ogólnie nie ma jednej przyjętej z góry zasady, jednakże przedstawiona sekwencja pozwala przejść od ogółu do szczegółu, dzięki czemu pozwala mi na łatwiejsze usystematyzowanie wszystkich niezbędnych informacji.

Kluczowe jest to, aby odpowiedzieć wyczerpująco na wszystkie z 5W.

Ok, a co z pozostałymi dwoma elementami? Jak czytać i rozumieć 2H?

How many? (1H) – Jak dużo? Ile faktycznie części było uszkodzonych / dotkniętych problemem? Pozwala to na określenie skali problemu i odpowiedzenie sobie na pytanie, czy mamy do czynienia z jednostkowym przypadkiem, czy jednak z problemem seryjnym. 

W naszym przypadku wiemy, że problem dotyczył odpowiednio 10% i 15% wyprodukowanych i dostarczonych wyrobów. Na podstawie danych z procesu możemy przeliczyć to na wartość bezwzględną (liczbową) i określić, jak duża ilość uszkodzonych wyrobów znajdowała się w partii produkcyjnej z 22 czerwca.

How? (2H) – Jak? Jest to pytanie, który przysparza najczęściej kłopotów w chwili prowadzenia analizy problemu, ze względu na jego otwartą formę. Za pytaniem „jak?” może kryć się wiele bardziej szczegółowych pytań, np. „Jak problem powstał?”, „Jak problem został wykryty?”, „Jak często problem się pojawia?”, „Jak problem został określony?”

Pytanie „Jak problem powstał?” na tym etapie prowadzenia analizy możemy porzucić. Po to właściwie prowadzimy analizę problemu, żeby wykryć faktyczne przyczyny występowania problemu.

Dlatego też zachęcam do stosowania pozostałych pytań jak?, w zależności od informacji, jakich potrzebujemy. W naszym przykładzie jesteśmy w stanie wykorzystać to pytanie do określenia częstotliwości: problem wystąpił w  dwóch dostawach z 25 czerwca i 2 lipca.

Dodatkowo dostajemy odpowiedź na pytanie, jak został wykryty. I tutaj mamy przede wszystkim informację, że problem został wykryty u klienta, podczas akcji sortowania. Można przyjąć, że była to kontrola wizualna. Możemy również założyć, że pierwsza seria błędów została wykryta na etapie procesowania przez klienta. Warto oczywiście doprecyzować, w jaki sposób klient określił nieczytelność kodów i czy była to ocena wizualna prowadzona przez człowieka, czy ocena automatyczna. Te informacje będą również istotne podczas chociażby określania działań korygujących. 

Ale pytanie „Jak?” możemy wykorzystać również do tego, by „wymusić” odtworzenie powstania problemu w procesie. Dzięki temu będzie możliwe dostarczenie dodatkowych odpowiedzi na temat tego, jakie zjawiska muszą zaistnieć, aby dany problem został wytworzony. Takie podejście stosowane jest często podczas analizy problemu prowadzonej chociażby za pomocą metody DMAIC, ale zdarzało mi się również przeprowadzać doświadczenia / eksperymenty na etapie określania problemu, pracując z problemami przy wykorzystaniu metody 8D.

Co z problemami wewnątrz organizacji?

Niezależnie od tego, czy mówimy o problemach wewnętrznych (reklamacjach klienta wewnętrznego), czy zewnętrznych (reklamacje klienta / odbiorcy zewnętrznego), sposób postępowania pozostaje niezmienny.

Dla lepszego zrozumienia posłużymy się innym przykładem wziętym z życia codziennego.

„W procesie obróbki mechanicznej z wykorzystaniem maszyny CNC dla partii komponentów AHA 255-151-169 DB pominięty został proces nawiercenia i gwintowania jednego z otworów montażowych. Brak otworów spowodował brak możliwości montażu komponentu w wyrobie gotowym całej partii komponentów dostarczonych z działu obróbki mechanicznej na dział montażu. W efekcie zaistniałego problemu cała partia została wycofana do procesu obróbki ze skrawaniem, celem ponownego przeprocesowania i nawiercenia brakujących otworów wraz z gwintowaniem”.

Ok. Czego w takim przypadku jesteśmy w stanie się dowiedzieć? Wiemy już, że nie mamy dwóch podstawowych informacji, daty wystąpienia oraz ilości. Czy w takim układzie jesteśmy w stanie opisać problem za pomocą narzędzia 5W2H? Spróbujmy…

I tutaj zatrzymajmy się na chwilę. Wiemy, że problem został wychwycony przez operatora. Ale nie wiemy, przez którego operatora dokładnie. Ponadto brakuje nam jeszcze dwóch zmiennych do opisania błędu. 

Dobrą praktyką będzie więc wyjście do GEMBA – a więc miejsca powstania problemu – w celu złapania wszystkich niezbędnych danych. Dzięki temu będzie możliwe zebranie wszystkich kluczowych danych i informacji (GENJITSU) oraz przeanalizowanie wadliwych sztuk (GEMBUTSU).

Kontynuując proces opisania przykładowego problemu, kolejne etapy przy wykorzystaniu narzędzia 5W2H będą wyglądały następująco:

Czy zawsze stosować 5W2H?

Narzędzie to nie jest obligatoryjne podczas prowadzenia analizy problemu. Nie jest też narzucone przez żadną ze znanych metod Problem Solving. Warto jednak zapamiętać jedną rzecz. Im więcej danych i informacji zebranych na etapie definiowania problemu, tym łatwiejsze zrozumienie istoty błędu, a finalnie lepsze zdefiniowanie przyczyn źródłowych i przypisanie działań korygujących eliminujących przyczyny powstawania problemu.

5W2H ze względu na swoją prostą konstrukcję i nakierowane pytania pozwala uzyskać najbardziej przydatne dla nas informacje w procesie opisywania i rozumienia problemu, z którym przyjdzie nam się zmierzyć. Siedem krótkich pytań i mnóstwo przydatnych informacji zwrotnych pozwala również na lepszą komunikację w zespole zajmującym się analizą problemu.

No właśnie: zespół. Drugi z najważniejszych elementów niezbędnych podczas prowadzenia Problem Solving. Jeśli wiemy, co  stanowi problem i dlaczego nim jest, wówczas wiemy też, kto z członków organizacji będzie dla nas najbardziej przydatny. Dlatego warto zadbać, aby zespół, który wykorzystamy na etapie definiowania problemu oraz dalszej analizy, był przede wszystkim interdyscyplinarny, jak i związany z analizowanym problemem (wyrób, obszar, proces). Dzięki temu łatwiej będzie uzyskać odpowiedzi na postawione pytania 5W2H czy w późniejszych etapach.

 

Autor: Michał Pawlaczek