Wyobraźmy sobie, że wdrożyliśmy w naszej firmie Lean IT. Że objawem wdrożenia jest zespół "leanowy", który ma wyszukiwać okazji do upraszczania procesów i pomagać z nich korzystać. A nowy zespół, podobnie jak każdy, dostaje swoje cele, uprawnienia i zabiera się do działania. Co możne zrobić źle?
Lean Management (pol. szczupłe zarządzanie) to koncepcja zarządzania, oferująca zestaw technik i metod, dzięki którym wykonywana praca skoncentrowana jest przede wszystkim na zaspakajaniu potrzeb klientów w, eliminację marnotrawstwa, ciągłe doskonalenie i partycypację uczestników procesu w jego udoskonalaniu. Z kolei Lean IT to zastosowanie Lean Management w środowisku IT - w obszarach dostarczania rozwiązań, utrzymania systemów czy świadczenia usług.
Z jakiego powodu IT zainteresowało się Lean Managementem? Korzyści ze stosowania Lean Managementem dostrzeżone w przemyśle czy usługach, a w szczególności oszczędności zasobów spowodowały, że również menedżerowie IT zapragnęli skorzystać z tego podejścia. Z różnym, jak pokazuje życie, skutkiem. A ponieważ najlepiej uczyć się na cudzych błędach, proponuję krótki przegląd 5 fuckup'ów w korzystaniu z lean, z którymi spotykałem się bezpośrednio czy też usłyszałem o nich w trakcie różnych spotkań.
Jedną z zasad Lean IT jest określenie KPI (ang. Key Performance Indicators czyli po polsku Kluczowe wskaźniki efektywności) które mówią po czym poznamy, czy osiągnęliśmy nasze cele (tu:) związane z upraszczaniem procesów IT. W wielu organizacjach ustalane są cele stawiane wykorzystaniu Lean Management - co jest jak najbardziej zasadne. Ale diabeł tkwi w szczegółach. Wyobraźmy sobie taki KPI: "Naszym celem jest wdrożenie po cztery usprawnienia, w każdym dziale, w ciągu roku". Jak myślicie, co spowoduje taki cel? Szukanie usprawnień? Tak. Szukanie okazji do usprawnień? Tak. Jakich usprawnień szukamy? Jakichkolwiek. Byle po cztery na dział. I tu właśnie ten diabeł. Lean IT wyraźnie mówi, aby wdrażać usprawnienia tam, gdzie ma to sens. Gdzie są uzasadnione ekonomicznie. Co jeśli w danym dziale w ciągu roku nie znajdziemy 4 okazji do usprawnień? A co, jeśli będzie jedna, ale jej wdrożenie zajmie 10 miesięcy i na 3 kolejne nie starczy czasu? A co, jeśli będziemy mieli 10 okazji. Które wybrać?
Natura ludzka jest taka, że jeśli postawi się nam jakiekolwiek cele i zaproponuje za nich realizację nagrodę, to będziemy starali się je zrealizować nie patrząc na to, czy nie szkodzimy organizacji w innych obszarach, czy nie tracimy z oczu korzystniejszych opcji. Więc stawiając cele przez Lean Management zastanówmy się, jakie powinny one być, aby wspierały rzeczywiste cele, istotne dla całej organizacji.
Na co dzień mamy skłonność do wydawania opinii na podstawie emocji, uczuć czy czegoś, co nazywam "wydajemisię". Na przykład: "Wydaje mi się, że testy idą zbyt wolno, bo za mało ludzi bierze w nich udział".
I już znamy rozwiązanie! "Dorzućmy ludzi do testów". To na pewno oczekiwany efekt. Tylko nasuwa się pytanie: czy na pewno wybieramy najlepsze rozwiązanie? Co to znaczy, że jest "za mało", "za wolno" czy "za dużo"? Skąd wiemy, że tak faktycznie jest?
Podejście Lean zakłada, że badając obszary do usprawnienia opieramy się na rzeczywistych danych. Przy "leanowaniu" konieczne jest zbieranie danych - wiarygodnych, związanych z tematem, kompletnych. Wszytko można zmierzyć. Jeśli nie mamy danych z systemu, skorzystajmy z metod ręcznych. Jeśli jakaś kategoria nie jest mierzalna, to... Szczerze mówiąc, nie ma "niemierzalnych" kategorii. Jest tylko kwestia doboru miary i metody jej pozyskania. Dopiero analiza wiarygodnych danych, pozbawionych zakłóceń w postaci emocji, pozwala na zidentyfikowanie i zajęcie się rzeczywistymi przyczynami, a nie tymi "wydajemisię". Na zajęcie się przyczynami, a nie objawami.
Pamiętajmy, że wiarygodne dane to nie tylko czasy, ilości itp. To również rzeczywisty, aktualny kształt procesów, które chcemy usprawniać (patrz pkt. 4). Żeby nie być gołosłownym, dla podanego wyżej (rzeczywistego!) przykładu w wyniku badania okazało się, że testujący musieli wymyślać sami przypadki testowe, stąd marnowany był czas ich pracy.
Zespół "leanowy" - wyszkolony, prężny, zwarty, gotowy, pełen energii i dobrych chęci, jak każdy neofita uważa, że wie wszystko najlepiej, że wszystko może zrobić najlepiej, że inni się nie znają, będą przeszkadzać, sabotować, nie chcą zmian.
I generalnie jest to prawda. Ludzie nie lubią zmian. A najbardziej się przed nimi bronią, jeśli... nie biorą udziału w ich definiowaniu i wdrażaniu. Dlatego warto od początku wciągać do działania osoby, które będą pracowały w takich usprawnionych procesach.
Zespoły leanowe często zaczynają od poświęcenia pewnego czasu (tygodnia, miesiąca, czasami dwóch) na poznanie procesów, którymi mają się zająć. Po co? Żeby wiedzieć, co usprawnić.
Moim zdaniem często jest to marnotrawstwo czasu. Warto wiedzieć, na czym polegają te procesy i jaki mają dawać rezultat - ale ogólnie. A szczegóły znają uczestnicy i klienci tychże. Wciągnijmy ich do pracy. Niech oni narysują nam aktualne mapy procesów, pokażą, jak w rzeczywistości one działają. I nie mówię o kierownikach zespołów biorących udział w procesie, ale o osobach, które faktycznie wykonują w nich prace. Sam się kiedyś naciąłem kilka razy, że kierownicy nie znali różnych "myków" stosowanych przez swoich pracowników, które miały wpływ na działanie procesu. Więc bierzmy ludzi z "linii produkcyjnych" i z ich wiedzy korzystajmy.
Przyszedł zespół leanowy, wdrożył uproszczenia do procesu, zrobił "+1" do swojego KPI i poszedł dalej. Znacie? Ja znam... Takie zespoły zapominały często o jednej rzeczy - ustanowieniu mechanizmów, które sprawiały by, że wprowadzone zmiany będą stałe - nie zostaną zaprzepaszczone po 2-3 miesiącach. A dzieje się tak najczęściej wówczas, kiedy wdrażane zmiany nie adresują rzeczywistych przyczyn, tylko "pudrują" rzeczywistość (o czym było wyżej) lub kiedy nie spowodowały modyfikacji KPI, zwyczajów, sposobów zarządzania pracą w zmienionym procesie. Zakładając, że przeprowadziliśmy dobrą zmianę pamiętajmy o ustanowieniu mechanizmów, które pozwolą ją utrzymać. Inaczej za jakiś czas ktoś przyjdzie i powie, że co prawda zmianę wdrożyliśmy, ale nic się nie... zmieniło.
Tak na marginesie - angielskie słowo "control" nie oznacza po prostu "kontrolowania", ale bardziej opisuje zdolności do zarządzania, wpływania czy sprawdzania.
Oczywiście powyższe nie wyczerpuje wszystkich możliwych nieprawidłowości. Jeśli znacie inne regularnie powtarzające się błędy, związane ze stosowaniem podejścia Lean IT - podzielcie się nimi. Spróbujemy wspólnie wypracować, w jaki sposób zapobiegać ich powielaniu.
