Zarządzanie projektem 6 Sigma. Faza Define krok 1. Definiowanie problemu

W pierwszej części naszej serii o metodyce DMAIC pisaliśmy, że jest ona podobna trochę do wizyty u lekarza, gdzie pacjent wie że coś mu dolega ale nie wie co, a lekarz powinien się dowiedzieć. Takim lekarzem w podejściu Six sigma jest Green Belt lub Black Belt, którzy biorą „na klatę” problemy firm w których pracują (lub którym doradzają) i uruchamiają projekty DMAIC.

Wybór problemu jest pierwszym krokiem w fazie define i jest kluczowy dla powodzenia projektu. Skąd wiemy, czy jakiś problem nadaje się do rozwiązania za pomocą DMAIC? Wyróżników jest kilka i omówimy w tym artykule każdy z nich. Warto zacząć od tego, czy problem który chcemy rozwiązać jest problemem biznesowym. Co to oznacza? Ano oznacza to tyle, że problem musi być istotny dla firmy i rodzaju działalności jaki ta firma prowadzi. Istotność biznesowa problemu jest kluczowa w podejściu Six Sigma, ponieważ Six Sigma to program rozwoju biznesu, a zatem nie podejmuje się działań, które biznesu nie wspierają. Jak możemy dowiedzieć się zatem, czy problem jest adekwatny? Na przykład sprawdzamy czy problem którego chcemy się podjąć odnosi się bezpośrednio do KPIs naszej organizacji.Jeżeli firma posiada system zarządzania który wykorzystuje chociażby Strategiczną Kartę Wyników to w bezpośredni sposób będzie to wynikało z przyjętych w Karcie Wyników wskaźników.

Jeżeli Karta Wyników „tłumaczy” strategię na mierzalne wskaźniki i cele, a firma realizuje konkretną strategię, to nie będzie raczej możliwe, by KPIs nie odzwierciedlały potrzeb biznesowych danej organizacji. Idealnym rozwiązaniem dla firmy w która chce prowadzić efektywny program 6 sigma byłoby wybieranie projektów które wpadają do koszyka potencjalnych inicjatyw, które są oceniane przez komitet oceniający i zostają zakwalifikowane jako „odpowiednie” do realizacji. Następnie takie projekty zostają przypisane do realizacji GB, BB lub MBB, a rozliczanie efektów następuje poprzez cykliczne raportowanie rezultatów do Six Sigma Championa, który jest ambasadorem programu Six Sigma w firmie. Jak można się domyślić, znacznie łatwiej działa się GB i BB w sytuacji, w której w organizacji funkcjonuje program Six Sigma i nie mamy do czynienia z sytuacją, że przypadkowo pojawiające się projekty są realizowane za pomocą DMAIC. To z czym powinniśmy mieć do czynienia to zaplanowany i systematyczny proces identyfikacji, oceny i przypisywania konkretnych projektów, których celem jest rozwój biznesu jak i organizacji.

Drugim warunkiem jest to, żeby projekt był wspierany poprzez to samo najwyższe kierownictwo, o którym pisaliśmy powyżej. Co to znaczy wspierany? Ano znaczy to tyle, że nie wystarczy zgoda na realizację, poklepanie po ramieniu i życzenia „wszystkiego najlepszego czy powodzenia”. Projekt jest identyfikowany przez kierownictwo jako kluczowy dla biznesu, tym samym angażuje to kierownictwo, co oznacza realne wsparcie i pomoc w krytycznych dla projektu chwilach, takich jak: braki zasobowe, przejściowe trudności, nagłe pożary, inne priorytety, itd. Innymi słowy kierownictwo zdaje sobie sprawę z tego, że wstrzymanie projektu jest związane z nieodwołalnymi stratami dla biznesu (no bo projekt jest przecież biznesowy). Tak jak pisaliśmy w części pierwszej naszej serii, zaangażowanie wyższego kierownictwa jest kluczowe tak dla całego programu Six Sigma jak i poszczególnych projektów.

Trzecim warunkiem wyboru dobrego problemu jest to, że musi on być mierzalny. Oznacza to nie mniej ni więcej tylko tyle, że jesteśmy w stanie sformułować opinię: „jesteśmy tutaj, a chcielibyśmy być tam”, gdzie „tutaj” i „tam” są wyrażone poprzez konkretne dane. Takie zdanie wskazuje jasno, że dysponujemy informacjami które pokazują, że obecny performance, poziom zadowolenia klienta, poziom braków, itd. nie jest dla nas na akceptowalnym poziomie. Ta różnica między stanem obecnym a pożądanym to jest właśnie nasz problem, który chcemy rozwiązać i wykorzystać do tego DMAIC. Mierzalność problemu wymusza odwołanie się do danych, co oznacza, że jeżeli w naszej firmie procesy nie są opomiarowane/mierzone, będziemy musieli poświęcić trochę czasu na zebranie danych (w niektórych firmach nazywa się to fazą pre-Define). Pocieszę Was – podobnie będzie w fazie Measure, tyle że tego czasu będziemy tam potrzebować znacznie więcej… Ale wróćmy do definicji problemu. Z drugie strony zdarza się, że firma posiada doskonale opisany procesy które są „zmierzone” i dane znajdują się w systemach informatycznych – wtedy wystarczy zebrać te dane i wykazać powagę problemu. Jednym z podstawowych narzędzi które nam w tym pomaga może być analiza Pareto.

Po czwarte dobry problem jest ograniczony jeśli chodzi o zakres oraz czas przeznaczony na projekt, który ma go rozwiązać. Mamy zatem do czynienia z problemem który jest przypisany do konkretnego procesu lub podprocesu, linii montażowej czy działu. Jest to zatem nie problem określony bardzo ogólnie tylko szczegółowo. Aby projekt udało się zrealizować w rozsądnym czasie (zakłada się że powinno to być maks. 6 miesięcy) musi być dookreślony i zawężony. Przede wszystkim zaś musimy mieć pewność, że to co definiujemy/opisujemy to problem, a nie symptom. Jaka jest różnica między jednym a drugim? Wróćmy do przykładu z lekarzem. Idę do lekarza mówiąc że mam problem bo bolą mnie plecy. Lekarz na to odpowie, że problemem nie jest ból pleców, tylko że za długo przesiaduję w fotelu w ciągu dnia. Żeby to zmienić, trzeba się ruszyć z fotela lub zmienić fotel na bardziej ergonomiczny (to najprawdopodobniej pomoże tylko na krótką metę). Ból pleców to zatem symptom. Podobnie w naszych firmach. Problemem nie jest koszt, braki, niezadowolenie klienta – to są wszystko symptomy. Problemem będzie natomiast: znaczny odpad produkcyjny spowodowany rysami na powierzchni produktu (koszt), niestabilny proces produkcyjny na maszynie nr 5 (braki) czy zbyt długi proces rekrutacji (zadowolenie klienta). Powyższe sformułowania: znaczny, niestabilny oraz zbyt długi muszą koniecznie zostać doprecyzowane, wyrażone za pomocą liczb/danych, by spełnić wymóg mierzalności. Jak przejść od poziomu symptomu do poziomu problemu? Jednym z narzędzi które możemy do tego wykorzystać jest metoda 5 Why, zwana metodą 5 razy „dlaczego?” lub będąc bardziej precyzyjnym 5 razy „z jakiego powodu?”.

Po piąte (last but not least), przyczyna i rozwiązanie naszego problemu nie są znane. To warunek konieczny by projekt DMAIC mógł być uruchomiony, w przeciwnym razie – jeżeli znamy problem i wiemy co mamy zrobić, zastosowanie naszego podejścia mija się z celem. Szkoda czasu, pieniędzy, zasobów i energii. Jeżeli wiem co mam zrobić kieruję się w kierunku popularnych metodyk zarządzania projektami (tradycyjnymi, agile, itp.), które właśnie do tego służą.

Powyższe wymagania w liczbie pięciu umożliwiają nam GB i BB  na odpowiednie sformułowanie problemu, zaangażowanie kierownictwa i uruchomienie działań projektowych z pewnością, że nie zostaną za chwilę wstrzymane, bo problem który chcemy rozwiązań nie będzie miał wpływu na biznes. Gdzie to wszystko (problem, cel projektu, zakres, daty) o czym teraz mówimy opisać? Służy do tego Project Charter (karta projektu), która pełni w projekcie Six Sigma rolę kontraktu między liderem projektu DMAIC a sponsorem i championem. O karcie projektu będzie w podsumowaniu fazy define, która kończy się kick-offem projektu często połączonym z podpisaniem właśnie project charter’a. Natomiast zanim do tego dojdzie musimy dobrze ustalić zakres procesu, który będziemy analizować oraz wymagania klienta. W następnej publikacji napiszemy jak określić zakres procesu, którym chcemy się zająć w naszym projekcie usprawnienowym. Już teraz zapraszam!