Firma może mieć ERP, system do planowania produkcji, dane z magazynu, informacje z maszyn i rozbudowane raportowanie, a mimo to nadal nie wiedzieć, co dokładnie dzieje się na produkcji i które sytuacje wymagają reakcji.

Spójny obraz sytuacji nie wymaga jednego systemu. Wymaga jasno określonej odpowiedzialności za dane, kontrolowanego sposobu ich wymiany, wspólnych reguł interpretacji oraz informacji o tym, jak aktualne i kompletne są dane wykorzystywane do oceny sytuacji.

Nie chodzi więc o zebranie wszystkiego w jednym miejscu, lecz o zbudowanie przepływu informacji, który pozwala ustalić, gdzie realizacja odbiega od planu, z czego to wynika i czy potrzebna jest reakcja.

Dlaczego ERP nie zawsze daje pełny obraz bieżącej sytuacji?

ERP może być najważniejszym systemem biznesowym w firmie produkcyjnej i jednocześnie nie zawierać wszystkich informacji potrzebnych do bieżącego sterowania produkcją.

Może przechowywać zamówienia, terminy, strukturę produktu czy zlecenia produkcyjne. Ocena aktualnej sytuacji może jednak wymagać również harmonogramu, postępu operacji, dostępności materiałów czy informacji o niedostępności zasobów.

Dlatego odpowiedź na pytanie “Czy to zlecenie nadal może zostać zrealizowane w terminie?” często nie znajduje się bezpośrednio w jednym systemie.

Nie oznacza to, że ERP jest niewłaściwy. Informacja potrzebna do decyzji może po prostu powstawać dopiero po zestawieniu danych z kilku źródeł.

Co oznacza spójny obraz sytuacji operacyjnej?

Spójny obraz sytuacji operacyjnej nie polega na pokazaniu wszystkich dostępnych danych na jednym ekranie. Chodzi o możliwość szybkiego ustalenia:

• czy realizacja przebiega zgodnie z planem,
• gdzie pojawiło się odchylenie,
• co jest jego przyczyną,
• jaki może być wpływ na kolejne operacje lub terminy,
• które sytuacje wymagają reakcji,
• czy dane pozwalają w ogóle wiarygodnie ocenić sytuację.

Lista zleceń, statusów i terminów pokazuje dane. Widok wskazujący konkretne odchylenie, jego przyczynę, przewidywany wpływ oraz aktualność informacji daje podstawę do podjęcia decyzji.

Szczegóły nadal powinny być dostępne. Użytkownik nie powinien jednak za każdym razem samodzielnie odtwarzać całej analizy przez porównywanie kilku systemów.

Integrację warto projektować od decyzji, a nie od systemów

Dobrym punktem wyjścia nie jest pytanie “Jak połączyć ERP, MES i WMS?”, lecz:

“Jaką decyzję chcemy podejmować i jakiej informacji dziś nam do niej brakuje?”

Załóżmy, że chcemy wiedzieć, czy kolejna operacja może rozpocząć się zgodnie z harmonogramem. Można wtedy przejść przez kolejne elementy:

pytanie biznesowe -> potrzebna informacja -> dane -> źródło -> reguły -> wymagana aktualność -> sposób prezentacji lub działania

Potrzebne mogą być na przykład:

• planowany czas rozpoczęcia operacji,
• zakończenie operacji poprzedzającej,
• dostępność wymaganych materiałów,
• dostępność maszyny i innych zasobów,
• status przygotowania materiału na stanowisko.

Następnie trzeba ustalić zasady oceny.

Samo opóźnienie poprzedniej operacji nie musi oznaczać problemu, jeśli harmonogram zawiera wystarczający zapas czasu. Podobnie materiał, którego nie ma jeszcze na stanowisku, nie musi być zagrożeniem, jeżeli jego przygotowanie i dostarczenie zajmuje mniej czasu niż pozostało do rozpoczęcia produkcji.

Technicznie trzeba zapewnić udostępnianie, przesyłanie i przetwarzanie danych. Ich znaczenie wynika natomiast z procesu, zasad planowania i sposobu działania konkretnej firmy.

Jak połączyć ERP, planowanie i dane z produkcji?

Integracja powinna tworzyć kontrolowany przepływ od danych źródłowych do informacji wykorzystywanej w decyzjach. Sam dostęp do kilku systemów nie wystarczy.

W uproszczeniu można wyróżnić trzy warstwy:

źródła i wymiana danych -> model danych i reguły biznesowe -> prezentacja i działanie

1. Źródła i wymiana danych

Najpierw trzeba ustalić, gdzie powstają informacje potrzebne do danego procesu.

W jednej firmie większość informacji może znajdować się w ERP. W innej harmonogram powstaje w systemie zaawansowanego planowania i harmonogramowania APS, a wykonanie rejestruje system wspierający realizację produkcji MES. Operacje magazynowe może obsługiwać WMS, czyli system zarządzania magazynem.

Nie każda firma musi mieć wszystkie te systemy – istotne jest to, gdzie rzeczywiście powstają potrzebne informacje.

Dane można pobierać przez API, czyli interfejs umożliwiający systemom wymianę danych, albo za pomocą plików wymiany. Aktualizacja może następować cyklicznie albo po określonym zdarzeniu. Procesy ETL służą natomiast do pobierania, przekształcania i ładowania danych do środowiska docelowego.

W starszych systemach spotyka się również odczyt danych bezpośrednio z bazy. W takim przypadku trzeba sprawdzić, czy ten sposób dostępu jest wspierany przez dostawcę, jakie obciążenie powoduje i czy pozostanie zgodny z kolejnymi wersjami systemu.

Sposób wymiany powinien wynikać z potrzeb procesu. Jeżeli dane wystarczy odświeżyć raz dziennie, mechanizm reagujący na każde zdarzenie może być niepotrzebny. Jeżeli zatrzymanie maszyny powinno w ciągu kilkudziesięciu sekund wpłynąć na ocenę sytuacji, synchronizacja raz na godzinę będzie niewystarczająca.

2. Model danych i reguły biznesowe

Pobranie danych z kilku systemów nie oznacza jeszcze, że można je bezpośrednio zestawić.

Ten sam obiekt może mieć różne identyfikatory, statusy i znaczenia. “Czas operacji” może w jednym systemie oznaczać czas planowany, w innym rzeczywisty czas pracy maszyny, a w kolejnym obejmować także przezbrojenie.

Trzeba więc określić relacje pomiędzy takimi elementami jak:

• zamówienie,
• zlecenie produkcyjne,
• operacja,
• materiał,
• zasób,
• termin,
• aktualny stan wykonania.

Dopiero na tej podstawie można stosować wspólne reguły biznesowe i wyliczać informacje, które nie występują bezpośrednio w żadnym z systemów źródłowych.

3. Prezentacja i działanie

Wynik może zostać udostępniony jako raport w narzędziu analitycznym BI, dashboard operacyjny, lista alertów, dedykowany ekran albo funkcja istniejącego już systemu.

Nie zawsze potrzebna jest nowa aplikacja. Część wymaganych możliwości może już istnieć w ERP, narzędziu planistycznym lub środowisku analitycznym. Przed tworzeniem nowych funkcji warto sprawdzić możliwości już używanych systemów.

Jeżeli użytkownik ma jedynie analizować wynik, wystarczy jego prezentacja. Jeżeli ma również wykonać działanie, trzeba określić, który system ma zarejestrować i wykonać zmianę.

Komentarz lub przypisanie osoby odpowiedzialnej mogą pozostać w warstwie operacyjnej. Zmiana harmonogramu, priorytetu zlecenia albo danych magazynowych powinna natomiast trafić do systemu, który odpowiada za te informacje.

Użytkownik powinien widzieć, czy dyspozycja oczekuje na wykonanie, została wykonana w systemie docelowym czy zakończyła się błędem. Samo przyjęcie żądania nie oznacza jeszcze, że zmiana rzeczywiście została zastosowana. Operacja musi też respektować uprawnienia i reguły obowiązujące w systemie docelowym.

Jak podzielić odpowiedzialność za dane między ERP, APS, MES i WMS?

W integracji ważniejsze od kopiowania tych samych informacji do wielu systemów jest ustalenie, który system odpowiada za konkretne dane i w którym systemie można je zmieniać.

Przykładowo ERP może odpowiadać za zlecenie produkcyjne, system planowania za obowiązujący harmonogram, MES za rejestrację rzeczywistego wykonania, a WMS za określone operacje magazynowe.

Dla istotnych danych trzeba ustalić:

• gdzie powstają,
• gdzie mogą być modyfikowane,
• który system jest referencyjny,
• które inne systemy potrzebują ich kopii,
• w którą stronę przebiega synchronizacja,
• jak szybko zmiana powinna zostać przekazana,
• co ma się wydarzyć w przypadku konfliktu lub braku aktualizacji.

Jeżeli to możliwe, warto unikać sytuacji, w której kilka systemów niezależnie modyfikuje ten sam atrybut i synchronizuje go w obu kierunkach. Bez jasnych zasad rozstrzygania rozbieżności taki model zwiększa ryzyko konfliktów i utrudnia ustalenie, która wartość jest obowiązująca.

Integracja powinna również umożliwiać wykrycie sytuacji, w której przepływ danych przestał działać poprawnie.

Czy wszystkie dane muszą być dostępne w czasie rzeczywistym?

Nie. Dane powinny być aktualizowane tak szybko, jak wymaga tego proces i maksymalny dopuszczalny czas reakcji.

Wymaganie bardzo krótkiego czasu aktualizacji może zwiększać złożoność rozwiązania. Jeżeli kierownik analizuje stan produkcji co kilkanaście minut, aktualizacja co pięć minut może być całkowicie wystarczająca.

Trzeba jednak rozróżnić trzy różne momenty:

• kiedy zdarzenie lub stan został zarejestrowany albo potwierdzony w systemie źródłowym,
• kiedy integracja pobrała tę informację,
• kiedy został odświeżony widok użytkownika.

Udana synchronizacja o 10:00 nie oznacza automatycznie, że dane opisują rzeczywisty stan produkcji z 10:00. Jeżeli wykonanie jest rejestrowane w systemie źródłowym z godzinnym opóźnieniem, częstsze pobieranie danych nie zapewni bieżącego obrazu sytuacji.

Z drugiej strony o aktualności nie przesądza sama data ostatniej zmiany rekordu. Status mógł nie zmienić się od godziny, ale system może nadal potwierdzać, że pozostaje obowiązujący.

Aktualność stanu źródłowego, aktualność synchronizacji i aktualność prezentacji to trzy różne rzeczy.

W rozwiązaniu operacyjnym warto również oddzielić stan procesu od jakości danych. Brak wykrytego ryzyka nie powinien być traktowany tak samo jak sytuacja, w której danych do wiarygodnej oceny jest za mało.

Gdzie definiować KPI, statusy i reguły biznesowe?

Nie ma jednego właściwego miejsca dla wszystkich wskaźników i reguł.

KPI to kluczowe wskaźniki efektywności. Te wykorzystywane w raportowaniu można obliczać we wspólnym modelu analitycznym, także w narzędziu BI.

Inaczej należy traktować reguły, które wpływają na bieżący proces. Jeżeli status “zlecenie zagrożone” uruchamia alert, przypisanie zadania lub zmianę sposobu działania, jego logika powinna być dostępna dla rozwiązania obsługującego ten proces, a nie istnieć wyłącznie jako formuła w pojedynczym raporcie.

Jeżeli właściwy system już wylicza potrzebny wynik, nie należy bez potrzeby tworzyć jego uproszczonej wersji w kolejnym miejscu. Dotyczy to na przykład terminów wyliczonych przez system planowania lub dostępności materiału ustalonej przez system źródłowy.

Najważniejsza jest jedna uzgodniona definicja. Jeżeli to możliwe, ta sama logika nie powinna być odtwarzana niezależnie w kolejnych raportach i aplikacjach.

Przy ocenie produkcji trzeba też rozdzielić:

• wykonanie planu zatwierdzonego na początku zmiany,
• zgodność z aktualnym harmonogramem po kolejnych zmianach,
• dotrzymanie terminów wobec klientów.

Każde z tych porównań odpowiada na inne pytanie i nie powinno być automatycznie sprowadzane do jednego wskaźnika “realizacji planu”.

System powinien umieć powiedzieć również: “nie mam wystarczających danych”

System nie powinien ukrywać braków lub nieaktualności danych.

Jeżeli dane potrzebne do oceny nie zostały zarejestrowane, nie można potwierdzić ich aktualnego stanu albo część źródeł jest niedostępna, poprawnym wynikiem może być:

“Brak wystarczających danych.”

To bardziej użyteczne niż zielony status sugerujący brak problemu.

Pojedynczy błąd synchronizacji nie musi automatycznie unieważniać wyniku. Jeżeli ostatni wiarygodnie potwierdzony stan nadal mieści się w określonym progu aktualności, ocena może pozostać ważna. Z drugiej strony poprawna synchronizacja nie gwarantuje, że zdarzenia są rejestrowane w systemie źródłowym bez opóźnienia.

Co powinien pokazywać wiarygodny dashboard operacyjny?

Dashboard nie powinien prezentować wyłącznie wyniku. Przy informacji wykorzystywanej do bieżących decyzji użytkownik powinien móc sprawdzić przynajmniej:

• co spowodowało dany status,
• na jakich danych został oparty,
• jak aktualne są te dane,
• czy wszystkie wymagane źródła były dostępne,
• jakie ograniczenia ma dana ocena.

Jeżeli wynik jest niewiarygodny z powodu brakujących lub zbyt starych danych, powinno to być widoczne równie wyraźnie jak samo odchylenie produkcyjne.

Na pierwszym poziomie dashboard powinien wskazywać, co wymaga uwagi, na kolejnym – dlaczego, a następnie umożliwiać przejście do szczegółowych danych lub działania.

BI, dashboard operacyjny czy aplikacja – czego potrzebuje firma?

Różnica dotyczy przede wszystkim celu rozwiązania, a nie konkretnego produktu.

W praktyce granice nie są sztywne. Narzędzie BI może obsługiwać część monitoringu, ERP może zawierać mechanizmy obsługi zadań i akceptacji, a dedykowana aplikacja może jednocześnie prezentować dane i rejestrować działania.

Nie należy więc zaczynać od wyboru klasy produktu. Najpierw trzeba ustalić, czy użytkownik ma analizować, obserwować czy również zmieniać przebieg procesu.

Przykład: jak powstaje informacja o ryzyku niedostarczenia materiału na czas?

Rozważmy jedną operację produkcyjną. Przyjęte wartości służą wyłącznie pokazaniu sposobu powstania oceny.

Załóżmy, że jest godzina 9:55.

Zapotrzebowanie materiałowe oraz zadanie związane z dostarczeniem komponentu są powiązane z tą samą operacją produkcyjną. Integracja musi więc prawidłowo odwzorować identyfikatory używane w poszczególnych systemach.

Do rozpoczęcia operacji pozostało 35 minut. Przy standardowym przebiegu przygotowanie i dostarczenie materiału zajmuje około 45 minut, a proces nie został jeszcze rozpoczęty.

Reguła może więc brzmieć:

“Jeśli przygotowanie nie zostało rozpoczęte, a szacowany czas przygotowania i dostarczenia materiału przekracza czas pozostały do startu operacji, system wskazuje ryzyko opóźnienia.”

Wynik nie powinien brzmieć:

“Operacja będzie opóźniona.”

Na podstawie dostępnych danych można stwierdzić wystąpienie ryzyka:

“Ryzyko opóźnienia rozpoczęcia operacji – do planowanego startu pozostało 35 minut, a przygotowanie i dostarczenie materiału zajmuje według przyjętego oszacowania około 45 minut.”

Taki komunikat pokazuje nie tylko status, ale również podstawę jego nadania.

Ta reguła dotyczy etapu przed rozpoczęciem przygotowania materiału. Samo uruchomienie zadania nie oznacza usunięcia ryzyka. Od tego momentu ocena powinna uwzględniać przewidywany termin dostarczenia materiału na stanowisko i porównywać go z planowanym rozpoczęciem operacji.

A co z aktualnością danych?

Załóżmy dodatkowo, że system magazynowy potwierdził o 9:53, że przygotowanie i dostarczenie materiału nie zostały rozpoczęte. Integracja pobrała ten stan o 9:54, a widok został odświeżony o 9:55.

Jeżeli dla tego procesu taki stan jest wystarczająco aktualny, można przeprowadzić ocenę.

Gdyby jednak ostatni wiarygodnie potwierdzony stan pochodził z 9:20 i nie było możliwości ustalenia, czy od tego czasu rozpoczęto przygotowanie materiału, takie dane mogłyby nie spełniać przyjętych wymagań aktualności. Wtedy system powinien oznaczyć bieżącą ocenę jako niemożliwą i nie przedstawiać ostatniego wyniku jako aktualnego.

Poprawnym komunikatem byłoby:

“Brak aktualnych danych magazynowych – nie można wiarygodnie ocenić ryzyka.”

Od informacji do działania

Po wykryciu ryzyka użytkownik może przekazać problem do logistyki. Jeżeli zmienia priorytet zadania magazynowego, zmiana powinna zostać wykonana w systemie odpowiedzialnym za ten proces.

Widok operacyjny powinien pokazywać, czy dyspozycja:

• oczekuje na wykonanie,
• została wykonana w systemie magazynowym,
• zakończyła się błędem.

Samo podniesienie priorytetu nie oznacza jeszcze, że problem został rozwiązany ani że materiał dotarł na stanowisko.

Ocena powinna być przeliczana po zmianie danych oraz odpowiednio często w miarę upływu czasu. Nawet gdy statusy pozostają niezmienione, może ubywać czasu na dostarczenie materiału.

W ten sposób powstaje zamknięty obieg:

dane -> ocena -> działanie -> aktualizacja lub upływ czasu -> ponowna ocena

Jak wdrożyć wspólny widok bez przebudowy całego środowiska IT?

Nie trzeba rozpoczynać od integracji wszystkich systemów i procesów. Lepiej wybrać jeden istotny scenariusz operacyjny i sprawdzić go na rzeczywistych danych.

Może to być na przykład:

• dostępność materiału przed rozpoczęciem operacji,
• terminowość zleceń,
• monitoring przestojów,
• wykorzystanie kluczowego zasobu,
• wybrany rodzaj odchylenia jakościowego.

1. Zdefiniować decyzję i zakres

Zamiast “potrzebujemy dashboardu produkcyjnego” lepiej określić:

“Chcemy odpowiednio wcześnie wykrywać operacje, których rozpoczęcie jest zagrożone niedostarczeniem materiału na czas.”

2. Określić dane, źródła i reguły

Trzeba ustalić:

• jakich danych wymaga ocena,
• gdzie są rejestrowane,
• który system za nie odpowiada,
• jak aktualne muszą być,
• jak działa reguła,
• kto ją zatwierdza i odpowiada za aktualizację jej parametrów,
• co powinno się wydarzyć po wykryciu problemu.

Nie ma potrzeby pobierania całej zawartości ERP czy MES, jeśli pierwszy scenariusz wymaga kilkunastu konkretnych pól.

3. Zbudować minimalny, ale kontrolowany przepływ

Pierwsza integracja może obejmować tylko kilka źródeł.

Powinna jednak uwzględniać:

• jednoznaczną identyfikację rekordów,
• obsługę błędów synchronizacji,
• kontrolę aktualności i kompletności danych,
• monitoring działania integracji,
• możliwość ustalenia źródła wyniku,
• sposób sygnalizowania sytuacji, w której ocena nie jest możliwa.

4. Zweryfikować rozwiązanie na rzeczywistych przypadkach

Nie wystarczy sprawdzić, czy system generuje poprawne alerty.

Trzeba przeanalizować również sytuacje, w których rzeczywisty problem wystąpił, ale rozwiązanie go nie wskazało.

Weryfikacja powinna odpowiedzieć między innymi na pytania:

• czy problem jest wykrywany odpowiednio wcześnie,
• ile nieistotnych ostrzeżeń generuje system,
• czy istotne przypadki nie są pomijane,
• czy użytkownik rozumie przyczynę statusu,
• czy dane są wystarczająco aktualne,
• czy dalsze działanie faktycznie trafia do właściwego procesu.

Przed uruchomieniem trzeba też uzgodnić dopuszczalne opóźnienie danych, sposób sygnalizowania awarii oraz odpowiedzialność za przywrócenie działania integracji.

5. Rozszerzać zakres po sprawdzeniu pierwszego scenariusza

Po zweryfikowaniu rozwiązania można dodawać kolejne źródła, reguły i procesy.

Pierwszy zakres może być niewielki, ale sposób integracji nie powinien blokować takiego rozwoju ani prowadzić do serii niezależnych skryptów i jednorazowych połączeń.

Kiedy integracja ERP ma większy sens niż kolejny ręczny raport?

Nie każdy raport wymaga automatycznego zasilania danymi.

Jeżeli zestawienie powstaje sporadycznie, nie wymaga wielu źródeł i nie wpływa na bieżące decyzje, ręczne przygotowanie może być całkowicie racjonalne.

Integrację warto rozważyć wtedy, gdy:

• te same dane są regularnie pobierane z kilku systemów,
• ręczne przygotowanie informacji opóźnia reakcję,
• błędy lub nieaktualność mają istotne konsekwencje,
• ten sam proces jest wielokrotnie odtwarzany przez różne osoby.

Kluczowe pytanie brzmi:

“Czy wystarczy usprawnić raport, czy trzeba również zautomatyzować pobieranie i przygotowanie danych?”

Integracja nie musi zastępować samego raportu. Może sprawić, że istniejący raport lub dashboard będzie zasilany automatycznie i według spójnych zasad.

Przed rozpoczęciem projektu warto również porównać koszt obecnego procesu z kosztem wdrożenia i utrzymania integracji oraz sprawdzić, czy potrzebnego efektu nie da się osiągnąć przez lepszą konfigurację już używanych systemów.

Czy jeden obraz sytuacji wymaga jednego systemu?

Nie. ERP, system planowania, MES, WMS i inne rozwiązania mogą nadal pełnić swoje wyspecjalizowane role.

Kluczowe jest określenie, za które dane odpowiadają poszczególne systemy, jak informacje są między nimi wymieniane, według jakich reguł powstaje wynik i kiedy można uznać go za wiarygodny.

W takim zastosowaniu integracja ma dostarczać użyteczną informację wcześniej niż obecny proces – bez ręcznego składania jej z kilku miejsc i bez ukrywania sytuacji, w których danych do wiarygodnej oceny po prostu brakuje.

FAQ: integracja ERP i raportowania w firmie produkcyjnej

Czy ERP można zintegrować z Power BI?

Tak. Power BI może korzystać z danych z ERP, interfejsów API, baz danych, hurtowni i innych źródeł. Samo techniczne podłączenie nie zapewnia jednak spójnego raportowania – potrzebne są również jednoznaczne definicje danych, wskaźników i zasad ich aktualizacji.

Czy do integracji ERP potrzebna jest hurtownia danych?

Nie zawsze. Hurtownia jest szczególnie przydatna przy analizie danych historycznych z wielu systemów. W prostszym scenariuszu operacyjnym może wystarczyć bezpośrednia integracja kilku źródeł lub wykorzystanie możliwości już istniejących systemów.

Czy dane z ERP muszą być synchronizowane w czasie rzeczywistym?

Nie. Powinny być dostępne z taką aktualnością, jakiej wymaga dana decyzja i dopuszczalny czas reakcji. Trzeba przy tym pamiętać, że częsta synchronizacja nie zapewni bieżącego obrazu, jeśli same zdarzenia są rejestrowane w systemie źródłowym z opóźnieniem.

Czy trzeba mieć APS i MES, żeby zbudować wspólny widok operacyjny?

Nie. O potrzebnym rozwiązaniu decydują dostępne dane i sposób ich rejestrowania, a nie liczba posiadanych systemów. W jednej firmie większość potrzebnych informacji może znajdować się w ERP, w innej będą pochodzić z kilku wyspecjalizowanych aplikacji.

Czy trzeba wymieniać ERP, żeby zbudować wspólny widok operacyjny?

Zwykle nie. Jeżeli ERP poprawnie realizuje swoją rolę i możliwy jest dostęp do potrzebnych danych, często wystarczy odpowiednio połączyć istniejące źródła i uzupełnić brakujące funkcje.

Jak zintegrować ERP z systemem planowania produkcji?

Najpierw trzeba określić, które informacje mają przepływać między systemami, który z nich odpowiada za ich zmianę i w którą stronę powinna przebiegać synchronizacja. Dopiero później dobiera się mechanizm techniczny i częstotliwość wymiany danych.

Czy można zintegrować starszy ERP, który nie ma nowoczesnego API?

Często tak. Można wykorzystać dostępne interfejsy, pliki wymiany, warstwę pośrednią lub – po analizie ryzyka – kontrolowany odczyt danych z bazy. W starszych systemach szczególnie ważne jest sprawdzenie bezpieczeństwa, stabilności i wpływu integracji na przyszłe aktualizacje.

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.