Pracując nad liczbami w projekcie Six Sigma możecie natknąć się na problem jak na te dane spojrzeć. Z doświadczenia wiem, że generalnie można wyróżnić dwa podejścia do takiej analizy: płytkie i głębokie. Poniżej postaram się opisać oba przypadki.
Wyobraźmy sobie, że otrzymaliśmy na etapie DEFINE dane z procesu (z jednego miesiąca). Wcześniej w wywiadzie z właścicielem procesu/sponsorem uzyskaliśmy informacje, że proces ten powinien być realizowany w ciągu 5 dni (w 5 dniu powinna być zrobiona ostatnia sprawa) roboczych od otrzymania sprawy i że obecnie jest problem bo mamy dużo spraw po terminie. Jako kierownicy projektu musimy przekształcić to „dużo” w liczby, dane i fakty. Zacznijmy od analizy płytkiej. Postanowiliśmy przygotować wykres kołowy, który pokaże terminowość:
I co z tego można wyczytać ? Odpowiedź brzmi, że dokładnie tyle ile właściciel procesu/sponsor powiedział czyli, że „mamy duży problem”. Żadna głębsza analiza na tej podstawie nie jest możliwa, a na tym etapie często nie ma możliwości dłuższych obserwacji w GEMBIE (z jap. miejsce wykonywania pracy).
Z ratunkiem (o ile posiadamy odpowiednio przygotowane dane źródłowe) przychodzi nam w tym przypadku histogram. Histogram to graficzny sposób prezentacji rozkładu ustalonej cechy. Korzystając z takich samych danych jak do budowy wykresu kołowego przygotowujemy właśnie histogram:
W pionie (Frequency) widzimy ilość spraw, a w linii poziomej mamy kolejne dni w których sprawy są rozpatrywane (np. w dniu przyjścia sprawy czyli 0 rozpatrywanych jest ich 10). Przede wszystkich w oczy może się rzucać to, że większość spraw robiona jest w 10 dniu, czyli dwukrotnie przekroczony jest termin. Dodatkowo z histogramu wynika, że proces jest ułożony w taki sposób, że sprawy rozpatrywane są w 1,3 dniu, a później ilość rozpatrywanych spraw spada, aż do 10 dnia. Najmniej spraw realizowanych jest w 0 i 7 dniu. Zdarza się również, że sprawy są realizowane prawie po 3 miesiącach od ich przyjścia, a kilkanaście przypadków było obsłużonych powyżej miesiąca. Po zebraniu pierwszych ogólnych informacji z procesu na podstawie:
- rozmowy ze sponsorem,
- pogłębionej analizy danych,
- rozmowy z zespołem projektowym,
- budowy ogólnego obrazu procesu.
Kierownik projektu może przeprowadzać dalszą analizę, zadając dużo bardziej konkretne pytanie o system pracy, przebieg procesu, organizację stanowisk, przyczyny specjalne itp. Jak widać korzystając z tych samych danych, ale patrząc na nie w różny sposób, można osiągnąć diametralnie różne efekty. Dlatego też polecam proste narzędzia graficzne analizy danych na etapie DEFINE, gdyż budowanie wiedzy przy ich pomocy może pozwolić dużo szybciej osiągnąć zamierzony efekt.
PS. Dane pochodzą z rzeczywistego projektu i jestem bardzo ciekaw Waszych teorii na temat „Dlaczego sprawy rozpatrywane są w większości w 10-tym dniu skoro deadline w procesie to 5-ty dzień ?”. Swoje pomysły zostawcie we wpisach, a ja za kilka dni udzielę prawidłowej odpowiedzi (o ile taka nie padnie wcześniej).
Jerzy Łukomski
super artykuł, od razu inaczej patrzy się na takie dane, choć nie ma tu żadnych skomplikowanych wyliczeń. obraz o wiele bardziej przemawia do wyobraźni niż dane.
a odnośnie 10 dni. generalnie miałabym kilka pomysłów. np. dział, który zajmuje się sprawami ustalił, że poświęca na to co 2 tyg cały dzień a pozostałe dni rozkłada równomiernie między inne zajęcia.
Poobserwowałbym co tam się dzieje i porozmawiałbym z ludźmi. Myślę, że wiedza o tym co jest nie tak gdzieś tam się czai :). To może być zarówno błędne raportowanie np: „zrobiłem w terminie, ale zaraportowałem kilka dni później, bo czyścimy listę zadań dopiero jak nam przychodzi monit po 10 dniach”, może też być opóźnienie w dostarczeniu pracy – czyli robią w 5 dni, ale otrzymują już w piątym dniu. I wiele, wiele innych. Myślę, że nie obejdzie się bez wizyty w GEMBIE.
„może też być opóźnienie w dostarczeniu pracy – czyli robią w 5 dni, ale otrzymują już w piątym dniu.” – mógłbyś Marku wyjaśnić o co chodzi bo nie do końca rozumiem 😉 ?
Chodziło mi o to, że mamy 3 punkty obsługi sprawy:
A – dostarczenie do firmy
B – dostarczenie do badanego zespołu
C – zakończenie
Może liczony jest czas T1 = C – A i wynosi on 10 dni. Tymczasem analizowany zespół sam sobie liczy czas T2 = C – B, i mają 5 dni :). Dlatego trzymają „swoje” SL, a całościowo nie jest ono trzymane. Mam nadzieję, że wyjaśniłem 😉
To kwestia systemu kontroli postępu prac przez kierownika zespołu:) on na pewno ma ustawiony alarm na 9 dniu procesowanie, czyli tuż przed przekroczeniem dwukrotności czasu zadanego. I co? Bierze się za „motywowanie” ludzi, poprzez pofatygowanie się i dopytanie, „Czemu te sprawy jeszcze nie wyszły @#&&$^&Q$&&!!” po czym wychodzą dnie następnego:)
Dobrze?:)
Generalnie wyrabiają się w 10 dni. Ja bym zobaczył te dane w szeregu czasowym, być może gdzieś tam po drodze nastąpiło przedefiniowanie wskaźnika i mamy nałożenie danych „starych – do 10 dni, i nowych do 5 dni, i jakiejś resztówki z przypadkami odstającymi (szczególnymi). Jest jeszcze jedna możliwość – różne zespoły pracują w oparciu o różne definicje wskaźnika 🙂 jeden do 5 dni a drugi do 10 dni.
Greetings!
Parę dni minęło 😉 i chciałbym udzielić odpowiedzi na którą pewnie niecierpliwie czekacie. Otóż odpowiedź ta jest bardzo prozaiczna. W trakcie analizy z operatorami procesu okazało się, że nie wiedzą oni, że zgodnie z ustaleniami „na górze” mają realizować proces w 5 dni, co więcej kierownicy operacyjni jednostek też tego nie wiedzieli i byli święcie przekonani, że mają 10 dni 🙂 W związku z tym tak organizowali sobie pracę, żeby domykać sprawy , które się dało do 10 dnia (rozpoczynali pracę nad sprawą czasami dopiero 7 dnia), a sprawy załatwiane w ciągu 5 pierwszych dni to były jakieś konkretne typy łatwiejsze od innych, dlatego też realizowane były szybciej. Usprawnieniem wdrożonym w tym temacie było przekazanie informacji o istniejącym standardzie do poziomu operatora procesu i kierownika operacyjnego, który tym zarządza (zapasy mocy produkcyjnych w zespole istniały i wystarczyła niewielka reorganizacja).