Gorączka 39 stopni, z nosa cieknie katar, kaszel nie pozwala spać w nocy. Czas do lekarza. Po 3 godzinach w poczekalni wchodzimy na upragnioną wizytę. Lekarz zerka jednym okiem na nas i rzuca “gorączka? katar? kaszel? Taaa… wirus. Teraz wszyscy mają. Taka pora roku.”. Wypisuje leki bez zadawania zbędnych pytań, wręcza recepty i prosi kolejną osobę. Czy naprawdę tego oczekiwałem jako pacjent? Przecież on nawet o nic nie zapytał… od kiedy? jak mocny katar? jaka gorączka? czy kaszel mokry czy suchy? czy gardło boli? Nawet nie sprawdził czy czegoś nie słychać w płucach! Do d… takie rozwiązanie problemu.
Rozwiązanie problemu… No właśnie… Problemu. Dla pacjenta problemem jest choroba oraz jej wszystkie uciążliwe skutki.
Dla pracownika na produkcji problemem są sztuki NOK wychodzące z maszyn, ciężkie przezbrojenie stanowiska czy brak przeszkolenia z danego procesu. Dla kierownika produkcji problemem są złe wyniki na produkcji – za niska wydajność, duża ilość awarii. Problemem dla inżyniera procesu będzie chociażby duży odpad produkcyjny oraz niestabilny proces. Działowi HR przeszkadza zbyt duża fluktuacja pracowników oraz częste zwolnienia lekarskie. Główna księgowa narzeka na problem z płatnościami faktur po terminie, a planiści nie nadążają zmieniać planu produkcyjnego w związku z ciągłym brakiem komponentów i zmieniającymi się zamówieniami w systemie. Każdy ma problemy. Pytanie czy powiemy już na wstępie “tak zawsze było u nas”, “nic na to nie poradzimy, tak musi być”, “aa, zgłaszałam już ten problem, ale nic się nie dzieje” i postawimy z góry diagnozę bez przeprowadzania chociażby małego śledztwa, czy może postanowimy w końcu zająć się problemem i rozwiązać jego przyczynę źródłową? Większość z nas jest przyzwyczajona do sposobu działania zwanego “jump to solution” – na wzór naszego lekarza. Czy nie warto byłoby jednak spełnić wymagania naszego pacjenta i wykonać najpierw szczegółowe badania? Na przestrzeni kilku ostatnich lat pracy z rozwiązywaniem problemów przekonałem się, że dobra definicja problemu (problem statement), to podstawa szybkiego i skutecznego zabicia problemu. Jutro postaram się podzielić z Wami przykładami wraz z zastosowaniem konkretnych metod. A w jaki sposób Wy określacie problem? Jakich narzędzi używacie? Czy lubicie spędzać dłuższą chwilę nad dokładną definicją problemu?
Dla pracownika na produkcji problemem są sztuki NOK wychodzące z maszyn, ciężkie przezbrojenie stanowiska czy brak przeszkolenia z danego procesu. Dla kierownika produkcji problemem są złe wyniki na produkcji – za niska wydajność, duża ilość awarii. Problemem dla inżyniera procesu będzie chociażby duży odpad produkcyjny oraz niestabilny proces. Działowi HR przeszkadza zbyt duża fluktuacja pracowników oraz częste zwolnienia lekarskie. Główna księgowa narzeka na problem z płatnościami faktur po terminie, a planiści nie nadążają zmieniać planu produkcyjnego w związku z ciągłym brakiem komponentów i zmieniającymi się zamówieniami w systemie. Każdy ma problemy. Pytanie czy powiemy już na wstępie “tak zawsze było u nas”, “nic na to nie poradzimy, tak musi być”, “aa, zgłaszałam już ten problem, ale nic się nie dzieje” i postawimy z góry diagnozę bez przeprowadzania chociażby małego śledztwa, czy może postanowimy w końcu zająć się problemem i rozwiązać jego przyczynę źródłową? Większość z nas jest przyzwyczajona do sposobu działania zwanego “jump to solution” – na wzór naszego lekarza. Czy nie warto byłoby jednak spełnić wymagania naszego pacjenta i wykonać najpierw szczegółowe badania? Na przestrzeni kilku ostatnich lat pracy z rozwiązywaniem problemów przekonałem się, że dobra definicja problemu (problem statement), to podstawa szybkiego i skutecznego zabicia problemu. Jutro postaram się podzielić z Wami przykładami wraz z zastosowaniem konkretnych metod.
A w jaki sposób Wy określacie problem? Jakich narzędzi używacie? Czy lubicie spędzać dłuższą chwilę nad dokładną definicją problemu?