AI w planowaniu produkcji: lepsze harmonogramy bez chaosu w ERP

Dlaczego klasyczne ERP nie radzi sobie z planowaniem produkcji

ERP kontra rzeczywistość hali produkcyjnej

System ERP świetnie radzi sobie z fakturą, magazynem, MRP i kontrolą kosztów, ale na hali produkcyjnej często wygląda to tak, jakby ktoś próbował grać w szachy przy użyciu kalka i długopisu. Teoretycznie wszystkie informacje są, praktycznie – planista i tak spędza wieczory w Excelu.

ERP działa przede wszystkim jako centralny rejestr zdarzeń i zasobów. Przechowuje zamówienia, zlecenia produkcyjne, BOM-y, marszruty, stany magazynowe i kalendarze. Jego główna rola to:

• utrzymywanie spójności danych w całej firmie,
• pilnowanie, by dokumenty i zlecenia miały komplety informacji,
• wspieranie rozliczeń, księgowości, controllingu,
• generowanie zleceń i zapotrzebowań na podstawie MRP i zamówień klientów.

To wszystko jest niezbędne, ale planowanie produkcji oznacza coś więcej niż „ustawić datę startu i końca zlecenia”. W realnym świecie zmienia się obsada, psuje się maszyna, klient przyspiesza termin, a operator wpisuje inne czasy niż książkowe. I tu klasyczny ERP zwykle się wykłada.

Gdzie ERP gubi się w szczegółach i zmienności

Największy problem ERP w planowaniu to poziom szczegółowości i brak elastycznej optymalizacji. System widzi operacje, czasy technologiczne, kalendarz pracy, ale:

• nie uwzględnia dobrze nieplanowanych zdarzeń (awaria, braki, absencje),
• często przyjmuje czasy normatywne, a nie rzeczywiste,
• nie radzi sobie z kolejnością zleceń, minimalizacją przezbrojeń czy WIP,
• działa „zlecenie po zleceniu”, bez globalnej optymalizacji całej linii lub gniazda.

Do tego dochodzi brak prognozowania. ERP zwykle liczy na bazie tego, co ma w danych statycznych: normy, marszruty, kalendarze. Nie patrzy na historię odchyleń, nie przewiduje, kiedy linia się „zakorkuje”, a kiedy będzie luz. Efekt? Plany na ekranie wyglądają pięknie, a na produkcji powstaje kolejka w jednym miejscu i przestoje w innym.

Planista jako wąskie gardło – sygnały, że ERP nie domaga

Jeżeli w firmie istnieje główny plik Excel „święty”, którym nikt spoza działu planowania nie może nawet oddychać – to jasny znak, że ERP nie wystarcza. Typowe objawy:

• planista codziennie rano przepisywuje dane z ERP do własnych arkuszy,
• większość ustaleń co do kolejności zleceń zapada „na kartce” lub przy tablicy na hali,
• zmiana planu oznacza lawinę ręcznych korekt w kilku systemach i plikach,
• tylko jedna lub dwie osoby „wiedzą, jak to naprawdę działa” – cała logika siedzi im w głowie.

W efekcie planista staje się wąskim gardłem. Gdy jest na urlopie, wszyscy chodzą na palcach, bo „nikt nie wie, co z tymi zleceniami zrobić”. Taki model jest nie tylko ryzykowny, ale też zabija skalowalność – przy wzroście liczby zleceń planowanie rośnie wykładniczo w złożoności.

Produkcja z papieru a produkcja, która da się naprawdę wykonać

Plan „na papierze” (lub w ERP) często zakłada:

• idealne czasy trwania operacji,
• pełną dostępność operatorów i maszyn,
• brak awarii, brak mikropostojów, brak problemów jakościowych,
• zerowe czasy komunikacji i logistyki wewnętrznej.

Tymczasem plan wykonalny na zmianie musi uwzględnić wszystkie te „detale”, które w ERP giną w uproszczeniach. Na przykład:

• operator, który ma praktycznie 20% wolniej na określonej referencji niż norma technologiczna,
• gniazdo, które zawsze ma 15 minut „przestoju organizacyjnego” po zmianie asortymentu,
• dostawę komponentów, która teoretycznie jest „na magazynie”, a praktycznie stoi na rampie.

AI w planowaniu produkcji nie naprawi ERP, ale może wypełnić lukę między „teorią” a rzeczywistością, pod warunkiem że jest dobrze zintegrowana i oparta na realnych danych z produkcji, a nie tylko na tym, co wpisano do systemu lata temu.

Co AI realnie może zrobić w planowaniu produkcji (bez magii)

Kluczowe zadania AI w harmonogramowaniu zleceń

AI w planowaniu produkcji działa najlepiej, gdy ma jasno określone zadania. Zamiast ogólnego „zoptymalizuj wszystko”, lepiej mówić o konkretnych obszarach:

• prognozowanie czasów operacji na bazie danych historycznych i bieżących warunków,
• optymalizacja kolejności zleceń z uwzględnieniem przezbrojeń i priorytetów,
• przydział zleceń do maszyn w sposób minimalizujący przestoje i wąskie gardła,
• koordynacja gniazd – tak, by półprodukty nie czekały w kolejkach niepotrzebnie.

AI nie musi od razu podejmować wszystkich decyzji. W wielu firmach na początek sensowny jest scenariusz, w którym AI:

• proponuje harmonogram,
• pokazuje wpływ proponowanych zmian na terminy dostaw, obciążenie maszyn, WIP,
• oddaje planistom możliwość ręcznej korekty.

Kluczowe jest, by system działał jako wsparcie decyzyjne, a nie „czarna skrzynka, której nie można dotknąć”. Planista musi rozumieć, co AI zrobiła i dlaczego, inaczej skończy się na klikaniu „przelicz jeszcze raz, bo mi się nie podoba”.

Predykcja czasów, awarii i przezbrojeń

Jedno z najpraktyczniejszych zastosowań AI to prognozowanie czasów realizacji operacji i przezbrojeń. Zamiast sztywnych norm z technologii można użyć modeli uczonych na:

• historii produkcji,
• danych z MES/SCADA (przestoje, prędkości rzeczywiste),
• informacjach o operatorach, zmianach, materiałach, partiach.

Model może np. stwierdzić, że:

• referencja A produkowana w nocy trwa o 10–15% dłużej,
• na maszynie M2 operatorzy B i C mają stałe odchylenie od normy,
• po określonej sekwencji przezbrojeń występują mikropostoje, które realnie wydłużają cykl.

Podobnie z awariami i przestojami. Modele predykcji mogą wskazywać:

• zwiększone ryzyko nieplanowanego postoju,
• maszyny, które zbliżają się do granicy bezpiecznej pracy,
• obszary, gdzie trzeba „dmuchać na zimne” i planować bufor czasu.

Nikt nie wymaga od AI jasnowidzenia. Ale jeżeli system potrafi przewidzieć, że na maszynie X z wysokim prawdopodobieństwem w ciągu 2–3 dni pojawi się problem, to harmonogram może to uwzględnić – przesuwając kluczowe zlecenia na inne okno czasowe lub inną maszynę.

Optymalizacja kolejek, WIP i obciążenia

Drugi mocny obszar to optymalizacja kolejek zleceń. W wielu halach produkcyjnych wystarczy przejść się między gniazdami, żeby zobaczyć:

• stos półproduktów czekających na obróbkę,
• maszynę, która ma wolne moce, ale „czeka na swoją kolej”,
• linie, na których produkowane są serie nie w tej kolejności, która byłaby najmniej uciążliwa.

AI może liczyć różne warianty kolejek zleceń, uwzględniając:

• terminy zamówień klienta,
• czasy przezbrojeń zależne od kolejności,
• poziom zapasów w toku (WIP),
• dostępność ludzi, narzędzi, form.

Zamiast jednego „sztywnego” planu, dostaje się zestaw scenariuszy, np.:

• wariant A – maksymalna terminowość, kosztem większej liczby przezbrojeń,
• wariant B – minimalizacja przezbrojeń i kosztów, kosztem lekkiego ryzyka opóźnień dla niektórych klientów,
• wariant C – priorytet na kluczowych klientów i zamówienia ekspresowe.

Taka gra scenariuszami to codzienność dobrego planisty. AI nie robi tu magii – jedynie liczy szybciej i w większej liczbie wymiarów, niż człowiek jest w stanie ogarnąć ręcznie.

Reakcja na zakłócenia: rush order, braki, absencje

Największa różnica między „statycznym” ERP a AI w planowaniu produkcji wychodzi na jaw w momencie zakłóceń:

• pojawia się rush order od kluczowego klienta,
• dostawa materiału ma opóźnienie,
• dwóch operatorów z kluczowego gniazda idzie na zwolnienie,
• maszyna zatrzymuje się na awarię.

ERP zwykle oczekuje, że planista ręcznie przeanalizuje wpływ takich zmian. AI może:

• szybko przeliczyć nowe obciążenie,
• zaproponować, które zlecenia przesunąć,
• wskazać, które terminy dostaw są zagrożone i w jakim stopniu,
• pokazać alternatywne ścieżki produkcji, jeśli istnieją.

Co istotne, dobrze zaprojektowany system nie powinien „łamać” całego planu z powodu jednego zlecenia. Zamiast tego rekomenduje minimalny zestaw zmian, który pozwala wpasować rush order przy akceptowalnym wpływie na resztę portfela zleceń.

AI jako turbo-kalkulator, a planista jako właściciel decyzji

Najrozsądniejszy model pracy to taki, w którym:

• AI robi ciężką pracę liczbową,
• planista weryfikuje, koryguje i decyduje,
• firma jasno określa, jakie decyzje może podejmować system, a jakie zostają po stronie ludzi.

Dzięki temu:

• planista zamiast przepisywać dane może skupić się na wyjątkach i komunikacji z produkcją oraz sprzedażą,
• decyzje są spójne i oparte na danych, a nie na „nastroju dnia”,
• łatwiej jest też uczyć nowych planistów, bo część „know-how” przechwyca AI.

Granice możliwości AI są jasne: nie widzi ona całego kontekstu politycznego i relacyjnego. Nie zna historii klienta, jego wrażliwości cenowej, strategii handlowców, planów zarządu. Dlatego zawsze ostatnie słowo powinien mieć człowiek – przynajmniej w krytycznych decyzjach.

Podstawy techniczne – jakie typy AI przydają się w planowaniu

Uczenie maszynowe do prognoz i szacowania ryzyka

Pierwsza grupa technologii to modele uczenia maszynowego (ML), które pomagają lepiej oszacować parametry wejściowe do planowania:

• rzeczywiste czasy trwania operacji,
• czasy przezbrojeń w zależności od sekwencji produktów,
• prawdopodobieństwo awarii lub przestoju,
• prawdopodobieństwo braków jakościowych (scrap rate).

Modele mogą być proste (regresja, drzewa decyzyjne, gradient boosting) lub bardziej złożone (sieci neuronowe). Najczęściej wystarczy jednak dobrze przygotowany model tablicowy, który:

• bierze pod uwagę typ produktu, maszynę, operatora, zmianę,
• uczy się na historii, jak te czynniki wpływały na realne czasy,
• zwraca prognozę czasu operacji wraz z przedziałem niepewności.

Taka prognoza zastępuje sztywny czas technologiczny w algorytmach harmonogramowania, dzięki czemu plan staje się bliższy rzeczywistości już na starcie.

Algorytmy optymalizacyjne i metaheurystyki

Druga grupa technologii to algorytmy optymalizacyjne, które układają harmonogram. W zależności od specyfiki produkcji mogą to być:

• metody programowania liniowego / mieszanego (LP/MIP),
• metaheurystyki (algorytmy genetyczne, symulowane wyżarzanie, tabu search),
• algorytmy hybrydowe łączące klasyczną optymalizację z ML.

Klasyczne APS często opierają się właśnie na tego typu algorytmach. AI dodaje tu:

Reinforcement learning i planowanie sekwencyjne

Trzecia grupa technik, która coraz częściej wchodzi na hale, to uczenie ze wzmocnieniem (reinforcement learning, RL). Tu system nie tylko liczy harmonogram „na raz”, ale uczy się, jak reagować na zmiany w czasie:

• dostaje aktualny stan: obciążenie maszyn, kolejki, opóźnienia,
• podejmuje zestaw decyzji: które zlecenia przesunąć, które przyspieszyć, które opóźnić,
• dostaje „nagrodę” lub „karę” – np. za dotrzymanie terminów, liczbę przezbrojeń, poziom WIP,
• na tej podstawie uczy się polityki, czyli sposobu działania przy różnych sytuacjach.

W praktyce RL przydaje się szczególnie w środowiskach, gdzie plan jest ciągle w ruchu – dużo zakłóceń, krótkie serie, częste rush orders. Zamiast za każdym razem liczyć wszystko od zera, agent RL uczy się:

• jak mocno „dotykać” plan przy nowych zakłóceniach,
• które zmiany zazwyczaj bardziej szkodzą niż pomagają,
• jak utrzymać stabilność planu przy rozsądnej reaktywności.

Warunek powodzenia jest jeden: RL nie uczy się na żywym organizmie. Najpierw trzeba zbudować symulator produkcji (przynajmniej uproszczony) i tam „przepalić” tysiące scenariuszy. Dopiero potem takie polityki można przenosić do realnego systemu – i nadal mocno je pilnować w pierwszych tygodniach.

Modele generatywne jako wsparcie, nie „mózg planowania”

Nowa modna kategoria to modele generatywne (w tym duże modele językowe). W planowaniu produkcji nie powinny one jednak decydować o kolejności zleceń, tylko raczej:

• pomagać opisywać i wyjaśniać decyzje systemu,
• tworzyć czytelne raporty dla produkcji, sprzedaży, zarządu,
• wspierać konfigurację i parametryzację algorytmów poprzez dialog z planistą.

Przykład z życia: planista patrzy na ekran i pyta w interfejsie tekstowym „dlaczego te dwa zlecenia zamieniłeś miejscami?”. Model generatywny tłumaczy logikę na ludzki język:

• „Zamieniłem kolejność, bo zlecenie Z123 ma termin o 2 dni wcześniejszy, a przezbrojenie z produktu A na B zajmuje krócej niż z B na A, co skraca łączny czas o ok. 40 minut przy zachowaniu terminów pozostałych zleceń”.

Takie „opisowe” warstwy AI obniżają barierę wejścia dla planistów i pomagają zbudować zaufanie do systemu. Nie zastępują jednak twardego silnika optymalizacyjnego – są raczej tłumaczem między światem matematyki a praktyką hali.

Dane – paliwo dla AI w planowaniu produkcji

Jakie dane są naprawdę potrzebne (a jakie można sobie odpuścić na start)

Zanim pojawi się jakakolwiek „inteligencja”, trzeba mieć czym ją karmić. W planowaniu produkcji najważniejsze są:

• historia zleceń – co, kiedy, na jakiej maszynie, w jakich ilościach,
• czasy rzeczywiste – start/stop operacji, przezbrojenia, przestoje,
• dane o zasobach – maszyny, gniazda, ludzie, kwalifikacje, narzędzia,
• struktury produktów i marszruty – BOM, operacje, zależności, alternatywy,
• jakość – scrap rate, przyczyny braków, reklamacje.

Częsty błąd to paraliż w stylu: „dopóki nie uporządkujemy wszystkich danych w ERP, nie ma sensu zaczynać z AI”. Zwykle da się zacząć od:

• 1–2 kluczowych rodzin produktów,
• kilku gniazd o największym obciążeniu lub problemach,
• ostatnich 6–12 miesięcy historii zamiast archiwów z poprzedniej dekady.

Lepszy jest mniejszy, ale wiarygodny wycinek danych niż perfekcyjna, ale nierealna wizja „pełnej hurtowni, kiedyś tam”.

Źródła danych: ERP, MES, arkusze i… notatniki

W większości zakładów dane są rozproszone:

• ERP trzyma zlecenia, BOM-y, marszruty,
• MES/SCADA rejestruje czasy, przestoje, alarmy,
• HR lub inny system – grafiki i kwalifikacje ludzi,
• arkusze Excela planistów – „prawdziwy plan”,
• czasem jeszcze zeszyty mistrzów z własnymi notatkami.

Budując AI do planowania, trzeba przygotować warstwę integracyjną, która:

• zbierze te dane w jednym miejscu (hurtownia, lakehouse, cokolwiek sensownie utrzymywalnego),
• zmapuje podstawowe identyfikatory (numery zleceń, maszyn, indeksów),
• usunie oczywiste duplikaty i sprzeczności,
• doda znaczniki czasu tak, by dało się odtworzyć sekwencję zdarzeń.

Na etapie pierwszych pilotaży nikt nie oczekuje kosmicznych standardów data governance. Wystarczy, że dane są wystarczająco dobre, by modele mogły się na nich czegoś nauczyć i żeby błędy nie fałszowały całego obrazu.

Jakość danych: typowe problemy i proste usprawnienia

Typowe potknięcia przy danych do planowania:

• czasy z ERP nie zgadzają się z rzeczywistością – bo nikt ich nie aktualizował od lat,
• brak rozróżnienia między przezbrojeniem a awarią – wszystko jest jednym „postojem”,
• start/stop operacji klika się hurtowo pod koniec zmiany, więc znaczniki czasu są fikcją,
• nieprecyzyjne kody przyczyn – „inne”, „pozostałe”, „błąd operatora” jako domyślne odpowiedzi.

Zanim ktoś zacznie inwestować w „zaawansowane AI”, często wystarczy kilka prostych kroków:

• uszczegółowić kategorie przestojów (awaria / przezbrojenie / brak materiału / organizacyjne),
• uprościć ekrany rejestracji tak, by operator miał mniej pól do klikania, ale za to bardziej sensowne,
• wprowadzić prostą kontrolę: jeśli operacja trwa według systemu 0 minut lub 3 dni, to trafia na listę do weryfikacji,
• umówić się, że kilka kluczowych gniazd raportuje dane rzetelniej – nawet kosztem pełnej ewidencji w reszcie zakładu.

To nie jest „projekt data governance na dwa lata”. To raczej kilka tygodni pragmatycznych zmian, które podniosą jakość danych do poziomu używalnego dla modeli.

Labelowanie i inżynieria cech: jak przełożyć surowe logi na coś sensownego

Surowe logi z MES czy ERP same z siebie niewiele mówią. Trzeba je przekształcić w cechy (features), na których AI rzeczywiście może pracować. W planowaniu są to m.in.:

• czas operacji podzielony na: właściwą produkcję, przezbrojenie, mikroprzestoje,
• charakterystyki partii: wielkość, wariant, poziom złożoności,
• kontekst: zmiana dzienna/nocna, dzień tygodnia, sezonowość,
• historia maszyny: czas od ostatniego przeglądu, liczba godzin pracy, liczba ostatnich awarii.

Bez sensownej inżynierii cech modele ML albo nie „złapią” zależności, albo zaczną uczyć się śmieci. Tu bardzo pomaga współpraca:

• planisty i mistrzów – którzy wiedzą, co realnie wpływa na czasy,
• analityków danych – którzy wiedzą, jak to zakodować w danych.

Jeśli zespół na warsztacie mówi: „ta referencja na nocnej zawsze idzie wolniej, a jak operator X jest sam na zmianie, to już w ogóle”, to jest to bezcenna wskazówka do zbudowania właściwych cech w modelu.

Architektura: AI obok ERP, a nie zamiast

Dlaczego AI nie powinna siedzieć „w środku” ERP

ERP jest systemem transakcyjnym: ma przyjmować zamówienia, rejestrować zlecenia, księgować dokumenty. Wciskanie zaawansowanego planowania i AI w sam środek ERP kończy się zwykle:

• koszmarem upgrade’ów (każda nowa wersja ERP = strach o niestandardowe algorytmy),
• ograniczeniami wydajności (baza ERP nie lubi ciężkich obliczeń),
• brakiem elastyczności (każda zmiana w logice AI wymaga projektu deweloperskiego w ERP).

Znacznie sensowniejsze jest postawienie oddzielnego modułu planistycznego z komponentami AI, który:

• czyta dane z ERP (i innych systemów),
• liczy harmonogramy i scenariusze,
• zwraca wyniki do ERP w postaci planu lub zleceń zaktualizowanych o terminy i przydziały.

ERP pozostaje wtedy źródłem prawdy o danych podstawowych i zleceniach, a AI staje się „mózgiem planowania” obok, nie „mutacją ERP”.

Warstwa integracji: jakie interfejsy są naprawdę potrzebne

Od strony technicznej integracja AI z ERP i MES zwykle sprowadza się do kilku kluczowych przepływów:

• import stanu – zlecenia otwarte, stan realizacji, dostępne moce, zapasy,
• eksport planu – przypisanie zleceń do maszyn, kolejność, okna czasowe,
• aktualizacje w trakcie dnia – informacje o awariach, rush orders, brakach materiałowych,
• feedback historyczny – zrealizowane czasy, przestoje, opóźnienia, które zasilają modele ML.

Technicznie można to zrobić:

• klasycznymi interfejsami plikowymi (CSV, XML) – prosto, ale z opóźnieniem,
• API/REST – dla bardziej „online’owej” pracy,
• kolejkami komunikatów (MQ, Kafka) – przy dużej skali i wysokiej dynamice zdarzeń.

W pierwszym kroku często wystarczy prosty mechanizm: kilka raz dziennie pełny import i eksport (np. co 2–4 godziny), a w przyszłości – przejście na bardziej ciągłą synchronizację.

Gdzie fizycznie „mieszka” AI: on-prem, chmura, hybryda

Decyzja o tym, gdzie uruchomić komponenty AI, zależy od:

• wymogów bezpieczeństwa i zgodności (branże wrażliwe, np. automotive, lotnictwo),
• dostępności infrastruktury IT na miejscu,
• potrzeby reakcji w czasie zbliżonym do rzeczywistego.

Najczęstsze scenariusze:

• on-premise – gdy dane „nie mogą wyjść z zakładu”, a IT ma zasoby do utrzymania klastrów obliczeniowych,
• chmura – elastyczność mocy obliczeniowej, łatwiejsze aktualizacje, ale wymaga dobrego zabezpieczenia i wyjaśnienia kwestii prawnych,
• hybryda – część analityczna (trening modeli, symulacje) w chmurze, a silnik harmonogramowania na miejscu, zasilany gotowymi modelami.

Ważne, by architektura umożliwiała aktualizację modeli bez zatrzymywania całej produkcji. Modele trzeba okresowo douczać na nowych danych; system nie może być „wypalony” raz na zawsze.

Warstwa prezentacji: jak podać plan, żeby ktoś chciał z niego korzystać

Nawet najlepszy algorytm można zabić kiepskim interfejsem. Planista potrzebuje:

• podglądu planu w czasie (oś czasu, Gantt) z możliwością łatwego przesuwania zleceń,
• szybkiego filtrowania po kliencie, maszynie, referencji, poziomie zagrożenia terminu,
• widoku „przed/po” – co AI zmieniła względem poprzedniego planu,
• wyjaśnień, dlaczego konkretne zlecenie trafiło tam, gdzie trafiło.

Dla produkcji przydadzą się prostsze widoki:

• lista zleceń na zmianę / dzień na każdą maszynę,
• czytelne oznaczenia priorytetów (ekspres, standard, niski),
• informacje o przewidywanych przezbrojeniach i wymaganych narzędziach.

Tryb współpracy: człowiek decyduje, AI podpowiada

Największa pułapka przy wdrażaniu AI w planowaniu to traktowanie jej jak „czarnej skrzynki, która wie lepiej”. W praktyce najlepiej sprawdza się model, w którym:

• AI generuje propozycję planu – z uwzględnieniem ograniczeń, priorytetów, czasów,
• planista robi przegląd i korekty – zwłaszcza w miejscach, gdzie zna ryzyka,
• system zapisuje co zostało zmienione względem propozycji AI i dlaczego.

Ten ostatni punkt jest kluczowy: jeśli planista zawsze ręcznie „poprawia” konkretne sytuacje (np. pewną maszynę omija przy krótkich seriach, bo realnie robi wolno przezbrojenia), to jest to sygnał dla zespołu, że:

• brakuje odpowiedniej cechy w modelu,
• albo parametry (czasy, kalendarz, priorytety) są źle ustawione.

Zamiast kłócić się, kto ma rację – planista czy algorytm – lepiej włączyć ten konflikt w pętlę uczenia. AI ma być „junior plannerem”, który z czasem coraz mniej wymaga poprawek, a nie nieomylnym szefem produkcji.

Wyjaśnialność: dlaczego zlecenie trafiło właśnie tam

Jeśli system ma realnie wspierać planistę, a nie go irytować, musi tłumaczyć swoje wybory. Nie chodzi o doktorat z teorii grafów, tylko o kilka prostych wskazówek:

• „zlecenie X przydzielono na maszynę M3, bo: krótszy czas przezbrojenia o 20 minut względem M2, brak konfliktu z priorytetem klienta A, dostępny operator z kwalifikacją Q”
• „zlecenie Y przesunięto o 1 dzień, bo: brak materiału do godziny 10:00, blokada gniazda przez awarię Z”

Technicznie można to zrealizować na dwa sposoby:

• wyjaśnialność heurystyk – zasady rozwiązywania konfliktów opisane w zrozumiały sposób,
• narzędzia XAI (SHAP, LIME itp.) – dla modeli ML szacujących np. realne czasy operacji.

Planista nie musi znać skrótów rodem z konferencji AI, ale doceni prosty wniosek typu: „kluczowy wpływ na kolejność miały: priorytet klienta, długość serii, przezbrojenia”.

Jak przełożyć praktykę planowania na parametry dla AI

Od „tak zawsze robimy” do jaskini konkretów

W każdym zakładzie funkcjonują niepisane zasady planowania:

• „tego klienta nie wolno spóźnić”,
• „po tej referencji zawsze robimy tamtą, bo kolory”,
• „na nocnej tej operacji lepiej nie puszczać, bo za dużo poprawek”.

AI nie zrozumie takich ogólników. Trzeba je rozebrać na części pierwsze i zamienić na mierzalne parametry. Przykłady:

• „nie spóźnić” → maksymalne dopuszczalne opóźnienie w godzinach / dniach, inna kara w funkcji celu,
• „po tej referencji tamta” → macierz kosztów przezbrojeń między kombinacjami maszyna–produkt,
• „na nocnej nie puszczamy” → ograniczenie kalendarza: produkt X tylko na zmianach 1–2.

Dobry warsztat startowy z planistami i mistrzami powinien wyprodukować listę takich „reguł z korytarza”, a potem wspólnie ustalić, jak je zmaterializować w:

• parametrach optymalizacyjnych (wagi, kary, ograniczenia),
• cechach wejściowych do modeli ML (zmiana, typ produktu, rodzaj klienta itp.).

Funkcja celu: co tak naprawdę ma być „najlepsze”

Plan „idealny” dla logistyki będzie wyglądał inaczej niż plan „idealny” dla produkcji czy finansów. W modelu trzeba to jasno nazwać. Najczęściej używane kryteria:

• terminowość – minimalizacja liczby i wielkości spóźnień,
• efektywność – maksymalne wykorzystanie kluczowych zasobów,
• stabilność – jak najmniej zmian w już opublikowanym planie,
• koszt – sumaryczny koszt przezbrojeń, nadgodzin, ekspresowych wysyłek.

Zamiast jednego „superkryterium” lepiej zbudować wielokryterialną funkcję celu, gdzie ustala się wagi. Przykład:

• w danym zakładzie spóźnienie zlecenia na OEM jest 5 razy „gorsze” niż dodatkowe przezbrojenie,
• zmiana planu na dziś po godzinie 8:00 jest „droższa” niż korekta na za trzy dni.

Takie wagi zwykle na początku są szacunkowe. Z czasem, po kilku miesiącach pracy systemu, można je korygować na podstawie realnych konsekwencji (koszty kar, utracone zlecenia, liczba nadgodzin).

Ograniczenia twarde i miękkie: gdzie AI nie ma prawa kombinować

Kolejny krok to podział między:

• ograniczenia twarde – nie wolno ich złamać nigdy,
• ograniczenia miękkie – można złamać, ale system liczy „karę”.

Przykłady ograniczeń twardych:

• brak kwalifikacji operatora do danej maszyny / operacji,
• brak narzędzia lub formy w zakładzie (np. w serwisie),
• konieczność wykonania operacji w określonej sekwencji technologicznej.

Ograniczenia miękkie:

• praca w nadgodzinach,
• planowanie dużej liczby krótkich serii pod rząd,
• przesunięcie zleceń „złotych klientów” poza preferowane okna czasowe.

Jeśli wszystko zostanie wrzucone do jednego worka jako „twarde”, algorytm szybko zacznie zwracać komunikaty w stylu: „brak rozwiązania”. Z kolei zbyt wiele miękkich ograniczeń skończy się planem, który książkowo wygląda dobrze, ale łamie krytyczne zasady bezpieczeństwa albo jakości.

Parametryzowalne scenariusze: inni klienci, inny plan

Realne życie wygląda tak, że jednego dnia produkcja „gasi pożar” dla kluczowego klienta, a drugiego – skupia się na maksymalnej efektywności. W systemie warto więc przewidzieć scenariusze planowania, np.:

• tryb „terminowość krytyczna” – wysoka kara za spóźnienia, niższy nacisk na przezbrojenia,
• tryb „efektywność” – minimalizacja liczby zmian przezbrojeń, mniejszy nacisk na krótkie spóźnienia,
• tryb „stabilność” – preferowane drobne poprawki planu zamiast jego ciągłego „tasowania”.

Planista wybiera tryb (lub jego wariant) w zależności od sytuacji rynkowej, backlogu, dostępności zasobów. To humanizuje pracę z AI: zamiast „algorytm powiedział tak”, pojawia się „w wybranym scenariuszu to jest najlepsze, co da się zrobić”.

Jak zebrać wiedzę od planistów, żeby nie uciekła do szuflady

Przy budowie parametrów bardzo pomaga krótka, ale dobrze poprowadzona seria warsztatów z planistami, mistrzami i utrzymaniem ruchu. Struktura może wyglądać tak:

1. Mapa decyzji – co planista robi w typowym dniu, jakie ma kroki i wyjątki.
2. Lista reguł nieformalnych – „zawsze…”, „nigdy…”, „jeśli… to…”.
3. Priorytety biznesowe – kogo naprawdę nie można spóźnić, co jest „nice to have”.
4. Największe bóle – gdzie obecny plan się rozsypuje: zmiany, awarie, braki.

Każdy taki element powinien trafić do jednej z trzech szuflad:

• parametr optymalizacyjny (waga, kara, ograniczenie),
• cecha do modelu ML (np. typ klienta, sezon, referencja),
• element interfejsu (np. filtr „zlecenia wysokiego ryzyka”).

Bez tego kroku AI stanie się tylko „ładniejszą tabelką Gantta”, a nie sposobem na rzeczywiste odciążenie planistów.

Kalibracja: pierwsze miesiące z AI jako test A/B dla planu

Nawet najlepiej przemyślana parametryzacja to na starcie hipoteza. Dlatego pierwsze wdrożenia AI w planowaniu warto traktować jak:

• równoległy tor – planista układa plan po staremu, AI po swojemu,
• porównanie wyników – opóźnienia, liczba przezbrojeń, nadgodziny, ilość „gaszonych pożarów”.

Przez kilka tygodni można:

• nie publikować planu AI na produkcję, a jedynie analizować różnice,
• stopniowo wdrażać AI na wybranych liniach / gniazdach, gdzie ryzyko jest mniejsze.

Na tej podstawie zespół koryguje:

• wagi w funkcji celu (np. zwiększa karę za łamanie okien serwisowych),
• ograniczenia (coś przechodzi z miękkiego do twardego albo odwrotnie),
• cechy w modelach ML (dodanie zmiennych, które planista intuicyjnie uwzględnia).

Po tej fazie „oswajania” system stopniowo przejmuje coraz większą część decyzji planistycznych. Zwykle w pewnym momencie planista stwierdza, że wracać do Excela już mu się po prostu nie chce – i to jest całkiem przyjemny sygnał, że parametryzacja trafiła w punkt.

Najczęściej zadawane pytania (FAQ)

Dlaczego ERP tak słabo radzi sobie z planowaniem produkcji?

Klasyczne ERP zostało zaprojektowane głównie jako centralny rejestr danych: zamówień, zleceń, BOM-ów, marszrut, magazynu i kosztów. Świetnie pilnuje spójności dokumentów i rozliczeń, ale traktuje planowanie produkcji dość „książkowo” – zakłada normatywne czasy, pełną dostępność zasobów i brak zakłóceń.

W praktyce ERP nie ogarnia dobrze zmienności: awarii, absencji, opóźnionych dostaw, realnych czasów pracy konkretnych operatorów, kolejek między gniazdami czy minimalizacji przezbrojeń. Dlatego planista kończy z „świętym Excelem”, tablicą na hali i setką ręcznych korekt, a system ERP jedynie odtwarza to, co ktoś ręcznie wymyślił.

Jak AI może poprawić harmonogramowanie produkcji w porównaniu z ERP?

AI nie zastępuje ERP, tylko dokłada warstwę „inteligentnego harmonogramowania” nad danymi z ERP i MES. Wykorzystuje historię produkcji, czasy rzeczywiste, informacje o operatorach czy zmianach, żeby lepiej prognozować czasy operacji, przezbrojeń i ryzyko przestojów.

Dzięki temu może:

• układać kolejność zleceń z uwzględnieniem terminów, przezbrojeń i WIP,
• przydzielać zlecenia do maszyn tak, aby ograniczyć wąskie gardła i puste przebiegi,
• szybko przeliczać różne scenariusze (terminowość vs. koszty vs. priorytety klientów), które planista normalnie liczyłby pół dnia na kartce.

Planista dalej decyduje, ale zamiast jednej ręcznie kleconej wersji ma kilka sensownych wariantów do wyboru.

Czy AI w planowaniu produkcji zastąpi planistę?

AI w obecnej, biznesowej formie jest przede wszystkim narzędziem wsparcia, nie automatycznym „szefem planowania”. Najlepiej działa, gdy:

• proponuje harmonogram na bazie danych i modeli,
• pokazuje wpływ zmian na terminy, obciążenie maszyn i WIP,
• umożliwia planistom łatwą korektę i dopisanie „zdrowego rozsądku”.

Doświadczony planista ma wiedzę kontekstową, której nie ma system: relacje z kluczowymi klientami, „charaktery” maszyn, lokalne zwyczaje na hali. AI zdejmie z niego liczenie i przekładanie klocków, ale decyzja biznesowa – co przesunąć, co zaryzykować – wciąż zostaje po stronie człowieka.

Jakie konkretne problemy na hali produkcyjnej może rozwiązać AI?

Najczęściej AI pomaga tam, gdzie ERP się „zamyśla” albo udaje, że problemu nie ma. Przykładowe obszary:

• prognozowanie realnych czasów operacji zamiast suchych norm,
• szacowanie długości przezbrojeń w zależności od kolejności zleceń,
• wczesne wskazywanie maszyn z podwyższonym ryzykiem awarii,
• redukcja kolejek półproduktów między gniazdami (WIP),
• szybkie przeliczenie planu przy rush orderze, absencjach czy opóźnionej dostawie.

Przykład z życia: zamiast produkować partię A, potem B, potem znowu A (bo tak wyszło z ERP), system proponuje blok A–A–B, dzięki czemu oszczędzasz jedno przezbrojenie i kilka godzin przestoju „organizacyjnego”.

Jakie dane są potrzebne, żeby AI dobrze planowała produkcję?

Minimalny zestaw to nie tylko „ładne” dane z ERP, ale przede wszystkim informacje z rzeczywistej produkcji. Przydają się:

• historia zleceń z czasami rzeczywistymi (start/stop, przestoje),
• dane z MES/SCADA: prędkości, mikropostoje, alarmy,
• informacje o operatorach, zmianach, materiałach i partiach,
• dane o przezbrojeniach, sekwencjach i typowych problemach jakościowych.

Im bardziej dane odzwierciedlają „jak jest naprawdę”, a nie „jak powinno być w technologii”, tym trafniejsze modele predykcyjne i lepsze harmonogramy. AI zasilona wyłącznie starymi normami z technologii będzie tylko bardziej skomplikowanym kalkulatorem.

Czy wdrożenie AI do planowania wymaga wymiany systemu ERP?

Nie. Zazwyczaj AI jest dokładana jako osobny moduł lub system APS, który integruje się z istniejącym ERP i ewentualnie MES. ERP pozostaje źródłem prawdy o zleceniach, BOM-ach, marszrutach czy stanach magazynowych, a AI wykorzystuje te dane do tworzenia lepszych harmonogramów.

Kluczowe jest sensowne spięcie systemów: automatyczna wymiana danych (zlecenia, czasy, statusy), jasne zasady, co „rządzi” (kto jest masterem danych) oraz przejrzysty interfejs dla planisty. W dobrze zrobionej integracji użytkownicy nie „czują”, że coś zostało dołożone – poza tym, że nagle da się ułożyć plan bez nocnej zmiany przy Excelu.

Od czego zacząć, jeśli chcę użyć AI do planowania produkcji w mojej firmie?

Praktycznie najlepiej zacząć od małego, konkretnego problemu zamiast „reorganizować całe planowanie wszechświata”. Dobrym pierwszym krokiem jest:

• zmapowanie aktualnego procesu planowania (gdzie wchodzi Excel, kartki, tablice),
• wybranie jednego obszaru – np. jedna linia, jedno gniazdo, jeden typ produktów,
• zebranie i uporządkowanie danych z ERP/MES dla tego obszaru,
• uruchomienie pilota, w którym AI proponuje harmonogram, a planista go ocenia i koryguje.

Po kilku tygodniach takiego pilota widać czarno na białym, czy modele faktycznie „czują” waszą produkcję, gdzie są luki w danych i ile realnie czasu udaje się odzyskać w planowaniu. Potem można skalować na kolejne linie i procesy – już z mniejszą ilością eksperymentów i większą ilością konkretu.

Najważniejsze wnioski

• Klasyczny ERP dobrze ogarnia dokumenty, MRP i księgowość, ale „siada” na poziomie realnego harmonogramu – nie widzi zmienności na hali, przez co planista i tak kończy z własnym Excelem.
• Główne słabości ERP w planowaniu to sztywne normy czasowe, brak reakcji na awarie i absencje, brak globalnej optymalizacji linii oraz ignorowanie kolejek, przezbrojeń i realnego WIP.
• Planista staje się wąskim gardłem: utrzymuje „święty” plik, ręcznie przenosi dane między systemami i tak naprawdę trzyma logikę planowania w głowie – co jest ryzykowne i kompletnie nieskalowalne.
• Różnica między planem „z papieru” a planem wykonalnym wynika z detali ignorowanych przez ERP: wolniejszych operatorów, organizacyjnych przestojów, opóźnień logistyki czy mikropostojów po przezbrojeniach.
• AI nie naprawia ERP, ale wypełnia lukę między teorią a rzeczywistością, jeśli ma dostęp do aktualnych danych z produkcji (MES, SCADA, historia zleceń), a nie tylko do starych norm technologicznych.
• Największy sens ma AI skupiona na konkretnych zadaniach: prognozowaniu rzeczywistych czasów operacji, optymalizacji kolejności zleceń, przydziale do maszyn i koordynacji gniazd, tak by ograniczyć przestoje i korki.
• AI powinna działać jako asystent planisty – proponować harmonogram i pokazywać skutki zmian – zamiast „magicznej czarnej skrzynki”, bo inaczej skończy się na bezmyślnym klikaniu „przelicz jeszcze raz”.