DMAIC jako metodologia doskonalenia procesów oparta na danych

DMAIC to pięciofazowa metoda rozwiązywania problemów procesowych oparta na sekwencji Define, Measure, Analyze, Improve i Control, czyli: definiowanie, pomiar, analiza, doskonalenie i kontrola. Jej korzenie sięgają programu Six Sigma rozwijanego w Motoroli w latach 80., z którym wiązany jest inżynier Bill Smith. DMAIC wymusza przejście od precyzyjnego nazwania problemu, przez zebranie danych i potwierdzenie przyczyn, aż do wdrożenia zmiany oraz zabezpieczenia procesu przed powrotem do wcześniejszych wyników.

W publikacjach dotyczących historii Six Sigma często przywołuje się znaczne ograniczenie liczby defektów oraz wielomiliardowe oszczędności osiągnięte przez Motorolę. Konkretne kwoty różnią się zależnie od okresu i sposobu ich liczenia, dlatego ważniejsza od pojedynczej liczby jest logika stojąca za tym rezultatem: problemy nie były rozwiązywane na podstawie intuicji, lecz przez pomiar zmienności, analizę przyczyn i kontrolę wyników po wdrożeniu.

DMAIC sprawdza się przede wszystkim tam, gdzie istniejący proces regularnie generuje błędy, opóźnienia, straty lub niestabilne wyniki, a przyczyna problemu nie jest oczywista. Metoda może być stosowana w produkcji, logistyce, sprzedaży, finansach, obsłudze klienta oraz procesach administracyjnych. Warunkiem jest możliwość obserwowania procesu i mierzenia jego wyników.

Co oznacza skrót DMAIC i jaki jest cel tej metodologii?

Skrót DMAIC opisuje pięć kolejnych faz projektu:

• Define, czyli zdefiniuj problem, cel, zakres i wymagania klienta.
• Measure, czyli zmierz sposób działania procesu i ustal poziom bazowy.
• Analyze, czyli znajdź oraz potwierdź przyczyny źródłowe.
• Improve, czyli zaprojektuj, przetestuj i wprowadź rozwiązania.
• Control, czyli ustabilizuj nowy sposób pracy i monitoruj rezultaty.

Głównym celem metodologii DMAIC jest systematyczne eliminowanie przyczyn defektów, zmienności i niewystarczającej wydajności istniejącego procesu. Zespół nie powinien przechodzić bezpośrednio od zauważenia problemu do wdrożenia pierwszego dostępnego pomysłu. Najpierw musi ustalić skalę zjawiska, zrozumieć mechanizm jego powstawania i potwierdzić, czy planowana zmiana wpływa na właściwą przyczynę.

W praktyce biznesowej cykl DMAIC może służyć między innymi do:

• ograniczenia liczby błędów i reklamacji,
• skrócenia czasu realizacji procesu,
• zmniejszenia kosztów złej jakości i pracy poprawkowej,
• stabilizacji wyników między zmianami, zespołami lub lokalizacjami,
• poprawy terminowości i satysfakcji klientów,
• zwiększenia zdolności procesu do obsługi większego wolumenu.

Różnica między DMAIC a działaniem ad hoc polega na sposobie dochodzenia do rozwiązania. W podejściu ad hoc organizacja reaguje na najbardziej widoczny objaw. W DMAIC każda hipoteza musi zostać odniesiona do danych, a wynik poprawy porównany z poziomem bazowym. Metoda ogranicza w ten sposób ryzyko wdrażania zmian, które są logiczne na pierwszy rzut oka, lecz nie rozwiązują rzeczywistego problemu.

Jak DMAIC łączy się z Six Sigma i Lean Six Sigma?

DMAIC stanowi podstawowy model realizacji projektów Six Sigma dotyczących poprawy istniejących procesów. Six Sigma jest szerszą koncepcją zarządzania jakością i zmiennością, natomiast DMAIC porządkuje sposób prowadzenia konkretnego projektu. Nie są to więc pojęcia tożsame. DMAIC jest metodą wykorzystywaną wewnątrz Six Sigma.

Six Sigma powstała w Motoroli w latach 80. jako odpowiedź na problemy jakościowe i presję konkurencyjną. Bill Smith zwrócił uwagę na związek między zmiennością procesu, wadami ujawnianymi podczas użytkowania produktów i kosztami napraw. Program uzyskał silne wsparcie kierownictwa Motoroli, a firma otrzymała w 1988 roku Malcolm Baldrige National Quality Award.

W latach 90. Six Sigma została upowszechniona przez General Electric pod kierownictwem Jacka Welcha. GE połączyło projekty doskonalące z rozwojem menedżerów, systemem celów i oceną efektów finansowych. W raportach i opracowaniach dotyczących programu przywoływane są setki milionów dolarów nakładów oraz jeszcze wyższe korzyści osiągane w kolejnych latach. Historia GE pokazuje, że sama znajomość narzędzi statystycznych nie wystarcza. Potrzebne są sponsorzy, zasoby, odpowiedzialność właścicieli procesów i powiązanie projektów z wynikiem organizacji.

Lean Six Sigma łączy koncentrację Six Sigma na jakości i zmienności z podejściem Lean, które koncentruje się na przepływie, wartości dla klienta oraz eliminacji marnotrawstwa. W projekcie Lean Six Sigma analiza może więc obejmować zarówno liczbę defektów i rozrzut wyników, jak i kolejki, zbędny transport, oczekiwanie, nadmierne zapasy lub wielokrotne przekazywanie tej samej sprawy. DMAIC pozostaje strukturą projektu, ale jest uzupełniany przez takie narzędzia Lean, jak VSM, standaryzacja pracy, zarządzanie wizualne, 5S czy analiza wartości dodanej.

Kiedy lepiej zastosować DMAIC, a kiedy DMADV lub PDCA?

DMAIC należy zastosować, gdy proces już istnieje, lecz nie spełnia oczekiwań dotyczących jakości, czasu, kosztu albo stabilności. Problem powinien być powtarzalny, mierzalny i na tyle złożony, że nie można wiarygodnie wskazać jego przyczyny bez pogłębionej analizy.

DMADV, czyli Define, Measure, Analyze, Design, Verify, jest właściwszy przy projektowaniu nowego procesu, produktu lub usługi. Może być także potrzebny wtedy, gdy obecnego procesu nie da się usprawnić bez zmiany jego podstawowej konstrukcji. DMAIC optymalizuje istniejący model, natomiast DMADV prowadzi do zaprojektowania nowego.

PDCA, czyli Plan, Do, Check, Act, sprawdza się w szybszych, iteracyjnych cyklach ciągłego doskonalenia. Jest dobrym wyborem, gdy problem ma ograniczony zakres, przyczyna jest stosunkowo łatwa do sprawdzenia, a rozwiązanie można szybko i bezpiecznie przetestować. PDCA stanowi historyczne i koncepcyjne źródło wielu współczesnych metod doskonalenia, lecz nie narzuca tak szczegółowej analizy statystycznej ani tak rozbudowanych bramek projektowych jak DMAIC.

W praktyce należy dobrać metodykę do problemu, a nie problem do preferowanej metodyki. Pełny projekt DMAIC byłby nieekonomiczny przy prostym odstępstwie, które można usunąć po krótkiej obserwacji. Z kolei zastosowanie uproszczonego PDCA do chronicznego problemu jakościowego może zakończyć się kolejną serią nieskutecznych korekt.

Pięć faz DMAIC krok po kroku

Fazy DMAIC tworzą sekwencję. Zespół nie powinien przechodzić do projektowania rozwiązań, zanim nie potwierdzi przyczyn problemu. Każdy etap powinien zakończyć się przeglądem bramkowym, nazywanym gate review. Sponsor, właściciel procesu i prowadzący projekt sprawdzają wtedy, czy powstały wymagane rezultaty i czy dostępne dowody uzasadniają rozpoczęcie kolejnej fazy.

Nie oznacza to, że projekt przebiega bez żadnych powrotów. Nowe dane mogą wymagać korekty zakresu albo ponownego sprawdzenia pomiaru. Powroty powinny jednak wynikać z odkrytych faktów, a nie z braku dyscypliny projektowej.

Define i Measure: jak zdefiniować problem i zmierzyć stan obecny?

Cel fazy Define: ustalenie, jaki problem ma zostać rozwiązany, dla kogo jest on ważny, jaki jest zakres projektu oraz czego projekt nie obejmuje.

Pytanie fazy: jaki konkretny wynik procesu wymaga poprawy i dlaczego?

Define powinno rozpocząć się od problem statement, czyli opisu problemu zawierającego miejsce jego występowania, skalę, okres oraz wpływ biznesowy. Zdanie „proces trwa za długo” nie spełnia tego warunku. Lepsza definicja wskazuje, którego procesu dotyczy opóźnienie, jaka część spraw przekracza termin i jakie konsekwencje powoduje.

Karta projektu, czyli Project Charter, porządkuje cel, zakres, mierniki, role, uzasadnienie biznesowe i harmonogram. SIPOC pozwala zobaczyć na wysokim poziomie dostawców, wejścia, proces, wyjścia oraz klientów. CTQ, czyli Critical to Quality, przekłada potrzeby klienta na mierzalne wymagania. Wstępna FMEA może pomóc rozpoznać najbardziej ryzykowne miejsca procesu, ale nie zastępuje dalszej analizy danych.

Cel fazy Measure: stworzenie wiarygodnego obrazu działania procesu przed zmianą.

Pytanie fazy: jak proces działa obecnie i jaka jest rzeczywista skala problemu?

Zespół ustala definicje wskaźników, źródła danych, sposób pobierania prób oraz okres pomiaru. Następnie wyznacza baseline, czyli poziom bazowy. Może to być średni czas realizacji, odsetek błędów, koszt jednostkowy, poziom terminowości albo liczba spraw wracających do poprawy.

Measurement System Analysis służy sprawdzeniu, czy sam system pomiarowy nie generuje błędów. W produkcji może to dotyczyć przyrządów i różnic między operatorami. W procesach usługowych problemem bywają niespójne definicje statusów, ręcznie uzupełniane dane albo różne sposoby klasyfikowania tej samej sprawy.

W jednym z projektów dotyczących procesu produkcji na siedmiu wtryskarkach trzy źródła danych pokazywały trzy różne poziomy realizacji planu. Surowe dane z systemu wskazywały 84,1%, karty produkcyjne 76,9%, a wynik po korekcie sposobu liczenia wyniósł 68,2%. Różnica wynikała między innymi z obniżania planu o awarie, przez co część niewykonanej produkcji znikała z raportowania. Próba przejścia do Improve bez uporządkowania fazy Measure prowadziłaby do optymalizacji procesu na podstawie fałszywego obrazu sytuacji.

Analyze: jak zidentyfikować pierwotną przyczynę problemu?

Cel fazy Analyze: rozpoznanie i potwierdzenie czynników, które powodują obserwowany wynik.

Pytanie fazy: dlaczego problem powstaje i które przyczyny mają mierzalny wpływ na proces?

Analiza powinna rozpocząć się od rozdzielenia objawu od przyczyny. Długi czas realizacji może wynikać z przeciążenia zasobów, ale równie dobrze z powrotów, brakujących danych, zmiennego napływu spraw albo niewłaściwej kolejności pracy. Zwiększenie zatrudnienia usunie problem tylko w pierwszym przypadku.

Diagram Ishikawy pomaga zespołowi uporządkować możliwe przyczyny w kategoriach dotyczących ludzi, metod, maszyn, materiałów, pomiaru i otoczenia. Jest narzędziem do budowania hipotez, nie dowodem potwierdzającym przyczynę. Hipotezy trzeba sprawdzić przez obserwacje, analizę danych, testy statystyczne albo kontrolowany eksperyment.

Przy odpowiedniej ilości danych można wykorzystać regresję, testy hipotez i analizę korelacji. Wskaźniki Cp i Cpk pomagają ocenić, czy stabilny proces mieści się w określonych granicach tolerancji. Cp opisuje potencjalną zdolność procesu przy założeniu właściwego wycentrowania, natomiast Cpk uwzględnia także położenie średniej względem granic specyfikacji.

Narzędzia analityczne i uczenie maszynowe mogą skrócić czas przeglądania dużych zbiorów danych, wykrywania nietypowych wariantów oraz poszukiwania korelacji. Nie rozstrzygają jednak samodzielnie o związku przyczynowym. Model może wykazać, że określona cecha współwystępuje z opóźnieniem, ale potwierdzenie mechanizmu nadal wymaga wiedzy procesowej i testu.

Improve i Control: jak wdrożyć rozwiązania i utrzymać efekty?

Cel fazy Improve: przygotowanie i przetestowanie zmian, które wpływają na potwierdzone przyczyny.

Pytanie fazy: jakie rozwiązanie poprawia wynik procesu bez generowania nieakceptowalnych skutków ubocznych?

Zespół generuje warianty rozwiązań, ocenia ich wpływ, koszt, wykonalność i ryzyko, a następnie przygotowuje pilotaż. Test A/B może porównać dwa sposoby realizacji procesu. Design of Experiments pozwala sprawdzić wpływ kilku parametrów oraz ich interakcji. W prostszych procesach wystarczy ograniczony pilotaż przeprowadzony na wybranej zmianie, grupie klientów albo typie spraw.

Ocena efektu powinna porównywać te same mierniki przed i po zmianie. Baseline i wynik po wdrożeniu muszą obejmować porównywalny wolumen, okres oraz warunki. Korzyść finansowa może wynikać z redukcji braków, mniejszej liczby godzin pracy poprawkowej, niższych kosztów reklamacji, ograniczenia nadgodzin albo zwiększenia przepustowości bez dodatkowych etatów. Samo skrócenie czasu nie jest jeszcze oszczędnością, dopóki organizacja nie określi, jak wykorzysta uwolnioną zdolność.

Cel fazy Control: utrzymanie wyniku i szybkie wykrywanie odchyleń.

Pytanie fazy: jak zapobiec powrotowi procesu do wcześniejszego sposobu działania?

Control obejmuje aktualizację standardów pracy, przypisanie odpowiedzialności, sposób raportowania oraz plan reakcji. Statistical Process Control i karty kontrolne pomagają odróżnić naturalną zmienność od sygnału wymagającego interwencji. Plan kontroli określa mierzony parametr, częstotliwość pomiaru, dopuszczalne granice, właściciela oraz działanie po przekroczeniu progu.

Nie każdy projekt wymaga rozbudowanego SPC. W procesach usługowych kontrolę mogą tworzyć dashboard, codzienny board meeting, tygodniowy przegląd błędów i cykliczny audyt standardu. Mechanizm musi być proporcjonalny do ryzyka, ale nie może ograniczać się do deklaracji, że wynik będzie monitorowany.

Narzędzia stosowane w poszczególnych fazach DMAIC

Narzędzia DMAIC powinny odpowiadać na pytanie konkretnej fazy.

W Define najczęściej wykorzystuje się Project Charter, SIPOC, Voice of the Customer, CTQ oraz wstępną FMEA. Ich zadaniem jest zdefiniowanie problemu, granic procesu, oczekiwań i ryzyk.

W Measure stosuje się plan zbierania danych, arkusze pomiarowe, mapę procesu, MSA, statystykę opisową oraz wyznaczenie poziomu bazowego. W zależności od procesu można dodać VSM, chronometraż, obserwację pracy, analizę logów systemowych albo process mining.

W Analyze wykorzystywane są diagram Ishikawy, 5 Why, Pareto, analiza regresji, testy hipotez, analiza wariancji, Cp i Cpk. Przy analizie przepływu przydatne są dane o kolejkach, powrotach, liczbie przekazań i wariantach procesu.

W Improve stosuje się macierze oceny rozwiązań, pilotaże, testy A/B, DOE, poka-yoke, standaryzację oraz analizę ryzyka rozwiązania. W projektach Lean Six Sigma mogą pojawić się również balansowanie pracy, zmiana layoutu, ograniczanie partii i poprawa przepływu.

W Control potrzebne są plan kontroli, SPC, standardowe procedury operacyjne, instrukcje pracy, dashboardy, audyty oraz plany reagowania.

Obowiązkowe są rezultaty poszczególnych faz, a nie wszystkie narzędzia z katalogu. Każdy projekt musi mieć zdefiniowany problem, wiarygodny baseline, potwierdzone przyczyny, sprawdzone rozwiązanie i mechanizm utrzymania wyniku. Zaawansowane testy statystyczne, DOE czy process mining są opcjonalne. Ich użycie zależy od rodzaju procesu, skali ryzyka, liczby zmiennych i jakości danych.

Jak sprawdzić, czy proces nadaje się do wdrożenia DMAIC?

Proces jest dobrym kandydatem do DMAIC, jeżeli:

• istnieje i jest wykonywany wystarczająco często, aby można było obserwować powtarzalne wzorce,
• jego wynik można mierzyć,
• problem wpływa na klienta, koszt, jakość, czas lub ryzyko,
• organizacja nie zna potwierdzonej przyczyny problemu,
• istnieją dane historyczne albo można je zebrać w rozsądnym czasie,
• właściciel procesu ma możliwość wdrożenia i utrzymania zmian.

Sygnałem ostrzegawczym jest sytuacja, w której proces dopiero ma powstać. Wtedy właściwsze będzie DMADV lub projektowanie procesu. DMAIC może być również nadmiernie rozbudowany, gdy przyczyna jest oczywista, rozwiązanie ma niewielkie ryzyko i można je szybko zweryfikować w cyklu PDCA.

Problematyczne są również procesy wykonywane sporadycznie, bez powtarzalnych danych albo podlegające całkowicie różnym warunkom w każdym przypadku. Przed uruchomieniem DMAIC może być wtedy potrzebna standaryzacja definicji, uproszczenie procesu lub uporządkowanie sposobu rejestrowania danych.

Cp i Cpk mogą wspierać kwalifikację procesu, gdy wynik ma mierzalne granice specyfikacji. Niski Cpk wskazuje, że proces nie mieści się stabilnie w wymaganiach albo jest przesunięty względem tolerancji. Wskaźnik nie wyjaśnia jednak przyczyn. Jest sygnałem do rozpoczęcia diagnozy, a nie gotową odpowiedzią.

Jeżeli organizacja nie wie, od którego procesu zacząć ani czy ma dane wystarczające do DMAIC, pierwszym krokiem może być audyt lub mapowanie procesów biznesowych. Pozwala ono ustalić rzeczywisty przebieg pracy, granice procesu, mierniki i obszary, w których pogłębiona analiza przyniesie największą wartość.

Dlaczego projekty DMAIC kończą się niepowodzeniem?

Pierwszą barierą jest źle zdefiniowany zakres. Projekt obejmujący cały łańcuch dostaw, wiele produktów i kilka niezależnych problemów szybko staje się niemożliwy do zarządzania. Zespół zbiera coraz więcej danych, lecz nie zbliża się do decyzji. Przeciwdziałaniem jest precyzyjny Project Charter, jednoznaczny problem statement oraz kryteria wyłączenia tematów poza zakresem.

Drugim powodem są niewiarygodne dane w fazie Measure. Jeżeli zespoły inaczej rozumieją początek i koniec procesu, błędy są klasyfikowane niespójnie, a system nie rejestruje pracy wykonywanej poza nim, baseline będzie fałszywy. Projekt może wtedy potwierdzić nieistniejącą przyczynę lub wykazać poprawę, która wynika wyłącznie ze zmiany sposobu raportowania. Potrzebne są wspólne definicje, walidacja systemu pomiarowego i porównanie danych z obserwacją procesu.

Trzecią barierą jest brak realnego sponsora. Sponsor nie powinien ograniczać się do zatwierdzenia rozpoczęcia projektu. Musi usuwać bariery między działami, zapewniać dostęp do danych, rozstrzygać konflikty priorytetów i egzekwować decyzje właścicieli działań. Bez tego projekt zatrzyma się, gdy rozwiązanie będzie wymagało zmiany odpowiedzialności albo współpracy kilku jednostek.

Czwartym problemem jest przedwczesne przejście do Improve. Uczestnicy często przychodzą na warsztat z gotowym rozwiązaniem i traktują wcześniejsze fazy jako formalność. W efekcie DMAIC staje się uzasadnieniem wcześniej podjętej decyzji. Gate review powinien zatrzymać projekt, jeżeli przyczyna nie została potwierdzona danymi.

Ostatnią barierą jest regresja po zakończeniu projektu. Nowy sposób pracy działa podczas pilotażu, gdy zespół projektowy monitoruje wyniki, lecz po kilku tygodniach wracają stare nawyki. Powodem może być brak właściciela procesu, nieaktualne instrukcje, brak mierników albo brak reakcji na pierwsze odchylenia.

Faza Control zabezpiecza organizację przed takim scenariuszem. Karty kontrolne, standardowe procedury operacyjne, dashboardy, plany reakcji i cykliczne audyty powinny zostać uruchomione przed formalnym zamknięciem projektu. Projekt DMAIC jest zakończony dopiero wtedy, gdy proces osiąga lepszy wynik bez stałej obecności zespołu projektowego.

Kiedy DMAIC będzie właściwym następnym krokiem?

Metoda DMAIC ma największą wartość przy powtarzalnym i kosztownym problemie, którego przyczyny nie można wiarygodnie ustalić na podstawie pojedynczej obserwacji. Zapewnia dyscyplinę potrzebną do oddzielenia objawów od przyczyn, sprawdzenia rozwiązania i utrzymania rezultatu.

Nie każda organizacja powinna jednak zaczynać od rozbudowanego projektu Lean Six Sigma. Czasami najpierw trzeba ustalić właściciela procesu, zmapować przepływ, ujednolicić dane lub ograniczyć zakres problemu. Dopiero wtedy można ocenić, czy potrzebny jest pełny cykl DMAIC, prostszy PDCA, czy zaprojektowanie nowego procesu.

Sigla Consulting wspiera organizacje w diagnozie, mapowaniu i optymalizacji procesów oraz w przygotowaniu i wdrażaniu rozwiązań opartych na danych. Punktem wyjścia może być rozmowa o procesie, który generuje największe koszty, opóźnienia lub problemy jakościowe, oraz o tym, jaki zakres analizy będzie adekwatny do skali problemu.

Dariusz Goluch

Prezes Zarządu, Sigla Consulting

Prezes Zarządu Sigla Consulting. Odpowiada za realizację projektów, certyfikowany praktyk Lean Management. Prowadzi transformacje od analizy stanu obecnego po standaryzację.

ProcesyPoradniki lean