Lean IT w praktyce: krótki przewodnik co to jest Lean

Lean IT, czyli zastosowanie pryncypiów podejścia Lean Management w środowisku IT, wciąż często spotyka się ze sceptycyzmem. Bo przecież „IT nie produkuje części samochodowych czy pralek”, generalnie nie produkuje niczego. Nic bardziej mylnego. IT tworzy produkty!

Produktami działu IT są: świadczone usługi, utrzymanie systemów czy dostarczone nowe rozwiązania – systemy i usługi. Biorąc pod uwagę, że często na IT nakładana jest presja zmniejszania kosztów – a jednocześnie zwiększania wydajności i sprawności – warto zastanowić się, czy nie skorzystać z podejść proponowanych przez dział Lean. Jak więc w pracy działu IT skorzystać z pryncypiów opisanych przez Lean?

Zidentyfikuj klienta i określ, jaką wartość mu dostarczasz

Przede wszystkim należy odpowiedzieć na pytanie: jakich klientów może mieć typowy zespół IT funkcjonujący w przedsiębiorstwie? Najczęściej są nimi pracownicy innych działów tej firmy lub innych zespołów IT, czyli klienci wewnętrzni. Mogą być nimi też klienci zewnętrzni, będący jednocześnie klientami całego przedsiębiorstwa. Specyficznym klientem będzie obszar zarządzania firmą: właściciele, zarząd, rada nadzorcza, działy finansów czy zasobów ludzkich.

Każda z tych grup będzie miała zapewne inne wymagania. Czasami mogą być one sprzeczne. Klient przedsiębiorstwa będzie chciał szybko i tanio otrzymać serwis IT. Dział finansów będzie pilnował, aby efektywność przychodowa takiego serwisu była na pożądanym poziomie. Każdy z tych klientów będzie skłonny zapłacić za pewne rzeczy – za te, które stanowią dla niego określoną wartość. Co ciekawe, pewne działania będą stanowiły wartość dla niektórych klientów (np. raportowanie kosztów będzie wartościowe dla działu finansów), a dla innych będą zbędnym obciążeniem. Przykładowo, konieczność zapłacenia za to raportowanie, ukryta w cenie usługi, będzie bezwartościowa dla klienta zewnętrznego.

Dlatego z punktu widzenia podejścia Lean, każdy z zespołów IT powinien wiedzieć, kto jest jego klientem, jakie są jego potrzeby i oczekiwania, za co jest skłonny zapłacić – czy to żywą gotówką (klient zewnętrzny), czy też wsparciem w uzyskaniu odpowiedniego budżetu (klient wewnętrzny). Ważne jest, aby nie domyślać się, ale zapytać klienta, na czym mu naprawdę zależy, co jest dla niego najważniejsze. A potem jego potrzeby i oczekiwania nazwane w LeanVoC (Voice of Customer) powinniśmy opisać w taki sposób, abyśmy mogli jednoznacznie powiedzieć, czy je spełniamy, czy też nie: wskaźnikami, parametrami, przedziałami poprawności, w LeanCtQ (Critical to Quality).

Dlaczego zapytanie klienta jest ważniejsze niż nasze domysły

W opinii wielu działów odpowiedzialnych za dostarczanie rozwiązań IT, z punktu widzenia klienta najważniejsze są zakres (duży), czas (krótki) i koszt (niski). Tymczasem z mojej praktyki wynika, że te czynniki są istotne, ale jeszcze ważniejsza jest PRZEWIDYWALNOŚĆ dostarczenia rozwiązania. Czyli taki czynnik, który w żadnym znanym mi opracowaniu dotyczącym parametrów „dobrego projektu” nie występuje. Może dlatego, że nikt o niego nie pyta.

Podam przykład. Zmodyfikowano kiedyś dużej firmie proces dostarczania rozwiązań, porządkując go w cztery duże wdrożenia rocznie i jednocześnie przyjmując politykę dzielenia dużych projektów na mniejsze części, tzw. generacje. Z początku ze strony biznesu słychać było wyłącznie sprzeciw: „To straszne, że mamy czekać co najmniej 3 miesiące na wdrożenie”, „Dostaniemy tak mało!”. Po 3-4 wdrożeniach te same osoby zaczęły chwalić, że IT dotrzymuje terminów (mimo że były dłuższe niż deklarowane przed zmianą). A to okazało się istotniejsze niż „krótki czas” (wcześniej często niedotrzymywany), „niższe koszty” (koszt na funkcję systemu był nieco wyższy ze względu na dłuższe testy) czy „duży zakres”. W nowym rozwiązaniu na początek dostarczano najpierw te 20% rozwiązania, które obsługiwało 80% potrzeb. Ale z punktu widzenia odbiorcy dotrzymywanie czasu dostarczenia rozwiązania wspierało cele biznesowe, realizowane przy współpracy z partnerami, czy wzmacnianie kampaniami marketingowymi, gdzie obie aktywności wymagały pewności dostarczenia na czas rozwiązania.

Zidentyfikuj i narysuj strumień wartości

Chcąc usprawnić działanie IT, zacznijmy od tych obszarów, które są najbardziej istotne z punktu widzenia klientów. Skąd będziemy wiedzieć, które to? Możemy oczywiście ich zapytać. Możemy też zerknąć do backlogu błędów czy zmian i zobaczyć, jakich obszarów dotyczą. Również rejestr uwag i reklamacji dotyczących systemów i usług IT powie nam, na czym najbardziej zależy naszym klientom. Mając już wyobrażenia o oczekiwaniach klientów, wybierzmy te obszary (procesy), w których stosunek korzyść do kosztów wprowadzenia będzie jak najlepszy, a czas na ich dostarczenie jak najkrótszy.

Zdobyta w poprzednim kroku wiedza o potrzebach i wartościach klienta pozwoli nam zidentyfikować, co w procesach adresowanych dla danej kategorii odbiorcy warto utrzymać lub wzmocnić, np. dodatkowymi zasobami, automatyzacją czy zbudowaniem serwisu samoobsługowego. Z drugiej strony możemy przyjrzeć się, z czego można zrezygnować, na co położyć mniejszy nacisk, co nie jest warte naszej pracy.

Dla wybranego procesu na początek stwórzmy mapę jego aktualnego stanu. Co ważne, takiego, jaki faktycznie jest teraz, a nie jaki był kiedyś zaplanowany czy jaki „wydaje-nam-się-że-jest”. Opiszmy poszczególne kroki mapy takimi parametrami, jak czas i koszt wykonania, użyte zasoby czy ilość działań możliwych do wykonania w danej jednostce czasu. Nie zapomnijmy o tym, co dzieje się pomiędzy poszczególnymi czynnościami. Ile czasu trwa przekazanie sprawy z jednej czynności do drugiej? Czy musimy przemieszczać jakieś materiały czy półprodukty? Czy sprawa czeka w kolejce i jak długo? Ile spraw może obsłużyć dany zespół w jednostce czasu, a ile do niego trafia? Mapa procesu – opisana takimi parametrami – staje się mapą strumienia wartości. Możemy z niej odczytać, jakie obszary procesu dostarczają wartość z punktu widzenia klienta, a jakie nie. Wtedy możemy zobaczyć, jak wygląda obraz danej usługi IT z perspektywy klienta.

Podejdź do tego działania jak detektyw do morderstwa

Przyglądając się aktualnemu stanowi wybranego procesu, osobiście odwiedź „miejsce zbrodni”. Pójdź tam, gdzie proces jest realizowany. Popatrz, jak jest realizowany. Przesłuchaj świadków – pracowników obsługujących ten proces. Dobra praktyka pokazuje, że bez skorzystania z wiedzy osób, które pracują w danym procesie, nie dowiemy się, jak naprawdę on wygląda. Dlatego nie rozmawiajmy z właścicielami procesów, ale z pracownikami, którzy je obsługują.

W jednym z działów firmy produkcyjno-handlowej zamówienia przyjmowane były za pośrednictwem faksu. Pracownicy pobierali z niego dokumenty, układali je sobie i zajmowali się obsługą tych spraw. Pojawił się pomysł wdrożenia systemu opartego na serwerze faksowym i operowanie na obrazach zamiast papieru. Ze strony klienta w projekcie brał udział – i aktualny proces opisywał – kierownik zespołu obsługującego proces.

Po przystąpieniu do testów dostarczonego rozwiązania okazało się, że zespół, który miał pracować na tym systemie, zdecydowanie nie zgodził się na jego używanie. System nie pozwalał bowiem na porządkowanie obrazów dokumentów w dowolny sposób, a pracownicy układali je różnie, w zależności od typu sprawy. Dzięki temu ich efektywność – a co za tym idzie premia – była większa. Kierownik nie miał świadomości takiego usprawnienia procesu, bo nie pracował w nim od kilku miesięcy. W efekcie konieczna była zmiana założeń, kodu, dodatkowe testy, co spowodowało wydłużenie czasu trwania projektu i kosztów o ok. 30%.

Eliminuj straty

Stworzona mapa strumienia wartości może być prosta lub złożona. Może opisywać procesy, które trwają chwilę lub wiele miesięcy, a bywa, że i lat (np. wdrożenia dużych systemów IT). Analizując ją pod kątem tego, na czym najbardziej zależy klientom danego procesu, które elementy stanowią wartość dodaną, które muszą być – bo niezbędna administracja albo zewnętrzne regulacje tego wymagają – można zaproponować większe lub mniejsze usprawnienia. Możemy zaproponować usunięcie lub zmianę tych obszarów, które są zbyt kosztowne, działają zbyt wolno lub generują zbyt dużo błędów.

Najciekawsze są te pomysły, które nie wymagają zmian w systemach IT, ale np. zmiany percepcji, przyzwyczajeń czy korekty sposobu pracy. Warto przyjrzeć się obszarom, w których „zawsze tak pracujemy i zawsze jest dobrze”. A w szczególności warto przyjrzeć się tym obszarom, w których najwięcej czasu zużywamy na… oczekiwanie.

„IT bardzo wolno robi dostępy do systemów IT dla nowych pracowników” – takie stwierdzenie przez wiele lat padało pod adresem menedżerów działu IT w pewnej firmie. W końcu – przy współpracy z doświadczonym konsultantem – przygotowano mapę strumienia wartości, aby zidentyfikować, które kroki procesu powodują największe opóźnienia. Okazało się, że 95% czasu procesu zajmuje oczekiwanie na dokonanie akceptacji dostępów przez… przełożonego nowego pracownika. Czyli działanie w ogóle poza obszarem IT. Na pytanie, dlaczego konieczna jest taka akceptacja – skoro pracownikowi przyznawane są standardowe dostępy zdefiniowane dla jego stanowiska pracy – padła odpowiedź, że „tak było zawsze”. Dokonanie pierwszej zmiany, polegającej na usunięciu tego kroku, spowodowało, że czas udzielania dostępów skrócił się z ok. 8 dni roboczych do ok. 15 minut…

Zadbaj, aby klient dostał to, czego potrzebuje i wtedy, kiedy tego potrzebuje

Zrozumienie potrzeb klienta powinno dotyczyć nie tylko zakresu,  lecz także chwili, w której te potrzeby muszą być zaspokojone. Opisany na początku przypadek, kiedy cenniejsza okazała się „przewidywalność” niż inne cechy projektu, jest tego przykładem. Warto też przyjrzeć się, czy nie „produkujemy” zbyt dużo, zbyt dokładnie czy zbyt często. W środowisku start-upów nierzadko powtarzane jest twierdzenie, że „produkt nie musi być idealny, musi być wystarczająco dobry”. Podobnie w rzeczywistości biznesowej nie zawsze wszystko musi być „na zaraz”. Czasami wystarczy, aby było w uzgodnionym późniejszym terminie, ale NA PEWNO. W projekcie czasami warto szybciej zrobić prototyp, a później (jak się sprawdzi) wypracować rozwiązanie docelowe.

To, co na pewno warto zrobić – mając mapę strumienia wartości wybranego procesu – to zastanowić się wspólnie z klientem, które kroki procesu nie dają dla niego wartości, które generują produkty w zbyt dużej (lub małej) ilości i w odpowiednim (lub nie) czasie. Taka analiza może pomóc chociażby w dostrojeniu SLA (Service Level Agreement) do potrzeb klienta. Czy każde zgłoszenie, w każdym okresie musi być robione z takim samym czasem realizacji? Może zgłoszenia odblokowania konta w domenie w poniedziałki muszą być wykonane szybciej, a w środku tygodnia mogą być realizowane trochę dłużej? Negocjujmy tego typu sprawy, pokazując, jakie są koszty realizacji serwisów czy procesów. I pamiętajmy, że dla procesów możemy mieć kilku klientów o rozbieżnych oczekiwaniach.

Nie chomikuj zasobów

Niektóre działy IT wykazują się postawą charakterystyczną dla chomików. Mają składziki pełne nowych komputerów, do „szybkiego wydania jak pracownik zamówi”, które to komputery po pół roku są już przestarzałe, a pracownicy chcą nowszych modeli. Wdrożone rozwiązania: (1) utrzymywanie mocno okrojonego magazynu (z 20 do 2 sztuk), (2) szybka ścieżka dostawy sprzętu od dostawcy, w krytycznych przypadkach wiążąca się z wyższym kosztem, (3) uzgodnienie z działem HR, że o planach zatrudnienia więcej niż 5 pracowników miesięcznie informują z ustalonym wyprzedzeniem.

Inny przykład „chomikowania” to utrzymywanie backlogu 250 zmian do systemów IT przy dochodzących co miesiąc 20-30 nowych i możliwości realizacji 15-20 miesięcznie. Wdrożone rozwiązanie: (1) uzgodnienie automatycznego usuwania zmian, które są w backlogu dłużej niż 12 miesięcy, (2) nieprzyjmowanie zmian o priorytecie niższym niż ustalona wartość, (3) przyjmowanie do backlogu tylko takich zgłoszeń, do których wykonania w ciągu kolejnych dwóch miesięcy IT się zobowiązało.

Dążenie do perfekcji

Jedną z głównych idei filozofii Lean jest ciągłe dążenie do perfekcji. Można sobie teoretycznie wyobrazić, że tak długo będziemy usprawniać jakiś proces, że będzie już idealnie perfekcyjny i nie będzie można go w żaden sposób usprawnić. Brzmi kusząco, ale pamiętajmy o jednej ważnej rzeczy. Środowisko, w którym działa proces, się zmienia. Zmieniają się też potrzeby i oczekiwania klientów. Odnosząc się do wcześniejszego przykładu: dzisiaj może nam zależeć głównie na przewidywalności dostarczania rozwiązań IT i pod to usprawnimy nasz proces. Jednak jutro być może ważniejszy będzie koszt realizacji albo czas dostarczenia rozwiązania. I wówczas nasz proces dostarczania nowych rozwiązań może wyglądać zupełnie inaczej.

Nie można też popaść w przesadę i zajmować się tylko doskonaleniem procesów, pomijając dostarczanie wartości przez ich wykonywanie. Znam przypadki organizacji, które tak zagłębiły się w doprowadzaniu działania do perfekcji, że przez kilka miesięcy nie realizowały swoich zadań. Trzeba tutaj zastosowywać coś, co jest różnicą między angielskimi słowami „continuous” i „continual”. Pierwsze pojęcie oznacza „bez przerwy, non stop”. Drugie – „regularnie, z przerwami”. Nie możemy wdrażać jednej zmiany za drugą bez zaobserwowania rzeczywistych skutków pierwszej z nich. Być może od razu da efekty. Ale może będzie wymagać modyfikacji, dostrojenia. A może porzucenia? Na to potrzeba czasu, w trakcie którego trzeba korzystać z danej zmiany i patrzeć, jakie daje wyniki. Wprowadzenie kolejnej, bez jakiegoś przedziału czasu, może np. spowodować zakłócenia, których przyczyn trudno będzie dociec, jeśli naraz wdrożymy kilka modyfikacji.

Wracając do dążenia do perfekcji. Często jest tak, że pierwsze usprawnienia przynoszą najbardziej spektakularne efekty (tzw. efekt nisko wiszących owoców). Było to widać chociażby w opisanej historii z udzielaniem dostępów do systemów IT. Pierwsze usprawnienie skróciło przeciętny czas realizacji procesu o 99%. Kolejnych kilka usprawnień – standaryzacja uprawnień i automatyzacja procesu – spowodowało skrócenie czasu trwania procesu do… 15 sekund. Przejście z 8 dni do 15 minut na pewno robi większe wrażenie niż z 15 minut do 15 sekund. Tym bardziej że to drugie wymagało o wiele więcej działań niż pierwsze. Czy było warto? Właściciel procesu twierdzi, że tak. Bo oprócz oszczędności czasu – Voice of Customer nowego pracownika oraz VoC jego przełożonego – usprawnienia te pozwoliły na wyeliminowanie działania manualnego ludzi w procesie (VoC kierownika zespołu IT) oraz zmniejszenie liczby błędów w procesie, a co za tym idzie – uwag i reklamacji (VoC szefa działu IT). Poza tym pamiętajmy, że jeśli co miesiąc wdrożymy 2% usprawnienia danego aspektu procesu, to po roku mamy proces sprawniejszy o ponad 26% w stosunku do wartości początkowej.

Jak widać na powyższych przykładach, pryncypia IT Lean Management mają bardzo praktyczne zastosowanie w IT. Pomagają lepiej zrozumieć potrzeby klientów, dostosować do ich potrzeb usługi IT, wygenerować konkretne korzyści – oszczędności, większą sprawność, mniej reklamacji – a w końcu zaangażować wszystkie szczeble pracowników, skupiając ich wokół idei regularnego usprawniania działań IT.

Zainteresowanych pogłębieniem tematu – Lean IT Management – zapraszam serdecznie na warsztaty towarzyszące konferencji Let’s Manage IT 2016, której patronem medialnym jest magazyn ITWIZ. W trakcie konferencji będziecie mogli posłuchać m.in. Roba Akershoeka, Solution Architecta w The Open Group, który opowie o IT4IT. A także wziąć udział w warsztatach (roundtable) „Using Lean Value Stream analysis to improve flow, exemplified in case (a server order process)” prowadzonych przez  – Reni Friis z Lean IT Association, organizacji, która zdefiniowała metodykę Lean IT. Reni w trakcie 90-minutowego warsztatu pokaże praktyczne podejście do Lean IT.

Szczegółowy plan konferencji znajdziecie na stronie http://konferencja.letsmanageit.pl

Jarosław Łojewski jest doradcą, coachem i trenerem, zajmuje się wsparciem w rozwoju umiejętności miękkich wśród specjalistów i menedżerów IT. Korzysta m.in. z 10-letniego doświadczenia pracy w roli Business Relationship Managera w międzynarodowej korporacji, w której to odpowiadał m.in. za budowanie relacji i komunikację między IT i częścią biznesową firmy. Przeszedł ścieżkę kariery od programisty do dyrektora departamentu w dziale IT.