Maszyna ruszyła. Czy wiedza po naprawie została w zakładzie?

Wyobraźmy sobie taką sytuację. Maszyna staje. Technik sprawdza kilka rzeczy, rozpoznaje problem i przywraca pracę. W zgłoszeniu zostaje: „Usunięto usterkę. Urządzenie sprawne”.

Produkcja rusza. Zgłoszenie można zamknąć.

Tylko czy na podstawie tego zapisu następna zmiana będzie wiedziała, co sprawdzić, gdy objaw wróci?

To od tego pytania zacząłbym rozmowę o AI w utrzymaniu ruchu.

MASZYNA RUSZYŁA · CZY WIEDZA ZOSTAŁA? · AI W UTRZYMANIU RUCHU

Co zwróciło moją uwagę w przypadku Rockwella

W artykule Dennisa Scimeki opublikowanym w IndustryWeek 24 września 2026 r. Rockwell Automation podaje, że w zakładzie w Singapurze średni czas naprawy (MTTR) spadł z 18 do 12 minut. Opisany asystent AI korzysta z danych procesowych, historii usterek, instrukcji 394 urządzeń oraz wiedzy, którą spisano wspólnie z technikami. Źródło: IndustryWeek.

To deklaracja firmy przytoczona w publikacji. Artykuł nie przedstawia niezależnej weryfikacji ani szczegółowych okresów porównania. Traktuję ten wynik jako punkt wyjścia do pytań o własny proces, a nie obietnicę dla każdego zakładu.

Mnie najbardziej interesuje tutaj spisana wiedza techników. Dalej przedstawiam własną propozycję podejścia do pilotażu — nie opis wdrożenia Rockwella.

01 Zapisz wiedzę, z której skorzysta następna zmiana

Samo stwierdzenie „wymieniono czujnik” byłoby dla mnie niewystarczające. Chciałbym wiedzieć, jaki objaw skierował technika właśnie do tego elementu. Co sprawdził wcześniej? Które podejrzenia odrzucił? Jaki test potwierdził, że problem został usunięty?

W mojej propozycji zapis zdarzenia odpowiadałby na sześć pytań:

• Co się działo? Objaw, alarm i wpływ na pracę urządzenia.
• W jakich warunkach? Wariant produktu, ustawienia, faza cyklu i ostatnie zmiany.
• Co sprawdzono? Kolejność kontroli oraz ich wyniki.
• Co ustalono? Przyczyna potwierdzona albo hipoteza, która nadal wymaga sprawdzenia.
• Co wykonano? Konkretne działanie i wykorzystane części.
• Jak sprawdzono efekt? Próba po naprawie i późniejsza obserwacja, czy objaw powrócił.

Nie oczekiwałbym eseju po każdym postoju. Zacząłbym od krótkiego formularza dla wybranej grupy usterek. Jego jakość oceniłbym prostym testem: czy inny technik potrafi zrozumieć tok diagnozy bez telefonowania do autora?

02 Powiąż każdą podpowiedź AI ze źródłem

W pierwszym pilotażu oczekiwałbym pomocy w dotarciu do sprawdzonych informacji. Technik opisuje objaw, a system wskazuje podobne zdarzenia, właściwą dokumentację i czynności, które wcześniej wykonano.

Każda podpowiedź powinna prowadzić do konkretnego źródła: zgłoszenia, zatwierdzonej instrukcji albo potwierdzonej notatki. Chciałbym też widzieć, do jakiej maszyny i konfiguracji odnosi się dany zapis.

Jeśli informacji brakuje, oczekiwałbym jasnego komunikatu o braku podstaw do odpowiedzi. Podpowiedź AI traktowałbym jako materiał do oceny przez uprawnionego technika, z zachowaniem obowiązujących procedur bezpieczeństwa.

AI mogłaby również przygotowywać robocze podsumowanie naprawy. Technik sprawdzałby je i zatwierdzał. Osobno oznaczałbym hipotezę, wykonaną czynność i potwierdzoną przyczynę. W ten sposób chciałbym ograniczyć ryzyko, że przypuszczenie z jednego zgłoszenia zacznie funkcjonować jako gotowa odpowiedź przy następnej awarii.

03 Sprawdź, na którym etapie odzyskujesz czas

Chciałbym ustalić, w której części obsługi awarii pojawia się poprawa. Dlatego zapisywałbym osobno czas zgłoszenia, rozpoczęcia diagnozy, ustalenia przyczyny, zakończenia naprawy i dopuszczenia maszyny do pracy.

Osobno uzgodniłbym definicję MTTR i całego czasu postoju. Nie zakładałbym, że zakład liczy je tak samo. Wcześniejsza diagnoza, szybsza naprawa i wcześniejsze dopuszczenie do produkcji to trzy różne wyniki, które chcę umieć rozróżnić.

Do tego dodałbym czas oczekiwania na części lub wsparcie oraz informację o nawrocie tej samej usterki w uzgodnionym okresie.

Przed porównaniem wyników ustaliłbym wspólną definicję początku i końca pomiaru. Porównywałbym podobne rodzaje usterek i pokazał liczbę zdarzeń w obu grupach. Sprawdziłbym też, czy jednocześnie zmieniły się obsada, dostępność części albo zakres przeglądów. Bez tego nie przypisywałbym całej różnicy asystentowi AI.

04 Przeprowadź pilotaż i podejmij decyzję na podstawie wyników

Wybrałbym jedną grupę urządzeń i powtarzający się problem, dla którego mamy dokumentację oraz ludzi mogących ocenić poprawność podpowiedzi.

Najpierw przejrzałbym z technikami wcześniejsze zgłoszenia. Uzupełniłbym luki tam, gdzie da się je rzetelnie odtworzyć. Wskazałbym osobę odpowiedzialną za zatwierdzanie i aktualizowanie wiedzy.

Następnie sprawdziłbym system na znanych przypadkach. Czy odnajduje właściwe informacje? Czy wskazuje źródła? Czy potrafi przyznać, że podobieństwo objawów nie wystarcza do ustalenia przyczyny?

Dopiero potem uruchomiłbym użycie przy bieżących zgłoszeniach. Przed startem ustaliłbym z zespołem, jakie wyniki uzasadnią kontynuację. Oceniałbym czas diagnozy, użyteczność odpowiedzi, liczbę błędnych podpowiedzi oraz nakład pracy potrzebny do utrzymania bazy.

05 Wróć do przyczyny na odprawie

Na odprawie interesowałoby mnie nie tylko to, że urządzenie znów działa. Zapytałbym również: czego dowiedzieliśmy się o przyczynie? Co zmienimy, żeby ograniczyć powtórkę? Kto sprawdzi efekt i kiedy?

Tak chciałbym wykorzystywać LEAI — połączenie Lean i AI. Ułatwiać dostęp do wiedzy, a następnie wykorzystywać ją do sprawdzania przyczyn i doskonalenia procesu.

Przed zakupem asystenta AI zrobiłbym jeden prosty test. Wybrałbym kilka ostatnich napraw i poprosił technika z innej zmiany, żeby na podstawie zapisów wyjaśnił, co się wydarzyło i dlaczego podjęto dane działanie.

Tam, gdzie musimy dopowiadać historię z pamięci, zacząłbym pracę nad bazą wiedzy.

Na wspólnym przeglądzie wybrałbym jedno zgłoszenie i sprawdził sześć pól z karty naprawy. Potem ustaliłbym właściciela brakujących informacji oraz termin ich uzupełnienia. Od takiego zadania można zacząć przygotowanie do pilotażu.