CMMS jako operacjonalizacja EAM?
Na przestrzeni ostatnich lat większość firm, z którymi miałem styczność, wdrożyła już system CMMS lub EAM, ale niekoniecznie go wykorzystuje. Rozróżnienie systemów CMMS i EAM z perspektywy typowego działu Utrzymania Ruchu zazwyczaj nie jest istotne, gdyż funkcjonalności systemów EAM zawierają w sobie to, co oferują systemy CMMS. W kontekście tego artykułu ma to jednak znaczenie.
Na potrzeby dalszych rozważań CMMS traktuję jako system o mniejszym zakresie funkcjonalnym, skoncentrowany na operacyjnym wsparciu Utrzymania Ruchu. EAM natomiast jako system, który oprócz podstawowych funkcjonalności, takich jak zgłaszanie usterek i awarii, zarządzanie pracą oraz materiałami technicznymi, oferuje również szereg dodatkowych funkcjonalności oraz integrację z systemem ERP, w tym z obszarem finansów.
CMMS nie konkuruje z EAM – CMMS może być narzędziem jego operacjonalizacji.
Operacjonalizacja EAM a wdrożenie systemu
Operacjonalizacja EAM to nic innego jak wprowadzenie systemu do codziennego stosowania na poziomach operacyjnych – Techników, Operatorów oraz Brygadzistów. Być może część czytelników nie widzi większej różnicy pomiędzy operacjonalizacją a wdrożeniem systemu i jest to w pełni zrozumiałe. Najprawdopodobniej są to organizacje, w których system EAM został dobrze wdrożony i faktycznie stał się elementem codziennej pracy.
Istnieje jednak duża grupa wdrożeń, które z różnych przyczyn zakończyły się formalnym uruchomieniem systemu, po czym… niewiele z niego weszło do operacyjnej codzienności. W takim przypadku bardzo szybko pojawia się przekonanie, że „system EAM nie działa”.
Gdzie leży problem?
Problemy są oczywiście specyficzne dla każdej organizacji, jednak można je uprościć do trzech najczęściej spotykanych kategorii.
System EAM wdrożony „w ramach ERP”
System został wdrożony jako element większego projektu ERP, bez realnej analizy wymagań działu technicznego. EAM był w pakiecie. W efekcie system nie realizuje potrzeb Utrzymania Ruchu, a pomiędzy Excelami i rzeczywistością operacyjną a systemem EAM powstaje „interfejs białkowy”. Dane wymagane do raportowania finansowego i zakupowego są wprowadzane do systemu, natomiast dane operacyjne funkcjonują poza nim.
System EAM wdrożony „out-of-the-box”
Systemy EAM posiadają bardzo rozbudowane możliwości konfiguracyjne oraz narzędzia dodatkowe, które nie zawsze wchodzą w zakres standardowego pakietu. Jeżeli w procesie wdrożeniowym nie poświęcono wystarczającej uwagi konfiguracji, dostosowaniu systemu do realiów organizacji oraz odpowiednim szkoleniom, efekt jest często taki, że system o tej samej nazwie w jednej firmie działa dobrze, a w innej jest omijany przez użytkowników.
Niespójność między procesami a funkcjonalnościami systemu
Każdy system powinien odpowiadać na konkretne potrzeby biznesowe. Nie chodzi tu o daleko idącą customizację i kodowanie systemu „od podstaw”, ponieważ wiąże się to z istotnymi ryzykami. Bardzo często problemem jest sytuacja odwrotna – rzeczywiste potrzeby są stosunkowo proste, natomiast dostępne narzędzie jest skomplikowanym „kombajnem”. Brak osadzenia systemu w kontekście procesów biznesowych jest jedną z głównych przyczyn jego niskiej użyteczności.
Skutki operacyjne
Bezpośrednimi ofiarami opisanych problemów są Technicy i Inżynierowie Utrzymania Ruchu, na których spada obowiązek raportowania, przepisywania i dublowania danych pomiędzy Excelami a systemem EAM. Pośrednio traci dział Utrzymania Ruchu, Produkcja oraz cała organizacja. W praktyce wszystko sprowadza się do prostego stwierdzenia: „EAM nie działa”.
Na tym etapie kończy się narzekanie, a zaczyna potrzeba działania. Pogłębiające się straty efektywności, frustracja zespołu oraz rosnąca rotacja pracowników prowadzą do dłuższych przestojów i większej liczby awarii.
Warto podkreślić, że przytoczone problemy nie są winą systemu EAM. Nie chodzi o szukanie winnych, lecz o znalezienie sposobu rozwiązania problemu.
Do czego dążymy?
Skoro zidentyfikowaliśmy problemy, warto odpowiedzieć na pytanie, czego faktycznie oczekujemy od Narzędzia – celowo bez przesądzania, czy mówimy o systemie EAM czy CMMS – oraz jakie elementy w jego otoczeniu należy „zaopiekować”.
Procesy biznesowe
Narzędzie powinno wspierać konkretne procesy biznesowe. Jeżeli system ma służyć m.in. do zgłaszania usterek, należy jasno określić:
-
kto inicjuje proces,
-
jak przebiega,
-
czym się kończy,
-
jakie są jego warianty.
Mapowanie procesów Utrzymania Ruchu jest zalecane jeszcze przed wyborem systemu, ale w przypadku już funkcjonującego narzędzia staje się krokiem krytycznym. Dodatkową korzyścią jest fakt, że sama analiza procesów często stanowi dobrą bazę do doskonalenia UR, niezależnie od systemu.
Wymagania funkcjonalne
Wymagania funkcjonalne wynikają bezpośrednio z procesów biznesowych i odpowiadają na pytania dotyczące m.in. lokalizacji Master Data, interfejsów z innymi systemami, zasad wprowadzania danych czy potrzeby aplikacji mobilnej. Istotnym elementem są również wymagania w obszarze cyberbezpieczeństwa.
Dobrze przygotowana specyfikacja funkcjonalna pozwala Klientowi rozmawiać z firmą wdrażającą Narzędzie precyzyjnym językiem, odnoszącym się do realnych potrzeb biznesowych.
Szkolenia i wiedza procesowa
Szkolenia są często wskazywane jako jedna z głównych przyczyn problemów z systemami CMMS i EAM. Znając uczestników procesów UR, można jasno określić, kto i z jakiego zakresu powinien zostać przeszkolony.
Doświadczenia z wdrożeń pokazują, że firmy wdrażające systemy szkolą użytkowników z obsługi technicznej, zgodnie z umową, natomiast użytkownicy nie zawsze wiedzą, w jakich sytuacjach procesowych i według jakich zasad korzystać z poszczególnych funkcji. Przykładowo użytkownik dowie się, które pola formularza należy wypełnić, ale niekoniecznie zrozumie, dlaczego dane pole jest istotne i jakie informacje powinny się w nim znaleźć.
Ta wiedza bardzo często leży po stronie organizacji i ma kluczowe znaczenie dla jakości danych oraz efektywnego wykorzystania systemu.
Rozwiązanie mobilne
Rozwiązanie mobilne, obejmujące aplikację oraz urządzenia, jest jednym z fundamentów operacjonalizacji Narzędzia. Warto jasno określić, kto będzie korzystał z aplikacji i jakich funkcjonalności potrzebuje. Należy uwzględnić koszty licencji, wymagania dotyczące pracy offline, a także aspekty sprzętowe, takie jak praca w strefach EX, wykorzystanie skanerów kodów czy wielkość ekranu.
Aplikacja mobilna stanowi podstawowy interfejs pomiędzy użytkownikami operacyjnymi a systemem, dlatego kluczowy jest balans pomiędzy funkcjonalnością a łatwością obsługi.
Taktyka przejścia z AS-IS do TO-BE
Na tym etapie organizacja posiada obraz problemów oraz oczekiwań wobec Narzędzia. Kolejnym krokiem jest wybór taktyki zmiany stanu AS-IS w TO-BE. W praktyce najczęściej rozważane są dwie opcje.
Rozwój obecnego systemu EAM
Opcja ta ma sens w sytuacji, gdy różnica pomiędzy stanem obecnym a docelowym jest niewielka, koszty rozwoju są akceptowalne, a wymogi korporacyjne lub potrzeba unifikacji systemów IT ograniczają możliwość wyboru innych rozwiązań.
CMMS jako warstwa operacyjna
Drugą opcją jest wdrożenie systemu CMMS jako nakładki zintegrowanej z istniejącym EAM, który pozostaje głównym systemem w obszarze danych finansowych i zakupowych. Rozwiązanie to warto rozważyć w sytuacji, gdy ingerencja w EAM jest ograniczona, a jednocześnie konieczne jest zwiększenie liczby użytkowników i zakresu wykorzystania systemu na poziomie operacyjnym.
Wadą tego podejścia mogą być dodatkowe koszty integracji oraz utrzymania kolejnego systemu.
Podsumowanie
Nie istnieje jedno uniwersalne rozwiązanie ani jedna właściwa ścieżka. Celem nie jest daleko idące dostosowywanie systemu do organizacji, lecz wybór takiego rozwiązania, które pozwoli zrealizować wymagania biznesowe przy możliwie największym wykorzystaniu standardowych funkcjonalności.
Dopiero analiza konkretnego przypadku biznesowego, oparta na jasno określonych procesach, wymaganiach i dostępnych ofertach, pozwala świadomie zdecydować, czy lepszą drogą jest rozwój EAM, czy wykorzystanie CMMS jako narzędzia jego operacjonalizacji. Taka analiza, przeprowadzona z perspektywy niezależnego doradcy, pozwala uniknąć kosztownych błędów i znacząco zwiększa szanse, że system CMMS lub EAM faktycznie zacznie funkcjonować w codziennej praktyce operacyjnej.