AI w PLM: Product Lifecycle Intelligence kolejnym etapem ewolucji PLM

Sztucznej inteligencji nie sposób dziś ignorować. Wszyscy najwięksi dostawcy rozwiązań PLM dodają funkcje AI do swojego portfolio, analitycy przewidują nową falę wzrostu produktywności, a firmy produkcyjne szukają praktycznych sposobów wykorzystania sztucznej inteligencji w inżynierii, produkcji i serwisie.

Można uznać, że to po prostu kolejny rozdział w rozwoju Product Lifecycle Management. Moim zdaniem sytuacja wygląda jednak nieco inaczej. Duża część dzisiejszej dyskusji o AI w PLM koncentruje się na nowych możliwościach. Tymczasem ważniejsza zmiana zachodzi gdzie indziej: producenci zaczynają oczekiwać od Product Lifecycle Management czegoś więcej.

PLM powstał po to, aby zarządzać produktami. Dziś oczekuje się od niego wsparcia w podejmowaniu decyzji.

Kiedy Product Lifecycle Management zaczął być powszechnie stosowany, rozwiązywał problem znany każdej organizacji inżynieryjnej. Informacje o produkcie były rozproszone. Pliki projektowe znajdowały się w różnych systemach, zmiany inżynieryjne trudno było prześledzić, a zespoły często pracowały na nieaktualnej dokumentacji. Wraz ze wzrostem złożoności produktów zarządzanie tym wszystkim bez uporządkowanego środowiska stawało się praktycznie niemożliwe.

PLM to zmienił. Wprowadził zasady zarządzania informacją, kontrolę wersji i jedno źródło prawdy dla informacji o produkcie. Dla wielu producentów stał się jedną z najważniejszych inwestycji technologicznych ostatnich dwóch dekad.

To się nie zmieniło. Zmieniło się natomiast otoczenie.

Współczesne produkty łączą mechanikę, elektronikę, oprogramowanie wbudowane, łączność, a coraz częściej także sztuczną inteligencję. Zespoły odpowiedzialne za ich rozwój są rozproszone pomiędzy różnymi lokalizacjami i dostawcami. Wymagania regulacyjne stale rosną. Pojedyncza zmiana inżynieryjna może wpłynąć na produkcję, jakość, zakupy, serwis i zgodność regulacyjną jeszcze zanim produkt trafi do klienta.

Zarządzanie informacją nadal jest niezbędne, ale już nie wystarcza. Liderzy inżynierii zadają dziś inne pytania niż dziesięć lat temu.

Nie:

„Gdzie znajdę najnowszą definicję produktu?”

Coraz częściej:

„Jeżeli wprowadzimy tę zmianę, na co jeszcze wpłynie?”

To zasadniczo różne pytania. Pierwsze dotyczy dostępu do informacji. Drugie – zrozumienia zależności. Łatwo przeoczyć tę różnicę, ponieważ oba pytania opierają się na tych samych danych. Wymagają jednak zupełnie innych możliwości.

Weźmy przykład dostawcy, który zastępuje jeden materiał innym. Znalezienie najnowszej specyfikacji jest stosunkowo proste. Zrozumienie konsekwencji tej zmiany – już nie. Czy konieczne będą dodatkowe testy? Czy zmiana wpłynie na parametry produkcji? Czy dotyczy produktów, które już pracują u klientów? Czy trzeba będzie zaktualizować dokumentację przekazaną organom regulacyjnym?

Żaden pojedynczy system nie zawiera wszystkich tych odpowiedzi. Pojawiają się one dopiero wtedy, gdy informacje pochodzące z różnych etapów cyklu życia produktu można analizować wspólnie.

Ta zmiana oczekiwań wyjaśnia, dlaczego w ostatnich latach coraz częściej mówi się o Product Lifecycle Intelligence (PLI). Wbrew temu, co może sugerować nazwa, PLI nie oznacza zastąpienia PLM kolejną platformą. Odzwierciedla raczej szerszą zmianę sposobu myślenia.

Sztuczna Inteligencja nie stworzyła problemu. Po prostu go ujawniła.

Wiele rozmów o AI w PLM zaczyna się od copilotów, inteligentnego wyszukiwania czy automatycznego tworzenia dokumentacji. Te możliwości są istotne, ale nie wyjaśniają, dlaczego niektóre organizacje odnoszą sukces, podczas gdy inne nie potrafią wyjść poza pojedyncze projekty pilotażowe.

Powinniśmy zacząć zadawać pytania:

• Czy Sztuczna Inteligencja potrafi podsumowywać dokumentację techniczną?
• Czy potrafi przeszukiwać dane inżynieryjne za pomocą języka naturalnego?
• Czy potrafi generować wymagania lub sugerować ulepszenia projektu?

To przydatne możliwości. Niektóre z nich już dziś przynoszą mierzalny wzrost produktywności. Nie wyjaśniają jednak, dlaczego dwóch producentów korzystających z podobnych narzędzi AI może osiągać zupełnie różne rezultaty.

Odpowiedź zazwyczaj ma mniej wspólnego z samą sztuczną inteligencją, a więcej ze środowiskiem, w którym ona działa.

Każdy, kto pracował z dojrzałym środowiskiem PLM, wie, że cenna wiedza o produkcie rzadko znajduje się w jednym miejscu. Wymagania mogą być przechowywane w ALM, struktury produktów w PLM, informacje produkcyjne w MES, dane o dostawcach w ERP, dane jakościowe w QMS, a historia serwisowa – w jeszcze innym systemie.

Każdy z tych systemów osobno dobrze spełnia swoją funkcję. Razem opowiadają historię produktu. Problem polega na tym, że zależności pomiędzy nimi są często oczywiste dla ludzi, ale niewidoczne dla oprogramowania.

Doświadczony inżynier wie, że problem zgłoszony przez technika serwisowego może mieć związek ze zmianą inżynieryjną zatwierdzoną kilka miesięcy wcześniej. Wie, gdzie szukać, kogo zapytać i które decyzje mogą dostarczyć brakującego kontekstu. A AI? AI nie ma takiej intuicji – może pracować wyłącznie na zależnościach, które już istnieją w dostępnej wiedzy o produkcie.

Dlatego niektóre inicjatywy AI szybko się skalują, podczas gdy inne pozostają ograniczone do pojedynczych projektów pilotażowych. Różnicę rzadko stanowi sam model językowy. Znacznie częściej decyduje o niej jakość kontekstu produktowego, w którym ten model funkcjonuje.

I to zmienia charakter całej dyskusji.

Pytanie nie brzmi już, czy producenci mają wystarczająco dużo danych o produktach, ponieważ większość z nich już je ma. Prawdziwe – i znacznie ważniejsze – pytanie brzmi: czy te dane tworzą spójną, połączoną historię?

Product Lifecycle Intelligence zaczyna się od połączeń, nie od algorytmów

Jeżeli AI ujawniła ograniczenia wynikające z rozproszonej wiedzy o produkcie, pojawia się oczywiste pytanie: co trzeba zmienić?

Intuicyjna odpowiedź: lepsza AI.

Bardziej użyteczna odpowiedź: lepszy kontekst.

Zastanówmy się, jak dziś podejmowane są decyzje inżynieryjne. Rzadko zdarza się, aby jedna osoba podejmowała decyzję na podstawie pojedynczego dokumentu. Zamiast tego łączy informacje z wielu źródeł. Analizuje wymagania, porównuje kolejne wersje projektu, sprawdza ograniczenia produkcyjne, bierze pod uwagę wcześniejsze problemy jakościowe, a w razie potrzeby rozmawia z osobami, które znają historię produktu.

Innymi słowy, nie tylko zbiera informacje – łączy je ze sobą.

Na tym właśnie opiera się Product Lifecycle Intelligence.

Zamiast traktować dane o produkcie jako zbiór niezależnych rekordów, PLI koncentruje się na relacjach między nimi. Wymaganie jest powiązane z oprogramowaniem, które je realizuje. Oprogramowanie jest powiązane ze sprzętem, na którym działa. Ten z kolei łączy się z procesami produkcyjnymi, informacjami o dostawcach, wynikami testów oraz produktami, które już pracują u klientów.

Wartość tkwi nie tyle w pojedynczych rekordach, ile w łańcuchu zależności, który wspólnie tworzą.

Wyobraźmy sobie, że klient zgłasza nieoczekiwaną awarię produktu. Znalezienie raportu serwisowego jest łatwe. Prawdziwym wyzwaniem jest zrozumienie, co wydarzyło się wcześniej, zanim produkt w ogóle trafił do klienta. Które wymaganie wprowadziło daną funkcjonalność? Która zmiana inżynieryjna ją zmodyfikowała? Jaka wersja oprogramowania została zainstalowana? Czy dany komponent pochodził od innego dostawcy? Czy podobne problemy wykryto podczas walidacji, ale uznano je wówczas za akceptowalne?

Ręczne znalezienie odpowiedzi na te pytania może wymagać zaangażowania kilku zespołów i pracy w wielu systemach. Szybkość ich uzyskania może jednak zdecydować o tym, czy firma rozwiąże problem w ciągu kilku godzin, czy kilku tygodni.

Dlatego Product Lifecycle Intelligence nie należy traktować jako kolejnej kategorii oprogramowania funkcjonującej obok PLM. Lepiej rozumieć PLI jako kolejny etap jego ewolucji. Rola PLM rozszerza się – od zarządzania informacją o produkcie do wspierania organizacji w jej analizowaniu i interpretowaniu.

Wyobraźmy sobie producenta, który otrzymuje zgłoszenia o nieoczekiwanej awarii produktu u klienta. Pierwsze pytanie rzadko brzmi: co się zepsuło? Znacznie ważniejsze jest: dlaczego do tego doszło, ilu produktów może dotyczyć problem i co należy zrobić dalej?

Bez połączonego kontekstu produktowego zespoły inżynierii, jakości, serwisu i produkcji często przez wiele dni składają informacje pochodzące z PLM, ALM, ERP, QMS oraz systemów serwisowych. Muszą ustalić, które wymaganie wprowadziło daną funkcjonalność, która zmiana inżynieryjna ją zmodyfikowała, jaka wersja oprogramowania została wydana, czy uczestniczył w tym ten sam dostawca i czy podobne problemy występowały już wcześniej.

Product Lifecycle Intelligence nie zastępuje tego dochodzenia. Przyspiesza je, ponieważ uwidacznia zależności między informacjami. Prawdziwa wartość nie polega wyłącznie na szybszym znalezieniu danych, ale na skróceniu czasu potrzebnego do oceny wpływu, określenia skali problemu i podjęcia decyzji z większą pewnością.

Dlaczego Digital Thread jest dziś ważniejszy niż kiedykolwiek

Dlatego rozmowa nieuchronnie prowadzi do Digital Thread.

Przez lata Digital Thread był często opisywany jako sposób na połączenie systemów inżynieryjnych. To prawda, ale pokazuje tylko część jego wartości.

• Połączenie systemów jest osiągnięciem technologicznym.
• Połączenie wiedzy jest kompetencją biznesową.

Digital Thread zachowuje relacje między informacjami na kolejnych etapach cyklu życia produktu. Łączy decyzje podejmowane podczas opracowywania koncepcji ze zmianami inżynieryjnymi, realizacją produkcji, kolejnymi wersjami oprogramowania, zdarzeniami jakościowymi i działaniami serwisowymi. Zamiast traktować każdy etap jako osobny proces, tworzy pomiędzy nimi ciągłość.

Ta ciągłość staje się coraz cenniejsza wraz ze wzrostem znaczenia oprogramowania w produktach.

Weźmy przykład zdalnej aktualizacji oprogramowania maszyny przemysłowej. Na pierwszy rzut oka jest to po prostu nowa wersja oprogramowania. W rzeczywistości może wpłynąć na procedury operacyjne, harmonogramy konserwacji, dokumentację regulacyjną, planowanie części zamiennych czy obsługę klienta.

Z perspektywy poszczególnych systemów działania te należą do różnych działów. Z perspektywy Digital Thread wszystkie są konsekwencją jednej decyzji dotyczącej produktu.

To rozróżnienie ma znaczenie, ponieważ AI nie tworzy kontekstu samodzielnie.

Asystent AI może w kilka sekund podsumować tysiące dokumentów, ale nie jest w stanie wywnioskować zależności, które nie istnieją. Jeżeli dane inżynieryjne, konfiguracje oprogramowania, informacje produkcyjne i historia serwisowa pozostają rozproszone, model nie ma wiarygodnego sposobu, aby zrozumieć, jak wpływają na siebie nawzajem.

Im pełniejszy Digital Thread, tym bogatszy kontekst dostępny zarówno dla ludzi, jak i dla AI.

Dlatego organizacje inwestujące w Product Lifecycle Intelligence nie przygotowują się wyłącznie na bardziej zaawansowaną sztuczną inteligencję. Budują środowisko, w którym zarówno ludzie, jak i technologia mogą podejmować decyzje w oparciu o ten sam, spójny obraz produktu.

Organizacje, które najwięcej zyskują dzięki AI, zazwyczaj najpierw zrobiły coś innego

Łatwo założyć, że kolejną przewagę konkurencyjną w produkcji zapewni wdrożenie bardziej zaawansowanych modeli AI. W praktyce wiele organizacji odkrywa, że sztuczna inteligencja przynosi największą wartość dopiero wtedy, gdy wcześniej zadbano o odpowiednie fundamenty.

Organizacje, które robią największe postępy w wykorzystaniu AI, rzadko od niej zaczynały. Znacznie częściej przez lata budowały fundamenty, dzięki którym sztuczna inteligencja może być użyteczna: poprawiały jakość danych, ustanawiały zasady zarządzania nimi, łączyły różne dyscypliny inżynieryjne i tworzyły wiarygodny Digital Thread obejmujący cały cykl życia produktu.

Inwestycje te nie były pierwotnie realizowane z myślą o generatywnej AI. Ich celem było zwiększenie efektywności inżynierii, przyspieszenie rozwoju produktów i ograniczenie ryzyka kosztownych błędów. Dziś pełnią jeszcze jedną funkcję: zapewniają kontekst, na którym może polegać AI.

To ważne rozróżnienie, ponieważ zmienia sposób, w jaki producenci powinni myśleć o kolejnych inwestycjach.

Jeżeli wiedza o produkcie pozostaje rozproszona, dodanie kolejnej aplikacji AI raczej nie rozwiąże podstawowego problemu. Może pomóc poszczególnym osobom pracować szybciej, ale trudno będzie jej poprawić jakość podejmowania decyzji w skali całej organizacji.

Jeżeli natomiast wiedza o produkcie jest połączona i możliwa do prześledzenia, AI staje się znacznie bardziej wartościowa, ponieważ może analizować zależności w całym cyklu życia produktu, zamiast działać wyłącznie na odizolowanych zbiorach danych.

Dlatego dyskusje o Product Lifecycle Intelligence stają się coraz bardziej istotne. Nie dlatego, że PLI wprowadza zupełnie nowy zestaw technologii, ale dlatego, że odzwierciedla inne oczekiwania wobec współczesnego PLM.

Przez lata sukces mierzono zdolnością do gromadzenia, kontrolowania i udostępniania informacji o produkcie. Coraz częściej będzie on mierzony w inny sposób.

• Jak szybko organizacja potrafi zrozumieć wpływ podjętej decyzji?
• Jak pewnie może ocenić ryzyko przed wprowadzeniem zmiany?
• Jak skutecznie zespoły inżynierii, produkcji i serwisu mogą pracować w oparciu o ten sam kontekst produktowy?

Te pytania definiują Product Lifecycle Intelligence znacznie lepiej niż jakakolwiek techniczna definicja.

Wartość Product Lifecycle Intelligence

Ostatecznie organizacje nie inwestują w Product Lifecycle Intelligence wyłącznie po to, aby połączyć więcej danych o produkcie. Inwestują, aby poprawić jakość i szybkość podejmowania decyzji dotyczących produktu w inżynierii, produkcji, jakości i serwisie.

Gdy kontekst produktowy jest połączony i łatwo dostępny, organizacje mogą:

• szybciej oceniać wpływ zmian inżynieryjnych,
• wykrywać problemy jakościowe, zanim doprowadzą do kosztownych awarii produktów u klientów,
• skracać czas analizy awarii dzięki możliwości śledzenia zależności w całym cyklu życia produktu,
• wcześniej identyfikować ryzyka regulacyjne i związane z dostawcami,
• tworzyć wiarygodny kontekst produktowy potrzebny do skalowania AI poza pojedyncze projekty pilotażowe.

Wartość Product Lifecycle Intelligence nie jest mierzona ilością przechowywanych informacji, ale jakością i szybkością decyzji, które umożliwia.

PLM nie traci na znaczeniu. Jego rola staje się bardziej ambitna.

Każda duża zmiana technologiczna wpływa na rolę istniejących systemów. Cloud computing nie wyeliminował ERP. Zmienił sposób, w jaki organizacje oczekiwały, że ERP będzie dostarczany. Transformacja cyfrowa nie zastąpiła PLM. Zwiększyła liczbę procesów biznesowych, które zaczęły od niego zależeć.

AI podąża podobną drogą.

Przyszłość AI w PLM będzie zależeć w mniejszym stopniu od zaawansowania modeli AI, a w większym od jakości kontekstu produktowego, do którego mają dostęp. Sama technologia rozwija się w niezwykłym tempie, ale jej długoterminowa wartość dla przemysłu będzie zależała nie tyle od możliwości poszczególnych modeli, ile od jakości wiedzy o produkcie, z której mogą korzystać.

Dlatego dyskusja stopniowo wychodzi poza funkcje AI i copiloty. Znacznie ciekawsze pytanie brzmi: czy organizacje stworzyły środowisko, w którym AI może rozumieć produkty, a nie tylko dokumenty?

Product Lifecycle Intelligence odzwierciedla właśnie tę zmianę. Nie zastępuje PLM – jest tym, w kierunku czego Product Lifecycle Management ewoluuje.

Poznaj kolejny etap rozwoju PLM

Jeżeli Twoja organizacja ma już dojrzałe środowisko PLM, ale nadal ma trudności ze skalowaniem AI poza pojedyncze zastosowania, problem może nie leżeć w samej technologii. Może wynikać ze sposobu, w jaki wiedza o produkcie jest połączona na kolejnych etapach jego cyklu życia.