Odkryj 5 rozdziałów książki już teraz!
15 kroków do zakupu systemu informatycznego
- 5 rozdziałów książki
- podsumowania z najważniejszymi informacjami z obszaru digitalizacji produkcji

Wdrożenie predictive maintenance zacznij od jednej maszyny, której awaria naprawdę kosztuje. Najpierw wybierz zasób, który zatrzymuje linię, generuje straty jakościowe, wymaga drogiego serwisu albo psuje plan produkcji. Potem policz koszt awarii, sprawdź dane i ustal, co zespół ma zrobić po alercie.
Ten tekst jest dla Ciebie, jeśli odpowiadasz za utrzymanie ruchu, produkcję, automatykę albo rozwój zakładu i chcesz przejść od testu do rozwiązania, które działa na hali. Zacznijmy od początku.
Predictive maintenance, czyli predykcyjne utrzymanie ruchu, polega na planowaniu działań serwisowych na podstawie danych o stanie maszyny i ryzyku awarii.
Zamiast wymieniać część co 6 miesięcy albo reagować dopiero po zatrzymaniu linii, obserwujesz sygnały, które mogą pokazywać pogarszający się stan urządzenia. Mogą to być między innymi:
Predictive maintenance możemy też opisać jako utrzymanie oparte na przewidywaniu awarii z danych obserwowanych, takich jak temperatura, hałas czy wibracje. ISO 17359, norma dotycząca monitoringu stanu maszyn, wskazuje też, że dobry program powinien zaczynać się od analizy kosztów, ważności maszyn dla produkcji i trybów awarii.
Na start możesz kierować się zasadą, że predykcja nie zaczyna się od algorytmu, tylko od sprawdzenia, która awaria boli Twój zakład najbardziej i czy da się ją zobaczyć wcześniej w danych.

Najczęściej nie dlatego, że technologia nie działa, a przyczyna jest zazwyczaj prostsza. Pilotaż wygląda dobrze na prezentacji, ale nie zmienia codziennej pracy UR, bo:
Firmy produkcyjne często mają problem z jakością danych, opisem awarii i przełożeniem analizy na działanie. Przeglądy badań dotyczące predictive maintenance potwierdzają też typowe bariery: szum w danych przemysłowych, błędne odczyty, różne warunki pracy maszyn i modele działające tylko dla konkretnego zasobu.
Dlatego celem pierwszego wdrożenia powinna być wcześniejsza decyzja serwisowa, którą zespół rozumie i potrafi wykonać.
Zdobądź bezpłatnie 5 rozdziałów książki!
Dołącz do buletynu i zyskaj dostęp do 40% książki
„15 kroków do zakupu systemu informatycznego”.
Na start nie wybierz jedną maszynę, nie całą linię. Wtedy prościej będzie Ci monitorować efekt.
Najlepszy pierwszy kandydat to urządzenie, które:
Siemens w raporcie The True Cost of Downtime 2024 podaje, że w dużym zakładzie automotive godzina nieplanowanego przestoju może kosztować 2,3 mln dolarów, ale to nie jest liczba do prostego przeniesienia na każdy zakład. Przykład ten dosadnie pokazuje jednak, dlaczego wybór pierwszej maszyny ma większe znaczenie niż wybór technologii.
Pomocna może być prosta tabela.
| Pytanie | Dobry sygnał | Ryzyko |
| Czy awaria zatrzymuje linię? | Tak, postój widać w OEE | Niski wpływ utrudni obronę projektu |
| Czy awaria już się powtarzała? | Są zlecenia UR i raporty zmianowe | Brak historii utrudni ocenę |
| Czy są objawy przed awarią? | Wibracje, temperatura, prąd, ciśnienie | Nagła awaria bez objawów to słaby start |
| Czy UR wie, co sprawdzić? | Jest procedura kontroli | Alert bez reakcji traci sens |
| Czy maszyna często pracuje? | Dane powstają codziennie | Mało pracy to mało danych |
Nie potrzebujesz od razu perfekcyjnego modelu finansowego, wystarczy Ci liczba, która pomoże podjąć decyzję. Uwzględnij:
Przykład
Awaria pompy zatrzymuje linię na 5 godzin. Każda godzina postoju to 18 000 zł utraconej marży. Serwis, części i braki kosztują 12 000 zł.
Koszt jednej awarii:
5 × 18 000 zł + 12 000 zł = 102 000 zł
Jeżeli taka awaria zdarza się 4 razy w roku, roczny koszt wynosi około 408 000 zł.
Wtedy łatwiej ocenić, czy monitoring, integracja danych i praca zespołu mają sens finansowy.
McKinsey podaje, że predictive maintenance może zmniejszyć przestoje maszyn o 30 do 50% i wydłużyć czas życia maszyn o 20 do 40%. U.S. Federal Energy Management Program wskazuje też, że programy PdM mogą dawać 8 do 12% oszczędności względem samego utrzymania prewencyjnego.
Naturalnie, liczby te traktuj jako punkt odniesienia, a nie obietnicę wyniku w każdym zakładzie.
Stwierdzenie, że chcemy przewidywać awarie prasy jest zbyt szerokie. Lepszy cel może brzmieć:
Pomoże Ci to wybrać dane, próg reakcji i osobę odpowiedzialną za sprawdzenie maszyny.
Jeżeli nie potrafisz wskazać trybu awarii, zacznij od warsztatu z UR, automatyką i produkcją. Zespół zwykle szybko wskaże 3 do 5 problemów, które wracają i kosztują najwięcej nerwów.
Zwykle nie trzeba zaczynać od nowych czujników. Część danych już istnieje, tylko jest rozproszona.
Sprawdź:
Sam wykres wibracji bez kontekstu może wprowadzać w błąd. Maszyna inaczej zachowuje się przy rozruchu, zmianie produktu czy pracy stabilnej.
McKinsey zwraca uwagę, że jakość danych jest jedną z barier dla zastosowań AI w produkcji. Dlatego przed modelem trzeba uporządkować podstawy: nazwy maszyn, czasy zdarzeń, przyczyny awarii i sposób zapisu reakcji UR.

Nie każde predykcyjne utrzymanie ruchu wymaga zaawansowanego modelu od pierwszego dnia.
Czasem wystarczy wykrywać trend:
To może dać zespołowi kilka dni albo godzin na reakcję. Często właśnie tyle potrzeba, żeby zamówić część, zaplanować postój i uniknąć naprawy w najgorszym momencie.
Model predykcyjny ma sens wtedy, gdy masz historię danych, oznaczone awarie i powtarzalny wzorzec. Bez tego system może wyglądać dobrze, ale nie pomoże ludziom na zmianie.
To etap, który decyduje o powodzeniu wdrożenia.
Alert powinien jasno mówić Ci:
Przykładowy proces może wyglądać tak:
Ludzie szybciej korzystają z systemu, gdy widzą, że alert prowadzi do konkretnej decyzji, a nie tylko do kolejnego powiadomienia.
Poniżej masz prosty plan, który pomaga nie rozciągać pilotażu bez końca.
| Etap | Co zrobić | Efekt |
| Dni 1 do 15 | Wybierz jedną maszynę i policz koszt awarii | Jasny business case |
| Dni 16 do 30 | Opisz jeden tryb awarii i sprawdź dane | Wiadomo, czego szukać |
| Dni 31 do 50 | Zbierz dane normalnej pracy maszyny | Punkt odniesienia |
| Dni 51 do 70 | Ustaw alert i procedurę reakcji | Zespół wie, co robić |
| Dni 71 do 90 | Oceń wyniki i decyzję o kolejnym kroku | Decyzja: poprawić, rozszerzyć albo zatrzymać |
Po 90 dniach sprawdź, czy:
Predictive maintenance (PdM) nie rozwiąże każdego problemu utrzymania ruchu.
Lepiej zacząć od czegoś innego, gdy:
Wtedy lepszym pierwszym krokiem może być uporządkowanie zleceń UR, analiza przyczyn awarii, monitoring podstawowych parametrów albo zmiana planu przeglądów.

Jeśli chcesz zacząć od uporządkowania danych z maszyn, produkcji i utrzymania ruchu, w explitia chętnie pomożemy Ci zrobić pierwszy krok.
Szczególnie wtedy, gdy masz już dane w PLC, SCADA, MES albo systemie UR, ale zespół nie ma jednego widoku, który pomaga szybko podjąć decyzję.
Wdrożenie predictive maintenance często zaczyna się od potrzeby połączenia danych w taki sposób, żeby UR i produkcja widziały ten sam problem w tym samym czasie.
Zrób mały audyt jednej maszyny. Wybierz zasób, który najbardziej boli produkcję przy awarii. Policz koszt godziny postoju i sprawdź, jakie dane już masz. Potem opisz jeden tryb awarii i reakcję zespołu po alercie.
Jeżeli po tym ćwiczeniu zauważysz rzeczywisty koszt, dostępne dane i jasną decyzję serwisową, masz dobry punkt startu. Wtedy predykcyjne utrzymanie ruchu może być dla Ciebie spokojniejszym sposobem pracy dla UR i produkcji.
Predictive maintenance to utrzymanie ruchu oparte na danych o stanie maszyny i przewidywaniu ryzyka awarii. W odróżnieniu od utrzymania prewencyjnego nie opiera się wyłącznie na czasie lub liczbie cykli, ale na objawach pogarszającego się stanu urządzenia.
Najlepiej zacząć od jednej maszyny o wysokim koszcie awarii. Następnie policz koszt postoju, wybierz jeden tryb awarii, sprawdź dostępne dane, ustaw monitoring lub alert i opisz reakcję zespołu UR.
Nie zawsze. Pierwszy etap może opierać się na monitoringu stanu, trendach i progach alarmowych. AI ma sens wtedy, gdy masz dobrą historię danych, opisane awarie i powtarzalne wzorce.
Pierwszy sensowny etap można zaplanować na około 90 dni. Taki okres wystarcza, żeby wybrać maszynę, sprawdzić dane, ustawić alerty i ocenić, czy projekt ma wartość operacyjną.
Najczęściej: zły wybór maszyny, brak danych o awariach, brak procedury reakcji na alert, zbyt szeroki zakres i mierzenie sukcesu technologią zamiast wpływem na przestoje, koszty i pracę zespołu UR.