Value-Stream Mapping
Jak identyfikować wąskie gardła i przyśpieszać proces dostarczania
Swego czasu pomagałem w pewnej firmie poprawić procesy dostarczania. Pierwszym krokiem było wykonanie Value Stream Mappingu - zmapowanie procesów dostarczania. Rezultat tak zaskoczył decydentów (wolne czasy dostarczania, liczba błędów), że postanowili coś z tym zrobić.
Poniższy opis sytuacji i proponowanych rozwiązań jest zanonimizowany i zaadaptowany na potrzeby artykułu.
Jednak zanim przejdziemy do techniki i jej zastosowania – omówmy sam problem.
Problemy w firmie
Firma jest dostawcą rozwiązań informatycznych dla sektora transportu publicznego. To system dla klientów komunikacji publicznej, który obejmuje:
Elektroniczną informację pasażerską
System biletowy i kontrolę dostępu
System wspiera codzienne operacje transportowe w miastach.
Struktura IT w firmie obejmuje dwa zespoły deweloperskie (A i B), dział wdrożeniowy, wsparcia klienta, zgodności (compliance) oraz bezpieczeństwa. Każdy z tych zespołów ma swoje priorytety:
Zespoły deweloperskie dążą do szybkiego wprowadzania nowych funkcjonalności.
Dział zgodności pilnuje przestrzegania regulacji dotyczących transportu publicznego i ochrony danych osobowych.
Zespół bezpieczeństwa dba, by chronić wrażliwe dane operacyjne i płatnicze.
Dział wdrażania aplikuje nową wersję systemu na środowiskach klienta.
Wsparcie techniczne obsługuje zgłoszenia od przewoźników i pasażerów.
Gdy firma skontaktowała się ze mną po raz pierwszy, proces dostarczania cechował się niską wydajnością:
Wprowadzenie nowej funkcjonalności trwało miesiącami (np. aktualizacji systemu poboru opłat).
Poprawki, takie jak usprawnienia w systemie informacji pasażerskiej, czekały w kolejce.
Aktualizacje zabezpieczeń systemów były odkładane na coraz to późniejsze terminy.
Frustracja narastała zarówno wśród pracowników, jak i klientów (przewoźników) oczekujących na usprawnienia systemu.
Sytuacja w firmie była charakterystycznym przykładem problemu wąskich gardeł, o którym pisałem w poprzednim newsletterze. Każdy zespół wskazywał na innych jako źródło opóźnień, brakowało całościowego spojrzenia na procesy, a efektywność pracy spadała cały czas.
Dla mnie były to sygnały nie do pomylenia. Firma potrzebowała analizy swoich procesów dostarczania.
Value-Stream Mapping jako narzędzie diagnozy
Value Stream Mapping (VSM) to narzędzie z arsenału Lean Management, które pozwala zobrazować w przystępny sposób cały proces dostarczania. W kontekście systemu, pomoże zrozumieć, jak pomysł na nową funkcję przechodzi drogę od koncepcji do wdrożenia.
VSM składa się z kilku kluczowych elementów:
Ośrodki pracy - miejsca, gdzie faktycznie wykonywana jest praca, np. analiza wymagań, development, testy.
Kolejki - miejsca, gdzie zadania czekają na przetworzenie.
Przepływ informacji - jak informacje przemieszczają się pomiędzy ośrodkami.
Informacje o procesowaniu (lekko dostosowane do produktów cyfrowych):
ZAD – ile zadań czeka w kolejce lub jest procesowanych.
CK – czas kolejki – ile czasu zadanie czeka na podjęcie.
CP – czas procesowania – ile czasu zadanie jest fizycznie przetwarzane.
CD – czas dostarczania – ile czasu mija, zanim zadanie przejdzie przez cały ośrodek.
%POP – stopień poprawności – jaka liczba zadań ma tak istotne defekty, że praca musi wrócić do poprzedniego defektu.
Proces tworzenia VSM wygląda następująco:
Identyfikujemy wszystkie ośrodki pracy w procesie dostarczania.
Określamy kolejki między ośrodkami.
Definiujemy liczbę zadań w każdym ośrodku i kolejce.
Mierzymy czasy pracy w ośrodkach i czasy oczekiwania w kolejkach (średnia, mediana, odchylenia)
Określamy stopień poprawności licząc zadania, które miały dostrzegalne defekty (w pracy nad produktami cyfrowymi drobne defekty i współpraca międzydziałowa jest normalna)
Celem jest określenie efektywności procesu dostarczania. Sumujemy całkowity czas przejścia przez proces (czas dostarczenia) i faktyczny czas pracy (czas procesowania) oraz mnożymy przez stopień defektów.
VSM pomaga zidentyfikować wąskie gardła i straty w następujący sposób:
Wizualizacja procesu – wizualizacja całego procesu co ułatwia dostrzeżenie nieefektywności.
Identyfikacja wąskich gardeł - ośrodki z długimi czasami pracy lub dużymi kolejkami to potencjalne miejsca opóźnień.
Odkrywanie strat - długie czasy oczekiwania i powroty do poprzednich stadiów generują straty.
Analiza proporcji - porównanie czasu faktycznej pracy do całkowitego czasu przejścia pokazuje, ile czasu marnujemy.
Identyfikacja nadmiarowej pracy - zbyt duża liczba zadań w toku (WIP) może pokazywać, że otwieramy tematy, ale ich nie kończymy.
Często okazuje się, że problem wcale nie leży w zespole, którzy wszyscy uznawali za źródło błędów. Na przykład "wąskim gardłem" może być nie zespół deweloperski, a proces zatwierdzania zmian przez dział compliance.
Główne problemy zidentyfikowane przez VSM
Spójrzmy na mapę strumienia wartości:
Podsumowanie pokazuje numerycznie skalę nieefektywności:
Jak można zauważyć, że większość czasu w procesie jest poświęcone na oczekiwanie, a nie faktyczną pracę. Szczególnie wyraźnie dostrzegalne są długie okresy oczekiwania między wsparciem, a działem wdrożenia (14 dni) oraz przed działem zgodności (10 dni).
Jakie problemy zostały uwidocznione?
Brak widoczności całego procesu
Problem: Zespoły nie mają pełnego obrazu procesu dostarczania. Developerzy koncentrują się na swoich zadaniach, nie wiedząc jakie problemy generują. Dział wdrożeń odnotowuje olbrzymie straty, ale jest na końcu łańcucha i niewiele może zrobić.
Skutek: Brak zrozumienia wpływu własnej pracy na kolejne etapy. Zespoły optymalizują lokalne metryki, nie zdając sobie sprawy, że mogą jednocześnie pogarszać sytuację globalnie.
Silosy informacyjne między zespołami
Problem: Każdy pracuje samemu, a następnie przerzuca zadania do innego backlogu. Brakuje miejsca do wspólnej dyskusji i podejmowania decyzji.
Skutek: Informacje nie przepływają płynnie pomiędzy zespołami. Często dochodzi do nieporozumień i powielania pracy. Brakuje spójnego źródła prawdy o stanie wdrożenia.
Nadmiar pracy w toku (WIP)
Problem: W systemie jest bardzo dużo równolegle realizowanych zadań. Każdy zespół stara się być "zajęty", rozpoczynając nowe prace.
Skutek: Wydłużenie czasu dostarczenia pojedynczej funkcjonalności. Zwiększona złożoność zarządzania projektem. Częste zmienianie kontekstu przez pracowników obniża efektywność.
Długie czasy oczekiwania między etapami
Problem: Pracy brakuje płynności, jeden zespół kończy, a drugi przejmuje pałeczkę po 2 tygodniach. Uwidacznia się to szczególnie w momencie przejścia między zespołem wsparcia a działem wdrożeń.
Skutek: Wydłużenie się całkowitego czasu dostarczenia. Utrata kontekstu między etapami. Frustracja klientów czekających na nowe funkcje.
Dużo zwrotek do poprzednich zespołów
Problem: Procesy przeglądów compliance i bezpieczeństwa ujawniają problemy, które wymuszają cofnięcie całej funkcji do poprzedniego stadium. Dodatkowo, wsparcie techniczne często potrzebuje dodatkowej dokumentacji, czym muszą zająć się developerzy, którzy dawno skończyli pracę nad danym zadaniem.
Skutek: Znaczące wydłużenie się czasu dostarczenia funkcjonalności. Zespoły muszą wracać do zadań uznanych za zakończone, co rodzi frustrację. Zaburza to planowanie i priorytetyzację bieżących prac.
Błędogenny proces wdrażania
Problem: Proces wdrażania jest pełen niedociągnięć. Chociaż różni klienci pracują na odmiennych środowiskach, to te różnice nie są odpowiednio testowane przed wdrożeniem. W efekcie dział wdrożeń często musi radzić sobie nieoczekiwanymi problemami u klienta. Oprócz straty czasu, rodzi to konieczność wprowadzania kolejnych zmian w dokumentacji.
Skutek: Częste błędy podczas wdrożeń. Niezadowolenie klientów. Konieczność awaryjnych poprawek, które dodatkowo obciążają zespoły developerskie i zaburzają harmonogram prac.
Zidentyfikowaliśmy 6 głównych problemów, to już sukces! Ale co je powoduje?
Powody problemów
Analiza VSM pokazała nie tylko problemy w procesie dostarczania, ale również pomogła zidentyfikować ich źródła. Co stało za wcześniej opisanymi trudnościami:
Niejasne wymagania compliance i bezpieczeństwa
Problem polegał na braku jasno zdefiniowanych wymagań dotyczących zgodności i bezpieczeństwa na wczesnych etapach procesu. W rezultacie:
Praca była często zawracana do zespołów deweloperskich już po ukończeniu.
Developerzy tracili czas na implementację funkcji, które fjnalnie okazywały się niezgodne z wymogami.
Konieczność wielokrotnego wracania do tego samego zadania rodziła frustrację w zespołach.O podobnej sytuacji pisałem w artykule o celach i możliwościach - bez jasno określonych celów, trudno o efektywne działanie.
Brak automatyzacji w testach bezpieczeństwa
Ten problem jest ściśle powiązany z poprzednim. Brak stabilnych, jasno zdefiniowanych wymagań bezpieczeństwa uniemożliwiał skuteczną automatyzację testów. W efekcie:
Testy bezpieczeństwa były czasochłonne i wykonywane manualnie.
Proces testowania stał się wąskim gardłem, wydłużając i tak skomplikowany czas dostarczenia.
Wsparcie techniczne niezrozumiałe dla developerów
Istniała luka komunikacyjna między zespołem wsparcia technicznego a developerami:
Developerzy nie rozumieli w pełni potrzeb wsparcia technicznego, bo nie pracowali z nimi na co dzień.
W rezultacie, produkowana dokumentacja i opisy procesów były niewystarczające lub nieadekwatne.
Problemy, które powinny być rozwiązane na wczesnym etapie, wracały do developerów znacznie później, gdy kontekst pracy był już zapomniany.
Ta sytuacja przypomina problem, o którym wspominałem w newsletterze o pracy w małych partiach - brak płynnej komunikacji prowadzi do konieczności przerabiania dużych partii pracy.
Brak informacji o środowiskach testowych
Ostatnim, choć nie najmniej ważnym problemem był brak odpowiednich środowisk testowych odzwierciedlających rzeczywiste warunki u klientów:
Testy były przeprowadzane dopiero na końcu procesu, podczas instalacji u klienta.
Prowadziło to do wykrywania błędów na bardzo późnym etapie.
Konieczność powrotu do fazy implementacji na tym etapie była kosztowna i czasochłonna.
To klasyczny przykład problemu "shift left" w testowaniu, o którym wspominałem w kontekście wdrażania jakości od początku procesu.
Identyfikacja przyczyn tych problemów była krokiem w kierunku optymalizacji procesu dostarczania.
Zaproponowane rozwiązania
Po zidentyfikowaniu powodów problemów, zespół zaproponował szereg rozwiązań.
Oto kluczowe propozycje:
Ustalenie standardów pracy
Naszym celem było ustalenie jakich wymagań compliance, bezpieczeństwa oraz opisu dokumentacji potrzebujemy.
1. Określenie kluczowych aspektów do uwzględnienia w standardach:
Regulacje branżowe dotyczące transportu publicznego
Wymagania GDPR i inne przepisy o ochronie danych
Standardy bezpieczeństwa dla systemów płatności
2. Ustalenie zasad kontaktu z działem wsparcia:
Na etapie planowania nowych funkcjonalności
Przy wprowadzaniu zmian w krytycznych obszarach systemu
W przypadku wątpliwości dotyczących zgodności z regulacjami
Większy zakres współpracy na początkowym etapie
Skupiliśmy się na stworzeniu modelu pracy, który pozwoliłby wyłapywać większość problemów na początku.
1. Wprowadzenie sesji Risk Stormingu w celu wczesnej identyfikacji potencjalnych problemów:
Organizacja warsztatów z udziałem uczestników różnych zespołów
Identyfikacja potencjalnych obszarów ryzyka na wczesnym etapie projektu
2. Włączenie wymogów dokumentacyjnych jako integralnej części procesu:
Włączenie zespołu wsparcia technicznego w proces planowania
Definiowanie wymagań dokumentacyjnych przed rozpoczęciem prac
3. Określenie metod działania pomiędzy zespołami:
Spotkania kick-off z udziałem wszystkich zespołów
Regularne przeglądy międzydziałowe w celu definiowania wąskich gardeł
Automatyzacja procesów
Po przejściu przez etap standardyzacji pracy można przynajmniej jej część zautomatyzować:
1. Automatyzacja procesów bezpieczeństwa, compliance i standardów dokumentacji:
Wdrożenie narzędzi do automatycznej analizy kodu pod kątem bezpieczeństwa
Automatyczne sprawdzanie zgodności z wymogami compliance
Generowanie szablonów dokumentacji na podstawie kodu
2. Stworzenie środowisk testowych opartych o parametry klientów:
Automatyczne tworzenie środowisk testowych odzwierciedlających konfiguracje klientów
Ciągłe testy integracyjne na różnych konfiguracjach
Zrównoleglanie pracy
Wejście na wyższy poziom współpracy pozwala wielu zespołom na jednoczesne działanie w jednym obszarze.
1. Wprowadzenie równoległej pracy developerskiej oraz przeprowadzanie testów funkcjonalnych, bezpieczeństwa i zgodności:
Zespoły pracują jednocześnie, wymieniając się informacjami na bieżąco.
Każdy jest w tym samym kontekście projektowym.
2. Wdrożenie podejścia "Project SQUAD":
Tworzenie interdyscyplinarnych zespołów odpowiedzialnych za całość projektu.
Częste sychronizacje międzyzespołowe.
Odpowiedzialność za rezultat wdrożenia.
Wprowadzenie limitów WIP
Aby mieć przestrzeń na wszystko, co powyższe, skupiliśmy się nad tym by nie brać na siebie zbyt wielu tematów naraz.
1. Ograniczenie liczby równoległych projektów:
Nie więcej niż 5 otwartych dużych tematów równocześnie.
W przypadku tematów priorytetowych ustalenie, na jaki kompromis idziemy z obecnymi wdrożeniami.
2. Wdrożenie narzędzi do wizualizacji i zarządzania WIP:
Wizualizacja na tablicy Kanban w Jirze pokazująca tematy pomiędzyzespołowe.
Wdrażanie zmian
Jak to mówi Szymon Górnik:
Zastanów się czy rozwiązaniem będzie #DŻEMOR - czyli namacalne [do spróbowania] efekty pracy z nisko wiszących owoców.
Chcemy osiągnąć rezultaty na tyle szybko, by zarazić zmianami kolejne osoby.
Rozwiązania w skali krótko- i długoterminowej
Możemy więc rozwiązania przedstawić na osi krótko - długoterminowe. Te, które rozpoczynamy od razu, dają szybszy rezultat. Zagadnienia bardziej strategiczne, chociaż są kosztowne, to dają większy zwrot z inwestycji.
Docelowy proces działania
Na podstawie wprowadzonych zmian i usprawnień, docelowy proces pracy wyglądałby tak:
Interdyscyplinarny zespół projektowy – definiuje kluczowe wymagania do implementacji i weryfikacji.
Równoległa praca dwóch zespołów developerskich - zmniejsza liczbę niespójności i ogranicza liczbę zadań, dba o odpowiednią dokumentację procesów pomiędzy obszarami.
Równoległe testy działów zgodności, bezpieczeństwa i wdrożeń – z wykorzystaniem środowisk testowych.
Równoległe wdrożenie i szkolenie pracowników – z wykorzystaniem materiałów z poprzednich faz.
Taki model pracy zapewni:
Ograniczenie zwrotek przez wcześniejsze zaadresowanie największych problemów.
Dopasowanie tempa pracy działów do całkowitej wydajności procesu.
Zmniejszenie kosztu kognitywnego przez skupienie się na mniejszej liczbie zadań.
Szybsze reagowanie przez bycie w tym samym miejscu i pracy nad tym samym projektem.
Mierzenie efektów
Wdrożenie zmian o takiej skali nie jest zadaniem na tydzień czy dwa. To praca trwająca miesiącami, a może nawet latami. Celem jest, aby stopniowo poprawiać wskaźniki ilościowe:
Zmniejszyć liczbę otwartych zadań.
Skrócić czasy dostarczenia.Zmniejszyć odsetek błędów.
Jak i jakościowe:
Złagodzić napięcia pomiędzy działami.
Zredukować koszty context-switchingu.
Wzmocnić poczucie dowożenia wartości (w przeciwieństwie do przerzucania tasków z backloga do backloga.)
Niekiedy wskaźniki ilościowe będą rosły wolniej, ale to reakcje pracowników same pokażą, że jakościowo praca idzie o wiele lepiej. Tutaj można zrobić nawiązanie do podejścia SPACE.
Podsumowanie
Celem dzisiejszego tekstu było przedstawienie Ci w jaki sposób za pomocą VSM możesz:
Zobrazować cały proces dostarczania wraz z faktycznymi czasami pracy.
Przeanalizować co idzie nie tak oraz dlaczego tak się dzieje.
Określić potencjalne rozwiązania, które mają za zadanie przyśpieszyć dostarczanie.
Zmapować docelowy proces i proces dojścia do niego.
Zdefiniować pożądane obserwowalne rezultaty.
Jeśli interesuje Cię ten temat to zerknij na inne materiały, które mogą Ci pomóc:
Narzędzia pracy konsultanta – Value-Stream Mapping - https://radekmaziarka.pl/2020/05/29/narzedzia-pracy-konsultanta-value-stream-mapping/
Dlaczego tak wolno dowozimy - o kolejkach - https://radekmaziarka.pl/2022/05/29/dlaczego-tak-wolno-dowozimy-o-kolejkach/
Miro – Szablon VSM - https://miro.com/app/board/o9J_kkKxXac=/
Miro – Przykład VSM i materiały dodatkowe - https://miro.com/app/board/uXjVO8PNp4E=/
I książki:
“Value Stream Mapping” - https://www.amazon.com/Value-Stream-Mapping-Organizational-Transformation/dp/0071828915
“Flow Engineering” - https://www.amazon.com/gp/product/1950508455/