Pierwszy projekt AI w firmie produkcyjnej: jak wybrać problem do pilotażu

Na odprawie pojawia się pomysł: „Wykorzystajmy sztuczną inteligencję, żeby poprawić produkcję”. Padają przykłady kontroli jakości, przewidywania awarii i automatycznego analizowania raportów. Problem zaczyna się chwilę później. Nie wiadomo, od którego procesu zacząć, jakie dane sprawdzić ani po czym poznać, że pilotaż zakończył się sukcesem. ^[3]

To typowa sytuacja przy planowaniu pierwszego projektu AI w firmie produkcyjnej. Sama technologia nie wybiera dobrego zastosowania. Najpierw trzeba znaleźć problem, który jest wystarczająco ważny, powtarzalny, mierzalny i możliwy do bezpiecznego przetestowania. Dopiero później przychodzi czas na wybór modelu, dostawcy i sposobu integracji.

Zanim wybierzesz technologię, nazwij problem zakładu

Punkt wyjścia: konkretna sytuacja na hali

Pierwszy projekt AI w produkcji nie powinien zaczynać się od pytania: „Jaki system sztucznej inteligencji możemy kupić?”. Lepsze pytanie brzmi: która decyzja w procesie jest dziś zbyt późna, zbyt niedokładna albo zbyt kosztowna?

Hasło „chcemy użyć AI” nie jest jeszcze celem projektu. Nie mówi, co ma się zmienić, kto skorzysta z rozwiązania i jaki wynik będzie uznany za wystarczający. Jest deklaracją zainteresowania technologią, ale nie opisem potrzeby biznesowej.

Dobrze sformułowany problem może wyglądać tak:

• na konkretnej operacji rośnie liczba braków, a przyczyna jest ustalana dopiero po zakończeniu partii,
• określona maszyna zatrzymuje się bez planowanego ostrzeżenia,
• utrzymanie ruchu otrzymuje zbyt wiele alarmów, z których większość nie wymaga natychmiastowej reakcji,
• operatorzy ręcznie przeglądają dużą liczbę zdjęć lub dokumentów,
• decyzja o zwolnieniu partii opiera się na danych rozproszonych w arkuszach, raportach i systemach produkcyjnych,
• technolog długo szuka informacji w instrukcjach, kartach maszyn i historii zmian procesu.

W każdym z tych przypadków AI może być jednym z możliwych narzędzi. Nie zawsze będzie jednak najlepszym rozwiązaniem. Czasami problem wynika z braku instrukcji, niepoprawnego ustawienia czujnika, złej organizacji pracy albo niespójnego procesu rejestrowania danych. ^[2]

Problem biznesowy a rozwiązanie technologiczne

„AI do kontroli jakości” jest nazwą obszaru, a nie opisem pilotażu. Znacznie użyteczniejszy zapis brzmi: „Na jednej operacji operator ręcznie ocenia widoczną wadę elementu. Ocena nie jest zapisywana w jednolity sposób, a część wad jest wykrywana dopiero na końcu linii”.

Taki opis pozwala zadać kolejne pytania: jakie wady są najczęstsze, czy da się je zobaczyć na zdjęciu, kto dziś podejmuje decyzję, ile trwa kontrola, jak często występują pomyłki i co dzieje się z elementem po odrzuceniu.

Podobnie można opisać utrzymanie ruchu. Zamiast „zróbmy predykcyjne utrzymanie maszyn” lepiej zapisać: „Na jednej linii występują nieplanowane postoje związane z określonym podzespołem. Sygnały z maszyny są dostępne, ale nie są wykorzystywane do wcześniejszego ostrzegania zespołu technicznego”.

Pierwszy pilotaż powinien wspierać decyzję człowieka. System może wskazywać element do dodatkowej kontroli, sygnalizować podwyższone ryzyko awarii albo podpowiadać dokument zawierający potrzebną informację. Nie musi od razu sterować maszyną, zatrzymywać linii ani samodzielnie odrzucać produktów.

Dlaczego pierwszy projekt wymaga ograniczonego zakresu

Pilotaż ma sprawdzić kilka rzeczy jednocześnie: sens biznesowy, dostępność danych, jakość predykcji, akceptację użytkowników i możliwość bezpiecznej integracji z istniejącym środowiskiem. Rozszerzenie projektu na cały zakład utrudnia ustalenie, co faktycznie zadziałało. ^[1]

Jeśli system obejmuje kilka linii, różne produkty, wiele zmian i kilka sposobów rejestrowania danych, każdy problem z interpretacją wyniku może mieć inną przyczynę. Trudniej wtedy rozdzielić błędy modelu od błędów procesu, danych lub konfiguracji.

Bezpieczniejszy zakres to:

• jedna linia albo jedno stanowisko,
• jeden typ produktu lub ograniczona grupa podobnych produktów,
• jedna grupa użytkowników,
• jeden proces decyzyjny,
• jedno główne kryterium sukcesu,
• określony czas obserwacji,
• jasna procedura działania w przypadku błędu systemu.

Pilotaż nie jest pełnym wdrożeniem. Jego celem nie musi być natychmiastowa automatyzacja całej produkcji. Pierwsza faza ma dostarczyć dowodów: czy problem da się wykrywać wcześniej, czy użytkownicy potrafią korzystać z wyniku, czy dane są wystarczające i czy potencjalna korzyść uzasadnia dalsze inwestycje.

Pytania, które porządkują rozmowę

Przed zgłoszeniem pomysłu do oceny dobrze przeprowadzić krótką rozmowę z osobami odpowiedzialnymi za proces. Pomagają w niej konkretne pytania:

• Gdzie firma traci czas, materiał, jakość albo dostępność maszyn?
• Które decyzje są dziś podejmowane z opóźnieniem lub na podstawie niepełnych informacji?
• Czy problem występuje wystarczająco często, aby można było ocenić zmianę?
• Kto odczuje poprawę, a kto będzie korzystał z wyniku modelu?
• Jak wygląda reakcja po pojawieniu się ostrzeżenia?
• Co stanie się, jeśli system się pomyli albo przestanie działać?
• Czy problem można zmniejszyć prostą zmianą procesu, bez AI?
• Jak wygląda obecny poziom bazowy, czyli wynik przed pilotażem?

Ostatnie pytanie jest często pomijane. Bez poziomu bazowego nie da się uczciwie ocenić efektu. Jeżeli firma nie wie, ile trwa ręczna kontrola, ile występuje braków albo ile alarmów kończy się interwencją, późniejsza deklaracja poprawy będzie oparta na wrażeniu.

Zbierz pomysły od produkcji, jakości i utrzymania ruchu

Miejsca, w których najłatwiej znaleźć dobry temat

Najlepsze pomysły rzadko powstają wyłącznie w dziale IT. Osoby pracujące z procesem widzą powtarzające się zakłócenia, ręczne obejścia i momenty, w których decyzja przychodzi za późno.

Produkcja może wskazać między innymi:

• powtarzalne zakłócenia na stanowisku,
• oczekiwanie na decyzję jakościową lub technologiczną,
• ręczne zapisywanie tych samych informacji w kilku miejscach,
• przezbrojenia o zmiennym czasie trwania,
• spadki wydajności, których przyczyna jest ustalana dopiero po fakcie,
• czynności wymagające ciągłej obserwacji przez operatora.

Utrzymanie ruchu może zgłosić:

• awarie określonego typu,
• fałszywe lub nadmiarowe alarmy,
• problemy z planowaniem przeglądów,
• trudności w dotarciu do historii napraw,
• sygnały z maszyn, które są rejestrowane, lecz nie są analizowane,
• podzespoły o krótkim czasie reakcji między pierwszym symptomem a awarią.

Jakość często widzi potencjał w obszarach takich jak:

• wykrywanie wad na podstawie obrazu,
• powtarzalność pomiarów,
• analiza reklamacji,
• łączenie parametrów procesu z występowaniem braków,
• automatyczne porządkowanie opisów niezgodności,
• wyszukiwanie podobnych przypadków w historii.

W logistyce wewnętrznej można szukać problemów związanych z opóźnieniami dostaw materiałów na stanowiska, przewidywaniem zapotrzebowania, śledzeniem przepływu pojemników albo lokalizowaniem zasobów.

Dobrym uzupełnieniem tego tematu jest także poradnik: Przemysłowe bezpieczeństwo IT/OT: podstawy ochrony sieci produkcyjnej dla laików.

W biurach związanych z produkcją pojawiają się z kolei zadania polegające na wyszukiwaniu informacji w instrukcjach, raportach, zleceniach, kartach technicznych i dokumentacji zmian. Taki temat może być prostszy niż analiza sygnałów maszyn, ale nadal wymaga sprawdzenia jakości dokumentów, uprawnień i sposobu weryfikowania odpowiedzi.

Krótki warsztat z osobami, które znają proces

Do rozmowy powinien zostać zaproszony operator lub lider zmiany, technolog, przedstawiciel jakości, osoba z utrzymania ruchu oraz reprezentant IT lub OT. Nie chodzi o długie spotkanie strategiczne. Celem jest odtworzenie jednego przebiegu procesu.

Najpierw trzeba ustalić, co dzieje się przed problemem. Następnie: jak problem jest wykrywany, kto go potwierdza, jaka decyzja zapada i jakie są jej skutki. Taki przebieg można zapisać w kilku krokach:

1. pojawia się sygnał lub sytuacja związana z odchyleniem,
2. operator albo system zauważa problem,
3. informacja trafia do konkretnej osoby,
4. podejmowana jest decyzja,
5. proces jest kontynuowany, korygowany albo zatrzymywany,
6. wynik działania jest lub nie jest rejestrowany.

Ważne jest oddzielenie objawu od przyczyny. Zdanie „maszyna często stoi” może oznaczać awarie, brak materiału, długie przezbrojenia, oczekiwanie na kontrolę, problemy z planowaniem albo nieprawidłowe ustawienie parametrów.

Podczas warsztatu trzeba zebrać istniejące obejścia: arkusze, prywatne notatki, zdjęcia, alarmy, ręczne reguły i listy kontrolne. Często to właśnie one pokazują, jakie dane są naprawdę używane, a nie tylko jakie dane powinny być używane według dokumentacji.

Jak opisać kandydatów bez technicznego języka

Każdy pomysł można zapisać na jednej stronie. Taki opis powinien zawierać:

• proces i stanowisko — gdzie występuje problem,
• zdarzenie — co dokładnie się dzieje,
• skutek — wpływ na bezpieczeństwo, jakość, koszt, czas lub dostępność,
• obecne wykrywanie — kto i kiedy zauważa problem,
• obecną reakcję — co dzieje się po wykryciu,
• użytkownika wyniku — kto miałby otrzymać informację,
• oczekiwaną zmianę — wcześniejsze ostrzeżenie, szybsza kontrola, mniej ręcznych przeglądów albo lepsze ustalanie przyczyny,
• ryzyko błędu — co będzie skutkiem fałszywego alarmu lub przeoczenia.

Nie trzeba na tym etapie pisać o sieciach neuronowych, uczeniu nadzorowanym ani architekturze chmurowej. Te decyzje zależą od charakteru problemu i danych. Najpierw trzeba upewnić się, że temat jest zrozumiały dla osób, które ponoszą odpowiedzialność za proces.

Przykład: od hasła do tematu pilotażowego

Zamiast hasła „AI do kontroli jakości” powstaje temat: „Na jednej operacji operator ręcznie ocenia, czy element ma widoczną wadę. Wynik kontroli jest zapisywany niejednolicie, a decyzja o odrzuceniu bywa opóźniona”.

Ten opis pozwala sprawdzić, czy dostępne są zdjęcia, czy kryteria oceny są jednoznaczne, czy oświetlenie jest powtarzalne i czy istnieje osoba odpowiedzialna za reakcję na wskazanie systemu.

Oceń, który problem naprawdę nadaje się do pilotażu AI

Zebrane pomysły trzeba teraz porównać według tych samych kryteriów. Sam fakt, że problem jest uciążliwy, nie oznacza jeszcze, że warto rozwiązywać go za pomocą AI. Dobry kandydat do pilotażu łączy znaczenie biznesowe z możliwością bezpiecznego sprawdzenia rozwiązania w rzeczywistym procesie.

Porównaj kandydatów według wspólnych kryteriów

Najprościej przygotować krótką kartę oceny dla każdego problemu. Nie chodzi o pozorną precyzję, lecz o wymuszenie porównywalnej rozmowy między produkcją, jakością, utrzymaniem ruchu i IT.

Każde kryterium można ocenić na prostej skali, na przykład od niskiego do wysokiego poziomu spełnienia. Warto również zaznaczyć, które oceny są oparte na danych, a które wynikają tylko z opinii zespołu. Kandydat może wyglądać atrakcyjnie na spotkaniu, ale stracić priorytet po sprawdzeniu, że zdarzenia występują zbyt rzadko albo nie są jednolicie rejestrowane.

Sprawdź poziom bazowy przed uruchomieniem testu

Każdy pilotaż powinien mieć opisany poziom bazowy. To punkt odniesienia pokazujący, jak proces działa bez nowego rozwiązania. W zależności od problemu może nim być:

• odsetek elementów wymagających ponownej kontroli,
• liczba braków przypadających na określoną liczbę wyprodukowanych sztuk,
• czas ręcznej oceny jednego elementu,
• liczba nieplanowanych zatrzymań i ich łączny czas,
• czas od pojawienia się sygnału do reakcji technika,
• liczba alarmów kończących się rzeczywistą interwencją,
• czas potrzebny na znalezienie właściwej instrukcji lub informacji w dokumentacji.

Pomiar nie musi być skomplikowany. Ważne, aby dotyczył tego samego procesu, który ma wspierać system. Jeżeli pilot ma pomagać w szybszym wykrywaniu wad, sam czas działania aplikacji nie wystarczy jako główna miara sukcesu. Trzeba sprawdzić również, czy wada została wykryta wcześniej, czy decyzja była trafna i czy zmniejszyła się liczba elementów przekazywanych do dalszej obróbki.

Przydatne jest ustalenie kilku poziomów wyniku:

• miara operacyjna — na przykład czas kontroli lub czas reakcji,
• miara jakości decyzji — na przykład liczba przeoczeń i fałszywych wskazań,
• miara biznesowa — na przykład ograniczenie braków, przestojów albo pracy dodatkowej,
• miara użytkowa — na przykład odsetek wskazań, z których operator faktycznie skorzystał.

Ustal, czy AI jest właściwym rozwiązaniem

Nie każdy problem wymaga modelu AI. Czasem źródłem trudności jest brak jednej instrukcji, nieaktualna lista parametrów, niespójny sposób wpisywania danych albo brak odpowiedzialności za reakcję. W takim przypadku wdrożenie AI może tylko przykryć problem organizacyjny.

Przed nadaniem projektowi priorytetu warto zadać trzy pytania:

1. Czy prostą zmianą procedury można osiągnąć podobny efekt?
2. Czy reguła oparta na jasno określonym progu lub warunku rozwiąże problem?
3. Czy główną przeszkodą jest skala, zmienność albo złożoność informacji, z którą człowiek nie radzi sobie wystarczająco szybko?

AI ma większe uzasadnienie wtedy, gdy trzeba analizować wiele obrazów, sygnałów lub dokumentów, wykrywać trudne do zapisania wzorce albo łączyć informacje z różnych źródeł. Jeżeli wystarczy ujednolicić formularz kontroli lub poprawić przekazywanie alarmów, prostsze rozwiązanie będzie zwykle szybsze, tańsze i łatwiejsze do utrzymania.

Dobrym uzupełnieniem tego tematu jest także poradnik: Jak przygotować pracowników do pracy z robotami i systemami AI w zakładzie.

Przykładowo, jeśli operatorzy nie wpisują jednolitych przyczyn postoju, model analizujący historię awarii będzie pracował na nieporównywalnych opisach. Najpierw trzeba uporządkować sposób rejestracji. Dopiero później można sprawdzać, czy analiza danych pozwoli wcześniej rozpoznać ryzyko zatrzymania.

Oceń dane razem z ich pochodzeniem

Sama obecność danych nie oznacza, że nadają się one do pilotażu. Trzeba sprawdzić, czego dotyczą, kto je wprowadza, z jaką częstotliwością powstają i czy można ustalić ich związek z konkretnym zdarzeniem.

W przypadku kontroli wizualnej należy ustalić między innymi:

• czy zdjęcia obejmują zarówno poprawne, jak i wadliwe elementy,
• czy opis wady jest jednoznaczny,
• czy obrazy pochodzą z podobnych warunków oświetlenia i ustawienia kamery,
• czy wiadomo, jaka decyzja została ostatecznie podjęta,
• czy przypadki graniczne były rozstrzygane przez doświadczoną osobę,
• czy w danych nie brakuje całych zmian, produktów albo okresów pracy.

W utrzymaniu ruchu trzeba natomiast połączyć sygnały z maszyny z rzeczywistymi zdarzeniami: awarią, interwencją, wymianą podzespołu lub zatrzymaniem linii. Sam alarm nie jest jeszcze potwierdzeniem usterki. Jeśli system ma przewidywać awarię, należy wiedzieć, kiedy awaria faktycznie wystąpiła oraz ile czasu wcześniej pojawiły się symptomy.

Na tym etapie warto wybrać niewielką próbkę danych i prześledzić ją ręcznie. Taki przegląd często ujawnia niejednoznaczne oznaczenia, przerwy w rejestracji, duplikaty albo informacje zapisane poza oficjalnym systemem. Lepiej wykryć te ograniczenia przed rozpoczęciem budowy pilotażu niż po otrzymaniu pierwszych wyników.

Uwzględnij koszt błędnej podpowiedzi

System wspierający decyzję człowieka również może powodować skutki operacyjne. Fałszywy alarm może skierować technika do sprawnej maszyny, wydłużyć kontrolę albo zwiększyć liczbę zatrzymywanych elementów. Przeoczenie może z kolei dopuścić wadliwy produkt do kolejnego etapu lub opóźnić reakcję na pogarszający się stan urządzenia.

Dlatego przy każdym kandydacie trzeba opisać co najmniej dwa rodzaje błędu:

• fałszywe wskazanie — system sygnalizuje problem, którego nie ma,
• przeoczenie — system nie wskazuje problemu, który rzeczywiście wystąpił.

Znaczenie obu błędów zależy od procesu. W kontroli jakości ważne może być ograniczenie przeoczeń, ale zbyt duża liczba fałszywych wskazań także obniży zaufanie operatorów. W utrzymaniu ruchu nieuzasadnione wezwania technika mogą być mniej groźne niż brak ostrzeżenia przed awarią, jednak system nie powinien samodzielnie uruchamiać ryzykownej reakcji bez określonej procedury.

Bezpieczny pilotaż powinien mieć ustalony tryb awaryjny. Gdy wynik jest niepewny, użytkownik wraca do obecnej metody oceny. Gdy aplikacja jest niedostępna, proces nie może zostać bez instrukcji. Taka zasada powinna być uzgodniona z osobami pracującymi na zmianie, a nie dopiero dopisana w dokumentacji projektu.

Przykład porównania dwóch kandydatów

Załóżmy, że zakład rozważa dwa tematy. Pierwszy dotyczy wskazywania elementów wymagających dodatkowej kontroli wizualnej. Drugi ma przewidywać awarie podzespołu na jednej z linii.

Pierwszy temat może mieć dobrze określony użytkownik wyniku, regularne zdarzenia i prostą reakcję: operator odkłada element do dodatkowej oceny. Jeżeli zdjęcia są dostępne, a kryteria wady można ujednolicić, pilotaż da się prowadzić bez automatycznego odrzucania produktów.

Drugi temat może mieć większą potencjalną wartość, ale również większą niepewność. Jeżeli awarie występują rzadko, historia napraw jest niepełna, a technik nie ma określonego czasu na reakcję, trudno będzie potwierdzić skuteczność rozwiązania. W takim przypadku rozsądniejszym pierwszym krokiem może być uporządkowanie rejestracji zdarzeń i przygotowanie monitoringu sygnałów, zamiast od razu budować system predykcyjny.

Nie oznacza to, że temat utrzymania ruchu należy odrzucić. Może po prostu wymagać wcześniejszego etapu przygotowawczego. Do pierwszego pilotażu warto wybrać ten problem, przy którym szybciej można uzyskać wiarygodny wynik i bezpiecznie sprawdzić sposób pracy użytkowników.

Ustal warunki przejścia do pilotażu

Na końcu oceny należy zapisać decyzję oraz jej uzasadnienie. Wybrany temat powinien mieć:

• konkretny proces i ograniczony zakres testu,
• jednoznacznie wskazanego użytkownika wyniku,
• opis obecnego sposobu pracy,
• poziom bazowy i sposób jego pomiaru,
• potwierdzone źródła danych albo jasno opisane braki,
• ustaloną reakcję na wskazanie systemu,
• kryterium sukcesu oraz warunek zakończenia testu,
• procedurę działania przy błędzie lub niedostępności rozwiązania.

Jeżeli któregoś z tych elementów brakuje, nie trzeba od razu rezygnować z pomysłu. Należy jednak nazwać brakujące przygotowanie. Może nim być uporządkowanie etykiet jakościowych, rozpoczęcie regularnego pomiaru czasu kontroli, uzupełnienie historii awarii albo uzgodnienie, kto podejmuje decyzję po otrzymaniu ostrzeżenia.

W ten sposób wybór pierwszego projektu AI przestaje być konkursem na najbardziej efektowny pomysł. Staje się decyzją o tym, który problem zakładu można zmierzyć, bezpiecznie przetestować i przełożyć na działanie konkretnego zespołu. Dopiero po takim wyborze warto przejść do określenia danych, sposobu budowy rozwiązania i planu pilotażu.

Źródła

• [1] McKinsey & Company – How advanced industrial companies should approach artificial-intelligence strategy ↑
• [2] McKinsey & Company – Revolutionizing semiconductor fab operations with AI ↑
• [3] NIST – The Rise of Artificial Intelligence (AI) in U.S. Manufacturing Text Only ↑