Wybór partnera do wdrożenia AI w środowisku PTC Windchill wymaga potwierdzenia zarówno kompetencji w realizacji projektów PLM, jak i doświadczenia we wdrażaniu sztucznej inteligencji. Firmy produkcyjne muszą wiedzieć, w jaki sposób proponowane rozwiązanie wykorzysta nadzorowane dane produktowe, będzie współpracować z różnymi systemami inżynierskimi oraz wesprze podejmowanie decyzji, za które nadal odpowiadają inżynierowie.
TT PSC, firma wymieniona przez PTC w gronie Global System Integrators, opublikowała referencje projektowe dotyczące migracji do Windchill w Liebherr oraz integracji środowiska inżynierskiego w Schaeffler. Wraz z opisem ProductAscentAI przygotowanym przez PTC przykłady te stanowią praktyczny punkt wyjścia do oceny kompetencji, jakich producenci powinni oczekiwać od partnera.
Czego potrzebuje środowisko inżynierskie, aby AI przynosiła rzeczywistą wartość
Wyobraźmy sobie inżyniera oceniającego proponowaną zmianę komponentu. Istotne informacje mogą obejmować konkretną rewizję komponentu, jego konfigurację produktową, powiązane wymagania i dowody weryfikacji. Zanim inżynier oceni analizę wygenerowaną przez AI, musi wiedzieć, które źródła zostały w niej uwzględnione i gdzie brakuje pełnych danych potwierdzających wnioski.
Partner wdrożeniowy powinien umieć wyjaśnić, w jaki sposób ten kontekst trafia do aplikacji AI. Który system jest źródłem wiążących informacji? Jak rozstrzygane są sprzeczności między rekordami? W jaki sposób rozwiązanie respektuje uprawnienia dostępu użytkowników? Takie pytania pozwalają przejść od ogólnej rozmowy o możliwościach AI do oceny konkretnego procesu inżynierskiego.
Wyznaczają również granice rozwiązania. Jeśli w połączonych systemach brakuje informacji, proces musi umożliwiać wykrycie luki i przekazanie jej do wyjaśnienia odpowiedzialnemu inżynierowi.
Jak rozróżnić możliwości AI oferowane przez PTC od dodatkowych prac rozwojowych
Oferta powinna jasno wskazywać, które funkcje zapewniają produkty PTC, a które wymagają konfiguracji, integracji lub dodatkowego rozwoju. Według PTC Windchill AI Assistant umożliwia dostęp do wiedzy zawartej w dokumentach przy użyciu języka naturalnego oraz tworzenie podsumowań, z odwołaniami do źródeł i egzekwowaniem uprawnień dostępu.
Proces obejmujący kilka systemów inżynierskich wymaga osobnej oceny niezbędnych informacji i połączeń. Przykładowo przegląd wymagań i przygotowanie propozycji architektury mogą angażować, obok Windchill, narzędzia ALM lub inżynierii systemów. Partner powinien określić, gdzie realizowane jest każde zadanie i jak zweryfikowane wyniki trafiają do odpowiednich procesów inżynierskich.
W opisie ProductAscentAI przygotowanym przez PTC TT PSC odpowiada za ocenę gotowości danych, konsolidację PLM tam, gdzie jest potrzebna, wdrażanie rozwiązań AI firmy PTC oraz łączenie agentów dostosowanych do potrzeb klienta z istniejącą infrastrukturą. Takie rozróżnienie pomaga producentowi ocenić zakres wdrożenia i ustalić, kto będzie utrzymywać poszczególne elementy rozwiązania.
Poproś potencjalnych partnerów o udokumentowanie zależności od wersji produktów, sposobu wdrożenia i licencjonowania, a także kosztów oraz odpowiedzialności za ewentualne dodatkowe komponenty.
Co projekty TT PSC mówią o gotowości do wdrożenia AI
Przygotowanie danych produktowych w Liebherr
Opis projektu TT PSC dla Liebherr przedstawia migracje do Windchill PLM przeprowadzone w ponad 14 lokalizacjach, w ramach ponad 10 podprojektów. Prace obejmowały normalizację, synchronizację i korygowanie danych pochodzących z różnych systemów źródłowych oraz dostosowanie Windchill w obszarach zarządzania zmianą, danych CAD i zestawień materiałowych (BOM).
To doświadczenie ma znaczenie, gdy zastosowanie AI opiera się na informacjach pochodzących z wielu źródeł. Zanim AI zacznie je interpretować, zespół wdrożeniowy musi zapewnić spójność rekordów i relacji wymaganych przez wybrany proces. Referencja Liebherr potwierdza doświadczenie w realizacji migracji PLM i przygotowaniu danych.
Łączenie informacji inżynierskich w Schaeffler
Opis projektu Schaeffler przedstawia opracowane przez TT PSC rozwiązania Digital Thread zorientowane na procesy i oparte na technologiach PTC. Wspierają one identyfikowalność informacji między systemami, przejrzystość oraz dostęp do danych zgodny z rolami użytkowników.
Przy wyborze partnera AI kluczową kompetencją jest umiejętność łączenia informacji inżynierskich bez utraty ich kontekstu. Producent może wykorzystać tę referencję do rozmowy o zaangażowanych systemach, utrzymywanych między nimi powiązaniach oraz zakresie odpowiedzialności TT PSC podczas realizacji projektu. Pozwala to ocenić, na ile to doświadczenie odpowiada własnemu środowisku firmy.
Wsparcie analizy wymagań i architektury przez AI
Framework AI opracowany przez TT PSC analizuje wymagania i specyfikacje, proponując podział funkcjonalny, potencjalne bloki systemowe i interfejsy do oceny przez inżynierów. W artykule o ProductAscentAI PTC informuje o ograniczeniu nakładu pracy na analizę wymagań i architektury we wczesnej fazie o 60–80% w jednym z projektów wykorzystujących opisane podejście. Inżynierowie sprawdzają i zatwierdzają wygenerowane propozycje.
Zgłoszona poprawa dotyczy właśnie tego etapu analizy. Porównywalny pilotaż powinien mieć własny punkt odniesienia, a ocena wyników musi uwzględniać czas potrzebny na przegląd inżynierski i poprawki.
Jak określić niezbędny zakres modernizacji PLM
Zakres modernizacji powinien wynikać z potrzeb wybranego przypadku użycia. Ocena gotowości powinna ustalić, czy obecne środowisko Windchill udostępnia wymagane informacje i mechanizmy dostępu, oraz zidentyfikować konkretne luki.
Poproś partnera o uzasadnienie każdej proponowanej zmiany. Szerszy program konsolidacji może być uzasadniony, gdy rozproszone systemy uniemożliwiają spójny dostęp do potrzebnych informacji produktowych. Węższy proces może wymagać jedynie ukierunkowanego przygotowania danych lub integracji. Każda rekomendowana inwestycja powinna wynikać ze zidentyfikowanego ograniczenia i prowadzić do oczekiwanej poprawy.
W przypadku wdrożenia obejmującego europejskie lokalizacje należy również ustalić, czy proponowany model realizacji odpowiada potrzebom poszczególnych zakładów lub biur. Potwierdź języki robocze, miejsca przetwarzania danych, zasady dostępu i odpowiedzialność za wsparcie po uruchomieniu rozwiązania.
Testowanie proponowanego rozwiązania na rzeczywistym zadaniu inżynierskim
Poproś każdego partnera z krótkiej listy o pokazanie reprezentatywnego procesu na uzgodnionym zestawie dokumentów i ról użytkowników. Uwzględnij sytuacje, które w codziennej pracy mogłyby prowadzić do niepełnej lub mylącej odpowiedzi.
| Sytuacja testowa | Co powinna wykazać demonstracja |
| Dokumenty zawierają sprzeczne informacje | Czy rozwiązanie wykrywa sprzeczność, wskazuje źródła i przekazuje nierozstrzygnięte kwestie do przeglądu inżynierskiego. |
| Użytkownik nie ma dostępu do części dokumentacji | Jak ograniczenia dostępu wpływają na wyszukiwanie i wygenerowaną odpowiedź, w tym odwołania do źródeł oraz podsumowania. |
| Dostępne informacje nie pozwalają udzielić odpowiedzi | Jak rozwiązanie sygnalizuje brak wystarczających dowodów i unika przedstawiania niepotwierdzonego wniosku jako faktu. |
| Zadanie zależy od konkretnej rewizji lub konfiguracji | Jak proces wybiera właściwe informacje i pokazuje ten wybór inżynierowi przeprowadzającemu weryfikację. |
Są to proponowane testy akceptacyjne. Sposób ich realizacji będzie zależał od wybranych produktów i architektury. Demonstracja powinna wyjaśniać, jak każde wymaganie zostanie spełnione w środowisku danego producenta.
Jak mierzyć wyniki pilotażu przed skalowaniem rozwiązania
Przed rozpoczęciem prac ustal punkt odniesienia i kryteria akceptacji. W analizie wymagań mierz czas przygotowania wyniku nadającego się do weryfikacji, odsetek ustaleń zaakceptowanych przez inżynierów oraz nakład pracy potrzebny na korekty. W wyszukiwaniu informacji oceniaj trafność odpowiedzi i adekwatność źródeł, a także czas wyszukiwania.
Wykorzystuj reprezentatywne zadania, także te trudniejsze. Szybsze przygotowanie wyników ma niewielką wartość, jeśli osoby dokonujące przeglądu poświęcają zaoszczędzony czas na usuwanie błędów. Ocena powinna zatem obejmować całe zadanie, włącznie z weryfikacją przez człowieka, i dokumentować sposób postępowania w razie niepowodzeń.
Pilotaż powinien także określić odpowiedzialność za działanie rozwiązania. Ustal, kto zatwierdza wyniki inżynierskie, kto monitoruje rozwiązanie i kto utrzymuje integracje w miarę rozwoju systemów źródłowych. Daje to producentowi podstawę do oceny zarówno zmierzonej poprawy, jak i bieżących kosztów użytkowania rozwiązania.