Kiedy ekspert odchodzi, odchodzi też historia maszyny

Linia pakująca, wtorek, godzina 14:22. Operator zmienia status stanowiska na „awaria mechaniczna”. Technik dyżurny, który od trzech miesięcy pracuje w firmie, otwiera zlecenie i widzi: nazwę maszyny, kategorię, datę. Nie ma historii poprzednich interwencji, komentarzy ani dokumentacji. Pyta, kto ostatnio naprawiał tę maszynę. Okazuje się, że Marek, który odszedł dwa miesiące temu.

MTTR tej awarii: 4 godziny i 20 minut.
 Poprzednia, bardzo podobna awaria naprawiana przez Marka: 55 minut.

Różnica trzech godzin i 25 minut często nie wynika wyłącznie z kompetencji pracownika. W wielu przypadkach problemem jest brak dostępu do historii maszyny, wcześniejszych obserwacji, sprawdzonych hipotez i procedur, które zostały w głowie doświadczonego technika.

To właśnie tutaj zaczyna się zarządzanie wiedzą w utrzymaniu ruchu. Nie od samego zakupu systemu, ale od odpowiedzi na jedno pytanie: czy wiedza krytyczna dla produkcji istnieje w organizacji, czy tylko w głowach kilku pracowników?

Wiedza techniczna w UR: jawna, ukryta i trudna do odzyskania

W teorii zarządzania wiedzą rozróżnia się wiedzę jawną, czyli tę, którą można zapisać, przekazać i odtworzyć, od wiedzy ukrytej, która powstaje przez lata obserwacji, prób i błędów przy konkretnej maszynie.

Wiedza w maintenance jest ważnym zasobem organizacji, a jej przechwycenie zależy od systemowego podejścia do zarządzania wiedzą w firmie [1].

W praktyce działu utrzymania ruchu wiedza ukryta przyjmuje najczęściej trzy formy.

Wiedza diagnostyczna

Technik rozpoznaje charakterystyczny dźwięk zużytego łożyska w napędzie podajnika, zanim drgania przekroczą próg alarmu. Wie też, że określona wibracja przy rozruchu nie musi oznaczać awarii, bo wynika z temperatury oleju w pierwszych minutach pracy.

Wiedza o wyjątkach

To wiedza o tym, co w danej maszynie nie działa dokładnie tak, jak opisuje DTR producenta. Na przykład: przy zmianie dostawcy taśmy uszczelniającej trzeba skorygować parametry dociskowe o 0,3 bara. Albo: czujnik pozycji na linii 4 przekłamuje wskazania przy wilgotności powyżej 70%.

Wiedza historyczna

To informacje o tym, co już zdarzało się z konkretną maszyną i jak problem został rozwiązany. Przykład: dwa lata temu podobna awaria na linii 3 nie była awarią czujnika, tylko efektem rozluźnionego zacisku w szafie sterowniczej.

Instrukcje obsługi, schematy elektryczne i DTR zwykle są dostępne. Problem zaczyna się wtedy, gdy wiedza diagnostyczna, wiedza o wyjątkach i historia awarii nie są zapisywane w systemie. Wtedy istnieją personalnie, ale nie organizacyjnie.

Rotacja pracowników w dziale UR: koszt, którego nie widać wprost

Literatura dotycząca zarządzania wiedzą opisuje zjawisko utraty wiedzy eksperckiej, które pojawia się wtedy, gdy doświadczeni pracownicy odchodzą z organizacji, a ich wiedza nie została wcześniej przechwycona w procedurach, dokumentacji ani systemach informacyjnych. W organizacjach wiedzochłonnych odejście ekspertów może oznaczać utratę wiedzy trudnej do szybkiego odtworzenia [2].

W utrzymaniu ruchu ten mechanizm jest szczególnie istotny, bo wiedza serwisowa jest głęboko kontekstowa: zależy od konkretnej maszyny, warunków produkcji i historii awarii, która często nie została nigdzie zapisana.

Ekonomiczny mechanizm jest prosty: im dłużej technik diagnozuje problem od zera, tym większy koszt przestoju i większe ryzyko opóźnień w planie produkcji.

W przykładowym scenariuszu technik z dużym doświadczeniem naprawia powtarzalną awarię w 55 minut, podczas gdy nowy pracownik bez dostępu do historii potrzebuje 4 godzin i 20 minut. Nie dlatego, że jest niekompetentny, ale dlatego, że musi odtworzyć proces diagnostyczny od początku: sprawdzić dokumentację, zapytać innych, przetestować hipotezy, które poprzednik już kiedyś wykluczył.

Przy trzech podobnych zdarzeniach miesięcznie i koszcie przestoju na poziomie 5000 zł za godzinę różnica w czasie diagnozy może przełożyć się na dziesiątki tysięcy złotych rocznie. W każdym zakładzie konkretna wartość będzie inna, bo zależy od kosztu godziny postoju, częstotliwości awarii, obłożenia produkcji i krytyczności danej linii. Mechanizm pozostaje jednak ten sam: brak dostępu do wiedzy wydłuża diagnozę.

Cyfryzacja jest jednym z ważnych czynników wspierających transfer wiedzy podczas zmiany pokoleniowej w organizacji [3]. Firmy bez cyfrowego repozytorium historii interwencji, procedur i obserwacji technicznych są bardziej narażone na utratę wiedzy przy każdej rotacji.

Bariery w dzieleniu się wiedzą rzadko wynikają wyłącznie z braku narzędzia. Mogą mieć charakter indywidualny, organizacyjny i technologiczny: brak czasu, brak standardów, niska motywacja do dokumentowania, niewystarczające wsparcie procesowe oraz niedopasowane systemy informacyjne [4]. W utrzymaniu ruchu te bariery są szczególnie widoczne wtedy, gdy doświadczenia techników nie trafiają do historii zleceń, procedur ani harmonogramów przeglądów.

W praktyce powtarzają się cztery problemy:

•  historia awarii sprowadzona do pola „naprawiono”, bez opisu objawów, hipotez i rozwiązania, 
•  dokumentacja serwisowa przechowywana w folderach na dysku sieciowym, niedostępna przy maszynie w momencie awarii, 
•  wiedza prewencyjna pozostająca wyłącznie w głowie jednego technika, 
•  brak procedur dla powtarzających się awarii, przez co każda interwencja zaczyna się od nowa. 

Każdy z tych problemów może wpływać na MTTR i dostępność linii produkcyjnej, szczególnie wtedy, gdy dotyczy krytycznych maszyn lub powtarzalnych awarii.

Historia zlecenia jako baza wiedzy technicznej

Zamknięte zlecenie z wpisem „naprawiono” jest tylko rejestrem zdarzeń. Zlecenie z opisem objawów, sprawdzonych hipotez, wykonanych działań i obserwacji na przyszłość staje się elementem bazy wiedzy.

To różnica między samym odnotowaniem awarii a realnym wsparciem kolejnego technika, który za kilka tygodni stanie przy tej samej maszynie.

Ten mechanizm jest zbliżony do koncepcji experience feedback, czyli wiedzy generowanej z poprzednich działań maintenance i wykorzystywanej jako wsparcie decyzyjne przy kolejnych interwencjach [5]. Warunek jest jeden: wiedza musi być zapisana w miejscu dostępnym dla kolejnego technika.

Dobrze opisana historia zlecenia powinna odpowiadać na pytania, które technik faktycznie zadaje przy zatrzymanej maszynie:

•  jakie były objawy i jak opisał je operator? 
•  co sprawdzono jako pierwsze? 
•  które hipotezy odrzucono? 
•  jaka część została wymieniona? 
•  jaki parametr zmieniono? 
•  co warto sprawdzić przy podobnym objawie następnym razem? 

W module CMMS AndonCloud każde zlecenie pracy może zawierać notatkę, załącznik z dokumentacją techniczną, przypisanie kategorii oraz procedurę. Dzięki temu zamknięcie zlecenia nie musi kończyć się jedynie statusem „wykonano”. Może zostawić po sobie informację, która pomoże przy kolejnej interwencji.

Po kilku miesiącach systematycznego uzupełniania zleceń może powstać historia maszyny, która pomaga nowym pracownikom szybciej zawężać diagnozę i korzystać z doświadczeń poprzednich interwencji. Nie gwarantuje to automatycznie skrócenia każdego postoju, ale ogranicza ryzyko powtarzania tych samych błędów diagnostycznych.

Szablony procedur: jak wiedza eksperta staje się standardem pracy

Prasa hydrauliczna, cykliczny przegląd uszczelnień co 6 tygodni. Przez trzy lata przegląd wykonywał ten sam technik. W tym czasie zauważył, że przy każdej wymianie uszczelnienia warto jednocześnie sprawdzić stan zaworu zwrotnego, bo oba elementy zużywają się w podobnym rytmie. Pominięcie zaworu często powodowało powrót problemu po kilkunastu dniach.

Jeśli ta obserwacja zostaje w głowie technika, pozostaje wiedzą personalną. Jeżeli trafia do checklisty jako wymagany krok procedury, staje się standardem pracy całego zespołu.

Dzielenie się wiedzą między doświadczonymi i mniej doświadczonymi pracownikami w działach maintenance jest trudne między innymi ze względu na ukryty charakter tej wiedzy [6]. Procedury i checklisty mogą ograniczać ten problem, ponieważ przenoszą część doświadczenia eksperta do codziennego procesu pracy.

W AndonCloud szablon procedury może przyjąć formę checklisty z polami tekstowymi, checkboxami i opcjami jednokrotnego wyboru. Pola oznaczone jako wymagane blokują zamknięcie zlecenia bez ich uzupełnienia, co pomaga utrzymać standard dokumentowania i ogranicza ryzyko pominięcia ważnych kroków.

To nie zastępuje kompetencji technika. Daje jednak zespołowi wspólny punkt odniesienia: co należy sprawdzić, w jakiej kolejności i jakie informacje powinny zostać zapisane po zakończeniu interwencji.

Zlecenia cykliczne i automatyczne: prewencja bez polegania wyłącznie na pamięci

Wiedza ukryta w utrzymaniu ruchu to nie tylko wiedza o awariach. To także wiedza o rytmie maszyny: kiedy smarować napęd, kiedy sprawdzić ustawienia dociskowe, które komponenty szybciej się zużywają i które przeglądy warto wykonywać częściej, niż sugeruje dokumentacja producenta.

Gdy technik odchodzi, ten rytm często odchodzi razem z nim.

Zlecenia cykliczne w CMMS pomagają przenieść tę wiedzę do harmonogramu. W AndonCloud mogą być generowane automatycznie według ustalonego cyklu: codziennie, co tydzień, co miesiąc lub co rok. System tworzy kolejne zlecenie zgodnie z harmonogramem, dzięki czemu przegląd nie zależy wyłącznie od pamięci konkretnej osoby.

Drugim mechanizmem są automatyczne zlecenia uruchamiane przez zdarzenia na hali. Przykład: operator zmienia status stanowiska na „awaria mechaniczna”, a system tworzy zlecenie z przypisanym szablonem procedury dla tego typu awarii. Inne zlecenie i inna procedura mogą uruchomić się przy awarii elektrycznej.

W praktyce oznacza to mniej ręcznego przekazywania informacji i mniejsze ryzyko, że zgłoszenie zgubi się między operatorem, brygadzistą a technikiem. Technik dostaje zlecenie, kontekst zdarzenia i procedurę, która może bazować na wcześniejszych doświadczeniach zespołu.

To właśnie połączenie zdarzenia z hali, zlecenia serwisowego i procedury opartej na wiedzy technicznej sprawia, że zarządzanie wiedzą przestaje być osobnym projektem. Staje się częścią codziennej pracy działu UR.

Od czego zacząć zarządzanie wiedzą w CMMS?

Najczęstszy błąd przy wdrożeniu polega na próbie opisania całego parku maszynowego naraz. Efektem może być kilka tygodni pracy bez widocznego rezultatu, po których zespół traci motywację, a system pozostaje pusty.

Lepsze podejście to sekwencja małych, ale konsekwentnych działań.

Krok 1: wybierz maszynę najbardziej zależną od wiedzy jednej osoby

Nie zaczynaj od maszyny z najobszerniejszą dokumentacją producenta. Zacznij od tej, przy której nowi pracownicy najczęściej pytają: „kto to zwykle naprawia?” albo „czy ktoś już miał taki przypadek?”.

To właśnie tam wiedza jest najbardziej spersonalizowana i najbardziej narażona na utratę.

Krok 2: rozmawiaj o konkretnych przypadkach, nie o ogólnej wiedzy

Nie pytaj technika: „co trzeba wiedzieć o tej maszynie?”. To zbyt szerokie pytanie.

Zapytaj:

•  co sprawdzasz jako pierwsze przy tym objawie? 
•  kiedy nie wymieniasz od razu tej części? 
•  po czym poznajesz, że problem wróci? 
•  co musi być spełnione, zanim zamkniesz zlecenie? 
•  jakie błędy diagnostyczne powtarzają się najczęściej? 

Z takich odpowiedzi powstaje pierwszy użyteczny szablon procedury.

Krok 3: ustal minimalny standard opisu zlecenia

Pole notatki nie musi być długim raportem. W wielu przypadkach wystarczą trzy informacje:

•  co się stało, 
•  co sprawdzono, 
•  co rozwiązało problem. 

Najważniejsza nie jest objętość opisu, ale konsekwencja. Jeżeli każde zamknięte zlecenie zawiera choćby krótki opis diagnostyczny, po czasie zaczyna powstawać realna historia maszyny.

Krok 4: zabezpiecz wiedzę przed odejściem pracownika

Jeśli wiadomo, że technik z kluczową wiedzą odchodzi lub zmienia rolę, warto wcześniej przejrzeć jego harmonogramy, procedury i najczęściej obsługiwane maszyny. Po odejściu pracownika zespół traci możliwość zadania pytań, które często są ważniejsze niż sama dokumentacja.

Po pierwszym etapie wdrożenia celem nie powinien być system z setkami procedur. Lepszym wynikiem jest 5–10 dobrze opisanych szablonów dla najczęstszych awarii, historia kilkudziesięciu zleceń z opisem diagnostycznym i pierwsze zlecenia cykliczne działające bez przypominania przez przełożonego.

To wystarczy, żeby kolejna zmiana kadrowa była mniej bolesna dla działu UR i dla produkcji.

AndonCloud CMMS: gdzie wiedza techniczna zostaje w firmie

Moduł CMMS w AndonCloud integruje się z cyfrowym systemem Andon. Dzięki temu zdarzenie na hali może uruchomić zlecenie z procedurą bez ręcznego tworzenia zadania i bez konieczności przekazywania informacji przez kilka osób.

To połączenie jest ważne, bo utrzymanie ruchu nie działa w oderwaniu od produkcji. Awaria zaczyna się przy stanowisku, ale jej konsekwencje widać w OEE, terminowości, obciążeniu techników i planowaniu kolejnych zmian.

AndonCloud może wspierać zarządzanie wiedzą techniczną przez:

•  historię zleceń i komentarze, 
•  załączniki z dokumentacją techniczną, 
•  szablony procedur i checklisty, 
•  zlecenia cykliczne, 
•  zlecenia automatyczne uruchamiane przez statusy stanowisk, 
•  powiadomienia dla odpowiednich osób, 
•  kategorie awarii i historię zmian, 
•  raportowanie zdarzeń i analizę powtarzalnych problemów. 

System sam w sobie nie rozwiązuje problemu utraty wiedzy. Pomaga dopiero wtedy, gdy zespół konsekwentnie zapisuje informacje, buduje procedury i korzysta z historii zleceń przy kolejnych interwencjach.

Dobrym pierwszym krokiem jest sprawdzenie, przy których maszynach zespół najczęściej mówi: „to wie tylko jedna osoba”. To właśnie tam cyfrowa historia zleceń, procedury i automatyczne harmonogramy mogą najszybciej ograniczyć ryzyko utraty wiedzy technicznej.

Podsumowanie

Zarządzanie wiedzą w utrzymaniu ruchu to decyzja o tym, czy wiedza krytyczna dla produkcji istnieje w organizacji, czy tylko w głowach kilku pracowników.

CMMS nie chroni zakładu przed utratą wiedzy przez sam fakt wdrożenia. Robi to dopiero wtedy, gdy każde zamknięte zlecenie zawiera więcej niż status, procedury odzwierciedlają doświadczenie techników, a harmonogramy przeglądów działają niezależnie od składu zespołu.

W produkcji seryjnej przewagę daje nie tylko szybka reakcja na awarię, ale też zdolność do uczenia się z każdej interwencji. Jeśli wiedza z napraw, przeglądów i powtarzalnych problemów zostaje w systemie, nowi pracownicy nie zaczynają od zera, a dział UR może pracować bardziej przewidywalnie.

FAQ

Co to jest zarządzanie wiedzą w utrzymaniu ruchu?

Zarządzanie wiedzą w utrzymaniu ruchu to sposób gromadzenia, porządkowania i wykorzystywania informacji technicznych potrzebnych do utrzymania maszyn w dobrej kondycji. Obejmuje między innymi historię awarii, opisy interwencji, procedury, checklisty, harmonogramy przeglądów i doświadczenia techników. Celem jest to, aby wiedza nie była zależna wyłącznie od pojedynczych osób, ale była dostępna dla całego zespołu.

Dlaczego utrata wiedzy technicznej jest problemem dla produkcji?

Utrata wiedzy technicznej może wydłużać diagnozę awarii, zwiększać MTTR i utrudniać planowanie pracy działu UR. Jeżeli tylko jeden technik wie, jak zachowuje się konkretna maszyna, jego odejście oznacza, że zespół musi odtwarzać tę wiedzę od początku. W produkcji seryjnej taki brak informacji może przekładać się na dłuższe przestoje, opóźnienia i większe obciążenie pozostałych pracowników.

Jak CMMS pomaga zachować historię awarii maszyn?

CMMS pozwala zapisywać zlecenia, komentarze, kategorie awarii, wykonane działania, załączniki i procedury. Dzięki temu historia maszyny nie ogranicza się do informacji, że awaria została usunięta. Technik może sprawdzić, jakie objawy wystąpiły wcześniej, co było sprawdzane, które działania nie pomogły i jakie rozwiązanie okazało się skuteczne. To ułatwia diagnozę powtarzalnych problemów.

Co powinno zawierać dobrze opisane zlecenie serwisowe?

Dobre zlecenie serwisowe powinno zawierać opis objawów, kontekst zgłoszenia, wykonane czynności diagnostyczne, wymienione części, zmienione parametry i krótką informację, co rozwiązało problem. Warto również zapisać, które hipotezy zostały odrzucone. Dzięki temu kolejne osoby nie muszą powtarzać tych samych testów przy podobnej awarii.

Jak rotacja pracowników wpływa na MTTR?

Rotacja pracowników może wpływać na MTTR, jeśli wiedza o maszynach, awariach i wyjątkach procesowych nie jest zapisana w systemie. Nowy technik bez dostępu do historii często diagnozuje problem od zera. Musi pytać innych, szukać dokumentacji i testować hipotezy, które doświadczony pracownik znał z wcześniejszych interwencji. Dobra baza wiedzy nie zastępuje doświadczenia, ale może skrócić drogę do trafnej diagnozy.

Jak tworzyć procedury utrzymania ruchu na podstawie wiedzy ekspertów?

Najlepiej zaczynać od konkretnych przypadków, a nie od ogólnych instrukcji. Warto zapytać doświadczonych techników, co sprawdzają jako pierwsze przy danym objawie, kiedy nie wymieniają od razu części, jakie błędy diagnostyczne się powtarzają i co musi być wykonane przed zamknięciem zlecenia. Z takich odpowiedzi można zbudować checklistę lub szablon procedury w CMMS.

Czy zlecenia cykliczne pomagają ograniczyć zależność od pamięci techników?

Tak, zlecenia cykliczne pomagają przenieść wiedzę o rytmie przeglądów do systemu. Jeżeli smarowanie, kontrola ustawień lub przegląd komponentu zależą wyłącznie od pamięci jednej osoby, ryzyko pominięcia rośnie przy urlopie, chorobie lub rotacji. Harmonogram w CMMS pozwala generować zlecenia automatycznie i utrzymywać powtarzalność działań prewencyjnych.

Jak AndonCloud CMMS wspiera zarządzanie wiedzą techniczną?

AndonCloud CMMS pozwala tworzyć historię zleceń, dodawać notatki, załączać dokumentację, przypisywać kategorie i korzystać z procedur. Dzięki integracji z systemem Andon zdarzenie na hali może uruchomić zlecenie serwisowe z odpowiednim szablonem. To pomaga połączyć informację od operatora, reakcję technika i późniejszą analizę w jednym procesie.

Czy AndonCloud może tworzyć zlecenia automatycznie po zmianie statusu stanowiska?

Tak, AndonCloud może tworzyć zlecenia na podstawie zdarzeń, takich jak zmiana statusu stanowiska. Przykładowo awaria mechaniczna może uruchomić zlecenie z procedurą mechaniczną, a awaria elektryczna — z inną checklistą i innym przypisaniem. Dzięki temu zgłoszenie nie musi przechodzić przez kilka osób, a technik otrzymuje bardziej uporządkowany kontekst interwencji.

Źródła

[1] Cárcel-Carrasco, J. i in. (2020). Factors in the Relationship between Maintenance Engineering and Knowledge Management. Applied Sciences, 10(8), 2810.

[2] Joe, C., Yoong, P., & Patel, K. (2013). Knowledge loss when older experts leave knowledge-intensive organisations. Journal of Knowledge Management, 17(6), 913–927.

[3] Igoa-Iraola, E. & Díez, F. (2024). Procedures for transferring organizational knowledge during generational change: A systematic review. Heliyon. PMCID: PMC10909792.

[4] Riege, A. (2005). Three-dozen knowledge-sharing barriers managers must consider. Journal of Knowledge Management, 9(3), 18–35.

[5] Ruiz, P.P., Kamsu-Foguem, B. & Grabot, B. (2014). Generating knowledge in maintenance from Experience Feedback. Knowledge-Based Systems, 68, 4–20.

[6] Roham, H. & Gomes, J.F.S. (2024). Knowledge management and knowledge sharing in maintenance department of high-tech industries. Journal of Quality in Maintenance Engineering, 30(4), 605–623.