Zarządzanie · 4 min czytania

Ten o kosztach, które nie są pracą

Marnotrawstwo w projekcie według Lean: zbędne kroki, nieużywane funkcje i błędy wykryte za późno. Jak mapa strumienia wartości pomaga je znaleźć i usunąć.

Część kosztów w projekcie pochodzi z rzeczy, które nie powinny istnieć. Pytanie tylko, jaka to część?

Zbędne kroki i funkcje, których nikt nie użył. Błędy wykryte za późno, żeby były tanie. Dokumentacja pisana dla spokoju sumienia zamiast dla odbiorcy.

Jak Lean nazywa koszty bez wartości?

Nazywa je wprost: marnotrawstwo. Japońskie muda. Taiichi Ohno opisał w systemie produkcyjnym Toyoty siedem jego rodzajów, od nadprodukcji przez czekanie po poprawianie wad. Lean szuka marnotrawstwa wszędzie: w czasie, w pieniądzu i w wysiłku ludzi, którzy robią rzeczy bez wartości dla klienta.

Mary i Tom Poppendieck przenieśli te kategorie do tworzenia oprogramowania. Ich lista brzmi znajomo w każdym zespole IT:

  • Praca rozpoczęta i niedokończona. Kod, który leży w gałęzi i nikomu nie służy.
  • Dodatkowe funkcje. Zbudowane „na zapas”, nigdy nieużyte.
  • Ponowne uczenie się. Wiedza zgubiona i odkrywana od nowa.
  • Przekazania. Każde przekazanie pracy między osobami gubi część kontekstu.
  • Przełączanie między zadaniami. Każdy powrót do przerwanej pracy kosztuje czas.
  • Opóźnienia. Czekanie na decyzję, dostęp, przegląd.
  • Defekty. Im później wykryte, tym droższe.

O tym, jak łatwo przeoczyć pracę, której nie widać w raportach, pisałem wcześniej.

Jak znaleźć marnotrawstwo w procesie?

Mapą strumienia wartości. Value Stream Mapping rozkłada proces na kroki, od zamówienia do dostarczenia. Przy każdym kroku zadajesz jedno pytanie: czy klient zapłaciłby za to, gdyby wiedział, że to robimy?

Jeśli tak, krok tworzy wartość. Jeśli nie, zostają dwie możliwości. Część kroków jest potrzebna, choć klient by za nie nie zapłacił, na przykład wymogi prawne. Te warto ograniczać. Reszta jest kosztem, który można usunąć.

Koszty, które nie są pracą. Mapa strumienia wartości: przy każdym kroku pytanie, czy klient zapłaciłby za to, gdyby wiedział, że to robimy. Tak: wartość. Nie, ale konieczne, na przykład wymogi prawne: ograniczaj. Nie: usuń. Przykłady marnotrawstwa w IT: niedokończona praca, nieużywane funkcje, przekazania, czekanie, przełączanie zadań, defekty wykryte za późno, dokumentacja bez odbiorcy. Problem rzadko leży w ludziach, częściej w systemie, który kazał im robić rzeczy nadmiarowe.

Mapa zwykle pokazuje, że najwięcej czasu i pieniędzy pochłaniają rzeczy pomiędzy krokami: czekanie, przekazania i poprawki. To, co sprawdziłem przy okazji pytania „po co”, działa także tutaj: zanim zoptymalizujesz krok, zapytaj, czy powinien istnieć.

Co daje usunięcie marnotrawstwa?

Procesy odchudzone z tego, co pożera budżet i czas bez zwrotu. Zespół ma więcej czasu na pracę, za którą klient płaci, a lead time się skraca, choć nikt nie pracuje szybciej.

Jest też drugi efekt. Mapa pokazuje, że problem rzadko leży w ludziach. Leży w systemie, który kazał im robić rzeczy nadmiarowe. W. Edwards Deming powtarzał, że większość problemów jakości wynika z systemu, za który odpowiada kierownictwo. Pisałem o tym we wpisie o stylu zarządzania.

Dlaczego organizacje nie szukają marnotrawstwa?

Bo marnotrawstwo wygląda jak praca. Ludzie są zajęci, raporty powstają, spotkania się odbywają. Nikt nie zapisuje w budżecie pozycji „rzeczy, których nie powinniśmy robić”.

Część organizacji nigdy nie zadaje pytania o wartość dla klienta. I płaci za to każdego miesiąca.

Narzędzie jest narzędziem. Pytanie, co z niego wyciągniesz.

Bibliografia

  1. Ohno, T. (1988). Toyota Production System: Beyond Large-Scale Production. Productivity Press.
  2. Womack, J. P., Jones, D. T. (1996). Lean Thinking: Banish Waste and Create Wealth in Your Corporation. Simon & Schuster.
  3. Poppendieck, M., Poppendieck, T. (2003). Lean Software Development: An Agile Toolkit. Addison-Wesley.
  4. Deming, W. E. (1986). Out of the Crisis. MIT Press.

💬 Dołącz do dyskusji na LinkedIn → Komentuj i podziel się swoim podejściem