Analiza przyczyn źródłowych Six Sigma DMAIC
Krótki opis
Szablon Analiza przyczyn źródłowych Six Sigma DMAIC to uporządkowane, pięcioetapowe ramy rozwiązywania problemów, ułożone od lewej do prawej w pięciu kolumnach: Define, Measure, Analyze, Improve i Control. W każdej fazie u góry znajdują się pytania pomocnicze, a poniżej — dedykowane miejsce robocze na zapisywanie ustaleń. Szablon wymusza sekwencję opartą na danych — użytkownicy nie powinni przechodzić do etapu Improve, zanim etap Analyze nie zostanie zweryfikowany danymi.
Kto może z niego korzystać
Inżynierowie jakości, zespoły doskonalenia procesów, zespoły produktowe i inżynieryjne, menedżerowie operacyjni oraz praktycy Six Sigma (Green Belt/Black Belt). Zastosowalne w przemyśle wytwórczym, tworzeniu oprogramowania, ochronie zdrowia, finansach oraz w każdej branży skoncentrowanej na redukcji wad lub zmienności procesów.
Jak tego używać
Pracuj kolejno od lewej do prawej przez pięć faz:
Zdefiniuj – Określ problem, zidentyfikuj klienta, ustal cel i zakres.
Zmierz – Ustal metrykę bazową i zbierz dane o aktualnej wydajności.
Analizuj – Zidentyfikuj przyczyny źródłowe, stosując 5 Whys lub diagram rybiej ości; zweryfikuj przyczyny danymi. (Do tej fazy można dołączyć ramkę 5 Whys lub diagram rybiej ości.)
Ulepsz – Opracuj rozwiązania ukierunkowane na zweryfikowane przyczyny źródłowe; przeprowadź pilotaż przed pełnym wdrożeniem.
Kontroluj – Ustandaryzuj rozwiązanie, monitoruj wyniki i określ plan reakcji, aby utrzymać osiągniętą poprawę.
Przykład
Zespół produktowy zajmujący się defektami oprogramowania, które trafiają do produkcji:
Define: Zbyt wiele błędów trafia do użytkowników końcowych; celem jest zmniejszenie liczby błędów wydostających się do produkcji o 50% do końca IV kwartału; zakres obejmuje zespół koszyka i płatności.
Measure: Punktem odniesienia jest 14 błędów wydostających się do produkcji miesięcznie (maj–lipiec); 60% przypisano modułowi koszyka; dział wsparcia poświęca około 90 godzin/miesiąc na zgłoszenia błędów.
Analyze: Analiza 5 Whys dla dziesięciu najważniejszych błędów wykazała brak zautomatyzowanego zestawu testów regresyjnych i pośpieszne przeglądy przed wydaniem; 8 z 10 błędów zostałoby wykrytych przez testy regresyjne.
Improve: Opracowano zautomatyzowany zestaw testów regresyjnych z 120 testami; dodano listę kontrolną przeglądu PR oraz 24-godzinne zamrożenie wydań; pilotaż przeprowadzono z zespołem koszyka i płatności we wrześniu.
Control: Cotygodniowy panel błędów; próg alertu ustawiono na 5 błędów wydostających się do produkcji miesięcznie; zestaw testów regresyjnych obowiązkowy w CI dla wszystkich zespołów od października. Wynik: po pilotażu liczba błędów wydostających się do produkcji spadła z 14 do 6 miesięcznie.
Pozdrawiam!
Khawaja Rizwan
