Mapowanie strumienia wartości

Historia mapowania strumienia wartości

Początki mapowania strumienia wartości często przypisuje się firmie Toyota Motor Corporation. W tej kwestii nie ma jednak całkowitej pewności. Firma Toyota mogła go przejąć z innych źródeł lub mógł wyrosnąć organicznie ze wspólnych pomysłów w społeczności lean manufacturing. Wczesne wersje diagramów ukazujących przepływ materiałów i informacji można znaleźć już w książce z 1918 roku zatytułowanej „Installing Efficiency Methods” autorstwa Charlesa E. Knoeppela.

W firmie Toyota praktyka ta nosiła nazwę „mapowania przepływu materiałów i informacji” i była wykonywana niemal bez głębszego namysłu. Sukces Toyoty i zastosowanie praktyk lean manufacturing pomogło wypromować mapowanie strumienia wartości jako najlepszą współczesną praktykę dla zespołów biznesowych o wysokiej efektywności w latach 90. XX wieku.

Korzyści z mapowania strumienia wartości

Mapowanie strumienia wartości ma kluczowe znaczenie dla zrównoważonego rozwoju biznesu. Oto dlaczego:

• Zmniejszenie lub wyeliminowanie marnotrawstwa może poprawić wynik finansowy firmy. Jako bonus — zostaje odkryta pierwotna przyczyna i źródło marnotrawstwa.
• Po zidentyfikowaniu nieefektywnych przypadków przekazania zadań w ramach wizualizacji strumienia wartości zespoły mogą świadomie pracować nad swoim postępowaniem, kulturą, komunikacją i współpracą.
• Zespoły odrzucają indywidualne opinie i ustalają priorytety w oparciu o perspektywę klienta.

Wyzwania związane z mapowaniem strumienia wartości

W razie braku ostrożności mapowanie strumienia wartości może samo w sobie stać się marnotrawstwem. Oto jak uniknąć typowych pułapek:

• Wskaźnik LOE (ang. level of effort, poziom nakładów) na przeprowadzenie mapowania strumienia wartości powinien być zrównoważony z potencjalną wartością i oszczędnościami. Od samego początku należy zwracać uwagę na wskaźnik zwrotu z inwestycji.
• W proces mapowania strumienia wartości należy zaangażować osoby doświadczone zarówno z zespołów biznesowych, jak i produkcyjnych, ponieważ proces mapowania może być bardzo złożony i obejmować wiele działów.
• Strach i niepewność są częstymi objawami podczas tej procedury, dlatego proces identyfikacji marnotrawstwa może okazać się intensywny.
• Poprawienie jednego elementu tu czy tam z pewnością przyniesie jakieś oszczędności. Może jednak nie przełożyć się bezpośrednio na poprawę wyniku finansowego, dopóki nie zostanie zakończona pełna analiza. Mimo to warto rozpocząć proces zmian choćby małymi kroczkami.
• Nie należy się spieszyć z korzystaniem z profesjonalnych wykresów, narzędzi i symboli. Najpierw użyj ołówka czy zwykłej tablicy do stworzenia zarysu pomysłu. Mapę sformalizuj dopiero, gdy zostanie odpowiednio dopracowana. Pamiętaj, że starasz się ograniczyć straty, a tworzyć kolejne.

Ogólnie rzecz biorąc, mapowanie strumienia wartości jest dobrą praktyką, ale nie warto z nią przesadzać.

Przypadki użycia mapowania strumienia wartości

Przyjrzyjmy się pokrótce, jak mapowanie strumienia wartości może przynieść korzyści różnym branżom. Domena określa elementy procesu, które zostają odwzorowane na mapie strumienia wartości.

W łańcuchu dostaw mapowanie strumienia wartości może pomóc w wykrywaniu kosztownych opóźnień na drodze do uzyskania gotowego produktu. W produkcji mapowanie strumienia wartości pomaga w identyfikacji marnotrawstwa poprzez analizę każdego etapu obsługi materiałów i przepływu informacji. Elementami procesu uwzględnionymi w strumieniu wartości są materiały.

W branżach usługowych mapowanie strumienia wartości ułatwia efektywną i terminową obsługę klientów zewnętrznych, natomiast w przypadku administracji i urzędów usprawnia obsługę klientów wewnętrznych. W placówkach opieki zdrowotnej umożliwia skuteczne leczenie pacjentów zgodnie z wysokimi standardami opieki. Elementami procesu uwzględnionymi w strumieniu wartości są potrzeby klientów.

Jak mapowanie strumienia wartości pozwala identyfikować i ograniczać marnotrawstwo

Mapowanie strumienia wartości wywodzi się z branży produkcyjnej. W ramach przykładu wyobraźmy sobie, że fabryka samochodów otrzymuje zamówienia na nowe samochody i potrzebuje surowców do ich produkcji. Firma wykorzystuje mapowanie strumienia wartości do nakreślenia kroków wymaganych do wyprodukowania nowego samochodu.

Po zapoznaniu się z etapami produkcji samochodu firma identyfikuje sytuację przekazywania zadań, która zdaje się być niekorzystna. Etap ten wymaga użycia wózka widłowego do przenoszenia surowców z krańca magazynu na linię produkcyjną. Wiąże się to jednak z pewnym ryzykiem i jest czasochłonne. Na podstawie tej obserwacji firma decyduje się na stałe przenieść magazyn surowców bezpośrednio w sąsiedztwo linii produkcyjnej. Umożliwia to zwiększenie wydajności i być może całkowicie eliminuje konieczność używania wózka widłowego.

Lean manufacturing wyróżnia siedem rodzajów powstawania marnotrawstwa.

Nadprodukcja

Nadprodukcja stanowi katalizator wielu innych form marnotrawstwa. Gdy produkt jest wytwarzany w nadmiarze, prowadzi to do dalszego marnotrawstwa z racji takich niepotrzebnych kosztów, jak dodatkowa przestrzeń magazynowa, marnowanie surowców czy kapitał zamrożony w postaci bezużytecznych zapasów.

Zapasy

Marnotrawstwo zapasów stanowi koszt wynikający z przechowywania i utrzymywania nadwyżki zapasów. Obejmuje marnowanie przestrzeni, koszt czynszu za powierzchnię magazynową, koszty transportu oraz straty spowodowane pogorszeniem jakości przechowywanych produktów.

Ruch

Marnotrawstwo ruchu to koszt wszystkich działań wykonywanych przez osoby lub maszyny, które można by ograniczyć do minimum. Wcześniejszy przykład z wózkiem widłowym i lokalizacją zapasów jest doskonałym przykładem marnotrawstwa ruchu i optymalizacji w tym zakresie. Marnotrawstwo ruchu ma wiele uciążliwych skutków ubocznych, w tym zanieczyszczenie środowiska, odpady paliwowe z eksploatacji pojazdów czy koszty napraw i konserwacji.

Defekty

Wypadki się zdarzają i mogą być kosztowne. Zarządzanie stratami wynikającymi z defektów obejmuje działania mające na celu identyfikację oraz łagodzenie skutków wypadków i niedoskonałości, których efektem jest wadliwy produkt końcowy. Defekty są kosztowne, ponieważ wymagają wymiany elementów oraz mogą wiązać się z dodatkowymi kosztami recyklingu lub całkowitą utratą surowców.

Nadmierne przetwarzanie

Marnotrawstwo w postaci nadmiernego przetwarzania odnosi się do każdego etapu elementu wytwórczego, który można uznać za zbędny. Przykłady obejmują dodawanie funkcji, o które użytkownicy nie prosili, czy dopieszczanie obszarów produktu, które mogą być niewidoczne dla użytkownika.

Przestoje

Marnotrawstwo związane z przestojami obejmuje koszt każdego etapu procesu produkcyjnego spowalniającego uzyskanie efektu końcowego. Przestoje niosą za sobą wydatki na oświetlenie, ogrzewanie i chłodzenie, a także ryzyko utraty ważności materiałów, czy też niespełnienia warunków umów.

Transport

Marnotrawstwo w zakresie transportu jest dość podobne do marnotrawstwa ruchu. Dotyczy zewnętrznych działań przewozowych pomiędzy wieloma obiektami lub partnerami zewnętrznymi, podczas gdy marnotrawstwo ruchu obejmuje operacje w ramach jednej lokalizacji.

Producent oprogramowania nie zajmuje się fizycznym przemieszczaniem surowców po magazynach w celu opracowania produktu. Pisanie oprogramowania oznacza przekształcanie pomysłów w rzeczywiste środowiska użytkownika, które stanowią wartość dla klienta.

Mapowanie strumienia wartości w przypadku producenta oprogramowania polega na obserwacji przepływu „danych wejściowych” pochodzących z różnych źródeł, np. informacji z działu wsparcia klienta, wymagań sprzedażowych czy analiz konkurencji, a także dostarczaniu ich jako wartościowych danych wyjściowych do klienta końcowego. Etapy mapowania strumienia wartości w rozwoju oprogramowania dotyczą przede wszystkim komunikacji między zespołami.

Użytkownik zgłasza zapotrzebowanie na daną funkcję, zespoły produktowe ją opracowują, inżynierowie odbierają projekt i tworzą oprogramowanie, które następnie jest dostarczane do użytkownika końcowego. Zarządzanie strumieniem wartości w przypadku oprogramowania może być wykorzystane do identyfikacji punktów marnotrawstwa pomiędzy powyższymi etapami.

Poniżej przedstawiamy listę siedmiu rodzajów marnotrawstwa, które można napotkać podczas tworzenia oprogramowania lub innej pracy twórczej.

Produkt ukończony częściowo

Zdarza się to, gdy oprogramowanie jest wypuszczane w stanie nieskończonym. Może to nastąpić z powodu braku kompletnej specyfikacji lub testów automatycznych. Częściowe ukończenie produktu wywołuje również szereg innych efektów ubocznych, jako że dostarczanie aktualizacji i uzupełnianie brakujących funkcjonalności wymaga dodatkowej pracy.

Nadprogramowe funkcje

Często określa się to mianem „feature creep” — nadprogramowe funkcje stanowią marnotrawstwo z racji wykonywania większej ilości pracy niż jest to konieczne. Nadprogramowe funkcje to cechy produktu niewymagane bezpośrednio przez użytkowników, ale wymyślone przez producenta na podstawie intuicji lub przypuszczeń. Ich wprowadzanie może być owocem szczerych intencji, ale najczęściej wynikają z nieznajomości rzeczywistych potrzeb klienta.

Powielanie czynności

Brak odpowiedniej dokumentacji może skutkować marnotrawstwem w postaci powielania czynności. W przypadku awarii lub przerwy w działaniu oprogramowania najlepszą praktyką jest zbadanie i udokumentowanie powodów zaistnienia danej sytuacji. Jeśli ta pojawi się ponownie, a nie zostanie udokumentowana, konieczne będzie przeprowadzenie kolejnego dochodzenia i procedury naprawczej.

Marnotrawstwo związane z powielaniem czynności pojawia się również wtedy, gdy zespół lub dany pracownik musi się zaznajomić z nową technologią. Trendy technologiczne szybko się pojawiają i równie szybko znikają. Pod wpływem trendów panujących na rynku młodsi programiści mają tendencję do sięgania po najnowsze modele ram postępowania i bibliotek. W efekcie konieczne może się stać ponowne przyuczenie do tworzenia już znanych funkcjonalności w oparciu o nowe ramy postępowania.

Przekazywanie zadań

Marnotrawstwo związane z przekazywaniem zadań pojawia się w przypadku zmiany właścicieli projektu czy rotacji pracowników. Kluczowi członkowie zespołu odchodzą i projekt zostaje przekazany członkowi zespołu bez znajomości kontekstu. To częsty i ciężki do uniknięcia scenariusz. Marnotrawstwo związane z przekazywaniem zadań wynika ze złego zarządzania i zmiany priorytetów członków zespołu już w trakcie działania.

Ta forma marnotrawstwa może również powstać w obrębie pipeline'ów komunikacyjnych. Dlatego, w obrębie zespołu DevOps, zespół programistyczny może się ściślej zintegrować z zespołem operacyjnym, aby zapobiec błędom w komunikacji podczas przekazywania produktu do dalszego etapu. To stanowi przykład zapobiegania marnotrawstwu.

Opóźnienia

Opóźnienia zwykle powstają w przypadku ściśle sprzężonych zależności w ramach projektu. Realizacja może zostać wstrzymana ze względu na zależność od decyzji lub zasobów na wcześniejszym etapie. Chociaż najlepiej jest unikać zależności między tymi zadaniami, to jednak idealne ich rozdzielenie może stanowić nie lada wyzwanie. Opóźnienie w jednym zadaniu może spowodować dalsze opóźnienia w zadaniach zależnych. To prowadzi do lawinowego powstawania problemów. Tworzenie oprogramowania często odbywa się w szybkim tempie, a zadania są rozdzielane pomiędzy członków zespołu.

Zmiana zakresu zadań

Marnotrawstwo dotyczące zmiany zakresu zadań przypomina marnotrawstwo związane z ich przekazywaniem. Przy czym to drugie ma miejsce w przypadku przenoszenia zadań z jednej osoby na drugą, podczas gdy pierwsze dotyczy obowiązków danej jednostki. Zmiana kontekstu umysłowego jest kosztowna. Istnieje pewien mentalny rytm czy też „tryb działania”, który inżynierowie oprogramowania muszą wypracować, aby osiągać optymalne efekty. Sprawnie działające organizacje dbają o samopoczucie i koncentrację umysłową swoich inżynierów. Nieefektywne organizacje bombardują ich nieistotnymi czynnikami rozpraszającymi, np. spotkaniami czy wiadomościami e-mail, które zakłócają ich pracę.

Defekty

Marnotrawstwo związane z defektami ma miejsce, gdy oprogramowanie jest wypuszczane z błędami. To kategoria zbieżna z produktem częściowo ukończonym, choć potencjalnie może generować większe straty — natura defektu w tym przypadku pozostaje nieznana i nie da się jej przewidzieć. Defekty mogą zostać zidentyfikowane przez klientów, a następnie zgłoszone do działu obsługi klienta, co stanowi kosztowne utrudnienie prowadzące do opóźnień i zmian zakresów zadań.

The value stream mapping symbols

Istnieją standardowe symbole opisujące mapowanie strumienia wartości.

1. Określenie rozwiązywanego problemu

Jaki problem rozwiązujesz z punktu widzenia klienta? Czy Twoi klienci mają poczucie, że wprowadzanie nowych funkcji czy ulepszeń w produkcie trwa zbyt długo? Opublikuj opis problemu i zadbaj o to, aby wszyscy zainteresowani się z nim zaznajomili.

2. Powołanie odpowiedniego zespołu

Powołaj doświadczony zespół, który umiejętnie rozwiąże zaistniałe problemy w odpowiednio krótkim czasie. Szefostwo powinno zaplanować wystarczający budżet, aby zapewnić nieprzerwaną realizację.

3. Określenie granic procesu

Po opublikowaniu opisu problemu proporcjonalnie ogranicz zakres mapowania strumienia wartości. Być może nie będzie potrzebne mapowanie całego procesu, a zamiast tego korzystniejsze okaże się skupienie na konkretnym obszarze.

4. Mapowanie ograniczonego procesu

Pamiętaj, aby przeanalizować ograniczony proces. To może mieć istotne znaczenie, ponieważ doświadczenia z pierwszej ręki nie da się zastąpić narracjami (potencjalnie nieobiektywnymi) teoretycznymi ani dokumentacją sporządzoną przez kogoś innego (która może być niekompletna i niedokładna).

Zdefiniuj kroki. Osobiście przeprowadzam analizę mapowania strumienia wartości wielokrotnie. Choć może się to wydawać zbędne, nieraz zdarzyło mi się odnaleźć brakujące elementy dopiero przy drugim podejściu. Kiedy badaliśmy je dalej, podczas trzeciego (i ostatniego) podejścia wychodziło szydło z worka.

5. Zgromadzenie danych procesu

Podczas mapowania strumienia wartości notuj dane procesu w polach danych mapy. Dane procesu obejmują między innymi liczbę zaangażowanych osób, średnią liczbę godzin pracy, czas cyklu, czas oczekiwania, czas działania, czas przestojów itd.

6. Stworzenie osi czasu

Zmapuj czasy opracowania procesu i wdrażania.

7. Ocenienie bieżącej mapy

Wykaż się dociekliwością. Czy Twoje zespoły mają między sobą wiele zależności? Czy czas wdrażania jest zbyt długi? Jeśli tak, czy to dlatego, że zestawy testów nie mogą przebiegać równolegle? Czy dysponujesz stabilnymi środowiskami, czy też obserwujesz sporadyczne wyniki negatywne, których zespoły następnie nie są w stanie odtworzyć?

Mogą też istnieć kroki procesu, które uważasz za wartościowe, ale nie mają żadnego znaczenia dla klienta. Jeśli chodzi o przepływ informacji, zwróć uwagę na pojawiające się w nim zastoje i spowolnienia. Zwróć uwagę, czy przepływ miał charakter przekazywania, czy wyciągania informacji.

8. Zaprojektowanie przyszłej mapy

Możesz nie być w stanie stworzyć pełnej i ostatecznej wersji — i to jest dopuszczalne. Upewnij się, że Twoja nowa mapa jest zgodna z wizją firmy.

Poza tym nic nigdy nie jest przesądzone. Dokonuj ciągłych korekt w oparciu o potrzeby klienta.

9. Wdrożenie przyszłej mapy

Postępuj zgodnie z mapowaniem strumienia wartości i zatwierdzaj zmiany, aby miały większy sens dla klientów. Problem stwierdzony na początku powinien zostać rozwiązany. Regularnie monitoruj wskaźniki KPI i wyciągaj wnioski z trendów. Upewnij się, że wszyscy wiosłują w odpowiednim kierunku — w stronę klienta.

Jeśli chcesz zobaczyć, jak wygląda gotowy produkt, oto przykład mapy strumienia wartości.

The application of value stream mapping to continuous delivery

W dziedzinie tworzenia programowania zarządzanie strumieniem wartości może doprowadzić do ujawnienia przypadków niewydajności od etapu pomysłu po fazę produkcji, włączając w to pętle sprzężenia zwrotnego i przeróbki. Efektem może być ograniczenie liczby wymaganych kroków oraz konieczności dokonywania poprawek. Mapowanie procesu może pomóc w wizualizacji stref przekazywania zadań, co pozwala odkryć, gdzie przestoje powstrzymują przepływ pracy.

Z założenia ciągłe dostarczanie (CD) nie musi wykorzystywać mapowania strumienia wartości. Całkowicie możliwe jest zaprojektowanie i wdrożenie pipeline'u CD bez znajomości mapowania strumienia wartości.

Przy odpowiednim wdrożeniu mapowanie strumienia wartości sprzyja kulturze ciągłego doskonalenia, która sprawdziła się przy tworzeniu oprogramowania i w operacjach. Mapa obrazuje wyniki analizy strumienia wartości, stanowiąc wizualne narzędzie ułatwiające zrozumienie i komunikację.

Dlaczego warto wprowadzić mapowanie strumienia wartości w swoim zespole?

Why bring value stream mapping to your team?

Mapowanie strumienia wartości może mieć zastosowanie w branżach, gdzie potrzebne jest usprawnienie wszystkich funkcji biznesowych. Wizualizacja przekazywania zadań pomaga zoptymalizować przepływ pracy i generować oszczędności. Bez wizualizacji spotkania personelu trwają dłużej, a wymierne efekty są niejasne.

Mapy strumienia wartości potrafią zdziałać cuda w zakresie motywacji do ciągłego doskonalenia. W branży programistycznej ciągłe doskonalenie stanowi trzon paradygmatu ciągłości, w ramach którego pipeline'y ciągłego dostarczania zapewniają klientom produkty w sposób częsty, przewidywalny i trwały. Wydawanie oprogramowania w tym samym tempie, co wymyślanie kolejnego, jest podstawą satysfakcji klienta.

Mapowanie strumienia wartości pomaga również poprawić kulturę zespołu, ponieważ wydajne zespoły są bardziej zaangażowane i przyjemnie się z nimi pracuje. Skoro kultura pracy, produktywność i oszczędności to tylko niektóre z licznych korzyści, to czy mapowanie strumienia wartości nie powinno znaleźć się na szczycie listy priorytetów firmy?

Open DevOps firmy Atlassian zapewnia dostęp do otwartej platformy łańcucha narzędzi umożliwiającej tworzenie pipeline'u programistycznego opartego na CD z wykorzystaniem ulubionych narzędzi. Wykorzystując system Jira jako podstawę, można włączyć mapowanie strumienia wartości na przepływ pracy i procesy.