7 grzechów głównych, czyli wiosno dziękuję że w końcu jesteś…

Czy zmiana pogody może mieć wpływ na eliminowanie marnotrawstw? Oczywiście, że tak.

Na poniższym przykładzie, trochę z przymrużeniem oka opiszę, jak dzięki temu że słońce zastąpiło deszcz i wichurę udaje mi się z dnia na dzień być lepszym człowiekiem dla siebie, rodziny i otoczenia.  Nie będzie to zatem wpis o tym, jak eliminować marnotrawstwa w procesach, a raczej wyjście o krok dalej – jak zastosować to podejście w życiu codziennym. W oryginalnym ujęciu bowiem ciągłe doskonalenie nie ma tylko miejsca w pracy, ale tak naprawdę duch zmiany powinien być z nami cały czas.

Jak doskonale wiemy, lub nie, 7 grzechów głównych (TIMWOOD) w naszych procesach, to:
Transportation – nadmierny transport
Inventory – zapasy
Motion – zbędny ruch
Waiting time – oczekiwanie
Overproduction – nadprodukcja
Overprocessing – nadmierne przetwarzanie
Defects – defekty, błędy, niezgodności.
Możemy do powyższych dodać jeszcze tzw. marnotrawstwo intelektu, czyli niewykorzystania kwalifikacji, umiejętności, braku zastosowania posiadanej wiedzy lub po prostu jej nierozwijanie.

Jak dzięki temu, że zmieniła się pogoda, zacząłem dzień co dzień walczyć z 7 grzechami głównymi? Proszę zobaczyć.

Transportation – dzięki temu, że na dworze jest coraz cieplej, świeci słońce i ogólnie nie padają deszcze jak również nie wieją typowe dla naszej jesieni przejmujące wiatry odstawiłem do garażu samochód i jeżdżę do pracy rowerem. Nie tylko oszczędzam paliwo, ale również spalam kalorie. Dodatkowo, gdyby zrobić diagram spaghetti okaże się, że moja trasa jest o 30% krótsza bo jadę wałami nad odrą, nie stoję w korkach i oszczędzam 5 minut. Czas nadrobiony wykorzystuję potem na to by przygotować się do pracy, ale warto.

Inventory – myślę o zwolnieniu się mojego ‚magazynu’. Moim magazynem jest szafa, w której przechowywane grube zimowe płaszcze i kurtki zostają zastąpione lekkimi wiatrówkami, bluzami z dresu, które zajmują mniej miejsca i dzięki temu mogę wykorzystać dodatkowo tę przestrzeń. Wiosna to też czas na wystawienie na balkon roślin ciepłolubnych, które całą zimę spędziły w mieszkaniu. Tym samym uwolnimy sporo metrów kwadratowych, zrobi się bardziej przestrzennie a rośliny odżyją na słońcu. Schowam je znów jesienią, by nie zmarzły.

Motion – w tym wypadku wyeliminowanie zbędnego ruchu jest związane z tym, że nie muszę w kółko podchodzić do okna i sprawdzać, czy pada deszcze czy nie pada, lub jaka jest temperatura – czy ujemna na tyle, żeby brać czapkę i szalik czy może już jest cieplej. Teraz wiem że po prostu jest ciepło, wychodzę na dwór bez obawy o to, że zaskoczy mnie chłód i mróz.

Waiting time – nie ma czasu na czekanie. Gdy wiosna za oknem nie czekam na tramwaj ani autobus tylko jadę rowerem. Nie czekam w kolejce do lekarza bo nie mam kataru ani nie czekam na autostradzie w wielkim korku bo w związku z opadami śniegu i gołoledzią są utrudnienia na trasie. Gdy pogoda za oknem i słońce świeci wszystko dzieje się szybciej. Więcej w nasz życia i motywacji do działania.

Overproduction – nadprodukcja to wytwarzanie więcej niż muszę. W okresie jesienno-zimowym wytwarzamy więcej zapasów żywieniowych (w postaci konfitur, weków, soków, itd.) które później będą przechowywane, aby móc z nich korzystać, gdy nie będzie świeżych warzyw i owoców, tak jak to jest w okresie letnim. Gdy wszystkiego jest pod dostatkiem i jest dostępne pod ręką nie magazynujemy – to takie ‚just-in-time’, czyli tyle ile trzeba na wtedy kiedy trzeba. Zmniejszenie nadprodukcji to zmniejszenie kosztów magazynowania, jak również zmniejszenie ryzyka, że coś w trakcie przechowywania nam się zepsuje. Czy komuś kiedyś zepsuł się dżem? No właśnie.

Overprocessing – nadmierne przetwarzanie to czysty ‚gold plating’. Mogę zaliczyć do tego w moim przypadku ubieranie się na cebulkę w kilka warstw ubrań, wielokrotne sprawdzanie mojego synka czy czapka dobrze przylega i szalik się nie rozwiązał, jak również inne czynności typowo już zimowe np. odśnieżanie, przerzucanie śniegu w inne miejsca, próba hamulców samochodem czy nie jest zbyt ślisko… Zamiast tego teraz mogę wyjść na dziedziniec bez większych przygotowań bez obawy o swoje zdrowie, a synek może wychodzić na dwór w krótkim rękawku.

Defects – co można rozpatrywać w kategorii defektu w tym przypadku? Moim zdaniem wszystko co dzieje się koło mnie i posługując się językiem technicznym „nie jest zgodne ze specyfikacją”. Bardzo odczuwałem w związku z tym ostatniej zimy we Wrocławiu defekt w postaci smogu w naszym mieście. Defekt jest rezultatem niesprawnie działającego procesu, braku kontroli i wiąże się z czynnościami naprawczymi. Ile czasu spędziliśmy obserwując jakość powietrza w naszym mieście? Ile zainwestowaliśmy w oczyszczacze powietrza? Dzięki lepszej pogodzie spada zanieczyszczenie powietrza pyłami 2,5 (nie pali się w piecach) i w końcu można odetchnąć pełną piersią.

Intellect – ciągły, ale to ciągły rozwój. W okresie wiosenno-letnim liczba inicjatyw na świeżym powietrzu wzrasta w sposób wykładniczy. Spotkania grup zainteresowań, kina plenerowe, miejska plaża w naszym pięknym mieście Wrocławiu, podróże, które jak wiemy kształcą… W okresie zimowym rownież mamy takie możliwości, nie mniej jednak gdy słońce na dworze liczba dostępnych eventów wzrasta średnio o około 40%. Spotkania, nowe rzeczy, nowe umiejętności – to nasz rozwój…

Tyle by było jeśli chodzi o przewagę okresu letniego nad zimowym w zakresie eliminacji marnotrawstw. Jak widać lato temu sprzyja, a prace nad ciągłym doskonaleniem możemy odnieść nie tylko do naszej pracy i firmy, ale też życia codziennego. Oczywiście z pewnym umiarem 🙂

Jak mówi KAIZEN – szukaj doskonałości we wszystkim co robisz!

Post napisany z przymróżeniem oka 😉 zatem wszelkie komentarze mile widziane

Dobrego tygodnia 🙂

Zarządzanie projektem 6 Sigma. Faza Measure krok 2. Identyfikacja potencjalnych zmiennych wpływających na problem

W ostatnim wpisie mapowaliśmy nasz proces, aby uzyskać jego szczegółowy obraz. Mówiliśmy też o tym, że w zależności od tego, jaki mamy problem, będziemy wykorzystywać różne podejścia do mapowania. Inne mapy stworzymy do problemów typowo procesowych (nazwijmy je sigmowymi) inne do typowo leanowych (eliminacja marnotrawstwa) i od doboru tych narzędzi zależy powodzenie naszego projektu. Jedno jest pewne – w etapie mapowania dla dobrego zrozumienia naszego procesu trzeba często przygotować kilka map procesów i nie jest to nic nadzwyczajnego. Czy to w celu dobrania odpowiedniego poziomu szczegółowości, czy też zawężeniu obszaru poszukiwań – aby nasz proces nie był zbyt rozległy, bo to będzie ograniczać możliwości poszukiwania i pomiaru zmiennych (nakład pracy versus dostępne zasoby). W takim przypadku, jeśli okaże się, że nasz proces jest zbyt rozbudowany (do tej pory nie wiedzieliśmy przecież jak bardzo) warto rozdzielić pracę na 2 mniejsze projekty, tak aby każdy zajmował się innym problemem. Zaowocuje to w przyszłości – będzie nam łatwiej zarządzać zakresem.

Posiadając mapy procesu, które są naszym punktem odniesienia, wraz z zespołem zaczynamy poszukiwanie x’ów które wpływają na naszego Y’ka. Zasada, którą kieruję się dobierając zespół do ćwiczenia poszukiwania zmiennych to aby był on przede wszystkim interdyscyplinarny. Dlaczego? sami eksperci z procesu prawdopodobnie nie będą w stanie zidentyfikować wszystkich przyczyn, bo gdyby tak było problem najprawdopodobniej już zostałby rozwiązany, czyż nie? Musimy zatem zebrać grupę osób, która wspólnie w trakcie spotkania, będzie w stanie zidentyfikować potencjalne przyczyny, o których do tej pory nikt nie pomyślał. Zatem interdyscyplinarność – osoby z procesu, osoby z procesów współpracujących i ktoś spoza, kto wniesie świeżość spojrzenia i swoimi obserwacjami zaskoczy wszystkich. Nie da się bowiem znaleźć przyczyn naszego problemu tylko w grupie osób, które są z procesu – gdyby było to możliwe, już przecież zostałoby to zrobione (!).

Do samej czynności generowania zmiennych polecam zastosować burzę mózgów w jej tradycyjnym wydaniu (burza mózgów A.Osborna), czyli 30 minutowa sesja w której uczestnicy z wykorzystaniem mapy procesu starają się znaleźć jak najwięcej przyczyn występowania problemu (zmiennych wpływających na Y’ka). 

Potencjalne przyczyny grupa umieszcza na mapie procesu np. za pomocą post-itów, tak jak na zdjęciu. Te potencjalne przyczyny to czyli zmienne, które w dalszej kolejności chcemy zmierzyć, zebrać do nich informacje i przeanalizować wszystkie fakty dostępne na ich temat (jeżeli nie mamy danych to zapisy wideo, mapy layout’ów powierzchni, diagramy spaghetti, itd.).

Zasady burzy mózgów Osborna. Podziel burzę mózgów na 2 sesje – kreatwyną i podsumowanie. Wprowadź przed burzą mózgów zespół w problem, daj pracownikom czas na przygotowanie się, niech każdy zgłębi temat. Przyjście nieprzygotowanym niczego nie wniesie. Proś o punktualność. Rozpocznij wprowadzeniem w zasady: liczy się ilość a nie jakość, nie krytykujemy, nie omawiamy – tylko szukamy przyczyn. Czas na omawianie przyjdzie później. Stąd burza mózgów jest nazywana metodą odroczonego wartościowania – aby omówić pomysły powinno się poczekać minimum jeden dzień, w tym czasie następuje inkubacja i może dojdziemy do tego, że o czymś ważnym zapomnieliśmy.

Po burzy mózgów, przed podsumowaniem, mamy zwykle od kilkunastu do kilkudziesięciu potencjalnych zmiennych, które zespół wskazał jako istotne, zatem należy podsumować rezultaty burzy mózgów – ograniczyć ich liczbę – poprzez wyeliminowanie powtarzających się, połączenie bardzo podobnych do siebie lub wyeliminowanie zupełnie nieracjonalnych tak, by uzyskać listę, z której będzie można w następnym kroku fazy measure zbudować plan zbierania danych. Zatem musimy wykonać coś na kształt lejkowania. Możemy wykorzystać do tego narzędzie znane jako diagram pokrewieństwa (affinity diagram), który pozwala nam podsumować nasze zmienne w kategorie ze względu na podobieństwo między nimi. Jest to użyteczne podejście, które koncentruje nasza uwagę na źródłach pochodzenia problemów i stanowi pierwszy krok do analizy możliwości kolekcji tych konkretnych danych.

Nie ma złotej zasady, która mówiłaby ile zmiennych powinniśmy mierzyć, zawsze pozostaje to rezultatem kompromisu między kosztem a możliwościami firmy. Pamiętajmy jednak o tym, że jeżeli zignorujemy zmienne które potencjalnie mogą wpływać na nasz problem i albo ich nie zdefiniujemy, albo pomimo tego że zostały zdefiniowane – nie będziemy chcieli ich mierzyć, może okazać się, że nie uda nam się w fazie analyze znaleźć kluczowych zmiennych wpływających na nasz problem. Stąd faza measure w tym właśnie miejscu wymaga tak dużo uwagi. W sytuacji, w której wciąż liczba zmiennych jest na tyle duża, że przekracza nasze możliwości pomiaru, nie warto subiektywnie rezygnować z tych które ‚wydają nam się’ mniej istotne, zamiast tego sugeruję zawsze użycie oceny ekspertów.

Jeżeli udało nam się uzyskać listę zmiennych do pomiaru, zmiennych z którymi zgadza się grupa pracowników biorących udział w ćwiczeniu, następnym krokiem w naszym projekcie DMAIC będzie przygotowanie planu zbierania danych, dla zmiennych, które zdecydowaliśmy się mierzyć.

O tym już w następnym artykule. Zapraszam! 🙂

 

Efektywny projekt DMAIC z wykorzystaniem Trello.

Praca lidera projektu jest wymagająca. Komunikacja, koordynowanie działań, motywowanie, rozliczanie, delegowanie, monitorowanie… Aby zarządzać projektem efektywnie, warto wykorzystać dobre narzędzia. Co to znaczy dobre? Między innymi intuicyjne, łatwe w obsłudze, umożliwiające bezproblemową komunikację z zespołem projektowym oraz interesariuszami naszego projektu, najlepiej w wersji na komputer, tablet no i komórkę. Tak, żeby można było pracować w trasie, w przerwie, no i żeby dokumentacja projektu nie zajmowała czasu, który możemy poświęcić na analizy, rozmowę z ludźmi, dochodzenie prawdy czy wdrażanie rozwiązań.

Można to wszystko zrobić kilkoma narzędziami. Do zarządzani projektem wykorzystamy MS Project, do budżetowania excela przechowywanego w katalogu pt.’finanse’, sama zaś dokumentacja projektu, gdy już będzie gotowa, zajmie kilka megabajtów prezentacji power point. Stworzona w trudach i wiecznym niedoczasie z narzekaniem – dlaczego siedzę nad slajdami gdy powinienem iść dalej i usprawniać, usprawniać… Jestem przecież Black Beltem!

Jest na to rozwiązanie, które sam wykorzystuję i chciałbym się nim z Wami podzielić. Narzędzie to nazywa się Trello i dużo zostało już o nim napisanych artykułów, ale ja konkretnie chcę pokazać jak możesz to wykorzystac do projektu DMAIC. No to start.

Wchodzimy na Trello.com i możemy się zarejestrować, to nic nie kosztuje (płatna jest dopiero opcja biznes class). Podstawowy widok od którego zaczyna się nasza przygoda to Boards, czyli tablice. Możemy zakładać tablice, które będą pojedynczymi projektami lub będą pełniły rolę portfela projektów, czy programu – zależy jaki poziom szczegółowości zadań jest nam potrzebny w naszych przedsięwzięciach, ale o tym za chwilę. Nie będę opisywał wszystkich funkcjonalności, nie taki jest cel tego posta, chcę pokazać, które z funkcjonalności mogą przydać się aby przeprowadzić projekt DMAIC. Tak wygląda nasz projekt DMAIC.

Dodatkowo do naszego projektu DMAIC, do każdego kroku dodałem narzędzia, które znalazłem w sieci. Te narzędzia mogą okazać się przydatne w trakcie realizacji projektu i możecie je dowolnie modyfikować. Nie są to narzędzia stworzone przeze mnie, ponieważ liczba darmowych opcji jest tak imponująca, że wolę się niektórymi z nich z Wami podzielić, niż Tworzyć je od początku. jak mawiał S.Jobs – kreatywność to łączenie kropek. Zatem jeżeli będziecie mieć komentarze do mojej propozycji, którą się dzielę  – piszcie śmiało. Może wspólnie stworzymy super narzędzie, z którego każdy będzie mógł korzystać. Tymczasem poniżej pokazano, jak zobaczyć czy w danym kroku jest załącznik.

Jeżeli klikniesz na poniższy link, zostaniesz przekierowany do tablicy publicznej projektu DMAIC, który stworzyłem jako template, który możesz wykorzystywać do swoich projektów: https://trello.com/b/xqeBPRgL/projekt-dmaic-public-template

Wchodząc w dalszej kolejności na swoje konto w Trello, możesz skopiować mój cały projekt, czyli mój board. jak to zrobić? Wejdź w menu, następnie w more, a potem w  ‚copy board’ i gotowe. Wpisujesz nazwę swojego projektu (boardu) i wybierasz zespół, do którego chcesz przypisać tę tablicę. Możesz utworzyć dowolną ilość zespołów składającą się z Twoich współpracowników dodając po prostu ich adresy e-mail. Muszą mieć również dostęp do Trello, a dzięki temu będziesz mógł komunikować się z nimi i w czasie rzeczywistym rozdzielać zadania, dodawać komentarze, itd.

Jak już będziesz mieć gotowy swój projekt, jakkolwiek go nazwiesz, możesz do każdego z kroków w danej fazie dodawać szczegółowe czynności (tzw. checklisty w poszczególnych krokach, czyli kartach). Zauważmy, że Trello do prowadzenia naszych projektów oferuje następującą hierarchię:
tablica (projekt) -> lista (fazy) -> karta (czynność) -> checklista (zadania)
Najmniejszym elementem naszego projektu jest karta, która umożliwia dodawania checklist z zadaniami. Poprzez odkreślanie zadań jako ‚done’ uzyskuje się na widoku projektu liczbę wypełnionych zadań w odniesieniu do wszystkich (np.8/10). Jeżeli dodatkowo ustawisz deadline na konkretne zadanie, w sytuacji przekroczenia zapali się na czerwono i będzie to widoczne z poziomu projektu.

Teraz możesz zacząć odkrywać moc tego narzędzia. Trello oferuje tzw. power-ups, które są dodatkowymi funkcjonalnościami, zwiększającymi efektywność naszych działań. Może to być Slack do komunikacji z zespołem, dysk Gmail do przechowywania plików czy inne, równie ciekawe rozwiązania. W darmowej wersji Trello 1 power-up jest za darmo na 1 tablicę (czyli 1 projekt).

Osobiście prowadząc projekt DMAIC korzystam z kilku dodatków. Oto najważniesze z nich.
1. Elegannt pozwala mi ustawiać datę start i stop mojej aktywności oraz zachować odpowiednią kolejność czynności. Lepszy niż robienie harmonogramów w Excelu i bardziej elastyczny (moim zdaniaem) niż MsProject. Jak zainstalować? Wpisz w google elegannt for Trello i zaraz znajdziesz ten dodatek. Po prostu zainstaluj, jest darmowy.
2. Dodatkowo mierzę czas spędzony na poszczególnych zadaniach z wykorzystaniem narzędzia Tmetric (wpisz tmetric for Trello w google), który zlicza czasy per zadania (działa na zasadzie start-stop). Nie jest to dodatek power-up, jest niezależnym narzędziem, a żeby go sobie zainstalować trzeba pracować na Chrome. Dzięki Tmetric możesz mierzyć czasy nie tylko w trello (jest to nakładka na Chrome), zatem możesz go wykorzystać do ogólnie pojętego pomiaru efektywności.
3. Burn-chart to typowy power-up w Trello, który pozwala mieć kontrolę nad kosztami w projekcie. Jeżeli chcesz uniknąć exceli, aby kontrolować swoje wydatki, nie ma nic lepszego.
4. Google-drive pozwala na dostęp do wszystkich plików i folderów projektowych bezpośrednio z Twojego projektu. Chcesz mieć kontrolę nad bezpieczeństwem informacji i stworzyć efektywny sposób przechowywania informacji, to może być opcja.
5.Slack – komunikator który pozwala na temat bieżących spraw projektowych rozmawiać z naszymi zespołami, nie czekając na feedback odnośnie naszych komentarzy zwołać spotkanie i zaangażować w nie wszystkich zainteresowanych.

To tak pokrótce, bo narzędzi jest wiele i każdy może znaleźć coś dla siebie. Tak jak wspominałem jednorazowo w wersji darmowej Trello można mieć jedno narzędzie na projekt, więc są spore możliwości aby wypróbować które z nich się nam przyda. Tutaj trzeba poszperać i popróbować samemu. Może coś ciekawego jeszcze uda się znaleźć? Na pewno tak (!)

 

 

 

 

 

 

 

Zarządzanie projektem 6 Sigma. Faza Measure krok 1. Opracowanie szczegółowej mapy procesu

Po zatwierdzeniu karty projektu przez zespól, interesariuszy oraz sponsora projektu, lider może przystąpić do dalszych prac projektowych. Wchodzimy zatem do fazy Measure, której głównym zadaniem jest zebranie informacji co do tego, jak wygląda nasz proces. Chodzi o liczby, dane i fakty – te które mamy w systemach, a także te, które dopiero będziemy zbierać, bo w fazie Measure opracowujemy statystyczny obraz procesu. Innymi słowy chcemy nasz problem, naszego Y’ka opisać za pomocą zmiennych (czyli x’ów), które naszym zdaniem na niego wpływają. Zaczynamy zatem budować funkcję matematyczną, która przyjmuje postać:
Y = f(x1,x2,x3,x4,…..,xn).
To czy zmienne x faktycznie wpływają na Y i jaka jest ostatecznie postać tej funkcji, to okaże się w fazie Analyze. Na razie musimy zebrać dane, bo postępujemy metodycznie – oto siła DMAIC’a. Aby znaleźć miejsca w naszym procesie, w których coś może być nie tak i to zmierzyć warto w tym momencie przygotować szczegółową analizę procesu – czyli zmapować interesujący nas obszar. Pamiętamy bowiem o tym, że jeden obraz wart jest więcej niż tysiąc słów (stare chińskie przysłowie) oraz o tym, że zmapowany przez nas proces będzie dokumentem referencyjnym, do którego będziemy się odnosić, gdy będzie taka potrzeba.

Należy teraz podkreślić bardzo, ale to bardzo ważną rzecz, mianowicie aby dokonać szczegółowej analizy procesu nie powinniśmy korzystać z map, które są dostępne. W firmach, które posiadają certyfikację ISO bardzo często procesy są zmapowane i jako takie stanowią część systemu zarządzania jakością. Istnieje pokusa, by zaoszczędzić czas i zamiast spotykać się z zespołem wejść w nasz system BPM’owy, wydrukować mapę i w trakcie krótkiego spotkania z zespołem porozmawiać na temat tego, dlaczego proces nie działa. Źle, tak nie robimy. Nawet jeśli mamy rozwiązania serwerowe, zarządzanie wersjonowaniem procesów i osoby odpowiedzialne za aktualizację – proces musi być zmapowany w stanie jakim jest teraz, a nie w jakim opisują go mapy czy takim, jaki chcielibyśmy żeby był. Oznacza to, że idziemy do GEMBA, czyli tam gdzie wykonywany jest nasz proces (open space, hala produkcyjna, itd.) , a następnie z osobami, które ten proces wykonują (operatorzy, księgowi, specjaliści dziedzinowi, jakościowcy, itd.) omawiamy dokładnie każdy krok i rysujemy – na tablicy, na karteczkach, magic chart’ach… Nie jest tak ważna technika jak to, aby uzyskać obraz obecnego procesu, z którym zgadzają się wszystkie osoby wykonujące ten proces.

Ponieważ są różne rodzaje map procesów, nasuwa się pytanie: „jakie mapowanie zastosować”? To zależy od tego, z jakim problemem mamy do czynienia. Zatem w zależności od rodzaju problemu, do przygotowania mapy procesu w którym ten problem występuje, stosujemy adekwatne podejście. I tak oto.

1. Jeżeli nasz proces jest niestabilny, tym samym można podejrzewać, że prawdopodobnie pewne zmienne (lub charakterystyki/właściwości) oddziałują w nieprzewidywalny sposób na naszego Y’ka – najlepiej zastosować flowchart (schemat blokowy), który rozbija proces na najmniejsze czynności lub operacje i pomoże nam wskazać miejsce potencjalnego problemu.

2. Z kolei w sytuacji gdy nasz proces trwa zbyt długo, a to wpływa z kolei na niezadowolenie klienta i naszym celem jest skrócenie czasu procesu (tzw. lead time), w rezultacie musimy zdefiniować a potem wyeliminować marnotrawstwa, zatem zaczynamy nasze mapowanie od stworzenia mapy strumienia wartości (VSM), dla konkretnego procesu/produktu/klienta. Mapa strumienia wartości różni się istotnie od schematu blokowego, przede wszystkim tym, że jest mapą głownych kroków/etapów procesu a nie mapą detaliczną, a dodatkowo musi być przygotowana dla konkretnego rodzaju produktu/usługi i klienta, podczas gdy flowchart jest tutaj uniwersalny. Poniżej przykładowa mapa VSM dla procesów usługowych, tzw. Makigami, zawiera zidentyfikowane marnostrawstwa, linię czasu pomagająca w ocenie lead time procesu oraz tabelkę z podsumowanie min. i max czasów przestojów i czynności.

3. W dalszej kolejności możemy przygotować tzw. diagram spaghetti, jeżeli mamy do czynienia z marnotrawstwem transportu i/lub ruchu. W przykładzie poniżej widzimy, jak przemieszczają się pracownicy SSC, którzy chcą wydrukować dokument. Pomarańczowe linie wskazują przebieg ścieżek komunikacji, wskazujący na – w tym przypadku – złe rozplanowanie kluczowych dla stanowisk pracy pomieszczeń (drukarnia, archiwum). W tym przypadku jest to biuro, ale można wyobrazić sobie magazyn po którym poruszamy się w poszukiwaniu narzędzi czy jeździmy wózkiem widłowym aby przywozić i odwozić towary i komponenty.

Powyższe metody mapowania procesów umożliwiają nam stworzenie obrazu procesu, który w dalszej kolejności będziemy analizować, aby znaleźć potencjalne zmienne wpływające na problem (x’y wpływające na Y’ka), a następnie zebrać do nich dane w celu przetworzenia i dalszej analizy (opracowanie obrazu procesu w fazie measure i dalej listy przyczyn źródłowych w fazie analyze). O przygodzie związanej z poszukiwaniem zmiennych, o tym jak przekonać się czy coś jest ważne a coś innego nie, o tym jak nie zapomnieć o czymś być może najistotniejszym – o tym wszystkim już w następnym odcinku mojego bloga. Zapraszam 😉

Post Scriptum.
1. Podstawowa książka dla każdego kto chce nauczyć się widzieć marnotrawstwa to Naucz się widzieć autorstwa M.Rother i J.Shook
2. O diagramach spaghetti więcej można przeczytać w książce Lean w biurze i usługach autorstwa D.Locher
3. Wprowadznie do mapowania procesów i języka BPMN można znaleźć w pozycji Zrozumieć BPMN autorstwa Sz.Drejewicz

Zarządzanie projektem 6 Sigma. Faza Define krok 4. Akceptacja karty projektu i kick-off

Za nami analiza problemu, definiowanie procesu w którym będziemy realizować projekt oraz określenie głosu klienta. Wiemy zatem co boli naszą firmę i w którym miejscu, a teraz trzeba porozmawiać o tym ze sponsorem i uzgodnić plan działania. Z zebranymi informacjami udajemy się do sponsora i przedstawiamy swoje potrzeby dotyczące działań projektowych. Wspólnie ze sponsorem ustalamy kto pomoże nam w projekcie – kto wejdzieDefine_krok4 w skład naszego zespołu projektowego, a kto będzie wspierał nas swoją wiedzą i doświadczeniem tylko od czasu do czasu, w zależności od potrzeb. Czyli rozróżniamy zespół zarządzający projektem od zasobów projektowych. Otrzymana zgoda na zaangażowanie zasobów pozwala nam przejść dalej, przedstawiamy harmonogram działań oraz planujemy ryzyka i działania na linii projekt-interesariusze. Sponsor jest osobą, która w większości przypadków jest nam w stanie pomóc w tych zadaniach. Tym samym czeka nas przygotowanie analizy ryzyk oraz analiza interesariuszy. To bardzo ważne by w nasz projekt zaangażować od samego początku osoby, które moga mieć wpływ na projekt w dalszych etapach – chcemy uniknąć sytuacji w której ze względu na brak poinformowania o pracach projektowych w fazie Improve nie dostaniemy zgody na wdrożenie naszych rozwiązań. Aby zaangażować niezbędnych interesariuszy jak również powiadomić organizację o naszych działaniach projektowych należy przeprowadzić kick-off, w trakcie którego wspólnie przejdziemy przez kartę projektu. Będzie to dobry moment aby rozwiać ewentualne wątpliwosci jak również uzyskać potwierdzenie zaangażowania poprzez akceptację karty projektu. Przykladowa karta projektu Six Sigma znajduje się poniżej i stanowi swoistą checklistę do fazy define. Dopiero gdy karta jest wypełniona w całości możemy zrobić kick-off i przejść do następnej  fazy – Measure.

karta projektu

 Przedstawiona tutaj karta jest najczęściej stosowaną przeze mnie w projektach usprawnieniowych. Lubię ja za prostotę i polecam innym bo zawiera podstawowe informacje niezbędne do uruchomienia projektu, jak również służy jako referencja w dalszych etapach – odwołujemy się do niej w trakcie całego projektu. Z jakich obszarów się składa? Możemy rozpocząć omawianie karty od informacji, które już mamy, a które należy w naszej karcie projektu uzupełnić. Sa to informacje kluczowe dla każdego projektu, a zaliczamy do nich: definicję problemu, który będziemy w projekcie rozwiązywać (jak definiowaliśmy problem zobacz DMAIC część 2), cel/cele projektu (DMAIC część 4) oraz proces, którego projekt dotyczy (DMAIC część 3). Cele naszego projektu, ich wartość obecna i ta, którą chcemy osiągnąć stanowią miary/charakterystyki naszego projektu i z nich zespół projektowy będzie rozliczany. Pochodzą one wprost od klienta i GB/BB musi mieć je cały czas na uwadze, projekt bowiem realizujemy przede wszystkim dla klienta. Problem, cele i zakres stanowią bazę naszych prac projektowych i wyznaczają obszar naszego działania.

Po określeniu kluczowych obszarów warto skutecznie nazwać nasz projekt. Skutecznie czyli umieścić informację w sposób budzący ciekawość pracowników naszej firmy tak, by chcieli dopytać się jaki jest jego cel i być może tym samym zaangażować się w działania projektowe, co może być dla nas bardzo pomocne. Szczególnie w organizacjach gdzie lider projektu musi sam zbudować sobie grupę projektową jest to bardzo pomocne. Numer projektu jest z kolei indywidualnym identyfikatorem projektu w organizacji i zwykle nadaje go Champion lub właściciel koszyka projektów usprawnieniowych, jeżeli w firmie mamy sprawnie działający program (zobacz DMAIC część 2). Nie ma dwóch projektów o takim samym numerze. W dalszej kolejności data rozpoczęcia i zakończenia projektu (estymowane) a także informacje o liderze projektu oraz sponsorze (e-mail, numer telefonu, imię i nazwisko), tak by zawsze można było się z nimi łatwo skontaktować. Lider projektu zarządza zespołem projektowym, stąd w dalszej kolejności karta projektu zawiera informacje o zespole projektowym, który będzie zarządzał działaniami oraz o zasobach, które będą niezbędne – myślimy tutaj o zasobach materialnych, które trzeba zakupić lub wypożyczyć, jak np. oprogramowanie, whiteboard do mapowania procesu, pisaki, komputer, post-it notesy oraz niematerialnych – eksperci z naszej firmy, którzy będą wspierać nas w poszczególnych fazach. Wycena zasobów jest ważnym etapem projektu DMAIC pozwalającym na ocenę rzeczywistej stopy zwrotu z naszego projektu. Nic bowiem bardziej mylnego niż sformułowanie, że projekt przyniósł tylko oszczędności, a nie poniósł żadnych kosztów.

Gdy karta projektu jest wypełniona informacjami możemy zorganizować kick-off projektu aby przedstawić nasz projekt sponsorowi, zespołowi projektowemu oraz interesariuszom, aby zdobyć ich zaangażowanie. Może to być kluczowe w trakcie projektu – by zebrać dane w fazie measure, wdrożyć rozwiązania w fazie improve czy wykazać, że zmiany przyniosły rezultaty w fazie control. Interesariusze są potrzebni liderowi, który dzięki nim jest w stanie nie tylko przeprowadzić swoją zmianę w procesie ale przede wszystkim zaangażować organizację, by go wspierała. Dobrą praktyką jest podpisywanie karty projektu, w celu akceptacji warunków oraz uzgodnienia odpowiedzialności za konkretne rezultaty. W dzisiejszych czasach w rozproszonych zespołach może to być niewykonalne, aby spotkać się face-to-face, omówić cele projektu a następnie podpisać kartę. Zamiast tego mamy telekonferencję i akcpetację przez maila lub w workflow, tak też jest dobrze. Natomiast nie do przecenienia pozostaje wartość rzeczywistego podpisu i spotkania we wspólnym gronie, gdzie jesteśmy w stanie odpowiedzieć na każde pytanie i ustalić, że zgadzamy się na warunki współpracy. Okazuje się bowiem czasami, że dopiero przed złożeniem podpisu sponsor zapoznaje się dokładnie z zakresem prac i zaczyna być świadomy swojej roli…

Podsumowując rolę i znaczenie karty projektu w naszym projekcie DMAIC warto zwrócić uwagę na to, że:
1. nie ma projektu Six Sigma bez karty projektu (!) – no bo  w jaki sposób będziemy odnosić się do problemu, celów i zakresu projektu?
2. karta projektu jest kontraktem między liderem projektu oraz sponsorem – sponsor zgadza się dostarczyć liderowi zasobów do realizacji prac, zaś lider zobowiązuje się dostarczyć konkretnych rezultatów
3. karta projektu pełni rolę checklisty dla Green Belta/Black Belta – wskazuje co musi zostać wykonane w fazie define
4. karta projektu jest dokumentem referencyjnym, do którego wracamy w trakcie projektu aby walidować zakres projektu oraz odświeżać ustalone cele
5. last but not least – karta jest wizytówką projektu, którą wykorzystujemy aby komunikować w firmie, że realizujemy taki a taki projekt, unikając sytuacji w której ktoś zacznie realizować projekt o takim samym zakresie lub na tym samym procesie, przy podobnym problemie.

Po podpisaniu/zaakceptowaniu karty projektu przechodzimy od następnego etapu projektu Six Sigma, czyli do fazy measure, w której to będziemy chcieli zebrać wszelkie liczby, dane i fakty i opracować statystyczny obraz procesu, w którym występuje problem. Innymi słowy będziemy chcieli zidentyfikować potencjalne zmienne (x) które wpływają na nasz problem (Y) i zebrać dane, by w fazie analyze za pomocą analiz statystycznych dowieść powiązania (lub braku) pomiędzy nimi.

Post Scriptum.
1. Przykładowa karta projektu, która posłużyła mi do zbudowania własnej może zostać znaleziona w książce The Six Sigma Handbook, autorstwa T.Pyzdek, P.Keller
2. Dodatkowo w fazie define należy przeprowadzić planowanie: ryzyka, interesariuszy, budżetu oraz opracować harmonogram. Widzimy zatem, że jeżeli chodzi stricte o narzędzia zarządzania projektem to lider projektu six sigma powinien czerpać dobre praktyki z innych metodyk projektowych, np. PMBOK, jako że sam DMAIC takowych nie daje.

Zarządzanie projektem 6 Sigma. Faza Define krok 3. Określenie oczekiwań klienta

Jako pasjonat metodyki 6 Sigma i podejścia do zarządzania projektami usprawnieniowymi bazującego na DMAIC, prowadząc szkolenia i rozmawiając z różnymi osobami w trakcie konferencji (których nota bene ostatnimi czasy jest coraz więcej) staram się przekonać rozmówców, że ten program – jeśli wdrożony z głową – może przynieść firmie wspaniałe rezultaty. Często w trakcie takiej wymiany poglądów dochodzi do odwołania się do firmy, w której 6 sigma się narodziła, a chodzi o Motorolę. W 1985 Motorola wdrożyła program 6 sigma, jako panaceum na problem jakościowe swoich produktów, by w rok później otrzymać Amerykańską Nagrodę Jakości im. Baldrige’a (Malcolm Baldrige National Quality Award). To co znamy z programów 6 sigma czyli DMAIC, różne kolory beltów, masterów (czyli program certyfikacyjne) wykuwało się właśnie tam. Po Motoroli w Stanach Zjednoczonych program 6 sigma stał się na tyle popularny, że wdrożyły go takie firmy jak General Electric, Allied Signal czy Kodak. Nawet US Army szczyciło się jeszcze kilka lat temu osiągnięciami z wdrożonego program ciągłego doskonalenia bazującego na 6 Sigma (co prawda z domieszką Lean a więc Lean 6 Sigma).

Warto zatem zapytać, czy ten program jest naprawdę tak dobry, skoro obecnie ani Motorola ani Kodak nie są liderami swoich rynków, a wręcz bezpowrotnie z nich zniknęły. O co zatem chodzi? Dlaczego ciągle słyszymy, że ten program może być panaceum na problem organizacji, a firmy które go zastosowały – w długim okresie czasu wyszły na tym źle? Tutaj dochodzimy do sedna. Wśród firm, które wdrożyły ten program są takie, którym sie udało jak i takie, którym się nie udało. Sam program to nie wszystko – liczy się bowiem najbardziej istotna i fundamentalna ze wszystkich kwestia – strategia. Jeżeli firma nie ma jasnej strategii działania, to niestety jej się nie uda. Nie chodzi bowiem o pogoń za idealnym produktem, takim który będzie spełniał najsurowsze wymagania jakościowe, ale chodzi przede wszystkim o to, żeby spełniać oczekiwania klienta. Czasy się zmieniają, nowe technologie wprowadzają nowe możliwości (smartfony, technologia cyfrowej obróbki zdjęć, itd.) i jeżeli nasza strategia nie nadążam za tymi zmianami, niestety żaden program nam nie pomoże.

Define_krok3Zatem kluczowym pytaniem, które organizacja powinna sobie ciągle zadawać by aktualizować swoją strategię jest: ‚czego oczekuje od nas klient’? Podobnie rzecz się ma w programie 6 sigma – realizujemy projekty usprawnieniowe, których celem jest satysfakcja klienta. O kliencie nie możemy zapomnieć w naszym projekcie, bo projekt realizujemy właśnie dla NIEGO. To właśnie dlatego zaraz po wstępnej analizie procesu (patrz część 3 naszego cyklu) przechodzimy do oczekiwań klienta naszego procesu, który chcemy usprawnić. Chcemy bowiem dowiedzieć się od klienta, jakie problem sprawia mu process i co powinniśmy usprawnić, aby był zadowolony.

W rozbudowanej analizie potrzeb klienta może nam pomóc model Kano (autor: Noriaki Kano), natomiast do podstawowej analizy możemy wykorzystać podejście CTC-CTQ (Critical to Customer – Critical to Quality). CTQ pomaga przełożyć często enigmatycznie wyrażone ‚chciejstwa’ (chciałbym bardziej czerwony, liczę na lepiej, szybciej, taniej) lub ‚niechciejstwa’ (nie chcę takiego smaku) na konkretne miary, charakterystyki czy wręcz specyfikację procesu. Jeżeli mamy coś osiągnąć – dobrze by było wiedzieć co, a w tym właśnie pomoże nam CTQ. Gdyby pokusić się o jednozdaniową definicję tej metody, wyglądałaby pewnie tak: ‚CTQ to przejście od wyrażonych w sposób ogólny oczekiwań klienta, do parametrów procesu, które musimy uzyskać, aby te oczekiwania spełnić’. Innymi słowy jest to przejście od potrzeby 1wszego poziomu (CTC) do potrzeby 3ciego lub 4tego poziomu (CTQ). W zależności od tego jak bardzo złożone oczekiwanie klienta – dotyczące produktu lub usługi – jest, poziomów może być więcej lub mniej. Ich liczba nie jest stała.

Chciałbym posłużyć się teraz pewnym przykładem, który pomoże nam lepiej zrozumieć ideę CTQ. Chodzi mianowicie o projekt zrealizowany we Wrocławiu przy okazji Mistrzostw Europy w piłce nożnej Polska-Ukraina w 2012 roku, a konkretnie o odnowienie dworca głównego PKP. Jak wiemy właśnie wtedy zmienił swój kolor na – jak to niektórzy obserwatorzy podsumowują – wściekło pomarańczowy, zaś według osób biorących udział w renowacji uznawany jest za pierwotny (po dokonaniu ponad 300 odkrywek), a nazywa się fachowo pomarańczowy ugier.

dworzec pkp wroclaw2

Zainspirowała mnie sytuacja, której byłem uczestnikiem na przystanku autobusowym w pobliżu dworca PKP właśnie. Pasażerowie dyskutowali na temat jednej ze ścian budynku, która co jakiś czas jest malowana na inny kolor. Raz to piaskowy, raz pomarańczowy, innym zaś razem żółty albo szary. Oczekujący ubolewali (eufemizm) nad tym, że pewnie to drogie, sporo kosztuje i zastanawiali się, dlaczego PKP jako zarządca nie może się w końcu zdecydować na konkretny kolor. Byłoby lepiej dla wszystkich bo to nasze podatki przecież, itd… Historia ma drugie dno. Budynek dworca by zostać odnowiony musiał pogodzić interesy kilku zaangażowanych stron, między innymi sponsora, głównego architekta, konserwatora zabytków czy zarządcy obiektu. Nie w sposób przypadkowy zarządca obiektu znalazł się na samym końcu – nie mógł podjąć decyzji co do koloru samodzielnie, miał odnowić budynek zgodnie z zaleceniami architekta i konserwatora. Dlatego też ściana budynku tak wiele razy zmieniała kolor, co wychwycili pasażerowie autobusów – trzeba było dobrze ten kolor dobrać, a przecież przed wojną nie było kolorowych zdjęć, zatem dopuszczono się pewnego eksperymentu: malowano ścianę i sprawdzano, czy spełnia określone wymagania. I tak raz za razem.

W naszym języku powiedzielibyśmy, że przechodzono od oczekiwań klienta (konserwator) do konkretnego parametru, charakterystki, a zatem od potrzeby ogólne do specyfikacji. Poprzez analyze wielu kolorów, która się dokonała, klient w tym przypadku konserwator, mógł w końcu wybrać ten najbardziej odpowiedni, a zatem przeszedł z poziomu potrzeby ogólnej – odmalowanego dworca – do poziomu specyfikacji – dworca odmalowanego farbą o konkretnym numerze NCS S2050-Y30R.

CTC-CTQ

I tak właśnie powinno postępować się za każdym razem, gdy chcemy dokładnie dowiedzieć się jakie są oczekiwania klienta – pytać do skutku aż otrzymamy konkretną informację. Szybki samochód – ile km/h to jest szybko? Ładny czerwony? Proszę pokazać palcem na palecie barw albo jeszcze lepiej w salonie, i na zewnątrz i przy zapalonych światłach…

W projektach 6 sigma ma to jeszcze dodatkowy wymiar – może okazać się, że klient poprzez takie ćwiczenie z nami procesowcami dojdzie do wniosku, że wcale nie potrzebuje spełnienia tak restrykcyjnych warunków dotyczących parametrów jakościowych produkty czy usługi. A nam wydawało się, że nie spełniamy jego oczekiwań (?) Teraz skoro już wiemy, że jest inaczej – może nie trzeba będzie usprawniać procesu, który de facto dostarcza to czego oczekuje klient (tak naprawdę klient był zadowolony tylko my sami stworzyliśmy sztucznie ten problem poprzez nieznajomość jego oczekiwań) tylko zmienić limity specyfikacji. Może nam to niejednokrotnie oszczędzić zbędnej pracy i spowodować, że zaczniemy spełniać rzeczywiste oczekiwania klienta, a nie te które nam się nimi wydają, a to wszystko bez konieczności przeprowadzenia projektu DMAIC (!). Jesteśmy co prawda GB i BB, ale zawsze powinniśmy brać pod uwagę zasoby firm w których pracujemy i nie angażować ich jeśli nie ma takiej potrzeby. Jeżeli mówimy o zasobach, to ich kwestia zostanie poruszona już w następnym artykule naszego cyklu dotyczącym karty projektu i spotkania otwierającego projekt, tzw. kick-off meeting. Już teraz zapraszam 🙂

Post Scriptum.
Historia dotycząca renowacji dworca, a konkretnie jego kolorytu jest opisana szczególowo tutaj:
http://www.gazetawroclawska.pl/artykul/394487,pomaranczowy-ugier-taki-bedzie-kolor-dworca-glownego-pkp,id,t.html

Zarządzanie projektem 6 Sigma. Faza Define krok 2. Wstępna analiza procesu

Define_krok2W ostanim odcinku naszego cyklu artykułów wybieraliśmy problem, który chcemy rozwiązać z wykorzystaniem metodyki DMAIC. Gdy mamy już wybrany problem, którym chcemy zająć się w naszym projekcie (tzw. project Y ‚why’) i mamy już wybrany proces, którego ten problem dotyczy, to przychodzi czas na wstępna analizę procesu. Kluczowym słowem jest tutaj ‚wstępna’ ponieważ w fazie Define dopiero rozpoczynamy analizować nasz proces. Musimy zobaczyć jak wygląda proces na ogólnym poziomie, aby następnie przeanalizować dostępne dane i przekonać się, w którym miejscu (kroku) naszego procesu mamy największe problemy. Zatem rezultatem wstępnej analizy procesu będzie ogólny obraz procesu wraz z najważniejszymi krokami oraz danymi opisującymi te kroki biorąc pod uwagę naturę naszego problemu.

Do stworzenia ogólnego obrazu procesu najlepiej wykorzystać narzędzie SIPOC (Supplier-Input_Process-Outpu-Customer) którego zaletą jest to, że na jednej kartce papieru, na jednej tablicy czy jednym slajdzie jesteśmy w stanie opisać nasz proces. I to nie tylko główne kroki, ale też wejścia i wyjścia oraz dostawców i odbiorców. Ktoś może zapytać, dlaczego w tym momencie nie zacząć od szczegółowej mapy procesu, która jest w naszej księdze jakości, w naszym korporacyjnym systemie (mamy zmapowane wszystkie procesy w takich narzędziach jak Aris) itd. To dlatego, że my chcemy zobaczyć ogólny obraz procesu a nie szczegółowy, to po pierwsze. Po drugie w projekcie DMAIC nie wykorzystujemy już gotowych map procesów, gotowych analiz, gotowych scenariuszy – wszystko musimy wypracować sami. Dlaczego? Dlatego, że gdyby proces działał zgodnie z tym jak jest opisany, to nie byłoby problemu. A nie działa, prawda? Oznacza to, że to co mamy zmapowane albo nie jest wykorzystywane przez pracowników, albo jest mocno zdezaktualizowane. I dlatego proces przysparza nam problemów.

pareto2W drugiej kolejności poprzez analizę dostępnych danych staramy się dowiedzieć, który z etapów procesu jest dla nas kluczowy czyt. problematyczny. Jeżeli naszym problemem jest lead time procesu to będziemy szukać danych dotyczących czasu trwania poszczególnych kroków, a gdy naszym problemem jest odpad powstający w trakcie procesu produkcyjnego, to będziemy chcieli dowiedzieć się, w którym miejscu tego procesu najwięcej odpadu powstaje. Jest to nic innego jak zawężanie naszego obszaru poszukiwania, które ma na celu skierowanie całej naszej mocy poznawczej na krytyczne kroki. Popularnym narzędziem, które możemy wykorzystać w celu analizy dostępnych danych na tym etapie jest diagram Pareto-Lorenza, który wraz z ogólnym obrazem procesu wskaże nam dokładnie, którym obszarem procesu powinniśmy się zająć i dlaczego.

Gdyby ktoś zastanawiał się nad tym, dlaczego bazujemy póki co na ogólnym obrazie procesu to skłania nas do tego przede wszystkim to, że nie mamy jeszcze tak naprawdę formalnej zgody na zaangażowanie zespołu projektowego i/lub zasobów. To pojawia się dopiero w ostatnim kroku fazy Define w trakcie spotkanie otwierającego projekt, tzw. kick-off meeting’u (spotkania otwierającego projekt). Nie mamy jeszcze zespołu projektowego, chociaż możemy już podpytywać sponsora o to, kogo i na ile czasu możemy zaangażować. To działanie, którego podejmuje się GB/BB możemy nazwać wstępnym omawianiem warunków projektu. Lider projektu musi przecież wiedzieć, czy może zaangażować pracowników nawet na bardzo krótką chwilę (np.30 minut), ponieważ zwykle są to pracownicy nie podlegający bezpośrednio GB/BB. Po drugie zaś chodzi przede wszystkim o efektywność naszych działań – stworzenie ogólnego obrazu procesu zajmie nam 1h, natomiast zmapowanie całego procesu zgodnie ze sztuką BPMN może nam zająć 2 dni. Nie chcemy marnować kilkunastu godzin, jeśli ostatecznie okazuje się, że będzie nas interesował tylko wycinek. Prawda? Może DMAIC jest rozwiązaniem Six Sigma, ale nie wykluczajmy użycia podejścia Lean, gdy to niezbędne.

Zatem wiemy już, jaki zakres procesu będzie naszym obszarem działania w projekcie, teraz należy znaleźć odpowiedź na pytanie: ‚czego oczekuje klient’?. W firmach mamy do czynienia z różnymi rodzajami klientów – jedni są klientami zewnętrznymi, inni są klientami wewnętrznymi, czasem nasz sponsor projektu jest jednocześnie naszym klientem, itd. GB/BB musi zorientować się. kto za projekt płaci, a kto wymaga i konkretnie czego? Innymi słowy – jakie parametry naszego procesu spowodują, że klient będzie zadowolony z naszego usprawnienia? Jak do tego dojść zostawmy na następny odcinek naszej serii w którym będziemy chcieli określić wymagania klienta. Zapraszam 🙂

Post Scriptum.
1. Idea Pareto w codziennym życiu jest bardzo ciekawie opisana w książce pt.’Jedna rzecz’. W tej pozycji G.Keller i J.Papasan opisują, jak ważne jest odpowiednie zarządzanie priorytetami i skupianie się na rzeczach najważniejszych – innymi słowy wybór kluczowych 20% które powodują 80% rezultatów.
2.Ciekawostka – ponowie o zasadzie Pareto. Sama zasada została sformułowana nie jak można by przypuszczać przez Vilfredo Pareto, lecz w 1951 roku przez Josepha Jurana w książce Quality Control Handbook. Opisywał ją Juran jako zasadę analizy „kluczowych nielicznych i błahych licznych”. Juran powoływał się na prace Pareta i nazwał zasadę 80/20 jego nazwiskiem…

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.

define_wybor problemuWybó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.

funnel_ideas

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.

statystyka_6sigma_2Drugim 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.

d1e898a164c8Po 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żą.

its all OKPowyż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! 🙂

Post Scriptum.
1.Sam wybór problemu jego opisanie jak i budowanie portfela projektów możemy znaleźć w książce The Six Sigma Handbook, autorstwa T.Pyzdek, P.Keller
2. w naszej publikacji powoływaliśmy się również na portal www.isixsigma.com, na którym to w grupie zrzeszającej praktyków Six Sigma przeprowadziłem załączoną ankietę nawiązującą do zaangażowania najwyższego kierownictwa we wsparcie projektu

Zarządzanie projektem 6 Sigma. Wprowadzenie do DMAIC

W pierwszym odcinku naszej serii publikacji o tym jak zarządzać projektem 6 sigma postanowiłem nie zaczynać od tego, co to jest 6 sigma
i dlaczego właśnie 6 i dlaczego sigma, co to oznacza oraz że powstało w USA a dokładniej to w Motoroli. Myślę że całkiem dużo informacji na ten temat znajduje się w Wiki, a ja zamiast tego przechodzę do sedna – trochę w stylu „na początku musi być trzęsienie ziemii, a potem napięcie będzie wzrastać”. No to zaczynamy.

Z dimejkiem (DMAIC) jest jak z tym dowcipem: „przychodzi baba do lekarza i mówi że ją boli, tylko nie wiadomo gdzie”. No to doktor musi zbadać, zebrać informacje, zrobić wywiad, a tak w ogóle powinien zacząć od tego, że dowie się o co tak naprawdę pacjentce chodzi… Projekty Six Sigma mają to do siebie, że wyglądają trochę jak taka wizyta u lekarza. Jak jest to zły lekarz to i projekt jest kiepski, ale jak dobry – no to rezultaty też są zgodne z oczekiwaniami, albo nawet lepsze. Green Belt lub Black Belt, jako przedstawiciele infrastruktury Six Sigma w firmie pełnią rolę lekarza, z tą różnicą że nie badają ludzi (tego staramy się unikać, bo chcemy badać procesy) tylko skupiają się na procesach.

Gdyby zatem do doktora przyszła pacjentka, to co by doktor zrobił?

Krok 1. zapytałby „co pani doskwiera?” (że boli kolano, że jest gorączka, że nie mogę spać w nocy, itd.) czyli zdefiniowałby problem. Tym samym wykonuje pierwszy krok naszego dimejka – Define – definiowanie problemu. Załóżmy, że problemem jest temperatura – pacjentka ma na przykład 39 stopni vs. 36,8 uważanej za akceptowalny dla osoby dorosłej standard.16382-a-doctor-examining-a-female-patient-pv
Krok 2. znając problem lekarz przechodzi do wywiadu (jak na zdjęciu obok) by zebrać jak najwięcej informacji na temat możliwych przyczyn, zatem do fazy Measure. Lekarz będzie szukał odpowiedzi na pytanie – co może wywoływać tak wysoką temperature? Innymi słowy szuka zmiennych mogących mieć wpływ na gorączkę: „czy była Pani ostatnio chora, czy ktoś w rodzinie obecnie choruje, jak długo utrzymuje się temperature, jaki jest poziom przeciwciał we krwi” itd. W ten sposób dla lekarza powstaje karta choroby a dla Green/Black Belta statystyczny obraz procesu.
Krok 3. z zebranych informacji lekarz stara się wyciągnać wnioski, czyli weryfikuje które z przyczyn faktycznie mogą wpływać na temperature, a które nie mają żadnego znaczenia. Dokonuje tym samym weryfikacji pewnych hipotez, której rezultatem jest stworzenie listy przyczyn źródłowych na problem (gorączkę) wpływających.
Krok 4. mając pewność co do przyczyn źródłowych, wpływających na gorączkę, lekarz przepisuje leki, które mają na celu jej zbicie. Tym samym chodzi nam o powrót do stanu akceptowalnego (czyli temperatury 36,8). Jest do wprowadzenie pewnego rozwiązania (leczenia), a zatem jesteśmy w fazie Improve.
Krok 5. w trakcie przyjmowania leków dobrze jest obserwować zachowanie naszego organizmu i odnotowywać jego reakcje. Teraz chcemy upewnić się, że przepisane leki nam pomogą, innymi słowy że wdrożone rozwiązania przyniosą konkretne efekty. Do tego służy faza Control, czyli sterowanie zmianami (nie kontrola, a sterowanie). Dobry lekarz będzie chciał w tym kroku umówić się z nami na wizytę kontrolną, by upewnić się że „rozwiązanie” działa.

Powyższy przykład „medyczny” układa nam się w cykl DMAIC. Posiada też jedną znamienną charaktersytykę, która odróżnia problem „nadające się” do rozwiązania za pomocą 6 sigma od innych – są to problemy o nieznanej przyczynie i nieznanym rozwiązaniu (nie wiemy co pacjentce dolega). Tak właśnie. Wszelkie inne projekty bowiem czy inicjatywy, których celem jest wdrożenie konkretnego z góry znanego rozwiązania czy standardu nie wymagają używania DMAIC. Pytanie – czy można? Zastanówmy się – DMAIC to (jak pokazuje doświadczenie) projekt trwający najczęściej od 4 do 6 miesięcy, zatem czy warto? Łatwiej będzie nam przecież opracować plan instalacji nowej linii (do którego mamy dokumentacje) który będzie trwał miesiąc. Czy zatem DMAIC jest metodyką, którą stosujemy w przypadku problemów nękających naszą organizację, powracających jak zła zmora, na które nikt nigdy nie znalazł rozwiązania bo brakowało wiedzy, informacji, kwalifikacji? Właśnie tak. Pomóc ma w tym ustrukturyzowane podejście do rozwiązywania problemów, które dla czytelności możemy wyrazić poniższym rysunkiem:

DMAIC
W projekcie 6 sigma każda z faz składa się z sugerowanych działań/kroków, mających na celu przeprowadzenie konkretnego procesu wnioskowania. Poszczególne działania można potraktować jako sugerowane (tak zwane „good to have”) na drodze do zrealizowania projektu DMAIC. Dlaczego dobrze ich przestrzegać? Bo jeśli któryś z nich pominiemy możemy narazić się na szereg ryzyk np.: zebranie złych danych, pominięcie kluczowych oczekiwań klienta, błędne wnioski z analiz statystycznych, złe rozwiązanie na główny problem, wdrożenie rozwiązania, które nie rozwiązuje problemu (brak pilotażu), itd.

Wracając do DMAIC to jego niepodważalną zaletą jest to, że jest naszym zdaniem przede wszystkim zdroworozsądkowym podejściem do rozwiązywania problemów. Eliminuje przeskakiwanie od problemu do rozwiązania, z czym często borykamy się w naszych organizacjach. Podejmujemy decyzje bazując na niepełnych informacjach lub wręcz w ogóle ich nie analizując – bo albo ich nie mamy, albo nie uważamy tego za konieczne. Bo przez lata prowadzenia działalności wykształciliśmy podejście na zasadzie „jakoś to będzie” lub „tak nam się wydaje” i co najgorsze – jest nam z tym dobrze. DMAIC wychodzi temu naprzeciw i proponuje podejście bazujące w pełni na liczbach, faktach i zebranych danych, które analizujemy i podejmujemy decyzje bazując na konkretnych rezultatach naszych analiz.

To jednak co jest kluczowe w tym, żeby projekty DMAIC w firmie „hulały” to wsparcie, wsparcie i jeszcze raz zaangażowanie najwyższego kierownictwa. Poniżej przedstawiamy rezultaty ankiety, którą przeprowadziłem swego czasu na portal isixsigma.com, zrzeszającym praktykujących beltów wszystkich poziomów, co ich zdaniem jest kluczowe dla funkcjonowania programu 6 sigma w organizacji. Oto rezultat.

Bez tytułuJak widać na pierwszym miejscu wskazano jednogłośnie zaangażowanie kierownictwa, ale prócz zaangażowania najwyższego kierownictwa liczy się również panująca w organizacji atmosfera
i wewnętrzne regulacje, które:
1. stwarzają warunki do prowadzenia projektów – dostarczanie szkoleń, wsparcia kierowników i championa 6 sigma, zaangażowanie pracowników technicznych, możliwość pozyskiwania informacji finansowych, świadomość i wsparcie klientów
2. umożliwiają stworzenie koszyka projektów nadających się do tego aby zaangażować w ich prowadzenie zespół projektowy. Projekty które zostały wybrane przez Championa 6 sigma i zarząd jako kluczowe dla biznesu i które nie zostaną wstrzymane w wyniku chwilowych trudności z zasobami.

 

O ile warunki (pkt.1) pozostają póki co poza obszarem zainteresowania naszego cyklu artykułów – być może podejmiemy je jako osobny temat – to już wybór projektów jest kluczowy do powodzenia projektów DMAIC, ba – nawet całego programu 6 sigma.

Zatem – w jaki sposób dobrać projekty, które „nadają się” do zarządzenia z wykorzystaniem DMAIC? Jakie narzędzia wykorzystać? Jak krok po kroku doprowadzić do sign-off projektu DMAIC i co na niego przygotować?

O tym już w następnej publikacji, w której zajmiemy się szczegółowo fazą Define, w tym jej krokami a także narzędziami, które mogą pomóc
w jej przeprowadzeniu. Zapraszamy 🙂

Post Scriptum. Ponieważ celem naszego cyklu artykułów jest wyniesienie jak największej ilości wiedzy, każdorazowo będziemy dzielić się informacją na temat ciekawych książek dotyczących tematów, które właśnie omawiamy. Zatem:
1. dla osób chcących nabyć informacji co to jest DMAIC (jeżeli wciąż mało po naszej publikacji) polecamy książkę: What is Six Sigma? Autorzy: Pete Pande, Larry Holpp. 86 stron samych konkretów na temat wartości programu 6 sigma w organizacji oraz samego podejścia.
2. trochę więcej o samej kulturze 6 sigma, wsparciu kierownictwa, budowaniu programy w: Rewolucja Six Sigma, Autor: George Eckes.
3. w naszej publikacji powoływaliśmy się również na portal www.isixsigma.com, który dostarcza wielu przydatnych informacji – przykładów, przypadków, narzędzi oraz odwołań do publikacji – dla każdego belta jak i wszystkich osób chcących zmieniać pozytywnie rzeczywistość
w swoich firmach.

Od marca – cykl artykułów dotyczących zarządzania projektami według DMAIC.

Od marca na blogu rozpoczniemy publikowanie serii artykułów dotyczących zarządzania projektami z wykorzystaniem metodyki DMAIC.

Celem tych publikacji będzie stworzenie przewodnika dla wszystkich potencjalnych oraz obecnych Green Belts oraz Black Belts, jak również koordynatorów projektów usprawnieniowych. Będziemy odpowiadać na pytania dotyczące konkretnych narzędzi, zaserwujemy zdrową dawkę statystyki (jak to w Six Sigma) oraz podzielimy się własnymi doświadczeniami w zakresie prowadzenie projektów Six Sigma.

Chciemy, by nasze publikacje pomagały na codzień osobom, których zadaniem jest wprowadzanie zmiany w firmach. Mamy podejście mocno narzędziowe co oznacza, że każda faza DMAIC zostanie podzielona na kroki i w każdym z kroków będziemy omawiać konkretne narzędzia. Narzędzia, które można zastosować, a czasem wręcz trzeba oraz  jak te narzędzia zostały zastosowane na konkretnym przykładzie w projektach, które realizowaliśmy, wspieraliśmy czy nadzorowaliśmy jako Championi Black Belt.

Im więcej pytań tym lepiej, dlatego liczymy na zainteresowanie wszystkich, którym tematyka DMAIC nie jest obca.

Stwórzmy dzięki temu platformę wymiany doświadczeń. Pokażmy co warto robić, a czego należy unikać.

Zapraszamy w marcu! 🙂