Jak uporządkować opisy zdarzeń utrzymania ruchu?

Podobne zdarzenia pod różnymi nazwami

Załóżmy, że kierownik przegląda dwa odrębne zlecenia dotyczące tego samego urządzenia. W pierwszym technik napisał: „Czujnik zabrudzony, po czyszczeniu praca przywrócona”. W drugim zapisano: „Brud na czujniku. Oczyszczono, urządzenie znów działa”. Zespół uzgodnił, że takie opisy zbiera w raporcie pod nazwą „zabrudzenie czujnika”.

Model może przypisać oba zlecenia do tej grupy i zachować przy nich oryginalne notatki. Kierownik zobaczy dwa zapisane zdarzenia, które warto omówić razem. Nie musi pamiętać wszystkich sformułowań używanych przez techników, żeby odnaleźć te wpisy. Może otworzyć oba zlecenia i sprawdzić ich przebieg, zamiast zaczynać od przeszukiwania całego archiwum.

W kolejnym zleceniu znajduje jednak tylko „Wymieniono czujnik, urządzenie działa”. Ten zapis opisuje wykonaną czynność i jej rezultat, ale nie podaje ustalonej przyczyny. Dopisanie go do grupy zabrudzeń zwiększyłoby liczbę takich zdarzeń bez podstawy w notatce. W zestawieniu można zachować informację o wymianie i pokazać, że przyczyny nie zapisano.

Tak uporządkowany raport pomaga wybrać sprawy do dalszego przeglądu. Kierownik widzi, gdzie wraca opisana obserwacja, a gdzie dokumentacja mówi tylko o wykonanej pracy. Ocena, dlaczego zdarzenia się powtarzają, wymaga dalszej analizy przez zespół znający urządzenie.

Wspólne oznaczenia mogą wystarczyć

Jeśli technicy już wybierają w systemie jednoznaczne oznaczenia zdarzeń, zwykłe filtrowanie i raport mogą dać potrzebny wynik. Warto najpierw sprawdzić, czy lista oznaczeń jest zrozumiała i czy pracownicy faktycznie jej używają. Dodanie modelu do raportu nie wyjaśni, dlaczego połowa zespołu wybiera ogólne „inne”.

Gotowe systemy potrafią rozdzielać informacje o zdarzeniu. Publiczne streszczenie dokumentacji IBM Maximo opisuje hierarchię kodów na zleceniach, która pozwala zapisać element objęty pracą, przyczynę i zastosowany sposób usunięcia problemu. To funkcja warta sprawdzenia przed zamówieniem osobnego rozwiązania. Źródło: publiczne streszczenie IBM.

Model warto sprawdzić, gdy potrzebne informacje nadal znajdują się w swobodnych opisach. Może to dotyczyć starszego archiwum albo notatek, których nie da się wygodnie zastąpić krótką listą wyboru. Wtedy pracownik korzystałby z propozycji wspólnego oznaczenia, a obok widziałby fragment, na którym ta propozycja się opiera.

Nie trzeba przy tym ujednolicać całego stylu pisania techników. Dla raportu istotne jest, żeby dwa opisy zabrudzenia trafiły do tej samej grupy, a notatka o samej wymianie zachowała własne znaczenie. Oryginalny tekst nadal pozwala przeczytać szczegóły, których zbiorcza nazwa nie oddaje.

Czego miałby nauczyć się model

Najpierw warto sprawdzić gotowy model z jasno opisanym podziałem zdarzeń. Jeśli poprawnie porządkuje notatki, dodatkowe uczenie może być zbędne. Taka próba pokaże również, czy sam zespół zgadza się co do przypisań. Różne oceny tej samej notatki mogą wynikać z niejasnego podziału albo wiedzy spoza dokumentu.

Fine-tuning oznacza dalsze uczenie istniejącego modelu na przykładach z pokazanym poprawnym przypisaniem. W tym zastosowaniu miałby pomóc mu rozpoznawać skróty i sformułowania spotykane w notatkach zakładu. Google wymienia klasyfikację jako zastosowanie nadzorowanego dostosowania, a zarazem wskazuje, że model ogólny może wystarczyć, gdy zadanie da się jasno opisać w instrukcji i uzyskać powtarzalne wyniki.

Adaptację uzasadnia więc konkretny błąd pozostający po takiej próbie. Model może na przykład regularnie pomijać opis zabrudzenia zapisany zakładowym skrótem, choć technicy zgodnie go rozumieją. Osoba znająca dokumentację pomaga wtedy ocenić przykłady. Jej zadaniem jest wskazanie, co wynika z notatki, również gdy szczegóły zdarzenia pamięta lepiej, niż zostały zapisane.

Zmiana sposobu opisywania pracy albo nowe grupy zdarzeń będą wymagały ponownego przeglądu działania. Warto ustalić, kto utrzymuje znaczenie oznaczeń w raporcie. Po zmianie podziału te same zdarzenia mogą trafić do innych grup. Kierownik potrzebuje tej informacji, żeby poprawnie porównać raporty z kolejnych okresów.

Przydatność widać w gotowym zestawieniu

Kierownik powinien porównać wynik na odrębnych zleceniach, których nie używano do dostosowania modelu. Czy znalazły się razem opisy, które wcześniej musiał sam wyszukiwać? Czy może szybko wrócić do notatek i czy nadal musi od początku sprawdzać każde przypisanie? Takie porównanie warto wykonać również dla gotowego modelu i obecnego raportu z systemu.

Jeśli problemem jest również łączenie kilku dokumentów opisujących tę samą wizytę, pomocny będzie artykuł o analizie notatek serwisowych za pomocą lokalnego modelu. Wyjaśnia, jak odtworzyć historię bez liczenia podsumowania jako kolejnego zdarzenia.

Od jednego raportu do decyzji o adaptacji

Syntalith tworzy aplikacje i dostosowuje modele AI. Dla zespołu utrzymania ruchu proponujemy zacząć od zestawienia, które dziś wymaga ręcznego czytania notatek. Porównujemy możliwości obecnych oznaczeń i gotowego modelu, a przy powracających błędach oceniamy sens próby adaptacji. Osoba znająca dokumentację pomaga ustalić grupy, które rzeczywiście przydadzą się na spotkaniu zespołu.

Wybrane rozwiązanie może przygotowywać takie zestawienie z odsyłaczami do zleceń, aby kierownik miał pod ręką materiał do dalszego przeglądu. Na pierwszą rozmowę wystarczy opisać jedno pytanie o powtarzające się zdarzenia, na które trudno dziś odpowiedzieć z raportu. Sposób wykorzystania dokumentów uzgodnimy, jeśli będą potrzebne do dalszej oceny. Informacje o ofercie są w cenniku Syntalith.