Odcinek 12. Edward zgłębia tajniki filozofii LEAN SIX SIGMA

W czasie wakacji większość naszych Klientów odpoczywała korzystając z sezonu urlopowego. Natomiast ja miałem więcej czasu, żeby poszerzyć swoje horyzonty. Dzięki uprzejmości moich kolegów z zespołu dowiedziałam się wiele o automatyzacji i nie tylko. Kolega Rafał zgodził się podzielić ze mną swoją wiedzą na temat filozofii LEAN SIX SIGMA.

Okiem Eksperta:

Osoby, z którymi rozmawiam, często pytają mnie, czy dany proces można zautomatyzować? Poniekąd kontrowersyjnie zawsze odpowiadam, że tak. Niemniej jednak zawsze też dodaję, że ważniejszym pytaniem jest, czy można proces zautomatyzować w jego obecnej formie? W tym momencie sytuacja zazwyczaj już się komplikuje i okazuje się, że automatyzacja jest dopiero kolejnym krokiem, jaki należy podjąć na drodze do określonego celu, ale na pewno nie pierwszym.

Mówi się, że jedyną stałą rzeczą w życiu jest zmiana.

To samo tyczy się procesów, które stale ewoluują przez zmiany w środowisku, w którym pracują. Mogą to być zmiany prawne, technologiczne, struktury wewnętrznej czy też profilu klientów. Dla przykładu: praca z dokumentami papierowymi ustępuje ich cyfrowym odpowiednikom, co wymusiło implementację narzędzi do podpisu cyfrowego.

Prowadzi to też do wprowadzenia metodologii zajmującej się wdrażaniem tzw. Continuous improvement, czyli ciągłego doskonalenia. Jedną z tych metodologii jest LEAN SIX SIGMA, która powstała z połączenia Lean oraz Six Sigma, aby połączyć najlepsze rozwiązania obu sposobów. Opiera się ona na kilku kluczowych zagadnieniach.

Genichi Genbutsu – czyli w wolnym tłumaczeniu „idź i sprawdź”. Istotą tego podejścia jest, aby kierownicy nie tylko spędzali czas za biurkiem, ale także osobiście sprawdzali przyczyny danej sytuacji problemowej u źródeł jej powstania, czyli tam gdzie powstaje dany produkt. Chodzi o to, że aby rozwiązać konkretne problemy, należy najpierw zapoznać się dokładnie z każdym etapem procesu, przeprowadzić analizę i wyciągnąć wnioski. W przypadku automatyzacji procesów biznesowych oznacza to, że osoby na pozycjach kierowniczych powinny również znać procesy wykonywane przez osoby na niższych stanowiskach. Dzięki temu łatwiej im będzie wytypować, które procesy z perspektywy strategii firmy powinny być zautomatyzowane jako pierwsze.

Decyzje należy podejmować w oparciu o następujące czynności:

  1. Określ cel
  2. Wybierz obszar
  3. Zwizualizuj proces
  4. Obserwuj i zadawaj pytania
  5. Przeanalizuj obserwacje
  6. Określ różnice między stanem faktycznym a pożądanym
  7. Zaprezentuj wyniki

Ciąg tych następujących po sobie zdarzeń jest bardzo zbliżony do kolejnego zagadnienia metodologii Lean Six Sigma, czyli cyklu DMAIC, składającym się z pięciu faz.

DEFINE

Definiowanie (Define) pozwala ustalić, na czym dokładnie polega problem oraz co jest niezbędne do jego rozwiązania. Tak określony cel powinien być tzw. SMART, czyli (S) skonkretyzowany, (M) mierzalny, (A) osiągalny, (R) istotny oraz (T) określony w czasie.

MEASURE

Pozwala to na przejście do kolejnej fazy, czyli Pomiaru (Measure), w której opisujemy sposób dokonywania obserwacji, a następnie przeprowadzamy odpowiednie obliczenia, celem ustalenia bieżącej wydajności procesu.

ANALYZE

Prowadzi to bezpośrednio do kolejnej fazy – Analizy (Analyze). Na tym etapie mamy już dostępne podstawowe dane pozwalające na podjęcie decyzji.

IMPROVE

Dzięki temu możemy zaimplementować potrzebne zmiany w fazie Doskonalenia (Improve). Wymyślone rozwiązanie należy przetestować, sprawdzić, a na końcu wdrożyć. W tym celu można posłużyć się cyklem PDCA oraz analizą FMEA.

CONTROL

Ostatnią fazą jest faza Kontroli (Control), która ma za zadanie zweryfikować przyjęte założenia oraz czy dany problem został rozwiązany.

Wspomniany już PDCA, zwany cyklem Deminga polega na podzieleniu wdrażania usprawnienia na cztery etapy:

  1. Plan (zaplanuj) – główny nacisk na to, co nie funkcjonuje prawidłowo
  2. Do (wykonaj) – wdrożenie zmian w formie testu
  3. Check (sprawdź) – analiza wyników, sprawdzając czy test zakończył się pozytywnie
  4. Act (popraw) – implementacja na produkcji

Cechą charakterystyczną tutaj jest cykliczność metodologii, ponieważ zakończenie fazy Act powinno powodować ponowne przejście do fazy Plan. Jednak, jeśli zdarzy się sytuacja, że eksperyment był nieudany, to należy pominąć etap wdrożenia na produkcję i przejść ponownie do przygotowania nowego planu – aż do rozwiązania problemu.

Jak w to wszystko jeszcze wplątać analizę FMEA? Z ang. Failure mode and effects analysis jest to analiza rodzajów i skutków możliwych błędów i ma ona na celu podjęcie działań prewencyjnych, zapobiegających skutkom wad, które mogą pojawić się zarówno w fazie projektowania, jak i wytwarzania. Głównymi założeniami jest to, że ok. 75% błędów ma swoją przyczynę w fazie przygotowywania produkcji. Z drugiej strony, wykrywanie ich dzieje się dopiero w fazie produkcji oraz w czasie eksploatacji (ok. 80% błędów). Jak to działa? W pierwszym etapie musimy ustalić nasz cel, zebrać zespół, podjąć decyzję, co będziemy analizować, rozłożyć proces na czynniki pierwsze i w końcu zebrać dane. Te z kolei posłużą nam w momencie przeprowadzenia zarówno jakościowej, jak i ilościowej analizy. Ostatecznym krokiem jest zaplanowanie działań korygujących, wdrożenie ich oraz obserwacja.

Wszystkie te elementy, o których pisałem, można zarówno bardzo dobrze zaimplementować przy wdrożeniach kolejnych automatyzacji, jak i przy optymalizacji już istniejących procesów. Zanim programista przystąpi do pracy, wraz z analitykiem muszą przejść przez procedurę Genichi Genbutsu, aby odpowiednio dobrze poznać automatyzowany proces. Następnie tworzą główny plan pracy, który bardzo przypomina sposób pracy cyklu DMAIC. Samo programowanie odbywa się w formie: Zaplanuj => Zaprogramuj => Przetestuj => Wdróż, co do złudzenia przypomina metodologię PDCA. Jednocześnie programista, wraz z SME oraz analitykiem, przygotowują listę potencjalnych błędów oraz ich obsługę w myśl metody FMEA. Może nie wszystko przebiega książkowo, czy też nie zawiera standardowej dokumentacji, natomiast trzon tych metod jest zawsze taki sam.

Autor: Rafał Korporowicz – Senior RPA Developer