Od usterki do naprawy: Przekształcanie wykrytego przestoju w zamknięte zlecenie robocze

Najważniejsze wnioski

• Fault-to-fix to zamknięta pętla od momentu zatrzymania maszyny do chwili, gdy zweryfikowane zlecenie naprawy zamyka problem. Większość zakładów ma oba końce (dane o przestojach i CMMS), ale nie ma nic automatycznego, co by je łączyło.
• Pętla zwykle przerywa się przy przekazaniu: przestój jest zarejestrowany, ale ktoś musi to zauważyć, zdecydować, że ma znaczenie, zgadnąć przyczynę i ręcznie otworzyć zlecenie robocze. To opóźnienie jest miejscem, w którym ukrywają się powtarzające się awarie.
• Zautomatyzowana pętla wykrywa przestój, ustala prawdziwą przyczynę i wysyła zlecenie robocze z dołączonym kontekstem, dzięki czemu technik przybywa wiedząc, co się stało, zamiast zaczynać od pustego zgłoszenia.
• Trudne nie jest samo powiadomienie, lecz ustalenie przyczyny. Pętla, która wyzwala ogólny komunikat „line down”, wciąż zostawia diagnozę człowiekowi; wartość pochodzi z przypisania dokładnej przyczyny do każdego przestoju.

Co właściwie oznacza fault-to-fix

Fault-to-fix opisuje pełną ścieżkę, którą przechodzi pojedyncze zdarzenie przestoju: wykrycie, diagnoza, wysłanie zlecenia, naprawa i weryfikacja. W sprawnej pętli każdy etap przekazuje czyste dane do następnego bez konieczności ich ponownego wprowadzania. W większości zakładów ścieżka jest podzielona między odłączone systemy, a luki między nimi wypełniają ludzie pamiętający, żeby podjąć działanie.

Objaw jest znany. Tablica OEE pokazuje przestój. Zespół utrzymania dowiaduje się o tym na porannym spotkaniu lub kiedy operator podejdzie i zgłosi problem.

W chwili, gdy istnieje zlecenie robocze, maszyna często już działa, a prawdziwa przyczyna jest zgadywana. Zdarzenie jest zapisywane jako drobny przestój, a ta sama usterka wraca w kolejnym tygodniu.

Dlaczego pętla się przerywa

Przerwa prawie zawsze występuje przy przekazaniu od wykrycia do diagnozy. Wykrycie, że maszyna się zatrzymała, jest proste; robią to automatycznie czujniki i liczniki. Wiedzieć, dlaczego się zatrzymała, jest trudne i to etap, który większość systemów pozostawia człowiekowi stojącemu przy linii.

• Przyczyna jest brakująca lub błędna. Operator pod presją czasu wybiera najbliższy kod przyczyny, więc dane, które powinny kierować naprawą, są od początku niewiarygodne.
• Zlecenie jest tworzone ręcznie. Ktoś musi zdecydować, że przestój wart jest zgłoszenia i otworzyć zlecenie, co oznacza, że krótkie powtarzające się przestoje nigdy nie generują rejestru.
• Kontekst się gubi. Technik otrzymuje zgłoszenie z napisem „Line 3 down” bez żadnych danych otoczenia, więc diagnoza zaczyna się od zera.

O tym, jak przestoje są klasyfikowane w pierwszej kolejności, przeczytasz w downtime versus uptime.

Zautomatyzowany przepływ fault-to-fix

1. Wykrycie. Przestój jest rejestrowany automatycznie z sygnału urządzenia lub systemu OEE, z dokładnym znacznikiem czasu i czasem trwania.
2. Diagnoza. Do przestoju przypisywana jest prawdziwa przyczyna, a nie zgadywany kod. To etap, na którym widzenie komputerowe i kontekst zdarzeń wykonują pracę, której zabiegany operator nie jest w stanie zrobić.
3. Wysłanie zlecenia. Zlecenie robocze otwiera się automatycznie, wstępnie wypełnione informacjami o zasobie, przyczynie i kontekście produkcyjnym.
4. Naprawa. Technik przybywa z gotową diagnozą i rejestruje, co faktycznie zostało wykonane.
5. Weryfikacja. Zamknięte zlecenie łączy się z pierwotnym zdarzeniem przestoju, dzięki czemu powtarzająca się ta sama usterka jest od razu widoczna.

System zarządzania zleceniami jest kręgosłupem kroków od trzeciego do piątego, a harmonogram konserwacji zapobiegawczej to miejsce, w którym projektuje się eliminację powtarzających się usterek.

Ręczny versus zautomatyzowany fault-to-fix

Na co zwrócić uwagę w platformie fault-to-fix

• Dokładne uchwycenie przyczyny, nie tylko alarmy. Alarm informujący „down” to za mało. Sprawdź, jak platforma określa przyczynę bez polegania na pośpiesznym ręcznym wpisie.
• Jeden model danych dla OEE i utrzymania. Jeśli przestoje są w jednym systemie, a zlecenia w innym, pętla ma szew, w którym dane się gubią. Jedno źródło prawdy usuwa ten problem.
• Automatyczne tworzenie zleceń z kontekstem. Zgłoszenie powinno zawierać zasób, przyczynę i stan produkcji bez ponownego wprowadzania danych.
• Weryfikacja w zamkniętej pętli. Zamknięte zlecenie powinno łączyć się z zdarzeniem przestoju, aby powtarzalność była mierzalna.
• Działa na mieszanych i starszych liniach. Pętla powinna przynosić wartość zanim wszystkie zasoby będą nowe lub w pełni zainstrumentowane.

Jak Fabrico zamyka pętlę

Fabrico jest zaprojektowane jako jedna platforma dla OEE i CMMS, więc wykryty przestój i wynikające z niego zlecenie dzielą tę samą bazę danych zamiast przekraczać integracyjny szew.

Gdy linia się zatrzymuje, Fabrico używa widzenia komputerowego, aby uchwycić rzeczywistą przyczynę przestoju zamiast polegać na kodzie przyczyny, a następnie otwiera zlecenie robocze z już dołączoną przyczyną i kontekstem produkcyjnym.

Zamknięte zlecenie łączy się z oryginalnym zdarzeniem, dzięki czemu usterka, która się powtarza, jest widoczna zamiast ukryta. Fabrico jest zbudowane i hostowane w UE z uwzględnieniem lokalizacji danych i posiada certyfikat ISO 27001.

Aby zobaczyć działanie pętli na swoich liniach, umów się na demo.

Powiązane materiały

• Najlepsze oprogramowanie do analizy przyczyn źródłowych
• OEE dla produkcji
• Systemy zarządzania zleceniami
• Przestój kontra czas pracy
• Harmonogram konserwacji zapobiegawczej

Aby przekształcić to w decyzję dotyczącą narzędzia, zobacz nasz przegląd najlepszych systemów monitorowania produkcji.

Najczęściej zadawane pytania

Czy fault-to-fix to to samo co utrzymanie predykcyjne?

Nie. Utrzymanie predykcyjne próbuje działać zanim wystąpi awaria. Fault-to-fix dotyczy tego, co się dzieje po wystąpieniu przestoju: uchwycenia prawdziwej przyczyny i szybkiego przekształcenia jej w zamknięte, zweryfikowane zlecenie robocze. Obie koncepcje się uzupełniają, ale fault-to-fix dostarcza wartości nawet dla zasobów bez modelu predykcyjnego.

Czy potrzebujemy nowych czujników na każdej maszynie?

Nie. Pętla powinna przynosić wartość na mieszanych i starszych liniach, wykorzystując istniejące sygnały i strumień zdarzeń OEE. Pełna instrumentacja może pojawić się później; nie jest warunkiem wstępnym.

Co najczęściej powoduje przerwanie pętli?

Przekazanie od wykrycia do diagnozy. Wykrycie przestoju jest łatwe; przypisanie dokładnej przyczyny jest trudne, a ogólny alert wciąż zostawia diagnozę człowiekowi. Pętla jest tak dobra, jak dobre są dane o przyczynie, które przechwytuje.

Czym to się różni od samodzielnego CMMS?

Samodzielny CMMS zarządza zleceniami roboczymi, ale zwykle polega na tym, że ktoś otworzy je ręcznie. Fault-to-fix automatycznie łączy zdarzenie przestoju ze zleceniem, dzięki czemu krótkie powtarzające się przestoje, które nigdy nie wygenerowałyby ręcznego zgłoszenia, nadal tworzą rejestr.