facebook instagram linkedin

Metodologia Problem Solving cz.2, Ocena stanu faktycznego

Metodologia Problem Solving cz.2, Ocena stanu faktycznego

W poprzednim artykule, przedstawiliśmy etap początkowy analizy problemu, a mianowicie ‘Definiowanie problemu’. Przy wykorzystaniu narzędzia 5W2H przedstawiliśmy jak w prosty sposób, przy zastosowaniu 7 pomocniczych pytań opisać i zrozumieć faktyczny problem z jakim przychodzi nam się mierzyć. Dzisiaj przejdziemy o krok dalej, pozostając jednak w obrębie pierwszej fazy analizy problemów. Etap ten w zależności od wybranej metody (dla przypomnienia, najczęściej stosowane to 8D, DMAIC lub Raport A3), ma na celu przede wszystkim pomóc nam w zrozumieniu jaka jest skala problemu oraz w jaki sposób zdefiniować obszary w których mogą występować potencjalne przyczyny prowadzące do powstania problemu. Faza ta w zależności od wybranej metody rozwiązywania problemów przybiera najczęściej nazwę „Measure”.

Przedstawienie problemu w liczbach


Ponieważ metodologia Problem Solving to usystematyzowany sposób ‘walki’ z problemami, to niejako odgórnie narzucony jest z góry wymóg pracy z parametrami dostarczającymi informacji na temat problemu. Do tych zaliczać będziemy dane, liczby oraz fakty. I o ile o faktach mówimy już przy wykorzystaniu narzędzia 5W2H podczas opisywania problemu o tyle warto pamiętać, że do pełni obrazu potrzebne jest przedstawienie problemu w formie skwantyfikowanej – a więc za pomocą liczb zgromadzonych w postaci zgromadzonych danych.

Oczywiście odpowiadając na pytanie „How many? (Jak dużo?)”, dostarczamy pierwszych istotnych informacji przedstawionych za pomocą liczb ale warto zastanowić się w tym miejscu czy te informacje są dla nas satysfakcjonujące. Czy dają nam pełny obraz sytuacji w jakiej znajduje się nasza organizacja lub też analizowany proces. W niektórych przypadkach będzie to informacja w zupełności wystarczająca. Dla przykładu wróćmy do przykładu przedstawionego w poprzednim artykule, nieznacznie go modyfikując.

„W procesie obróbki mechanicznej z wykorzystaniem maszyny CNC, dla partii 150 sztuk wyprodukowanych 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.”

Powyższy przykład ilustruje nam skalę problemu jaki wystąpił dla problematycznej partii. Jednakże jest to bardzo spłaszczone zobrazowanie skali problemu z jakim mamy do czynienia. Na ten moment jesteśmy w stanie stwierdzić jedynie czy ten problem występował tylko dla tej jednej partii, czy może pojawiał się już wcześniej, tylko występował jednostkowo w mniejszej skali więc nie był eskalowany, a występująca wada była z miejsca naprawiana. Warto, przy takiej okazji zatrzymać się na chwilę i zagłębić się w dane pochodzące z naszego procesu. Pomocnym narzędziem w takim przypadku będzie z pewnością arkusz danych, który z miejsca dostarczy nam wszystkich informacji na temat pojawiających się wad w danej jednostce lub przedziale czasu. I tak z jednej strony pozwoli nam na przegląd wszystkich znanych i zdefiniowanych wad, których wystąpienie możliwe jest w danym procesie, jak również za pomocą liczb dostarczy informacji ile wad danego rodzaju występuje. Dodanie do arkusza przedziałów czasowych (dni, tygodnie, miesiące – w zależności od potrzeb) oraz z podziałem na zmiany produkcyjne dodatkowo uzupełni informację o tym kiedy najczęściej występują określone problemy w procesie.

Przykład arkusza danych poniżej.

 

W ten prosty i przejrzysty sposób jesteśmy w stanie wyczytać jakiego rodzaju wady pojawiają się najczęściej oraz w jakiej skali. Oczywiście powyższy przykład będzie miał zastosowanie do szczególnego procesu lub maszyny, w tym przypadku do maszyny CNC, ale arkusz ten możemy modyfikować w dowolny dla siebie sposób, dopasowując go do analizowanych procesów lub problemów. I tak, odpowiednio zmodyfikowany arkusz danych może posłużyć do zbadania, np. występowania wąskich gardeł poprzez pomiar czasu operacji maszyn lub etapów procesu, analizy występowania awarii na potrzeby zarządzania parkiem maszynowym czy ilości zrealizowanych zleceń przez dział handlowy. Uniwersalność tego narzędzia pozwala na dostosowanie go w zależności od potrzeb.

1 obraz = 1000 słów

Co dalej w chwili gdy mamy zgromadzone dane? Jak wykorzystać je w analizie problemu? Jak przetworzyć dalej informację, tak by była pomocna?

Zgromadzone dane przedstawione za pomocą liczb potrafią dać ogrom wiedzy na temat tego jak funkcjonują procesy. Ale żeby dobrze zrozumieć w którym miejscu się znajdujemy, musimy przebrnąć nierzadko przez szereg wierszy zawierających dane, odpowiednio je odczytać i przetworzyć. To może prowadzić do pominięcia istotnych informacji, które tak rzetelnie gromadziliśmy na przestrzeni czasu. Z pomocą przychodzi tu rozwiązanie graficzne, które niemal natychmiast pokazuje w jaki sposób kształtuje się analizowany proces. Jednym z najczęściej wykorzystywanych narzędzi jest wykres Pareto, który za pomocą wykresu słupkowego, z jednej strony przedstawia ilość zaistniałych wad, a z drugiej strony na osi pomocniczej prezentuje udział procentowy w zbiorze wszystkich odnotowanych wad (czerwona linia na osi wyrażonej %).

Wróćmy zatem do naszego przykładu. Wiemy, że odnotowaliśmy 150 wad, w postaci braku otworów, z jednej partii. Analizując ostatni tydzień, możemy zauważyć, że łącznie w całej puli możliwych do wystąpienia wad brak otworu występował w sumie w ilości 197 szt., co stanowi niemal 80% wszystkich odnotowanych z tego okresu problemów. Wiemy też, że wada występowała na maszynie CNC.

Z tego miejsca można zauważyć, że skala problemu jest znacznie większa niż zostało to zasygnalizowane na początku analizy problemu, i możemy się domyślać, że problem ten istnieje już od pewnego czasu. To automatycznie, wymusza, poniekąd działania nakierowane nie tylko na ten konkretny proces czy maszynę ale równocześnie daje wskazówkę do tego, żeby przyjrzeć się bliżej oprogramowaniu samej maszyny CNC.

Wykres Pareto nie jest jednak jednak jedynym narzędziem pozwalającym na zobrazowanie stanu w jakim znajduje się proces. W zależności od gromadzonych danych, ich jakości oraz typowi możliwe jest stosowanie innych wykresów jak np.:

 
  • Wykres przebiegu w czasie – stosowany dla danych przedstawionych na osi czasu, dla naszego przykładu ten sam zestaw danych możemy analizować również w podziale na poszczególne dni.
  • Karty x-R, Im-R i inne iteracje kart statystycznych Shewhart’a dla przedstawienia szczegółowych parametrów procesu (np. odchylenia dla średnicy otworu)
  • Histogram – również stosowany w przypadku statystycznej analizy procesu
  • Diagram rozrzutu lub korelacji – wykorzystywany do analizy zależności pomiędzy dwoma badanymi zmiennymi (cechami)
  • Inne w zależności od potrzeb i analizowanego problemu.

Zgromadzone i przedstawione w postaci graficznej dane to swego rodzaju klamra zamykająca z jednej strony fazę definiowania i pomiaru problemu ale jednocześnie wprowadza analizę na ścieżkę definiowania potencjalnych przyczyn powstania problemu oraz obszaru ich występowania.

Od ogółu do szczegółu

W wieloletniej pracy zarówno inżyniera jakości jak i specjalisty odpowiedzialnego za doskonalenie procesów, spotykałem się z podejściem, iż zaraz po zamknięciu etapu definiowania problemu, następowało przechodzenie do analizy problemu poprzez analizę przyczyn źródłowych. I nie ma w tym podejściu nic złego, bowiem niezależnie od przyjętej metody Problem Solving, czy to za pomocą 8D czy DMAIC czy też raportu jednostronicowego A3, jest to naturalny sposób postępowania. Przejście do analizy przyczyn źródłowych przy wykorzystaniu takich narzędzi jak diagram przyczynowo-skutkowy Ishikawy (diagram rybiej ości) czy 5Why? 
(5x dlaczego?), jest czymś naturalnym i wręcz oczekiwanym.

Bazując jednakże, zarówno na wiedzy i doświadczeniu innych ekspertów jak i na własnej wiedzy i obserwacji procesów, z pełną świadomością mogę zachęcić do zainicjowania analizy przyczynowo – skutkowej jeszcze na etapie definiowania problemu.

Dlaczego akurat takie podejście? Otóż, wprowadzenie do analizy problemu, diagramu Ishikawy już na tym etapie pozwala zarówno na łatwiejsze określenie zarówno potencjalnych przyczyn występowania problemu jak również obszarów, w których te przyczyny mogą występować. Należy przy tym zaznaczyć, że;

 

POTENCJALNE PRZYCZYNY POWSTANIA PROBLEMU

PRZYCZYNY ŹRÓDŁOWE POWSTANIA PROBLEMU

 

Oczywiście, nie można wykluczyć, że potencjalne przyczyny występowania problemów w dalszym toku prowadzonej analizy nie staną tymi źródłowymi, które w rzeczywistości doprowadziły do wygenerowania problemu.

Dla lepszego zobrazowania sensu wprowadzenia analizy przyczynowo – skutkowej już na tym etapie, należy zaznaczyć, że pozwala ona na uporządkowanie zgromadzonych informacji i przypisanie ich do właściwych obszarów. Dzięki temu ograniczamy w pewnym sensie zakres prowadzonej analizy problemu do kluczowych składników mających wpływ na efekt końcowy naszego procesu. Nie tracimy dzięki temu energii na analizowanie wszystkich składowych w procesie co przy okazji eliminuje efekt rozproszenia uwagi na inne zmienne, nie mające bezpośredniego przełożeni na analizowany problem.

Nie wyklucza to jednak wprowadzenia pozostałych zmiennych i ich analizy w późniejszym toku prowadzonej analizy przyczyn źródłowych, jeśli zajdzie taka potrzeba.

Wróćmy więc do naszego przykładu. Wiemy co jest problemem, dlaczego jest to dla nas problem, jak również mamy wiedzę gdzie powstał i w jakiej ilości. Spróbujmy więc przenieść pozyskaną wiedzę na diagram rybiej ości.

  

Powyższy diagram jest przykładem określenia potencjalnych przyczyn powstania problemu i obszarów ich występowania. Oczywiście, obszary mogą zostać zmodyfikowane tak by odpowiadały składowym obszaru w którym prowadzona jest analiza problemu.

Zwróćmy uwagę, że zaproponowane na tym etapie potencjalne przyczyny stanowią jedynie hasłowe wskazówki co potencjalnie mogło wpłynąć na efekt końcowy jakim w rozpatrywanym przypadku jest brak nawierconych otworów. Dzięki takiemu podejściu możliwe jest zarówno wskazanie zmiennych, które należy poddać głębszej analizie, ale również daje nam to wskazówkę, gdzie jeszcze z jakich obszarów należy uzupełnić informacje w postaci danych, liczb i faktów, które pozwolą w późniejszym etapie na bardziej trafne wskazanie realnych przyczyn źródłowych powstania problemu.

Dla lepszego zrozumienia powyższego diagramu;

  • Man (Człowiek) -> Kwalifikacja pracowników: wskazuje na konieczność weryfikacji czy wszyscy pracownicy posiadali stosowne uprawnienia i kwalifikacje do obsługi maszyny CNC
  • Machine (Maszyna) -> Parametry maszyny: nakierowuje na szczegółowe sprawdzenie czy wybrane lub przygotowane parametry procesu (program) w trakcie realizacji procesu były właściwie wprowadzone
  • Method (Metoda) -> Kontrola wyrobu: daje wskazówkę do tego by sprawdzić czy wszystkie czynności zostały wykonane zgodnie z wytycznymi opracowanymi w instrukcji Pracy
  • Management (Zarządzanie) -> Maintenance Plan: pozwala na zgromadzenie danych dotyczących awarii i zarządzania parkiem maszynowym w czasie kiedy doszło do powstania problemu
  • Environment (Środowisko / Otoczenie) -> Rozproszenie: daje podstawy do tego by sprawdzić czy czynniki zewnętrzne nie prowadzą do zmniejszenia poziomu skupienia pracownika.


Oczywiście w zależności od jakości zebranych informacji w oparciu o przeprowadzoną wstępnie analizę potencjalnych przyczyn powstania problemu, możliwe jest podjęcie decyzji, przy wykorzystaniu czy to burzy mózgów czy matrycy Eisenhower’a, co do wyboru i szczegółowej analizy zmiennych w celu określenia przyczyn źródłowych.

Należy również wspomnieć o tym, że określenie potencjalnych przyczyn i obszarów ich występowania, pozwala na zaadresowanie i wprowadzenie działań korekcyjnych / tymczasowych, które pozwolą uchronić proces lub klienta przed dostarczeniem kolejnych wadliwych wyrobów, na czas prowadzonej analizy Problem Solving. Ponadto ciągłe monitorowanie procesów po wprowadzonych działaniach korekcyjnych może dodatkowo dać odpowiedź gdzie w procesie występuje „przeciek” prowadzący do powstania problemu, a tym samym pozwoli na zawężenie obszaru, który zostanie poddany dalszej analizie w celu poszukiwania przyczyn źródłowych.

Podsumowanie

Reasumując, pierwszy etap rozwiązywania problemów za pomocą metodologii Problem Solving to dość obszerny i złożony proces. Jest on jednak kluczowy do tego by nasza analiza problemów nie zakończyła się niepowodzeniem. Niestety zdarza się, że etap ten jest bagatelizowany, a jakość zdefiniowania problemu za pomocą danych, liczb i faktów oraz jakość samych danych dostarczonych na potrzeby prowadzonej analizy skutkuje finalnie fiaskiem w postaci nierozwiązanego problemu lub jego powtórki w przyszłości.

Niestety pokutuje też przekonanie, iż to kolejny etap, a mianowicie określenie przyczyn źródłowych, skupia największą uwagę osób uczestniczących w procesie Problem Solving. Efektem braku dobrze wykonanej fazy wstępnej i przygotowania do analizy problemu, jest wówczas niedopasowanie działań korygujących i zapobiegawczych do przyczyn źródłowych, które nie korelują z faktycznie istniejącym problemem.

Dlatego też gorąco zachęcamy do tego by podczas prowadzonej analizy poświęcić czas i energię na właściwe przeprowadzenie etapu definiowania problemów. Mamy również nadzieję, że pomocne w tym będą wskazówki przedstawione zarówno w tym jak i poprzednim artykule, który ukazał się na łamach magazynu Nowoczesny Przemysł.

Autor: Michał Pawlaczek

×

Niezbędne pliki cookies

Te pliki cookie są niezbędne do działania strony i nie można ich wyłączyć. Służą na przykład do utrzymania zawartości koszyka użytkownika. Możesz ustawić przeglądarkę tak, aby blokowała te pliki cookie, ale wtedy strona nie będzie działała poprawnie.

Zawsze aktywne

Analityczne pliki cookie

Te pliki cookie pozwalają liczyć wizyty i źródła ruchu. Dzięki tym plikom wiadomo, które strony są bardziej popularne i w jaki sposób poruszają się odwiedzający stronę. Wszystkie informacje gromadzone przez te pliki cookie są anonimowe.