DC House wdraża system, który z CSV z danymi produktowymi robi gotowe do druku PDF-y etykiet i opakowań — bez ręcznej pracy w DTP. Przy dużych katalogach: import CSV, dopasowanie tekstu, walidacja przed eksportem, kody kreskowe i oznaczenia środowiskowe nakładane automatycznie. Koszt od 6 500 zł netto, cena z umowy jest ostateczna po Zwiadzie.
Ten artykuł pokazuje, jak taki system wygląda od środka — które funkcje realnie zdejmują pracę z grafika, jak zbudować architekturę, żeby nowy wzór etykiety nie wymagał programisty, i ile to kosztuje w zależności od zakresu. To nie jest obieg umów ani faktur (RPA i dokumenty w MŚP): tu chodzi o pliki do druku. Ogólne widełki automatyzacji są w osobnym tekście (koszt automatyzacji 2026); tu rozbijamy je na zakres etykiet.
Dlaczego klasyczny DTP przestaje wystarczać
Firma z kilkunastoma produktami radzi sobie w Adobe InDesign bez problemu — grafik otwiera plik, wpisuje dane, eksportuje PDF. Problem zaczyna się przy katalogu liczącym setki wariantów: różne rozmiary opakowań, różne rynki, różne wersje językowe, różne wymogi regulacyjne w zależności od kraju sprzedaży.
Przy takiej skali ręczna praca w DTP przestaje się skalować. Każda zmiana ceny, składu czy normy oznacza przejście przez cały katalog ręcznie, plik po pliku. Błąd w jednym miejscu — literówka, źle dopasowany kod kreskowy, ucięty tekst — powtarza się przez dziesiątki wariantów, zanim ktoś go zauważy, często dopiero po tym, jak towar trafi już na półkę sklepową.
Dochodzi do tego zależność od jednej osoby. Jeśli tylko jeden grafik w firmie zna strukturę plików DTP i umie w nich pracować, jego urlop albo odejście zatrzymuje cały proces wydawania nowych etykiet — dokładnie wtedy, kiedy dział sprzedaży czeka na wprowadzenie nowego wariantu na rynek. To ten sam mechanizm, który opisujemy przy pierwszych trzech procesach bez działu IT: proces stoi, bo stoi jedna osoba, nie dlatego, że brakuje narzędzia.
Co powinien robić system generowania etykiet
Cztery elementy odróżniają system, który realnie działa, od prostego „mail merge”:
- Import danych strukturalnych z CSV — jeden plik, wszystkie warianty produktu, bez ręcznego wklejania.
- Automatyczne dopasowanie tekstu do pola — skalowanie fontu tak, żeby długi tekst się zmieścił, bez ucinania treści i bez ręcznej korekty każdego wariantu.
- Walidacja przed eksportem — system musi sam wykryć błędy: brakujące pole, przepełniony tekst, niedomknięty element graficzny — zanim plik trafi do drukarni, nie po fakcie.
- Seryjne generowanie kompletu plików — jedno uruchomienie, wszystkie rozmiary i warianty z pliku CSV naraz, gotowe pliki PDF do druku.
Bez walidacji zostaje generator, który produkuje błędy szybciej niż grafik. Bez dopasowania tekstu zostaje szablon, który pęka na pierwszym dłuższym składzie. Te cztery punkty są minimalnym zakresem, od którego w DC House w ogóle rozmawiamy o wdrożeniu — nie o „skrypcie, który czasem zadziała”.
Kody kreskowe i oznaczenia branżowe — automatycznie
System, który warto wdrażać, generuje i nakłada automatycznie dwa typy elementów, które w ręcznym procesie są najczęstszym źródłem błędów:
- Kody kreskowe (np. EAN-13) — generowane programowo per wariant i rozmiar, nie kopiowane z poprzedniej wersji etykiety.
- Oznaczenia środowiskowe i recyklingowe — różne rynki eksportowe mają różne, obowiązkowe wymogi oznakowania opakowań. System, który sam dobiera właściwy zestaw oznaczeń do rynku docelowego na podstawie danych z CSV, eliminuje najczęstszy błąd: wysłanie do druku etykiety z niewłaściwym oznaczeniem dla danego kraju.
To nie jest ozdoba. Przy eksporcie jeden zły piktogram oznacza reprint całego nakładu albo zatrzymanie towaru. Ręczne kopiowanie kodu z poprzedniej etykiety kończy się tym, że dwa rozmiary idą do druku z tym samym EAN-em. Generator, który liczy kod z kolumny CSV, zamyka tę dziurę zanim PDF wyjdzie z systemu.
Jak przygotować dane, żeby automatyzacja zadziałała
System jest tylko tak dobry, jak dane, które do niego wchodzą. Trzy rzeczy decydują, czy wdrożenie pójdzie sprawnie:
- Spójna struktura pliku CSV — te same kolumny, w tej samej kolejności, dla każdego wariantu produktu. Brakujące pola albo niespójne nazewnictwo kolumn to najczęstsza przyczyna opóźnień na starcie projektu.
- Jednoznaczne powiązanie danych z szablonem — system musi wiedzieć, który wiersz CSV odpowiada któremu wzorowi etykiety. Zwykle robi się to przez dodatkową kolumnę z identyfikatorem modelu.
- Źródło prawdy dla norm i oznaczeń — jeśli piktogramy i oznaczenia branżowe pochodzą z osobnego systemu (np. PIM albo arkusza działu jakości), warto to zmapować przed startem, nie w trakcie wdrożenia.
Firmy, które mają dane rozproszone po kilku Excelach bez jednego źródła prawdy, zwykle potrzebują dodatkowego etapu porządkowania danych przed właściwym wdrożeniem — to się dzieje podczas Zwiadu, nie w trakcie budowy systemu. Dzięki temu zakres nie puchnie w połowie projektu, kiedy ktoś odkrywa trzeci arkusz z „prawdziwymi” składami.
Architektura — silnik wielomodelowy
Największym błędem przy budowie takich systemów jest zaszycie logiki konkretnego wzoru etykiety bezpośrednio w kodzie programu. Efekt: każdy nowy model produktu wymaga programisty, nie tylko wpisania danych.
Właściwe podejście to silnik wielomodelowy — dodanie nowego wzoru etykiety sprowadza się do wpisania konfiguracji i przygotowania szablonu, bez dotykania kodu aplikacji. Praktycznie oznacza to rozdzielenie trzech warstw: silnika generującego PDF (stały, raz napisany), konfiguracji szablonu (opisuje pola, ich pozycje i reguły skalowania) oraz danych wejściowych z CSV. Nowy model produktu to nowy wpis konfiguracyjny, nie nowa wersja programu.
Wybór technologii zależy od kontekstu firmy. Rozwiązanie webowe sprawdza się, gdy z systemu ma korzystać kilka osób z różnych działów i gdy ważny jest dostęp bez instalacji czegokolwiek na komputerze. Rozwiązanie desktopowe ma sens, gdy proces jest w rękach jednej, wyspecjalizowanej osoby i priorytetem jest szybkość przy dużych plikach CSV. W obu przypadkach generator PDF działa po stronie serwera albo aplikacji, nie w przeglądarce — to zapewnia spójność wyniku niezależnie od tego, na jakim urządzeniu ktoś uruchamia proces.
To ta sama decyzja, którą opisujemy przy Make.com kontra własny kod: no-code bywa szybki na jeden szablon, ale przy setkach wariantów, walidacji i kodach kreskowych rachunek szybko idzie w abonament i limity operacji. Generator etykiet to nie scenariusz Make — to silnik, który musi dać identyczny PDF niezależnie od tego, kto kliknie „generuj”.
Panel użytkownika nie musi być rozbudowany. W praktyce wystarcza prosty interfejs: wgraj plik CSV, wybierz model etykiety (jeśli katalog ma ich kilka), uruchom generowanie, pobierz gotową paczkę plików PDF. Cała złożoność zostaje w warstwie silnika, nie w interfejsie, z którego korzysta zespół na co dzień.
Ile to kosztuje
Widełki są te same co przy automatyzacji procesów — bo to ten sam filar, nie osobny produkt „od etykiet”.
| Zakres | Koszt (netto) | Co obejmuje |
|---|---|---|
| Proces PoC | od 6 500 zł | Jeden model etykiety, import CSV, generowanie PDF, podstawowa walidacja |
| Wdrożenie standardowe | od 28 000 zł | Silnik wielomodelowy, kilka wzorów etykiet, kody kreskowe, panel do wgrywania CSV |
| Wdrożenie rozbudowane | od 85 000 zł | Pełna architektura wielomodelowa, oznaczenia branżowe per rynek, walidacja zaawansowana, integracja z istniejącymi systemami, dokumentacja dla zespołu klienta |
Cena z umowy jest ostateczna po Zwiadzie — zakres zależy od liczby modeli etykiet, złożoności danych wejściowych i tego, czy system ma integrować się z istniejącymi systemami (ERP, PIM), czy działać samodzielnie. Kwoty z tabeli to próg wejścia, nie oferta z powietrza.
Ile trwa wdrożenie
Proces PoC (jeden model etykiety, podstawowa funkcjonalność) da się zrealizować w 2–3 tygodnie — to wystarczy, żeby zweryfikować, czy podejście działa na realnych danych klienta, zanim padnie decyzja o pełnym wdrożeniu. Pełna architektura wielomodelowa z walidacją i integracjami to zwykle 6–10 tygodni, zależnie od liczby wzorów etykiet i złożoności reguł walidacyjnych.
Jeśli CSV jest spójne, a wzorów jest kilka, dolna granica jest realna. Jeśli dane siedzą w trzech Excelach i każdy dział ma „swoją prawdę” o składzie, najpierw porządkowanie — i to widać w Zwiadzie, nie w połowie sprintu deweloperskiego.
Trzy najczęstsze błędy przy budowie takich systemów
| Błąd | Konsekwencja |
|---|---|
| Logika wzoru etykiety zaszyta w kodzie, nie w konfiguracji | Każdy nowy model produktu wymaga programisty — system nie skaluje się z katalogiem |
| Brak walidacji przed eksportem | Błędy (przepełniony tekst, brakujące pole) wykrywane dopiero w drukarni, nie w systemie |
| Kody kreskowe i oznaczenia kopiowane ręcznie z poprzednich wersji | Powielone błędy przez dziesiątki wariantów, zanim ktoś zauważy |
Te trzy błędy często idą w komplecie: skrypt na jeden szablon, zero walidacji, EAN wklejony z poprzedniego PDF. Działa na dziesięciu wariantach. Pada na dwusetnym. Wtedy firma wraca do DTP albo płaci za przepisanie silnika — drożej niż gdyby od razu rozdzielić warstwy.
Co realnie się zmienia po wdrożeniu
Zespół, który wcześniej spędzał dni na ręcznym przygotowywaniu wariantów etykiet w DTP, po wdrożeniu wgrywa jeden plik CSV i pobiera gotową paczkę PDF-ów. Wprowadzenie nowego produktu do sprzedaży przestaje czekać na dostępność jednej, konkretnej osoby w firmie. Zmiana ceny czy normy w setkach wariantów to jedna aktualizacja danych, nie setki ręcznych edycji plików.
To nie jest projekt, który kończy się w dniu wdrożenia. Dobra dokumentacja techniczna pozwala zespołowi klienta samodzielnie dodawać kolejne modele i szablony bez każdorazowego kontaktu z wykonawcą — to powinno być częścią zakresu projektu, nie dodatkiem za dopłatą. Wsparcie powdrożeniowe ma sens jako osobna, jasno zakontraktowana pozycja, nie domyślne oczekiwanie po obu stronach. Ustalamy to na etapie oferty, nie dopiero gdy pojawi się pierwsze pytanie po starcie produkcyjnym.
Macie duży katalog produktów i ręczną pracę w DTP, która nie nadąża za skalą? Umówcie rozmowę — 45 minut, 0 zł. Sprawdzimy, ile realnie da się zautomatyzować i jaki model architektury pasuje do Waszych danych. Jeśli ma sens, następny krok to płatny Zwiad.
Więcej o naszym podejściu do automatyzacji: Automatyzacja procesów.
O autorze
Artur Jaźwiec — współzałożyciel DC House. Automatyzacja B2B, integracje i systemy, które zdejmują ręczną pracę z katalogu, nie tylko z maila.