Siedem błędów w projektach Lean Six Sigma. Dlaczego genialne rozwiązania nie rozwiązują problemów?

Usiądź wygodnie, bo zaczniemy od sceny, którą na pewno znasz.

Sala konferencyjna. Problem jakościowy na produkcji. Przy stole trzech dyrektorów, dwóch mistrzów i kierownik zmiany. Po dziesięciu minutach wszyscy już wiedzą, co jest grane. Dostawca nawalił. Maszyna pamięta czasy Gomułki. Operatorzy są niedoszkoleni. Po dwudziestu minutach jest plan działań. Po trzech miesiącach problem wraca, często w gorszej formie.

Znasz to? Ja znam aż za dobrze.

Na jednym z naszych webinarów w Szkole Jakości rozmawiałem o tym z Marcinem Masłowskim. Marcin jest Black Beltem Lean Six Sigma z ponad 15 latami doświadczenia w nadzorowaniu projektów optymalizacyjnych w międzynarodowej korporacji. Przeprowadził kilkadziesiąt projektów, certyfikował projekty Green Beltów i uczył studentów na AGH oraz Uniwersytecie Ekonomicznym. Wylistował siedem błędów, które widzi w projektach usprawnieniowych najczęściej.

W tym artykule rozkładam je na części pierwsze. Pokażę Ci, na czym polega każdy z nich, dlaczego jest tak kosztowny i co robić zamiast tego. Na końcu znajdziesz konkretną mapę działania i odpowiedzi na najczęstsze pytania.

Czym właściwie jest Lean Six Sigma i po co Ci DMAIC?

Lean Six Sigma to połączenie dwóch podejść. Lean skupia się na eliminowaniu marnotrawstwa i przyspieszaniu przepływu. Six Sigma skupia się na redukcji zmienności procesu, czyli na tym, żeby proces był przewidywalny i powtarzalny. Metodyka ma korzenie japońsko-amerykańskie. Duży wkład w jej powstanie miały Toyota oraz Motorola.

Kręgosłupem każdego projektu jest cykl DMAIC:

• Define (zdefiniuj): czym jest problem, jaki jest zakres, kto jest klientem procesu.
• Measure (zmierz): jak proces wygląda dziś, w liczbach.
• Analyze (przeanalizuj): co naprawdę powoduje problem.
• Improve (usprawnij): jakie rozwiązanie usuwa przyczynę.
• Control (kontroluj): jak utrzymać wynik na stałe.

Brzmi prosto. Problem polega na tym, że w praktyce ludzie tę kolejność przeskakują, skracają albo odwracają. Właśnie stąd biorą się wszystkie błędy opisane poniżej.

Błąd 1. Dlaczego zakochujesz się w rozwiązaniu, zanim zrozumiesz problem?

Zacznę od historii, którą Marcin przytoczył na webinarze. To realny przypadek szpitala w Kalkucie w Indiach.

Przy szpitalu działała przychodnia, a na terenie szpitala apteka. Liczba pacjentów przychodni rosła, w pewnym okresie o ponad 50%. Sprzedaż apteki stała w miejscu. Coś się nie zgadzało.

Co zrobiłbyś na miejscu dyrektora? Promocja? Program lojalnościowy? Więcej reklamy? Kierownictwo szpitala zrobiło coś, co wyglądało bardzo rozsądnie. Wprowadzono aptekę całodobową, bo przychodnia też działała całą dobę. Do tego uruchomiono bezpłatną dostawę leków do domu w określonym promieniu.

Efekt? Sprzedaż nie drgnęła. Za to szpital wydał sporo pieniędzy na dodatkowy etat, nowe grafiki zmian i umowę z lokalnym przewoźnikiem.

To jest błąd numer jeden: przechodzimy do rozwiązań, zanim zrozumiemy problem. Rozwiązania były dobre. Problem w tym, że rozwiązywały problem, którego nie było.

Dopiero gdy powołano zespół projektowy pracujący metodą Lean Six Sigma, ktoś poszedł do gemba, czyli tam, gdzie dzieje się proces. Zespół zaczął pytać pacjentów i zbierać dane. Okazało się, że tylko 31% pacjentów z receptą kupowało leki w szpitalnej aptece. Prawie 70% szło gdzie indziej, mimo że apteka była dosłownie pod nosem. Utracona sprzedaż koncentrowała się w konkretnych godzinach przedpołudniowych.

To już były fakty, z którymi można pracować. Do tej historii jeszcze wrócę, bo jej zakończenie jest najlepszą lekcją w całym artykule.

Co robić zamiast tego? Zanim zaproponujesz jakiekolwiek rozwiązanie, zapytaj: czy wiem, co się dzieje, czy tylko mi się wydaje? Jeśli odpowiedź brzmi „wydaje mi się”, jesteś w fazie Define, nie w fazie Improve.

Błąd 2. Czy na pewno zdefiniowałeś problem, a nie jego przyczynę?

Na spotkaniu zarządu pada zdanie: „Problemem są niedoszkoleni operatorzy”. Wszyscy kiwają głowami. Szkolenia zostają zaplanowane.

Co jest nie tak? To zdanie nie jest definicją problemu. To jest hipoteza dotycząca przyczyny.

Wyobraź sobie firmę produkującą pompy przemysłowe. Od kilku miesięcy rośnie liczba wyrobów odrzucanych na teście końcowym. Na burzy mózgów ustalono, że winni są nowi operatorzy. Tymczasem niedoszkolenie to tylko jedna ze zmiennych. Przyczyną może być materiał, ustawienie maszyny, temperatura, komponent od dostawcy i kilkanaście innych rzeczy. Zawężając problem do operatorów na samym starcie, zamykasz sobie drogę do prawdziwej przyczyny.

Dobrze zdefiniowany problem wygląda zupełnie inaczej:

W ciągu ostatnich 6 miesięcy poziom braków na linii montażowej nr 3 wynosił 4,8%, przy wymaganym poziomie 1,8%. Najczęściej występującym defektem jest nieszczelność. Problem generuje 180 godzin poprawek miesięcznie, co przekłada się na około 320 tys. zł dodatkowych kosztów rocznie.

Widzisz różnicę? Pierwsza wersja to opinia. Druga to fakty. Nie ma w niej ani słowa o przyczynie.

Dobry problem statement odpowiada na pięć pytań:

1. Kiedy problem występuje i od kiedy?
2. Gdzie konkretnie? To wyznacza zakres projektu.
3. Co dokładnie się dzieje?
4. Jaka jest skala problemu?
5. Jaki jest wpływ, czyli co się stanie, jeśli nic z tym nie zrobimy?

Ostatnie pytanie jest kluczowe i często pomijane. Jeśli problem kosztuje firmę 320 tys. zł rocznie, warto zaangażować zespół. Jeśli kosztuje 1200 zł rocznie, kilka dniówek menedżera będzie droższe niż cała oszczędność. Robienie projektu na siłę, bez realnego wpływu biznesowego, nie ma sensu.

Einsteinowi przypisuje się zdanie, że gdyby miał godzinę na uratowanie świata, 55 minut poświęciłby na zrozumienie problemu, a 5 minut na rozwiązanie. Nie wiadomo, czy naprawdę to powiedział. Wiadomo za to, że to zdanie świetnie opisuje fazę Define.

Jest jeszcze jeden wariant tego błędu, który Marcin widział wielokrotnie przy certyfikowaniu projektów. Ktoś od początku zna rozwiązanie i tylko „dorabia” do niego dokumentację DMAIC. Jeśli rozwiązanie jest znane od pierwszego dnia, to nie jest kandydat na projekt Green Belt. To jest zwykłe „just do it”. Wdróż i nie udawaj analizy.

Błąd 3. Dlaczego ufasz danym, którym nie powinieneś ufać?

Masz wynik Cpk z procesu. Jest poniżej 1,0, czyli proces nie jest zdolny do spełnienia wymagań klienta. Co robisz?

Większość osób odpowiada: szukam przyczyny źródłowej. To prawie dobra odpowiedź. Pierwsze pytanie powinno jednak brzmieć: czy ta wartość w ogóle jest prawdziwa?

Możesz mieć 10 tysięcy pomiarów z produkcji. Pytanie brzmi, czy to jest 10 tysięcy pomiarów, którym możesz zaufać.

Prosty przykład. Trzech operatorów mierzy średnicę wałka. Każdy dostaje inny wynik: 20,04 mm, 19,97 mm i tak dalej. Widzisz zmienność. Tylko czyja to zmienność? Produktu czy systemu pomiarowego?

Tutaj wchodzą dwa pojęcia, które przewijają się przez każdy projekt Six Sigma:

• Powtarzalność (repeatability): ten sam operator, tym samym przyrządem, mierząc ten sam element kilka razy, dostaje ten sam wynik. Czyli czy ktoś jest spójny sam ze sobą.
• Odtwarzalność (reproducibility): różni operatorzy, mierząc ten sam element, dostają ten sam wynik.

Jeśli każdy operator ma swoje własne przesunięcie (jeden mierzy trochę „w górę”, drugi trochę „w dół”), na karcie kontrolnej dostajesz zupełny miszmasz. Czasem to właśnie te setne części milimetra decydują, czy Twoje Cpk jest na akceptowalnym poziomie, czy nie.

Problem dotyczy nie tylko pomiarów fizycznych. Marcin podał przykład z obszaru usług. Czas obsługi klienta w contact center liczony był od momentu odebrania telefonu. W pewnym momencie właściciel procesu uznał, że liczy się od chwili, gdy pracownik zaczyna robić notatki. Dane z systemu sprzed pół roku i dane z dziś mierzą więc dwie różne rzeczy. Porównując je, wyciągasz fałszywe wnioski.

Wniosek jest brutalny: jeśli system pomiarowy nie jest wiarygodny, wszystkie analizy możesz wyrzucić do kosza.

W fazie Measure kolejność jest zawsze taka sama:

1. Definicja operacyjna (operational definition): od kiedy do kiedy mierzymy i co dokładnie.
2. Plan zbierania danych (data collection plan).
3. Metoda próbkowania (sampling).
4. Analiza systemu pomiarowego (MSA): czy wszyscy mierzą tak samo.
5. Baseline: dopiero teraz masz punkt zerowy, czyli rzetelny obraz tego, jak proces wygląda dziś.

Właśnie to ustrukturyzowane podejście do danych odróżnia projekt Six Sigma od zwykłej akcji naprawczej.

Błąd 4. Czy średnia mówi Ci prawdę o procesie?

Dashboard na hali. Dwie maszyny produkują ten sam komponent. Średnia z ostatniego tygodnia dla obu wynosi 20 mm, dokładnie tyle, ile ma być. Wszystko wygląda świetnie.

Teraz spójrz na rozkład danych. Maszyna A ma małe odchylenie standardowe i mieści się w granicach specyfikacji z dużym zapasem. Maszyna B ma rozrzut tak duży, że część wyrobów wypada poza tolerancję. Średnia jest identyczna. Procesy są zupełnie różne. Maszyna B jest nieprzewidywalna i produkuje braki.

Jest jeszcze ciekawszy przypadek. Średnia jest w porządku, ale histogram ma dwa garby. Okazuje się, że zmiana dzienna pracuje zupełnie inaczej niż zmiana nocna. Dwa różne procesy zlane w jedną średnią. Bez narysowania histogramu nigdy byś tego nie zobaczył.

To jest błąd numer cztery: patrzenie wyłącznie na średnią. W Six Sigma nie wystarczy przesunąć średniej we właściwe miejsce. Celem jest minimalizacja zmienności. Sama nazwa metody pochodzi przecież od sigmy, czyli odchylenia standardowego.

Pełny obraz procesu w fazie Measure i Analyze budujesz z kilku elementów:

• Odchylenie standardowe: jak duży jest rozrzut.
• Histogram: jaki jest kształt rozkładu (normalny, skośny, dwumodalny).
• Karta kontrolna (control chart): jak proces zachowuje się w czasie. Histogram tego nie pokaże. Karta kontrolna pokaże przesunięcia, trendy i sygnały przyczyn specjalnych.
• Wskaźniki zdolności: Cp i Cpk mówią, czy zmienność krótkoterminowa mieści się w wymaganiach klienta. Pp i Ppk mówią to samo w ujęciu długoterminowym.

Pamiętaj, że Cpk równe 1,0 to absolutne minimum. W wielu branżach, choćby w motoryzacji, klienci wymagają wartości 1,33 lub 1,67 dla charakterystyk krytycznych.

Błąd 5. Dlaczego diagram Ishikawy nie podaje Ci przyczyny źródłowej?

Rośnie liczba pękniętych komponentów po obróbce. Zespół robi wzorcowy diagram Ishikawy. Metodycznie, zgodnie ze sztuką. Na diagramie lądują: doświadczenie operatora, ustawienie maszyny, materiał od dostawcy, temperatura otoczenia, sposób pomiaru pęknięć, różnice między kontrolerami, sposób chłodzenia.

Po godzinie dyskusji wszyscy zgadzają się, że winna jest temperatura otoczenia. Czy to jest przyczyna źródłowa?

Nie. To jest potencjalny X, czyli kandydat na przyczynę.

Diagram ryby nie służy do znajdowania przyczyn. Służy do znajdowania potencjalnych przyczyn, czyli tego, co trzeba sprawdzić. Zaproś na spotkanie pięć innych osób, a lista potencjalnych X-ów urośnie o ciśnienie, stan maszyny, sposób ustawienia i kilka kolejnych pozycji. Nawet jeśli zrobisz Ishikawę i pogłębisz ją metodą 5 Why, nadal nie masz udowodnionej przyczyny. Masz hipotezę.

Poprawna logika wygląda tak:

Problem → Ishikawa i 5 Why → lista potencjalnych X-ów → plan zbierania danych → weryfikacja na danych → potwierdzone, istotne X-y → dopiero teraz rozwiązanie.

Celem nie jest znalezienie jak największej liczby zmiennych. Celem jest znalezienie tych kilku istotnych X-ów, które naprawdę wpływają na wynik procesu, i potwierdzenie ich danymi.

Wróćmy do szpitala w Kalkucie. Na burzy mózgów padła bardzo logiczna hipoteza: pacjenci nie mogą znaleźć apteki. Rozwiązanie aż prosiło się o wdrożenie: oznakowanie, plakaty, lekarze kierujący pacjentów. Zespół potraktował to jednak jako potencjalny X i poszedł zapytać pacjentów. Pacjenci doskonale wiedzieli, gdzie jest apteka. Hipoteza upadła, zanim wydano na nią choćby złotówkę.

Błąd 6. Czy próbujesz naprawić wszystko naraz?

Masz średnio 1000 defektów miesięcznie. Robisz analizę Pareto. Okazuje się, że 43% to nieszczelności, a trzy główne kategorie odpowiadają za około 80% wszystkich defektów. Świetnie, idziemy w nieszczelności.

Dobry Green Belt zejdzie jednak głębiej. Samo Pareto to jeszcze nie odpowiedź. Jeśli masz kilka linii, kilka zmian i kilka produktów, nadal możesz strzelać w niewłaściwy cel.

Następny krok to stratyfikacja, czyli rozbicie danych według źródła:

• Na której maszynie? Maszyna nr 3.
• Na której zmianie? Nocnej.
• Którego produktu dotyczy? Indeks X17.

Z 430 nieszczelności zostaje Ci 145 przypadków w bardzo konkretnym miejscu. Zakres projektu zmienia się z ogólnego „poprawmy jakość produkcji” na precyzyjny: „redukcja nieszczelności produktu X17 na maszynie nr 3 podczas zmiany nocnej”.

Dlaczego to takie ważne? Bo przełożony prawie zawsze powie: „Skoro już to robisz, zrób od razu we wszystkich trzech lokalizacjach”. Brzmi ambitnie. W praktyce oznacza trzy mini zespoły, trzy razy więcej interesariuszy do zarządzania, trzy razy więcej spotkań i zależność od danych, które w jednej lokalizacji są, a w drugiej nie. Marcin widział wiele projektów, które po roku kończyły się zdaniem: „Cztery lokalizacje to było za dużo”.

Projekt Green Belt powinien mieć wąski zakres. Lepiej zamknąć jeden konkretny projekt w około trzy miesiące, a potem przenieść sprawdzone rozwiązanie na inne linie, niż utknąć na rok w projekcie, który wymknął się spod kontroli. Przy okazji ucierpi Twoja reputacja, bo ktoś powie, że „nie dowiozłeś”.

Pamiętaj tylko o drugiej stronie medalu. Wąski zakres nadal musi być wart Twojego czasu, czyli musi wrócić do tego, co ustaliłeś w problem statement.

Błąd 7. Czy „wdrożone” naprawdę znaczy „zakończone”?

Projekt się udał. Braki spadły z 8% do 1,6%. Są maile z gratulacjami, nagrody i ulotki z sukcesem.

Mijają trzy miesiące. Przychodzi nowy operator. Ktoś zmienia ustawienie maszyny. Zmienia się partia materiału. Instrukcja stanowiskowa wciąż opisuje stary proces. Braki rosną do 4,2%.

Czy projekt zakończył się sukcesem?

Często powód jest jeszcze prostszy. Ludzie przyklepali nowe rozwiązanie, ale nie chcą według niego pracować. Wracają do starych nawyków. Albo wdrożono automatyzację, wyskoczył błąd, nie było budżetu na poprawkę i wszyscy wrócili do pracy ręcznej.

Marcin widział kiedyś ofertę pracy na stanowisko, którego jedynym zadaniem była faza Control. Ta osoba wracała do projektów pół roku po ich zamknięciu i sprawdzała, czy rozwiązania nadal działają. To dobrze pokazuje, jak często ta faza jest zaniedbywana.

Faza Control to nie formalność. To konkretne elementy:

• Plan kontroli (control plan): co monitorujemy, jak często, kto odpowiada.
• Standardy pracy i SOP-y: instrukcje opisujące nowy sposób pracy, a nie stary.
• Karty kontrolne aktualizowane na bieżąco.
• KPI z progami: żeby wiedzieć, w którym momencie proces zaczyna się pogarszać.
• Plan reakcji (reaction plan): co dokładnie robimy, gdy KPI przekroczy próg.
• Właściciel procesu (process owner).

Ostatni punkt jest szczególnie ważny. Firmy mają strukturę silosową: każdy dział odpowiada za swój kawałek. Klient czuje jednak cały proces, od złożenia zamówienia, przez produkcję i wysyłkę, aż po dostawę. Właściciel procesu odpowiada za całość, horyzontalnie, od A do Z. Bez niego nikt nie pilnuje, czy rozwiązanie przetrwało.

Projekt nie kończy się wtedy, gdy wynik się poprawił. Kończy się wtedy, gdy jesteś w stanie ten wynik utrzymać w długim terminie.

Jak skończyła się historia szpitala w Kalkucie?

Obiecałem, że wrócę. Oto pełny przebieg tego projektu, krok po kroku według DMAIC.

Define. Sprzedaż apteki była poniżej oczekiwanego poziomu, mimo dużego wzrostu liczby pacjentów.

Measure. Zebrane dane pokazały, że około 70% pacjentów przychodni nie kupowało leków w szpitalnej aptece.

Analyze. Zespół sprawdził hipotezy z diagramu Ishikawy i zrobił pogłębione wywiady z pacjentami. Hipoteza „nie mogą znaleźć apteki” odpadła. Potwierdziły się dwie prawdziwe przyczyny:

1. Zbyt długi czas zakupu. Droga do apteki, kolejka i sam zakup zajmowały średnio około 21 minut, a w szczycie nawet pół godziny. Pacjenci zapytani o akceptowalny czas wskazali 12 minut. To był ich CTQ (critical to quality), czyli parametr krytyczny dla jakości z punktu widzenia klienta.
2. Brak kompletnej recepty. Apteka często nie miała wszystkich leków z recepty. Pacjent i tak musiał iść do innej apteki, więc wolał kupić tam wszystko naraz, zamiast stać w dwóch kolejkach.

Zauważ, że żadna z tych przyczyn nie miała nic wspólnego z godzinami otwarcia ani z dostawą do domu. Pierwsze, „oczywiste” rozwiązania strzelały zupełnie obok celu.

Improve. Wprowadzono dwa główne usprawnienia:

• Reorganizacja leków metodą 5S. Część najczęściej wydawanych leków leżała w magazynie piętro wyżej. Farmaceuta musiał po nie chodzić. Po analizie, które leki schodzą najczęściej, przeniesiono je pod rękę.
• Wcześniejsze przesyłanie recepty. Pacjent mógł wysłać skan recepty do apteki, zanim do niej dotarł. Farmaceuta zaczynał kompletować leki, zanim pacjent stanął przy okienku.

Control. Wprowadzono monitoring procesu, przeszkolono pracowników i wpisano zmiany na stałe w system pracy apteki.

Wyniki:

• średni czas zakupu spadł z około 21 do około 9,3 minuty,
• odsetek pacjentów obsłużonych w limicie 12 minut wzrósł z zera do prawie 90%,
• liczba pacjentów korzystających z apteki wzrosła o 23%.

W skali roku oznaczało to bardzo duży dodatkowy przychód. Bez nowych etatów, bez kampanii reklamowej, bez programu lojalnościowego.

Dlaczego te błędy wciąż się powtarzają?

Moim zdaniem z trzech powodów.

Pierwszy to presja czasu. Zarząd chce wyniku na wczoraj. Faza Define i Measure wyglądają jak „nicnierobienie”, bo nie widać w nich spektakularnych działań. Tymczasem to właśnie one decydują o tym, czy pieniądze wydane w fazie Improve przyniosą efekt.

Drugi to autorytet zamiast danych. Na spotkaniu wygrywa ten, kto mówi najgłośniej albo ma najwyższe stanowisko. Six Sigma odwraca tę logikę: wygrywa ten, kto ma lepsze dane.

Trzeci to brak umiejętności przełożenia narzędzi na język biznesu. Wielu inżynierów zna Ishikawę, Cpk, 5S i kanban. Mniej potrafi poprowadzić cały projekt od karty projektu do planu kontroli, policzyć oszczędność w złotówkach i obronić ją przed dyrektorem finansowym. Znajomość narzędzi to nie sztuka. Sztuką jest doprowadzenie projektu do końca.

Jak poprowadzić projekt Lean Six Sigma bez tych błędów? Mapa działania

1. Opisz problem faktami, nie opiniami. Odpowiedz na pięć pytań: kiedy, gdzie, co, jaka skala, jaki wpływ. Usuń z opisu każde słowo, które sugeruje przyczynę.
2. Policz wpływ finansowy. Jeśli koszt problemu jest mniejszy niż koszt projektu, odpuść albo zrób „just do it”.
3. Zawęź zakres. Pareto, a potem stratyfikacja: maszyna, zmiana, produkt, lokalizacja. Celuj w projekt, który zamkniesz w około trzy miesiące.
4. Zweryfikuj system pomiarowy. Definicja operacyjna, plan zbierania danych, próbkowanie, MSA. Dopiero potem baseline.
5. Patrz na zmienność, nie tylko na średnią. Histogram, karta kontrolna, Cp/Cpk i Pp/Ppk.
6. Traktuj Ishikawę jako listę hipotez. Każdy potencjalny X potwierdź albo odrzuć na danych, zanim zaczniesz szukać rozwiązań.
7. Idź do gemba i do klienta. Zapytaj ludzi, którzy są w procesie i którzy z niego korzystają. Ustal ich CTQ.
8. Zaprojektuj fazę Control, zanim ogłosisz sukces. Plan kontroli, standardy, KPI z progami, plan reakcji i właściciel procesu.

FAQ: najczęstsze pytania o projekty Lean Six Sigma

Czym różni się Green Belt od Black Belta?

To poziomy kompetencji w Lean Six Sigma. Yellow Belt to wiedza podstawowa, głównie o marnotrawstwie. Green Belt to poziom średnio zaawansowany: samodzielnie prowadzisz projekt DMAIC, znasz podstawy statystyki i potrafisz udowodnić oszczędność. Black Belt prowadzi projekty większej skali, nadzoruje Green Beltów i swobodnie korzysta z zaawansowanej statystyki oraz oprogramowania takiego jak Minitab, Statistica czy JMP. Master Black Belt jest mentorem Black Beltów. Szczegółowe wymagania zależą od organizacji certyfikującej.

Ile trwa typowy projekt Green Belt?

Dobrze zawężony projekt Green Belt da się zamknąć w około trzy miesiące. Jeśli Twój projekt zapowiada się na rok, najpewniej masz za szeroki zakres.

Jak duże oszczędności powinien przynieść projekt Green Belt?

Nie ma jednej normy. Marcin jako punkt odniesienia podaje rząd kilkudziesięciu tysięcy złotych rocznie, na przykład około 50 tys. zł. Ważniejsze od kwoty jest to, żeby oszczędność była policzona i udowodniona danymi.

Co zrobić, jeśli przełożony nie zgodzi się na projekt?

Zacznij od fazy Define. Nie wymaga ona dużych nakładów, tylko kilku spotkań i wstępnych danych. Przygotuj kartę projektu (project charter) z policzonym kosztem problemu i przedstaw ją przełożonemu. Firmy płacą zewnętrznym konsultantom duże pieniądze za taką diagnozę. Pracownik, który robi to od środka, rzadko spotyka się z odmową. Z mojego doświadczenia wynika też, że ludzie, którzy wychodzą poza zakres obowiązków i zmieniają procesy, to ci, którzy awansują.

Dlaczego w Lean Six Sigma używa się tylu angielskich terminów?

To metodyka stosowana na całym świecie, a wiele pojęć, jak CTQ (critical to quality) czy VOC (voice of the customer, głos klienta), nie ma dobrych polskich odpowiedników. W międzynarodowej firmie usłyszysz „CTQ”, a nie „parametr krytyczny dla jakości”. Warto znać oryginalne terminy. Wystarczy jeden decydent, który nie mówi po polsku, a cała prezentacja projektu przechodzi na angielski.

Jaka wartość Cpk jest wystarczająca?

Cpk poniżej 1,0 oznacza, że proces nie jest zdolny do spełnienia wymagań. W praktyce wielu klientów, zwłaszcza w motoryzacji, wymaga co najmniej 1,33, a dla charakterystyk krytycznych często 1,67. Zawsze sprawdź wymagania swojego klienta. Pamiętaj też, że Cpk liczone na niewiarygodnych danych pomiarowych nic nie znaczy (patrz błąd numer 3).

Czy do projektu Green Belt potrzebuję Minitaba?

Na poziomie Green Belt nie jest to konieczne. Większość analiz (Pareto, histogram, karty kontrolne, Cp/Cpk) zrobisz w Excelu, mając dobre szablony. Zaawansowane oprogramowanie statystyczne staje się standardem na poziomie Black Belt.

Chcesz przejść przez cały projekt DMAIC z mentorem, a nie metodą prób i błędów?

Wszystkie błędy z tego artykułu da się ominąć. Wymaga to jednak czegoś więcej niż znajomości narzędzi. Wymaga przeprowadzenia prawdziwego projektu od karty projektu do planu kontroli, z kimś, kto zrobił to dziesiątki razy.

Właśnie dlatego razem z Marcinem Masłowskim przygotowaliśmy w Szkole Jakości szkolenie Green Belt Lean Six Sigma z AI:

• 72 lekcje wideo (około 10 godzin) w 8 modułach, od wprowadzenia, przez każdą fazę DMAIC, po egzamin,
• 10 gotowych plików do projektu: kryteria wyboru projektu, karta projektu, Pareto, ankieta VOC, symbole VSM, plan zbierania danych i inne,
• prompt book liczący ponad 150 stron z ponad 50 zaawansowanymi promptami AI do każdej fazy DMAIC,
• grupa WhatsApp z trenerem i innymi uczestnikami, z odpowiedzią w ciągu 24 godzin,
• własny projekt realizowany w Twojej firmie i obrona przed Black Beltem,
• dostęp do materiałów przez 365 dni,
• certyfikat wydawany przez instytucję szkoleniową o numerze 2.18/00117/2020.

Nie przyniesiesz do CV kolejnego „zapoznałem się z narzędziami”. Przyniesiesz obroniony projekt z policzoną oszczędnością.

🚨 Sprawdź szczegóły i program szkolenia ➡️ [LINK DO KURSU]

‍