Samo korzystanie z Excela nie oznacza utraty kontroli nad danymi. Problem zaczyna się wtedy, gdy bez ręcznego łączenia informacji z ERP, arkuszy i innych systemów firma nie potrafi jednoznacznie ustalić bieżącego stanu produkcji, realizacji zamówień czy zapasów.

Sygnałem ostrzegawczym są różne liczby opisujące tę samą sytuację, raporty zależne od konkretnych osób, dane dostępne z opóźnieniem oraz brak możliwości odtworzenia sposobu wyliczenia wyniku. Rozwiązaniem zwykle nie jest wymiana ERP ani rezygnacja z Excela. Najpierw trzeba ustalić, które dane są potrzebne do podejmowania decyzji, gdzie powstają, kto za nie odpowiada i w jaki sposób są dziś przetwarzane.

Dlaczego firma nadal pracuje w Excelu, mimo że ma ERP?

Korzystanie z Excela obok ERP jest czymś naturalnym. Nowe potrzeby planistyczne, raportowe i analityczne często pojawiają się poza zakresem obsługiwanym przez ERP.

Pojawia się potrzeba nowego zestawienia, dodatkowego wskaźnika albo zmiany sposobu planowania. Modyfikacja systemu wymaga czasu lub zaangażowania dostawcy, więc ktoś eksportuje dane i przygotowuje rozwiązanie w Excelu.

Na początku arkusz może być w pełni wystarczający. Z czasem dochodzą kolejne kolumny, formuły, dane z innych źródeł, importy lub makra. Plik zaczyna być używany przez kilka osób, później przez cały dział, a rozwiązanie stworzone na potrzeby jednej sytuacji staje się stałym elementem procesu.

W firmie produkcyjnej ERP zwykle nie jest jedynym systemem. Obok niego mogą działać systemy wspierające realizację produkcji, gospodarkę magazynową, kontrolę jakości i utrzymanie ruchu, a także rozwiązania zbierające dane bezpośrednio z maszyn.

Ryzyko rośnie, gdy Excel zaczyna wypełniać luki między tymi systemami i staje się podstawą codziennych decyzji.

Kiedy Excel przestaje być narzędziem, a staje się ryzykiem operacyjnym?

Excel dobrze sprawdza się w analizach ad hoc, symulacjach, kalkulacjach i jednorazowych zestawieniach. Ryzyko pojawia się wtedy, gdy arkusz zaczyna pełnić rolę aplikacji obsługującej proces, bazy danych, nieformalnej warstwy integracyjnej albo podstawy cyklicznego raportowania.

Jeżeli planista pobiera dane z ERP, żeby sprawdzić kilka wariantów harmonogramu, Excel pełni swoją naturalną funkcję.

Jeżeli jednak aktualny plan produkcji istnieje wyłącznie w jego arkuszu, a bez tego pliku nikt nie potrafi ustalić kolejności realizacji zleceń, arkusz staje się elementem procesu operacyjnego, a nie tylko narzędziem analitycznym.

Podobnie jest z raportami. Sam fakt, że końcowe zestawienie trafia do Excela, nie musi być problemem. Problem pojawia się wtedy, gdy przed jego przygotowaniem trzeba pobrać kilka plików, przekopiować dane, ręcznie obsłużyć wyjątki, uruchomić własne formuły i na końcu sprawdzić, czy wynik wygląda wiarygodnie.

Dobrym testem jest jedno pytanie:

Co stanie się z procesem, jeśli arkusz stanie się niedostępny albo przez dwa tygodnie nie będzie osoby, która wie, jak go obsłużyć?

Jeżeli raport przestanie powstawać, plan nie będzie aktualizowany albo nikt nie odtworzy sposobu obliczenia wyniku, arkusz jest krytycznym elementem procesu, a nie tylko narzędziem pomocniczym.

Po czym poznać, że firma traci kontrolę nad danymi?

Problemu nie należy mierzyć liczbą arkuszy. Ważniejsze jest to, czy informacje potrzebne do zarządzania są jednoznaczne, aktualne, możliwe do odtworzenia i dostępne bez ręcznego składania ich z wielu miejsc.

Typowe sygnały ostrzegawcze to:

• produkcja, sprzedaż i logistyka podają różne wartości dotyczące tego samego zlecenia,
• przygotowanie raportu wymaga eksportu danych z kilku systemów i ich ręcznego połączenia,
• informacje są ręcznie kopiowane pomiędzy plikami lub aplikacjami,
• konkretne zestawienie potrafi przygotować tylko jedna osoba,
• spotkanie zaczyna się od ustalenia, “która liczba jest prawidłowa”,
• raport pokazuje sytuację sprzed kilku godzin albo poprzedniego dnia, mimo że decyzje trzeba podejmować na bieżąco,
• dwie osoby liczą ten sam wskaźnik i otrzymują różne wyniki,
• kierownicy nie ufają danym w systemie i prowadzą własne zestawienia,
• wartości są ręcznie korygowane, ale później trudno odtworzyć przyczynę zmiany,
• ten sam obiekt – na przykład produkt, materiał, zlecenie, partia lub maszyna – ma różne oznaczenia w poszczególnych systemach,
• nikt nie potrafi jednoznacznie wskazać źródła liczby widocznej na dashboardzie.

Jeżeli kilka z tych sytuacji występuje regularnie, problem nie dotyczy już pojedynczego raportu. Dotyczy sposobu, w jaki firma tworzy, przetwarza i wykorzystuje dane.

“Czy zrealizujemy plan?” – gdzie naprawdę powstaje odpowiedź

Wyobraźmy sobie jedno z podstawowych pytań dyrektora produkcji:

Czy do końca tygodnia zrealizujemy plan produkcji i dotrzymamy terminów zamówień klientów?

ERP pokazuje zamówienia, zlecenia i terminy, system realizacji produkcji – faktyczne wykonanie operacji, a system magazynowy – dostępność materiału. Informacje o awariach i planowanych postojach znajdują się w systemie utrzymania ruchu, natomiast system jakości wskazuje partie zablokowane lub oczekujące na decyzję.

Planista prowadzi przy tym własny arkusz z aktualną kolejnością produkcji, zmienioną na przykład po awarii jednej z maszyn.

Każde z tych źródeł może zawierać poprawne dane. Mimo to odpowiedź na pytanie dyrektora nie istnieje w żadnym z nich.

Powstaje dopiero wtedy, gdy ktoś zbierze informacje, połączy je, uwzględni wyjątki i zinterpretuje wynik.

Osobnym problemem jest aktualność danych. Niektóre informacje są odświeżane niemal w czasie rzeczywistym, inne dopiero po ręcznym uzupełnieniu arkusza planisty. Trzeba więc wiedzieć nie tylko, czy dane są poprawne, ale także czy opisują ten sam moment.

Firma może mieć wszystkie potrzebne dane, a jednocześnie nie mieć odpowiedzi na podstawowe pytanie operacyjne.

Jeżeli taka analiza jest jednorazowa, ręczna praca może być uzasadniona. Jeżeli jednak każdego dnia lub tygodnia ktoś wykonuje te same kroki według tych samych reguł, problem nie polega już na braku danych. Polega na sposobie ich przepływu i wykorzystania.

Dlaczego ERP nie musi dawać pełnego obrazu produkcji?

ERP obsługuje określone procesy i rejestruje związane z nimi zdarzenia oraz transakcje, ale odpowiedź na pytanie zarządcze często wymaga połączenia planu z faktycznym wykonaniem, dostępnością materiału, statusem jakościowym i sytuacją na maszynach.

Nie oznacza to, że ERP działa nieprawidłowo. Informacje potrzebne do podjęcia decyzji wykraczają po prostu poza zakres jednego procesu i jednego systemu.

Problemem nie jest samo rozproszenie danych, lecz brak jednoznacznych źródeł, reguł łączenia oraz uzgodnionych wymagań dotyczących aktualności.

Jedno źródło prawdy nie oznacza jednego systemu

Uporządkowanie danych nie wymaga przeniesienia wszystkich informacji do jednej aplikacji.

Znacznie ważniejsze jest jednoznaczne określenie, skąd pochodzi konkretny rodzaj danych i które źródło należy traktować jako referencyjne.

ERP może odpowiadać za dane dotyczące zamówienia, system produkcyjny – za faktyczne wykonanie operacji, system magazynowy – za stan zapasu, a system jakości – za status partii.

Firma nie potrzebuje więc jednego systemu zawierającego wszystkie informacje. Powinna natomiast mieć spójny obraz sytuacji oparty na jasno określonych źródłach danych.

Nie każda informacja biznesowa ma jednak jedno źródło. Wskaźnik terminowości, efektywności lub dostępności może być wynikiem obliczeń opartych na danych z kilku systemów.

Dla danych źródłowych trzeba więc wskazać źródło referencyjne, a dla informacji pochodnych – wspólną regułę obliczania.

Samo wskazanie źródeł i reguł obliczania również nie wystarcza, jeśli poszczególne systemy inaczej identyfikują te same produkty, materiały, zlecenia, partie, operacje lub maszyny. Potrzebne są wspólne identyfikatory albo jednoznaczne reguły ich mapowania.

Trzeba też ustalić poziom szczegółowości, na którym informacje mają być porównywane. Inaczej wygląda analiza całego zlecenia, inaczej pojedynczej operacji, partii czy cyklu maszyny. Dane mogą być poprawne w swoich systemach źródłowych, a mimo to nie nadawać się do bezpośredniego zestawienia, jeśli dotyczą różnych poziomów szczegółowości.

Istotne są również definicje.

Co dokładnie oznacza “zlecenie wykonane”?

Kiedy liczony jest przestój?

Co oznacza “dostępny materiał” – fizyczną obecność w magazynie czy ilość możliwą do wykorzystania przez konkretne zlecenie?

Bez takich ustaleń nawet technicznie poprawna integracja może dostarczać różnych odpowiedzi na to samo pytanie.

Ręczne raportowanie kosztuje więcej niż czas pracowników

Największym kosztem ręcznego raportowania nie zawsze jest czas poświęcony na przygotowanie zestawienia. Gdy problem narasta, to właśnie uzgadnianie danych przed podjęciem decyzji – a nie samo przygotowanie raportu – staje się większym kosztem.

Pierwszą konsekwencją jest opóźnienie informacji. Jeżeli raport dotyczący poprzedniej zmiany jest gotowy kilka godzin później, decyzja może opierać się na stanie, który przestał być aktualny.

Drugą jest ryzyko błędu. Im więcej eksportów, kopiowania, własnych formuł i ręcznych korekt, tym większa zależność wyniku od sposobu przygotowania raportu.

Trzecią jest brak możliwości odtworzenia wyniku. Po kilku tygodniach może być trudno ustalić, z którego źródła pochodziła wartość, kto ją zmienił i dlaczego.

Najpoważniejszym skutkiem bywa jednak utrata zaufania do danych.

Kierownik prowadzi własny arkusz, bo nie ufa raportowi centralnemu. Sprzedaż przygotowuje inne zestawienie. Produkcja jeszcze inne. Powstają kolejne wersje informacji, które później trzeba ponownie uzgadniać.

Mechanizm zaczyna się sam napędzać:

brak zaufania -> własne zestawienia -> więcej wersji danych -> jeszcze mniejsze zaufanie

W efekcie menedżerowie poświęcają część czasu nie na podejmowanie decyzji, lecz na ustalanie stanu faktycznego.

Jak ograniczyć ręczne raportowanie bez wymiany ERP?

Porządkowanie raportowania nie powinno zaczynać się od wyboru narzędzia. Najpierw trzeba ustalić, jakie informacje są naprawdę potrzebne do podejmowania decyzji i jak dziś powstają.

Zacznij od decyzji biznesowych

Zamiast zaczynać od pytania “jakie dane mamy w ERP?”, lepiej określić najważniejsze pytania operacyjne:

• Czy wykonamy plan?
• Które zlecenia są zagrożone?
• Czy mamy materiały potrzebne do realizacji najbliższych zleceń?
• Gdzie i dlaczego występują największe przestoje?
• Dlaczego terminowość realizacji spada?

Dopiero później należy ustalić, jakich danych potrzeba, żeby na te pytania wiarygodnie odpowiedzieć.

Ustal wskaźniki i ich definicje

Jeżeli decyzja opiera się na wskaźnikach, trzeba ustalić nie tylko sposób ich obliczania, ale również znaczenie danych wejściowych.

Dwa działy mogą korzystać z poprawnych danych, a mimo to pokazywać różne wyniki, jeśli inaczej rozumieją “wykonanie”, “przestój”, “brak” czy “terminowość”.

Ujednolicenie definicji jest często równie ważne jak sama integracja systemów.

Wskaż źródła, właścicieli i wymaganą aktualność danych

Dla każdej istotnej informacji warto odpowiedzieć na trzy pytania:

Skąd pochodzi?

Kto odpowiada za jej definicję, jakość i zasady utrzymania?

Jak aktualna musi być, żeby można było na jej podstawie podjąć decyzję?

Właściciel danych to osoba lub rola biznesowa odpowiedzialna za ich definicję, wymagania jakościowe i zasady utrzymania. Nie musi być administratorem systemu, w którym dane są przechowywane.

Aktualność jest równie istotna. Raport może korzystać z właściwego źródła, ale nadal być bezużyteczny, jeśli dane aktualizują się raz dziennie, a decyzje trzeba podejmować co godzinę.

Jeżeli dane są błędne, korekta powinna trafić do systemu źródłowego albo do kontrolowanego mechanizmu korekt, a nie wyłącznie do końcowego arkusza. W przeciwnym razie przy kolejnym eksporcie ten sam problem wróci.

Rozpisz pełną mapę decyzji i danych

Analizę warto zacząć od decyzji i cofnąć się do potrzebnych wskaźników oraz danych. Następnie należy prześledzić, jak dane trafiają ze źródeł przez kolejne przekształcenia do raportu, alertu lub odbiorcy.

Pomocna może być taka mapa:

decyzja -> wskaźnik i jego definicja -> wymagane dane -> źródła i właściciele -> identyfikatory i poziom szczegółowości -> wymagana aktualność -> reguły przetwarzania -> raport lub alert -> odbiorca

Taka analiza ujawnia miejsca, w których dane są przepisywane, powielane, ręcznie poprawiane albo przetwarzane według zasad znanych tylko jednej osobie.

Pozwala też odróżnić problem z systemem od problemu z procesem, definicją danych lub odpowiedzialnością za ich utrzymanie.

Dopiero wtedy wybierz sposób integracji i raportowania

Kiedy wiadomo już, które źródła są właściwe, jak aktualne powinny być dane i według jakich zasad mają być interpretowane, można dobrać rozwiązanie techniczne.

Wybór zależy między innymi od wymaganej aktualności danych, liczby i rodzaju źródeł, możliwości integracyjnych istniejących systemów, potrzeby przechowywania historii, skali danych oraz krytyczności procesu.

Zakres rozwiązania może obejmować prostą wymianę danych i automatyczne generowanie raportu, wspólną warstwę danych z narzędziem BI albo jedynie usunięcie kilku ręcznych kroków bez przebudowy całej architektury.

Docelowy przepływ można sprowadzić do prostego modelu:

systemy źródłowe -> kontrolowany przepływ danych -> uzgodnione dane i reguły -> raportowanie i alerty -> decyzje

Excel może pozostać narzędziem analitycznym wykorzystywanym przez odbiorcę danych. Nie powinien jednak pełnić roli niekontrolowanej warstwy integracyjnej, od której zależy codzienne działanie firmy.

Dojrzałość nie polega na tym, że firma nie korzysta z Excela. Polega na tym, że kluczowe procesy i decyzje nie zależą od ręcznego składania w nim danych.

Dlaczego samo wdrożenie nowego ERP lub narzędzia BI nie rozwiąże problemu z danymi?

Kiedy liczba ręcznych raportów rośnie, naturalną reakcją jest próba zastąpienia ich nowym narzędziem. Technologia może być częścią rozwiązania, ale sama nie usuwa źródła problemu.

Nowy ERP może być uzasadniony, jeżeli obecny system rzeczywiście ogranicza rozwój firmy. Nie ujednolici jednak automatycznie definicji danych ani odpowiedzialności za ich aktualizację.

Dashboard lub inne narzędzie BI może znacząco poprawić dostęp do informacji. Jeśli jednak zostanie podłączone do niespójnych źródeł, pokaże przede wszystkim bardziej czytelną wersję istniejących rozbieżności.

Hurtownia danych może być właściwym elementem architektury, ale zbieranie danych bez jasno określonych potrzeb biznesowych łatwo prowadzi do dużego projektu technologicznego o niejasnej wartości.

Zakaz korzystania z Excela usuwa natomiast narzędzie, którym pracownicy często wypełnili realną lukę. Jeżeli nie zapewnimy lepszego sposobu wykonania tego samego zadania, luka pozostanie.

Celem nie powinno być więc wyeliminowanie konkretnego programu. Celem jest usunięcie zależności kluczowych procesów od ręcznego i niekontrolowanego przepływu informacji.

Od czego zacząć porządkowanie danych w firmie produkcyjnej?

Nie trzeba zaczynać od pełnej inwentaryzacji wszystkich systemów, raportów i arkuszy.

Lepszym punktem startowym jest wybór 3-5 ważnych decyzji operacyjnych. W pierwszej kolejności warto przeanalizować te obszary, w których dane lub raporty:

• są potrzebne regularnie,
• wymagają dużo ręcznej pracy,
• prowadzą do sporów o poprawność danych,
• zależą od wiedzy konkretnych osób,
• docierają zbyt późno, aby wspierać decyzję,
• mają istotny wpływ na produkcję lub realizację zamówień.

Dla każdej z tych decyzji warto najpierw cofnąć się do potrzebnych danych i ich źródeł, a następnie prześledzić, jak informacje są przetwarzane i trafiają do odbiorcy.

Taka analiza pokazuje, gdzie znajduje się rzeczywisty problem: w niejasnej definicji danych, kilku źródłach pokazujących różne wersje tej samej informacji, braku właściciela, niewystarczającej aktualności danych, ręcznym przetwarzaniu albo braku integracji.

Dopiero wtedy można sensownie zdecydować, co rzeczywiście należy zmienić.

Pierwszym pytaniem nie powinno więc być: “Jaki system powinniśmy wdrożyć?”

Znacznie lepiej zacząć od innych:

Na podstawie jakich danych podejmujemy najważniejsze decyzje? Skąd te dane pochodzą, kto za nie odpowiada i jak są przetwarzane? Czy są wystarczająco aktualne w chwili podejmowania decyzji?

Największe korzyści z AI w produkcji przynoszą zwykle nie projekty najbardziej efektowne podczas prezentacji, lecz te, które ograniczają koszt lub skutki konkretnego problemu operacyjnego i wykorzystują wiarygodne dane. Trzeba przy tym rozróżnić czas uruchomienia rozwiązania, czas do pierwszego mierzalnego efektu i okres zwrotu z inwestycji.

System pracujący z dokumentacją techniczną można uruchomić stosunkowo szybko i wcześnie ocenić jego przydatność. Model przewidujący rzadkie, ale bardzo kosztowne awarie może wymagać znacznie dłuższego przygotowania, a mimo to mieć większy docelowy potencjał finansowy.

Dlatego pytanie “gdzie możemy zastosować AI?” rzadko jest dobrym punktem wyjścia. Lepsze brzmi: który problem operacyjny warto rozwiązać i jaka technologia będzie do tego najbardziej odpowiednia?

W skrócie

Gdzie AI daje szybki zwrot?
Tam, gdzie oczekiwana strata wynikająca z problemu jest wysoka, dane są dostępne i wystarczająco wiarygodne, a osiągalne korzyści mogą pokryć pełny koszt rozwiązania w akceptowalnym czasie.

Czy każdy problem wymaga AI?
Nie. Często lepsza jest integracja, klasyczna automatyzacja albo optymalizacja matematyczna.

Czy bałagan w danych wyklucza AI?
Nie. Dane nieustrukturyzowane lub rozproszone to coś innego niż dane niewiarygodne.

Kiedy AI automatyzuje chaos?
Gdy przyspiesza źle zdefiniowany proces albo działa na informacjach, które nie odpowiadają rzeczywistemu przebiegowi operacji.

Gdzie AI daje najszybszy zwrot w firmie produkcyjnej?

Do pierwszego pilotażu nie zawsze warto wybierać zastosowania o największym potencjale finansowym. Liczy się jednocześnie skala problemu, dostępność i wiarygodność danych, koszt uruchomienia rozwiązania oraz czas potrzebny do osiągnięcia pierwszego mierzalnego efektu.

Warto od początku rozdzielić trzy pojęcia:

Zastosowanie, które można szybko przetestować, nie zawsze daje najwyższy zwrot. Z kolei projekt o największym potencjale nie musi być najlepszym pierwszym wdrożeniem.

Wiedza techniczna i dokumentacja

Jednym z zastosowań, które można stosunkowo szybko zweryfikować, jest wykorzystanie generatywnej sztucznej inteligencji do pracy z istniejącą wiedzą techniczną.

W wielu firmach problemem nie jest brak informacji. Instrukcje maszyn, procedury, dokumentacja serwisowa, zgłoszenia i historia wcześniejszych awarii istnieją, ale są rozproszone pomiędzy katalogami, systemami i formatami. Technik musi wiedzieć, gdzie szukać informacji, znaleźć odpowiedni dokument i samodzielnie przeanalizować jego treść.

System AI może znacznie skrócić czas potrzebny na wyszukanie i analizę informacji. Warunkiem nie jest jednak samo podłączenie modelu do folderu z dokumentami. Rozwiązanie powinno uwzględniać obowiązujące wersje dokumentacji i uprawnienia użytkowników, wskazywać źródło odpowiedzi oraz potrafić odmówić odpowiedzi albo wyraźnie zaznaczyć, że dostępne informacje nie pozwalają na wiarygodny wniosek.

Analiza odchyleń i priorytetyzacja wyjątków

Dobrymi kandydatami są również procesy, w których pracownik codziennie analizuje wiele raportów, rekordów, alertów lub zdarzeń tylko po to, żeby znaleźć kilka przypadków wymagających reakcji.

System może wstępnie wykrywać odchylenia, grupować zdarzenia i kierować uwagę na te, które mają największe znaczenie operacyjne.

Wartością nie jest kolejny automatycznie wygenerowany raport. Wartością jest ograniczenie zakresu informacji, który człowiek musi ręcznie przeanalizować, zanim zauważy problem wymagający decyzji.

Podobne podejście można zastosować w zakupach i gospodarce materiałowej. System nie musi automatycznie składać zamówień – może wskazywać komponenty najbardziej zagrożone brakiem, opóźnieniem dostawy albo nadmiernym zapasem.

Czy predykcyjne utrzymanie ruchu jest dobrym pierwszym projektem AI?

Nie zawsze. Predykcyjne utrzymanie ruchu, określane również jako predictive maintenance, może mieć bardzo wysoki potencjał, ale zwykle wymaga dłuższej, spójniejszej i lepiej opisanej historii danych niż prostsze zastosowania AI.

W przypadku modelu uczonego do przewidywania konkretnego typu awarii potrzebna jest zwykle odpowiednia historia zdarzeń oraz informacja, jakie sygnały poprzedzały wcześniejsze problemy.

Sama trafność predykcji również nie wystarcza. Prognoza musi pojawić się na tyle wcześnie, żeby możliwa była reakcja. Model, który trafnie ostrzega o awarii pięć minut przed zatrzymaniem maszyny, może nie przynieść praktycznej korzyści, jeśli dział utrzymania ruchu potrzebuje dwóch godzin na interwencję. Z kolei zbyt duża liczba fałszywych alarmów szybko podważy zaufanie do systemu.

Dlatego warto rozważać także prostsze zastosowania: dostęp do wiedzy, wsparcie diagnostyki, analizę historii usterek czy wykrywanie nietypowych zachowań maszyny.

Kontrola jakości – nie tylko rozpoznawanie obrazu

AI sprawdza się również tam, gdzie jakość można oceniać na podstawie powtarzalnych danych: obrazu, wyników pomiarów, parametrów procesu albo historii niezgodności.

Widzenie komputerowe (computer vision) może wspierać wykrywanie wad produktu. Modele uczenia maszynowego mogą analizować zależności między parametrami procesu a wynikiem jakościowym. Generatywna AI może pomagać klasyfikować opisy niezgodności i wyszukiwać podobne przypadki.

Jeżeli doświadczeni kontrolerzy regularnie oceniają te same przypadki inaczej, przed automatyzacją trzeba ustalić dopuszczalne kryteria, zasady eskalacji oraz koszt obu rodzajów błędów: przepuszczenia rzeczywistej wady i niepotrzebnego odrzucenia poprawnego produktu.

Planowanie produkcji – AI nie zastępuje optymalizacji

Planowanie dobrze pokazuje, dlaczego AI nie powinno być traktowane jako jedna technologia.

Model uczenia maszynowego może przewidywać bardziej realistyczny czas wykonania operacji. Generatywna AI może zestawić dane źródłowe i przedstawić w czytelnej formie czynniki, które wpłynęły na ocenę ryzyka. Takie wyjaśnienie powinno wynikać z danych lub modelu analitycznego, a nie z samej narracji modelu językowego.

Do wyznaczenia harmonogramu przy wielu ograniczeniach służą natomiast algorytmy i silniki optymalizacyjne.

Nawet matematycznie optymalny wynik jest jednak tyle wart, ile kompletność modelu procesu. Jeżeli pominiemy krytyczne ograniczenie – na przykład dostępność konkretnego operatora, narzędzia lub materiału – system może stworzyć plan poprawny matematycznie, ale niewykonalny na hali.

Najlepsze rozwiązanie może więc łączyć predykcję, optymalizację i wsparcie decyzji.

Czy każdy problem operacyjny warto rozwiązywać za pomocą AI?

Nie. Jeżeli problem można niezawodnie rozwiązać prostszym mechanizmem, AI może jedynie zwiększyć koszt, złożoność i liczbę elementów wymagających późniejszego utrzymania.

Jeżeli po zatwierdzeniu zamówienia dane mają zostać przesłane do ERP, potrzebna jest integracja. Jeżeli zlecenie przekraczające określony próg wymaga dodatkowej akceptacji, wystarczy reguła biznesowa. Jeżeli trzeba znaleźć najlepszą kombinację spośród wielu wariantów przy znanych ograniczeniach, właściwym narzędziem może być optymalizacja matematyczna.

AI ma szczególne uzasadnienie tam, gdzie trzeba interpretować nieustrukturyzowane informacje, rozpoznawać wzorce, klasyfikować, prognozować albo pracować z sytuacjami, których nie da się rozsądnie opisać kompletnym zestawem sztywnych reguł.

W złożonych procesach ostatni wariant bywa najbardziej użyteczny.

System wspierający planowanie może pobierać dane przez klasyczne integracje, wykorzystywać model predykcyjny do szacowania czasów wykonania, silnik optymalizacyjny do budowy harmonogramu, generatywną AI do przedstawiania kontekstu oraz czynników wpływających na ocenę ryzyka, a reguły biznesowe do kontroli operacji wymagających zgody człowieka.

Najlepsze rozwiązania wykorzystujące AI nie muszą być systemami zbudowanymi wokół AI. Powinny być systemami rozwiązującymi konkretny problem biznesowy, w których AI odpowiada tylko za tę część zadania, w której poprawia wynik albo ogranicza koszt.

Czy AI ma sens, jeśli firma ma bałagan w danych?

Tak – jeżeli problemem jest nieuporządkowana forma lub rozproszenie danych. Znacznie większą przeszkodą są informacje błędne, nieaktualne albo zdarzenia, których firma w ogóle nie rejestruje.

“Bałagan w danych” może oznaczać co najmniej trzy różne sytuacje:

Nie ma potrzeby porządkowania wszystkich danych w firmie przed pierwszym projektem.

Jeżeli celem jest skrócenie czasu diagnozy awarii, znaczenie mają przede wszystkim dane dotyczące maszyn, zgłoszeń, wcześniejszych napraw i dokumentacji technicznej. Dane sprzedażowe czy finansowe nie muszą być częścią tego projektu.

Czy AI może pracować na PDF-ach, Excelach i mailach?

Tak. Sam fakt, że informacje znajdują się w takich formatach, nie wyklucza ich wykorzystania przez AI.

Znaczenie mają jednak czytelność, struktura, możliwość wiarygodnego wydobycia treści, wersjonowanie i kontekst.

Skan o słabej jakości, rozbudowany arkusz z makrami czy dokument bez informacji o wersji mogą wymagać dodatkowego przygotowania.

Problemem nie jest więc sam PDF. Problemem może być pięć PDF-ów opisujących tę samą procedurę, jeżeli nikt nie wie, który z nich jest aktualny.

Co zrobić z danymi rozproszonymi między ERP, MES i innymi źródłami?

Trzeba przede wszystkim nadać im wspólny kontekst.

ERP może zawierać dane o zleceniu i terminie, MES – informacje o aktualnym postępie produkcji, system magazynowy – dane o materiałach, a dodatkowy arkusz – informacje o wyjątkach nieobsługiwanych przez pozostałe systemy.

Każde źródło może być poprawne. Problem pojawia się wtedy, gdy nie wiadomo, jak łączyć rekordy, które źródło jest wiążące dla danego typu informacji, jak mapować statusy pomiędzy systemami i co oznacza brak określonej wartości.

Model AI nie powinien zgadywać znaczenia statusów, identyfikatorów ani zależności pomiędzy danymi.

Czy AI może naprawić dane złej jakości?

Tylko częściowo.

Może wykrywać nietypowe wartości, klasyfikować dane, wskazywać niespójności i pomagać w ich porządkowaniu. Nie odtworzy jednak wiarygodnie zdarzenia, którego firma nigdy nie zarejestrowała.

Jeżeli maszyna była zatrzymana, ale przestój nie trafił do systemu, tej informacji po prostu nie ma. Jeżeli pracownicy wybierają przypadkową przyczynę awarii tylko po to, żeby zamknąć zgłoszenie, historia awarii nie odzwierciedla ich rzeczywistych przyczyn.

AI może pomóc uporządkować informacje. Nie może stworzyć wiarygodnego obrazu operacji tam, gdzie firma sama nie rejestruje rzeczywistości.

Kiedy AI zamiast poprawiać proces automatyzuje chaos?

Wtedy, gdy zwiększa szybkość działania procesu, zanim firma ustali, czy proces jest poprawny, dane jednoznaczne, a wynik możliwy do zweryfikowania.

Najczęściej widać to nie w spektakularnych błędach, ale w ręcznych obejściach oficjalnego procesu: dodatkowych Excelach, decyzjach podejmowanych telefonicznie, statusach interpretowanych inaczej przez różne działy czy wiedzy dostępnej tylko kilku osobom.

Dobrym przykładem jest raportowanie operacyjne.

Załóżmy, że model ma przygotowywać codzienne podsumowanie wyników produkcji na podstawie ERP, raportu produkcyjnego i arkusza controllingowego.

Jeżeli wszystkie źródła używają tych samych definicji i wiadomo, które źródło jest wiążące dla każdego wskaźnika, system może szybko wskazać odchylenia i przygotować ich kontekst.

Jeżeli jednak każde źródło inaczej definiuje wydajność, oblicza ją na innym etapie procesu albo dla innego przedziału czasu, AI może stworzyć bardzo przekonujące podsumowanie na podstawie danych, które wzajemnie sobie przeczą.

Płynna i logiczna odpowiedź nie jest dowodem poprawności informacji wejściowych.

Jak sprawdzić, czy proces jest dobrym kandydatem do AI?

Dobry przypadek użycia łączy istotny problem biznesowy, wystarczającą gotowość procesu i danych oraz akceptowalne ryzyko błędu.

Jak ocenić konsekwencje błędu?

Zanim zaczniemy porównywać potencjalne korzyści poszczególnych projektów, trzeba odpowiedzieć na szersze pytanie:

co się stanie, jeśli system poda błędny wynik, nie poda go na czas albo będzie niedostępny?

Inaczej ocenia się rozwiązanie, które błędnie sklasyfikuje wewnętrzny dokument, a inaczej system, którego rekomendacja może prowadzić do odrzucenia produktu, zatrzymania maszyny albo zmiany harmonogramu całej linii.

Ryzyko zależy od skutku błędu, jego prawdopodobieństwa, wykrywalności, czasu potrzebnego na reakcję i możliwości cofnięcia decyzji.

Łatwiej je ograniczyć, gdy istnieją mechanizmy wskazujące sytuacje wymagające dodatkowej kontroli, decyzję można przekazać człowiekowi, operację cofnąć albo przejść na bezpieczny tryb działania.

Trzeba również ustalić tryb awaryjny: jak proces działa bez rozwiązania AI i kto przejmuje decyzję, gdy system jest niedostępny albo nie może dostarczyć wyniku w wymaganym czasie.

Jeżeli błąd może wywołać poważne i trudne do odwrócenia konsekwencje, zakres automatyzacji powinien być odpowiednio mniejszy.

Macierz wartości i gotowości

Po ocenie ryzyka przypadek użycia warto rozpatrzyć w dwóch wymiarach.

Połączenie wysokiej wartości i wysokiej gotowości oznacza problem, który ma znaczenie, dysponujemy odpowiednimi danymi, rozumiemy proces i potrafimy zmierzyć rezultat.

Wysoka wartość przy niskiej gotowości nie oznacza, że AI nie ma sensu. Jeżeli koszt awarii maszyny jest bardzo wysoki, ale brakuje właściwej historii zdarzeń, pierwszym etapem może być poprawa sposobu ich rejestrowania.

Niska wartość przy wysokiej gotowości to kategoria, w której łatwo wdrażać AI tylko dlatego, że technicznie jest to proste. Sam fakt, że coś można łatwo zautomatyzować, nie oznacza jeszcze, że warto.

Niska wartość przy niskiej gotowości zwykle oznacza brak uzasadnienia do inwestycji.

Pięć pytań biznesowych przed rozpoczęciem projektu AI

Po ocenie ryzyka warto odpowiedzieć na pięć pytań:

1. Jaki dokładnie problem operacyjny rozwiązujemy?
2. Jaki koszt generuje ten problem i na jaki wynik operacyjny wpływa?
3. Jaką decyzję lub czynność chcemy usprawnić, jak jest dzisiaj wykonywana i kto za nią odpowiada?
4. Jakich danych potrzebujemy i czy możemy im wystarczająco ufać?
5. Po czym jednoznacznie poznamy, że rozwiązanie działa lepiej niż obecny sposób pracy?

Jeżeli odpowiedzi prowadzą do wniosku, że wystarczy integracja albo klasyczna automatyzacja, analiza spełniła swoje zadanie.

Celem kwalifikacji projektu nie jest udowodnienie, że potrzebujemy AI. Celem jest wybranie rozwiązania, którego oczekiwany efekt uzasadnia koszt, złożoność i ryzyko.

Proof of Concept, pilotaż biznesowy i wdrożenie operacyjne – czym się różnią?

Te trzy etapy odpowiadają na różne pytania i nie powinny być traktowane zamiennie.

PoC może pokazać, że model poprawnie klasyfikuje dokumenty albo odpowiada na pytania z instrukcji. Nie dowodzi jeszcze, że pracownik wykona dzięki temu swoją pracę szybciej ani że rozwiązanie będzie opłacalne.

Pilotaż powinien obejmować rzeczywiste lub reprezentatywne dane, udział docelowych użytkowników oraz najważniejsze elementy przyszłego procesu.

Pilotaż nie musi obejmować dużej skali. Można ograniczyć go do jednej linii, typu produktu, grupy maszyn czy kilku użytkowników. Nie należy jednak usuwać elementów, które mogą zdecydować o wyniku – na przykład integracji, jeśli właśnie dostępność aktualnych danych jest głównym ryzykiem projektu.

Przed pilotażem trzeba określić stan wyjściowy

Bez punktu odniesienia nie wiadomo, czy nastąpiła poprawa.

Jeżeli system ma wspierać diagnostykę, można mierzyć czas wyszukiwania informacji, czas znalezienia przyczyny oraz średni czas naprawy i przywrócenia urządzenia do pracy.

Jeżeli ma wykrywać odchylenia, interesuje nas czas analizy, liczba przypadków wymagających reakcji oraz czas od pojawienia się problemu do jego zauważenia.

Porównując wyniki sprzed pilotażu z wynikami uzyskanymi w jego trakcie, trzeba również uwzględnić równoległe zmiany wolumenu, asortymentu, obsady, materiałów lub organizacji procesu.

Pozytywna opinia użytkowników jest istotna, ale sama nie pokazuje zwrotu z inwestycji.

Czy pilotaż powinien od razu zakładać pełną autonomię?

Nie. Na etapie pierwszego pilotażu system AI powinien przede wszystkim rekomendować, priorytetyzować lub klasyfikować, zamiast samodzielnie wykonywać decyzje o dużych konsekwencjach.

Dzięki temu można obserwować, jak często użytkownik akceptuje rekomendację, w jakich sytuacjach ją odrzuca oraz kiedy system nie ma wystarczających informacji.

Samo formalne zatwierdzenie przez człowieka nie jest jednak wystarczającym zabezpieczeniem. Użytkownik musi mieć dostęp do źródeł, kryteriów i informacji potrzebnych do oceny rekomendacji, a także czas na jej rzeczywistą weryfikację.

Dopiero obserwacja rzeczywistej współpracy człowieka z systemem pokazuje, które decyzje można bezpiecznie automatyzować w większym stopniu.

Po uruchomieniu nadal trzeba mierzyć jakość

Wdrożenie operacyjne nie kończy pracy nad systemem.

Zmieniają się procesy, produkty, dokumentacja, parametry maszyn i zachowania użytkowników. Model, który działał dobrze podczas pilotażu, może po kilku miesiącach wymagać ponownej walidacji.

Monitorowanie powinno obejmować nie tylko dostępność aplikacji, ale również jakość wyników i zmianę kluczowych parametrów procesu.

Przykład: jak może wyglądać pilotaż AI w firmie produkcyjnej?

Rozważmy przykładową firmę, w której planista codziennie analizuje kilkaset odchyleń dotyczących zleceń produkcyjnych. Większość nie wymaga działania, ale część może prowadzić do opóźnienia, problemu materiałowego albo konfliktu z innym zleceniem.

To scenariusz ilustracyjny, a nie opis konkretnego wdrożenia.

Problem: planista poświęca znaczną część dnia na ręczne przeglądanie informacji, żeby znaleźć niewielką grupę zdarzeń wymagających reakcji.

Stan wyjściowy: przed rozpoczęciem pilotażu mierzymy czas analizy, liczbę spraw przeglądanych dziennie, liczbę przypadków faktycznie wymagających interwencji oraz czas od pojawienia się istotnego problemu do jego zauważenia.

Dane: z ERP pobieramy informacje o zleceniach i terminach, z MES lub innego systemu rejestrującego wykonanie produkcji – dane o aktualnym postępie, a z systemu magazynowego – informacje o dostępności kluczowych materiałów. Najpierw trzeba ustalić, czy identyfikatory i statusy pozwalają te informacje wiarygodnie połączyć.

Zakres pilotażu: zamiast automatycznie zmieniać harmonogram, system ocenia ryzyko i priorytetyzuje zdarzenia. Planista nadal podejmuje decyzję. Pilotaż obejmuje jedną linię lub wybraną grupę zleceń.

Zabezpieczenia: błędne wskazanie nie zmienia automatycznie planu. Fałszywy alarm oznacza dodatkową weryfikację przez planistę, natomiast pominięcie rzeczywiście zagrożonego zlecenia jest rejestrowane i analizowane.

Porównanie z prostszą alternatywą: wynik modelu warto zestawić również z prostym mechanizmem regułowym. Jeżeli kilka przejrzystych reguł wskazuje zagrożone zlecenia równie skutecznie, zastosowanie AI nie ma wystarczającego uzasadnienia.

Kryteria sukcesu: przed rozpoczęciem pilotażu trzeba ustalić główne wskaźniki oraz minimalne wartości, których osiągnięcie uzasadni dalszy rozwój projektu. Mogą to być na przykład:

• określone skrócenie czasu ręcznej analizy,
• maksymalny dopuszczalny odsetek ważnych problemów pominiętych przez system,
• wymagane skrócenie czasu reakcji,
• odpowiedni odsetek ostrzeżeń, które umożliwiły skuteczną interwencję, o ile w trakcie pilotażu wystąpiła wystarczająca liczba takich zdarzeń.

Wskaźniki diagnostyczne: dodatkowo warto obserwować:

• liczbę fałszywych alarmów,
• odsetek rekomendacji odrzuconych przez planistę,
• typy przypadków, dla których system działa najsłabiej,
• wpływ na terminowość zleceń, jeżeli zakres i czas trwania pilotażu pozwalają ocenić go wiarygodnie.

Decyzja: jeżeli system osiąga ustalone wcześniej kryteria, ogranicza ręczną analizę i poprawia czas reakcji przy akceptowalnym poziomie błędów, można rozszerzyć zakres. Jeżeli największym problemem okazują się niespójne statusy pomiędzy systemami, kolejną inwestycją może być poprawa danych i integracji, a nie bardziej zaawansowany model.

Taki pilotaż pozwala odpowiedzieć na pytanie biznesowe. Nie sprawdza wyłącznie, czy model “potrafi analizować dane”.

Jak mierzyć zwrot z AI w firmie produkcyjnej?

Zwrot z inwestycji ocenia się, przeliczając zmianę wyniku operacyjnego na wartość pieniężną i porównując ją z pełnym kosztem rozwiązania w tym samym okresie. Liczba użytkowników, zapytań do modelu czy wygenerowanych raportów opisuje wykorzystanie narzędzia, a nie jego opłacalność.

Warto rozróżnić trzy podstawowe miary.

Korzyść netto:

wartość pieniężna korzyści w analizowanym okresie – całkowity koszt rozwiązania w tym samym okresie

Uproszczone ROI:

(wartość pieniężna korzyści w analizowanym okresie – całkowity koszt rozwiązania w tym samym okresie) / całkowity koszt rozwiązania w tym samym okresie × 100%

Okres zwrotu:

czas, po którym skumulowane korzyści pomniejszone o koszty bieżące pokrywają początkowy nakład.

Nie każdy projekt wymaga rozbudowanego modelu finansowego, ale tych pojęć nie należy traktować zamiennie.

Jeżeli korzyści nie można wiarygodnie przeliczyć na pieniądze, lepiej pokazać ją jako osobny efekt operacyjny niż włączać do pozornie precyzyjnego wyliczenia ROI.

KPI powinien wynikać z problemu

Dla utrzymania ruchu mogą to być czas przestoju, średni czas naprawy i przywrócenia urządzenia do pracy albo liczba nieplanowanych zatrzymań.

W kontroli jakości istotne mogą być poziom braków, koszt kontroli czy odsetek produktów przechodzących proces poprawnie za pierwszym razem.

W planowaniu będą to między innymi terminowość, czas realizacji i liczba pilnych zmian harmonogramu.

System wspierający pracę z dokumentacją może przede wszystkim skracać czas wyszukiwania informacji i diagnostyki.

Nie trzeba na siłę sprowadzać każdego projektu do tego samego KPI.

Uwolniony czas nie zawsze oznacza oszczędność

Jeżeli AI skraca przygotowanie raportu z dwóch godzin do trzydziestu minut, uwalnia półtorej godziny pracy.

Nie oznacza to automatycznie oszczędności odpowiadającej półtorej godziny wynagrodzenia.

Korzyść powstaje wtedy, gdy pracownik może obsłużyć większą skalę, szybciej reagować na problemy, ograniczyć nadgodziny albo wykorzystać czas do zadań o większym znaczeniu.

Dlatego trzeba odróżnić czas uwolniony od korzyści uzyskanej dzięki temu czasowi.

Korzyść może polegać na uniknięciu straty

Przy awariach, problemach jakościowych, opóźnieniach czy brakach materiałowych główną korzyścią może być uniknięcie kosztownego zdarzenia.

Taki wynik trzeba liczyć ostrożnie. Samo ostrzeżenie o potencjalnym ryzyku nie oznacza jeszcze, że system zapobiegł całej możliwej stracie.

Im większą korzyść przypisujemy unikniętym zdarzeniom, tym ważniejsza jest wiarygodna metoda porównania z wcześniejszym sposobem działania.

Koszt AI to znacznie więcej niż model

Do całkowitego kosztu posiadania należy wliczyć między innymi:

• analizę procesu,
• czas ekspertów dziedzinowych i użytkowników zaangażowanych w projekt,
• przygotowanie danych,
• integracje,
• implementację,
• infrastrukturę,
• licencje lub API,
• szkolenia i zmianę sposobu pracy,
• bezpieczeństwo, kontrolę dostępu i audyt,
• monitorowanie,
• utrzymanie,
• ponowną walidację,
• obsługę przypadków wymagających człowieka,
• zmiany po aktualizacji systemów źródłowych.

Najdroższą częścią projektu nie musi być sam model. W rozwiązaniach operacyjnych dużą część kosztu stanowią często integracje, obsługa wyjątków i włączenie systemu do codziennej pracy.

Dokładność modelu nie jest jeszcze KPI biznesowym

Model o wysokiej ogólnej dokładności może być bardzo użyteczny albo całkowicie nieakceptowalny.

Wyobraźmy sobie proces, w którym tylko 1% produktów ma wadę. System uznający każdy produkt za prawidłowy osiągnąłby 99% ogólnej dokładności, a jednocześnie nie wykryłby ani jednej wady.

Dlatego przy rzadkich zdarzeniach znacznie ważniejsze od samej ogólnej dokładności są rodzaje popełnianych błędów: ile rzeczywistych problemów system pomija i ile generuje fałszywych alarmów.

Znaczenie ma również koszt każdego z tych błędów.

Błędnie oznaczony dokument może po prostu trafić do ręcznej weryfikacji. Przepuszczenie krytycznej wady produktu może być niedopuszczalne nawet przy bardzo wysokiej ogólnej skuteczności modelu.

Od czego zacząć wdrażanie AI w firmie produkcyjnej?

Od problemu, nie od technologii.

Najpierw warto znaleźć kilka obszarów, w których firma regularnie traci czas lub pieniądze albo jest narażona na istotne ryzyko. Następnie trzeba porównać je pod względem potencjalnej korzyści, gotowości procesu i danych oraz konsekwencji błędu.

Dalsza kolejność jest prosta:

problem -> proces -> dane -> technologia -> pilotaż -> pomiar -> decyzja o skalowaniu

Wynikiem analizy nie musi być projekt AI. Może się okazać, że potrzebna jest integracja, prostsza automatyzacja, poprawa sposobu rejestrowania zdarzeń albo zmiana samego procesu.

Taka decyzja jest lepsza niż wdrożenie AI tylko dlatego, że technicznie da się je zbudować.

Najczęstsze pytania o AI w firmach produkcyjnych

Czy AI w produkcji wymaga dużej ilości danych?

Nie. Wymagana ilość danych zależy od rodzaju zastosowania.

Generatywna AI może pracować z istniejącą dokumentacją, procedurami i opisami zdarzeń bez budowania od podstaw dużego zbioru treningowego. Model predykcyjny tworzony dla konkretnego procesu może natomiast wymagać odpowiednio długiej i reprezentatywnej historii.

Pytanie powinno więc brzmieć nie “czy mamy dużo danych?”, lecz “czy mamy dane potrzebne do rozwiązania tego konkretnego problemu?”.

Czy trzeba mieć MES, żeby wdrożyć AI w produkcji?

Nie. MES może być bardzo wartościowym źródłem informacji, ale nie jest warunkiem każdego projektu.

Dane mogą pochodzić z ERP, systemów realizacji produkcji, systemów magazynowych, systemów jakościowych, maszyn, dokumentacji lub arkuszy. Ważniejsze jest to, czy opisują potrzebny fragment procesu wystarczająco wiarygodnie.

Czy firma potrzebuje własnego zespołu data science?

Nie. Przy pierwszym, ograniczonym projekcie firma może skorzystać z kompetencji zewnętrznego zespołu.

Musi natomiast zapewnić udział osób dobrze rozumiejących proces i dane oraz potrafiących ocenić, czy wynik systemu jest poprawny.

Wraz ze wzrostem liczby i znaczenia rozwiązań AI firma potrzebuje jednak coraz większych kompetencji wewnętrznych w obszarze architektury, danych, bezpieczeństwa, monitorowania i zarządzania systemami.

Czy rozwiązanie AI musi działać w chmurze?

Nie.

Możliwe są architektury chmurowe, lokalne i hybrydowe. Wybór zależy od rodzaju rozwiązania, systemów źródłowych, wymaganej wydajności, kosztu, bezpieczeństwa i zasad przetwarzania danych.

Technologia powinna wynikać z wymagań projektu, a nie odwrotnie.

Czy AI może korzystać z poufnej dokumentacji firmowej?

Tak, ale wymaga to świadomego zaprojektowania architektury.

Trzeba ustalić, gdzie dane są przetwarzane, jakie informacje opuszczają infrastrukturę firmy, kto może uzyskać do nich dostęp, jak długo dane są przechowywane, na jakich zasadach można je usunąć oraz czy mogą być wykorzystywane do trenowania lub doskonalenia modeli.

Potrzebne mogą być również mechanizmy kontroli dostępu, rejestrowania operacji i audytu.

Poufność dokumentacji nie wyklucza wykorzystania AI. Wpływa natomiast na sposób, w jaki rozwiązanie powinno zostać zbudowane.