Do napisania niniejszego posta zainspirowała mnie książka "Projekt Feniks", autorstwa Gene Kima, Kevina Behra i Georga Spafforda. Jest to fikcyjna opowieść o transformacji funkcji IT, a w efekcie całego przedsiębiorstwa. Boryka się ono z licznymi trudnościami o charakterze biznesowym. Rozwiązaniem przynajmniej części z nich, mogą być usprawnienia narzędzi informatycznych. W punkcie startu do poprawy jest bardzo dużo: brak innowacji, niska sprawność istniejących narzędzi, niedostosowanie ich do wymagań otoczenia, w tym konkurencji. Z tą całą sytuacją musi zmierzyć się Bill Palmer. Do niedawna liniowy menedżer niskiego szczebla. Z dnia na dzień powierzona zostaje mu odpowiedzialność za całą architekturę IT, w tym krytyczny dla istnienia przedsiębiorstwa projekt o kryptonimie Feniks. Czy sobie poradzi? Odsyłam do lektury.
Do "problemów", z którymi zmierzyć się musi Bill, zalicza się Brent. Jest to jedna z kluczowych osób w dziale IT. Do niego zwracają się inni, jeżeli tylko jakiś system przestaje działać, pojawia się błąd, potrzebna jest szybko mała lub większa modyfikacja. Liczba tych próśb kumuluje się do poziomu, w którym Brent nie jest w stanie obsłużyć ich na bieżąco. Dodatkowo, nie ma on czasu na dokumentowanie czy testowanie wdrażanych zmian. O takich "drobiazgach" jak urlop nawet nie ma co wspominać. W efekcie, Brent, czy raczej wszystko co się dzieje wokół niego, staje się tzw. wąskim gardłem.
Lektura wyżej opisanej historii zainspirowała mnie do przemyśleń odnośnie zarządzania działem czy zespołem controllingu. Bardzo taka jednostka jest postrzegana w przedsiębiorstwie jako sprawna, niezwykle efektywna maszyna. Potrzeba na cito złożyć zestawienie dla zarządu - żaden problem. Przygotowanie prognozy w 24h? No pewnie. Automatyzacja raportów i transformacja cyfrowa? Proszę uważać za wykonane panie prezesie / pani prezes. Znamy? Oj znamy. Jeśli tak, to bardzo prawdopodobne jest, że właśnie doświadczamy problemu wąskiego gardła.
Czym jest wąskie gardło? Jest to taki element procesu produkcyjnego, na którym "spiętrza się produkcja w toku". Jeżeli wąskie gardło będzie występować, to przy założeniu, że zadania realizowane w procesie są względnie ustandaryzowane (pod względem długości czasu trwania czy poziomu skomplikowania), to liczba efektów działania procesu na wyjściu będzie zawsze taka sama.
W efekcie, niezależnie od tego, ile zadań (materiałów, problemów) włożymy na wejściu do procesu, liczba efektów tej pracy nie będzie się zmieniać. Za to będzie się zwiększać liczba aktualnie realizowanych zagadnień (czyli produkcja w toku).
Obrazowo problem wąskiego gardła przedstawiono na poniższej grafice.
Jak widać, niezależnie od liczby zadań jakie skierujemy do całego systemu, problematyczny proces D jest w stanie w danej jednostce czasu obsłużyć tylko pewną maksymalną liczbę z nich. W efekcie, tuż przed tym procesem następuje spiętrzenie. Nawet mimo, że proces C trwa dłużej niż A i B, sytuacja nie ma jak się poprawić. Procesy po wąskim gardle nie pracują w pełnej możliwej skali, bo nie otrzymują "surówki do dalszej obróbki" w odpowiednich do możliwości ilości i tempie.
Zarządzenie wąskim gardłem jest jednym z ważniejszych zadań menedżerskich. Zarówno w działach produkcyjnych, jak i wsparcia, takich jak IT czy finanse.
W jaki sposób najczęściej naprawiamy wąskie gardło? Najczęściej dokładamy zasobów. Widzimy, że zespół jako całość "nie wyrabia", ludzie siedzą po nocach, wszystko trwa za długo. Nie stanowi większego problemu aby udowodnić, że potrzeba nam dodatkowych rąk do pracy. Jaki jest tego skutek?
Jeżeli te ręce dołożymy do procesów "przed" wąskim gardłem, to w najlepszym razie zwiększymy ilość produkcji w toku. Kolejka zadań "w realizacji" się wydłuży, natomiast liczba nadgodzin nie spadnie. Możemy być też pewni, że liczba wykonanych zadań na koniec całego procesu nie wzrośnie.
Dołożenie zasobów za wąskim gardłem spowoduje, że np. nowo zatrudnione osoby będą się nudzić. No może na początku nie, bo będą się wdrażać. Ale już za chwilę okaże się, że ich praca jest bez sensu. Osoby te będą wkrótce poszukiwać nowego miejsca pracy, albo po prostu zbijać bąki.
Odrobiwszy ww. lekcje, dokładamy większej staranności, identyfikujemy punkt występowania wąskiego gardła i lokujemy zasoby precyzyjnie w "bolącym miejscu". I co się dzieje? Paradoksalnie, istnieje duża szanse że nic. Nowo zatrudnione osoby siedzą i nudzą się, podobnie jak wcześniej zatrudnieni "za wąskim gardłem". Dodatkowo frustrują się, bo widzą jak ciężko pracują ich starsi koledzy. A ci są tak zajęci, że nie mają czasu na wdrożenie nowych osób.
Okazuje się, że krytycznie ważne jest nie tylko samo znalezienie wąskiego gardła. Druga sprawa, to zrozumienie na czym ono polega. A odkrycie to może być całkowicie zaskakujące. Pamiętam historię z mojego własnego, menedżerskiego doświadczenia, gdy źródłem problemu był stary laptop. Tak - stary laptop, na którym wykonywane było pewne ważne zadanie, wymagające dużej ilości danych i mocy obliczeniowych. Sam proces był skonstruowany wiele lat wcześniej, optymalnie do ówczesnych możliwości (wydajności sieci, możliwości pracy na danych, plikach rozproszonych itp.). Z czasem laptop się zestarzał i nie dawał już rady: w międzyczasie wolumen danych urósł, także wykorzystywane narzędzia (jak system operacyjny), które były aktualizowane zgodnie z politykami, zużywały więcej zasobów komputera niż kiedyś. W efekcie, sprzęt ten przeciętnie na kilka dni w tygodniu był zablokowany przez wykonywane obliczenia. A pracownik czekał na ich wynik, dokonywał poprawek i uruchamiał kolejne etapy procesu, popijając nerwowo kawę. Prosta wymiana laptopa nie była możliwa, bo oznaczałaby brak dostępności do plików i narzędzi przez kilka dni (przynajmniej przy zachowaniu standardowych procedur). A inne problemy to brak zastępowalności pracownika w trakcie urlopu czy brak możliwości przekazania tych zadań większej liczbie osób (w mniemaniu ww. pracownika) tylko do problemu dokładały.
Tym niemniej, po odkryciu i zrozumieniu na czym polega problem, udało się go rozwiązać bardzo szybko. Przedmiotowy proces został przeniesiony na infrastrukturę sieciową i podzielony na etapy. Do jego wykonywania stopniowo wdrażano kolejne osoby, a poszczególne etapy upraszczano. W efekcie, w przeciągu ok. 2 miesięcy to wąskie "gardełko" zostało całkowicie odblokowane.
W dziale controllingu, źródłem wąskich gardeł mogą być:
Utalentowani pracownicy. To jest ciekawy choć nie tak rzadki paradoks. Są to ludzie o bardzo szerokich kompetencjach. Ludzie, którzy rano przygotują business case dla skomplikowanej inicjatywy, a po południu złożą atrakcyjnie wyglądający raport albo napiszą trudne zapytanie do bazy danych. Ich obecność nas uspokaja - możemy wykonywać szerokie spektrum zadań relatywnie tanio i bez konieczności zatrudniania dodatkowych FTE. No żyć nie umierać. Niestety do czasu...
Mniej utalentowani pracownicy, skłonni do tzw. "rzeźbiarstwa". Przekomplikowane modele z multum makr i formuł. Niemożność prostego wytłumaczenia najłatwiejszych procesów. Badanie wydawałoby się oczywistych odchyleń godzinami, czasem po nocach. Wszystko to wynika z relatywnie niskich kompetencji, ale i różnego rodzaju obaw czy lęków. Powstaje myślenie, że jak coś przekombinujemy, to zabezpieczymy swoją pozycję i przyszłość, bo nikt poza nami nie będzie mógł tego zrobić.
Nieplanowana praca. Wrzutki, ad hoc, pilne, super pilne, potrzebuję asap. Dla prezesa, dla właścicieli, dla super ważnego dyrektora. Kiedy to będzie? Dlaczego tego jeszcze nie ma?
Skomplikowana manualna praca. Wyjmij dane, włóż do pivota, przeklej, przefiltruj. Przeklej, zrób pivota. Przefiltruj, przeklej i gotowe! No comment...
Słabe zarządzanie. Tak, niestety. Brak odpowiedniej delegacji, brak komunikacji, nieufność, brak dbałości o rozwój pracowników i wiele innych grzeszków. Bardzo trudne do zdiagnozowania wąskie gardło, bo dotyczy nad. Zbyt dużo bierzemy na siebie, robimy z wiedzy tajemnicę a nie użytek, nie rozmawiamy z pracownikami i interesariuszami. Wreszcie, nie umiemy delegować: ograniczamy się do chaotycznych wrzutek a na rozwój pracowników nie mamy czasu.
Jak szukać wąskiego gardła? Istnieje szereg sposobów. Kluczowe jest, aby nasz wybór pozwolił na:
Uchwycenie wielkości produkcji w toku
Identyfikację miejsca, gdzie ta produkcja w toku się kumuluje.
Dał przesłanki do identyfikacji źródeł problemu.
Jednym z pomysłów może być wykorzystanie w procesie zarządzania działem controllingu tablic Kanban (lub nawiązujących do nich).
Uproszczony przykład takiej tablicy przedstawiłem niżej. Podzielono w nim zadania na 4 grupy. Poszczególne osoby są w nim identyfikowane przy pomocy kolorów. Łatwo można zobaczyć, czy na poziomie jakiejś osoby występuje kumulacja zadań oczekujących/ realizowanych.
Powyższy przykład jest uproszczony. Istnieje szereg narzędzi, które wspierają w podobny sposób proces zarządzania. Ja osobiście korzystam z aplikacji Trello. Ciekawą aplikacją, umożliwiającą kolaborację w obrębie zespołu jest też np. Miro. Wykorzystanie tych aplikacji jak najbardziej mogę polecić na podstawie własnych doświadczeń (nie mam żadnej relacji komercyjnej z producentami / sprzedawcami).
Poniżej "góra" rzeczywistej tablicy Trello, jaką wykorzystuję w pracy w jednym z obszarów.
Poniżej przykładowy Kanban z aplikacji Miro:
No dobrze. To już wiemy gdzie to wąskie gardło jest i na czym polega? To jak sobie z nim poradzić?
Wykorzystywanie narzędzi. Wymienione propozycje narzędzi służą przede wszystkim do zarządzania codzienną pracą. Identyfikacja problemów jest powiedzmy wartością dodaną. Zasadniczo everything that works, is just fine. Jeżeli wolimy korzystać z zadań w kliencie pocztowym, czy mamy flip chart w pokoju gdzie pracujemy (na którym naklejamy kartki post-it w różnych kolorach) - to w porządku. Ważne, aby widzieć strukturę zadań (zlecone, oczekujące, realizowane) i ich przypisanie. A jeszcze ważniejsze, aby na takiej tablicy regularnie pracować całym zespołem.
Ticketowanie. Pewnym pomysłem jest wprowadzenie ticketowania. Ma to sens zwłaszcza w controllingu działającym na zasadzie shared service. Tym niemniej, również w lokalnych zespołach można rozważyć pewną formę ticketowania: opisu zadań i kierowania ich do wspólnego repozytorium. Z tego repozytorium osoby dysponujące wolnym czasem mogą realizować poszczególne zadania. Ważne jednak, że zadania nie wiszą na skrzynkach poszczególnych członków zespołu, tylko są przedmiotem wiedzy wszystkich.
Statusowanie i komunikacja. Krytyczne jest, aby zespół regularnie się spotykał. Na spotkaniach należy omawiać plan działań na najbliższe dni / tygodnie, określać priorytet zadań, przypisywać aktywności do osób i odwrotnie. Przydatnym narzędziem w trakcie takiego spotkania jest właśnie np. tablica Kanban. Dzięki temu, unikniemy sytuacji deklaratywnych ("jesteśmy zarobieni i nic już nie przyjmiemy") tylko obiektywnie zobaczymy ile zadań jest "na tapecie" w danym zespole, gdzie ich realizacja postępuje, a gdzie nie.
Zastępowalność. w swoich zespołach staram się zawsze zapewnić zasadę minimum jednego dublera dla danego zadania. Zwłaszcza jeśli do jego realizacji potrzebne są specyficzne umiejętności lub zasoby (oprogramowanie, dostępy). Dzięki temu, w sytuacji urlopu, zwolnienia lekarskiego czy innej, nieprzewidzianej sytuacji, dane zadanie może być zrealizowane.
Opis zadań / procesów (i regularne ich przeglądy). Aby wszystkie wymienione wyżej pomysły zadziałały, niezbędna jest doskonała znajomość realizowanych przez dział / zespół procesów. W miarę dokładnie powinny być opisane zadania i poziomy odpowiedzialności za nie. Ewentualny dokument powinien wskazywać również zastępstwa, źródła, kontakty. Wagę takiego dokumentu docenimy chociażby przy okazji zmian personalnych (odejść lub zatrudnień).
Zwiększenie zasobów. Oczywiście, rozwiązaniem jest zwiększenie liczby osób / dokupienie narzędzi w punkcie wąskiego gardła. Tym niemniej, przejście wyżej sygnalizowanej ścieżki zdrowia pozwoli na zminimalizowanie ryzyka, gdzie zwiększenie zasobów nie przyniesie żadnego skutku.
Inwestycja w szkolenia i rozwój. W tym nasze umiejętności jako zarządzających.
Reasumując, przedstawiłem pokrótce mój pomysł na poradzenie sobie z problemem wąskich gardeł w dziale controllingu. Mi osobiście temat ten wydaje się niezwykle ciekawym. Stanowi swoiste wyzwanie, które, mam wrażenie, nie zawsze jest uświadomione. Warto jest jednak przyjrzeć się temu problemowi bliżej. Pozwoli to na zwiększenie efektywności działania controllingu w przedsiębiorstwie, zoptymalizowaniu doboru ludzi i narzędzi. Podniesie naszą ocenę wśród interesariuszy. Pozytywnym skutkiem będzie też uniknięcie wielu niepotrzebnych frustracji.
I tym optymistycznym akcentem zakończę niniejszy post, dziękując wszystkim, którzy dotarli do samego końca bo dawno się tu tak nie rozpisałem:)