Lokalne AI do przygotowania przeglądu awarii

Syntalith proponuje aplikację do przygotowania materiałów o jednej awarii, działającą w uzgodnionym środowisku zakładu. Inżynier otrzymuje wspólny widok zapisów, może otworzyć dokument przy danym zdarzeniu i poprawić zestawienie przed spotkaniem. Taki zakres warto rozważyć, gdy zespół ma potrzebne informacje, ale ich zebranie z rozproszonych opisów powtarza się przy kolejnych przeglądach.

Alarm, zatrzymanie i późniejsze działanie serwisu

Załóżmy, że inżynier przygotowuje przegląd konkretnej awarii. Rejestr zawiera alarm sprzed zatrzymania urządzenia. Operator opisał zatrzymanie w swojej notatce, a późniejsze zlecenie serwisowe odnotowuje wymianę elementu. Aplikacja może ułożyć te zapisy w kolejności i przy każdym pokazać jego źródło. Wpis operatora pozostaje przypisaną mu obserwacją, a wymiana czynnością zapisaną w zleceniu.

Sama kolejność nie dowodzi, że alarm wskazywał przyczynę zatrzymania ani że wymieniony element usunął problem. Jeśli w zgromadzonych materiałach nie ma opisu późniejszego zachowania urządzenia, w zestawieniu może pojawić się pytanie o taki zapis. Inżynier wie wtedy, czego brakuje do rozmowy z zespołem. Inżynierowie oceniają przyczyny, dalsze działania i bezpieczeństwo urządzenia.

Materiał, do którego można wrócić podczas spotkania

Chronologia ma pomóc uczestnikom rozmawiać o tych samych zdarzeniach. Przy opisie postoju można otworzyć zgłoszenie, a przy działaniu serwisu zobaczyć treść zlecenia. Gdy ktoś kwestionuje skrót przygotowany przez model, inżynier od razu dociera do zapisu i go poprawia. Pytania pozostają obok zdarzeń, których dotyczą, więc łatwiej przekazać je osobie znającej dany fragment historii.

Znaczenie ma także rodzaj daty. Data zapisania notatki może być późniejsza niż opisane w niej zdarzenie. Jeżeli dokument nie pozwala określić czasu zdarzenia, aplikacja powinna pokazać tę niejasność, zamiast nadawać mu pozornie dokładne miejsce na osi czasu. Podobnie różniące się relacje operatora i serwisu muszą pozostać widoczne do wyjaśnienia.

Inżynier potrzebuje wiedzieć, jakie materiały obejmuje zestawienie. Może wtedy zauważyć brak dokumentu, który pamięta, i uzupełnić przegląd.

Najpierw sprawdź raport w obecnym systemie

System CMMS, czyli oprogramowanie do zarządzania utrzymaniem ruchu, może już łączyć urządzenie, zgłoszenia i zlecenia. Microsoft opisuje w Dynamics 365 analizę rejestracji awarii według urządzeń, okresów i objawów, z dostępem do powiązanych zleceń. Taki raport jest sensownym punktem wyjścia do oceny potrzeb zespołu.

Jeżeli inżynier może w nim znaleźć całą historię i wygodnie przejść do opisów, osobna aplikacja może niewiele zmienić. Czasem wystarczy udostępnić właściwy raport lub połączyć istniejące rekordy. Model warto sprawdzić tam, gdzie ważna część historii pozostaje w swobodnych notatkach i osobnych dokumentach, które inżynier musi czytać i zestawiać ręcznie.

Powtarzające się obserwacje z wielu wizyt to odrębne zadanie, opisane w artykule o analizie notatek serwisowych. Przy przeglądzie pojedynczej awarii potrzebny jest materiał do omówienia jej przebiegu, wraz z rozbieżnościami i brakującymi informacjami.

Historia zakładu we własnym środowisku

Jeżeli poufność historii urządzeń wymaga pozostawienia materiałów we wskazanym środowisku zakładu, lokalny model może być jednym z elementów rozwiązania. Ollama rozróżnia modele lokalne i chmurowe oraz opisuje możliwość wyłączenia funkcji chmurowych.

Zakres aplikacji musi objąć cały obieg materiałów: pobranie dokumentów, przygotowanie zestawienia i jego zapis, także w kopiach zapasowych. Z działem IT trzeba uzgodnić, kto ma dostęp do historii i opracowań oraz jak będzie wyglądać utrzymanie i pomoc przy problemach wymagających wglądu w treść. Sam wybór lokalnego modelu nie rozstrzyga, gdzie pozostałe części aplikacji przetwarzają dane.

Początek od jednego zdarzenia

Prace z Syntalith mogą rozpocząć się od znanej zespołowi awarii i materiałów wskazanych przez utrzymanie ruchu. Inżynier porówna przygotowaną chronologię z obecnym raportem: zobaczy, do których dokumentów dociera wygodniej, jakie skróty musi poprawić i czy pytania wskazują rzeczywiste braki. Próba w docelowym środowisku pokaże również, czy oczekiwanie na zestawienie pasuje do sposobu przygotowywania spotkań.

Z opiekunem systemu ustalimy powiązanie źródeł i odpowiedzialność za późniejsze utrzymanie aplikacji. Po obejrzeniu materiału można zdecydować, czy rozbudować połączenie z CMMS i objąć podobnym przeglądem kolejne awarie.

Opisz nam jedną awarię, przy której przygotowanie materiałów wymagało szukania w kilku miejscach. Na pierwszą rozmowę wystarczy opis tych miejsc i tego, co inżynier chce mieć przed spotkaniem; poufne raporty mogą pozostać w firmie. Informacje o wycenie znajdziesz w cenniku.