Jak Temared oszczędził 5400 godzin pracy w jeden weekend?

Wyobraź sobie 30 000 plików technicznych, dwa kraje, jeden weekend i… tylko jedną szansę, żeby to wszystko nie wybuchło w poniedziałek rano. Brzmi jak scenariusz filmu akcji dla inżynierów? Trochę tak było. Kiedy polski lider produkcji przyczep, firma Temared, przejęła spółki w Holandii, okazało się, że największą barierą nie jest język, ale… standardy w dokumentacji SOLIDWORKS.

Zapraszam Cię do historii o tym, jak dzięki automatyzacji, chłodnej głowie i sporej dawce ziołowej herbaty, oszczędziliśmy 5400 godzin nudnej, ręcznej pracy, zamieniając chaos w międzynarodowy standard. 

 Szybkie fakty: 

• Klient: Temared (lider produkcji przyczep w Europie). 
• Skala: Ponad 30 000 plików (łącznie ok. 50 000 operacji). 
• Wyzwanie: usprawnienie komunikacji pomiędzy działami, a szczególnie pomiędzy działem technicznym i produkcją — tak, aby obie strony pracowały na tej samej, aktualnej i jednoznacznej dokumentacji. 
• Czas: 1 intensywny weekend (zamiast 4 miesięcy pracy ręcznej). 
• Zysk: Oszczędność ok. 5400 roboczogodzin i eliminacja ryzyka błędów produkcyjnych. 

Temared w kilku słowach: skala, która robi wrażenie 

Temared to marka stawiająca na przyczepy do biznesu. Tworzy wielofunkcyjne przyczepy bagażowe oraz specjalistyczne konstrukcje do transportu samochodów, maszyn budowlanych, motocykli, quadów i łodzi. Firma oferuje blisko 300 modeli z możliwością szerokiej konfiguracji. Stawia na jakość, bezpieczeństwo i niezawodność, a jej produkty są obecne praktycznie na całym świecie – współpracuje z ponad 300 dystrybutorami w 57 krajach na 6 kontynentach.

Jest też głównym filarem, na bazie którego powstał międzynarodowy holding – Unitrailer Holding – konsolidujący europejski rynek przyczep. Sama grupa dynamicznie rozwija swoje moce wytwórcze, czego najlepszym dowodem jest rok 2025, w którym łącznie wyprodukowano 65 000 przyczep. Skala operacji, inwestycje w automatyzację oraz konsekwentne budowanie pozycji rynkowej sprawiają, że marki wchodzące w skład Unitrailer Holding są jednymi z najszybciej rozwijających się w europejskiej branży przyczep.

Ambicje firmy są równie konkretne, co wyniki: firma celuje w pozycję największego producenta przyczep w Europie oraz lidera – lub przynajmniej wicelidera – na każdym europejskim rynku. Kierunek jest wyraźny, a konsekwencja widoczna: marki Unitrailer Holding były wielokrotnie nagradzane, m.in. prestiżowym Diamentem Forbes. Więc przy tej skali… dokumentacja nie może żyć własnym życiem. 

Moment, w którym „działało” przestało wystarczać 

W Polsce Temared korzysta z SOLIDWORKS PDM od lat. System był dobrze skonfigurowany: procedury, obiegi, standardy opisów, formatki rysunkowe, lokalizacja językowa — wszystko zaprojektowane pod jeden zespół w jednym kraju. 

I to działało.
Aż do czasu, gdy firma przejęła dwie spółki w Holandii i do gry weszło międzynarodowe środowisko. 

Wtedy pojawił się klasyczny problem ekspansji: 

• te same informacje opisywane na różne sposoby, 
• różne nazwy właściwości, różne zestawy pól, 
• formatki pokazujące inne dane, 
• nieścisłości w nazewnictwie i interpretacji dokumentacji, 
• a do tego „rewizja” raz była widoczna tu, raz tam — zależnie od historii pliku, zespołu i przyzwyczajeń. 

Krótko mówiąc: to nie był konflikt ludzi. To był konflikt standardów. 

Rewizje: mały detal, który robi duży bałagan 

Dodatkowym impulsem do zmian była decyzja o usprawnieniu i uporządkowaniu informacji o rewizjach. Temared postanowił zmienić logikę prezentacji rewizji na dokumentacji:
z „po zaakceptowaniu” na „przed zaakceptowaniem”. 

Niby detal. Ale w praktyce ten detal decyduje o tym, czy produkcja i zakupy pracują na tym, co trzeba, czy na tym, co „już prawie gotowe”. A „prawie” w dokumentacji technicznej jest jak „prawie szczelny zbiornik” — teoretycznie brzmi niegroźnie, ale w praktyce… wiadomo. W skali produkcji 50 000 przyczep rocznie, pomyłka na etapie rewizji to nie jest błąd w papierach – to ryzyko wyprodukowania setek sztuk wadliwego towaru i ogromne straty finansowe. 

Siedziba główna w Polsce zdecydowała, że warto to ujednolicić na bazie krajowych doświadczeń oraz dobrych praktyk obserwowanych w innych firmach. Aby mieć pewność, że tak potężna operacja zakończy się sukcesem, Temared zdecydował się na współpracę z firmą Visiativ. Do realizacji zadania został wyznaczony doświadczony zespół wdrożeniowy, na czele ze mną. Więc dysponowałem nie tylko wiedzą ekspercką, ale i sprawdzonymi narzedziami: autorskim rozwiązaniem myCADtools.

Cel: jeden język, jeden standard, jedna wspólna logika – Temared

Podjęto decyzję o dwóch fundamentalnych zmianach: 

• Ujednolicenie nazw właściwości i przejście na język angielski 

Aby każdy zespół (niezależnie od kraju) mówił tym samym językiem w dokumentacji, zapadła decyzja o przepisaniu nazw właściwości na zrozumiały dla wszystkich angielski. 

• Uniwersalne formatki rysunkowe 

Formatki miały stać się jednolite i uniwersalne, niezależnie od tego, czy rysunek powstał w Polsce, czy w Holandii. 

I wtedy padło pytanie, które zna każda firma po przejęciu:
„Dobra… a ile tego jest?” 

Skala wyzwania: 53 283 powodów, żeby nie robić tego ręcznie 

Szybka inwentaryzacja pokazała: 

• ponad 13 000 plików rysunkowych 
• ponad 11 000 plików modeli części 
• ponad 4 000 plików złożeń 
• ponad 3 000 plików z używanymi standardami 
• 53 283 operacje na plikach 

Łącznie: około 30 000 plików, które trzeba było objąć zmianą. 

Policzyliśmy wariant ręczny (żeby go potem z czystym sumieniem wyrzucić do kosza): 

• ok. 7 minut na plik (check-out w PDM → otwarcie w SOLIDWORKS → zmiana → zapis → check-in) 
• daje to 5497 roboczogodzin 

Przy 10 osobach w zespole: prawie 4 miesiące pracy…
pod warunkiem, że nikt nie ma projektów, spotkań, telefonów, przerw na kawę i potrzeby życia jak człowiek. 

To był scenariusz z kategorii:
„Firma stoi, ale za to właściwości są piękne.”  

Co gorsza, praca ręczna przy takiej masie danych to pewność wystąpienia setek błędów ludzkich (literówki, przeoczenia), które są niezwykle trudne do wyłapania. 

Nie wchodziło w grę: 

• zatrudnienie „armii studentów” (ryzyko błędów + ochrona IP), 
• oddelegowanie jednej osoby (czas + blokada bieżącej pracy). 

Wniosek był prosty:
albo automatyzacja, albo chaos w wersji premium. 

Od rozmów do planu: jak wyglądało podejście projektowe 

Zanim ruszyliśmy z jakimikolwiek zmianami, odbyłem serię rozmów z Damianem Michotą (Kierownik Działu Technicznego) i Kamilem Wojanowskim (Dyrektor Techniczny Grupy), żeby doprecyzować stan docelowy: 

• jak ma wyglądać nowy standard, 
• co zmieniamy w istniejących obiegach dokumentacji, 
• które przypadki są wyjątkami, 
• jak szeroki jest zakres i gdzie są miny. 

Potem zrobiliśmy to, co lubię najbardziej:
testy na odizolowanym środowisku. 

Przetestowaliśmy kilka scenariuszy, wybraliśmy najbezpieczniejszy i najefektywniejszy wariant — taki, który będzie działał nie tylko „na papierze”, ale też w realnym życiu, gdzie pliki bywają uparte, a rzeczy dzieją się o 2:17 w nocy. 

Technologia, która zrobiła robotę: Integration z myCADtools, rozwiązaniem Visiativ

Postawiliśmy na automatyzację z wykorzystaniem: Integration z pakietu myCADtools od Visiativ.

To był klucz: rozwiązanie pozwoliło zautomatyzować operacje, które ręcznie byłyby monotonne, czasochłonne, a także ryzykowne. 

Moim zadaniem było przygotowanie procedur i logiki: 

• podmiana formatek arkuszy z zachowaniem informacji o rewizji, 
• scenariusze zależne od formatu pliku oraz stanu w obiegu dokumentacji, 
• listy kontrolne i procedury awaryjne (bo to nie był projekt „na odwagę”, tylko na wynik). 

Operacja „Weekend”: czyli jak zamieniliśmy stacje robocze w fabrykę automatyzacji 

Wspólnie z Jarosławem Gaikiem (Dyrektor IT) i Arturem Pietrakiem (Dział IT) przygotowaliśmy środowisko do przeprowadzenia całej akcji. 

I teraz najlepsze:
główną rolę grały stacje robocze użytkowników, które miały wykonać operacje. 

Tak, dobrze czytasz. To nie była jedna „magiczna maszyna serwerowa”, tylko sensownie zaplanowana dystrybucja pracy, dzięki której mogliśmy działać wydajnie. 

A dzięki współczesnym narzędziom zdalnym…
połączyłem się ze wszystkimi komputerami z mojego biura. 

Bez pielgrzymki do siedziby firmy.
Bez biegania „od komputera do komputera”.
Za to z możliwością spokojnego obserwowania pasków postępu… 

…popijając ziołową herbatkę na uspokojenie, bo jak człowiek patrzy, jak kilkadziesiąt tysięcy plików zmienia się „w locie”, to nawet najbardziej techniczna dusza docenia zioła. 

Plan jak w lotach kosmicznych: check-in, backup i start o 19:00 

Ustaliliśmy harmonogram: 

Czwartek 

• wszyscy ewidencjonują swoje pliki, 
• robimy kopie zapasowe, 
• rekonfigurujemy środowisko. 

Czwartek 19:00 

• startujemy z procesem. 

Cel:
w poniedziałek o 8:00 firma pracuje normalnie, jakby nic się nie stało. 

Były przygotowane: 

• listy plików pod konkretne scenariusze, 
• checklisty, 
• procedury awaryjne, 
• plan reagowania na problemy. 

I ruszyliśmy. 

Problemy były. Oczywiście, że były. Ale nie wygrały. 

Kiedy główny proces ruszył i wziąłem na warsztat pliki części, pojawił się dodatkowy „bonus”, którego nikt nie zamawiał. 

Okazało się, że dla każdego pliku części muszę przepisać właściwości elementu blaszanego do właściwości pliku – między innymi: 

• grubość blachy, 
• pole powierzchni, 
• ilość gięć. 

Na papierze brzmi prosto. W praktyce… system postanowił przypomnieć mi, że międzynarodowe środowisko ma swoje zasady. 

Problem: „to zależy w jakim języku” 

Właściwości blachy w modelach były opisywane różnie, w zależności od tego, jaką wersję językową SOLIDWORKS miał użytkownik, który kiedyś tworzył plik. Raz nazwy były po polsku, raz po angielsku. 

Pierwotne procedury radziły sobie tylko z wersją polską, więc: 

• część plików przechodziła poprawnie, 
• część nie dawała się przetworzyć, 
• a całość zaczęła działać wolniej niż „zdalny pulpit na hotelowym Wi-Fi”. 

I to był dokładnie ten moment, który mógł wykoleić cały projekt przez czas. 

Decyzja: nie zatrzymuję machiny 

W takiej sytuacji najgorsze, co mógłbym zrobić, to zatrzymać cały proces i próbować „naprawić wszystko na żywo”, bo wtedy nie tylko rośnie stres — rośnie też ryzyko, że projekt utknie i zablokuje firmę. 

Podjąłem więc decyzję:
wyłączyłem tę podprocedurę i puściłem główny proces dalej. 

Czyli: najpierw dowiozłem kluczowe ujednolicenie, a temat blach zostawiłem na kontrolowaną „dogrywkę”, już z poprawioną logiką. 

Poprawka i dogrywka: 7 maszyn, 10 000 plików i powtórka akcji 

Po zakończeniu głównego wątku poprawiłem procedurę odczytu właściwości blach tak, żeby uwzględniała różne wersje językowe. 

Następnie, już w pełni kontrolowanie, na 7 maszynach wróciłem do plików części, w których występowały elementy blaszane. 

Tak — oznaczało to ponowne uruchomienie ponad 10 000 plików. 

Ale zysk czasowy był ogromny, a cały proces domknąłem zgodnie z planem.
I co najważniejsze: bez zatrzymywania pracy projektowej i bez ryzyka, że poniedziałek rano zacznie się od pytania: „ktoś wie, czemu nie działa dokumentacja?”  

W automatyzacji największym ryzykiem rzadko jest samo narzędzie — najczęściej jest nim „wielość standardów” ukryta w danych (języki, nazwy właściwości, nawyki zespołów), dlatego dobrze zaprojektowany proces musi być na to odporny od samego początku. 

Czynnik białkowy – najsłabsze ogniwo automatyzacji 

W automatyzacji jest jeden element, który najczęściej psuje statystyki niezawodności… to czynnik białkowy, czyli człowiek. To właśnie człowiek popełnia najwięcej błędów w czynnościach powtarzalnych: podczas przepisywania danych pomiędzy systemami, kopiowania informacji do arkuszy Excela, w trakcie ręcznego uzupełniania pól, czy weryfikowaniu „po łebkach” kolejnych rekordów. Monotonia robi swoje — włącza się rutyna, a uwaga z czasem spada. I w naszym projekcie też zaliczyliśmy ten moment, w którym człowiek okazał się najsłabszym ogniwem. 

Rola eksperta w takim procesie jest kluczowa

Oprogramowanie to tylko narzędzie, ale to człowiek musi zareagować, gdy system napotyka nieprzewidziane trudności. 

Jednak zacznijmy od końca. Jestem już na etapie oddawania systemu klientowi. Wszystko wygląda dobrze, procesy przeszły, logi się zgadzają, a w głowie już układam sobie poniedziałkową kawę i spokojny poranek. Robimy jeszcze wyrywkową kontrolę dokumentacji… i nagle zauważamy, że na części rysunków nie ma poprawnych formatek.

I to jest ta chwila grozy, kiedy w sekundę przez głowę przelatuje cały czarny scenariusz: czy dotrzymam terminu, co to spowodowało, czy teraz trzeba będzie ręcznie przeglądać wszystko? Czy to błąd systemu? Aplikacja automatyzująca zawiodła? Czy jednak mój błąd? A może to „wina klienta”, bo gdzieś po drodze ktoś miał inne jednostki w szablonie arkuszy, albo inne rozmiary niż standardowe i formatki się nie wczytują? 

Najbardziej podstępne było to, że w historii plików widniała informacja, że proces wykonał się poprawnie — tylko efektu końcowego brakowało. Dopiero analiza logów pokazała prawdę: jedna ze stacji roboczych nie zaczytała nowych formatek, których używałem w procesie. I to nie był bug w oprogramowaniu ani sabotaż kosmiczny — to było moje przeoczenie w procedurze. Wyrywkowe sprawdzanie dokumentacji tego nie wykryło, bo rutyna zrobiła swoje i weryfikację jednej stacji zwyczajnie „odhaczyłem w głowie”, albo przepijałem zieloną herbatę… 

Na szczęście to jest właśnie różnica między chaosem a kontrolą: miałem przygotowane listy kontrolne, wiedziałem jak podzielić pracę i jak ją powtórzyć bez rozbijania całego projektu. Zmodyfikowałem procedurę, rozłożyłem zadanie na kilka stacji i po około 3 godzinach temat był domknięty — wszystko wróciło na właściwe tory, a system został oddany zgodnie z planem. 

Co zyskał biznes? Czyli dlaczego to jest temat dla zarządu 

Ten projekt nie był „techniczną kosmetyką”. To była zmiana o realnym wpływie na organizację, możliwa dzięki połączeniu doświadczenia zespołu wdrożeniowego Visiativ oraz unikalnych możliwości pakietu myCADtools.

Najważniejsze efekty:

• Ujednolicone nazwy właściwości w języku angielskim — wspólny język danych dla wszystkich zespołów.
• Jednolite, uniwersalne formatki rysunkowe — spójność dokumentacji niezależnie od lokalizacji.
• Uporządkowana logika rewizji — mniej błędów interpretacji, więcej przewidywalności.
• Uniknięcie 5400 roboczogodzin ręcznej pracy — dzięki automatyzacji myCADtools, proces który trwałby miesiącami, zamknęliśmy w jeden weekend.
• Brak konieczności wstrzymywania projektów i „zamrażania firmy” na miesiące — zachowanie ciągłości biznesowej to najwiekszy zysk przy tej skali.
• Minimalizacja ryzyka błędów ludzkich (najdroższy rodzaj błędów) — nasze autorskie algorytmy sprawdzające wyeliminowały ryzyko pomyłek, które przy pracy ręcznej byłyby nieuniknione.
• Lepsza współpraca międzyoddziałowa, mniej „wojen o nazwy”.

W skrócie: Automatyzacja nie tylko przyspieszyła pracę — ona uratowała sensowność całej operacji. Wdrożenie rozwiązań Visiativ pokazało, że technologia w rękach ekspertów potrafi zdjąć z barków firmy ciężar, który inaczej hamowałby jej międzynarodowy rozwój przez lata.

Lekcja dla firm rosnących przez przejęcia: automatyzacja to nie luksus 

Jeśli Twoja firma: 

• wchodzi na nowe rynki, 
• łączy zespoły, 
• przejmuje inne podmioty, 
• albo po prostu rośnie szybciej niż dokumentacja nadąża… 

…to prędzej czy później trafisz na moment, gdy standardy przestaną być „miłym dodatkiem”, a staną się warunkiem przetrwania skali. 

Temared podjął dobrą decyzję:
zamiast robić projekt „heroiczny” (czytaj: ręczny i ryzykowny), postawił na mądrą automatyzację, kontrolę i plan. Kluczem do sukcesu było zaufanie Nam – specjalistom z Visiativ – wiedzieliśmy, że przy 40 000 plików nie ma miejsca na improwizację. Wykorzystaliśmy możliwości myCADtools, by zamienić tygodnie pracy w godziny precyzyjnego procesu.

A ja?
Ja byłem jak wieża kontroli lotów — na ekranie kolejne „starty i lądowania”, a w tle ciche tykanie czasu do poniedziałkowego poranka. I tak, herbata ziołowa była częścią procedury bezpieczeństwa. 

Gdy firma rośnie, chaos zaczyna się nie w ludziach, tylko w systemach i procedurach.

W Visiativ nie tylko wdrażamy systemy – my rozwiązujemy realne problemy, które blokują rozwój dużych organizacji.

Skontaktuj się z nami — pokażemy Ci, jak to ugryźć bez rewolucji i bez utraty ciągłości pracy.