12.11.
2025

Pilotaż 3DEXPERIENCE w praktyce: jak w 6 tygodni rzetelnie sprawdzić efekty i podjąć decyzję

W wielu firmach przejście na nowe narzędzie zaczyna się od długiego researchu, imponujących prezentacji i… zbyt szerokich ambicji. Efekt? Energia rozprasza się na poboczne tematy, a zespół po miesiącu nie potrafi odpowiedzieć na najprostsze pytanie: „Czy jest nam z tym łatwiej?”.

Pilotaż 3DEXPERIENCE warto zaplanować inaczej. Jak krótki eksperyment z jasną hipotezą: „Jeśli uporządkujemy ścieżkę zmian, publikację wydań i dostęp do aktualnej dokumentacji, to spadnie liczba pomyłek wersji, skróci się czas akceptacji, a produkcja przestanie dzwonić z pytaniem „co produkujemy?”. Sześć tygodni w zupełności wystarczy, by to udowodnić, o ile od początku postawimy na prawdziwą pracę na prawdziwym zleceniu, a nie turystykę po funkcjach.

Tydzień 1 - Ustalamy zasady gry i „zamyka się” zakres

Pierwsze spotkanie jest krótkie, ale gęste od konkretów. Przy stole zasiada lider techniczny, przedstawiciel konstrukcji, produkcji i jakości. Nie omawiamy całego katalogu możliwości platformy - zamiast tego wybieramy jedną linię produktową lub jeden projekt klienta, na którym każdy rozumie stawkę i typowe potknięcia. Padają pytania, które „ustawiają” cały pilot: jakie decyzje dziś rozchodzą się mailem, które zmiany wracają do nas jak bumerang, kiedy ostatnio produkcja pracowała na nieaktualnym PDF-ie i ile to kosztowało dodatkowego czasu?

Na tym etapie definiujemy minimalny proces: projekt → akceptacja → wydanie do produkcji. Ustalamy statusy w Collaborative Lifecycle (In Work, Frozen, Released) i prostą regułę: wydruk i podgląd wyłącznie z 3DEXPERIENCE. Nie dlatego, że „tak trzeba”, ale dlatego, że tylko w ten sposób stworzymy jedno źródło prawdy, do którego wszyscy będą się odwoływać.

Równolegle powstaje agenda komunikacyjna: krótki post w 3DSwym informujący zespół, że przez sześć tygodni testujemy nowy sposób pracy; termin cotygodniowej odprawy (30 minut), gdzie patrzymy na dwie liczby: ile zmian przeszło ścieżkę oraz ile było telefonów „co obowiązuje?”. Tydzień zamykamy nadaniem ról i uprawnień w środowisku, utworzeniem przestrzeni np.: „Released to Manufacturing” i prostym planem publikacji wydań.

Tydzień 2 - Dane „tylko niezbędne” i konfiguracja procesu zmian

Zaczyna się cicho i roboczo. Konstruktorzy przenoszą do przestrzeni tylko te części i złożenia, które będą potrzebne w pilotażu. To ważne: nie migrujemy historii sprzed pięciu lat, nie czyścimy świata. Wgrywamy „żywe” elementy, z którymi będziemy pracować tu i teraz. W Bookmark Editor powstają pierwsze zestawy - jedna zakładka dla konstrukcji, druga dla produkcji, trzecia dla jakości. Nie są idealne; będą ewoluować.

Kluczowym momentem jest wspólne wypełnienie pierwszej karty Change Action lub Issue Management. Na ekranie pojawiają się pola: opis intencji, zakres wpływu (części, dokumenty), powód zmiany (np. uwaga klienta, błąd montażowy), wymagane terminy i proponowana osoba akceptująca. Wpisujemy prawdziwą sprawę, nie przykład. Ktoś proponuje skrócić opis, bo „wszyscy wiedzą, o co chodzi”; rezygnujemy z tego odruchu. Opis ma być zwięzły, ale tak konkretny, żeby osoba z produkcji mogła go zrozumieć bez telefonu do autora.

Pod koniec tygodnia zespół produkcji dostaje krótką sesję „Zobacz i wydrukuj” z 3DPlay. Nie pokazujemy całej platformy - tylko to, co potrzebne, by samodzielnie odnaleźć wydanie, podejrzeć rysunek, wydrukować i wrócić do pracy. Miarą sukcesu jest zdanie z hali: „Już nie czekam na maila, po prostu wchodzę i drukuję”.

Tydzień 3 - Pierwsze prawdziwe zmiany i pierwsze wydania

Od tej chwili wszystko musi być „na serio”. Przez Change Action Action lub Issue Management przechodzą dwie–trzy realne modyfikacje: drobny detal w otworowaniu, korekta tolerancji, zmiana dostawcy elementu katalogowego. Każda ma swoją mini historię: kto zgłosił, kto ocenił, kto zaakceptował, kiedy została opublikowana. Równolegle powstają pierwsze wydania w przestrzeni dla produkcji. Zespół uczy się rozpoznawać różnicę między „In Work” a „Released” nie ze slajdu, ale z życia: jednym wolno się posługiwać na hali, drugim nie.

To dobry moment na 3DMarkUp. Wspólnie otwieramy model „sprzed” i „po”, nanosimy adnotacje: tu zmieniliśmy średnicę, tu dodaliśmy fazkę, tu nie ma wpływu na BOM. Krótka, pięciominutowa „warstwa koloru” dołącza do każdej zmiany - po to, by osoba, która nie śledziła całego wątku, w sekundę zobaczyła istotę korekty.

Później Lider techniczny sprawdza dwie rzeczy: czy każdy dokument użyty na produkcji miał status Released oraz, czy wszystkie korekty przeszły przez akceptację zmian. Jeżeli coś „wylało się bokiem” - nie szukamy winnych, tylko przyczyny. Najczęściej jest banalna: brak jednego odsyłacza w Bookmark Editor albo stary nawyk wysłania PDF-a. Zmieniamy środowisko tak, by odruch „na skróty” przestał być najwygodniejszy.

Tydzień 4 - Stabilizacja, dyscyplina i pierwsze małe zwycięstwa

Czwarty tydzień to czas, kiedy nowy sposób pracy zaczyna się bronić sam. Produkcja już wie, że najszybciej jest wejść do 3DPlay, a nie szukać plików w mailach. Konstruktorzy widzą sens opisywania zmian, bo po raz pierwszy ktoś z jakości dopisał do wątku uzasadnienie reklamacyjne i ten „gwóźdź” osadził się w historii produktu.

W 3DSwym pojawia się szereg krótkich wpisów „FAQ”, które nazywają oczywistości: jak znaleźć ostatnie wydanie dla referencji X, gdzie zobaczyć różnice między rewizjami, jak zgłosić drobną uwagę, która nie wymaga pełnej zmiany. Język jest prosty, bez żargonu. „Kliknij tu, sprawdź to, jeżeli widzisz Y zgłoś przez Z”. Taka mikro-dokumentacja działa lepiej niż 100-stronicowy manual, bo odpowiada na pytania, które naprawdę padły.

W tle zbieramy liczby. Nie tworzymy skomplikowanych kokpitów - na razie wystarczy, że wiemy, ile było zmian i ile zajęła akceptacja, ile razy ktoś pytał „co obowiązuje” oraz ile dokumentów wydrukowano z miejsca innego niż 3DPlay. Te dane nie mają „nas zadowolić”; mają być uczciwe. Jeżeli coś wciąż szwankuje, to znak, że albo proces jest zbyt ciężki, albo któryś etap nie działa prawidłowo.

Tydzień 5 - Szlif, drobne korekty i przygotowanie do decyzji

W piątym tygodniu domykamy szczegóły. Formularz zmian dostaje jedno dodatkowe pole, którego brak najbardziej doskwierał (np. „wpływ na dokumentację serwisową”). W Bookmark Editor porządkujemy nazewnictwo, by „dziś” i „wczoraj” nie brzmiały podobnie. W Collaborative Tasks znikają stare zadania, pozostają tylko te, które popychają realną pracę.

To także moment krótkiego warsztatu retrospektywnego. Każdy przynosi jedną rzecz, która go spowalnia, i jedną, która przyspiesza. Nie mówimy „wszyscy tak mają” tylko szukamy małych, konkretnych przesunięć. Ktoś zauważa, że akceptacje w piątki po 14:00 wiszą do poniedziałku. Ustalamy jasną zasadę i drugą osobę do podbijania zmian, jeśli akceptant jest poza biurem. Pilotaż ma sens tylko wtedy, gdy obok funkcji pojawia się dyscyplina.

Tydzień 6 - Dowody, nie wrażenia

Finał ma formę krótkiej, godzinnej prezentacji dla decydentów. Zaczynamy od prawdziwego przypadku, który przeszedł przez cały proces: od zgłoszenia problemu z montażem, przez Change Action, po wydanie i wydruk w 3DPlay. Na jednym slajdzie pokazujemy „mapę zdarzeń”: kto, kiedy i dlaczego, z linkami do obiektów w 3DEXPERIENCE. Nie chodzi o fajerwerki- chodzi o to, by każdy zobaczył, że ścieżka istnieje i jest używana.

Potem wjeżdżają liczby. Tyle trwała akceptacja „przed”, tyle „po”. Tyle razy pracowaliśmy na złej wersji „przed”, tyle „po”. Tyle było telefonów „co obowiązuje” w tygodniu „przed”, tyle „po”. Jeśli w którymś wskaźniku jest remis - nie ukrywamy tego. Uczciwość na tym etapie daje kredyt zaufania na fazę 2. Na koniec pokazujemy trzy cytaty: z produkcji, konstrukcji i jakości. „Przestaliśmy pytać o rysunki”, „łatwiej mi wytłumaczyć, co zmieniam”, „mamy ślad na audyt”. To krótkie zdania, ale niosą wagę.

Decyzja „Go/No-Go” nie jest już kwestią opinii. To spokojne podsumowanie: pilotaż pokazał, że przy minimalnym zakresie potrafimy utrzymać jedno źródło prawdy i przeprowadzić zmianę bez chaosu. Jeżeli idziemy dalej, plan fazy 2 jest prosty: dokładamy MBOM/Shop-floor, rozbudowujemy obszar jakości lub podpinamy integrację z ERP, ale tylko tam, gdzie już dziś widzimy zwrot.

Najczęstsze obawy:

„To nas spowolni” - tylko wtedy, gdy pozwolimy, by proces był cięższy niż problem. Dlatego zaczynamy od jednej ścieżki i jednego miejsca wydań.
„Ludzie i tak będą wysyłać PDF-y” - nie będą, jeśli z 3DPlay jest szybciej i wygodniej. Udrożnienie ścieżki legalnej to najlepszy bat na „skrót”.
„A co z integracją z ERP?” - w pilotażu nie jest potrzebna. Najpierw pokaż, że proces żyje i daje efekty; integrację dołóż tam, gdzie faktycznie skraca obieg.

Podsumowując, podejmuj decyzje na dowodach, nie na przeczuciu

Dobry pilotaż 3DEXPERIENCE to nie przegląd katalogu funkcji, tylko ćwiczenie z dyscypliny procesu. Kiedy wydania trafiają w jedno miejsce, zmiany mają prostą ścieżkę, a podgląd jest „od ręki” w przeglądarce, znika najdroższy rodzaj pracy: bieganie za informacją. Po sześciu tygodniach nie pytasz już „czy nam się to podoba”, tylko widzisz, o ile krótsza jest akceptacja, o ile rzadsze są pomyłki wersji i ile razy mniej ktoś pytał „co obowiązuje”.

Reszta to decyzja biznesowa: kontynuujemy, bo pilotaż udowodnił, że porządek opłaca się bardziej niż gaszenie pożarów.

Zobacz także: