Gdzie naprawdę leży problem: nie w technologii, tylko w organizacji
Dlaczego projekty AI upadają po „sukcesie” PoC
W większości zakładów przemysłowych projekty AI nie upadają dlatego, że modele są kiepskie. Upadają dużo później – wtedy, gdy te modele trzeba wpiąć w prawdziwą produkcję, z jej awaryjnością, zmianami, ludźmi i procedurami. Proof of concept na historycznych danych zwykle da się „dowiezć”. Prawdziwa walka zaczyna się przy wdrożeniu w trybie 24/7, gdy trzeba zapewnić stabilne dane, integrację z automatyką, reakcje ludzi i utrzymanie rozwiązania w czasie.
Typowy scenariusz wygląda tak: prezentacja PoC pokazuje ładne wykresy, wysoką trafność modelu i kilka przykładowych przypadków, w których AI „zgadła” awarię czy wadę produktu. Zarząd jest zadowolony, vendor też. Po kilku miesiącach od wdrożenia nikt już nie pamięta, gdzie jest panel z rekomendacjami, a inżynierowie procesów częściej zaglądają do Excela niż do systemu AI. Oficjalnie projekt „poszedł”, nieoficjalnie – nikt na nim nie pracuje.
To nie jest wina samej technologii. To efekt tego, że PoC był robiony jak eksperyment w laboratorium, a nie jak pierwszy krok zmiany organizacyjnej. Model AI może działać poprawnie, a mimo to nie wnosić żadnej wartości, jeśli nie jest zakotwiczony w decyzjach, odpowiedzialności i codziennej pracy ludzi na hali. Sukces technologiczny bez sukcesu organizacyjnego jest w przemyśle równoznaczny z porażką.
Mit „brakuje nam tylko dobrego algorytmu” kontra realne braki
W wielu fabrykach funkcjonuje przekonanie, że do sukcesu w AI brakuje „tylko” dobrego algorytmu albo właściwego dostawcy. To mit. Algorytmy, biblioteki i narzędzia są względnie łatwo dostępne, a różnice między nimi rzadko decydują o tym, czy projekt przetrwa. Rzeczywiste braki leżą w czterech innych obszarach: procesie, danych, decyzjach i odpowiedzialności.
Proces: brak jest ustalonego sposobu pracy z projektem – kto co robi, w jakiej kolejności, jakie są kryteria wejścia i wyjścia. Dane: sygnały z maszyn są niespójne, część jest na papierze, część w SCADA, część w MES, a etykiety (np. informacja, czy partia była wadliwa) pojawiają się z opóźnieniem lub są niekompletne. Decyzje: nie wiadomo dokładnie, kto ma reagować na sygnał od AI, w jakim czasie i jaką akcją. Odpowiedzialność: nikt nie jest rozliczany z efektu projektu, więc naturalnie schodzi on na dalszy plan.
Rzeczywistość jest taka, że nawet średni model, ale oparty na sensownym procesie, dobrych danych i jasnym łańcuchu decyzji, da więcej wartości niż wyrafinowany algorytm, który żyje obok realnego procesu produkcyjnego. Bez uporządkowania organizacji, najlepszy zespół data scientistów będzie przypominał mechanika próbującego naprawić auto, którego właściciel nie chce oddać na przegląd i nie zamierza wymieniać oleju.
Fabryka jako zbiór silosów – i co to robi projektom AI
Produkcja, jakość, utrzymanie ruchu, logistyka, BHP, IT, automatyka/OT – każdy z tych działów ma własne priorytety, wskaźniki, język i szefów. Dla produkcji kluczowe jest, żeby linia jechała, dla utrzymania – żeby maszyny się nie psuły, dla jakości – żeby nie było reklamacji, dla BHP – żeby było bezpiecznie, dla IT – żeby systemy były stabilne i bezpieczne. AI w fabryce dotyka wszystkich naraz, ale najczęściej nie ma wspólnego „parasola” i jednego języka, w którym można rozmawiać o celach i kompromisach.
W efekcie projekt AI wchodzi w środek takiego układu. Dla produkcji to często dodatkowa komplikacja („znów coś chcą, a my mamy target”), dla utrzymania – potencjalne ryzyko („kto będzie odpowiadał, jeśli AI każe zatrzymać linię?”), dla IT – kłopot bezpieczeństwa i integracji, dla jakości – obietnica, ale bez gwarancji, że system będzie miał wpływ na decyzje. Brak wspólnego języka powoduje, że każdy patrzy na AI przez swój wąski filtr, zamiast traktować je jako narzędzie do wspólnego celu biznesowego.
Przykład: projekt predykcji awarii wymaga danych z PLC, historii alarmów ze SCADA, danych o naprawach z CMMS, a także informacji, jak awarie wpływają na OEE i jakość. Jeżeli te dane „należą” do trzech różnych działów, a każdy ma inny sposób ich rejestracji, to już na starcie projekt tonie w uzgodnieniach. Bez celowo zbudowanego, międzydziałowego zespołu i sponsora, który spina te silosy, nie ma szans na stabilne wdrożenie.
Dlaczego zarząd „kupuje projekt AI”, a produkcja „dostaje kłopot”
Z perspektywy zarządu projekty AI w fabryce często wyglądają jak inwestycja strategiczna: poprawa OEE, redukcja scrapu, mniej awarii, lepsza kontrola energii. Z perspektywy hali produkcyjnej to bywa kolejny system, kolejny ekran, kolejne raporty i kolejny zestaw oczekiwań. Jeśli nie ma jasnego przełożenia na codzienną pracę operatorów i mistrzów, pojawia się opór pasywny: „przejdziemy na to, jak będzie gotowe i sprawdzone”, co oznacza w praktyce „najpierw niech ktoś udowodni, że warto, a póki co robimy po staremu”.
Problem jest strukturalny: decyzja o starcie projektu często zapada wysoko, ale wdrożenie dotyka najniższego poziomu organizacji. Brakuje średniego szczebla (kierowników produkcji, liderów zmian, głównych technologów), który jest włączony od początku, współtworzy rozwiązanie i bierze odpowiedzialność za jego wykorzystanie. Bez tego AI staje się „produktem działu innowacji” albo „projektem centrali”, który trzeba jakoś przetrwać, a nie narzędziem do ułatwienia pracy.
Jeżeli zarząd nie zdefiniuje od razu właściciela biznesowego po stronie operacji i nie przekaże mu mandatu oraz zasobów, projekt od początku ma mniejsze szanse. AI w fabryce nie może być tylko zakupem technologii; musi być świadomie zaprojektowaną zmianą sposobu pracy zespołów.
AI jako projekt organizacyjny – konsekwencje dla składu zespołu
Traktowanie AI wyłącznie jako projektu technicznego prowadzi do prostego schematu: przetarg, vendor, instalacja, szkolenie, raport końcowy. W świecie produkcji to za mało. AI zmienia sposób podejmowania decyzji – kto, kiedy i na podstawie jakiego sygnału reaguje. To ingerencja w procedury, role, odpowiedzialności, grafiki pracy, a czasem w system premiowania. To jest czysta materia organizacyjna, a nie tylko techniczna.
Konsekwencja jest oczywista: zespół projektowy nie może składać się wyłącznie z IT, data scientistów i dostawcy. Potrzebny jest właściciel procesu (np. kierownik produkcji na konkretnej linii), technolog lub inżynier procesu, przedstawiciel utrzymania ruchu, ktoś z automatyki/OT, przedstawiciel operatorów oraz osoba odpowiedzialna za change management. Dopiero taka mieszanka powoduje, że rozwiązanie jest dopasowane do realiów hali, a nie tylko do slajdów prezentacyjnych.
Bez zrozumienia, że AI to projekt organizacyjny, organizacja próbuje „wtłoczyć” nowy sposób pracy w stare ramy. To kończy się tym, że system jest, ale decyzje i tak zapadają po staremu: „bo tak robił zawsze Marek z nocnej zmiany i działa”.
Typowa trajektoria upadku projektu AI w fabryce – krok po kroku
Jak to zwykle startuje: entuzjazm, vendor i szeroki „use case”
Początek jest niemal wszędzie podobny. Pojawia się inspiracja: konferencja, case study z innej fabryki, naciski centrali, prezentacja dostawcy. Ktoś rzuca hasło: „Musimy coś zrobić z AI, bo konkurencja już to ma”. Do gry wchodzi vendor z gotową ofertą: platforma AI, moduły do predykcji awarii, optymalizacji zużycia energii czy kontroli jakości wizyjnej. Projekt dostaje zielone światło.
Use case zazwyczaj pozostaje bardzo ogólny: „optymalizacja produkcji”, „predykcyjne utrzymanie ruchu”, „redukcja scrapu”. Brakuje jednoznacznego określenia, jakie konkretne wskaźniki mają się zmienić i w jakiej skali. Nikt nie precyzuje, czy chodzi o zmniejszenie scrapu o kilka punktów procentowych na jednej linii, czy o globalną transformację wszystkich zakładów.
Entuzjazm jest duży, bo AI brzmi atrakcyjnie. Ale brak precyzyjnego zdefiniowania problemu powoduje, że zespół – jeśli w ogóle został powołany – nie ma jasnych kryteriów sukcesu. W takiej sytuacji każde demo wygląda nieźle, ale jednocześnie prawie nic nie może być jednoznacznie uznane za porażkę lub sukces.
PoC w oderwaniu od infrastruktury i pracy operatorów
Kolejny krok to proof of concept. Najczęściej odbywa się na wycinku danych historycznych, czasem na jednej maszynie lub linii. Vendor prosi o dane, IT i automatyka pomagają je wyciągnąć, data scientist buduje pierwsze modele. Po kilku tygodniach powstają wykresy, raporty, czasem proste dashboardy. Model „przewiduje” awarie z pewnym wyprzedzeniem albo identyfikuje wzorce związane ze scrapem.
Problem w tym, że PoC jest często projektowany tak, żeby było „łatwiej technicznie”, a nie „bliżej realnej pracy”. Dane są ręcznie czyszczone i łączone, pewne brakujące informacje są uzupełniane przez inżynierów, zakłada się idealne warunki zasilania modelu. Operatorzy albo nie uczestniczą w pracach, albo są proszeni jedynie o „potwierdzenie sensowności” kilku przypadków.
W efekcie powstaje rozwiązanie, które działa na sterylnym zbiorze danych, ale nie ma jeszcze nic wspólnego z codzienną rzeczywistością: z przerwami w zasilaniu, ręcznymi poprawkami operatorów, zmianami w konfiguracji linii czy „obejściami” stosowanymi, gdy system źle raportuje. To klasyczny przykład: na PoC wszystko wygląda obiecująco, a potem zaczyna się zderzenie z infrastrukturą i ludźmi.
„Sukces” na slajdach zamiast realnego wpływu na wskaźniki
PoC kończy się prezentacją wyników. Pokazuje się wskaźniki typu accuracy, ROC AUC, wykresy wskazujące, że model rozróżnia klasy (np. awaria / brak awarii, dobra sztuka / wada) z sensowną skutecznością. Często padają zdania: „Model trafnie wskazał 8 na 10 awarii” albo „Udało się odtworzyć 70% przypadków scrapu na podstawie parametrów procesu”. Na slajdach wygląda to dobrze.
Jednak niewiele mówi to kierownictwu produkcji i utrzymania ruchu. Oni myślą w kategoriach: „ile godzin przestojów mniej?”, „ile ton złomu mniej?”, „ile mniej reklamacji?”. Jeżeli w prezentacji nie ma przełożenia jakości modelu na biznes (np. symulacji, jak wyglądałby ostatni kwartał, gdyby model działał i ekipa reagowała), to pojawia się wrażenie, że to ciekawy eksperyment, ale niekoniecznie przełom.
Mit polega na tym, że „dobry wynik na slajdach” wystarczy, by projekt naturalnie przeszedł w fazę wdrożenia. Rzeczywistość jest inna: bez biznesowego „aha!” nikt nie ma interesu, by przepychać trudną część, czyli integrację i zmianę sposobu pracy. Po kilku tygodniach lub miesiącach slajdy trafiają do archiwum, a temat traci priorytet.
Cichy rozjazd: ani do kosza, ani do skalowania
Po PoC rzadko kiedy ktoś staje i mówi: „To nie ma sensu, przerywamy”. Zamiast tego projekt przechodzi w miękki stan zawieszenia. Ktoś deklaruje, że „wrócimy do tego w kolejnym kwartale”, że „trzeba dopracować dane”, że „czekamy na decyzję centrali”. Formalnie projekt żyje, realnie nic się nie dzieje.
Czasem następują próby pilotażowego wdrożenia, ale bez odpowiednio przygotowanych procesów. System działa w trybie „obserwuj i ucz się”, operatorzy mają „sprawdzać” rekomendacje, ale nikt nie wiąże tego z ich odpowiedzialnością ani z wynikami. Po kilku miesiącach pojawia się opinia: „System czasem coś pokazuje, czasem nie, ale jakoś się bez tego obywaliśmy”. To naturalna reakcja organizmu, który nie widzi zacisku między nowym narzędziem a swoją pracą.
Końcowy efekt jest zawsze podobny: projekt AI nigdzie oficjalnie nie umiera, ale też nie dojrzewa do skali. Kolejne inicjatywy ruszają od nowa, często powtarzając te same błędy. W głowach decydentów powstaje przekonanie: „AI to fajna rzecz na prezentacje, ale z tym jest za dużo zamieszania na produkcji”. To bezpośrednio zabija kolejne inicjatywy.
Najczęstsze mity o AI w fabryce, które psują projekty już na starcie
Mit: „Najpierw idealny data lake, potem AI”
Popularna narracja brzmi tak: „Zanim zaczniemy z AI, musimy mieć idealnie uporządkowane dane, data lake, standardy, globalną architekturę”. Brzmi rozsądnie, ale w praktyce często prowadzi do wieloletnich programów infrastrukturalnych, w których AI jest wiecznie „w następnym etapie”. Tymczasem produkcja żyje codziennymi problemami, których nie rozwiązuje ani data lake, ani slajdy architektoniczne.
Rzeczywistość jest taka, że większość udanych wdrożeń AI w fabrykach zaczyna się od konkretnego problemu i rozsądnego zakresu danych, a nie od globalnej „magazynowni wszystkiego”. Projekt predykcji awarii może ruszyć na danych z jednej linii i kilku systemów, zamiast czekać na idealną centralizację całej korporacji. Oczywiście, trzeba mieć pomysł, jak później skalować rozwiązanie, ale nie oznacza to paraliżu na starcie.
Mit: „Jak zrobimy PoC na jednej linii, to potem już tylko klikać ‘deploy’ wszędzie”
Obietnica jest kusząca: „Najpierw zróbmy PoC tu, a potem tylko sklonujemy rozwiązanie na kolejne zakłady”. Problem w tym, że nawet w ramach jednej fabryki dwie pozornie identyczne linie potrafią różnić się drobnymi szczegółami: inną wersją sterownika, innymi nawykami operatorów, lokalnymi obejściami błędów. To wszystko wpływa na dane i działanie modelu.
Mit polega na traktowaniu PoC-u jak produktu, który da się po prostu przekopiować. Rzeczywistość: PoC jest eksperymentem w konkretnym ekosystemie techniczno-organizacyjnym. Skalowanie wymaga ponownego przejścia przez część kroków: weryfikacji jakości danych, dopasowania interfejsu do sposobu pracy, szkolenia lokalnej kadry. Inaczej kończy się na tym, że w jednej fabryce AI „działa”, a w trzech kolejnych jest „wyłączone, bo przeszkadza”.
Zdrowe podejście jest odwrotne: PoC projektowany jest od razu z myślą o skalowaniu. Nie chodzi o to, żeby od razu implementować globalną architekturę, tylko tak prowadzić prace, by można było jasno odpowiedzieć na pytanie: co z tego da się powtórzyć, a co jest specyficzne dla tej linii i tego zakładu?
Mit: „AI samo znajdzie problem, my tylko damy dane”
Część organizacji ulega wrażeniu, że wystarczy „zebrać dużo danych”, a algorytmy same wykryją, co wpływa na scrap, awarie czy opóźnienia. Brzmi to jak opowieść o magicznej kuli: wgrywamy dane, klikamy „analyze”, system wyrzuca gotowe recepty.
W realnej fabryce bez hipotezy procesowej otrzymuje się głównie korelacje, które niewiele mówią operacjom. Tak, model może wykryć, że scrap rośnie częściej na nocnej zmianie albo gdy zmienia się konkretne ustawienie. Bez kontekstu procesu to ciekawostka, a nie podstawa decyzji. Potrzebny jest inżynier procesu, który powie: „To może mieć sens, bo na nocnej mamy inny harmonogram czyszczeń” albo „Ta korelacja jest fałszywa, bo w tym okresie wymienialiśmy matryce”.
Mit: AI zastąpi rozumowanie technologów. Rzeczywistość: dobre AI przyspiesza ich pracę, ale nie wykonuje jej za nich. Jeżeli projekt startuje bez hipotezy „co może być nie tak z procesem”, to kończy się tabelą ciekawych wykresów i brakiem decyzji.
Mit: „Operatorzy się przyzwyczają, jak zobaczą, że działa”
Często pada zdanie: „Na razie nie angażujmy za bardzo operatorów, bo ich to zablokuje, pokażmy im gotowe rozwiązanie – jak zobaczą efekt, to się przekonają”. W teorii brzmi to jak ochrona ludzi przed „zamieszaniem”. W praktyce prowadzi do otwartego oporu lub cichego sabotowania systemu.
Operatorzy są przyzwyczajeni do konkretnych procedur, skrótów i trików, które przez lata pomagały im robić swoją robotę. Jeżeli nowy system bez uprzedzenia zaczyna im „mówić, co mają robić”, a do tego jest projektowany bez ich udziału, to pierwszą reakcją jest obrona dotychczasowego sposobu pracy. Pojawia się narracja: „To zabiera kontrolę”, „System nie zna życia”, „Znów wymysł z biura”.
Rzeczywistość jest odwrotna: im wcześniej operatorzy są włączeni – choćby po to, żeby nazwać problemy i opisać typowe scenariusze – tym łatwiej potem akceptują zmianę. W dodatku zapobiega to projektowaniu interfejsu i alarmów „dla slajdów”, a nie dla realnego stanowiska pracy.
Co musi być ustalone przed startem: problem, właściciel, decyzje
Precyzyjne zdefiniowanie problemu biznesowego
Najczęstsza przyczyna rozjazdu to nie „słaby model”, tylko rozmyty cel. Sformułowanie typu „chcemy poprawić OEE” jest zbyt ogólne. AI nie jest lekarstwem na wszystkie wskaźniki naraz. Trzeba wybrać konkretny ból, który organizacja rzeczywiście czuje.
Dobry problem startowy ma kilka cech: jest zawężony (np. „redukcja scrapu na linii X dla produktu Y”), jest mierzalny (wiadomo, jak jest teraz i co byłoby poprawą) oraz ma jasny horyzont czasowy („oceniamy efekt po trzech miesiącach pracy modelu”). Bez tego każdy wynik można będzie zinterpretować na wiele sposobów – idealne środowisko dla polityki, ale nie dla decyzji.
Mit: im szerzej zdefiniujemy cel, tym większy efekt. Rzeczywistość: im szerzej, tym bardziej projekt jest „niczyj” i tym trudniej komukolwiek odpowiadać za efekt.
Jeden właściciel biznesowy po stronie operacji
Drugim elementem jest jasny właściciel biznesowy – po stronie produkcji, utrzymania ruchu lub logistyki, w zależności od problemu. Nie sponsor z centrali, nie „komitet sterujący”, tylko konkretna osoba, która na co dzień żyje tym wskaźnikiem i ma wpływ na organizację pracy.
W praktyce jest to często kierownik obszaru, szef utrzymania ruchu lub lider linii. Jego rola to nie tylko „podpisywać dokumenty”, ale realnie uczestniczyć w definiowaniu wymagań, akceptacji zakresu i potem w decyzji: czy zmieniamy sposób pracy według wskazań systemu. Bez takiej osoby projekt AI natychmiast zamienia się w spór między IT, vendorami i centralą, a produkcja zachowuje komfortową pozycję obserwatora.
Właściciel biznesowy musi też wiedzieć, że to jest jego projekt, a nie tylko „coś zrzucone z góry”. Dlatego deklaracja zarządu powinna być jednoznaczna: ten człowiek dostaje mandat i czas na udział w projekcie, a nie „ma się tym zająć po godzinach” i jednocześnie dowozić wszystkie bieżące targety jak wcześniej.
Decyzje, które będą podejmowane na podstawie AI
Nawet dobrze zdefiniowany problem i właściciel nie wystarczą, jeśli nie ma jasności, jakie konkretne decyzje mają się zmienić dzięki AI. System może przewidywać awarie z wyprzedzeniem, ale ktoś musi zdecydować: kto reaguje, w jakim czasie, czy wolno zatrzymać linię, jak to raportować. Bez tego model jest tylko dodatkowym ekranem z wykresem.
Najpraktyczniej zacząć od prostego katalogu decyzji: co dziś robimy manualnie, co chcemy robić inaczej na podstawie AI, a czego na razie nie ruszamy. Przykład: „Gdy model sygnalizuje wysokie ryzyko awarii łożyska w ciągu 8 godzin, lider zmiany ma prawo przeplanować krótką przerwę serwisową bez pytania wyżej”. Taki zapis jest bardziej wart niż 20 slajdów z architekturą.
Mit: decyzje „wykrystalizują się” same, gdy rozwiązanie będzie gotowe. Rzeczywistość: jeśli nie ustali się ich na początku, system zostanie w trybie „do obserwacji”, a ludzie będą go ignorować, bo nikt nie powiązał go z realną odpowiedzialnością.
Minimalna mapa zmian w procesach i KPI
AI w fabryce dotyka nie tylko jednego wskaźnika, ale też sposobu jego rozliczania. Przykładowo, jeśli system ma sugerować korekty parametrów procesu, to trzeba zdecydować: czy zmieniamy zasady odpowiedzialności za scrap, jak dokumentujemy decyzje oraz jak liczymy efekty – z rozbiciem na zmiany, produkty, rodzaje przyczyn.
Przed startem projektu dobrze jest narysować prostą mapę: które procedury dotknie system, jakie raporty trzeba będzie zmodyfikować, które KPI będą używane do oceny efektu. Nie musi to być 100-stronicowa instrukcja, wystarczy czytelny „szkic” uzgodniony z produkcją, utrzymaniem ruchu, jakością i finansami. Bez tego po pierwszych miesiącach zaczynają się spory: „Czy to poprawa dzięki AI, czy tylko sezonowość?” albo „Czy te dodatkowe postoje to koszt projektu, czy inwestycja w stabilność?”.
Z czego naprawdę składa się skuteczny zespół AI w fabryce
Rdzeń zespołu: technologia + proces + zmiana
Skuteczny zespół AI w fabryce nie jest zlepkiem przypadkowych ludzi, którzy „mają trochę czasu”. To świadomie zbudowana struktura, w której łączą się trzy perspektywy: technologiczna, procesowa i organizacyjna. Brak którejkolwiek z nich prowadzi do typowych patologii: technologicznego gadżetu, ignorowanego na hali, albo ręcznych obejść, które niszczą jakość danych.
Praktycznie oznacza to, że w każdym projekcie powinny być co najmniej trzy „filary”: osoba odpowiedzialna za dane i modele (data/ML), osoba znająca proces (technolog, inżynier procesu) oraz ktoś, kto potrafi przełożyć to na zmianę pracy ludzi (change management, lider transformacji). Dopiero wokół tego można dobierać pozostałych specjalistów.
Data/ML: ktoś, kto rozumie i dane, i ograniczenia hali
Rola „data scientist” w fabryce różni się od pracy w e-commerce czy finansach. Tu nie wystarczy znajomość algorytmów – trzeba rozumieć, jak powstają dane na linii, jakie są typowe źródła szumu, co oznaczają przestoje, ręczne wpisy czy brakujące wartości. Bez minimalnej orientacji w automatyce i systemach OT łatwo zbudować model, który nie ma szans działać w trybie on-line.
Kluczowe jest, by osoba odpowiedzialna za model potrafiła rozmawiać z automatykami i technologami ich językiem, a nie tylko żądać „więcej danych”. Dobre pytania bywają cenniejsze niż kolejne gigabajty logów: „Co oznacza ta flaga w PLC?”, „Czy to jest realny odczyt, czy domyślna wartość po restarcie?”, „Jak często operator nadpisuje ten parametr?”.
Inżynier procesu / technolog: tłumacz między danymi a rzeczywistością
Bez mocnego technologicznego partnera projekt AI wisi w powietrzu. To technolog lub inżynier procesu jest w stanie ocenić, czy modele mają sens z perspektywy fizyki procesu i doświadczenia linii. Gdy system pokazuje, że kluczowym czynnikiem ryzyka jest pewien zakres temperatury, technolog może powiedzieć: „To nierealne, ten czujnik jest źle skalibrowany od miesięcy” albo przeciwnie: „To ciekawa wskazówka, której nie mieliśmy w standardowych raportach”.
Rola inżyniera procesu nie powinna ograniczać się do „konsultacji na żądanie”. Potrzebuje on realnego czasu w projekcie: na wspólne warsztaty z data/ML, na weryfikację hipotez, na udział w projektowaniu logiki alarmów i rekomendacji. Inaczej skończy się na tym, że jego uwagi trafią dopiero na końcu, gdy cała architektura systemu będzie już zamrożona.
Automatyk / OT: strażnik rzeczywistości sprzętowo-systemowej
Automatycy i specjaliści OT często są wrzucani do projektu AI jako „dostawcy danych” – mają „tylko podłączyć się do PLC i wysłać sygnały”. To błąd. To oni najlepiej wiedzą, które sygnały są stabilne, gdzie są wąskie gardła sieci, jakie są ograniczenia sterowników i co się stanie przy przeciążeniu systemu kolejnymi zapytaniami.
Zaangażowany OT-owiec na starcie jest w stanie uchronić projekt przed kosztownymi niespodziankami: „Ten sterownik nie udźwignie takiej częstotliwości odczytów”, „Tutaj mamy wyspę sieciową, z której nie wyniesiemy danych w czasie rzeczywistym”, „Ten czujnik jest logiczny, a nie fizyczny – to różnica”. Jeżeli jego rola zostanie zredukowana do „przyjdź, gdy nie działa”, projekt wejdzie na minę dopiero w pilotażu.
Utrzymanie ruchu: praktycy awarii i ograniczeń zasobów
Zespół utrzymania ruchu często bywa pomijany na wczesnym etapie, a potem oczekuje się, że będzie głównym użytkownikiem systemu predykcyjnego. To oni najlepiej znają historię awarii, faktyczne czasy reakcji, realne koszty przestojów i dostępność ekip. Bez ich udziału AI wygeneruje „idealny plan serwisów”, który jest nie do zrealizowania kadrowo.
Dobry przedstawiciel utrzymania ruchu wnosi też cenną perspektywę priorytetów: „Ta maszyna ma wysoki scrap, ale niski wpływ na bottleneck, bardziej opłaca się nam skupić na tamtej”, „Ten alarm jest dla nas bezużyteczny, bo i tak nie mamy części na magazynie, czas reakcji minimum dwa dni”. To są kryteria, których czysty model statystyczny nie ma prawa znać.
Przedstawiciel operatorów: filtr na to, co jest wykonalne na zmianie
Obecność reprezentanta operatorów w zespole projektowym bywa traktowana jako „ładny gest”. W praktyce to klucz do uniknięcia wielu głupich błędów. Operator potrafi powiedzieć, czy zestaw kroków sugerowanych przez system da się wykonać w czasie, gdy ma równolegle trzy inne zadania i audyt jakości.
Bez tego powstają rekomendacje typu: „Przy każdym alarmie ryzyka scrapu wykonaj sekwencję pięciu czynności”, podczas gdy w realiach danej zmiany można wykonać maksymalnie dwie. Albo interfejs, który wymaga przełączania się między trzema ekranami, gdy operator ma fizycznie tylko jeden panel dotykowy i ręce zajęte obsługą maszyny.
Change manager / lider zmiany: ktoś, kto „posprząta” konsekwencje
AI, które zaczyna wpływać na decyzje, uruchamia całą kaskadę skutków ubocznych: zmiana zakresu obowiązków, inne rozliczanie wyników, nowe źródło sporów między działami. Ktoś musi świadomie tym zarządzać. To nie jest „miękka rola”, którą można przypisać komuś z HR „po godzinach”.
Lider zmiany pilnuje, by projekt był osadzony w ogólnej strategii zakładu, by komunikaty do ludzi były spójne, by szkolenia nie kończyły się na „klikaniu w system”, tylko obejmowały też zmianę odpowiedzialności. To on (lub ona) reaguje, gdy pojawiają się plotki typu „system ma nas zastąpić” albo „wszystkie błędy teraz będą na nas”. Bez takiej roli napięcia rosną pod powierzchnią, a w pewnym momencie eksplodują w postaci biernego oporu.
IT / architekt korporacyjny: strażnik integracji i bezpieczeństwa
IT / architekt korporacyjny: bez niego projekt utknie na integracjach
W wielu firmach IT pojawia się dopiero wtedy, gdy system AI „trzeba podpiąć pod AD” albo „wystawić na produkcję”. To za późno. Architekt korporacyjny widzi całość: od polityk bezpieczeństwa, przez standardy backupu, po ograniczenia licencyjne systemów, z którymi trzeba się zintegrować.
Mit bywa taki: „Najpierw zróbmy POC na boku, potem się jakoś to włączy w korporacyjne IT”. Rzeczywistość: jeśli na początku nie sprawdzi się, jak wygląda sieć, jakie są reguły firewalli, gdzie wolno trzymać dane produkcyjne i jaki jest cykl wdrażania zmian w systemach centralnych, to „jakoś” zamienia się w wielomiesięczne przeciąganie kabli – w przenośni i dosłownie.
Przedstawiciel IT powinien brać udział w decyzjach o architekturze rozwiązania: czy system ma działać on-premise czy w chmurze, jak będzie wyglądało logowanie użytkowników, jak integruje się to z MES/ERP/CMMS. To on też zwykle odpowiada za kontakty z globalnym działem bezpieczeństwa i zatwierdzanie nowych komponentów technologicznych. Bez tej osoby projekt dryfuje w kierunku „piaskownicy pilotażowej”, z której nie ma wyjścia na produkcję.
Biznes owner z fabryki: osoba, która naprawdę ma „skórę w grze”
Każdy projekt AI w fabryce musi mieć jednego, czytelnego właściciela biznesowego. Nie „komitet sterujący”, tylko konkretną osobę z realnym wpływem na decyzje i budżet. To ona rozstrzyga spory priorytetów, godzi oczekiwania różnych działów i bierze odpowiedzialność za efekt, także po zakończeniu wdrożenia.
Dobry business owner rozumie, że model to środek do celu, a nie cel sam w sobie. Umie powiedzieć: „W tym roku naszym priorytetem jest stabilność bottlenecku, a nie kolejny dashboard do scrapu na bocznej linii”. To on zadaje pytania o wpływ na OEE, koszty, bezpieczeństwo, a nie tylko o „dokładność predykcji”.
Jeżeli właściciel jest tylko „na papierze”, projekt zaczyna działać w próżni decyzyjnej. Każdy ciągnie w swoją stronę: utrzymanie ruchu chce mniej alarmów, jakość – więcej, produkcja – krótsze postoje. Bez osoby, która może podjąć decyzję, projekt tonie w kompromisach.
Kluczowe kompetencje: co kto musi umieć, żeby projekt dowiózł
Data scientist / ML engineer: od modelu do działającego serwisu
W środowisku produkcyjnym rola data scientist nie kończy się na zbudowaniu modelu w notebooku. Potrzebna jest kombinacja umiejętności analitycznych i inżynierskich, które pozwolą przejść pełną drogę: od surowych danych z linii, przez przygotowanie cech, do stabilnego, monitorowanego modelu, który działa w czasie rzeczywistym.
Na poziomie technicznym oznacza to kilka rzeczy. Po pierwsze, swobodne poruszanie się po danych czasowych (time series) i zrozumienie typowych pułapek: rozjazdy zegarów, zmienne częstotliwości próbkowania, missingi związane z postojami. Po drugie, umiejętność budowania pipeline’ów, które dadzą się odtworzyć – wersjonowanie kodu i modeli, repozytoria, testy. Po trzecie, podstawowa znajomość konteneryzacji i API, bo inaczej ML pozostaje w fazie „eksperyment”, a nie „usługa”.
W praktyce równie ważne są kompetencje miękkie. Data scientist musi umieć wytłumaczyć technologicznemu, co model tak naprawdę robi, bez zasłaniania się żargonem. Powinien też słyszeć, gdy produkcja mówi „to się nie da wdrożyć na zmianie” – i potrafić razem z nimi zmienić logikę alarmów czy częstotliwość rekomendacji.
Inżynier danych / integrator: ktoś, kto „dowiezie” dane na miejsce
Każdy projekt AI w fabryce rozbija się prędzej czy później o integracje. Ktoś musi umieć bezpiecznie i stabilnie wyciągnąć dane z PLC, SCADA, MES, czasem z arkuszy Excela, i zamienić tę mieszankę w spójne, dobrze opisane strumienie danych. To nie jest zadanie „na marginesie” dla data scientist – to osobna specjalizacja.
Do kluczowych umiejętności integratora należą: znajomość protokołów przemysłowych (OPC UA, Modbus, czasem starsze wynalazki), rozumienie architektury sieci OT/IT, doświadczenie z narzędziami ETL/ELT i systemami typu historian. Ważna jest też świadomość konsekwencji: dodatkowy odczyt co sekundę z kilkudziesięciu sterowników to nie detal, tylko realne obciążenie dla infrastruktury.
Mit: „Jak tylko dostaniemy dostęp do bazy, dane już jakoś się ogarnie”. Rzeczywistość: bez kogoś, kto potrafi zaprojektować schematy, nazewnictwo, klucze łączeniowe i kontrolę jakości danych, data scientist spędza 80% czasu na walce z chaosem, a nie na budowaniu modeli.
Technolog / inżynier procesu: kompetencje, których nie zastąpi żaden dashboard
Technolog z zespołu AI potrzebuje dwóch zestawów umiejętności: głębokiej znajomości procesu oraz zdolności do pracy z danymi na poziomie „inżyniera-interpretatora”. Nie musi pisać kodu, ale powinien umieć czytać wykresy korelacji, rozumieć podstawową statystykę, zapytać o rozkłady, mediany, odchylenia. Dzięki temu może świadomie kwestionować wnioski modelu.
Ten człowiek musi też swobodnie poruszać się w dokumentacji technicznej: kartach maszyn, SPC, FMEA, standardach jakości. To na jego barkach spoczywa przełożenie wyników modeli na realne zmiany parametrów: które limity można zawęzić, jakie okna procesu są jeszcze bezpieczne, gdzie dotykamy granic dopuszczalnych przez dostawców komponentów czy regulatorów.
Kluczowa jest umiejętność stawiania hipotez procesowych na bazie sygnałów z modelu: „Jeśli algorytm pokazuje, że przy tych kombinacjach parametrów scrap rośnie, to czy to wynika z nieliniowości materiału, czy z naszych ustawień startowych?”. Bez takiej dyskusji system zostaje w fazie „czarna skrzynka, która coś sobie przewiduje”.
Specjalista OT/automatyki: od sygnału w PLC do stabilnego systemu
Automatyk zaangażowany w projekty AI potrzebuje kompetencji wykraczających poza klasyczne „utrzymanie sterownika przy życiu”. Musi rozumieć zarówno szczegóły konfiguracji PLC, jak i ogólny kształt architektury OT w zakładzie. Bez tego trudno zaprojektować punkt zbierania danych, który będzie wystarczająco blisko procesu, a jednocześnie bezpieczny dla reszty systemu.
W praktyce oznacza to: znajomość konfiguracji sieci przemysłowych, zasad segmentacji i izolacji, umiejętność diagnozowania opóźnień i przerw w komunikacji. Potrzebna jest także odporność na „magiczne myślenie” zespołów AI: jeśli ktoś żąda odczytu co 100 ms z kilku setek zmiennych, automatyk musi umieć policzyć, co to zrobi z siecią i sterownikami – i twardo to zakomunikować.
Dobrze, gdy OT-owiec ma choć podstawową orientację w narzędziach do monitoringu systemów IT/OT, bo dzięki temu może aktywnie uczestniczyć w budowaniu systemów monitoringu dla rozwiązań AI – a nie tylko reagować, gdy linia już stanęła.
Inżynier utrzymania ruchu: diagnoza, priorytety, egzekucja w realnych warunkach
Predykcyjne utrzymanie ruchu brzmi atrakcyjnie na prezentacjach, ale bez doświadczonego inżyniera UR projekty lądują w szufladzie. Taka osoba musi łączyć praktyczną znajomość maszyn (typowe tryby awarii, słabe punkty, zachowanie pod obciążeniem) z umiejętnością pracy z danymi historycznymi o awariach i przestojach.
Przydatne są proste, ale konsekwentne nawyki analityczne: porządkowanie przyczyn awarii, dopilnowanie jakości opisów w CMMS, weryfikacja, czy przewidywana awaria odpowiada realnym symptomom, jakie zespół widzi na hali. Bez tego model uczy się na błędnych etykietach i później „przewiduje” coś, co w notatkach opisano jako „różne przyczyny”.
Krytyczna kompetencja UR to też umiejętność zarządzania priorytetami. Jeśli system AI proponuje dziesięć interwencji tygodniowo, inżynier UR musi umieć je urealnić: które są krytyczne, które można połączyć z planowanymi przestojami, których nie ma sensu ruszać z powodu braku części lub okien serwisowych. Bez takiego filtra fabryka szybko uzna, że „AI generuje nierealne wymagania”.
Przedstawiciel operatorów / lider zmiany: użytkownik, który mówi prawdę
Operator pełniący funkcję „ambasadora” w projekcie AI potrzebuje więcej niż tylko doświadczenia na stanowisku. Kluczowe są: otwartość na nowe rozwiązania, umiejętność jasnego opisywania problemów („co się naprawdę dzieje na zmianie, gdy świeci się pięć alarmów naraz”) i gotowość do przekazywania niepopularnych informacji w obie strony – do zespołu projektowego i do załogi.
Ten człowiek powinien umieć współtworzyć scenariusze użycia: jak wygląda dzień pracy z nowym systemem, jakie są punkty styku z istniejącymi ekranami, jak wyglądają przerwy, audyty, zmiany partii. To nie są „miękkie rozmowy”, tylko kluczowe wejścia projektowe, które decydują o ergonomii i akceptacji systemu.
Mit: „Operatorzy się przyzwyczają, jak już to wdrożymy”. Rzeczywistość: jeśli interfejs i logika pracy z systemem są projektowane bez ich udziału, bunt pojawia się po cichu – przez ignorowanie alarmów, „obejścia” i odkładanie korzystania z rekomendacji „na później”.
Change manager / lider transformacji: kompetencje do pracy z oporem
Lider zmiany w projektach AI musi rozumieć zarówno biznes produkcyjny, jak i mechanizmy oporu organizacyjnego. To nie jest rola ograniczona do wysłania kilku maili o „nowym systemie”. Chodzi o kogoś, kto potrafi zidentyfikować, kogo zmiana dotknie najmocniej, jakie są realne obawy zespołów i jak zamienić je w konkretne działania: szkolenia, pilotaże, korekty mierników.
Użyteczne są umiejętności z obszaru facylitacji warsztatów, dialogu z liderami zmian, projektowania komunikacji dopasowanej do różnych grup (operatorzy, brygadziści, kierownicy, kadra wyższa). Lider zmiany powinien też umieć „czytać” nieformalne sygnały: rosnącą liczbę zgłoszeń „system nie działa”, które w rzeczywistości są objawem braku zaufania, albo narastające konflikty między działami o to, kto ponosi odpowiedzialność za decyzje podjęte na podstawie rekomendacji AI.
W praktyce to właśnie ta rola spina w całość zmiany procesowe, szkolenia, aktualizację instrukcji, modyfikacje KPI i systemów premiowych. Bez tego każda z tych rzeczy zaczyna żyć własnym życiem, a ludzie przestają rozumieć, po co w ogóle wprowadzono nowe narzędzie.
IT / cyberbezpieczeństwo: kompetencje, które pozwalają spać spokojnie
Specjalista IT z kompetencjami w obszarze bezpieczeństwa musi umieć ocenić ryzyka związane z nowymi komponentami AI: dodatkowymi serwerami, połączeniami z chmurą, integracją z istniejącymi systemami biznesowymi. Chodzi nie tylko o klasyczne „łatki i antywirusy”, ale też o kontrolę uprawnień, segmentację sieci, szyfrowanie transmisji, logowanie zdarzeń bezpieczeństwa.
W fabryce dochodzi jeszcze perspektywa OT security: co się stanie, jeśli ktoś niepowołany uzyska dostęp do danych z linii lub – gorzej – do warstwy sterowania? Czy nowe rozwiązanie nie tworzy nieplanowanego mostu między światem IT a OT? Czy aktualizacje modelu nie wymagają otwierania dodatkowych portów, które zwiększają powierzchnię ataku?
Mit: „To tylko analityka, najwyżej ktoś zobaczy dane”. Rzeczywistość: źle zabezpieczona integracja pod AI potrafi stać się najsłabszym punktem całej architektury, a incydent bezpieczeństwa może zatrzymać nie tylko projekt, lecz także produkcję.
Manager produktu / właściciel rozwiązania: utrzymanie kierunku po wdrożeniu
Jeśli projekt AI ma stać się trwałym elementem ekosystemu fabryki, potrzebuje roli przypominającej product ownera. To osoba, która po formalnym „wdrożeniu” dalej zajmuje się rozwiązaniem: zbiera feedback, priorytetyzuje poprawki, planuje rozwój funkcji i dba o to, by system nie zestarzał się w rok.
Taki właściciel rozwiązania powinien znać użytkowników, rozumieć ich potrzeby i potrafić je skonfrontować z ograniczeniami technicznymi i budżetowymi. Musi umieć powiedzieć „nie” kolejnym życzeniom dotyczącym nowych wykresów, jeśli nie wspierają one głównego celu biznesowego. Jednocześnie to on inicjuje kolejne iteracje: nowe modele, rozszerzenie o dodatkowe linie, integrację z innymi systemami.
Bez tej roli projekty AI w fabrykach często „umierają z zaniedbania”. Po pierwszym roku nikt już nie pamięta, kto ma decydować o zmianach, błędy wiszą miesiącami, a system powoli wypada z codziennego użycia, bo nie nadąża za zmianami w procesie i organizacji.
Najczęściej zadawane pytania (FAQ)
Dlaczego projekty AI w fabrykach najczęściej upadają po fazie PoC?
Najczęstszy powód to rozjazd między „laboratoryjnym” PoC a prawdziwą produkcją 24/7. Model działał na historycznych, oczyszczonych danych, a na hali zderza się z brakami w danych, awaryjnością maszyn, zmianami ustawień, rotacją załogi i procedurami, które nikt nie zmienił pod AI.
Mit brzmi: „Skoro PoC wyszedł, to wdrożenie to formalność”. Rzeczywistość jest taka, że PoC zwykle nie dotyka kluczowych problemów: integracji z automatyką, sposobu reagowania ludzi oraz utrzymania rozwiązania w czasie. Bez zakotwiczenia AI w konkretnych decyzjach i odpowiedzialnościach system po kilku miesiącach staje się kolejnym, ignorowanym panelem.
Jakie są najważniejsze przyczyny porażki projektów AI w przemyśle?
Główne przyczyny nie są techniczne, tylko organizacyjne. Najczęściej pojawiają się braki w czterech obszarach: procesie, danych, decyzjach i odpowiedzialności. Brakuje jasnego sposobu pracy nad projektem, dane są rozproszone i niespójne, nie wiadomo, kto ma reagować na rekomendacje AI, a nikt nie jest rozliczany z efektu biznesowego.
Do tego dochodzi struktura silosowa: produkcja, utrzymanie ruchu, jakość, IT czy automatyka działają w oderwaniu od siebie. AI przecina wszystkie te obszary naraz, więc bez sponsora i zespołu międzydziałowego tonie w uzgodnieniach. Technologia bywa poprawna, tylko organizacja nie jest na nią przygotowana.
Czy do udanego projektu AI w fabryce wystarczy „dobry algorytm” lub właściwy dostawca?
To jeden z najpopularniejszych mitów. Algorytmy, biblioteki i narzędzia są dziś stosunkowo łatwo dostępne, a różnice między nimi rzadko decydują o „być albo nie być” projektu. Największe problemy leżą gdzie indziej: w jakości i dostępności danych, w procesie decyzyjnym oraz w tym, kto faktycznie jest właścicielem wyniku.
Średni model, ale zasilany sensownymi danymi i osadzony w dobrze opisanym procesie decyzyjnym, robi w praktyce więcej, niż wyrafinowany algorytm, który żyje obok realnego procesu produkcyjnego. Jeśli organizacja nie jest gotowa zmienić sposób pracy, najlepszy vendor i najnowsza technologia niewiele pomogą.
Jak zbudować zespół projektowy AI w fabryce, żeby dowiózł wynik?
Zespół nie może składać się wyłącznie z IT, data scientistów i dostawcy. Potrzebna jest mieszanka ludzi technicznych i operacyjnych, którzy realnie „dotykają” procesu. W praktyce oznacza to obecność: właściciela procesu (np. kierownika produkcji linii), technologa lub inżyniera procesu, przedstawiciela utrzymania ruchu, osoby z automatyki/OT, reprezentanta operatorów oraz kogoś odpowiedzialnego za zmianę organizacyjną.
Rzeczywistość obala tu mit: „projekt AI to sprawa działu innowacji lub IT”. Bez ludzi z hali, którzy mają mandat do zmiany procedur i nawyków, projekt kończy jako ciekawostka. Dobrze zbudowany zespół od początku ustala, jakie decyzje będą podejmowane inaczej dzięki AI i kto za nie odpowiada.
Jak przełamać opór produkcji wobec wdrożeń AI?
Klucz to przełożenie AI na konkretne, codzienne sytuacje operatora i mistrza zmiany. Zamiast obietnic typu „poprawa OEE o X%”, potrzebne są jasne odpowiedzi: kiedy ma się pojawić alarm, kto ma na niego reagować, w jakim czasie i jaką akcją. Do tego trzeba włączyć średni szczebel zarządzania (liderzy zmian, kierownicy produkcji) od samego początku, a nie dopiero przy szkoleniach.
Po drugie, AI nie może być „systemem obok”. Jeśli operator ma trzeci ekran z rekomendacjami, ale rozliczany jest z targetu produkcyjnego według starych zasad, to naturalnie wróci do starego sposobu pracy. Zmiana regulaminów, procedur i kryteriów oceny pracy bywa mniej spektakularna niż demo modelu, ale to ona decyduje, czy AI będzie używane, czy omijane.
Jak uniknąć rozbicia projektu AI o silosy organizacyjne (produkcja, UR, jakość, IT)?
Najpierw trzeba jasno wskazać sponsora biznesowego z mandatem, który „spina” różne działy – zwykle jest to ktoś z operacji lub dyrektor zakładu. Następnie buduje się zespół międzydziałowy z jasno opisanymi rolami i odpowiedzialnością za konkretny wskaźnik (np. scrap na danej linii, konkretne awarie, zużycie energii dla wybranych maszyn).
Pomaga też zawężenie use case’u. Zamiast ogólnego „predykcyjne utrzymanie ruchu w całej fabryce”, lepiej zacząć od jednego, dobrze opisanego problemu na konkretnej linii, gdzie wszystkie strony mają interes w rozwiązaniu. Mniejszy zakres to mniej uzgodnień, szybszy efekt i realny dowód, że współpraca między silosami jest możliwa.
Jakie elementy trzeba zaplanować, zanim fabryka ruszy z projektem AI?
Przed startem warto ustalić kilka rzeczy: jasno zdefiniowany, wąski use case (konkretny problem, a nie ogólne „optymalizacje”), dostęp i jakość danych potrzebnych do jego rozwiązania, właściciela biznesowego po stronie operacji oraz sposób, w jaki rekomendacje AI będą włączone w istniejące procedury. Bez tego projekt zaczyna się od entuzjazmu i slajdów, a kończy na gaszeniu pożarów organizacyjnych.
Mit mówi: „najpierw zróbmy PoC, a resztę się dogra później”. Praktyka pokazuje, że „później” oznacza zwykle nigdy, bo organizacja wraca do codziennych zadań. Im wcześniej spisane są decyzje, role i kryteria sukcesu, tym mniejsze ryzyko, że udana technicznie demonstracja przekształci się w martwy system po wdrożeniu.
Źródła informacji
- Artificial Intelligence in Industry 4.0: A Review. IEEE (2018) – Przegląd zastosowań AI w przemyśle i wyzwań wdrożeniowych
- Artificial Intelligence in Industry and Finance. Springer (2021) – Rozdziały o integracji AI z procesami biznesowymi i produkcyjnymi
- The AI Ladder: Demystifying AI Challenges in Business. IBM Institute for Business Value (2019) – Bariery danych, procesów i organizacji przy projektach AI
- Artificial Intelligence in Practice: How 50 Successful Companies Used AI. Wiley (2019) – Studia przypadków wdrożeń AI, w tym w produkcji i logistyce
- Predictive Maintenance in Industry 4.0: A Systematic Literature Review. Elsevier (2020) – Przegląd projektów predykcji awarii i typowych problemów danych
- Organizing for Digital: Why Digital Transformations Fail. McKinsey Global Institute (2018) – Analiza przyczyn porażek transformacji cyfrowych i roli zarządzania
