Gdy awaria trwa 40 minut, ale produkcja traci dwie godziny

Na raporcie technika awaria trwała 40 minut. W praktyce linia była niedostępna przez prawie dwie godziny. Dlaczego? Operator zauważył problem po kilku minutach. Potem szukał lidera. Lider przekazał informację do utrzymania ruchu. Technik dotarł na stanowisko, ale nie miał pełnego opisu objawów. Po naprawie linia czekała jeszcze na potwierdzenie jakości i ponowne uruchomienie.

Tak powstaje różnica między czasem samej naprawy a realnym wpływem awarii na produkcję. Dlatego MTTR nie powinien być traktowany wyłącznie jako wskaźnik pracy technika. W produkcji seryjnej to sygnał, jak sprawnie organizacja wykrywa problem, przekazuje informację, diagnozuje przyczynę, usuwa awarię i przywraca stanowisko do pracy.

Czym jest MTTR i dlaczego nie warto patrzeć na niego zbyt wąsko?

MTTR najczęściej rozwija się jako Mean Time To Repair, czyli średni czas naprawy. W praktyce utrzymania ruchu oznacza przeciętny czas potrzebny na przywrócenie maszyny, linii lub stanowiska do stanu umożliwiającego dalszą pracę.

W literaturze i normach maintenance podobne wskaźniki są powiązane z pojęciami obsługiwalności, niezawodności, dostępności technicznej oraz czasów przestoju [1][2]. W produkcji seryjnej warto jednak pamiętać, że MTTR może być liczony różnie w zależności od przyjętej definicji.

Najczęstsze podejścia to:

•  czas od zgłoszenia awarii do zakończenia naprawy, 
•  czas od zatrzymania maszyny do ponownego uruchomienia, 
•  czas od przyjęcia zlecenia przez UR do zamknięcia interwencji, 
•  czas od wystąpienia problemu do przywrócenia stabilnej produkcji. 

Każda z tych definicji pokazuje coś innego. Jeśli firma liczy tylko czas pracy technika, może nie widzieć opóźnienia w zgłoszeniu. Jeśli liczy wyłącznie czas postoju maszyny, może nie wiedzieć, ile trwała diagnostyka, oczekiwanie na części lub eskalacja.

Dlatego pierwszym krokiem nie jest samo skracanie MTTR, ale ustalenie, co dokładnie mierzymy.

Jak obliczyć MTTR?

Podstawowy wzór jest prosty:

MTTR = łączny czas napraw / liczba awarii

Przykład:

W ciągu miesiąca dział utrzymania ruchu obsłużył 20 awarii. Łączny czas napraw wyniósł 600 minut.

MTTR = 600 minut / 20 awarii = 30 minut

Na poziomie raportu wygląda to jasno. Problem zaczyna się wtedy, gdy dane są niepełne albo wpisywane ręcznie po zakończeniu zmiany. Wtedy MTTR może bardziej odzwierciedlać jakość raportowania niż rzeczywisty przebieg awarii.

Dlatego przy każdej interwencji warto zapisywać nie tylko czas startu i końca naprawy, ale również:

•  moment wykrycia problemu, 
•  moment zgłoszenia awarii, 
•  czas przekazania informacji do UR, 
•  czas rozpoczęcia diagnostyki, 
•  czas oczekiwania na części lub narzędzia, 
•  czas usunięcia przyczyny, 
•  moment ponownego uruchomienia stanowiska. 

Dopiero taki podział pokazuje, gdzie naprawdę znika czas.

MTTR a OEE: dlaczego średni czas naprawy wpływa na dostępność?

OEE składa się z trzech głównych obszarów: dostępności, wydajności i jakości. MTTR najmocniej wpływa na pierwszy z nich, czyli dostępność. Jeżeli awarie trwają długo albo reakcja na nie jest opóźniona, linia ma mniej czasu na produkcję zgodną z planem.

W podejściu TPM oraz w analizach efektywności produkcji przestoje techniczne są jednym z kluczowych źródeł strat dostępności [3]. To nie znaczy, że każdą awarię da się wyeliminować. Oznacza natomiast, że organizacja powinna wiedzieć, które awarie występują najczęściej, ile trwają i dlaczego ich usunięcie zajmuje tak dużo czasu.

W produkcji seryjnej nawet niewielkie różnice w MTTR mogą mieć duże znaczenie, szczególnie przy awariach powtarzalnych. Jeśli ten sam problem pojawia się kilka razy w tygodniu, a każda interwencja trwa o 10 minut za długo, strata szybko przestaje być marginalna. Może wpływać na realizację planu, nadgodziny, wykorzystanie operatorów i terminowość zamówień.

Dlatego MTTR warto analizować nie jako pojedynczą liczbę, ale w połączeniu z:

•  liczbą awarii, 
•  typem awarii, 
•  stanowiskiem lub linią, 
•  zmianą produkcyjną, 
•  kategorią przyczyny, 
•  dostępnością części, 
•  czasem reakcji utrzymania ruchu. 

Dopiero wtedy wskaźnik zaczyna wspierać decyzje, a nie tylko uzupełniać raport.

Co najczęściej wydłuża MTTR?

W wielu firmach problemem nie jest sama naprawa, ale wszystko, co dzieje się przed nią i wokół niej. Technik może działać sprawnie, ale jeśli informacja dociera za późno lub jest niepełna, cały proces i tak się wydłuża.

Najczęstsze przyczyny wysokiego MTTR to:

•  zbyt późne zgłoszenie awarii, 
•  brak jasnej kategorii problemu, 
•  ręczne przekazywanie informacji przez kilka osób, 
•  brak historii podobnych awarii, 
•  brak procedury diagnostycznej, 
•  szukanie dokumentacji technicznej dopiero przy maszynie, 
•  oczekiwanie na części zamienne, 
•  niejasne zasady eskalacji, 
•  zamykanie zleceń bez opisu przyczyny i rozwiązania. 

Badania dotyczące zarządzania utrzymaniem ruchu i pomiaru efektywności maintenance podkreślają, że same wskaźniki nie wystarczą. Muszą być powiązane z procesem decyzyjnym, dostępnością danych i działaniami doskonalącymi [4].

Inaczej MTTR staje się liczbą, którą raportujemy co miesiąc, ale z której niewiele wynika.

Jak skrócić MTTR bez zwiększania presji na techników?

Skracanie MTTR często bywa błędnie rozumiane jako „technicy mają naprawiać szybciej”. To ryzykowne podejście. Może prowadzić do pośpiechu, pomijania diagnostyki, zamykania zleceń bez opisu i powrotu tej samej awarii po kilku dniach.

Lepszym kierunkiem jest skracanie czasu, który nie wnosi wartości:

•  czasu oczekiwania na zgłoszenie, 
•  czasu szukania właściwej osoby, 
•  czasu przekazywania informacji, 
•  czasu szukania dokumentacji, 
•  czasu odtwarzania historii awarii, 
•  czasu testowania hipotez, które już wcześniej były sprawdzane. 

W praktyce warto zacząć od czterech działań.

Ustal jeden standard zgłoszenia awarii

Operator nie powinien zastanawiać się, do kogo zadzwonić i jak opisać problem. Zgłoszenie powinno być proste, szybkie i powtarzalne: stanowisko, status, kategoria awarii, opcjonalny komentarz.

Im mniej niejasności na starcie, tym szybciej utrzymanie ruchu może rozpocząć właściwą diagnostykę.

Oddziel czas reakcji od czasu naprawy

Jeśli firma mierzy tylko czas od rozpoczęcia naprawy do jej zakończenia, nie widzi opóźnień wcześniejszych. Warto rozdzielić:

•  czas od wystąpienia problemu do zgłoszenia, 
•  czas od zgłoszenia do reakcji, 
•  czas diagnostyki, 
•  czas właściwej naprawy, 
•  czas ponownego uruchomienia. 

Dzięki temu można zobaczyć, czy problemem jest dostępność techników, komunikacja, brak części, brak procedur czy sama złożoność awarii.

Buduj historię zleceń

Jeżeli przy każdej awarii zapisujemy tylko „naprawiono”, kolejna interwencja zaczyna się prawie od zera. Dobrze opisane zlecenie powinno zawierać objawy, sprawdzone hipotezy, przyczynę, wykonane działania i informację, co warto sprawdzić następnym razem.

Koncepcja wykorzystywania doświadczeń z poprzednich działań maintenance jako wsparcia decyzji przy kolejnych interwencjach jest opisywana w literaturze jako experience feedback [5].

Wdrażaj procedury dla powtarzalnych awarii

Nie każda awaria wymaga procedury. Ale jeśli ten sam problem pojawia się regularnie, warto przygotować checklistę diagnostyczną. Dzięki temu nowy lub mniej doświadczony technik nie musi zaczynać od pustej kartki.

Procedura nie zastępuje doświadczenia. Pomaga jednak ustandaryzować pierwsze kroki i ograniczyć ryzyko pominięcia oczywistych przyczyn.

Jak AndonCloud może wspierać analizę i ograniczanie MTTR?

AndonCloud może wspierać pracę nad MTTR w kilku punktach procesu: od zgłoszenia awarii, przez powiadomienie odpowiednich osób, po zapis historii interwencji i późniejszą analizę danych.

Przykład:

Operator zauważa problem na stanowisku i zmienia status na czerwony. Wybiera kategorię „awaria mechaniczna” i dodaje krótki komentarz. System może automatycznie powiadomić właściwe osoby przez przeglądarkę, e-mail, SMS lub telefonicznie. Jeżeli zdarzenie przekroczy ustalony próg czasu, może zostać uruchomiony alert lub ponowienie powiadomienia.

W module CMMS takie zdarzenie może utworzyć zlecenie serwisowe z przypisaną procedurą. Technik otrzymuje nie tylko informację, że wystąpił problem, ale też kontekst: stanowisko, kategorię, czas zgłoszenia, komentarz operatora i ewentualną checklistę diagnostyczną.

Po zakończeniu interwencji zlecenie może zostać uzupełnione o opis przyczyny, wykonane działania i wnioski na przyszłość. Z czasem powstaje baza danych, która pomaga analizować:

•  które awarie mają najwyższy MTTR, 
•  na których stanowiskach najczęściej występują problemy, 
•  czy opóźnienie powstaje przed reakcją, czy podczas naprawy, 
•  które procedury warto dopracować, 
•  gdzie potrzebne są części zamienne, szkolenie lub zmiana prewencji. 

To podejście nie gwarantuje automatycznej redukcji MTTR. Tworzy jednak warunki do tego, aby firma mogła mierzyć problem dokładniej, reagować szybciej i podejmować decyzje na podstawie danych, a nie wyłącznie relacji po fakcie.

Od czego zacząć pracę nad MTTR?

Najlepiej nie zaczynać od całego parku maszynowego. Lepszym punktem startowym jest jedna linia, jedna grupa awarii albo kilka stanowisk o największym wpływie na plan produkcji.

Praktyczna sekwencja może wyglądać tak:

1.  Wybierz 5–10 najczęstszych awarii z ostatnich miesięcy. 
2.  Sprawdź, czy znasz ich rzeczywisty czas zgłoszenia, reakcji i naprawy. 
3.  Oddziel awarie długie od awarii częstych. 
4.  Dla każdej kategorii ustal minimalny standard opisu zlecenia. 
5.  Przygotuj checklistę dla powtarzalnych problemów. 
6.  Ustal progi alertów dla awarii krytycznych. 
7.  Monitoruj MTTR osobno dla linii, kategorii awarii i zmian. 

W wielu firmach pierwsze wnioski pojawiają się szybko. Czasem okazuje się, że technicy nie potrzebują „pracować szybciej”, tylko szybciej dostawać pełną informację. W innym przypadku głównym problemem jest brak części. Jeszcze gdzie indziej — brak historii awarii, przez co każda zmiana rozwiązuje ten sam problem od początku.

MTTR jest wartościowy właśnie dlatego, że zmusza do zadania konkretnych pytań: gdzie zaczyna się opóźnienie, co naprawdę blokuje naprawę i które dane są potrzebne, żeby następnym razem zareagować szybciej.

Podsumowanie

MTTR w produkcji seryjnej nie jest tylko wskaźnikiem utrzymania ruchu. To miara sprawności całego procesu obsługi awarii: od zauważenia problemu, przez zgłoszenie i reakcję, po diagnozę, naprawę i przywrócenie produkcji.

Jeżeli MTTR jest wysoki, nie warto zaczynać od presji na techników. Lepiej sprawdzić, gdzie ginie czas: w komunikacji, braku danych, braku procedur, oczekiwaniu na części czy w powtarzaniu diagnoz, które kiedyś już wykonano.

Cyfrowy Andon i CMMS mogą pomóc uporządkować ten proces. AndonCloud wspiera szybkie zgłaszanie awarii, automatyczne powiadomienia, alerty, zlecenia serwisowe, procedury i raportowanie. Dzięki temu MTTR przestaje być tylko liczbą w raporcie, a staje się praktycznym narzędziem do poprawy dostępności i organizacji pracy utrzymania ruchu.

FAQ

Co to jest MTTR?

MTTR, czyli Mean Time To Repair, oznacza średni czas naprawy. W utrzymaniu ruchu najczęściej odnosi się do przeciętnego czasu potrzebnego na przywrócenie maszyny, linii lub stanowiska do pracy po awarii. Warto jednak jasno ustalić, od którego momentu liczony jest MTTR: od wystąpienia awarii, od zgłoszenia, od przyjęcia zlecenia czy od rozpoczęcia pracy przez technika.

Jak obliczyć MTTR?

Najprostszy wzór to: MTTR = łączny czas napraw / liczba awarii. Jeśli w danym miesiącu łączny czas napraw wyniósł 600 minut, a liczba awarii to 20, MTTR wynosi 30 minut. W praktyce warto doprecyzować, jakie czasy są uwzględniane w obliczeniu, ponieważ inny wynik da czas samej naprawy, a inny czas od zatrzymania linii do jej ponownego uruchomienia.

Czym różni się MTTR od czasu reakcji?

Czas reakcji oznacza, ile czasu mija od zgłoszenia awarii do podjęcia działań przez odpowiednią osobę. MTTR dotyczy zwykle czasu potrzebnego na naprawę lub przywrócenie sprawności. W produkcji seryjnej warto mierzyć oba wskaźniki osobno, ponieważ awaria może być naprawiona szybko, ale reakcja może nastąpić z dużym opóźnieniem.

Jak MTTR wpływa na OEE?

MTTR wpływa przede wszystkim na dostępność, czyli jeden z trzech głównych składników OEE. Im dłużej maszyna pozostaje niedostępna z powodu awarii, tym mniej czasu zostaje na produkcję zgodną z planem. Wysoki MTTR może obniżać OEE, szczególnie wtedy, gdy awarie dotyczą krytycznych stanowisk albo występują często.

Co najczęściej wydłuża MTTR?

MTTR wydłużają nie tylko trudne technicznie awarie. Często problemem jest opóźnione zgłoszenie, niepełna informacja od operatora, brak procedury diagnostycznej, szukanie dokumentacji, oczekiwanie na części lub brak historii wcześniejszych interwencji. Dlatego analiza MTTR powinna obejmować cały proces obsługi awarii, a nie tylko czas pracy technika.

Jak skrócić MTTR w produkcji seryjnej?

Najlepiej zacząć od uporządkowania zgłoszeń awarii, automatyzacji powiadomień, podziału czasu awarii na etapy oraz budowania historii zleceń. Pomocne są też checklisty dla powtarzalnych problemów i jasne progi eskalacji. Celem nie powinno być wyłącznie szybsze naprawianie, ale usuwanie opóźnień, które nie wnoszą wartości.

Czy cyfrowy Andon pomaga obniżyć MTTR?

Cyfrowy Andon może wspierać ograniczanie MTTR, ponieważ skraca drogę zgłoszenia awarii i szybciej przekazuje informację do właściwych osób. Operator nie musi szukać lidera ani przekazywać problemu ustnie. Status stanowiska, kategoria awarii i komentarz mogą od razu trafić do utrzymania ruchu. Efekt zależy jednak od konfiguracji procesu i sposobu pracy zespołu.

Jak AndonCloud wspiera analizę MTTR?

AndonCloud może rejestrować statusy stanowisk, zgłoszenia, powiadomienia, alerty oraz zlecenia serwisowe w module CMMS. Dzięki temu firma może analizować, które awarie występują najczęściej, ile trwa reakcja, ile trwa naprawa i gdzie powstają opóźnienia. Dane te można wykorzystać do poprawy procedur, planowania prewencji i lepszego zarządzania pracą UR.

Czy MTTR wystarczy do oceny utrzymania ruchu?

Nie. MTTR jest ważnym wskaźnikiem, ale nie powinien być analizowany samodzielnie. Warto zestawiać go z liczbą awarii, dostępnością, MTBF, OEE, kategoriami przyczyn, czasem reakcji oraz powtarzalnością problemów. Niski MTTR nie zawsze oznacza dobrą sytuację, jeśli awarii jest bardzo dużo. Dlatego MTTR powinien być częścią szerszego systemu raportowania.

Źródła

[1] EN 13306. Maintenance — Maintenance terminology. European Committee for Standardization.

[2] IEC 60050-192. International Electrotechnical Vocabulary — Part 192: Dependability. International Electrotechnical Commission.

[3] Nakajima, S. (1988). Introduction to TPM: Total Productive Maintenance. Productivity Press.

[4] Muchiri, P., Pintelon, L., Gelders, L., & Martin, H. (2011). Development of maintenance function performance measurement framework and indicators. International Journal of Production Economics, 131(1), 295–302.

[5] Ruiz, P. P., Kamsu-Foguem, B., & Grabot, B. (2014). Generating knowledge in maintenance from Experience Feedback. Knowledge-Based Systems, 68, 4–20.

[6] ISO 22400-2. Automation systems and integration — Key performance indicators for manufacturing operations management — Part 2: Definitions and descriptions. International Organization for Standardization.