Automatyzacja produkcji 2026: najpierw Lean, potem AI (i jak nie zautomatyzować własnego bałaganu)

W większości rozmów z właścicielami małych i średnich fabryk pierwsze pytanie brzmi: "czy możecie zautomatyzować nam cały proces produkcyjny, od zamówienia do faktury". I w większości przypadków odpowiadamy, że nie, przynajmniej nie od razu, bo zanim cokolwiek zautomatyzujemy, chcemy zobaczyć, jak ten proces wygląda naprawdę, a nie jak jest opisany w procedurze wisiącej na tablicy ogłoszeń.

To nie jest ostrożność dla ostrożności. To wniosek z kilku wdrożeń, w których zaczęliśmy od automatyzacji, bo klient się upierał, że "proces jest jasny, trzeba go tylko przenieść do systemu". Pół roku później wracaliśmy do tego samego klienta, bo okazywało się, że proces, który zautomatyzowaliśmy, był jednym z trzech wariantów działania, jakie faktycznie stosowano na hali, zależnie od zmiany, brygadzisty i tego, czy akurat ktoś był na urlopie. Automat działał zgodnie ze specyfikacją. Fabryka działała inaczej. I trzeba było robić to drugi raz, tym razem po audycie procesu, którego nie zrobiliśmy na starcie.

Dlaczego automatyzacja chaosu kończy się szybszym chaosem

Automatyzacja nie naprawia procesu, tylko go przyspiesza i utrwala, taki, jaki jest, z całymi jego wadami. Jeśli proces polega na tym, że brygadzista raportuje przestoje na papierowej kartce, która trafia do biura raz dziennie, a dane są niepełne i często spisywane z pamięci, to podłączenie do tego skanera, formularza mobilnego albo bota, który "automatycznie" wczytuje te dane do systemu ERP, nie rozwiązuje problemu niepełnych danych. Przyspiesza tylko ich wprowadzanie. Dostajemy błędne dane szybciej i w większej skali, bo nagle każdy przestój jest "automatycznie" rejestrowany, łącznie z tymi, które ktoś wcześniej po prostu olewał, bo nie miał czasu.

Mamy u klientów kilka powtarzających się wzorców tego zjawiska. Najczęstszy dotyczy właśnie raportowania przestojów. Firma produkcyjna chce dashboard OEE (wskaźnik efektywności wykorzystania maszyn) w czasie rzeczywistym, bo "trzeba wiedzieć, gdzie się traci czas". Problem jest w tym, że kody przyczyn przestojów, które operatorzy mają wybierać, były ustalane dekadę temu, nikt ich nie przegląda, a połowa przestojów i tak trafia do kategorii "inne", bo nikt nie chce się zastanawiać, który z 40 kodów wybrać w pięć sekund, stojąc przy maszynie. Zautomatyzowanie zbierania tych danych, zamiast najpierw uproszczenia listy kodów do kilku, które faktycznie mają sens operacyjny, daje w efekcie bardzo szybko generowany, bardzo kolorowy, bardzo bezużyteczny dashboard.

Drugi wzorzec to zlecenia produkcyjne. W małej fabryce zlecenie często żyje w trzech miejscach naraz: w arkuszu Excela planisty, w papierowej karcie na hali i w głowie kierownika zmiany, który "wie, co trzeba zmienić, bo klient dzwonił". Kiedy automatyzujemy generowanie i obieg zleceń bez wcześniejszego ustalenia jednego źródła prawdy, dostajemy system, który pięknie generuje dokumenty na podstawie danych, które i tak trzeba będzie korygować ręcznie na hali, bo system nie wie o telefonie od klienta. Efekt: ludzie zaczynają obchodzić system, bo jest "wolniejszy niż było wcześniej", i po trzech miesiącach wracamy do Excela, tylko teraz równolegle z kosztownym systemem, który stoi i się nie używa.

Gdzie w tym miejscu jest Lean i dlaczego nie można go pominąć

Nie jesteśmy firmą konsultingową Lean i nie prowadzimy wdrożeń Kaizen jako samodzielnej usługi. Ale korzystamy z dwóch klasycznych narzędzi Lean na etapie audytu, bo bez nich nie wiemy, co właściwie mamy zautomatyzować.

Mapa strumienia wartości jako punkt wyjścia

Mapa strumienia wartości (Value Stream Mapping) pokazuje, co faktycznie dzieje się od momentu przyjęcia zamówienia do wysyłki gotowego produktu, z czasami, zapasami międzyoperacyjnymi i miejscami, w których proces czeka. W praktyce robimy to z kierownikiem produkcji i kilkoma operatorami, na tablicy albo w arkuszu, krok po kroku, bez komputera. Zazwyczaj okazuje się, że z ośmiu kroków procesu trzy to czyste czekanie, informacja wisi gdzieś między działem handlowym a produkcją i nikt formalnie nie jest właścicielem momentu przekazania zlecenia z planowania na halę.

To jest moment, w którym widać, gdzie automatyzacja ma sens, a gdzie nie. Jeśli krok procesu polega na czekaniu, bo informacja fizycznie nie dociera na czas, automatyzacja przepływu informacji (np. automatyczne powiadomienie z systemu zamówień do planisty produkcji) ma ogromny sens, bo eliminuje czyste marnotrawstwo czasu. Jeśli krok procesu polega na tym, że człowiek podejmuje decyzję na podstawie niejasnych kryteriów, automatyzacja tego kroku bez wcześniejszego ustalenia kryteriów po prostu zamroziła niejasność w kodzie.

5S na hali przed czujnikami i integracjami

5S (selekcja, systematyka, sprzątanie, standaryzacja, samodyscyplina) brzmi jak temat zupełnie oddzielny od AI i automatyzacji, ale w praktyce decyduje o tym, czy dane, które chcemy zbierać automatycznie, mają sens. Mieliśmy sytuację, w której klient chciał czujniki zliczające cykle maszyny do automatycznego raportowania wydajności, a maszyna fizycznie stała w miejscu, gdzie brakowało jej części zamiennych w zasięgu ręki, więc operator co godzinę chodził po nie na drugi koniec hali. Czujnik pokazałby bardzo dokładnie, jak nieefektywnie wygląda proces, ale sam problem leżał w organizacji stanowiska pracy, nie w braku danych. 5S najpierw, czujniki później, bo inaczej płacimy za bardzo precyzyjny pomiar bałaganu.

Kiedy Lean się kończy, a zaczyna automatyzacja z AI

To jest pytanie, które najczęściej dostajemy po tym, jak klient już zrozumiał, że "najpierw proces, potem system". Odpowiedź, którą dajemy, jest dość konkretna: Lean kończy swoją robotę w momencie, gdy proces jest ustandaryzowany i powtarzalny, czyli krok wykonywany jest tak samo niezależnie od tego, kto go robi i na której zmianie. Nie musi być idealny. Musi być jednoznaczny.

Od tego momentu zaczynamy patrzeć na automatyzację, i tu robimy rozróżnienie, które w naszej pracy jest kluczowe: są kroki, które nadają się do prostej automatyzacji reguł (RPA, integracje, formularze, boty workflow), i są kroki, w których potrzebna jest AI, bo wymagają interpretacji, a nie tylko przekazania danych z punktu A do punktu B.

Przykład z raportowania przestojów po uporządkowaniu kodów przyczyn: jeśli lista kodów jest już krótka i jasna, prosty formularz na tablecie przy maszynie z automatycznym wysyłaniem do systemu to wystarczająca automatyzacja, bez AI. AI wchodzi do gry wtedy, kiedy chcemy, żeby system sam zaproponował kategorię przestoju na podstawie krótkiego opisu wpisanego przez operatora głosowo lub tekstowo ("pasek się zerwał na stacji 3"), albo kiedy chcemy, by system z historii przestojów wykrywał wzorce, które człowiekowi trudno zauważyć, bo analizuje dane z trzech zmian na raz. To są dwa różne poziomy problemu i mieszanie ich na starcie, czyli próba "od razu dać AI", zanim mamy ustandaryzowany, czysty zbiór danych, kończy się modelem, który uczy się na śmieciach i daje równie śmieciowe prognozy.

Podobnie ze zleceniami produkcyjnymi: po ustaleniu jednego źródła prawdy (np. jeden system, do którego trafiają zamówienia, zamiast trzech równoległych list), automatyzacja generowania zleceń na podstawie zamówień to zadanie integracyjne, nie zadanie dla AI. AI ma sens w momencie, gdy trzeba na przykład automatycznie priorytetyzować kolejkę zleceń na podstawie terminów, dostępności materiałów i obciążenia maszyn, czyli tam, gdzie decyzja wymaga ważenia kilku zmiennych naraz, a nie tylko przeniesienia danych z formularza do bazy. Więcej o tym, jak to wygląda w praktyce przy obiegu dokumentów i zleceń, opisujemy przy okazji automatyzacji faktur, gdzie problem jest strukturalnie bardzo podobny: najpierw trzeba ustandaryzować sposób, w jaki dokumenty wchodzą do firmy, zanim AI zacznie je sensownie czytać i klasyfikować.

Realna kolejność kroków, którą stosujemy

Nie mamy jednego sztywnego szablonu dla każdej fabryki, bo każda ma inny poziom bałaganu i inny budżet czasu, ale sekwencja, która się u nas powtarza, wygląda tak:

• Audyt na żywo, nie na papierze. Idziemy na halę i patrzymy, jak proces faktycznie przebiega, zamiast czytać procedurę. Rozmawiamy z operatorami, nie tylko z kierownikiem.
• Mapa strumienia wartości dla 1-2 kluczowych procesów. Nie mapujemy całej fabryki na raz, to się nigdy nie kończy. Wybieramy proces, który boli najbardziej, np. ten, w którym codziennie ktoś traci godzinę i więcej na przepisywanie danych między systemami lub kartkami.
• Standaryzacja kroku przed jego automatyzacją. Ustalamy jeden sposób wykonania danego kroku, wspólnie z ludźmi, którzy go wykonują, nie zza biurka.
• Pilotaż automatyzacji na jednym procesie. Dopiero teraz wchodzi system, integracja albo automatyzacja z AI, w jednym, dobrze zrozumianym miejscu, nie na całej hali naraz.
• Dopiero po stabilizacji pilotażu: skalowanie na kolejne procesy. I tu dokładamy AI tam, gdzie faktycznie jest potrzebna interpretacja danych, a nie wszędzie, bo "AI jest teraz na topie".

To, co w tej liście jest najmniej wygodne dla klienta, to krok trzeci, bo standaryzacja wymaga rozmowy z ludźmi, czasem konfliktu, czasem ustalenia, że "zawsze tak robiliśmy" nie jest wystarczającym argumentem. Łatwiej jest kupić system i mieć wrażenie, że problem jest rozwiązany, niż usiąść z brygadzistami i ustalić jeden sposób raportowania przestojów. Ale to właśnie ten krok, pominięty, jest najczęstszym powodem, dla którego za sześć miesięcy wracamy do tego samego klienta z tym samym problemem, tylko droższym.

Gdzie automatyzacja z AI realnie daje efekt w małej fabryce

Po przejściu tej sekwencji, automatyzacja z AI w produkcji MŚP najczęściej daje efekt w trzech miejscach, i to są miejsca, w których widzimy powtarzalny, mierzalny zysk, nie efekt demo.

Pierwsze to klasyfikacja i opisywanie zgłoszeń z hali, czyli zamiana krótkiego, często niechlujnego opisu problemu wpisanego przez operatora w pełny, skategoryzowany zapis zdarzenia, gotowy do analizy. Drugie to analiza trendów przestojów i awarii z wielu zmian i maszyn naraz, czego człowiek nie zrobi systematycznie, bo nie ma czasu codziennie przeglądać setek wierszy danych. Trzecie to automatyczne generowanie raportów produkcyjnych dla kierownictwa na podstawie danych, które wcześniej ktoś musiał ręcznie zestawiać w Excelu, często w piątek po południu, pod presją czasu, co samo w sobie jest źródłem błędów.

Warto też powiedzieć wprost, czego automatyzacja z AI w tym kontekście nie zrobi, bo to ważne dla wiarygodności całego podejścia: nie zastąpi decyzji o tym, czy przestawić linię na inny produkt w trakcie zmiany, nie podejmie decyzji o reklamacji klienta bez udziału człowieka, i nie naprawi złej komunikacji między działem handlowym a produkcją, jeśli ta komunikacja odbywa się głównie przez nieformalne telefony. Automat robi dobrze te 70-80% sytuacji standardowych, powtarzalnych. Wyjątek, niestandardowe zamówienie, awaria krytyczna, reklamacja, zawsze trafia do człowieka, i to jest zaprojektowane celowo, nie jest to ograniczenie, które trzeba "jeszcze dopracować".

Ta logika, uproszczenie procesu przed włączeniem AI, dotyczy nie tylko samej hali produkcyjnej. Te same wzorce widzimy przy wdrożeniach w biurach rachunkowych obsługujących firmy produkcyjne: tam też najpierw trzeba ustandaryzować obieg dokumentów między produkcją a księgowością, zanim automatyzacja czegokolwiek zacznie przynosić efekt, a nie tylko przyspieszać przekazywanie niekompletnych danych.