^
CMMS Maszyna SMART - centrum pomocy i dokumentacji
Szukaj:

Historia – obsługa reaktywna

Historia napraw, awarii, czynności eksploatacyjnych

Obsługa reaktywna

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

Cechy (parametry) zdarzeń

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
Czas oczekiwania (Twait) Czas jaki minął od zgłoszenia (TA) do rozpoczęcia obsługi (TB)
Czas obsługi (Tserw) Czas jaki minął od rozpoczęcia (TB) do zakończenia obsługi (TE)
Czas zawieszenia (Twait) Czas zawieszenia to czas na jaki przerwano pracę przy obsłudze zdarzenia
Może to być np. czas konieczny na sprowadzenie części.
Czas pracy (Twork) Czas pracy nie jest ustawiany, jest zawsze wyliczany jako
czas obsługi – czas zawieszenia.
Czas pracy dzięki odpowiednio dobranemu czasowi zawieszenia powinien odzwierciedlać rzeczywistą pracę pracowników przy obsłudze zdarzenia.
Czas całkowity (Ttotal) Czas jaki minął od zgłoszenia (TA) do zakończenia obsługi (TE)
Czas ten powinien odzwierciedlać całkowity czas niezdatności ( braku dostępności) obiektu do pracy wywołany zdarzeniem
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.
Graficzna prezentacja zależności czasowej zdarzenia:



Czasy oczekiwania, obsługi, całkowity oraz koszt przeliczane na podstawie czasów TA, TB i TE.
Przeliczyć możemy przyciskiem [Przelicz] lub nastąpi ono po zatwierdzeniu przyciskiem [OK]
Czas pracy zawsze wyliczany jest jako czas obsługi – czas zawieszenia.

Ważne – jeśli zmienimy jakiś czas ręcznie, np. zmienimy czas oczekiwania z 1 godziny na dwie i nie zatwierdzimy tej zmiany przyciskiem [Przelicz] to zostanie on tak zapamiętany.
Szczególnie ważne jest to przy parametrze koszt który możemy zmienić według uznania.

Rejestr historii

Dodawanie i edycja zdarzeń

Zgłoszenie awarii

Naprawa wymaga czasu. Na diagnostykę, na związane z nią czynności, na pozyskanie potrzebnych części. Na czas naprawy wpływają okoliczności i profesjonalizm personelu. Rzadko jednak można zoptymalizować sam czas naprawy – tylko przy naprawdę skomplikowanych można powiedzieć że pracownik A zrobił by to szybciej niż pracownik B.

Potencjał do optymalizacji leży w czasie oczekiwania. A tu mamy dwa zjawiska – czas jaki jest potrzebny od zepsucia się maszyny do powzięcia informacji przez odpowiednie osoby oraz ich dostępność. Mówiąc inaczej po jakim czasie UR się o awarii dowie i czy ma odpowiednie zasoby aby sprostać obsłudze wielu zdarzeń na raz.

Dlatego tak ważne jest rejestrowanie zgłoszeń o awariach pochodzących bezpośrednio od zainteresowanych. Ponadto w UR mamy często do czynienia ze zjawiskiem o którym rzadko się mówi. O czymś co my nazywamy „spychologią”. Chodzi o różnice zdań pomiędzy produkcją i UR co do tego kiedy powiadomiono stosowne służby.

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:

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