Historia – obsługa reaktywna

Obsługa reaktywna

Pomimo znacznego przesunięcia celów funkcjonowania służb utrzymania ruchu w kierunku konserwacji zapobiegawczej (PM) oraz konserwacji opartej na predykcji długo jeszcze głównym zadaniem UR będą działania reaktywne (RM), czyli mówiąc kolokwialnie usuwanie awarii.

Jednym z podstawowych zadań programu jest gromadzenie informacji o historii obiektu, jej naprawach, awariach, przeglądach, wymianie części czy wymianie oprzyrządowania.

Wbrew pozorom nie jest to proste zadanie bo opisanie zdarzenia takiego jak awaria nie jest proste co staramy się wykazać w naszym artykule:
Czas naprawy maszyn

Rodzaje zdarzeń

Mamy kilka rodzajów rejestrowanych zdarzeń:

1. Awaria – zdarzenie które spowodowało nieplanowane zatrzymanie pracy maszyny – urządzenia i które należy usunąć najszybciej jak to jest możliwe
   
   
2. Usterka – podobnie jak awaria ale możemy jej usunięcie odłożyć w czasie bez narażenia bezpieczeństwa obsługi oraz bezpieczeństwa technicznego urządzenia
   
   
3. Eksploatacja – czynność w ramach eksploatacji maszyn czy urządzeń, np. wymiana narzędzia czy rekonfiguracja linii produkcyjnej która została scedowana na pracowników utrzymania ruchu
   
   
4. Modernizacja – prace związane z szeroko rozumianym udoskonalaniem obiektów, np. modernizacje w ramach systemu KAIZEN
   
   
5. Ostrzeżenie – notatki na temat pracy / stanu technicznego obiektu, w szczególności przewidywanie możliwych, przyszłych problemów

W ramach historii widoczne są też zakończone przeglądy co pozwala na prześledzenie kompletnej historii urządzenia bez konieczności przeglądania dwu rejestrów ( historii i harmonogramu )
Uwaga – widoczna w rejestrze historii zakończone zlecenia są nieedytowalne – aby dokonać ich edycji trzeba przejść do harmonogramu.

Prześledźmy różnice pomiędzy awarią, usterką, eksploatacją, ostrzeżeniem i modernizacją na przykładzie maszyny która zasilana jest za pomocą kabla z wtykiem 3-fazowym:

• Jeśli ktoś wyrwał kabel z wtyczki to jest Awaria która wymaga natychmiastowej reakcji
  
  
• Jeśli ktoś uszkodził wtyk ale zapewnia on zasilanie maszyny i nie zagraża bezpieczeństwu więc można go wymienić jutro rano to jest Usterka. Trzeba ją usunąć jak najszybciej ale niekoniecznie natychmiast
  
  
• Jeśli przewód jest krótki, leży w miejscu gdzie chodzą ludzie i można o niego się „potknąć” ryzykując uszkodzenie to należało by się temu kiedyś bliżej przyjrzeć – zapisujemy to jako Ostrzeżenie
  
  
• Jeśli zdecydujemy się wymienić przewód na dłuższy z jakimiś ewentualnymi, dodatkowymi zabezpieczeniami to zrobimy to w ramach Modernizacji
  
  
• Jeśli to urządzenie jest elementem większej całości które przy niektórych produktach jest zastępowane innym urządzeniem a wymiana tych urządzeń ( przezbrajanie maszyny ) należy do obowiązków UR to robimy to w ramach Eksploatacji

Rejestr historii

Rejestr historii może mieć wiele tysięcy rekordów dlatego rejestr ma rozbudowany zestaw filtrów pozwalający na szybką selekcję interesujących nas informacji od rodzaju zdarzeń, zakresu czasu, grupowania obiektów itp.


Na zakładce ze szczegółami widzimy opis zdarzenia, informacje o obiekcie oraz informacje o zgłoszeniu jeśli zdarzenie powstało na podstawie zgłoszenia awarii czy eksploatacji.

Cechy (parametry) zdarzeń, edycja

Każde zdarzenie ma szereg parametrów: nazwa, czas kiedy nastąpiło, status, priorytet. Niektóre parametry występują we wszystkich ( poza ostrzeżeniem ) zdarzeniach. Tutaj opiszemy te które są wspólne, pozostałe opiszemy przy okazji opisu edycji poszczególnych zdarzeń

Obiekt, nazwa	Nadajemy zdarzeniu nazwę, określamy jakiego obiektu dotyczy wybierając go z listy
Opisy szczegółowe	Dwa pola tekstowe memo pozwalają na dodanie szczegółowego opisu oraz opisu w celu podjętych działań
Odpowiedzialny	Pracownik odpowiedzialny za zdarzenie. Domyślnie jest to zalogowany użytkownik, czyli ten co dodał wpis. Admin i szef mogą do zdarzenia przypisać innego pracownika
Baza Wiedzy	Opis niektórych zdarzeń niesie cenną wiedzę dla potomnych. Mając problem z nietypową awarią możemy zajrzeć do historii w nadziei że ktoś kiedyś coś podobnego już „przerabiał” A niektóre nie … Oznaczenie jako baza wiedzy pozwala odfiltrować te zdarzenia których opis niesie wiedzę
Pracę wykonała firma obca	Czasami za obsługę zdarzenia, np. za naprawę maszyny odpowiada firma obca.
info dla przełożonych	Informacja widoczna tylko w oknie edycyjnym. Można w nim zostawić np. notatkę o błędnych wpisach.
Zgłoszenie zdarzenia (TA)	godzina o której zgłoszono zdarzenie.
Rozpoczęcie obsługi (TB)	godzina o której podjęto działania
Zgłoszenie zdarzenia (TE)	godzina o której zakończono działania
Szacowany koszt	Koszt obsługi zdarzenia bez części Koszt ten wstępnie jest wyliczany jako czas pracy pomnożony przez domyślną stawkę godzinową ustawianą w panelu ustawień programu.

Czas operacyjny

Czas operacyjny określa nam kiedy wydarzyło się określone zdarzenie, kiedy rozpoczęto i zakończono jego obsługę. Na podstawie tych dat określamy czas trwania zdarzenia, dzielimy na czas oczekiwania obsługi etc.
Najlepiej posłużmy się przykładem. Najpierw spójrzmy na ogólny schemat przebiegu zdarzenia w czasie:


a następnie na fragment okna edycji zdarzenia:



Widzimy o której zgłoszono zdarzenie [TA], o której rozpoczęto jego obsługę, np. naprawę [TB] i o której to zdarzenie zostało zakończone [TE]

Czas Twait określa ile czasu czekano na rozpoczęcie obsługi.
Czas Ttotal to czas całkowitej obsługi zdarzenia od zgłoszenia do zakończenia.
Czas Tserw to czas obsługi zdarzenia czyli czas Ttotal pomniejszony o czas oczekiwania Twait.

I było by wszystko proste i łatwe gdyby nie to że przerwano naprawę maszyny aby pozyskać części. W naszym przykładzie mamy 1 godzinę oczekiwania i 48 godzin obsługi czyli w sumie 49 godzin.

Zwróćmy jednak uwagę na 4 parametr czyli czas zawieszenia Tsusp czyli czas na który przerwano obsługę z przyczyn takich jak oczekiwanie na części, serwis zewnętrzny czy z takiej prozaicznej przyczyny jak przerwa weekendowa.
Tu podano Tsusp 44 godziny. Czas ten odjęto od czasu obsługi uzyskując czas rzeczywistej pracy Twork.

Podsumowując przykład: oczekiwano 1 godzinę na reakcję UR, maszyna była niedostępna przez 49 godzin ale technicy pracowali przy niej tylko 4 godziny bo jej naprawę zawieszono na 44 godziny oczekując na części.

Pracownik odpowiedzialny z zlecenie pracy

Wiele systemów CMMS oferuje tzw. zlecenia pracy dla czynności nieplanowanych. Oznacza to że jeśli mamy awarię i w jej usunięciu biorą udział trzy osoby to musimy wystawić 3 zlecenia pracy. Na jedną awarię ….
Wtedy i TYLKO WTEDY możemy pracę poszczególnych osób podliczyć i rozliczyć. Oczywiście możemy mieć w swoich szeregach osoby o niższych kwalifikacjach lub niższym zaangażowaniu. Ale raporty oparte na ilości roboczogodzin to stanowczo za mało …..
Szerzej piszemy na ten temat w naszym mini kompendium o systemach CMMS

W naszym programie do zadania przypisujemy jedną, odpowiedzialną za realizację osobę.

Formalne potwierdzenie

Czasami, np. w przemyśle spożywczym wymagane jest aby ktoś do tego uprawniony potwierdził że naprawa czy inna czynność została wykonana z zachowaniem, mówiąc trochę żartobliwie, aby ktoś podpisał się pod pracą mechanika gwarantując że została wykonana w taki sposób że w kiełbasie nie będzie nakrętek…
W naszym programie można to zrobić za pomocą formalnego potwierdzenia:



Zapamiętywana ( i widoczna na podglądzie i wydrukach) jest informacja że danego dnia dana osoba dokonała zatwierdzenia, oraz formuła tego potwierdzenia, np. „zatwierdzam wykonanie naprawy zgodnie z wymogami” która może pochodzić ze słownika.

Formalne potwierdzenie dotyczy i historii i harmonogramu

Log operacji

Pracownik który ma uprawnienia do edycji zdarzenia może w każdej chwili zmienić dowolne parametry, np. któryś z czasów: zgłoszenia, rozpoczęcia czy zakończenia.
Ale nie może tego zrobić bez pozostawiania śladu. Każda operacja typu dodanie czy edycja jest zapisywana a jeśli zmieni się status, nazwa czy któryś z czasów to podana jest stara i nowa wartość.

Zgłoszenie awarii

Aby personel UR zareagował na awarie to musi o niej wiedzieć i to jak najszybciej. A z tym bywa różnie. Dlatego pracownicy produkcyjni czy ich bezpośredni przełożeni powinni mieć możliwość wprowadzania informacji o awariach do systemu.

Są trzy podstawowe cele:

• Przywołanie pomocy. Ale tu trzeba zachować ostrożność – to nie jest tak że ktoś na te zgłoszenia wyczekuje dlatego nic nie zastąpi kontaktu człowiek - człowiek
  
  
• Upublicznienie zgłoszenia – jeśli zastosujemy aplikację do ich wyświetlania na TV to o zgłoszonej awarii będą wiedzieli wszyscy a nie tylko zainteresowani
  
  
• Rejestracja rzeczywistego czasu zgłoszenia – możemy sprawdzić że problem zgłoszono o 11:34 a nie o 10:30 jak twierdzi produkcja
  
  

Dodanie zgłoszenia

Pracownik może dokonać zgłoszenia awarii za pomocą programu głównego ( mając np. profil operator nie będzie miał dostępu do innych opcji ) za pomocą programu pracującego w trybie terminala ( zobacz rozdział terminal) albo za pomocą aplikacji mobilnej.

W oknie zgłoszenia:



Pracownik wybiera obiekt ( w trybie terminala obiekt jest już ustawiony ), i opisuje problem. Może ustawić priorytet i jeśli potrafi to określić, podać czyje wsparcie jest potrzebne. Może też napisać kogo powiadomił jeśli przyjmiemy procedurę o której napiszę za chwilę.
Jeśli w opisie obiektu wypełniliśmy dla wybranego obiektu listę kontrolną to zostanie ona wyświetlona z prawej strony. Lista ta może wskazać pracownikowi co ma sprawdzić zanim wezwie pomoc – czasami to wystarczy aby rozwiązać problem….

Zgłoszenie awarii możemy potraktować w dwojaki sposób. Albo jako system przywoławczy. Zgłaszamy awarię i liczymy że ktoś na to zgłoszenie zareaguje. Osobiście proponuję rozważenie innego scenariusza.
Powiadomienie odbywa się w klasyczny sposób – operator lub jego bezpośredni szef telefonicznie kontaktuje się z kimś kogo pomoc uważa za stosowną. A następnie zgłasza problem jako potwierdzenie zgłoszenia.
Wtedy wpisujemy w polu powiadomiono: „Mechanik Kowalski – powiedział że będzie za pół godziny”

Rejestr i przekształcenie

Zgłoszenia jako informacje niepewne i niekonieczne trafiają do oddzielnego rejestru.
Niepewne bo po przybyciu na miejsce może się okazać że „zapomnieliśmy otworzyć powietrze” czyli było zgłoszenie a nie było awarii.
Niekonieczne bo często dowiadujemy się o problemach „innymi kanałami”. Zresztą możemy w ogóle nie korzystać z systemu zgłoszeń.
Domyślnie w rejestrze zgłoszeń widzimy tylko te które są aktywne:



Za pomocą filtru możemy przejrzeć wszystkie zgłoszenia, i aktywne i nie akatywne ( zamienione na konkretne zdarzenia ) z ostatnich 30 lub 300 dni.

Co robimy ze zgłoszeniami?
Zamieniamy je na inne zdarzenie: Awarię, Usterkę lub Ostrzeżenie. Albo anulujemy.
Po zaznaczeniu rekordu i wybraniu zdarzenia zgłoszenie znika z rejestru a nam otwiera się okno edycji nowego zdarzenia z częściowo wypełnionymi danymi.
Jeśli teraz przejdziemy do rejestru historii i odszukamy nowo dodaną awarie to na zakładce z informacjami szczegółowymi zobaczymy informacje o zgłoszeniu:

Zgłoszenie eksploatacji

Pozwala produkcji złożyć zapotrzebowanie na wykonanie czynności eksploatacyjnych. Wszystko jest prawie identyczne jak w zgłoszeniach awarii z tą różnicą że trafiają one do oddzielnego rejestru i podlegają zamianie na takie zdarzenia jak eksploatacja, modernizacja i ostrzeżenie.

Przykładem takiego zgłoszenia jest prośba produkcji o zmianę konfiguracji maszyny, np. wymianę wykrojników w prasie jeśli firma nie ma odrębnego zespołu do takich zadań.