MES-lite w 4 krokach: raportowanie bez wymiany maszyn (i jak zacząć bez wymiany maszyn)

Większość rozmów, które prowadzimy z małymi i średnimi zakładami produkcyjnymi, zaczyna się od tego samego zdania: „wiemy, że mamy przestoje, ale nie wiemy dokładnie ile i dlaczego”. I zanim ktokolwiek zdąży zapytać o wdrożenie MES, zadaję inne pytanie: czy macie w ogóle jakiekolwiek dane historyczne, na których dałoby się policzyć skalę problemu? W 8 na 10 przypadków odpowiedź brzmi: nie, mamy tylko wyczucie brygadzisty i karteczki na tablicy zmianowej.

To jest dokładnie ten moment, w którym pełny system MES to zły pierwszy krok. Nie dlatego, że MES jest złym narzędziem, tylko dlatego, że wdraża się go na podstawie wiedzy o procesach, której w małej fabryce zwykle jeszcze nie ma w formie danych. Kupowanie systemu klasy enterprise, żeby dopiero odkryć, gdzie tracicie czas, to odwracanie kolejności. Najpierw dane, potem decyzja o skali inwestycji.

Dlaczego klasyczny MES rzadko pasuje na start

Wdrożenie klasycznego systemu MES to zwykle proces liczony w miesiącach, nie w tygodniach, a budżet wyrażony sześciocyfrową kwotą w złotych to raczej dolna granica niż wyjątek, jeśli w grę wchodzi integracja z maszynami, licencje na stanowiska i wdrożeniowcy dostawcy. Do tego dochodzi coś, o czym mało kto mówi wprost: MES wymaga procesów, które są już opisane. Trzeba wiedzieć, jakie są typy przestojów, jakie kody przyczyn, jak wygląda przepływ zlecenia przez halę. W małej fabryce bez działu IT i bez dedykowanego inżyniera procesu ta wiedza często istnieje wyłącznie w głowach kierowników zmian.

Efekt bywa taki, że projekt MES rozjeżdża się na etapie analizy przedwdrożeniowej, bo firma próbuje jednocześnie zbudować standard pracy i wdrożyć narzędzie do jego pomiaru. To się da zrobić, ale kosztuje więcej czasu i pieniędzy, niż zakładano na starcie, a satysfakcja z pierwszych miesięcy używania systemu bywa niska, bo dane, które wpadają do systemu, są niekompletne albo błędne.

Czym jest MES-lite w praktyce

MES-lite to nie produkt, który się kupuje, tylko architektura, którą się składa z prostych klocków. W najbardziej podstawowej wersji potrzebne są trzy elementy: sposób rejestracji zdarzenia na hali, kanał przesyłania tego zdarzenia dalej i miejsce, gdzie dane się agregują i stają się czytelne.

Rejestracja zdarzenia to zwykle jedno z dwóch rozwiązań. Albo prosty czujnik IoT (np. czujnik cyklu maszyny albo czujnik prądowy wykrywający, że silnik stoi), albo tablet lub panel dotykowy przy stanowisku, na którym operator jednym kliknięciem zgłasza start zlecenia, stop, przyczynę przestoju czy brak jakościowy. Czujnik jest dokładniejszy i nie wymaga dyscypliny operatora, ale nie powie, dlaczego maszyna stanęła. Tablet wymaga, żeby ktoś kliknął, ale daje kontekst. W praktyce najlepiej działa połączenie obu: czujnik mówi „stop”, a system od razu wyświetla operatorowi na tablecie pytanie o przyczynę, zanim ten zdąży o tym zapomnieć.

Dane z hali trafiają dalej przez prostą automatyzację, np. w n8n lub Make, która odbiera zgłoszenie (webhook z tabletu, odczyt z czujnika przez bramkę IoT) i zapisuje je w jednym miejscu: arkuszu Google, bazie Airtable albo prostej bazie danych. Ta sama automatyzacja może od razu wysłać powiadomienie do kierownika zmiany, jeśli przestój trwa dłużej niż zadany próg, np. 15 minut, zamiast czekać, aż ktoś zauważy to na koniec dnia.

Ostatni element to warstwa raportowania: prosty dashboard w Looker Studio albo nawet dobrze zbudowany arkusz z tabelą przestawną, który pokazuje sumę przestojów per maszyna, per przyczyna, per zmiana. Nic wymyślnego, ale widoczne dla wszystkich, najlepiej wyświetlane na ekranie na hali.

Minimalny zestaw danych, bez którego raportowanie przestojów nie ma sensu

Widziałem próby zbierania danych, które kończyły się arkuszem pełnym informacji, z których nic nie dało się wyciągnąć. Żeby raportowanie przestojów w ogóle miało wartość analityczną, potrzeba kompletu tych pól przy każdym zdarzeniu:

• identyfikator zlecenia produkcyjnego, którego dotyczy zdarzenie,
• maszyna lub stanowisko, na którym doszło do przestoju,
• moment startu i zakończenia przestoju (nie sam fakt, że wystąpił, tylko czas trwania),
• kod przyczyny z ustalonej z góry, krótkiej listy (awaria, brak materiału, przezbrojenie, przerwa, brak operatora),
• operator lub zmiana, żeby dało się porównać wyniki między brygadami,
• liczba sztuk dobrych i braków wyprodukowanych w danym zleceniu.

Bez kodu przyczyny dane o przestojach są bezużyteczne, bo wiadomo tylko, że maszyna stała, a nie dlaczego. Bez powiązania z konkretnym zleceniem nie da się policzyć, czy dane zlecenie było rentowne. To jest dokładnie ten sam zestaw danych, którego wymaga klasyczny MES, tylko zbierany prostszymi narzędziami i bez konieczności integracji ze sterownikiem PLC każdej maszyny na starcie.

OEE bez systemu klasy enterprise

Wskaźnik OEE (Overall Equipment Effectiveness, całkowita efektywność wyposażenia) to iloczyn trzech składowych: dostępności, wydajności i jakości. Dostępność mówi, jaki procent zaplanowanego czasu pracy maszyna faktycznie pracowała, czyli ile czasu zabrały przestoje. Wydajność pokazuje, czy maszyna pracowała z zakładaną prędkością, czy wolniej niż powinna. Jakość to udział wyrobów dobrych w całości produkcji.

Duża część firm zakłada, że policzenie OEE wymaga systemu, który zbiera dane w czasie rzeczywistym z każdej maszyny. To prawda dla pełnej, ciągłej wersji wskaźnika, ale do pierwszej, wiarygodnej oceny sytuacji wystarczy dokładnie ten zestaw danych opisany wyżej, agregowany choćby raz dziennie. Mając czasy przestojów, planowany czas pracy, liczbę sztuk wyprodukowanych i liczbę braków, OEE liczy się w arkuszu jedną formułą. Nie trzeba do tego dedykowanego modułu raportowego za dodatkowe kilkadziesiąt tysięcy złotych.

Jak wygląda wdrożenie MES-lite krok po kroku

Weźmy typowy przykład: mała firma produkcyjna, dwie linie, ok. 20 osób na hali, dotąd raportowanie przestojów na kartce papieru wpisywanej ręcznie do arkusza pod koniec zmiany. Kierownik wie, że coś nie gra z jedną z linii, ale nie ma jak tego udowodnić zarządowi ani znaleźć konkretnej przyczyny.

Pierwszy krok to nie zakup sprzętu, tylko ustalenie krótkiej, wspólnej listy kodów przyczyn przestojów. Bez tego cała reszta nie ma sensu, bo każdy operator będzie opisywał to samo zdarzenie innymi słowami. Zwykle wystarcza 6-10 kategorii, nie więcej, bo długa lista sprawia, że operator wybiera pierwszą pasującą pozycję zamiast się zastanowić.

Drugi krok to postawienie taniego tabletu przy każdej maszynie z prostym formularzem: start zlecenia, stop z kodem przyczyny, koniec zlecenia z liczbą sztuk dobrych i braków. Formularz zbudowany np. w narzędziu typu Tally albo prostej aplikacji webowej, bez licencji na stanowisko liczonej w setkach złotych miesięcznie.

Trzeci krok to automatyzacja, która odbiera zgłoszenia i buduje z nich historię: n8n albo Make podpięte pod webhook z formularza, zapisujące dane do arkusza lub bazy, z regułą, że przestój dłuższy niż 15 minut trafia od razu jako powiadomienie na Slacka albo SMS do kierownika zmiany. To jest moment, w którym firma pierwszy raz widzi przestój, zanim skończy się zmiana, a nie następnego dnia rano.

Czwarty krok to dashboard widoczny na hali, pokazujący sumę przestojów, ich przyczyny i orientacyjny OEE dla każdej linii z ostatnich 7 dni. Po 4-6 tygodniach takiego zbierania danych zwykle widać wyraźny wzorzec: jedna maszyna generuje 40% wszystkich przestojów z powodu tego samego, konkretnego kodu przyczyny, np. braku materiału z magazynu, a nie awarii mechanicznej, jak wcześniej podejrzewano.

Dopiero z takim raportem w ręku decyzja o dalszej inwestycji, w konkretną naprawę procesu magazynowego, w szkolenie operatorów, a być może rzeczywiście w pełny system MES, jest oparta na danych, a nie na przeczuciu.

Gdzie MES-lite przestaje wystarczać

Trzeba powiedzieć wprost: MES-lite ma sufit. Jeśli firma rośnie, dochodzi kolejna linia, kolejna zmiana, integracja z ERP do automatycznego planowania zleceń, to arkusz i prosta automatyzacja zaczynają się gubić. Ręczne zgłoszenia na tablecie są mniej dokładne niż odczyt bezpośrednio ze sterownika maszyny, zwłaszcza przy bardzo krótkich cyklach, gdzie liczy się różnica kilkudziesięciu sekund. MES-lite nie ma też wbudowanej ścieżki audytowej ani zgodności z normami jakościowymi wymaganymi w niektórych branżach, np. motoryzacyjnej czy spożywczej na wyższym poziomie certyfikacji.

W praktyce widzimy to jako etap przejściowy: 3-12 miesięcy zbierania danych własnymi środkami, po którym firma albo stwierdza, że to wystarcza (bo skala produkcji na to pozwala), albo idzie do wdrożenia pełnego MES, ale już z gotowym opisem procesów, kodów przyczyn i realną wiedzą, co system ma raportować. Ten drugi scenariusz kończy się zwykle krótszym i tańszym wdrożeniem MES, bo dostawca nie musi robić analizy przedwdrożeniowej od zera.

Warto też pamiętać, że dane produkcyjne rzadko żyją w oderwaniu od reszty firmy. Jeśli zlecenie produkcyjne wiąże się z zamówieniem materiałów od dostawcy, naturalnym rozszerzeniem tego samego podejścia jest automatyzacja faktur i dokumentów zakupowych, żeby dane o kosztach materiałowych trafiały do tego samego systemu raportowego co dane o przestojach. A jeśli klienci pytają o status zlecenia telefonicznie albo mailowo, ten sam strumień danych ze zleceń da się wykorzystać do automatycznego informowania ich o postępie, co wchodzi już w obszar automatyzacji obsługi klienta.