Straty w Produkcji (Muda)
Toyota definiuje stratę bardzo prosto. To każdy element systemu, za który klient nie chciałby zapłacić. Czyli coś co nie dodaje wartości z jego punktu widzenia. Błędy, czekanie, przewożenie półproduktów z magazynu do magazynu to oczywiste przykłady. Ale dla Toyoty stratą są również nadmierne zapasy półproduktów czy materiałów gotowych, coś co w większości firm będzie traktowane jako aktywa, czyli majątek firmy. Dlatego idealnym rozwiązaniem w Toyocie jest przepływ jednego produktu przez system, co pozwala maksymalnie skrócić czas od zamówienia do otrzymania zapłaty. Taiichi Ohno, twórca Systemu Produkcyjnego Toyoty twierdził, że straty są wszędzie i trzeba tylko przyjrzeć się procesowi produkcji, żeby je znaleźć. Chcąc ułatwić poszukiwanie i usuwanie strat w fabrykach Taiichi wyróżnił siedem rodzajów strat czyli MUDA. Dopiero ich usunięcie daje firmie czas na zajęcie się czymś ważnym z punktu widzenia klienta.
Straty w tworzeniu oprogramowania
Model Ohno był dobrze znany w Ameryce już w latach 90-tych, głównie za sprawą książki „Lean Thinking” Jamesa Womacka i Daniela Jonesa. Jednak dopiero w 2001 roku Mary i Tom Poppendieck w swojej książce „Lean Software Development” przetłumaczyli straty z typowej produkcji na tworzenie oprogramowania. W międzyczasie do siedmiu rodzajów strat Taiichi Ohno doszły trzy nowe straty, związane z pracą umysłową. Poniżej znajdziesz listę dziesięciu strat wraz z ich odpowiednikami dla tworzenia software.
| Strata | w produkcji | w tworzeniu oprogramowania |
|---|---|---|
|
Zapasy |
Praca w toku jest najpoważniejszym rodzaj straty. Zapasy to wszystko, co nie jest ukończonym produktem. |
Wszystko, nad czym rozpoczęto, ale nie ukończono pracy: przeanalizowane, ale niezaimplementowane wymagania, niezintegrowany kod, nieprzetestowane funkcjonalności, niewdrożone rozwiązanie.
Zapasami są elementy, nad którymi odbywa się praca, ale również wszystko co czeka w różnego rodzaju kolejkach, Backlogach, czy dokumentach z wymaganiami. |
|
Nadprodukcja |
Produkty, na które nie ma zamówienia. |
Funkcjonalności, których klient nie potrzebuje lub nie używa |
|
Dodatkowe przetwarzanie |
Zbędne kroki w procesie wytwarzania, niewydajne przetwarzanie z powodu zastosowania nieefektywnego narzędzia. |
Procesy i aktywności, które nie zwiększają wartości produktu z punktu widzenia użytkownika (tzw. goldplating).
Nadmierna dokumentacja.
Ponowne uczenie się. |
|
Transport |
Przenoszenie półproduktów między stanowiskami pracy, lub z i do magazynów. |
Przekazywanie produktu i wiedzy (tzw. hand-off) między pracownikami (np. różnych działów). |
|
Zbędne ruchy |
Niepotrzebne ruchy wykonywane przez pracowników, takie jak podchodzenie po narzędzia, części. |
Wielozadaniowość – próba wykonania kilku zadań jednocześnie.
Powoduje czekanie i ponowne uczenie się. |
|
Czekanie |
Oczekiwanie na narzędzia, części, decyzje. Przechowywanie materiałów. |
Oczekiwanie na informacje, decyzje, zasoby, lub wykonanie pracy przez inny zespół/dział. |
|
Defekty |
Produkcja wadliwych części i ich składowanie, odrzuty oraz koszty napraw, przeróbek, części zamiennych. |
Błędy. Zaburzają rytm pracy i prowadzą do przeciążenia pracowników (Muri). |
|
Myślenie życzeniowe |
Tworzenie planów w oparciu o nierealne żądania, zamiast bazując na informacji zwrotnej i rzeczywistości. |
|
|
Rozproszona informacja |
Wiedza niedostępna osobom, które ją potrzebują. |
|
|
Niewykorzystany potencjał pracowników |
Nieangażowanie pracowników w proces ciągłej poprawy (Kaizen).
Niepodnoszenie oczekiwań w stosunku do pracowników.
Brak rozwoju pracowników. |
|
Możesz również skorzystać z naszej ściągi na temat Nieefektywności i Strat w tworzeniu oprogramowania.
Usuwanie strat to nie wszystko
Wiele firm koncentruje się jedynie na usuwaniu strat zapominając, lub nie wiedząc zarówno o pozostałych nieefektywnościach, jak i zasadach Lean. Powoduje to zbytnie wychudzenie organizacji, wręcz jej anoreksję. Uniemożliwia tym samym szybkie reagowanie na zmieniający się popyt na jej produkty. Jeszcze w gorszej sytuacji są firmy, które próbują usuwać nieefektywności lokalnie (np. tylko w dewelopmencie) nie patrząc na wpływ wprowadzanej zmiany na pozostałe elementy systemu (np. testy). Dlatego Lean, tak jak Agile trzeba wprowadzać całościowo, jako zmianę kultury organizacji, a nie skupiając się jedynie na kilku narzędziach.
