Lead time (czas realizacji) to czas od momentu zgłoszenia potrzeby - zamówienia, zadania, wniosku - do momentu jej dostarczenia. W Kanbanie: od wejścia zadania do systemu do jego ukończenia. Liczy się z perspektywy klienta: jego nie obchodzi, kiedy zaczęliście pracować, obchodzi go, kiedy dostał wynik.
Analityk używa lead time jako miary sprawności procesu - to jedna z najuczciwszych metryk, jakie istnieją, bo obejmuje także czas leżenia w kolejkach, czekania na decyzje i przerzucania między działami. A właśnie tam, nie w samej pracy, ginie zwykle większość czasu.
W MediFlow zmierzono lead time wdrażania zmian w portalu pacjenta: od zgłoszenia przez kierownika przychodni do działania na produkcji. Mediana: 16 dni. Rozbicie na etapy pokazało rzecz niewygodną - sama praca (analiza, kod, test) zajmowała łącznie 5 dni; pozostałe 11 to czekanie, z czego 9 dni na decyzję rady zmian, która zbierała się raz w tygodniu i często odraczała tematy. Wąskim gardłem nie była technologia, tylko proces decyzyjny. Po wprowadzeniu szybkiej ścieżki dla drobnych zmian mediana spadła do 7 dni - bez zatrudniania kogokolwiek.
Częsta pomyłka: mylenie lead time z cycle time. Cycle time liczy się od ROZPOCZĘCIA pracy nad zadaniem, lead time - od zgłoszenia. Zespół chwalący się cycle time 2 dni przy lead time 30 dni mierzy własną wygodę, nie doświadczenie klienta: zadanie robi się szybko, ale najpierw miesiąc leży w kolejce. Obie metryki są przydatne - pod warunkiem, że wiadomo, którą się patrzy i po co.
Lead time po polsku, czyli jak to nazwać w dokumencie
Lead time po polsku to najczęściej czas realizacji, rzadziej czas przejścia albo czas obsługi zgłoszenia. Żadne z tych tłumaczeń nie jest urzędowe i każde bywa używane na oznaczenie czegoś innego, więc w dokumencie wymagań sama nazwa nie wystarczy.
Zasada, która ucina spory na warsztatach: przy każdym użyciu dopisz, od czego do czego liczysz. Zamiast „czas realizacji: 5 dni" piszemy „czas realizacji: od rejestracji wniosku w systemie do wysłania decyzji do klienta, dni kalendarzowe". Dwa zdania w słowniczku projektu robią tu więcej niż najładniejszy wykres.
Czy „lead time" i „czas realizacji" to na pewno to samo?
Nie zawsze, i jest to problem czysto praktyczny. W dziale zakupów „czas realizacji" oznacza zwykle czas dostawcy: od złożenia zamówienia do przyjęcia towaru na magazyn. W produkcji - od uruchomienia zlecenia do wyrobu gotowego. W zespole IT - od zgłoszenia potrzeby do jej dostarczenia użytkownikowi. Ten sam projekt potrafi używać wszystkich trzech znaczeń równocześnie, bo każdy dział przyniósł swoje. Analityk, który tego nie rozpisze, dostanie na warsztacie trzy różne liczby i wrażenie, że ktoś się myli. Nikt się nie myli, po prostu każdy mierzy własny odcinek.
Skąd wziąć liczbę: dwa znaczniki czasu i nic więcej
Lead time nie wymaga narzędzia ani wdrożenia. Wymaga dwóch znaczników czasu na tej samej sprawie i konsekwencji w ich wybieraniu.
Znacznik początkowy to moment, w którym potrzeba pojawiła się po stronie odbiorcy: data wpływu wniosku, data zgłoszenia w systemie, data e-maila od kierownika. Znacznik końcowy to moment, w którym odbiorca może z rezultatu skorzystać: zmiana działa na produkcji, decyzja wyszła, towar jest na miejscu.
Dalej jest już arytmetyka: odejmujesz, dostajesz liczbę dni na jedną sprawę i powtarzasz to na wszystkich sprawach z wybranego okresu. Porównując lead times kilku procesów, pilnuj, żeby znaczniki były w każdym z nich wybrane tak samo.
Od którego momentu liczy się lead time?
Od zgłoszenia potrzeby przez odbiorcę, nie od chwili, w której zespół zaczął się nią zajmować. Rozróżnienie lead time od cycle time, opisane wyżej w tym haśle, najczęściej rozjeżdża się w narzędziu zgłoszeniowym. W wielu systemach zgłoszeniowych zadanie powstaje dopiero wtedy, gdy ktoś bierze je do pracy - wcześniej potrzeba żyje w mailu, na kartce albo w głowie kierownika. Data utworzenia zadania jest wtedy datą startu pracy, więc licząc od niej dostajesz cycle time i nazywasz go lead time. Wynik wygląda dobrze i nie opisuje niczego, co przeżywa klient. Sprawdzenie zajmuje jedno pytanie do zespołu: kiedy dokładnie powstaje u nas zgłoszenie w systemie?
Dlaczego mediana, a nie średnia?
Bo rozkład czasów realizacji bywa mocno niesymetryczny: większa część spraw mieści się w podobnym przedziale, a kilka ciągnie się tygodniami, bo utknęły na decyzji, na dostępie albo na jednej osobie z urlopem. Średnia daje się przeciągnąć tym ogonem i wychodzi liczba, której nie doświadczyła żadna konkretna sprawa. Mediana mówi, jak było w połowie przypadków, i jest odporna na pojedyncze anomalie. Sprawdź kształt rozkładu na własnych danych, zanim wybierzesz miarę - wystarczy posortować czasy i spojrzeć na dziesięć najdłuższych.
Osobno warto policzyć percentyl 85, czyli czas, w którym zmieściło się 85 spraw na 100. To z tych liczb ta, która najlepiej nadaje się na obietnicę wobec biznesu: „w 85 przypadkach na 100 zamykamy to w 12 dni". Mediana opisuje typowy dzień; percentyl mówi, na co odbiorca może liczyć w praktyce.
Do każdego wyniku dopisz liczbę spraw, na których liczyłeś. Mediana z dziewięciu zgłoszeń jest ciekawostką i tak trzeba ją podpisać; bez liczby spraw odbiorca nie ma jak tego ocenić.
Co psuje pomiar, zanim ktokolwiek spojrzy na wynik
Pięć rzeczy, które w praktyce wykrzywiają lead time i które warto rozstrzygnąć na starcie, zanim padnie pierwszy niewygodny wynik:
| Sytuacja | Pytanie do rozstrzygnięcia | Konsekwencja pominięcia |
|---|---|---|
| Sprawa wróciła po odbiorze (reopen) | Jeden lead time do końca, czy dwa osobne? | Wynik ładniejszy niż rzeczywistość odbiorcy |
| Sprawy porzucone i skasowane | Czy wchodzą do licznika? | W liczniku zostają same sprawy doprowadzone do końca |
| Pozycje leżące w backlogu od zawsze | Czy backlog to już kolejka, czy jeszcze nie? | Mediana wystrzeli albo zniknie, zależnie od decyzji |
| Dni robocze czy kalendarzowe | Które liczysz i czy tak samo w całym okresie? | Klient czeka w kalendarzowych, raport pokazuje robocze |
| Zmiana definicji zgłoszenia w trakcie okresu | Czy porównujesz to samo przed i po? | Trend, który opisuje zmianę definicji, nie zmianę procesu |
Żadne z tych rozstrzygnięć nie jest jedynym słusznym. Błąd, który psuje najwięcej, to zmiana zasady w połowie pomiaru i porównywanie wyników sprzed i po zmianie tak, jakby mierzyły to samo. Zasadę zapisz obok liczby - najlepiej w tym samym miejscu, w którym trzymasz definicje pojęć projektu.
Lead time a SLA: pomiar kontra zobowiązanie
To dwa różne gatunki liczby i mylenie ich kosztuje przy negocjacjach.
Czym różni się lead time od SLA?
Lead time to pomiar tego, co faktycznie się dzieje, także tam, gdzie nikt niczego nie obiecał. SLA to zobowiązanie: umowny czas reakcji i naprawy, z wyłączeniami, oknami serwisowymi i konsekwencjami za przekroczenie. Można mieć lead time bez SLA - tak wygląda zwykle proces wewnętrzny, w którym nikt niczego nie podpisywał. Można też mieć SLA bez pomiaru lead time, i to jest sytuacja, w której obietnica bierze się z sufitu.
Praktyczny wniosek dla analityka: zanim wpiszesz do wymagań konkretny czas obsługi, zmierz obecny lead time. Zobowiązanie ustawione poniżej dzisiejszej mediany jest łamane w ponad połowie spraw od pierwszego dnia obowiązywania umowy i nikt nie będzie pamiętał, że powstało na spotkaniu, na którym nikt nie miał danych. Jeśli danych nie ma, w wymaganiu zapisuje się to wprost jako założenie do zweryfikowania.
Czego lead time nie powie
Uczciwa lista ograniczeń, bo to metryka, którą łatwo przecenić:
- Nie mówi nic o jakości. Szybko dostarczona zmiana, która wraca po odbiorze, poprawia lead time i pogarsza sytuację. Dlatego obok czasu trzyma się miarę powrotów - liczbę spraw wracających po UAT albo liczbę zgłoszonych defektów.
- Nie mówi, czy sprawę warto było robić. Bardzo krótki czas realizacji rzeczy niepotrzebnych to sprawnie działająca maszyna do produkcji odpadu. Tym zajmuje się priorytetyzacja - patrz MoSCoW i WSJF.
- Mediana chowa ogon. Przy medianie 15 dni pojedynczy klient, który czekał 90, pamięta 90. Jeśli rozmawiasz o doświadczeniu klienta, pokaż rozkład albo przynajmniej percentyl i wartość skrajną.
- Nie wskazuje przyczyny. Sama liczba mówi tylko, że jest źle albo dobrze. Przyczynę widać dopiero po rozbiciu czasu na etapy - tak jak w przykładzie opisanym wyżej w tym haśle, gdzie dopiero rozbicie pokazało, że problemem był cykl posiedzeń rady zmian, a nie tempo pracy.
- Nie zastępuje rozmowy. Liczba otwiera rozmowę o procesie i tyle da się z niej wycisnąć bez ludzi, którzy ten proces prowadzą.
Jak używać tej liczby w rozmowie z biznesem
Na spotkanie wystarczy jedno zdanie i jedna decyzja do podjęcia. Zdanie ma budowę stałą:
Od [zdarzenia startowego] do [zdarzenia końcowego] mija u nas mediana X dni, policzona na N sprawach z [okres]. Z tego Y dni to [nazwany etap czekania].
Reszta wynika sama. Jeżeli największy kawałek to czekanie na decyzję, tematem rozmowy staje się tryb podejmowania decyzji. Jeżeli największy kawałek to czekanie na dostęp albo na środowisko, tematem jest kolejka udostępnień. Nazwanie etapu, w którym czas ginie, jest tu ważniejsze od samego wyniku, bo dopiero ono wskazuje, kto może coś z tym zrobić.
Jakie metryki warto pokazać obok lead time?
Trzy, i każda odpowiada na inne pytanie. Przepustowość mówi, ile spraw kończycie w jednostce czasu - bez niej skrócenie czasu może oznaczać po prostu, że robicie mniej. Praca w toku mówi, ile spraw jest otwartych równocześnie; jest to dźwignia, po którą sięga się najwcześniej, bo zależność między pracą w toku, przepustowością a czasem realizacji jest arytmetyczna i opisana przy tamtym haśle. Miara powrotów pilnuje, żeby skrócenie czasu nie odbyło się kosztem jakości. Dopiero te trzy razem opisują przepływ; pojedyncza liczba czasu daje się dowolnie opowiedzieć.
Wizualnie ten sam obraz daje diagram skumulowanego przepływu, na którym rosnące pasmo widać wcześniej niż w tabelce z medianami. Jak zbudować z metryki wskaźnik, który coś znaczy dla zarządu, opisuje osobno wpis Metryki i KPI - jak mierzyć sukces.
Gdzie analityk spotyka lead time w praktyce
W ogłoszeniach o pracę - prawie wcale. W bazie ofert zasilającej Barometr rynku BA było 2 września 2026 roku 291 aktywnych ogłoszeń; przeszukanie tytułów, fragmentów opisów i list umiejętności po rdzeniu lead ?time dało zero trafień. Dla porównania: kanban ma jedno trafienie na 291, BPMN 35, Jira 24. Agregator przechowuje zajawki ofert, nie ich pełną treść, więc to pomiar tego, co trafiło do zajawki. To pomiar języka ogłoszeń, czyli tego, co pracodawca wpisuje jako wymaganie. O tym, czego używa się w codziennej pracy, nie mówi nic: metryki przepływu rzadko trafiają do listy wymagań, częściej do pierwszego zadania po wdrożeniu.
Realnym miejscem spotkania jest tablica zespołu. Lekcja „Kanban dla analityka - przepływ zamiast sprintów" z kursu „Agile i Scrum dla analityka biznesowego" nazywa ten mechanizm wprost: „To jest największy dar Kanbana: uwidacznianie czekania". Zaleca też kolumny odwzorowujące prawdziwy proces „z osobną kolumną dla czekania na decyzje - bo czekanie to stan, nie wstyd". Kolejka przestaje być niewidzialna i widać, czyja jest. Lead time jest liczbową wersją tej samej obserwacji, a Kanban dostarcza do niej narzędzi.
Drugie miejsce to mapowanie procesu. Kiedy zespół robi mapę strumienia wartości albo prostą tabelę SIPOC, czasy poszczególnych kroków są wsadem do dokładnie tego samego rachunku - z tą różnicą, że mapa rozkłada proces na etapy, a lead time podaje ich sumę. W podejściu Lean skracanie tej sumy przez wycinanie czekania jest jednym z podstawowych ruchów, a Kaizen opisuje, jak robić to małymi krokami zamiast jedną reorganizacją.
Powiązane pojęcia
- Kanban - metoda, w której lead time jest podstawową miarą
- Praca w toku (WIP) - dźwignia, która skraca czas bez zwiększania tempa
- Diagram skumulowanego przepływu - ten sam obraz w formie wykresu
- SLA - zobowiązanie umowne, które warto oprzeć na pomiarze
- Mapa strumienia wartości i SIPOC - skąd wziąć czasy etapów
- Lean, Kaizen - kontekst metodyczny skracania czasu
- Definicja ukończenia - bez niej „dostarczone" znaczy co innego dla każdego
Chcesz przećwiczyć to na własnym procesie? Katalog kursów jest na analify.pl/kurs, a materiały do pobrania bez zakładania konta na analify.pl/odkryj.