Kiedy mówi się o automatyzacji w produkcji, rozmowa szybko schodzi na maszyny: roboty, computer vision, predictive maintenance, IoT, planowanie produkcji przez AI. To oczywiście ważne obszary. Problem w tym, że w wielu firmach dużo prostsza praca cały czas odbywa się ręcznie.

Klient wysyła zamówienie jako PDF, a pracownik przepisuje je do ERP. Dostawca przesuwa termin dostawy i wysyła potwierdzenie mailem, więc kupiec porównuje je z zamówieniem, aktualizuje termin w systemie i informuje planistę. Przy wysyłce ktoś kopiuje dane z ERP do portalu przewoźnika. Na koniec tygodnia ktoś inny eksportuje dane z trzech systemów do Excela i przygotowuje raport, który wygląda prawie tak samo jak tydzień wcześniej.

To nie są szczególnie efektowne przypadki użycia AI. I właśnie dlatego warto im się przyjrzeć.

W poprzednim tekście pisałem, że samo posiadanie ERP nie oznacza jeszcze, że cały proces jest zautomatyzowany. ERP może działać poprawnie, a ludzie nadal ręcznie przenosić informacje przed nim, po nim i pomiędzy innymi systemami. Teraz zejdźmy poziom niżej: gdzie konkretnie warto tej pracy szukać?

Poniższej listy nie warto traktować jako:

siedem procesów, które każda firma produkcyjna powinna natychmiast zautomatyzować.

Raczej jako:

siedem miejsc, które warto przejść krok po kroku i sprawdzić, czy ludzie nie wykonują tam codziennie pracy, którą system mógłby przejąć.

Gdzie nadal chowa się ręczna praca w nowoczesnej firmie produkcyjnej

ERP w produkcji jest dziś czymś zupełnie normalnym, podobnie jak MES, WMS, QMS, systemy planistyczne czy rozwiązania BI. Ale liczba wdrożonych systemów nie mówi jeszcze, jak wygląda codzienna praca pomiędzy nimi.

W praktyce ERP bywa uzupełniany Excelem, szczególnie przy bardziej dynamicznym planowaniu produkcji. Taki model daje elastyczność, ale z czasem prowadzi do problemów ze spójnością danych i ze skalowaniem.

Dlatego warto szukać przede wszystkim czynności, które mają kilka prostych cech:

• występują często
• za każdym razem wyglądają podobnie
• wymagają otwierania dokumentów albo kilku systemów
• polegają na porównywaniu, kopiowaniu albo przepisywaniu danych
• mają stosunkowo jasny standardowy przebieg
• tylko część przypadków wymaga prawdziwej decyzji człowieka

Jeżeli pracownik robi coś raz na pół roku, prawdopodobnie nie ma czego automatyzować. Jeżeli robi to 100 razy dziennie, sytuacja wygląda inaczej.

Najlepiej zacząć od trzech obszarów: zamówień klientów, zakupów i faktur.

Zamówienia, zakupy i faktury: od tego warto zacząć

1. Przyjmowanie zamówień klientów

Wyobraźmy sobie typowy proces. Klient wysyła zamówienie mailem, w załączniku jest PDF albo Excel.

Pracownik:

1. otwiera dokument
2. sprawdza klienta i adres dostawy
3. odczytuje numer zamówienia
4. przegląda pozycje
5. mapuje kod klienta na wewnętrzny kod produktu
6. sprawdza ilość i jednostkę
7. sprawdza cenę
8. sprawdza oczekiwany termin
9. wpisuje zamówienie do ERP
10. dołącza dokument
11. wysyła potwierdzenie

Jeżeli coś się nie zgadza, zaczyna się kolejna część procesu: mail do handlowca, pytanie do planisty, sprawdzenie wcześniejszego zamówienia, telefon do klienta.

To bardzo dobry kandydat do analizy, bo standardowy przypadek jest zwykle łatwy do rozpoznania. System może sam sprawdzić, kto jest klientem, jaki jest jego kod produktu i cena kontraktowa, czy ilość jest poprawna i czy zamówienie nie jest przypadkiem duplikatem.

Ale nie zawsze powinien sam podejmować decyzję. Jeżeli klient wpisał nietypowy produkt, zmienił warunki handlowe albo oczekuje terminu, którego produkcja nie jest w stanie dotrzymać, przypadek może trafić do człowieka. I to jest sensowny podział.

Standardowe zamówienie przechodzi automatycznie. Nietypowe trafia do osoby, która rzeczywiście musi coś zdecydować.

Praktyka pokazuje też, że nie ma jednego rozwiązania dla wszystkich klientów. Nawet SAP w swojej dokumentacji opisuje scenariusz, w którym handlowcy dostają zamówienia jako PDF-y w załącznikach do maili i bez automatyzacji tworzyliby na ich podstawie zamówienia ręcznie. Jednocześnie Dynamics, Oracle czy Infor mają mechanizmy do strukturalnego importu zamówień.

Dlatego nie warto zaczynać od:

Wrzućmy AI do wszystkich zamówień.

Dużego klienta, który wysyła tysiące podobnych zamówień, często da się podłączyć bezpośrednio: przez EDI, czyli ustandaryzowaną elektroniczną wymianę dokumentów między systemami, albo przez API. Dane przychodzą wtedy w gotowych polach i nie trzeba niczego odczytywać. AI ma sens gdzie indziej: przy dziesiątkach mniejszych klientów, z których każdy zamawia po swojemu, jeden wysyła PDF, drugi własny arkusz, trzeci opisuje produkty swoimi nazwami.

Najprostsza kolejność wygląda więc tak:

EDI/API → standardowy import ERP → odczytywanie dokumentów → walidacja → człowiek przy wyjątkach.

Warto mierzyć:

• średni aktywny czas obsługi jednego zamówienia
• liczbę zamówień na pracownika
• procent zamówień przechodzących bez ręcznej ingerencji
• liczbę wyjątków
• liczbę poprawek
• czas od otrzymania zamówienia do potwierdzenia klientowi

Nie trzeba na początku udowadniać, że system potrafi obsłużyć 100% zamówień. Jeżeli przejmie 70% prostych przypadków, a pozostałe 30% dobrze przygotuje dla pracownika, to może być znacznie lepszy wynik niż automatyzacja wszystkiego za wszelką cenę.

2. Potwierdzenia dostawców i zmiany w zamówieniach

Drugi proces wygląda niemal jak lustrzane odbicie pierwszego. Firma wysyła zamówienie do dostawcy, a dostawca odpowiada. Tylko że nie zawsze:

Potwierdzamy dokładnie to, czego chcieliście.

Czasem odpowiada:

Dostarczymy 24 września zamiast 10 września.

Albo:

Mamy 800 sztuk zamiast 1000.

Albo:

Cena uległa zmianie.

Wtedy kupiec:

• otwiera odpowiedź
• znajduje zamówienie w ERP
• porównuje ilości
• porównuje termin
• porównuje cenę
• aktualizuje potwierdzony termin
• sprawdza, czy materiał nie jest krytyczny
• informuje planistę
• czasem aktualizuje osobny Excel z brakami
• odpowiada dostawcy

Porównanie danych nie jest tym samym co decyzja biznesowa.

System może bez problemu wykryć:

PO 45172, pozycja 30
oczekiwany termin: 10 września
potwierdzony termin: 24 września
różnica: +14 dni

Może również sprawdzić, że materiał jest potrzebny do produkcji 18 września. To już bardzo dużo. Ale ktoś nadal powinien zdecydować:

• czy zaakceptować opóźnienie
• czy naciskać na dostawcę
• czy szukać innego źródła
• czy zmienić plan
• czy poinformować klienta

I właśnie takie procesy sprawdzają się najlepiej. Nie chodzi o „automatyzowanie zakupów”, tylko o automatyzację nudnej części:

znajdź różnicę, przepisz ją, pokaż konsekwencje.

A kupiec zostaje przy decyzji, dla której jego doświadczenie rzeczywiście ma wartość.

Nowoczesne ERP-y mają zresztą sporo gotowych możliwości w tym obszarze. Dynamics ma m.in. portal współpracy z dostawcami (vendor collaboration) także dla firm bez EDI, z automatycznym potwierdzaniem niezmienionych zamówień i ręczną obsługą proponowanych zmian. Dostawca może też po prostu odpowiedzieć mailem, co prowadzi z powrotem do ręcznej pracy kupca.

Dlatego znów warto zacząć od prostszego pytania:

Czy możemy podłączyć dostawcę przez portal, EDI albo API?

Jeśli nie, wtedy warto patrzeć na email i dokumenty.

3. Faktury zakupowe

To chyba najbardziej oczywisty przykład na całej liście. I jednocześnie ten, przy którym najczęściej wystarczy jedna rada:

Najpierw sprawdźcie, co już macie.

Typowy proces wygląda tak: faktura przychodzi mailem. Pracownik ją otwiera, znajduje dostawcę, wpisuje numer i datę faktury, sprawdza zamówienie i przyjęcie, porównuje ilość, cenę i podatek. Jeśli wszystko się zgadza, księguje dokument. Jeśli nie, pisze do zakupów albo osoby odpowiedzialnej za koszt.

To proces bardzo powtarzalny i dlatego producenci ERP rozwiązują go od lat. Oracle, Dynamics, IFS, Infor i Epicor mają rozbudowane mechanizmy do przechwytywania faktur, odczytywania danych, matchingu i obsługi wyjątków.

Jeżeli więc firma nadal ręcznie przepisuje zwykłe faktury powiązane z PO, nie warto zaczynać od projektowania własnej platformy AI. Najpierw trzeba sprawdzić:

1. czy ERP ma odpowiedni moduł
2. czy jest on licencjonowany
3. czy został skonfigurowany
4. czy dostawcy mogą wysyłać e-faktury
5. czy istniejący proces matchingu jest poprawnie ustawiony

Dopiero później warto szukać czegoś customowego.

W branżowych raportach można znaleźć uśrednione koszty obsługi jednej faktury, ale takie benchmarki mówią niewiele o konkretnej firmie. Dużo ważniejsze będą własne liczby:

• ile faktur obsługuje jedna osoba
• ile czasu aktywnie zajmuje faktura
• jaki procent przechodzi bez wyjątku
• jakie wyjątki pojawiają się najczęściej
• ile trwa wyjaśnienie wyjątku
• ile jest korekt i duplikatów

Dane z produkcji nie powinny być wpisywane dwa razy

4. Potwierdzenia produkcji i raportowanie wykonania

Ten przykład jest trochę inny. Nie chodzi już o dokument od klienta albo dostawcy, tylko o informację o tym, co rzeczywiście wydarzyło się na produkcji.

Operator kończy operację. Powstaje liczba dobrych sztuk, scrap (braki), czas, zużycie materiału i status operacji. Informacja trafia do MES, na terminal, na papier albo do Excela. A później ktoś na koniec zmiany przepisuje wynik do ERP.

Jeżeli ten sam fakt jest raportowany dwa razy, warto zadać pytanie:

Dlaczego?

Nowoczesne systemy potrafią już obsługiwać standardowe potwierdzenia produkcji: ilości, braki, poprawki, czasy i ruchy materiałowe. Jeżeli operator po prostu nie korzysta z funkcji, którą system ma, to być może nie mamy projektu automatyzacyjnego, tylko problem z konfiguracją, interfejsem, terminalem na hali, skanerem, integracją MES z ERP albo ze sposobem pracy.

Prawdziwy kandydat pojawia się wtedy, gdy:

zdarzenie zostało już zapisane w jednym systemie, ale człowiek musi ręcznie przenieść je do drugiego.

Albo:

dane cały dzień zbierane są na papierze i dopiero pod koniec zmiany ktoś wpisuje podsumowanie.

Tutaj AI zwykle nie jest potrzebne. Ilość to ilość, kod operacji to kod operacji, godzina zdarzenia to godzina zdarzenia. Najlepszym rozwiązaniem może być API, zdarzenie z maszyny, kod kreskowy albo poprawna integracja.

Człowiek powinien zostać przy nietypowych brakach, poprawkach, brakującym materiale, błędnych transakcjach i sytuacjach, w których stan na hali nie zgadza się z tym, co pokazuje system. System może przenosić informację. Pracownik nadal odpowiada za to, co naprawdę wydarzyło się na hali.

Dokumentacja jakościowa też jest przepływem danych

5. Wyniki jakościowe, certyfikaty i dokumenty dla klientów

Wyobraźmy sobie wysyłkę partii produktu, do której klient wymaga certyfikatu. Wyniki badań są w LIMS albo QMS, informacje o partii w ERP, specyfikacja produktu w innym miejscu, a klient ma własny wzór dokumentu.

Pracownik jakości:

1. pobiera wyniki
2. sprawdza partię
3. kopiuje wartości do szablonu
4. tworzy certyfikat analizy (CoA) albo zgodności (CoC)
5. generuje PDF
6. dołącza dokument do wysyłki
7. czasem wrzuca go jeszcze do portalu klienta

Każdy z systemów może działać prawidłowo. Problemem jest przepływ danych pomiędzy nimi.

To bardzo dobre miejsce do automatyzacji, ale też takie, w którym łatwo przesadzić. System może pobrać zatwierdzone wyniki badań, połączyć je z partią, wybrać właściwy szablon, wygenerować dokument, przypisać go do wysyłki i przesłać dalej. Nie oznacza to jednak, że AI powinno decydować:

Ta partia mimo odchylenia nadaje się do zwolnienia.

To zupełnie inny poziom odpowiedzialności.

Nowoczesne systemy jakościowe i ERP mają już funkcje wyników inspekcji i generowania certyfikatów, więc i tu najpierw warto sprawdzić, czego nie robi obecny system. Automatyzować warto przepływ informacji i generowanie dokumentów. Decyzje dotyczące zwolnienia produktu, odstępstwa czy istotnej niezgodności powinny zostać przy odpowiedzialnych pracownikach jakości.

Wysyłka tworzy kolejny łańcuch ręcznych przekazań

6. Obsługa przewoźników i dokumentów wysyłkowych

Zamówienie jest gotowe, towar stoi na magazynie. Teraz trzeba go wysłać.

Pracownik otwiera dostawę w ERP, kopiuje adres, wagę, liczbę palet, referencję i rodzaj usługi, po czym wpisuje wszystko do TMS albo portalu przewoźnika. Potem pobiera etykietę, a numer trackingowy przepisuje z powrotem do ERP. Po dostawie wchodzi do kolejnego systemu, pobiera potwierdzenie dostawy (POD) i dołącza je do dokumentacji.

To wręcz podręcznikowy przykład człowieka działającego jak integracja.

Najprostsza odpowiedź nie brzmi jednak:

Zbudujmy bota, który będzie klikał w portal.

Jeśli TMS albo przewoźnik ma API, konektor albo EDI, najlepiej zacząć właśnie tam. Najwięksi producenci ERP mają zresztą własne moduły transportowe i gotowe integracje z przewoźnikami.

RPA warto zostawić na sytuację:

mamy stary portal, nie ma API, interfejs jest stabilny i system zostanie z nami jeszcze przez kilka lat.

Nie jako pierwszy wybór.

Po automatyzacji pracownik nadal powinien dostać przypadki takie jak:

• przewoźnik odrzucił transport
• pojawiła się nietypowa dopłata
• mamy towary niebezpieczne
• wystąpił problem celny
• dostawa się nie udała
• trzeba podjąć decyzję o innym serwisie

To są wyjątki. Kopiowanie adresu z ERP do TMS nim nie jest.

Raportowanie: najpierw zgoda co do danych, potem automatyzacja

7. Powtarzalne raportowanie i uzgadnianie danych

Ten proces najłatwiej rozpoznać po kalendarzu. Poniedziałek rano, trzeba przygotować raport produkcyjny.

Ktoś:

1. eksportuje ERP
2. eksportuje MES
3. pobiera dane magazynowe
4. otwiera plik z zeszłego tygodnia
5. poprawia nazwy kolumn
6. robi XLOOKUP albo VLOOKUP
7. sprawdza brakujące indeksy
8. liczy te same KPI
9. aktualizuje wykresy
10. wkleja je do PowerPointa
11. wysyła raport

Za tydzień robi prawie to samo.

To bardzo dobry kandydat do automatyzacji, ale tylko pod jednym warunkiem:

firma zgadza się, co właściwie znaczą dane.

Są bowiem dwa zupełnie różne przypadki.

Przypadek pierwszy: raport jest powtarzalny

Źródła są te same, kolumny są te same, KPI są zdefiniowane, transformacje są takie same. Wtedy trudno znaleźć dobry powód, żeby człowiek co tydzień wykonywał identyczną pracę. Dane powinny przepływać automatycznie, raport powinien się odświeżać, a pracownik powinien analizować wynik.

Przypadek drugi: każdy system mówi coś innego

MES rozumie „wyprodukowano” inaczej niż ERP. Magazyn ma inne identyfikatory niż finanse. Jeden dział liczy wysyłkę według daty dokumentu, drugi według momentu opuszczenia magazynu.

Wtedy automatyzowanie Excela może tylko pogorszyć sytuację. Dostaniemy:

błędny raport szybciej i bardziej automatycznie.

Najpierw trzeba uzgodnić model danych. Kto jest właścicielem definicji? Który system jest źródłem prawdy? Co dokładnie oznacza KPI?

Trudno o wiarygodne branżowe liczby mówiące, ile godzin tygodniowo firmy tracą na takie raporty. Dlatego warto zmierzyć własną sytuację:

• ile godzin zajmuje przygotowanie raportu
• ile jest ręcznych eksportów
• ile ręcznych transformacji
• ile różnic trzeba wyjaśniać
• jak długo dane czekają, zanim trafiają do odbiorcy
• ile czasu analityk spędza na przygotowaniu danych, a ile na ich analizie

Docelowo chodzi o odwrócenie tych proporcji. Mniej:

kopiuję, czyszczę i składam.

Więcej:

widzę, co się wydarzyło i próbuję zrozumieć dlaczego.

Jak sprawdzić, czy któryś z tych procesów rzeczywiście warto automatyzować?

Znalezienie ręcznej pracy nie oznacza jeszcze, że warto budować automatyzację. Warto wziąć jeden z procesów powyżej i odpowiedzieć na kilka pytań.

Czy proces występuje często?

Codziennie albo kilkadziesiąt razy w tygodniu brzmi interesująco. Raz na kwartał dużo mniej.

Czy potrafimy zmierzyć wolumen?

Jeżeli nie wiemy nawet, ile takich przypadków mamy miesięcznie, najpierw policzmy.

Ile rzeczywistej pracy zabiera jeden przypadek?

Nie czas od maila do zakończenia sprawy, tylko aktywny czas pracy człowieka: otwieranie, czytanie, przepisywanie, porównywanie, ładowanie dokumentów.

Czy standardowy przypadek jest powtarzalny?

Jeżeli 80% wygląda podobnie, mamy czego szukać. Jeżeli każda sytuacja jest zupełnie inna, automatyzacja będzie trudniejsza.

Czy system, który już mamy, potrafi to zrobić?

To pytanie powinno pojawić się bardzo wcześnie. Może wystarczy skonfigurować workflow, uruchomić istniejący moduł, dodać integrację albo skorzystać z EDI czy API. Dopiero później warto myśleć o nowym rozwiązaniu.

Czy potrafimy zdefiniować wyjątki?

„Cena różni się o więcej niż 2%” jest regułą. „Termin przesunął się o więcej niż 5 dni” jest regułą. „Pracownik patrzy na dokument i po prostu wie, czy jest OK” jest sygnałem, że proces trzeba najpierw lepiej zrozumieć.

Co się stanie, jeśli system popełni błąd?

Jeśli błąd można zatrzymać przed zapisaniem transakcji i pokazać człowiekowi, ryzyko jest inne niż wtedy, gdy błędna decyzja od razu trafia do produkcji albo klienta.

Czy potrafimy zmierzyć efekt?

Na początku wystarczy prosta kalkulacja:

wolumen × aktywny czas obsługi

To daje pierwszą informację, ile administracyjnej pracy zużywa proces. Potem można doliczyć wyjątki, poprawki, opóźnienia, koszt błędów i wpływ na inne działy.

Po automatyzacji mierzymy dokładnie te same rzeczy. Nie „ile procent procesu jest AI-powered”, tylko:

ile pracy rzeczywiście zniknęło i co zmieniło się w działaniu firmy.

Nie chodzi o automatyzację siedmiu procesów

Jeżeli pięć procesów z tej listy wygląda znajomo, nie oznacza to, że trzeba uruchomić pięć projektów. Najlepiej zacząć od jednego. Takiego, który:

• występuje często
• zabiera zauważalną ilość czasu
• ma powtarzalny standardowy przebieg
• pozwala łatwo wykryć błąd
• daje się zmierzyć
• nie wymaga przebudowy połowy firmy

I jeszcze raz sprawdzić:

Czy istniejący ERP, MES, QMS albo TMS już tego nie potrafi?

To ta sama zasada, o której pisałem przy ERP: czasem najlepszą automatyzacją będzie uruchomienie funkcji, za którą firma już płaci. Czasem będzie to API, czasem EDI, czasem automatyczne odczytywanie dokumentów. Czasem potrzebna będzie dedykowana warstwa pomiędzy kilkoma systemami. A czasem najlepszą decyzją będzie zostawienie procesu w spokoju.

Wszystko to prowadzi do dość prostego modelu:

automatyzuj przenoszenie informacji → sprawdzaj regułami wszystko, co da się sprawdzić jednoznacznie → używaj AI tam, gdzie trzeba coś zinterpretować → kieruj istotne wyjątki do człowieka → zapisuj jego decyzję z powrotem do systemów.

To jest mniej efektowne niż wizja autonomicznej fabryki sterowanej przez agentów AI. Ale w wielu firmach właśnie w takich małych, powtarzalnych przekazaniach informacji kryje się praca, którą można usunąć bez wymiany ERP, bez przebudowy całej organizacji i bez próby automatyzowania decyzji, które nadal lepiej podejmuje człowiek.