Producenci oprogramowania do zarządzania cyklem życia produktu (ang. Product Lifecycle Management, PLM) obiecują, że ich systemy okażą się tak wspaniałe, że będą mogły być używane przez organizacje natychmiast po ich zainstalowaniu, rewolucjonizując sposób definiowania i zarządzania danymi produktów. Dotyczy to jednak tylko tych organizacji, które chcą dostosować swoje własne wewnętrzne standardy i procedury do uprzednio wdrożonych najlepszych praktyk zaimplementowanych w systemach PLM. Wszyscy inni muszą zdać się na konfigurację, personalizację i szersze dostosowanie produktu. Jaka jest różnica pomiędzy tymi rozwiązaniami i jak upewnić się, że nie staną się wadą w przyszłości?
OOTB
OOTB, czyli „out-of-the-box” (ang. „wprost z pudełka”), to zestaw funkcji dostępnych dla użytkowników bezpośrednio po zainstalowaniu systemu. W przypadku systemu PLM, OOTB oznacza grupę wstępnie zdefiniowanych elementów, np.:
- standardowy interfejs użytkownika, z możliwością przeglądania i wyszukiwania
- model danych (typy obiektów, ich atrybuty/parametry)
- cykle życia
- organizacja pracy
- szablony obiektów (wraz z szablonami produktów, zawierającymi definicje ról, kontrola dostępu, itp.)
Szczególnie w przypadku większych i bardziej złożonych systemów PLM, takich jak PTC Windchill, są one tworzone w oparciu o określone standardy przemysłowe i najlepsze praktyki. Zdefiniowane zostały wspólnie przez ich twórców i najwybitniejsze umysły z najlepszych uczelni świata, ale także rzeczywistych klientów za sprawą wieloletniego użytkowania systemu i praktycznego doświadczenia. Niektóre elementy, które początkowo uważano za niestandardowe, stopniowo trafiły do podstawowego produktu, stając się częścią rozwiązania „OOTB”.
Większość producentów oprogramowania szczyci się tym, że ich produkty „out-of-the-box” są gotowe do podjęcia każdego wyzwania w każdej firmie, ale bardzo niewielu z nich dotrzymuje słowa. Przykładowo: pakiet oprogramowania biurowego, w tym edytor tekstu, arkusz kalkulacyjny, program do tworzenia prezentacji, itp. będą działać podobnie niezależnie od tego, kto je wykonał (OK, będą pewne różnice w interfejsie użytkownika (UI) lub rodzajach animacji, których można używać, ale ogólne „odczucie” jest takie samo).
W przypadku PLM nie istnieje jednak uniwersalne rozwiązanie. Jest bardzo mało prawdopodobne, aby system OOTB (z j. ang. „vanilla” – „waniliowy” oznacza system w wersji dostarczonej przez producenta, bez żadnych modyfikacji) mógł być efektywnie wykorzystany w dosłownie dowolnej organizacji. Szczególnie większe i/lub starsze firmy mają swoje wypracowane metodyki pracy, które okazały się skuteczne i nie powinny być zmieniane pod kątem dopasowania do systemu – raczej system powinien być zmieniany w kierunku tych metodyk. To, jakie dane i metadane uważamy za ważne i które decydujemy się przechowywać w systemie PLM, zmienia się również między organizacjami, podobnie jak przypisane do nich role i reguły kontroli dostępu. Te i wiele innych rzeczy zazwyczaj trzeba zmienić w „waniliowym” systemie PLM, zanim stanie się on naprawdę użyteczny dla organizacji, i tu właśnie zaczyna się konfiguracja i personalizacja (dostosowywanie, lub „customization”[1]).
Mimo, że te dwa terminy („configuration” – „customization”) brzmią podobnie (w szczególności w j. angielskim), w rzeczywistości różnią się one dość mocno znaczeniem. Zacznijmy od wyjaśnienia, czym są te dwa pojęcia – najprościej jak to możliwe.
[1] Często spolszczane jako „customizacja” (czyt. „kustomizacja”). Proszę uprzejmie o wybaczenie tego „makaronizmu” kompletnie niszczącego reguły języka polskiego. Nie znam dobrego odpowiednika tego słowa w naszym języku ojczystym, a ani „personalizacja”, ani „dostosowywanie” w pełni nie oddają jego znaczenia.
Czym jest konfiguracja?
Konfiguracja (w systemie PLM) obejmuje wszystkie zmiany, jakie można wprowadzić w produkcie z punktu widzenia interfejsu użytkownika. Dostawcy PLM zazwyczaj posiadają narzędzia konfiguracyjne, które pozwalają na zmianę sposobu działania systemu w ograniczonym stopniu. Obejmuje to między innymi takie elementy jak:
- Zmiany w modelu danych, w tym definiowanie nowych typów obiektów i opisujących je atrybutów
- Określenie cyklów życia i ich stanów
- (Częściowo) określenie przepływów pracy
- Definicja szablonów obiektów (Produkt, Biblioteka, itp.) – w tym określenie ról w kontenerach i zasad kontroli dostępu
- Zarządzanie działaniem systemu za pomocą ustawień
Zdarza się również, że niektórzy traktują możliwość modyfikacji wartości pewnych ustawień systemowych (w przypadku Windchill: zmiana otwartych wartości tekstowych wewnątrz plików .property) jako konfigurację, ale dla jasności tego artykułu – nie zaliczajmy tego na razie do tej kategorii.
Innymi słowy, konfiguracja to modyfikacja systemu, która nie wymaga dostępu, modyfikacji, implementacji, itp. kodu źródłowego systemu[2]. Z tego powodu wiele osób uznaje również możliwość konfiguracji oprogramowania (a tym samym samej konfiguracji) za integralną część funkcjonalności OOTB.
Konfiguracje są zazwyczaj obsługiwane pomiędzy wersjami systemu, więc jeśli aktualizujesz swój PLM, zazwyczaj nie musisz się martwić o aktualizację konfiguracji, aby dopasować ją do nowszej wersji.
[2] Tak, skonfigurowane element zazwyczaj można wyeksportować z systemu (w celu zaimportowania ich na innej instancji) i wówczas przyjmuje to formę pliku XML, lub innego formatu, który może zawierać kod, natomiast zazwyczaj nie trzeba takiego kodu „dotykać”, tj. zmieniać go z użyciem edytora tekstu. Najczęściej po prostu „eksportujemy” i „importujemy” takie pliki, bez zaglądania do środka.
Co to jest personalizacja („customizacja”)?
Personalizacja (dostosowanie, „customizacja”) to z kolei wszystko co znajduje się poza konfiguracją. Personalizacja w tym rozumieniu to każda zmiana systemowa, która wymaga modyfikacji lub rozszerzenia kodu źródłowego systemu (tj. implementacji, kodowania), ponieważ pożądany rezultat nie jest możliwy do osiągnięcia wyłącznie poprzez konfigurację. W większości przypadków przykłady modyfikacji obejmują:
- Wyzwalacze (ang. trigger), które uruchamiają pewną akcję/zachowanie systemu w przypadku wystąpienia danego zdarzenia, np. automatyczne publikowanie po zakończeniu Change Notice, itp.)
- Nowe akcje i kreatory dla użytkowników
- Przepływy pracy (ang. workflows) (niektóre przypadki) – Windchill pozwala na pisanie kodu w edytorze przepływów pracy, więc jeśli chcesz wykonać jakieś niestandardowe operacje podczas uruchamiania przepływu pracy – możesz to zrobić
- Integracje systemowe – niestety, prawie wszystkie integracje systemowe dla PLM są niestandardowe
- Niektóre przypadki dotyczące zaawansowanego raportowania
- Różnego rodzaju wdrożenia dodatkowych reguł biznesowych, według których zmienia się zachowanie systemu
Nie wyczerpuje to jednak listy możliwych modyfikacji. Podczas niemal 10 lat pracy z Windchillem zaobserwowałem wiele rzeczy, które ludzie robią z tym systemem. Tych, których jeszcze nie widziałem, jest jeszcze więcej…
Systemy dla firm, w tym PLM, mają zazwyczaj własny cykl życia i są od czasu do czasu aktualizowane przez swoich producentów. PTC Windchill nie jest tu wyjątkiem: ma szczegółowy plan rozwoju na kilka lat do przodu. Aktualizując system do nowszej wersji, nigdy nie należy zakładać, że modyfikacje będą działać prawidłowo. Producenci systemów wprowadzają ulepszenia, zmiany, etc. do swoich podstawowych produktów, co może sprawić, że niektóre modyfikacje staną się zbędne, ale także część z nich może dotyczyć fragmentów kodu, który w nowej wersji nie istnieje (lub nie działa tak jak wcześniej) w podstawowym produkcie – co może spowodować różnego rodzaju problemy w działaniu systemu. Każda aktualizacja systemu z uwzględnieniem istniejących modyfikacji i konfiguracji powinna uwzględniać konieczność zweryfikowania ich zgodności z nową wersją i (jeśli to konieczne) ich aktualizacji. Dla porównania, aktualizacja systemu „waniliowego” może czasami zostać ukończona w ciągu kilku godzin. W przypadku skomplikowanych i obszernych modyfikacji może to być miesiąc, a nawet rok i więcej (tak, widziałem takie przypadki).
Jaka jest różnica między konfiguracją a „customizacją”?
Na pierwszy rzut oka główna różnica pomiędzy konfiguracją a personalizacją polega na tym, że pierwszą z nich można zazwyczaj wykonać za pomocą interfejsu systemowego, podczas gdy druga wymaga od programistów zakodowania nowej/zmienionej funkcjonalności. Niestety, nie jest to takie proste.
Konfiguracja, nawet jeśli została wyeksportowana do zbioru plików (w celu wykorzystania w innym systemie), jest zazwyczaj stosunkowo łatwa do zarządzania: Wystarczy śledzić listę dokonanych zmian i nigdy nie modyfikować ręcznie wyeksportowanych plików[3].
„Customizacja”, jak w przypadku większości spraw związanych z programowaniem, może być (i zazwyczaj jest) znacznie bardziej złożona i powinna być odpowiednio przeprowadzona. W przeciwnym razie wdrożenie jej spowoduje, że system będzie pełen błędów i usterek, a nawet nie uruchomi się w ogóle (!), czyniąc go bezużytecznym i powodując tym samym dużą stratę czasu i pieniędzy.
[3] Tak byłoby w idealnym świecie. W świecie rzeczywistym czasami trzeba zmodyfikować pliki konfiguracyjne, którymi są zazwyczaj pliki XML. Nie wpływa to jednak na kod głównej aplikacji.
Skąd mam wiedzieć, czy „customizacja” jest potrzebna?
Żaden system ani oprogramowanie nie jest w stanie zapewnić idealnej obsługi wszystkich klientów we wszystkich gałęziach przemysłu. W wielu przypadkach modyfikacja będzie rzeczywiście nieunikniona. Nawet tak częste działanie, jak dostarczanie informacji z PLM do systemu ERP na etapie przekazania projektu z działu inżynieryjnego do działu produkcji będzie wymagać modyfikacji w postaci integracji systemu.
Jako klient systemu PLM nie musisz znać wszystkich systemów PTC Windchill, Siemens Teamcenter i wszelkich innych, ani zasad ich „customizowania”. Próba poznania wszystkich tych skomplikowanych (lecz ważnych) elementów może zająć lata, których Twoja organizacja może nie mieć.
Dlatego powinieneś zdać się na dwie rzeczy:
- Dostawcę systemu – w końcu każdy, kto tworzy system powinien znać go najlepiej (zakładając, że jego przedstawiciele zgodnie z prawdą opisują to, co system może, a czego nie może robić OOTB i poprzez konfigurację)
- niezależnego partnera, Integratora Systemów, Autoryzowanego Dystrybutora, itp. – jak np. Transition Technologies PSC – który pomoże Ci ocenić Twoje potrzeby i określić, co może system.
Partner powinien być Twoim największym sojusznikiem przy wdrażaniu systemu PLM. Przez lata współpracy z innymi klientami, powinien posiąść dogłębną wiedzę na temat narzędzi, z którymi pracuje. Potrafi stwierdzić, czy system może działać tak, jak sobie tego życzysz, ale także potencjalnie doradzić, czy rzeczywiście warto porzucić jego „pudełkową” funkcjonalność na rzecz opracowania własnej.
Jak zarządzać personalizacją?
Tworzenie oprogramowania i operacje systemowe, często określane jako DevOps (często używany skrót z j. ang. oznaczający Software Development and System Operations), mogą być dość złożonym zagadnieniem – również dla systemów zarządzania cyklem życia produktu. Gdybym zagłębił się tutaj w szczegóły, przerodziłoby się to w cały artykuł o najlepszych praktykach DevOps dla PLM, więc ograniczę się tutaj tylko do niezbędnych szczegółów:
- Użyj systemu kontroli wersji dla kodu źródłowego (najlepiej Git lub jego odpowiednik)
- Użyj systemu takiego jak Atlassian Jira lub PTC Windchill RV&S (dawniej Integrity) jako system zarządzania cyklem życia aplikacji (ang. Application Lifecycle Management, ALM), aby śledzić postępy w rozwoju, zadania, problemy, tzw. „historie użytkowników”, sprinty itp.
- Ściśle zintegruj powyższe systemy, tak aby nikt nie mógł nic zmienić w repozytorium, jeśli nie pracuje nad konkretnym zadaniem.
- Używaj testów automatycznych dla każdego niestandardowego kawałka kodu (przynajmniej testów jednostkowych).
- Korzystaj z automatycznego tworzenia środowisk (jeśli to możliwe – znacznie upraszcza i redukuje nakład pracy i czas niezbędny do ich stworzenia) oraz wykorzystuj narzędzia automatyzacji, jak np. Jenkins.
- Ściśle zintegruj narzędzia automatyzacji z testami, kodem źródłowym i systemem ALM.
- Korzystaj z wielu środowisk walidacyjnych (na przykład: zespół programistyczny pracuje na systemie Dev, testerzy testują na systemie testowym, testowanie akceptacji użytkownika końcowego odbywa się na systemie QA – i wreszcie, nic nie jest zmieniane na środowisku produkcyjnym, chyba że jest częścią oficjalnego harmonogramu publikacji, a każda zmiana jest monitorowana, zarządzana i wielokrotnie sprawdzona)
Mogę się założyć, że jeśli system ma „customizację”, to posiada również konfigurację. W tym przypadku konfiguracja, raz wyeksportowana z systemu, powinna być również zarządzana w ramach powyższego procesu – dzięki temu całe wdrożenie systemu będzie spójne i płynne, a wszelkie problemy zostaną wykryte i rozwiązane na wczesnym etapie.
Oczywiście, powyższy proces jest uproszczony… i to znacznie. Mimo to (a może właśnie z tego powodu) niektóre organizacje decydują się nie trzymać się go kurczowo i podejmują duże ryzyko przy opracowywaniu własnych modyfikacji PLM. Z tego co widziałem, zawsze kończy się to katastrofą[4], więc jeśli chcesz uniknąć udziału w tej katastrofie, upewnij się, że Twój dostawca usług PLM stosuje odpowiednie techniki DevOps zanim będzie za późno.
[4] Tak, zawsze. Prędzej czy później, ale zawsze.
Konfiguracja a personalizacja
Po tym, co dotychczas przeczytałeś, możesz pomyśleć, że chcesz uniknąć wszelkiego rodzaju modyfikacji: są one często skomplikowane, ryzykowne i kosztowne. To w dużej mierze prawda: to, co można osiągnąć za pomocą produktu OOTB z pewnymi (nawet wieloma) elementami konfiguracji, powinno być zrobione w ten właśnie sposób. Ostatecznie, większość dostawców PLM stara się zapewnić jak największą elastyczność swoich produktów i rozwiązań, tak aby nie trzeba było ich konfigurować.
Pamiętaj jednak, że nawet najlepszy system PLM nie będzie miał wszystkich funkcji działających dokładnie tak, jak byś tego chciał, a tym samym będzie wymagał pewnych modyfikacji. Jeśli sprzedawca PLM kiedykolwiek spróbuje Cię przekonać, że jego produkt PLM będzie idealnie pasował do Twojego (i każdego innego biznesu) od samego momentu instalacji, pokaż mu, gdzie są drzwi.
Czy istnieje coś takiego jak zbyt duża personalizacja?
Widziałem projekty z kilkunastoma tysiącami niestandardowych klas, od kilkudziesięciu do wielu tysięcy linii kodu każda. Było to wykonalne, ale z trudem. Zarządzanie zależnościami pomiędzy różnymi pakietami powoli stawało się koszmarem, a próby rozwiązania problemów związanych ze zmianą wymagań i fragmentu kodu opracowanego przez konkretną osobę było prawie niemożliwe. Testowanie i naprawa błędów w rozwiązaniu trwało tygodniami, jeśli nie miesiącami, przed każdym kolejnym wdrożeniem nowej wersji customizacji.
Potem pojawiły się aktualizacje systemu zmieniające główny kod systemu, który został ”scustomizowany”…
(Nie trzeba dodawać, że wszelkie nadzieje na unowocześnienie tego systemu przed jego całkowitą „decustomizacją” [czyli usunięciem modyfikacji] zostały porzucone).
Obecnie producenci wypuszczają nowe wersje systemów częściej niż dotychczas. Podobnie jak w przypadku produktów fizycznych, tak też w przypadku oprogramowania cykle życia produktów również skróciły się do tego stopnia, że niektóre wersje są w pełni wspierane przez zaledwie kilka miesięcy. Klienci muszą zatem zdecydować, czy chcą korzystać z najnowszych funkcji (i często je aktualizować), czy zainstalować wersję z długoterminowym wsparciem technicznym (ang. Long Term Support, LTS). Oczywiście, im częstsze będą aktualizacje, tym więcej czasu trzeba będzie poświęcić na upewnienie się, że konfiguracja i (szczególnie) „customizacja” będą nadal funkcjonować zgodnie z oczekiwaniami.
Nie wszystko jest jednak stracone, jeśli rzeczywiście musisz mocno zmodyfikować swój system PLM. Istnieje sposób na zarządzanie i utrzymanie nawet rozbudowanych i złożonych modyfikacji: DevOps. Koncepcja ta, jeśli zostanie prawidłowo wdrożona, znacznie upraszcza wiele procesów i pomaga utrzymać wysoką jakość rozwiązania nawet w przypadku wprowadzenia istotnych modyfikacji. Nie rozwiązuje ona wszystkich problemów, ale pomaga. Bardzo pomaga.
Czy mogę spersonalizować system PLM oparty na chmurze?
I tak i nie. Pozwól, że wyjaśnię:
Jeśli zdecydujesz się na zakup systemu PLM w ramach oferty SaaS (Software as a Service), wówczas dostawca systemu zajmie się wszystkimi „zakulisowymi” pracami: konfiguracją serwerów, instalacją i utrzymaniem systemu, przeprowadzeniem aktualizacji, itp. Niestety, Ty jako klient rzadko (jeśli w ogóle) będziesz miał dostęp do samego systemu operacyjnego (ang. Operating System, OS), na którym działa aplikacja PLM. Ponieważ nie masz dostępu do OS, nie będziesz mógł wdrożyć swoich własnych klas / kodu. Będziesz musiał polegać na dostawcy SaaS przy wdrażaniu wszelkich zmian. Niektórzy dostawcy stosują długotrwałe i uciążliwe procesy w celu wdrożenia nawet najmniejszej zmiany, więc ostrożnie wybierz swojego partnera i zapytaj go o procedurę wdrożeniową.
Możesz również zakupić „zwykłą” licencję PLM i utrzymywać system we „własnym” środowisku chmurowym. W tym przypadku będziesz zobowiązany do stworzenia odpowiedniej (wirtualnej) infrastruktury, instalacji i utrzymania systemu, ale ponieważ jesteś „właścicielem” infrastruktury w chmurze, możesz robić z nią co tylko chcesz – włącznie z dostosowywaniem jej i zainstalowanych w niej systemów do własnych potrzeb (Gentherm – success story).
To drugie podejście wymaga znacznie większego wysiłku, nie wspominając już o dogłębnej znajomości rozwiązań chmurowych, zwłaszcza jeśli chcemy osiągnąć satysfakcjonujący poziom automatyzacji. Na szczęście właśnie w tym zakresie możesz polegać na swoim partnerze PLM, który chętnie Ci w tym pomoże. Przekonaj się sam jak osiągnąć automatyzację na poziomie SaaS (lub wyższym!) i zachować spokój ducha, wykorzystując publiczną chmurę obliczeniową do obsługi systemu Windchill, bazując na rzeczywistym przykładzie z branży motoryzacyjnej:
Wnioski
Wprawdzie można by powiedzieć, że należy za wszelką cenę unikać ”customizacji”, jednak w świecie PLM nie ma uniwersalnego rozwiązania. Podczas gdy niektóre organizacje mogą rzeczywiście czerpać korzyści ze stosowania „pudełkowego” systemu PLM, trudno oczekiwać, że wiele z nich zrezygnuje ze swoich reguł i metodyki pracy – czyli z rzeczy, które uczyniły te firmy tak świetnymi, jakimi są. O ile prawdą jest, że należy dążyć do zminimalizowania konieczności modyfikacji, o tyle nawet duże systemy mogą być efektywnie zarządzane, jeśli zastosowany zostanie odpowiedni proces. Ostatecznie podjęcie decyzji o wyborze konfiguracji lub „customizacji” (a nawet konkretnego produktu PLM) powinno być świadomą decyzją opartą na rzeczywistych potrzebach i wymaganiach organizacji – w najlepszym przypadku popartą szeroką wiedzą i doświadczeniem zaufanego partnera, który może później zrealizować ten plan. Napisz do nas.