Większość użytkowników Agile PLM nie zdaje sobie sprawy, ile pracy kryje się za migracją systemu PLM. Na pierwszy rzut oka wygląda to jak zadanie czysto techniczne: wyeksportować dane, przenieść je do nowego systemu, ponownie podłączyć integracje – i gotowe. W rzeczywistości jednak transformacja Product Lifecycle Management (PLM) dotyka jednych z najważniejszych procesów w organizacji – sposobu definiowania produktów, zarządzania zmianami oraz współpracy między inżynierią, produkcją, jakością i dostawcami.

Wraz z ogłoszeniem przez Oracle zakończenia wsparcia Premier Support dla Agile PLM w grudniu 2027 roku, wiele firm zaczyna dostrzegać, że pytanie nie brzmi już tylko: jak zastąpić narzędzie. Prawdziwe wyzwanie polega na tym, jak przejść dalej bez zakłócania systemów i procesów wspierających rozwój produktu.

Dobrze przeprowadzona migracja Oracle Agile PLM to nie tylko projekt zastąpienia systemu. To także szansa na modernizację sposobu zarządzania danymi produktowymi w całej organizacji.

Co w praktyce oznacza koniec wsparcia dla użytkowników Oracle Agile PLM

W 2025 roku Oracle potwierdził, że Agile PLM osiągnie koniec wsparcia Premier Support w grudniu 2027 roku. Po tym czasie platforma nie będzie już otrzymywać aktualizacji ani poprawek bezpieczeństwa – dostępne pozostanie jedynie ograniczone wsparcie Agile PLM – utrzymaniowe.

Technicznie rzecz biorąc, system nadal będzie działał. Jednak utrzymywanie krytycznej platformy biznesowej bez wsparcia dostawcy rodzi szereg wyzwań, które z czasem narastają.

Pierwszym z nich jest bezpieczeństwo. Gdy poprawki przestają być dostarczane, nowe luki pozostają niezałatane. W środowisku PLM może to oznaczać narażenie bardzo wrażliwych danych – projektów produktów, dokumentacji inżynieryjnej, informacji o dostawcach czy danych zgodności.

Istotny jest także aspekt zgodności regulacyjnej. W wielu branżach kluczowa jest pełna identyfikowalność i audytowalność danych produktowych. Gdy system nie jest już wspierany przez producenta, podczas audytów lub certyfikacji często pojawiają się pytania.

Dochodzi do tego codzienna rzeczywistość operacyjna. Utrzymanie systemów legacy staje się coraz trudniejsze wraz z rozwojem otoczenia IT. Integracje stają się kruche, liczba modyfikacji rośnie, a zespoły wewnętrzne spędzają więcej czasu na utrzymaniu niż na rozwoju.

Dlatego dla wielu organizacji problem nie polega na tym, że Agile nagle przestanie działać po 2027 roku. Problem polega na tym, że system stopniowo staje się trudniejszy do zabezpieczenia, integracji i rozwoju.

Użytkownicy Agile patrzą szerzej niż tylko na „zamiennik 1:1”

Gdy klienci Agile zaczynają analizować opcje, Oracle naturalnie zachęca do migracji do aplikacji Oracle Fusion Cloud PLM.

Dla części organizacji może to być właściwa droga. Jednak wiele firm robi krok wstecz i zadaje szersze pytanie: skoro i tak musimy zainwestować w dużą transformację PLM, czy nie powinniśmy ponownie ocenić całego krajobrazu?

Platforma PLM to nie jest zwykły system IT. Znajduje się w centrum procesów rozwoju produktu i łączy inżynierię, produkcję, jakość oraz serwis. Migracja wpływa więc nie tylko na dane, ale także na procesy, integracje i sposób pracy.

Dlatego wiele organizacji analizuje kilka wiodących rozwiązań PLM przed podjęciem decyzji strategicznej.

Dlaczego Windchill często pojawia się w tych analizach

Jedną z platform, która często pojawia się w takich rozważaniach, jest PTC Windchill.

Od lat wykorzystywana jest w branżach o wysokim stopniu złożoności produktów i rygorystycznych procesach inżynieryjnych – takich jak lotnictwo, przemysł ciężki, motoryzacja czy zaawansowana produkcja technologiczna.

Z perspektywy użytkowników Agile kluczową różnicą jest sposób zarządzania danymi produktowymi. Środowiska Agile często opierają się na rekordach, dokumentach i workflow zatwierdzeń. Windchill podchodzi do tego inaczej – zarządzanie cyklem życia jest wbudowane bezpośrednio w strukturę i konfigurację produktu.

Takie podejście daje większą kontrolę nad ewolucją produktu w obszarach inżynierii, produkcji i serwisu.

Istotnym aspektem jest także integracja. Nowoczesne środowiska inżynieryjne wymagają spójnej wymiany danych między PLM, CAD, ERP, MES i innymi systemami. Windchill oferuje dojrzałe mechanizmy integracyjne, otwarte API oraz narzędzia niezależne od systemów CAD.

Ważna jest również elastyczność wdrożenia. W przeciwieństwie do niektórych platform działających wyłącznie w modelu SaaS, Windchill umożliwia różne strategie wdrożeniowe – w zależności od wymagań regulacyjnych, bezpieczeństwa czy infrastruktury.

Migracja Oracle Agile PLM to nie tylko przenoszenie danych

Jednym z największych mitów jest przekonanie, że migracja PLM polega głównie na przeniesieniu danych z jednej bazy do drugiej.

W praktyce najważniejsza część projektu dotyczy czegoś innego: określenia, jak nowy system ma wspierać rozwój produktu oraz zdefiniowania strategii migracji danych zgodnej z przyszłymi procesami i celami biznesowymi.

Oracle Agile i Windchill opierają się na różnych modelach koncepcyjnych. Agile jest podejściem zorientowanym na rekordy i workflow. Windchill jest z kolei systemem zorientowanym na strukturę produktu.

Z tego powodu rzadko ma sens odwzorowanie procesów Agile jeden do jednego. Zamiast tego organizacje wykorzystują migrację jako okazję do przeglądu i modernizacji procesów.

Choć początkowo może to wydawać się dodatkowym wysiłkiem, właśnie tutaj pojawia się największa wartość projektu.

Jak wygląda realny proces migracji z Oracle?

Aby zobrazować złożoność takiej transformacji, poniżej przedstawiono typowy zakres migracji z Oracle Agile PLM do Windchill.

Części i dokumenty

  • Mapowanie klas Agile na typy Windchill
  • Przypisanie kontekstów produktowych
  • Uzupełnienie brakujących atrybutów
  • Standaryzacja wersjonowania

Pliki i załączniki

  • Określenie głównej zawartości
  • Konwersja plików do obiektów dokumentów
  • Definicja zasad grupowania

Zarządzanie zmianą

  • Klasyfikacja zmian
  • Mapowanie do obiektów Windchill
  • Filtrowanie istotnych zmian

Struktury BOM

  • Zachowanie struktury i ilości
  • Uzupełnienie brakujących danych
  • Transformacja oznaczeń referencyjnych

Producenci i AML

  • Mapowanie danych producentów
  • Odtworzenie historii zmian

Relacje część–dokument

  • Reklasyfikacja relacji
  • Rozróżnienie dokumentów opisowych i referencyjnych

Efekt:

Sukces migracji zależy nie tylko od transferu danych, ale od ich właściwego odwzorowania, oczyszczenia i transformacji.

Migracja jako szansa na uproszczenie środowiska systemowego

W wielu firmach Agile PLM nie funkcjonuje w izolacji. Z czasem pojawiają się dodatkowe systemy do zarządzania CAD, produkcją, dostawcami czy dokumentacją.

Często prowadzi to do wzrostu złożoności i kosztów utrzymania.

Migracja Oracle Agile PLM do nowoczesnego PLM daje szansę na uproszczenie tego krajobrazu i konsolidację danych produktowych w jednym środowisku.

Efektem jest spójniejsza „kręgosłupowa” struktura danych oraz solidna podstawa dla tzw. Digital Thread.

Zaplanuj sprawną migrację Oracle Agile PLM

Zobacz, jak TT PSC może pomóc

Więcej

Dlaczego warto zacząć wcześniej – co dalej dla użytkowników Oracle Agile PLM?

Choć 2027 rok może wydawać się odległy, projekty PLM rzadko są krótkie. Zwykle trwają od 12 do 24 miesięcy.

Firmy, które zaczynają wcześniej, mają czas na analizę opcji i kontrolowane wdrożenie.

Te, które zwlekają, często podejmują decyzje pod presją czasu.

Podsumowując

Koniec wsparcia dla Oracle Agile PLM to ważny moment, ale nie musi oznaczać kryzysu.

Dla wielu organizacji to okazja, by przemyśleć, jak zarządzać danymi produktowymi w całym cyklu życia.

Pozostanie przy niewspieranym systemie zwiększa ryzyko operacyjne i bezpieczeństwa. Migracja Oracle Agile PLM do nowoczesnej platformy daje natomiast szansę na lepsze zarządzanie, współpracę i rozwój.

Kluczem jest odpowiednio wczesne podejście do transformacji – nie jako czysto technicznej migracji, ale jako strategicznej ewolucji roli PLM w organizacji.