Lean Six Sigma i DMAIC: doskonalenie procesów Lean oparte na danych

Doskonalenie procesów Lean daje uporządkowany sposób na znalezienie miejsc, w których praca traci na czasie lub jakości, a następnie sprawdzenie zmian na podstawie dowodów. W tym przewodniku wyjaśniamy, jak Lean Six Sigma i DMAIC wspierają te działania, jakich danych wymaga każdy etap i jak zastosować ten cykl w procesie od zamówienia do płatności. Skupiamy się na wiarygodnym punkcie odniesienia, analizie weryfikującej założenia i mechanizmach, które pomagają utrzymać usprawnienia.

Doskonalenie procesów Lean to coś więcej niż zestaw narzędzi. DMAIC zapewnia praktyczną strukturę do badania procesu i podejmowania decyzji o zmianach.

Czym jest Lean Six Sigma, a czym nie jest

Lean, Six Sigma i Lean Six Sigma są ze sobą powiązane, ale pomagają rozwiązywać różne problemy.

Lean ma na celu wyeliminowanie czynności, które nie dodają wartości, takich jak oczekiwanie, niepotrzebne przekazywanie pracy i poprawki. Six Sigma ogranicza zmienność i błędy. Lean Six Sigma łączy oba cele w uporządkowanych działaniach doskonalących.

Mapowanie w Lean, w tym mapowanie strumienia wartości, pomaga przedstawić oczekiwany przebieg pracy. Dane o procesie pokazują, jak sprawy faktycznie przechodzą przez systemy. Mapa i dane dają zespołowi podstawę do rozmowy o różnicach między rzeczywistym przebiegiem procesu a oczekiwaniami.

Warto też jasno określić, czym Lean Six Sigma nie jest:

• To nie jest program certyfikacji. Poziomy pasów to forma szkolenia. Certyfikat nie zastępuje pomiaru punktu odniesienia ani rzeczywistego projektu doskonalącego.
• To nie zastępuje znajomości procesu. DMAIC porządkuje analizę, ale zespół nadal musi rozumieć pracę i jej ograniczenia.
• To nie jest jednorazowy projekt. Etap Control pozwala monitorować proces po zakończeniu pracy zespołu projektowego.
• Nie ogranicza się do produkcji. W procesach biurowych również występują oczekiwanie, poprawki, przekazywanie pracy i zbędne czynności.

Dlaczego DMAIC wymaga danych, a nie opinii

DMAIC obejmuje etap Measure, ponieważ bez punktu odniesienia nie da się stwierdzić, czy proces się poprawił. Bez niego etap Analyze może przerodzić się w spór o to, czyja pamięć jest bardziej wiarygodna.

Ręczna obserwacja i próbkowanie pomagają zrozumieć proces, ale obejmują tylko te sprawy i etapy, które poddano obserwacji. W procesach biurowych praca może przebiegać w systemach ERP, CRM, systemie zgłoszeń i arkuszach kalkulacyjnych. Żaden obserwator nie widzi każdej sprawy od początku do końca.

Jeśli systemy rejestrują identyfikator sprawy, czynność i znacznik czasu, można wykorzystać te zapisy zdarzeń do odtworzenia przebiegu spraw w procesie. Zamiast ręcznie zbierać każdą obserwację, zespół sprawdza dane i interpretuje wyniki. process mining pozwala analizować te zapisy w całym procesie.

Porównanie udokumentowanego i rzeczywistego przebiegu pracy może ujawnić dwa rodzaje rozbieżności:

• Etapy widoczne na diagramie, ale pomijane w praktyce. Kontrola może już nie być wykonywana albo zatwierdzenie może nie być już wymagane.
• Etapy wykonywane w praktyce, ale nieuwzględnione na diagramie. Obejście procedury mogło stać się rutyną, mimo że nie ma jasno wyznaczonej osoby odpowiedzialnej ani przeglądu.

Pięć etapów DMAIC w doskonaleniu procesów Lean

DMAIC obejmuje pięć standardowych etapów: Define, Measure, Analyze, Improve i Control. Każdy odpowiada na inne pytanie i prowadzi do innego rezultatu. Te etapy doskonalenia procesów Lean pomagają przejść od jasno określonego problemu do monitorowanej zmiany.

Define: określenie problemu, zakresu i CTQ

Jakie dane zastępuje: założenia dotyczące tego, które sprawy i czynności należą do zakresu.

Określcie problem do rozwiązania, granice procesu oraz miary krytyczne dla jakości (CTQ), istotne dla klienta lub firmy. Najpierw uzgodnijcie, co oznacza jedna sprawa. Może to być zamówienie, zgłoszenie, faktura lub roszczenie. Od tej decyzji zależy, które zdarzenia zostaną połączone i jak będą obliczane wszystkie kolejne miary.

Wykorzystajcie dane o procesie, aby sprawdzić, czy wstępna ocena zespołu odpowiada obecnemu przebiegowi pracy. Analiza może ujawnić warianty lub miary, które nie pojawiły się podczas warsztatu. Udokumentujcie zakres na mapie procesu lub diagramie BPMN, aby zespół mógł odwoływać się do tego samego obrazu.

Oczekiwany rezultat: zakres, za który może odpowiadać jeden zespół, zrozumiała dla wszystkich definicja sprawy i CTQ możliwe do zmierzenia na podstawie dostępnych danych.

Measure: ustalenie punktu odniesienia dla czasu cyklu, kosztów i poprawek

Jakie dane zastępuje: szacunki i małe próbki wykorzystywane jako przybliżenie obecnych wyników.

Zmierzcie proces względem CTQ uzgodnionych na etapie Define. W zależności od dostępnych danych i zakresu projektu punkt odniesienia może obejmować czas cyklu, koszt i liczbę poprawek na sprawę.

Jeśli proces obejmuje kilka systemów, ustalcie, jak połączyć ich zapisy. Łączenie dzienników według uzgodnionego identyfikatora sprawy pomaga śledzić ją w różnych systemach. Przed wykorzystaniem wyników zweryfikujcie sposób łączenia danych i znaczniki czasu. Niepełne lub błędne połączenie może sprawiać, że punkt odniesienia wygląda na bardziej wiarygodny, niż jest w rzeczywistości.

Opiszcie obecne wyniki na podstawie punktu odniesienia, zanim wyznaczycie cel. Dobierajcie miary do opisu problemu, zamiast wybierać je tylko dlatego, że łatwo je uzyskać.

Oczekiwany rezultat: punkt odniesienia do przeglądu przez właściciela procesu, wraz z opisem założeń i ograniczeń danych.

Zobaczcie, jak ustalić punkt odniesienia na podstawie rzeczywistych danych o procesie.

Analyze: znajdowanie wąskich gardeł, wariantów i rozbieżności dotyczących zgodności

Jakie dane zastępuje: hipotezy z warsztatów, których nie sprawdzono w odniesieniu do rzeczywistego przebiegu procesu.

Przeanalizujcie dowody, aby zrozumieć, skąd biorą się różnice w wynikach. Sprawdźcie, gdzie kumulują się opóźnienia, jakie warianty procesu występują, jaki odsetek spraw przebiega mniej typowymi ścieżkami i gdzie rzeczywisty przebieg odbiega od założeń.

Wariant procesu to jedna ze ścieżek, którymi sprawy przechodzą przez proces. Porównanie wariantów pomaga ustalić, czy opóźnienie dotyczy wielu spraw, czy koncentruje się na konkretnej ścieżce. Analiza zgodności zestawia rzeczywisty przebieg z założonym procesem i wskazuje różnice.

Uszeregujcie potencjalne przyczyny według wpływu i sprawdźcie je na podstawie danych. Rzetelna analiza może potwierdzić pierwotną hipotezę zespołu, ale może też wykazać, że główne ograniczenie leży gdzie indziej. Praktyczny przykład znajdziecie w artykule jak analizować proces i znajdować wąskie gardła.

Oczekiwany rezultat: lista potencjalnych przyczyn źródłowych uporządkowana według priorytetu, poparta dowodami i otwarta na weryfikację.

Improve: ustalanie priorytetów i testowanie zmian przed wdrożeniem

Jakie dane zastępuje: wybór zmiany, bo jest znana lub łatwo ją ogłosić.

Na podstawie analizy wybierzcie zmiany, które odpowiadają zidentyfikowanym przyczynom. Porównajcie oczekiwany wpływ z wymaganym nakładem pracy i ryzykiem. Jeśli to możliwe, zamodelujcie docelowy proces i przeprowadźcie symulację różnych scenariuszy przed wdrożeniem. Pozwala to sprawdzić możliwy wpływ zmiany na proces, ale symulacja nie gwarantuje określonego wyniku.

Udokumentujcie docelowy proces, aby osoby wykonujące pracę rozumiały jej nowy przebieg. Po wdrożeniu zmierzcie te same wskaźniki co przy ustalaniu punktu odniesienia. Porównanie pomoże ocenić, czy zmiana poprawiła wyniki, czy spowodowała nowe ograniczenie w innym miejscu.

Oczekiwany rezultat: zmiana sprawdzona względem punktu odniesienia oraz plan oceny rzeczywistych wyników po wdrożeniu.

Control: monitorowanie wyników, dashboardy i odpowiedzialność

Jakie dane zastępuje: poleganie na sporadycznych audytach lub pamięci, aby zauważyć zmianę wyników.

Etap Control pomaga utrzymać usprawnienie. Wybierzcie monitorowane miary, ustalcie progi uruchamiające przegląd i wskażcie osobę odpowiedzialną za reakcję. Dashboard pozwala właścicielowi procesu sprawdzić, czy wyniki się zmieniają i co wymaga analizy.

Uzgodnijcie częstotliwość przeglądów i działania podejmowane po wyjściu miary poza oczekiwany zakres. Wraz ze zmianą wolumenu lub struktury spraw sprawdzajcie, czy proces i jego cele nadal są aktualne.

Oczekiwany rezultat: wskazana osoba odpowiedzialna, jasne zasady przeglądu oraz miary pomagające wykryć pogorszenie wyników i zdecydować o dalszych działaniach. Więcej o bieżących pomiarach przeczytacie w artykule jak stale monitorować proces.

Przykład: proces od zamówienia do płatności

Oto przykład zastosowania pięciu etapów w procesie od zamówienia do płatności. Poniższe liczby ilustrują jeden scenariusz i nie stanowią obietnicy wyników.

Define. Projekt obejmuje proces od zamówienia do płatności dla jednej grupy produktów. Sprawa zaczyna się po przyjęciu zamówienia, a kończy po opłaceniu faktury. CTQ to poprawność faktury i czas do otrzymania płatności. Ponieważ problemem są opóźnienia w płatnościach, właściwszym punktem końcowym jest zapłata, a nie wysyłka.

Measure. Zespół łączy dane o zdarzeniach z systemu ERP i systemu fakturowania, korzystając z numeru zamówienia. Punkt odniesienia pokazuje medianę 34 dni od przyjęcia zamówienia do otrzymania płatności. Jedenaście z tych dni przypada na okres między wystawieniem a wysłaniem faktury.

Analyze. Opóźnienie koncentruje się na określonych ścieżkach. W tym przykładzie 22% zamówień przechodzi ręczną kontrolę kredytową, która wydłuża proces o dziewięć dni, a co szósta faktura jest wystawiana ponownie, co rozpoczyna naliczanie czasu do płatności od nowa. Żadna z tych ścieżek nie występuje w udokumentowanym modelu procesu.

Improve. Zespół rozważa podniesienie progu oceny kredytowej, aby ręczne kontrole dotyczyły tylko wyjątków. Symulacja na podstawie danych historycznych sugeruje, że mogłoby to skrócić proces o dziewięć dni w przypadku 18% zamówień, bez zwiększenia strat z tytułu nieściągalnych należności w analizowanych danych. Po wdrożeniu zespół nadal musi sprawdzić rzeczywiste wyniki.

Control. Zespół śledzi odsetek zamówień przechodzących ścieżką ręczną i ustala próg uruchamiający przegląd. Za miarę odpowiada zespół obsługi zamówień, a dashboard jest dostępny dla zespołu odpowiedzialnego za proces.

Typowe przyczyny niepowodzeń w doskonaleniu procesów Lean

Projekt DMAIC może na papierze przebiegać zgodnie z planem, a mimo to nie przynieść użytecznej zmiany. Zwróćcie uwagę na następujące problemy:

• Biurokracja związana z poziomami pasów. Zespół poświęca czas na dokumentację projektu, zanim sprawdzi proces lub dane. Karty projektu i mapy interesariuszy mogą być pomocne, ale same nie świadczą o postępach.
• Brak wiarygodnego punktu odniesienia. Jeśli etap Measure zostanie pominięty lub oparty wyłącznie na ankiecie, na etapie Analyze niewiele da się zweryfikować. Bez punktu wyjścia nie można później rzetelnie porównać wyników.
• Zakres określony na poziomie całego programu. Szeroki program może nie mieć jednego właściciela, definicji sprawy ani miary, na którą wpływ ma jeden zespół. Zawęźcie zakres do procesu o jasno określonych granicach i odpowiedzialności.
• Wybór usprawnienia przed analizą. Jeśli zespół już zdecydował, co zautomatyzować lub przeprojektować, może szukać wyłącznie dowodów potwierdzających tę decyzję. Wykorzystajcie etap Analyze do sprawdzenia proponowanej przyczyny, a nie do uzasadnienia z góry wybranego rozwiązania.
• Brak etapu Control. Jeśli po zakończeniu projektu nikt nie odpowiada za miary, zmiany wyników mogą pozostać niezauważone. Przed zamknięciem projektu wskażcie osobę odpowiedzialną, progi i częstotliwość przeglądów.

Jak ProcessMind wspiera poszczególne etapy DMAIC

ProcessMind pomaga analizować dane o procesach, dokumentować ich przebieg, oceniać wyniki i symulować proponowane zmiany. Wspiera analizę, ale to zespół decyduje o zmianach i je wdraża. Te narzędzia do doskonalenia procesów Lean dostarczają dowodów na potrzeby cyklu DMAIC, nie zastępując wiedzy o procesie ani odpowiedzialności za niego.

Wszystkie etapy opierają się na wspólnej definicji procesu. Jeśli na każdym z nich wykorzystuje się inne dane lub inny obraz procesu, zespół może tracić czas na uzgadnianie różnic zamiast oceniać usprawnienie.

Opis przebiegu analizy znajdziecie w artykule jak analizować dane o procesie. O tym, jak modelowanie procesów uzupełnia process mining, przeczytacie w artykule o połączonej roli modelowania procesów i process mining.

Jak rozpocząć projekt DMAIC

Wykorzystajcie te kroki, aby przejść od ogólnego celu doskonalenia do projektu, którego wyniki można mierzyć. Ten model doskonalenia procesów Lean pomaga skupić pierwszy cykl na procesie, który zespół potrafi zdefiniować, zmierzyć i ocenić:

1. Wybierzcie proces z jasno wskazanym właścicielem. Jeśli nikt nie odpowiada za proces, trudno będzie przypisać odpowiedzialność za etap Control.
2. Uzgodnijcie definicję sprawy. Zapiszcie, co rozpoczyna i kończy sprawę, oraz ustalcie, które systemy rejestrują te zdarzenia.
3. Najpierw mierzcie, potem doskonalcie. Ustalcie punkt odniesienia, zanim warsztaty lub prace nad zmianą procesu wyznaczą jego docelowy kształt.
4. Skupcie się na pierwszym cyklu. Zacznijcie od zakresu, który zespół może zbadać i ocenić. Następnie wykorzystajcie wnioski, aby zdecydować, czym zająć się dalej.

Po sprawdzeniu zmiany przejdźcie do wdrożenia usprawnień.

Co dalej

Rozpocznijcie projekt DMAIC od pomiaru punktu odniesienia.

Rozpocznijcie projekt DMAIC od pomiaru punktu odniesienia