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, 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.:
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.
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:
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.
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ą:
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).
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.
Ż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ć.
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.
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:
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.
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.
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.
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.
Poznaj znaczenie eco-designu dla biznesu i środowiska. Dowiedz się, jak zasady eco-designu, od redukcji materiałów po recykling, zwiększają zrównoważony rozwój, obniżają koszty oraz pomagają w spełnieniu regulacji, dając przewagę konkurencyjną na dzisiejszym rynku.
Odkryj, jak zarządzanie wariantami rewolucjonizuje projektowanie produktów w PLM. Nasz najnowszy artykuł zgłębia, w jaki sposób modułowe podejście do projektowania i produkcji może przekształcić procesy biznesowe, oferując przewagę konkurencyjną i ulepszając zarządzanie danymi. Poznaj kluczowe korzyści, wyzwania i strategie wdrażania zarządzania wariantami, aby maksymalizować efektywność i innowacyjność w Twojej firmie. Przygotuj się na nową erę w inżynierii i zarządzaniu produktami!
Optymalizacja procesów produkcji samochodów i zarządzanie złożonymi łańcuchami dostaw stanowią wyzwania, przed którymi stoi współczesny przemysł motoryzacyjny. W miarę jak sektor ten rozwija się, producenci samochodów poszukują bardziej efektywnych i elastycznych rozwiązań, aby pozostać konkurencyjnymi na dynamicznie zmieniającym się rynku. W obliczu rosnącej cyfryzacji oraz wprowadzania zasad Przemysłu 4.0, producenci samochodów poszukują i testują innowacyjne […]
Zrównoważone projektowanie produktów to podejście, które uwzględnia aspekty środowiskowe i ekonomiczne na każdym etapie cyklu życia produktu. Zrównoważony rozwój oraz wpływ na środowisko stały się czwartym kluczowym wskaźnikiem efektywności (KPI) w procesie tworzenia produktów, obok tradycyjnych miar, takich jak czas, koszt i jakość. Wpływ na środowisko naturalne – projektowanie dla zrównoważonego rozwoju Przyjęcie ram projektowania […]
Projektowanie z myślą o zrównoważonym cyklu życia to nie tylko koncepcja, ale konieczność w dzisiejszym świadomym ekologicznie świecie. Przyjmując praktyki zgodne z dyrektywą EcoDesign, wykorzystując Cyfrowe Paszporty Produktów i stosując technologie takie jak CCS, branże mogą znacznie zmniejszyć swój wpływ na środowisko. Przy wsparciu rozwiązania GreenPLM, firmy mogą płynnie zintegrować te praktyki ze swoimi działaniami, torując drogę do zrównoważonej i zyskownej przyszłości.
Chmura coraz częściej stanowi kluczowy aspekt powodzenia procesu transformacji cyfrowej. Rozmowa z Christianem Thiem, starszym analitykiem biznesowym w TT PSC Germany GmbH, dostarczy odpowiedzi na pytania: co należy uwzględnić w harmonogramie migracji do chmury oraz jak przygotować organizację do jej wdrożenia?
Digital Thread zapewnia ponadsystemową przejrzystość danych i informacji w całym cyklu życia produktu. Łączenie w sieć wszystkich systemów biorących udział w projekcie.
Zarządzenie cyklem życia produktu (PLM) nie jest koncepcją nową, w rzeczywistości istnieje od czasu, kiedy ludzie zaczęli wytwarzać rzeczy. Jednakże dzisiaj PLM nabiera innego znaczenia.
Zarządzanie cyklem życia produktu nigdy nie było tak ważne, jak teraz, w coraz bardziej zmieniającym się świecie. Dziś nie wystarczy już świetny pomysł, czy nawet dobra realizacja. Obecnie potrzebna jest pełna kontrola nad produktem – od koncepcji, przez projektowanie i produkcję, aż po obsługę serwisową oraz utylizację.
Większość nowoczesnych firm produkcyjnych korzysta z systemów PLM do dokumentowania danych produktowych i zarządzania nimi. Systemy PLM wspierają wiele kluczowych operacji w firmie: przede wszystkim administrowanie plikami CAD, dokumentami oraz danymi związanymi z zarządzaniem zmianą. Wszystkie te zależne od siebie funkcje są stale aktualizowane o nowe wymagania. Mały błąd, który pojawia się w jednym obszarze, może wpłynąć negatywnie na cały proces.
Na proces rozwoju produktu składa się wiele etapów, które bywają skomplikowane, czasochłonne i niezbyt dobrze sprecyzowane. Często zdarza się, że firmy mają trudności ze śledzeniem postępów w pracach nad rozwojem produktu i bieżącą aktualizacją dokumentacji. Głównym wyzwaniem, na którym chciałbym się skupić, jest ciągła potrzeba doskonalenia produktu. Nie żyjemy w świecie idealnym, w związku z tym zmiany są nieuniknione – niezależnie od tego, czy jest to tylko mały fragment projektu, który wymaga aktualizacji, dotychczas używana część nie jest już dostępna, czy też musicie się upewnić, że produkt spełnia wymagania nowych rynków.
Windchill to sztandarowe oprogramowanie Product Lifecycle Management autorstwa firmy PTC, które w tym roku doczekało się najnowszej wersji – Windchill 12. Od dawna zapowiadana premiera, zaplanowana na 2020 rok, ze względu na Pandemię COVID-19 stanęła pod znakiem zapytania. A jednak firma PTC nie zawiodła – 9 czerwca na targach w Bostonie ogłosiła wydanie najnowszej wersji wielokrotnie nagradzanego oprogramowania do zarządzania cyklem życia produktu (PLM). Windchill, który uznawany jest za modelowy przykład Systemu Klasy Enterprise, zyskał nowe funkcjonalności. Jaki potencjał kryje w sobie najnowsza, dwunasta wersja tego programu? Postanowiliśmy to dla Was przeanalizować.
Techniki komputerowego wspomagania CAD (ang. Computer Aided Design) od wielu lat są nierozerwalnie związane z bardzo dynamicznym rozwojem przemysłu, a z każdą kolejną dekadą ich rola stale rośnie. Z systemów, które w pierwszych wydaniach były stosunkowo proste, bo stanowiły w zasadzie wirtualną deskę kreślarską, z czasem wykształciły się pakiety zaawansowanych narzędzi informatycznych. Mimo iż początkowo mogły korzystać z nich jedynie wybrane instytuty badawcze oraz największe i najbardziej rozwinięte korporacje, systemy CAD stopniowo upowszechniały się, zyskiwały coraz to nowsze funkcjonalności, a ich obsługa stawała się coraz łatwiejsza. Prawdziwa rewolucja nastąpiła jednak dopiero w dobie szybkiego Internetu i Przemysłu 4.0, gdyż to właśnie wtedy dynamicznie przekształciły się w zintegrowane z systemami klasy PDM oraz PLM wyrafinowane narzędzia, które oprócz możliwości opracowywania w środowisku wirtualnym kompletnej reprezentacji 3D produktu, wspierają w zasadzie wszystkie inne aktywności związane z szeroko rozumianym projektowaniem, konstruowaniem, cyfrowym prototypowaniem i przygotowaniem danych dla innych etapów cyklu życia produktu.
Zmiany w sektorze produkcyjnym zachodzą dziś szybciej niż kiedykolwiek wcześniej. Rosnąca wieloaspektowość procesów wiąże się z utrzymaniem efektywności operacyjnej oraz wysokiego poziomu jakości. Potrzeba przejrzystości i wydajności operacji wzrasta, a innowacje produktowe muszą być wdrażane w coraz krótszym czasie. Efektywne planowanie jest kluczem do sukcesu biznesowego organizacji. W dobie rewolucji przemysłowej 4.0 jeszcze bardziej pomocne stały się technologie IT przeznaczone do zarządzania cyklem życia produktu (PLM).
ALM jest skrótem od Application Lifecycle Management, co można swobodnie przetłumaczyć na zarządzanie cyklem życia aplikacji. Jak sama nazwa wskazuje – z założenia koncepcja ta miała służyć głównie programistom w procesie powstawania programów. Aktualnie zaś ALM jest szeroko wykorzystywany w różnych dziedzinach biznesu, gdzie pomaga w zarządzaniu najróżniejszymi projektami. Ten ciągły proces wytwarzania oprogramowania można […]
Pewnego razu… za siedmioma górami, za siedmioma lasami… Zaraz, zaraz… To nie jest kolejna długa bajka o księżniczkach, zamkach i smokach, która nie wnosi merytorycznych konkretów. To historia o osiąganiu celów jak również realizowaniu pasji. To historia o ludziach, ich koncepcjach i o tym jak ewoluują one w przyszłości. Jest to opowieść o […]
Transition Technologies PSC po trwającym cztery lata kontrakcie, właśnie zakończyło program realizacji aż dwudziestu pięciu różnych projektów dla brazylijskiego potentata z branży lotniczej. Wiele godzin ciężkiej pracy… Przez ten czas nasz zespół spędził prawie 27 000 godzin pracując nad najlepszymi rozwiązaniami z obszaru PLM, w tym nad oprogramowaniem PTC Windchill oraz PTC Integrity Lifecycle Manager, […]
Zostańmy w kontakcie
Skontaktuj się