PLM Carve-Outs & Mergers: Co zrobić, gdy docelowy system Windchill zawiera już dane? 

Migracja danych do nowego systemu PLM rzadko sprowadza się do prostego schematu: wyeksportować dane, przekształcić je i zaimportować do nowego środowiska. W rzeczywistości najbardziej złożone projekty rozpoczynają się właśnie tam, gdzie kończą się standardowe scenariusze migracyjne. 

Dotyczy to szczególnie projektów PLM Carve-Outs & Mergers, w których organizacje wydzielają część działalności, łączą środowiska PLM po przejęciu innej firmy lub prowadzą transformację etapami. W takich przypadkach system docelowy bardzo często nie jest pusty. Zanim rozpocznie się właściwa migracja danych, w Windchillu istnieją już biblioteki, obiekty referencyjne, struktury produktowe czy dokumentacja wykorzystywana przez zespoły inżynierskie. 

To zmienia charakter całego przedsięwzięcia. Celem przestaje być wyłącznie migracja danych. Równie ważne staje się ich poprawne połączenie z informacjami, które już funkcjonują w środowisku docelowym. 

W jednym z projektów realizowanych spółki specjalizującej się w systemach przesyłu, dystrybucji oraz zarządzania energią elektryczną dla przemysłu lotniczego i kosmicznego, właśnie z takim scenariuszem przyszło nam się zmierzyć. 

Dlaczego projekty PLM Carve-Outs & Mergers są bardziej wymagające niż standardowa migracja? 

W klasycznej migracji dane trafiają do nowego, pustego środowiska. Oczywiście również wtedy należy zadbać o poprawne odwzorowanie modeli danych, zachowanie relacji między obiektami czy historii wersjonowania, jednak ryzyko konfliktów jest stosunkowo niewielkie. 

Projekty PLM Carve-Outs & Mergers wyglądają inaczej. 

Organizacja często wdraża nowe środowisko PLM etapami. Część danych zostaje załadowana wcześniej, ponieważ biznes nie może czekać na zakończenie całej migracji. Powstają biblioteki standardowych komponentów, dane referencyjne, klasyfikacje, pierwsze produkty czy dokumentacja techniczna. Dopiero później przychodzi czas na migrację danych historycznych z poprzedniego systemu. 

W efekcie pojawiają się dwa współistniejące zbiory informacji produktowej, które muszą zostać połączone w jeden spójny model danych. 

To właśnie ten etap bardzo często okazuje się największym wyzwaniem całego projektu. 

Migracja z Oracle Agile PLM do Windchill 

Projekt obejmował migrację danych z Oracle Agile PLM do PTC Windchill. 

Prace rozpoczęły się od wspólnego zdefiniowania strategii migracji. Obejmowała ona analizę wymagań biznesowych, przygotowanie mapowania danych oraz określenie sposobu transformacji poszczególnych obiektów pomiędzy systemami. 

Za ekstrakcję danych odpowiadały skrypty przygotowane przez zewnętrznego dostawcę, natomiast ich uruchamianie realizował nasz zespół. Od początku aktywnie uczestniczyliśmy również w definiowaniu wymagań dotyczących całego procesu migracji oraz sposobu obsługi potencjalnych konfliktów danych. 

Po zakończeniu ekstrakcji rozpoczynał się etap transformacji i przygotowania danych do załadowania do Windchilla. 

To właśnie wtedy okazało się, że standardowe podejście nie będzie wystarczające. 

Gdy Windchill nie jest pustym środowiskiem 

Jeszcze przed rozpoczęciem właściwej migracji klient samodzielnie załadował do Windchilla część danych. Były to przede wszystkim obiekty biblioteczne wykorzystywane przez organizację jako elementy referencyjne. 

Choć stanowiły one jedynie niewielki procent wszystkich danych, kolejne informacje migrowane z Oracle Agile PLM miały z nich korzystać i tworzyć z nimi relacje. 

Oznaczało to, że w systemie docelowym istniały już obiekty posiadające takie same identyfikatory lub nazwy jak dane przygotowane do migracji. 

W praktyce pojawiło się pytanie, z którym mierzy się wiele organizacji realizujących projekty PLM Carve-Outs & Mergers: 

Co zrobić, gdy ten sam obiekt istnieje już w Windchillu, a jednocześnie pojawia się w migrowanym zbiorze danych? 

Dlaczego Windchill Bulk Migrator nie rozwiązywał tego problemu? 

Do migracji wykorzystaliśmy Windchill Bulk Migrator (WBM), czyli narzędzie PTC przeznaczone do obsługi dużych migracji danych. 

Jest to rozwiązanie sprawdzające się bardzo dobrze w standardowych scenariuszach. Umożliwia import nowych danych oraz wykonywanie migracji przyrostowych dla obiektów wcześniej załadowanych z wykorzystaniem WBM. 

W naszym projekcie sytuacja wyglądała jednak inaczej. 

Część obiektów znajdujących się w Windchillu została utworzona poza procesem WBM. Kolejne dane migrowane z Oracle Agile PLM musiały zostać z nimi powiązane, zachowując jednocześnie poprawne relacje, historię wersjonowania oraz integralność całego modelu danych. 

Standardowy mechanizm WBM nie został zaprojektowany z myślą o takim scenariuszu. 

Nie chodziło więc o sam import danych, ale o podjęcie decyzji, w jaki sposób połączyć dwa współistniejące zbiory informacji produktowej. 

Opracowanie własnej strategii merge 

Zamiast próbować dopasować projekt do ograniczeń standardowego narzędzia, zdecydowaliśmy się opracować własne podejście do procesu merge. 

Podczas pierwszej iteracji testowej zastosowaliśmy prostsze podejście polegające na tymczasowym przemianowaniu migrowanych obiektów. Pozwoliło to skupić się na weryfikacji pozostałych elementów procesu migracji i dostarczyć pierwszy kompletny przebieg testowy bez rozwiązywania problemu kolizji. Dopiero w kolejnej iteracji, mając już zweryfikowaną pozostałą część procesu, wspólnie z klientem zdefiniowaliśmy wymagania dotyczące obsługi kolizji i opracowaliśmy docelową logikę merge.  

Nie był to proces, który można było zamknąć w kilku prostych regułach. 

Przez blisko tydzień analizowaliśmy różne scenariusze biznesowe i techniczne, określając, jak system powinien zachować się w każdej możliwej sytuacji. 

Każda kolizja wymagała innej decyzji 

Największym wyzwaniem było zaprojektowanie logiki, która nie tylko wykrywała konflikt, ale również podejmowała właściwą decyzję dotyczącą dalszego postępowania. 

Jeżeli obiekt nie istniał jeszcze w Windchillu, był ładowany standardowo. 

Jeżeli jednak system wykrywał kolizję, proces merge analizował, który z obiektów powinien pozostać nadrzędnym źródłem informacji. 

W części przypadków to dane pochodzące z Oracle Agile PLM stanowiły najbardziej aktualną wersję produktu. W takiej sytuacji nasze rozwiązanie wyszukiwało ostatnią wersję istniejącego obiektu w Windchillu i importowało migrowane dane jako kolejne wersje tego samego elementu. Zachowywane były przy tym wszystkie relacje pomiędzy obiektami oraz ich historia. 

W innych przypadkach nadrzędnym źródłem informacji pozostawał obiekt znajdujący się już w Windchillu. Wówczas dane z migracji nie były importowane jako duplikat, natomiast wszystkie relacje prowadzące do migrowanego elementu były automatycznie przepinane na rekord istniejący w systemie. 

Dzięki temu użytkownicy końcowi otrzymywali jeden spójny model danych, zamiast dwóch konkurencyjnych wersji tego samego obiektu. 

Automatyzacja procesu migracji 

Migracja PLM to proces iteracyjny. Zanim nastąpi uruchomienie produkcyjne, wykonywanych jest wiele testowych przebiegów pozwalających zweryfikować poprawność danych, relacji oraz struktur produktowych. 

Dlatego wszystkie skrypty odpowiedzialne za transformację danych oraz proces merge zostały przygotowane przez nasz zespół i w pełni zautomatyzowane. 

Cały proces – od importu danych z plików CSV, przez transformację, rozwiązywanie kolizji i przygotowanie danych do załadowania do Windchilla – mógł zostać uruchomiony automatycznie. 

Takie podejście znacząco skróciło czas przygotowania kolejnych iteracji migracji, zapewniło powtarzalność procesu i ograniczyło ryzyko błędów wynikających z ręcznego wykonywania poszczególnych operacji. 

Bezpieczny Go-Live 

Ze względu na poufny charakter danych nasz zespół nie posiadał dostępu do produkcyjnego środowiska Windchill. Go-Live został przeprowadzony wspólnie z klientem – klient wykonywał operacje w środowisku produkcyjnym, a my na bieżąco nadzorowaliśmy cały proces, weryfikowaliśmy jego przebieg i zapewnialiśmy wsparcie techniczne. Przygotowana przez nas strategia transformacji danych, logika merge oraz mechanizmy automatyzacji zostały wykorzystane podczas finalnej migracji zgodnie z założeniami. 

Migracja danych to dopiero początek 

Realizowany projekt pokazuje, że w projektach PLM Carve-Outs & Mergers największym wyzwaniem często nie jest samo przeniesienie danych pomiędzy systemami. 

Znacznie trudniejsze okazuje się zachowanie ciągłości informacji produktowej w sytuacji, gdy nowe środowisko PLM funkcjonuje już przed zakończeniem migracji. To właśnie wtedy pojawia się konieczność inteligentnego połączenia dwóch zbiorów danych, zachowania historii wersjonowania, relacji pomiędzy obiektami oraz integralności całego modelu informacji produktowej. 

Dlatego skuteczna migracja PLM wymaga nie tylko znajomości narzędzi takich jak Windchill Bulk Migrator, ale przede wszystkim odpowiednio zaprojektowanej strategii transformacji danych. W projektach typu PLM Carve-Outs & Mergers to właśnie ona decyduje o tym, czy organizacja otrzyma spójne środowisko PLM gotowe do dalszego rozwoju, czy będzie musiała przez lata mierzyć się z konsekwencjami niespójnych danych i ręcznego usuwania problemów powstałych podczas migracji. 

Najważniejsze wnioski 

• W projektach PLM Carve-Outs & Mergers migracja danych często odbywa się do środowiska, które zawiera już obiekty wykorzystywane przez organizację. 

• Standardowe narzędzia migracyjne nie zawsze obsługują scenariusze wymagające połączenia migrowanych danych z obiektami utworzonymi wcześniej w systemie docelowym. 

• Kluczowym elementem projektu jest zdefiniowanie spójnych zasad rozwiązywania kolizji, zachowania historii wersji oraz utrzymania relacji pomiędzy obiektami. 

• Automatyzacja procesu transformacji i merge zwiększa powtarzalność kolejnych iteracji migracji, ogranicza ryzyko błędów i skraca czas przygotowania danych do załadowania. 

• Skuteczna migracja PLM nie polega wyłącznie na przeniesieniu danych – jej celem jest zapewnienie ciągłości informacji produktowej oraz stworzenie spójnego środowiska gotowego do dalszego rozwoju.