Systemy klasy CMMS w utrzymaniu ruchu – Case Study

W nowoczesnym przedsiębiorstwie produkcyjnym niezbędną komórka organizacyjną są służby utrzymania ruchu. Ich funkcjonowanie byłoby zaś w znacznym stopniu utrudnione bez oprogramowania klasy CMMS.

Autor: Karol Węzik

Systemy CMMS czyli Computerised Maintenance Management Systems są to specjalizowane systemy informatyczne przeznaczone do wsparcia szeroko rozumianego Utrzymania Ruchu w zarówno małych, jak i dużych firmach produkcyjnych. Pozwalają one na zarządzanie wyposażeniem przedsiębiorstwa, planowanie przeglądów i czynności obsługowych oraz na zarządzanie procedurami nadzoru oraz dokumentacją serwisową. Do ich zadań zalicza się też rejestrację zdarzeń związanych z utrzymaniem wyposażenia produkcyjnego i pomiarowego czyli wszelkiego typu awarie, remonty lub przeglądy, a także zarządzanie personelem służb utrzymania ruchu.

Jednym z tego typu systemów jest System Utrzymania Ruchu S.U.R.-FBD który wdrożony został w firmie TBMECA Poland. Zadaniem tego systemu CMMS jest automatyzacja prac związanych z zarządzaniem środkami trwałymi infrastruktury,  prowadzeniem gospodarki remontowej, prowadzeniem przeglądów technicznych i konserwacji maszyn, prowadzeniem gospodarki magazynowej UR, zarządzaniem zamówieniami na materiały i części zamienne oraz pozwala on na przygotowywanie raportów i generowanie statystyk.

Przed wdrożeniem

W firmie TBMECA Poland funkcjonuje wyodrębniona komórka Działu Utrzymania Ruchu (DUR), która dzieli się na trzy zespoły o profilowanych specjalizacjach: grupa mechaników, elektryków oraz ślusarzy zajmujących się formami wtryskowymi.

W okresie od powstania firmy TBMECA Poland w październiku 2003 roku do lutego 2009 roku nie używaliśmy żadnego oprogramowania CMMS, a jedynie prostą bazę danych Access. Dane z awarii bądź usterek zapisywano w „karcie awarii”, którą potoczne nazywano „Żółtą Kartką” (analogicznie do funkcjonujących w sporcie), ponieważ w tym kolorze właśnie ją drukowano. Pracownik działu produkcji zlecał DUR zadanie, wypełniając kilka pól tej karty. Był to opis objawu usterki, data, numer maszyny itd. W kolejnym kroku DUR wypełniał dalszą część dokumentu. Jeśli przyczyna usterki była znana, wówczas karta była wypełniana. Jeśli jednak przyczyna nie była oczywista, to należało skorzystać z obszaru kartki, który pozwalał na krótką analizę „5 Why”.

Pracownik DUR zapisywał również czas zakończenia pracy, ilość osób zaangażowanych, sugerował również działania zapobiegawcze. Oczywiście wszystkie te zapisy odbywały się już po usunięciu awarii. Zakończenie prac i potwierdzenie pierwszych dobrych wyprodukowanych detali na danej maszynie potwierdzał Team Leader działu produkcji własnoręcznym podpisem również na tej samej Żółtej Kartce. Pod koniec dnia pracy, pracownik DUR zobowiązany był przepisać wszystkie informacje zawarte w karcie do bazy danych Access. Dane tej bazy były dostępnej tylko na jednym komputerze , co znacznie ograniczało i utrudniało dostęp do zapisanych informacji. „Żółte Kartki” były umieszczane w segregatorze i nikt już potem do nich nie zaglądał. Formalnie istniał i funkcjonował system rejestracji danych, lecz praktyczny poziom wykorzystania danych w tym systemie był bardzo niski. Czas potrzebny na wypełnienie kartki oraz konieczność dopilnowania Team Leadera produkcji by podpisał odbiór maszyny, oraz późniejsze, ponowne przypisywanie tych samych danych do komputera budziło uzasadnioną niechęć pracowników do tak pracochłonnego „systemu”.

Z bazy danych Access można było tworzyć proste raporty i wykresy bazując na danych przepisywanych z kartek. Dostęp do tej bazy mieli tylko pracownicy DUR, tak więc ślad po awarii zostawał tylko w naszym dziale, ponieważ „żółta kartka” również była archiwizowana w biurze DUR.

Ręcznie tworzony harmonogram przeglądów oraz brak wartościowej informacji zwrotnej z przeprowadzonych przeglądów, nie pozwalał na planowanie i dostosowywanie czasokresów przeglądów, ich zakresu i innych istotnych elementów przeglądu do rzeczywistych potrzeb eksploatowanych urządzeń. Jedynym kryterium była data przeglądu. Ogromna część czasu pracy poświęcana była na ręczne wypełnianie kart oraz przepisywanie ich potem do bazy danych. Brak efektywnego wykorzystania posiadanych już informacji oraz ograniczony dostęp do nich, skłonił nas do poszukiwania sprawniejszego systemu na rynku komercyjnym.

Głównym jednak mankamentem całości systemu był brak zarządzania Prewencyjnym Utrzymaniem Ruchu, co nie znaczy iż programu prewencyjnego nie było w ogóle. Część przeglądów była wykonywana poprzez „ręczne” zarządzanie, którą maszyną należy się zająć i co przy niej zrobić. Ten pierwszy okres zresztą nie był specjalnie wymagający ponieważ wszystkie maszyny były nowe i większość serwisowana była w okresie gwarancyjnym przez producenta. Były to w większości urządzenia doskonale przystosowane do swoich zadań, więc poziom awarii, czy też usterek był niewielki (ale nie znaczy, iż całkowicie bezawaryjne i odporne na „czynnik ludzki„).

Systemy CMMS

Pod koniec 2008 roku, czyli po około 4 latach funkcjonowania papierowych kart i prostej bazy danych, podjęliśmy pierwsze próby z systemami klasy CMMS. Jako pierwszy na pulpit komputera trafił program w wersji 30-dniowej, zagranicznego producenta, w polskiej wersji językowej. Narzędzie było intuicyjne, z bogatą szatą graficzną. Większość funkcji jak najbardziej przydatna, jednak brakowało kilku funkcjonalności potrzebnych z punktu widzenia potrzeb TBMECA Poland. Pytanie o możliwość modyfikacji programu, uwzględniające nasze potrzeby, spotkało się z odpowiedzią negatywną. Powodem odmowy dostosowania programu do naszych potrzeb była polityka producenta oprogramowania, który sprzedaje system jako układ modułowy i wszelkie rozszerzenia mogą być wprowadzane tylko z myślą o innych użytkownikach. Mimo to chcieliśmy lepiej poznać program, a ponieważ w ciągu miesiąca nie wszyscy pracownicy wyrobili sobie zdanie, poprosiliśmy o przedłużenie licencji próbnej o kolejne 30 dni. Niestety odpowiedź również była negatywna co pozwoliło szybko wyrobić sobie ogólne zdanie o dostawcy i wyobrazić sobie jak mogłaby wyglądać współpraca w przyszłości. Jako kolejny testowaliśmy program rodzimego producenta, a zachętą była niska cena. Niestety już po dwóch tygodniach niechęć wśród pracowników była tak wysoka, iż przerwaliśmy dalsze testy i postanowiliśmy szukać kolejnych aplikacji. Program był naprawdę uciążliwy w użytkowaniu.

Jako trzeci, testowany był system SUR-FBD. Już na samym początku przekazana instrukcja do oprogramowania zrobiła dobre wrażenie. Ogrom funkcji i możliwości sprawił, że koniecznie chcieliśmy sprawdzić je w praktyce. Po pierwszych 30-dniowych testach z zainstalowanym programem na trzech różnych stacjach PC, wiedzieliśmy, że program spełnia nasze oczekiwania już w swojej podstawowej wersji. Cena również była przekonywująca. Każdy z działu DUR miał możliwość sprawdzenia programu i podzielenia się swoimi wrażeniami. Pamiętam jedną z pierwszych uwag: „No, kolorowy to on nie jest, ale prosty za to”. Szata graficzna programu SUR-FBD jest stonowana, choć tak naprawdę w codziennym użytkowaniu nie ma to większego znaczenia. Po okresie testów postanowiliśmy zakupić system SUR-FBD – na początek 4 licencje stanowiskowe oparte na bazie MS Sql Server.