Jak utrzymać dobrą dynamikę projektów usprawniających?

• Co to jest Kobetsu Kaizen?
• Pierwsze kroki z Six Sigma.
• Dlaczego DEFINE i CONTROL są tak ważne?
• Czy konieczne jest nazywanie projektu DMAIC „po imieniu”?
• Jak radzić sobie z niechęcią i oporem w zespole?
• Jak dbać o dynamikę projektów?
• Czego może nauczyć rozwiązywanie problemów?

Zobacz również: Jak dobrać miary i metryki do projektu DMAIC?

Dzień dobry. Ja się nazywam KamiL Torczewski, a to jest 32 odcinek podcastu Six Sigma Espresso, czyli o Six Sigma i Lean bez owijania w bawełnę. Krótko, konkretnie i na temat. Do dzisiejszej rozmowy zaprosiłem Pawła Szymańskiego – eksperta ds. doskonałości procesowej w dużej firmie produkcyjnej. Paweł to osoba, która posiada duże doświadczenie w obszarze usprawniania procesów różnymi metodami, bo i tymi związanymi z Six Sigma i tymi związanymi z Lean, i tymi prostszymi i tymi trudniejszymi. Oprócz tego, że Paweł sam zrealizował i przeprowadził z sukcesem wiele projektów, to ma duże doświadczenie w pracy z innymi liderami jako coach, jako trener i jako mentor. Tym bardziej dla mnie ta perspektywa jest bardzo interesująca. W dzisiejszej rozmowie zahaczyłem o myślę bardzo praktyczne wątki, bardzo przyziemne, związane z tym jak utrzymać dużą, dobrą dynamikę projektów usprawniających, jak radzić sobie z oporem przed zmianami, który zawsze się pojawia, mamy go gwarantowany, jak pozyskiwać koalicję do pracy w projektach DMAICowych czy innych. To są myślę bardzo ciekawe pytania w szczególności dla tych z Was, którzy sami prowadzą czy próbują prowadzić projekty usprawniające, np. zgodnie z metodyką DMAIC. Myślę, że w tym podcaście znajdziecie kilka wskazówek, a może nawet i odpowiedzi. Zachęcam do wysłuchania tej rozmowy. Przed Wami Paweł Szymański i ja, czyli KamiL Torczewski.

KamiL: To co Paweł, startujemy?

Paweł: Jak najbardziej.

KamiL: To cześć Paweł, dzień dobry. Bardzo się cieszę, że jesteś moim gościem dzisiaj.

Paweł: Cześć KamiL, witam.

KamiL: Paweł, tym którzy Ciebie nie znają, nie mieli okazji spotkać – powiedz w dwóch słowach kim jesteś i czym się zajmujesz obecnie.

• Paweł Szymański – gość podcastu. Kim jest i czym się zajmuje? 

Paweł: Cześć wszystkim, z tej strony Paweł Szymański, jeśli ktoś mnie nie zna. Też mówią do mnie Szczepan, jeśli chcielibyście wiedzieć. Kim jestem? Na co dzień jestem ekspertem ds. doskonałości procesowej, wcześniej problem solving ekspert, ale to tylko nazwa. Co za tą nazwą się kryje? Przede wszystkim jestem coachem w różnych metodach rozwiązywania problemów, jak A3, jak 8D, Six Sigma, Kobetsu Kaizen oraz inne. Jestem też również trenerem tych metod, to znaczy, że szkolę osoby z tego zakresu oraz innych narzędzi rozwiązywania problemów takich jak: 5xDlaczego, Ishikawa, Pareto i wiele, wiele innych, które można by tu wymieniać. Jestem również mentorem, wspieram coachów, tych, którzy chcą być na ścieżce coachów. Wspieram również nie tylko ludzi w projektach jako liderów, ale również wspieram całą fabrykę: kierowników, jak i samego dyrektora w różnych procesach podejmowania decyzji oraz w innych rzeczach, w których jestem potrzebny w tym zakresie.

• Kobetsu Kaizen – co to jest? 

KamiL: Wymieniając różne narzędzia czy metody, którymi się posługujesz powiedziałeś też o Kobetsu Kaizen. O ile Kaizen myślę, że jest powszechnie znane i rozumiane, powiesz dwa słowa co to za tajemnicza nazwa?

Paweł: Nic innego, jak rozbicie w tym przypadku w 10 krokach rozwiązywania problemów. Odlejkowanie od samego problemu, czyli przechodzimy od rozwiązywania problemu… Definiujemy problem, zawężamy się, następnie przechodzimy przez zbieranie faktów, analizy 5xDlaczego. Potem kolejne kroki to jest planowanie działań, wdrażanie działań, następnie standaryzacja. Czyli tak naprawdę Kobetsu Kaizen to nic innego jak ukryte kroki, pomniejsze rozbicie problemu tak, żeby na spokojnie przejść od problemu do samego rozwiązania.

KamiL: Czyli Kaizen, który jest nomen omen pewną filozofią, czy nawet dla niektórych światopoglądem, jest tutaj uporządkowany w taką bardziej metodykę, logikę rozpisaną na kroki.

Paweł: Tak jest.

• Początki z Six Sigma 

KamiL: Paweł, my spotkaliśmy się przy okazji Twojej wędrówki po ścieżce Six Sigma. Przez te wszystkie różne metody, narzędzia, którymi się zajmujesz finalnie trafiłeś na tę ścieżkę Six Sigma. Jak to się stało, że w ogóle trafiłeś do Six Sigma i czy Ci to coś dało? Jeśli tak, to co?

Paweł: Ta ścieżka jest bardzo ciekawa muszę przyznać. Oczywiście zaczęło się to już na studiach. Tak, dokładnie na studiach byłem na wykładach oraz ćwiczeniach, gdzie poznałem troszeczkę Six Sigma. Wtedy nie wiedziałem, że będę jeszcze coś robił w Six Sigmie. Wtedy nie wiedziałem, że w ogóle jest mi to potrzebne do życia i jak wpłynie na moje życie tak naprawdę. Wtedy nie wiedziałem. Przygoda zaczęła się, gdy poszedłem do pracy w której zderzyłem się jako inżynier procesu z teorią Six Sigma i gdzie dodatkowo doszły szkolenia z Six Sigmy w języku angielskim. Nie miałem po prostu większego wyboru, musiałem tego się nauczyć. Wtedy też nie wiedziałem, że będzie mi to potrzebne i jakoś nie pałałem do tego, żeby w tym kierunku pójść jako inżynier procesu. Jednak z czasem, kiedy zacząłem zdobywać wiedzę procesową, spotykać się z problemami na GEMBA, na procesach i widzieć to jak to wygląda, a przy okazji moi drodzy koledzy z mojej sekcji zaczęli robić też projekty Green Beltowe, szkolić się – tu pozdrawiam Zbyszka i Łukasza – ja też zacząłem z nimi przebywać, wspierać ich w tej Six Sigmie, patrzeć co oni robią, jak robią. I wtedy zobaczyłem jakie to jest fajne, jakie to jest przydatne, jak fajnie można zrozumieć proces. Że te liczby do nas tak naprawdę mówią, wystarczy coś z nimi zrobić. Wtedy stwierdziłem, że to jest coś ciekawego, w co mógłbym iść. Nadarzyła się okazja szkolenia, oczywiście w Akademii Białego Kruka z której skorzystałem, gdzie wykorzystałem swoją wiedzę teoretyczną na procesach robiąc dwa projekty, później obrona. Ale to nie najważniejsze ta obrona. Najważniejsze to to, że wtedy złapałem tego bakcyla, że można zrobić coś bardzo fajnego, nie męcząc się za bardzo aż tak i zobaczyć jak wygląda to od strony takiej bezpośredniej. Tak, że to widać było namacalnie, że każda liczba, każda dana może nam zmienić coś w procesie, jak ona na to wpływa. Po prostu to polubiłem. Było to dla mnie bardzo cenne narzędzie, które dało mi po prostu konkretnie ustrukturyzowany sposób radzenia sobie z dużą liczbą danych. W ten sposób zacząłem się zagłębiać się w tę tematykę jeszcze bardziej i jestem tu gdzie jestem.

KamiL: Bardzo przyjemnie się tego słucha. Ja mam poczucie takie, że tak humanizujesz nieco Six Sigma, które ma takie postrzeganie wśród wielu osób, że to jest jakieś takie statystyczne, nieprzyjemne, trudne. Mówisz o tym z taką lekkością, że to fajne, że nagle się okazuje, że to może być… Jakoś bardzo lekko to brzmi w Twoich ustach wszystko, kiedy o tym opowiadasz.

Paweł: Możliwe, że brzmi lekko, jednak na początku też miałem lekkie obawy. Ja się nie dziwię, że są te obawy. One są, ale niepotrzebnie. Mogę z doświadczenia powiedzieć, że one są niepotrzebne. Najważniejsze – nie teoria, nie szkolenia. Szkolenia oczywiście tak, musi być szkolenie, ale to szkolenie, żeby później samemu wykorzystać na projekcie. Jeśli się zrobi chociaż jeden projekt, zrozumie się większość rzeczy. Jak się zrobi dwa, trzy, cztery to nie ma szans, żeby tego nie polubić. Aż czysta przyjemność wtedy wchodzi.

• Faza Define i Control – dlaczego są tak ważne? 

KamiL: Paweł, ja wiem z rozmów z Tobą, że masz taką szczególną uwagę, którą przywiązujesz do tych etapów metodyki DMAIC, Six Sigma, którymi jest DEFINE i CONTROL. Czyli ten etap pierwszy – otwierający i ten ostatni – zamykający. Chciałem Cię podpytać skąd takie przekonanie, skąd takie patrzenie? Nie jest ono takie powszechne, zwłaszcza wśród osób, które nie mają doświadczenia i uczą się tej metodyki. Często wydaje się, że najważniejszy to jest ten środek, czyli te pomiary, analiza, która tam jest, potem poprawianie tego procesu. A to DEFINE to trzeba nazwać problem i zacząć robić, a CONTROL to trzeba po prostu podsumować wyniki i tyle. Skąd taka Twoja duża uwaga i duży nacisk na te dwa etapy?

Paweł: To przede wszystkim trzeba powiedzieć, że to chyba doświadczenie. Też tak na samym początku miałem, że myślałem, że najważniejsze to ta ANALYSE, postawienie hipotez sobie i znalezienie tych przyczyn źródłowych. Jednak z czasem zobaczyłem gdzie błędy są popełniane, też przeze mnie również. I przede wszystkim dla mnie ta faza DEFINE, zacznijmy od tego, jest bardzo ważna, ponieważ tu po raz pierwszy spotykamy się z samym problemem. Często ten problem sam w sobie jest źle zdefiniowany, on jest narzucony przez kogoś. Albo sami wybierzemy problem, który nie do końca jest dobrze zdefiniowany, on nie jest zbyt dobrze zawężony na tyle ile mógłby być, jest za szeroko. I tutaj spotykamy się właśnie z tym, że trzeba jednak się na tym skupić i czysto technicznie do tego podejść. Wiele osób pewnie by się tutaj zgodziło, że trzeba się zawęzić, trzeba dobrze odpowiedzieć czym jest problem, charakter biznesowy i tak dalej. Ale poza tym, w fazie DEFINE jest bardzo ważne to, że po raz pierwszy zespół, który został stworzony do Six Sigma zderza się z tą nazwą, samą w sobie. Six Sigma. I już wtedy pojawia się takie „kurcze, a co ten tutaj kolega chce ode mnie? Co on znowu wymyślił?” Przyszedł nowy i jest pewien strach, pewien niepokój, dlatego, że nie wszyscy i mam tego pełną świadomość, wiedzą co to w ogóle jest Six Sigma. I jeśli my wchodzimy w ten projekt i my zaczynamy używać nomenklatury, którą my znamy prawdopodobnie już bardzo dobrze i zaczynamy mówić DMAIC, Six Sigma, statystyka, hipotezy, P-Value, Sipoc i tak dalej, to wszystko zaczynamy rzucać do ludzi, to możemy ich wystraszyć. Po prostu.

KamiL: Albo zniechęcić conajmniej.

Paweł: Dokładnie. Zniechęcenie przed nieznanym. Niechęć zmian w ogóle, ale do tego zaraz dojdę. Ważne tutaj jest także to, że te osoby spotykają się nagle z tą nazwą i tym co się za nią kryje. To nie jest takie straszne. Warto tutaj moim zdaniem przede wszystkim gdzieś używać tutaj bardziej przyjaznych słów, wyjaśnić w ogóle co chcemy zrobić, te kroki, co się kryje pod tym. Może nawet nie używać nazwy Six Sigma na samym początku. Potem pokazać, że to jest ta Six Sigma, na czym polega. Bo tak naprawdę Six Sigma gdzie się pojawi? W fazie dopiero ANALYSE, gdzie będziemy używać odchylenia standardowego. W fazie DEFINE tego nie będzie, nie będzie mowy o Six Sigmie. MEASURE? Też raczej nie będziemy używać tego słowa w ogóle. Warto na samym początku powiedzieć, że mamy taki problem i podejść pod tę stronę.

• Czy trzeba nazywać projekty DMAIC „po imieniu”? 

KamiL: Chciałem Cię zapytać, czy masz też takie doświadczenie, bo ja się spotkałem kilkukrotnie z tym, że właśnie ze względu na wcześniejsze złe doświadczenia tych pracowników albo ze względu na jakiś opór, niechęć, że lider prowadził cały projekt Six Sigmowy od DEFINE do CONTROL i dopiero po jego sfinalizowaniu, na końcu, powiedział: to co zrobiliśmy to się nazywa Six Sigma. I przeszliśmy przez takie kroki. Dopiero wtedy zostało to nazwane. Być może jest tak, że w ogóle nie trzeba tego nazywać w ten sposób. Ważne, żeby lider to rozumiał.

Paweł: Dokładnie. Lider ma tę wiedzę, on jest najważniejszy, on spaja to wszystko. On tutaj pokazuje co trzeba zrobić, więc nie trzeba mówić konkretnie, że robimy DMAIC, że robimy Six Sigmę. Ważne, że lider wie. Jak ktoś jeszcze jest bardzo zainteresowany wewnątrz co to za metoda i padną pytania – dlaczego by nie? Można śmiało wytłumaczyć moim zdaniem.

• Jak radzić sobie z oporem i niechęcią w zespole? 

KamiL: Jak sobie radzić, jak sobie Ty radziłeś z tym oporem, niechęcią? Jak mówisz o fazie DEFINE to bardziej skupiasz się nie tyle na takich merytorycznych stronach definiowania problemu, to powiedziałeś, że jest jasne dla wielu osób, ale na tym miękkim aspekcie. Że to jest taki moment, że trzeba jakoś zawalczyć o uwagę zespołu, o jego zaangażowanie, powadzić sobie z jakąś niechęcią. Co byś zaproponował? Oprócz tego, że mówisz o używaniu lżejszego języka. Czy coś jeszcze jest ważnego?

Paweł: Myślę, że tak. Przede wszystkim dobrze się skupić nie tylko na metodologii samej, ale też na zaangażowaniu jako lidera. Przede wszystkim, żeby pokazać tym ludziom, że my sami jako lider nie jesteśmy jakimś szefem, nie jesteśmy osobą decyzyjną, nie punktujemy „Ty zrób to, Ty zrób tamto i będzie super”. Myślę, że tutaj powinniśmy jako osoby, Green Belty, Black Belty na poziomie lidera skupiać się przede wszystkim na tym, że to jest zespół, że to są ludzie, że dla nich nie tylko wszystkie kroki bez nazwy metodologii Six Sigma będą trudne, a samo pierwsze zderzenie z rozwiązywaniem problemów jakąkolwiek metodą będzie dla nich problemem, bo pierwszy raz się z tym zderzyli. Często bierzemy do zespołów różne osoby i te osoby mogą nawet nie wiedzieć co to jest rozwiązywanie problemów, jakiekolwiek. Tutaj moim zdaniem powinniśmy pokazać, że nie „idź zrób i przynieś mi wyniki”, tylko „a pomożesz mi w rozwiązaniu problemów? Zrobimy to razem? Czegoś nie rozumiesz? Chodźmy, zmierzymy”, a nie delegowanie ludźmi. Bycie liderem to bycie też z zespołem. Nie można tego odseparować, moim zdaniem powinno się być zaangażowanym w każdy krok, każde zadanie jakie wykonują ludzie w środku.

KamiL: Zadam takie może niezręczne pytanie, ale po co ktoś miałby chcieć Ci pomagać w rozwiązywaniu jakiegoś problemu? Przecież on ma co robić, albo ona.

Paweł: Jak najbardziej i tutaj tu jest ten opór z którym się zderzamy. Może nie często, ale na pewno w życiu nie jeden kto prowadził jakikolwiek projekt zderza się z takimi osobami, które mówią „przecież niejeden inżynier tu przyszedł i chciał udowodnić, że rozwiąże problem”. Niejedna osoba przyszła z narzędziami, przyszła z innymi metodami i nie rozwiązała tego problemu. I wtedy mamy faktycznie do czynienia z takim strachem przed zmianą i udowadnianiem, że już się nie da, ja tu pracuję 40 lat i nikt tego nie zrobił, tak się pracuje i tak jest okej. Wtedy należy moim zdaniem trafić do tych ludzi, pokazać im krok po kroku jak wpływają sami na proces. To znaczy pokazać im, że oni sami, żeby dostrzegli, że można dowiedzieć się czegoś więcej. A używając Six Sigma to jak kroczek po kroczku wydobywać informacje. I nagle się okazuje, że te osoby, jak sobie tak przejdziemy krok po kroku i nie mówimy o tych wspaniałych wynikach na końcu, nie straszymy ich, „my to zrobimy, ukrócimy problem, rozwiążemy, będziemy świętować”. Nie, bo to już niejeden pewnie powiedział przed nami. Lepiej pokazać im jak wygląda proces, zawęzić go, zrobić wstępną analizę procesu, SIPOCa, następnie opracować tę szczegółową mapę procesu, następnie już na tym etapie gdzieś te osoby zaczną nawet sami zdradzać, że okej, tego nie wiedziałem, to coś dla mnie nowego. I nagle ktoś po 10-15 latach doświadczenia, czy nawet 5 latach doświadczenia na danym stanowisku mówi: „o, to coś nowego, fajne, nie patrzyłem na ten proces w ten sposób”. I wtedy przechodzą te osoby na naszą stronę można tak powiedzieć, zaczynają być częścią zespołu, a nie tylko osobami, które po prostu nie chcą bardziej przeszkadzać niż wspierać. Tutaj myślę, że metoda małych kroków i pokazanie, że jednak da się coś nowego dowiedzieć o procesie i pokazanie tych szczegółów pomaga.

KamiL: Tobie się Paweł zawsze udaje pozyskać wsparcie i sympatię tych osób z zespołu czy też być może czasem jest tak, że pomimo różnych starań jest nie i nie i koniec. Co wtedy?

Paweł: Uśmiecham się, bo wiem, że takie coś się zdarzyło. Że nie i koniec, przez większość czasu. Nie mówię, że od razu daje się przekonać osoby na fazie DEFINE czy MEASURE, ale ja dobrze wiem, że jak już kończy się dany projekt albo jesteśmy w trakcie gdzieś, widzę sam, że z oporu, kiedy osoba nawet nie chciała ze mną rozmawiać, tak bym to powiedział, sama później już opowiadała mi już nie o samym projekcie, a o swoim nawet życiu. Da się takie osoby przekonać. Nie jest to łatwe, nie należy się poddawać i też nic na siłę na pewno. Pokazywać kim się jest, po co jest i robić z tego jeszcze większy problem. Tylko starać się zdobyć zaufanie i pokazać, że nie przyszedłem tu tylko, bo robię projekt i chcę rozwiązać problem i będzie fajnie, bo będę miał z tego jakieś benefity. Tylko pokazać, że ja chcę rozwiązać problem, żeby komuś było łatwiej. I jak to się pokaże to swoje zaangażowanie w rozwiązywanie problemów i tę swoją pracę, którą trzeba było włożyć, to ludzie to docenią.

KamiL: Jakieś bliskie jest mi to co mówisz, bo w taki miękki sposób do tego podchodzisz. Nie wiem czy Ty też, ja się często spotykam z takim mówieniem o oporze jako o czymś, co trzeba przełamywać. Funkcjonuje takie przełamywanie oporu przed zmianą. I dla mnie jest to kompletnie kontrproduktywne, kiedy mówimy o przełamywaniu oporu, łamaniu. Zupełnie to z moich doświadczeń, w moim patrzeniu na biznes, na usprawnianie, nie prowadzi do dobrej współpracy. Jeżeli na starcie proponujemy, że trzeba coś i jakiś opór trzeba połamać, żeby ktoś chciał współpracować.

Paweł: Może się to źle skończyć.

• Faza Control – dlaczego jest ważna? 

KamiL: Paweł, powiedziałeś trochę o fazie DEFINE, czemu ona jest tak istotna i o tym miękkim aspekcie. A skąd taka Twoja duża uwaga przy fazie CONTROL?

Paweł: Często zdarza się tak, że przy fazie Control wszyscy chcą już zamknąć projekt i świętować. Tak to już bywa i faza CONTROL gdzieś jest niechlujnie powiedziane.. pomijana. A przede wszystkim to ona pokazuje, podsumowuje tak naprawdę cały nasz wysiłek jaki zrobiliśmy wcześniej. Często nie doceniamy tego co robiliśmy. Czasami te projekty trwają przecież pół roku, a nawet i więcej z różnych powodów. Nie dość, że zespół już się tak mocno zintegrował, wszystko jest fajnie pięknie, a na koniec tylko zamykamy i kończymy… to to nie ma takiego wymiaru, w którym można by powiedzieć: to jest to, jesteśmy dumni z tego. Nie dość, że faza CONTROL od tego czysto technicznego aspektu jest bardzo ważna, bo jakby nie patrzeć to CONTROL, to zarządzanie zmianą powoduje, że tam powinniśmy skupić się jak najbardziej. Bo to co zrobiliśmy, jeśli teraz nie zadbamy o to, to może być tak, że nam wszystko się rozjedzie i utracimy. Wiadomo, mówi się o tych procentach, jak ważna jest faza CONTROL, że to 70% sukcesu całego projektu. Tak, jak najbardziej. To są liczby, ale też za tymi liczbami stoją ludzie. I my jesteśmy w fazie CONTROL, gdzie właśnie zrobiliśmy bardzo dużo swojej pracy. Warto pokazać, jak duży wysiłek my zrobiliśmy, ile wysiłku włożyliśmy w każdy z kroków, pochwalić się tym. Czysty marketing. Marketing oczywiście wewnętrzny, pokazania jak dużo zrobiliśmy pracy,  jak fajnej pracy zrobiliśmy, jak wpłynęliśmy na procesy, jakie są korzyści, czyli porównanie się z tą fazą DEFINE, z kartą projektu. To jest dobre. Żeby tym ludziom, którzy są w tej pracy i oni chcieliby zamknąć i pójść i powiedzieć: no dobra, teraz musimy otworzyć szampana i świętować. Jasne, możemy otworzyć tego szampana, ale zanim to zrobimy – wyciągnąć jakieś wnioski, co nam poszło dobrze, co nam poszło źle. Ocena tych rezultatów biznesowych. Oczywiście też między sobą fajnie porozmawiać o tym czego się nauczyliśmy, czego się nie nauczyliśmy, ale tak jak mówię – ta wisienka na torcie to pokazać ile dobrego przyniosło te pół roku zmagań. Gdzie jesteśmy teraz, a gdzie byliśmy kiedyś. I to świętować. Ale też nie tylko samą Six Sigmę. Pokazać, gdzie byliśmy na początku, jako zespół. A gdzie jesteśmy jako zespół na końcu. Jakie relacje były na początku, jakie są teraz? I najczęściej są to uśmiechy, czasami można pocytować co kto powiedział na początku, a co mówi na końcu. Czasami takie spotkania zamykające są naprawdę bardzo fajne, bo możemy powspominać nawet bym powiedział.

KamiL: Jasne. Zamyśliłem się w ogóle jak mówiłeś teraz o tym, jakieś miałem różne wspomnienia i też takie zdanie mi przychodzi do głowy: czasami największa wartość z projektów Six Sigma to jest to, że one budują takiego realnego ducha pracy zespołowej. Przez dużo trudnej pracy włożonej i radzenia sobie z konfliktami, z niechęcią i jeżeli to się udaje to ta współodpowiedzialność za rezultaty, cieszenie się tym to jest super. To jest ogromna wartość z punktu widzenia kultury firmy.

Paweł: Zgadza się. Te relacje zostają już nie tylko na projekty. Te relacje, jeśli ktoś zostaje w danej firmie to zostają na lata.

KamiL: I tak podsumowując to co powiedziałeś o fazie CONTROL, to podkreślasz znaczenie takiego zatrzymania się na chwilę, zanim skończymy i domkniemy. Bo to jest taka chęć, dobra, kończymy, otwieramy szampana, a Ty mówisz: dobra, ale jeszcze zatrzymajmy się na chwilę i zobaczmy i spróbujmy to podsumować, wyciągnąć wnioski, na chwilę się przy tym zatrzymać i skierować uwagę na to. Myślę, że to bardzo cenne jest.

Paweł: Tak, taka retrospektywa tego co zrobiliśmy tak naprawdę.

• Jak zadbać o dynamikę projektów? 

KamiL: Powiedziałeś Paweł o tym, że te projekty trwają i pół roku, czasem może i dłużej. My też tak uczymy naszych absolwentów, że te 4-6 miesięcy to są takie widełki w których chcemy, żeby te projekty Black Beltowe się trzymały, Green Beltowe najlepiej jeszcze trochę krócej. Ale jak obaj wiemy, w życiu różnie jest i czasem te projekty rzeczywiście trwają dużo dłużej niż byśmy chcieli, czasem gdzieś się zupełnie rozchodzą. Jak z Twojego doświadczenia, co uważasz, że jest krytyczne lub ważne, żeby zadbać o dobrą dynamikę tych projektów?

Paweł: Jest kilka pomysłów. Tym bardziej z doświadczenia, moim zdaniem przede wszystkim nie powinniśmy trzymać dynamiki tylko na samym początku. Mówię tutaj o czysto technicznych spotkaniach. Czyli na początku są te spotkania bardzo często, potem im dalej w las tym te spotkania się rozchodzą. Na przykład: robiliśmy dwa spotkania w tygodniu, a później robimy jedno na miesiąc.

KamiL: A potem są ferie…

Paweł: A potem są ferie, wakacje i się okazuje, że spotkania są raz na dwa miesiące. A kogoś nie było, to potem już raz na trzy miesiące. I ja się nie dziwię, że wtedy taki projekt może nawet trwać rok. Dlatego patrząc z tej perspektywy, jeżeli trzymamy dynamikę jednego spotkania na tydzień to trzymajmy tę dynamikę przez cały czas. Przypuśćmy. Oczywiście to jest przykład, dlatego że dla każdego projektu i dla każdego środowiska zespołowego będzie ten okres inny. Wszystko zależy od problemu, pracy, procesu itd. Wiadomo, to jest tylko przykład, ale na pewno bym powiedział, że tę dynamikę należałoby trzymać od początku do końca. Czyli nie powiedzieć sobie, że DMAIC jest najważniejszy i tutaj robimy bardzo dużo spotkań, a CONTROL już mniej ważny i tam możemy zrobić dwa spotkania i koniec. Moim zdaniem to błąd. My powinniśmy też dużo poświęcić zarówno na DMAICa jak i CONTROL a środku…

KamiL: Na DEFINE i na CONTROL masz na myśli.

Paweł: Tak jest. Dodatkowo, gdzieś tutaj z mojej strony tę dynamikę bym podtrzymywał pozaprojektowo. To znaczy mamy spotkania czysto techniczne na naszych procesach, liniach, ale moim zdaniem to żeby trzymać dynamikę, trzymać to, że dzieje się i idziemy do przodu z tym wszystkim to przede wszystkim też być na Gembie, na procesie, pozaprojektowo. Nie, że iść i mierzyć i faktycznie to robić z projektem, ale też zobaczyć jak ten proces wygląda, rozmawiać z ludźmi, którzy są na tym procesie przecież. Idziemy z nimi porozmawiać. Jak idzie, jak to wygląda, czy to wszystko jest okej? Żeby też te osoby czuły, że ta dynamika jest potrzebna nie tylko na spotkanie, które ma godzinę, dwie w tygodniu, ale ta dynamika powinna być też poza projektem. Czyli idziemy na proces, idziemy z ludźmi, jeśli ludzie są na procesie to idziemy do nich, rozmawiamy o tym, dowiadujemy się coś, notujemy, zbieramy jakieś informację zwrotną przede wszystkim. Każdy proces też jest zmienny. To co my założyliśmy, że będziemy coś mierzyć i coś będziemy sprawdzać, to może ta dynamika się zmienić bezpośrednio na procesie, na Gembie. Tam idąc dopytujemy się jakie są przeszkody, a że czegoś nie da rady zrobić… Takich rzeczy się nie dowiemy na spotkaniu. Nie wszystko ludzie chcą mówić. A jak pójdziemy na proces to też dużo rzeczy się dowiemy, a jak już się dowiemy to będziemy mogli na to jakoś działać. Mamy też przecież Sponsora w swoim zespole. Możemy też delegować jakieś problemy gdzieś wyżej. Nie tylko jesteśmy sami w tym całym procesie. Więc ta dynamika nie powinna być tylko na liderze, ale też powinna być rozdystrybuowana na inne podmioty.

KamiL: Podsumowując – to rozumiem tak, że pierwsza rzecz o której mówisz, czyli niedopuszczanie do spowolniania, które jest, też mam podobne doświadczenia, częste. Czyli startujemy z dobrym tempem, a potem niezauważalnie zaczyna to tempo maleć, maleć i jak na to pozwolimy to ta trajektoria się utrzymuje często. Czyli uważność na to, niepozwalanie żeby ta dynamika już na początku zaczęła spadać. A druga rzecz – rozumiem to co mówisz tak, że uważasz, że warto jest dbać o tę dynamikę nie tylko na spotkaniach projektowych i w ramach tej struktury którą tworzymy, tylko też w takim naszym codziennym day-to-day, byciu w kontakcie z tymi osobami, byciu na Gembie etc.

Paweł: Tak. dodatkowo jeszcze bym tutaj mógł dodać, że powinniśmy gdzieś planować swoje działania, tzn. nie robić sobie to z głowy wszystko. Nie jesteśmy w stanie w całości wszystko mieć w głowie poukładane. I tutaj gdzieś korzystać z planowania swoich działań, nie tylko DMAICowych, ale też takich działań pośrednich. Dlatego, że nie jestem w stanie sobie wyobrazić, że lider pociągnie, zapamięta tyle tematów w głowie, będzie nimi kontrolował oraz będzie miał jeszcze swoje działania pozaprojektowe, tzn. swoją pracę codzienną. To przede wszystkim musi być poukładane, gdzieś musimy mieć tę ściągawkę, gdzieś musimy się do czegoś odnieść, żeby móc powiedzieć gdzie jesteśmy, gdzie powinniśmy być i czy możemy coś z tym zrobić. To jest jedno. A przy planowaniu, to też KamiL wspomniałeś, my też mamy jakieś wakacje, jakieś urlopy, mamy chorobowe, mamy święta. Jak tego nie zaplanujemy gdzieś dobrze też, nie ujmiemy tego w planie, to też się nam wszystko rozjedzie i ta dynamika pójdzie na bok. Nic z tym więcej nie zrobimy. Dlatego ta świadomość planowania powinna już być. Jeśli my robimy projekt, zaczynamy nagle wakacje, to bądźmy świadomi, że w zespole kogoś zabraknie.

KamiL: I co wtedy? Szukamy zastępstwo czy działamy bez tej osoby? Jakie Ty masz doświadczenia?

Paweł: To zależy, tak odpowiem. Nie ma tutaj jednoznacznej odpowiedzi. Próbuję się dopasować do tego co mam, jakie zasoby mam, jakie daje nam środowisko zasoby, tzn. mogę poprosić o zastępstwo, mogę spróbować zrobić to z takim zespołem jaki mamy, a potem tej osobie, której nie ma opowiedzieć co zrobiliśmy, jak zrobiliśmy itd. Czyli wrócić z tematem do tej osoby, jakie tematy zrealizowaliśmy w jej obszarze czy zakresie prac. Fajnie by było mieć zastępstwo, oczywiście tutaj myślę bardziej o takich rzeczach, ale też myślę, że zespół to nie jest jedna osoba i jesteśmy w stanie sobie przecież poradzić z innymi osobami. Po prostu trzeba to w inny sposób zaplanować, ale myślę, że jest to do zrobienia. Po prostu z zespołem zmniejszonym.

• Jak liczne są zespoły projektowe Six Sigma? 

KamiL: Też jestem zwolennikiem tego, żeby spotkania się odbywały, sprawy się toczyły niezależnie od tego, nawet czasami, jeśli się zdarza, że lidera nie ma, bo też tak może być. Lider też może się rozchorować zwyczajnie, odpukać, ale żeby był ktoś, powiedzmy lider, prawa ręka, kto może to spotkanie robocze poprowadzić. Z ciekawości zapytam Paweł, jak liczne są zespoły Six Sigmowe, które prowadziłeś? O jakiej liczbie osób rozmawiamy najczęściej?

Paweł: Ja tutaj najczęściej oscyluję w około 5, 6, do 7 osób.

• Czego może nauczyć rozwiązywanie problemów?

KamiL: Pytam o to, bo to jest też jeden z czynników, który nam nieraz komplikuje to planowanie. Zawsze byłem zdania, że raczej lepiej jak ten zespół jest mniejszy, ale taki bardziej zaangażowany, stabilny, obecny niż większy, ale ciągle kogoś brakuje, ciągle kogoś nie ma. Paweł, na koniec chciałem Cię jeszcze zapytać o taką część z Twojej historii. Wiem, że swego czasu w jednej z firm, w jednej z korporacji znanych otrzymałeś dość prestiżową nagrodę związaną z rozwiązywaniem problemów, usprawnianiem procesów. Chciałem Cię zapytać co możesz powiedzieć o tej nagrodzie, co to była za nagroda i czy ona Ci coś dała? I co to za historia?

Paweł: Tak, było coś takiego, potwierdzam. Bardziej bym to potraktował jako wyróżnienie niż nagrodę, za osiągnięcie dobrych wyników i zrealizowania w ramach projektu Six Sigma rozwiązania, które można było zaimplementować globalnie, nie tylko lokalnie na jednej fabryce. Co ona mi dała? Pokazała mi przede wszystkim jedną z najważniejszych rzeczy, że trzeba być cierpliwym przede wszystkim. Wyróżnienie polegało na tym, że zostało znalezione rozwiązanie, które było po prostu między dwoma zależnymi zmiennymi. Znaleziono zależności takie, które można było po prostu zaimplementować, żeby proces był stabilny. Bez wchodzenia w szczegóły oczywiście. I co mi dało? Ja pamiętam wtedy ten czas, że to nie było takie proste. Że znalezienie tego to nie było zrobienie w fazie ANALYSE jednej, dwóch analiz i tu mamy zależność i już mamy rozwiązanie. Mieliśmy tę zależność i nie wiedzieliśmy co z nią zrobić. Była i po prostu ok? Co dalej? Mogę powiedzieć, że ta cierpliwość. I nieodstępowanie od procesu, czyli rozmawianie ciągle z liczbami. Tutaj pamiętam setki godzin spędzonych na procesie z technikami oraz inżynierem. Tutaj pozdrawiam po raz drugi Łukasza z którym naprawdę spędziliśmy mnóstwo czasu z laptopami, z Mini Tabem, bezpośrednio na procesie, nie schodząc z niego póki się czegoś nie dowiedzieliśmy. Tak długo drążyliśmy teraz, że tak mocno poznaliśmy proces, tak mocno poznaliśmy zależności, że gdzieś w końcu te liczby do nas przemówiły. Ja wtedy właśnie zauważyłem pewną zależność, którą w końcu udało się zaimplementować gdzieś głębiej. Mam taki cytat Alberta Einsteina, który mówi: It’s not that I’m so smart, it’s just that I stay with problems longer. Tłumacząc na polski: nie jestem aż taki mądry, ale tak długo zostaję z problemem, aż go zrozumiem i w końcu znam rozwiązanie. I to mnie nauczyło i do dziś to wykorzystuję tak naprawdę. To jest zapał cierpliwości i zostania z problemem tak długo, aż będę miał rozwiązanie. I myślę, że to mnie tego nauczyło. Nagroda sama w sobie była dla mnie wyróżnieniem i pokazała, że warto. Ale jednak za tym kryje się dużo, dużo więcej. To było tak jakby punk zapalny u mnie, że warto poświęcić trochę czasu i faktycznie zrozumieć proces, zrozumieć liczby, co one do nas mówią i wykorzystać to na swoją korzyść, to znaczy na znalezienie rozwiązania.

KamiL: Mastercard by powiedział o tym co zyskałeś w kategoriach pewnie: bezcenne.

Paweł: Dokładnie, to było bezcenne. Jak z reklamy.

KamiL: Pozostaje mi życzyć naszym wszystkim słuchaczom i absolwentom obecnych i przyszłych kursów Black Belt cierpliwości, która jak wiemy jest bezcenna. A pytanie do Ciebie Paweł, czego Tobie życzyć teraz na tej ścieżce zawodowej z rozwiązywaniem problemów?

Paweł: Więcej fajnych przygód. Każdy projekt to przygoda i tak jak to traktuję.

KamiL: Nie znudziło Ci się jeszcze to?

Paweł: Nie, nie. Myślałem, że będę miał monotonną pracę, a uważam, że to nie jest monotonna praca. Każdy problem jest inny, każdy zespół jest inny i to daje mi siłę. Poznaję bardzo fajnych ludzi, poznaję też również procesy, problemy, jak do nich podchodzić i uczę się ciągle. Ta przygoda niech trwa tak długo jak może być i żeby mi się nie znudziła.

KamiL: No to chwilo trwaj i mnóstwa dobrych przygód Ci życzę Paweł i bardzo dziękuję Ci za rozmowę. To była przyjemność rozmawiać z Tobą o Six Sigma, właśnie też na takim poziomie stricte projektowym, praktycznym, operacyjnym. Bardzo dziękuję za to spotkanie.

Paweł: Również dziękuję i wszystkich pozdrawiam.

• Six Sigma Green Belt 
• Six Sigma Black Belt