Raportowanie przestojów w utrzymaniu ruchu

Scenariusz krok po kroku

1. 01

   Dwie zatrzymane maszyny i jeden wynik dla linii

   Rozważmy przykład przygotowany na potrzeby wyjaśnienia. Maszyna A stoi od 10:00 do 10:30, a maszyna B od 10:15 do 10:45. Każda ma osobny, prawidłowy zapis zatrzymania. Suma czasu dla urządzeń wynosi 60 minut.

   Jeśli zespół potwierdzi, że zatrzymanie dowolnej z tych maszyn wstrzymuje całą linię, a linia miała w tym czasie pracować, okres niedostępności linii wynosi 45 minut: od 10:00 do 10:45. Wspólne 15 minut występuje w obu zapisach maszyn, ale tylko raz w czasie niedostępności linii. Raport może pokazać obie wartości, z nazwą jednostki i wyjaśnieniem sposobu obliczenia.

   Takie połączenie przedziałów ma sens dopiero po ustaleniu zależności urządzeń. Bufor między maszynami albo równoległe stanowisko mogą pozwalać na dalszą produkcję. Z samych dwóch rejestrów serwisowych nie wynika wtedy, kiedy stanęła linia. Potrzebny jest zapis jej stanu lub potwierdzona reguła, którą zespół potrafi zastosować do tych danych.

   To osobny problem od dwóch wpisów opisujących jedno zdarzenie. Powiązanie logu i notatki operatora omawiamy w artykule o duplikatach w raporcie przestojów. Tutaj oba zdarzenia pozostają w raporcie.

2. 02

   Które minuty należą do raportowanego okresu

   Przyjmijmy w tym samym przykładzie, że raport obejmuje pracę od 10:00 do 10:40. Do wyniku dla tego okresu trafia 30 minut maszyny A i 25 minut maszyny B. Niedostępność linii, przy wcześniej ustalonych założeniach, wynosi 40 minut. Pozostałe pięć minut zdarzenia B pozostaje poza tym okresem; oryginalny zapis nadal kończy się o 10:45.

   Przed wdrożeniem trzeba więc wskazać kalendarz pracy i granice zestawienia. Warto osobno ustalić, jak pokazać zdarzenie jeszcze niezamknięte. Raport sporządzony przed końcem przestoju może mieć wynik tymczasowy i podaną godzinę odcięcia danych. Późniejsze zamknięcie zdarzenia powinno pozwalać wyjaśnić zmianę wartości.

   Dokumentacja Microsoft Dynamics 365 Asset Management opisuje zapisy okresu przestoju dla urządzenia na zleceniu, kody przyczyn i kalendarz używany do obliczenia czasu. Pokazuje też ustawienie uwzględniania kodu przyczyny w KPI. Warto sprawdzić takie funkcje w obecnym CMMS, czyli systemie zarządzania utrzymaniem ruchu. Przytoczona dokumentacja nie stanowi potwierdzenia opisanego wyżej sposobu liczenia czasu całej linii.

3. 03

   Komentarz do wyniku musi zachować niewiadome

   Zestawienie może zawierać czas, urządzenie i opis prac, choć przyczyna zatrzymania nadal czeka na potwierdzenie. Wymiana czujnika zapisana w zleceniu nie wystarcza, żeby nazwać wadliwy czujnik przyczyną awarii. Autor komentarza powinien móc wrócić do wpisu i sprawdzić jego status.

   Proponowana rola AI to skrócenie zatwierdzonych opisów na potrzeby odprawy. Przy komentarzu można pokazać źródła oraz sprawy pozostawione do wyjaśnienia. Wybór reguły liczenia, rozstrzygnięcie sprzecznych godzin i potwierdzenie przyczyny wymagają osoby odpowiedzialnej za raport. Ocena bezpieczeństwa urządzenia i decyzja o wznowieniu pracy pozostają poza tym zakresem.

4. 04

   Co zamówić i jak sprawdzić wynik

   Najpierw warto sprawdzić, czy obecny raport CMMS lub MES daje potrzebne rozróżnienie czasu urządzeń i linii. Jeżeli tak, praca może skończyć się na zmianie konfiguracji albo opisaniu reguł. Gdy planista co tydzień zestawia kilka eksportów, można wycenić ich połączenie dla jednej linii i jednego okresu raportowania. Syntalith może przygotować obliczenia, odnośniki do źródeł i listę zapisów do wyjaśnienia. Widok akceptacji, historia korekt oraz komentarz AI są elementami do uzgodnienia w ofercie.

   Zespół zakładu wskazuje źródła początku i końca zdarzeń, zależności urządzeń oraz obowiązujący kalendarz. Na tej podstawie przygotowuje oczekiwane wyniki próby. Oprócz zwykłego zatrzymania warto uwzględnić nakładające się przestoje, granicę zmiany, brak końca zdarzenia i korektę już zamkniętego okresu. Każda różnica między wynikiem oczekiwanym a raportem musi mieć wyjaśnienie przed odbiorem. Nie obiecujemy gotowego połączenia z konkretnym CMMS; dostęp do danych wymaga sprawdzenia.

   Demonstracja raportu z odnośnikami do liczb pozwala obejrzeć pracę ze źródłem i konfliktem wartości. Korzysta z danych syntetycznych i nie sprawdza przestojów maszyn ani kalendarza Waszej linii. Nie zawiera też testu modelu piszącego komentarz. Próba dla utrzymania ruchu jest osobnym zadaniem do przygotowania.

   Szerszy obieg zgłoszeń i dokumentacji opisuje AI w utrzymaniu ruchu, a łączenie danych różnych działów obejmuje automatyzacja raportowania. Opisz raport, którego czas trzeba dziś ręcznie poprawiać. Na pierwszą rozmowę wystarczą nazwy źródeł i wyjaśnienie, co kierownik ma rozstrzygnąć na podstawie zestawienia.