Model operacyjny utrzymania ruchu: w jaki sposób alerty OEE powinny inicjować zlecenia robocze

Najważniejsze wnioski

Zobacz typy zleceń roboczych, które powinny generować te alerty.

• W większości zakładów system OEE i CMMS działają jako dwa oddzielne modele operacyjne, jeden dla produkcji, drugi dla utrzymania ruchu, i spotykają się tylko na porannym spotkaniu.
• Zunifikowany model operacyjny utrzymania traktuje każde zdarzenie OEE jako punkt decyzyjny: zignoruj, zarejestruj lub utwórz zlecenie robocze. Zasady stojące za tą decyzją stanowią model.
• Największe zyski nie wynikają z szybszych zleceń roboczych. Pochodzą z wyeliminowania drobnych, powtarzających się strat, które dziś nigdy nie eskalują do zlecenia roboczego i dlatego nigdy nie są naprawiane.
• Zmiana jest w przeważającej mierze proceduralna, a nie techniczna: zdefiniowanie progów wyzwalających, wyznaczenie właściciela dla każdej klasy strat oraz spisanie reguły, która przekształca zdarzenie OEE w żądanie pracy bez ręcznego wpisywania.

Dlaczego obszary OEE i CMMS się rozjeżdżają

W typowym zakładzie system OEE obserwuje linię produkcyjną, a CMMS obserwuje urządzenie. Oba widzą „przestoje”, ale każdemu jawi się inna ich wersja. System OEE rejestruje każdą przerwę powyżej pewnego progu. Strona utrzymania ruchu rejestruje tylko te, które stały się zleceniami roboczymi. Luka między tymi dwoma liczbami, zwykle 20, 40% całkowitych przestojów, to miejsce, w którym występują drobne, powtarzające się straty. To również tam kryje się większość możliwych do osiągnięcia usprawnień.

Powód istnienia tej luki nie polega na tym, że jeden z zespołów wykonuje niewłaściwą pracę. Chodzi o to, że dwa systemy nie mają wspólnej definicji „ta przerwa wymaga zlecenia roboczego”. Operator decyduje, nadzorca decyduje, czasem nikt nie decyduje, a zasady przesuwają się linia po linii. Model operacyjny utrzymania to zestaw jawnych reguł, które przekształcają każde zdarzenie OEE w wynik binarny: zlecenie robocze otwiera się albo nie.

Cztery elementy składowe zunifikowanego modelu operacyjnego

1. Taksonomia zdarzeń: każda przerwa ma klasę

System OEE bez przejrzystej taksonomii klas strat to tylko zbiorczy stoper. Model operacyjny zaczyna się od skondensowania każdej przerwy do stabilnego zestawu klas, zwykle siedmiu do dziesięciu. Typowe: przezbrojenie, mikroprzerwa, drobna usterka mechaniczna, usterka elektryczna/czujnikowa, brak materiału, odrzuty jakościowe, planowe wydłużenie, inicjowane przez operatora.

Dokładna lista jest mniej istotna niż to, aby ta sama lista była używana wszędzie, na każdej zmianie, na każdej linii. Artykuł o wskaźnikach KPI w produkcji omawia rodziny KPI, do których ta taksonomia się wpinana.

2. Próg wyzwalający dla każdej klasy

Każda klasa potrzebuje reguły: po jakim czasie lub przy jakiej częstotliwości zdarzenie staje się zleceniem roboczym? Progi prawie zawsze są błędne w dniu uruchomienia i są dostrajane w tygodniach od drugiego do szóstego. Ważne jest, żeby reguła istniała i była widoczna. Przykłady typowych pierwszych progów:

• Drobna usterka mechaniczna > 5 minut → automatyczne zlecenie robocze.
• Ta sama klasa na tym samym urządzeniu 3+ razy w jednej zmianie → automatyczne zlecenie robocze nawet jeśli każde zdarzenie było krótkie.
• Wskaźnik odrzuceń jakościowych przekracza 1,5× tygodniową średnią kroczącą → oznacz, nie otwieraj automatycznie.
• Wariancja przezbrojeń > 30% powyżej standardu → przegląd na porannym spotkaniu, nie zlecenie robocze.

Reguły progów klastrowych („3 razy w 8 godzin”) zwykle wyłapują drobne, powtarzające się straty, które pojedyncze progi wydarzeń pomijają. Są to reguły o najwyższej wydajności dodawania.

3. Wyznaczony właściciel dla każdej klasy

Każda klasa strat ma jednego wyznaczonego właściciela, nie dział. Drobne usterki mechaniczne i elektryczne przypadają kierownikowi utrzymania ruchu. Przezbrojenia i zdarzenia inicjowane przez operatora przypadają kierownikowi produkcji. Brak materiału przypada planiście. Odrzuty jakościowe przypadają kierownikowi ds. jakości. Właściciel niekoniecznie wykonuje naprawę, ale odpowiada za trend i próg. Gdy klasa przekracza próg, właściciel działa pierwszy.

4. Zasada przekazania

Najważniejsza i najczęściej pomijana reguła. Gdy zdarzenie OEE automatycznie otwiera zlecenie robocze, dwie rzeczy muszą wydarzyć się w tej samej minucie: technik utrzymania ruchu widzi zlecenie na urządzeniu mobilnym, a rekord OEE jest powiązany ze zleceniem, tak żeby zamknięcie przepływało z powrotem.

Bez tego dwukierunkowego powiązania model operacyjny degeneruje się w „OEE tworzy hałas, CMMS to ignoruje” w ciągu kwartału. Gotowy do pracy w terenie CMMS na telefonie technika to to, co sprawia, że to działa. Artykuł o systemach zarządzania zleceniami roboczymi opisuje te elementy bardziej szczegółowo.

Co model daje, czego nie daje status quo dwóch oddzielnych systemów

Szybsze naprawy powtarzających się drobnych strat

Dzięki regułom klastrowym ta sama usterka, która występuje trzy razy, zostaje wykryta zanim ktośby ją zauważył, a drobne powtarzające się straty, dotychczas niewidoczne, zaczynają pojawiać się w backlogu utrzymania z rzeczywistą ścieżką naprawczą. Wiele zakładów stwierdza, że ta kategoria sama w sobie często odpowiada za znaczący udział, często 15, 25%, nieplanowanych przestojów po jej ujawnieniu. Zobacz szersze omówienie w naszym artykule o analizie przyczyn źródłowych w produkcji.

Rzeczywisty pomiar MTTR i MTBF

Kiedy każde istotne zdarzenie OEE staje się zleceniem roboczym, CMMS w końcu widzi pełną populację awarii. MTBF i MTTR zaczynają odzwierciedlać rzeczywistość zamiast podzbioru, który operatorzy lub nadzorcy zdecydowali się eskalować. Efektem ubocznym jest to, że harmonogramy konserwacji zapobiegawczej można dostroić na podstawie rzeczywistych danych o awariach zamiast zaleceń dostawców.

Jedna liczba na porannym spotkaniu

Dzięki temu, że zdarzenie OEE i zlecenie robocze mają wspólne ID, kierownik produkcji i kierownik utrzymania patrzą na ten sam wiersz. Poranne spotkanie przestaje być sporem „czyja liczba jest prawidłowa” i staje się dyskusją „która klasa strat poruszyła się w zeszłym tygodniu”. Ta jedna zmiana to operacyjne odblokowanie, którego poszukuje większość średnich zakładów przy zakupie systemu OEE, i prawie nigdy nie pochodzi wyłącznie z samego oprogramowania OEE.

Najczęstsze tryby niepowodzeń

Zbyt wiele reguł wyzwalających od początku

Typowym błędem jest uruchomienie 30 reguł wyzwalających przy starcie. Połowa jest błędna, wszystkie generują hałas, zespół utrzymania wyłącza integrację w trzecim tygodniu. Zacznij od pięciu lub sześciu reguł. Dodawaj jedną tygodniowo na podstawie tego, co jest pomijane.

Brak ścieżki zamknięcia z powrotem do OEE

Jeśli zlecenie robocze zostaje zamknięte, ale zdarzenie OEE pozostaje „otwarte” w rejestrze strat, liczby OEE i CMMS znów się rozjeżdżają, czasem w ciągu kilku tygodni. Zamknięcie musi przepływać w obie strony. Na tym często zawodzi wiele poskładanych systemów OEE+CMMS w praktyce.

Automatyczne tworzenie zleceń bez właściciela

Jeśli klasa generuje zlecenie, ale żaden wyznaczony właściciel nie obserwuje trendu, zlecenie zostaje wykonane, strata się powtarza i nic się nie zmienia. Wyznaczony właściciel to element, który zamienia wolumen w poprawę.

Jak Fabrico pomaga

Powyższy model operacyjny można wdrożyć na dowolnym dobrze zinstrumentowanym stosie technologii, ale praktyczny powód, dla którego średnie zakłady mają trudność z realizacją, jest taki, że narzędzie OEE i oddzielny CMMS rzadko dzielą czyste powiązanie zdarzenie/zlecenie robocze.

Fabrico zostało zbudowane wokół tego dokładnego przekazania: każde zdarzenie OEE żyje w tej samej bazie danych co zlecenia robocze, hierarchia aktywów i taksonomia strat, dzięki czemu reguły wyzwalające i ścieżki zamknięcia istnieją domyślnie, zamiast być integracją na zamówienie.

Jeśli chcesz zobaczyć, jak zunifikowany model wygląda na danych z Twojej linii, umów demo , a przejdziemy przez to razem.

Najczęściej zadawane pytania

Czy potrzebujemy zunifikowanej platformy OEE+CMMS, aby to zrobić?

Nie, ale problem ze ścieżką zamknięcia jest trudny do rozwiązania czysto w dwóch oddzielnych systemach. Zakłady na rozdzielonych stosach zwykle potrzebują warstwy pośredniczącej lub manuelnego kroku uzgadniania, który zanika w ciągu kwartału. Zunifikowana platforma usuwa to ryzyko.

Z iloma regułami wyzwalającymi powinien zacząć zakład?

Pięć lub sześć. Pokusa jest, by zdefiniować każdą regułę od pierwszego dnia; rzeczywistość jest taka, że większość reguł potrzebuje 4, 6 tygodni rzeczywistych danych, zanim próg będzie właściwy. Mały zestaw startowy dostrojony w ciągu pierwszego kwartału bije kompletny zestaw wdrożony na zimno.

Kto jest właścicielem modelu operacyjnego?

Operacyjnie, kierownik zakładu. Kierownik utrzymania ruchu i kierownik produkcji każdy odpowiadają za swoje klasy. Bez pojedynczego właściciela na poziomie zakładu progi się rozjeżdżają, wyznaczeni właściciele rotują bez przekazania, a model podupada.

Co się zmienia dla operatora na linii?

Bardzo niewiele na początku. Operator nadal rejestruje przestoje w ten sam sposób. Zmienia się to, że to system decyduje teraz, czy każda przerwa staje się zleceniem roboczym, więc operator nie musi podejmować tej decyzji zmiana po zmianie. Z czasem operator widzi mniej powtarzających się drobnych strat, ponieważ reguły wyzwalające wychwytują je wcześniej.

Jak mierzyć, czy model działa?

Dwie liczby: udział nieplanowanych przestojów, które mają powiązane zlecenie robocze (cel: powyżej 80% w ciągu 90 dni), oraz krocząca liczba zleceń generowanych przez reguły progów klastrowych (powinna pozostać różna od zera; jeśli spadnie do zera, reguły przestały wychwytywać cokolwiek nowego).