60% custom konfiguratorów bez wiedzy domenowej kończy się porażką. 95% systemów CPQ jest zaprojektowanych dla administratorów RevOps, podczas gdy 95% realnych użytkowników to handlowcy. Według Standish CHAOS Report tylko 31% projektów IT kończy się sukcesem – 19% to totalna porażka.
Jeśli jesteś po kilku miesiącach rozmów z software house’ami albo masz już wdrożony konfigurator, który nie działa, ten artykuł jest dla Ciebie. Pięć rzeczy, które zabijają projekty konfiguratorów, z danymi branżowymi i realnymi przykładami z naszych wdrożeń. I konkretne rekomendacje, jak ich uniknąć.
60% problemów to procesy, nie technologia. Twój konfigurator nie padnie przez kod. Padnie przez to, co dzieje się wokół niego.
|
Masz już konfigurator, który nie działa? Audyt 1-2 dni, bezpłatnie. Powiemy wprost, czy da się uratować. |
Zamów audyt |
TL;DR · 30 SEKUND
- 5 najczęstszych problemów wdrożeniowych: 1) reguły wyceny żyją w głowie handlowca, nie w systemie; 2) scope creep („dodajcie jeszcze…”); 3) integracja z ERP, który pamięta lata 2011; 4) handlowcy nie używają, wracają do Excela; 5) brak planowania utrzymania, konfigurator żyje 12 miesięcy i kłamie.
- 60% problemów to procesy, nie technologia. Najczęstszy fail to nie kod, to brak właściciela reguł wyceny w firmie i brak planu adopcji wśród handlowców.
- Reguła #1: przed wdrożeniem zrób warsztat z handlowcami i wyciągnij z głów wszystkie reguły wyceny, warianty, rabaty, wyjątki. Bez tego konfigurator jest „mock-up za 60 tysięcy”.
- Reguła #2: zaplanuj utrzymanie ZANIM podpiszesz umowę. Konfigurator bez właściciela po stronie klienta umiera w 12 miesięcy, zaczyna kłamać przy nowych produktach.
Wdrożenie konfiguratora produktowego to proces obejmujący: rozmowa wstępna (warsztat z handlowcami i product managerami, mapowanie reguł wyceny), specyfikację (dokument z wszystkimi wariantami, integracjami, edge case-ami), development (8-12 tygodni dla MVP), integrację z ERP/CRM/PIM, testy (UAT z realnymi handlowcami i klientami), rollout (szkolenia zespołu) oraz utrzymanie (kto dodaje nowe produkty, aktualizuje ceny, fixuje bugi).
Dlaczego reguły wyceny zostają w głowie handlowca, nie w systemie?
Sprawdź czy konfigurator ma sens u Ciebie
Ankieta 15 pytań (3 min). Po wypełnieniu wiemy oboje, czy jest o czym rozmawiać.
PROBLEM 1 · NAJCZĘSTSZY POWÓD OPÓŹNIEŃ
Cennik w PDF, reguły wykluczeń w głowie konstruktora, 15 lat doświadczenia handlowca, nigdzie nie spisane. Software house dostaje niepełne reguły, koduje to co ma, testy wywracają projekt.
To najczęstszy powód, dla którego projekty konfiguratora ciągną się miesiącami bez zauważalnych postępów. Firma zgłasza się do software house’u, mówi: „mamy cennik, mamy warianty, chcemy to zautomatyzować”. Na pierwszym spotkaniu okazuje się, że cennik to 136 stron PDF-a (realny case z naszego wdrożenia dla Akpil), warianty to 16 wersji bazowych razy 30+ opcji dodatkowych, a reguły wykluczeń („wał oponowy wymaga dyszla transportowego, ale dyszel transportowy jest niekompatybilny z systemem hydraulicznym X”) żyją w głowie konstruktora, który pracuje w firmie 15 lat.
Badania Kickflip na custom configurator development pokazują: wdrożenia bez wiedzy domenowej mają 60%+ failure rate. Dlaczego? Bo inżynier, który nigdy nie sprzedawał agregatu uprawowo-siewnego, nie zgaduje, że GPS wymaga komputera AK, a znaczniki hydrauliczne nie współgrają z maszyną poniżej 3 metrów szerokości.
Co się dzieje w projekcie: software house dostaje niepełne reguły. Koduje to, co dostał. Na etapie testów okazuje się, że system pozwala skonfigurować maszynę, której nie da się wyprodukować. Rewriting rules = kolejne 2-4 tygodnie. Scope creep gotowy.
W międzyczasie dyrektor projektu po stronie klienta dostaje telefon od CTO: „kiedy to będzie gotowe?”. Odpowiedź brzmi: „jak dostaniemy pełne reguły od handlowca”. Dwa tygodnie później to samo pytanie, ta sama odpowiedź. Miesiąc później ten sam dialog, ale już z nutą frustracji.
Jak tego uniknąć
Tydzień rozmowa wstępna PRZED linią pierwszego kodu. U naszych klientów zaczynamy od 5-7 dni siedzenia z handlowcami i konstruktorami. Mapujemy nie produkt, tylko ścieżkę klienta: jak klient pyta, co pyta najczęściej, jak handlowiec wycenia, jakie zależności uruchamiają się automatycznie. Dokument wyjściowy to 15-40 stron reguł w języku biznesowym (nie kodzie), klient sam go czyta i koryguje. Dopiero po akceptacji dokumentu dotykamy klawiatury.
Problem 2: Scope creep: „a dodajcie jeszcze…”
PROBLEM 2 · „FEW MONTHS” → 12-24 MIESIĘCY
Zarząd widzi działający konfigurator i chce więcej: panel dealerski, CRM, aplikacja mobilna. Każde „jeszcze jedno” to nowa wycena i nowy termin. Projekt 60k/10 tyg. kończy się po 9 miesiącach za 180k.
Twój konfigurator działa. Po trzech tygodniach pokazujesz go zarządowi. Zarząd mówi: „świetnie, ale może dodajmy panel dealerski? A jak już będziemy przy tym, to moduł CRM. A integracja z księgowością? No i jeszcze aplikacja mobilna, bo handlowcy jeżdżą do klientów”.
Gratulacje, właśnie podwoiłeś projekt.
Research Kickflip pokazuje typowy scenariusz: współzałożyciel zakłada „a few months of development”, realne wdrożenia rozciągają się do 12-24 miesięcy. Nie dlatego, że zespół nie umie. Dlatego, że scope creep jest realny i niemal nieunikniony.
Co się dzieje w projekcie: każde „a jeszcze dodajmy” to nowa wycena, nowy termin, nowa walidacja reguł. Projekt, który miał kosztować 60 000 PLN i skończyć się w 10 tygodni, kończy się po 9 miesiącach za 180 000 PLN, i nikt nie pamięta, kto o tym zdecydował.
Najgorsze przypadki, które widzieliśmy: firma wybrała tańszego dostawcę, scope się rozlał, dostawca zszedł z projektu w połowie. Klient zadzwonił do nas po dwóch miesiącach ciszy ze strony poprzedniego zespołu. System częściowo działał, handlowcy dawno wrócili do Excela, zarząd chciał głowy dyrektora IT, który rekomendował tego dostawcę. Koszt naprawy? Zwykle dwu- do trzykrotność pierwotnego budżetu, plus miesiące straconego czasu na rynku konkurencji.
Jak tego uniknąć
Fixed Price na MVP, Time & Materials dopiero w fazie 2. Zakres MVP jest zapisany w umowie przed pierwszą linią kodu. Wszystko poza tym zakresem to „change request” z osobną wyceną. Brzmi sztywno? Właśnie o to chodzi.
MVP powinien być minimalny i gotowy do produkcji, nie „część rozwiązania, którą potem dopiszemy”. Zwalidowałeś kierunek, dopiero wtedy inwestujesz w rozbudowę. Nie działa jak miał, nie robisz fazy 2.
Problem 3: Integracja z ERP, który pamięta lata 2011
PROBLEM 3 · KAŻDY INTEGRATION POINT = FAILURE MODE
Stary SAP albo Comarch z 2011 nie ma API. Dev, który go konfigurował, odszedł 5 lat temu. Konfigurator pokazuje stare ceny, handlowiec sprzedaje poniżej cennika.
Twój konfigurator musi rozmawiać z ERP-em, bo tam siedzi cennik, stany magazynowe i dane klientów. Problem: Twój ERP to Comarch XL w wersji z 2011 albo SAP z customizacjami, które zrobił dev, który odszedł pięć lat temu. API nie ma. Dokumentacja nie istnieje. Jedyną osobą, która rozumie data model, jest księgowa, która odchodzi na emeryturę za pół roku.
Research DigiCommerce na B2B configurator implementation identyfikuje: każdy integration point to potential failure mode, który zepsuje całe UX. W praktyce to oznacza, że jedna zepsuta synchronizacja cennika między ERP a konfiguratorem pokaże klientowi błędną cenę, i to nie jest hipotetyczne. Widzieliśmy projekt, gdzie handlowiec sprzedał maszynę 15% poniżej realnego cennika, bo konfigurator pokazywał starą wersję z marca.
Jak tego uniknąć
Audyt ERP przed wdrożeniem. Pierwszy tydzień dyskusji to nie „jak ma wyglądać konfigurator”, tylko „jak wygląda wasz ERP, gdzie siedzi cennik, kto go aktualizuje, jakie pola są źródłem prawdy”. Jeśli ERP ma API, synchronizujemy w czasie rzeczywistym. Jeśli nie, piszemy custom middleware.
Alternatywa: budujemy konfiguratory z natywną integracją z JSON Hub, naszą platformą, która zastępuje trzy narzędzia (CRM + ofertowanie + panel dealerski) jednym. Wtedy problem integracji z ERP jest zredukowany do jednego connectora, a nie pięciu.
Problem 4: Handlowcy nie używają. Wracają do Excela.
PROBLEM 4 · 95% USAGE = REPS, DESIGN = ADMINS
Wydałeś 80-150k, system działa pięknie. Po 3 miesiącach handlowcy dalej liczą w Excelu. System zaprojektowany dla RevOps, używany przez handlowców, fundamentalny misalignment.
To najgorszy przypadek. Wydałeś 80-150 tysięcy PLN, konfigurator działa, interfejs wygląda pięknie. Po trzech miesiącach od launchu okazuje się, że handlowcy dalej liczą oferty w Excelu. Dlaczego?
Vendori w analizie „Why CPQ implementations fail” wskazuje kluczowy problem: „CPQ is designed for RevOps admins, but 95% of daily usage comes from sales reps”. System zaprojektowany dla dyrektora sprzedaży (który chce kontrolować marże i raporty) jest używany przez handlowca (który chce szybko wysłać ofertę klientowi). Fundamentalny misalignment.
Handlowiec, który przez 8 lat używał Excela, ma tam wszystko rozpisane: swoje skróty, swoje makra, swój sposób oceny klienta. Konfigurator wymaga od niego nauki na nowo, a Excel działa. W głowie: „to jest narzędzie IT, nie moje narzędzie sprzedaży”. Jeśli nikt z zarządu nie tłumaczy, dlaczego przechodzimy, i nie pokazuje „what’s in it for me”, handlowiec zignoruje.
Jak tego uniknąć
Handlowcy w zespole projektowym od dnia pierwszego. Nie na końcu. Od samego rozmowa wstępna. Dwóch-trzech handlowców siada z nami i mówi, co ich wkurza w obecnym procesie. Potem, na każdym sprincie, oglądają prototyp i komentują.
Incentive alignment: jeśli konfigurator skraca czas wyceny z 3 godzin do 15 minut, pokaż handlowcowi, że zamiast 2 ofert dziennie może wysłać 8, a jego prowizja jest od liczby zamkniętych ofert. To jest wtedy jego narzędzie, nie IT-ka.
Problem 5: Nikt nie zaplanował utrzymania. Konfigurator żyje 12 miesięcy i kłamie.
PROBLEM 5 · „ZBUDUJEMY I GOTOWE”
Brak planu utrzymania = po 12-18 miesiącach konfigurator pokazuje stare ceny, brakujące warianty, zepsute integracje. Handlowiec przestaje mu ufać. Wraca do Excela.
Współzałożyciel podpisuje umowę na wdrożenie. Konfigurator idzie do produkcji. Założenie w głowie: „zbudujemy i gotowe, teraz będzie działał”. Miesiąc później dodajesz nowy wariant produktu, konfigurator go nie zna. Kwartał później aktualizujesz cennik, konfigurator pokazuje stare ceny. Pół roku później integracja z API dostawcy przestaje działać, bo ten dostawca zmienił endpoint.
Research Kickflip: „każda godzina spędzona na utrzymaniu custom configurator code to godzina, której nie spędzasz na inicjatywach wzrostu”. Ale to jest prawda tylko wtedy, gdy NIE masz planu utrzymania. Jeśli masz, utrzymanie jest przewidywalnym kosztem jak abonament na CRM.
Typowy wzorzec: konfigurator działa świetnie przez pierwsze 6 miesięcy. Potem firma rozwija ofertę, ceny się zmieniają, integracje rdzewieją. Bez utrzymania, po 12-18 miesiącach masz system, który kłamie, pokazuje stare ceny, brakujące warianty, niedziałające opcje. Handlowiec przestaje mu ufać. Wraca do Excela (patrz: problem 4).
Realny przykład: klient wrócił do nas 18 miesięcy po launch z pytaniem „konfigurator pokazuje stare ceny, handlowcy go nie używają, co teraz?”. Audyt pokazał, że cennik nie był synchronizowany z nowymi produktami, które dodali w ciągu roku, a owner po stronie klienta odszedł trzy miesiące po launch i nikt nie przejął koordynacji. Koszt naprawy: dwa miesiące pracy + porządkowanie cennika, którego nikt w firmie już nie znał na pamięć.
Jak tego uniknąć
Plan utrzymania PRZED podpisaniem umowy wdrożeniowej. Nie po launch. Nie „jak będzie potrzeba”. Przed. Typowy roczny koszt: ~20% wartości projektu.
Do tego potrzebujesz ownera po stronie klienta, jednej osoby, która agreguje feedback. Bez tego dostawca dostaje 15 skrzynek mailowych z „tu coś nie działa” od 15 różnych handlowców. Szczegóły kosztów utrzymania w artykule o cenach konfiguratora.
Jak uniknąć błędów we wdrożeniu konfiguratora? 5 checkpointów
Przed podpisaniem umowy z software house’em, sprawdź te pięć rzeczy:
| Checkpoint | Czerwona flaga jeśli… | |
| 1 | Dokument reguł wyceny | SH mówi „ustalimy później” |
| 2 | Fixed Price + jasny zakres w umowie | Zakres w dokumencie „orientacyjnym” |
| 3 | Audyt ERP w pierwszym tygodniu | SH zakłada „damy sobie radę z integracją” |
| 4 | Handlowiec w zespole od dnia 1 | SH woli rozmawiać tylko z IT |
| 5 | Plan utrzymania w umowie głównej | Utrzymanie „dogadamy po launch” |
Jeśli software house opiera się na którymś z tych punktów, masz sygnał ostrzegawczy. Dobry partner nie boi się transparentności na tych pięciu obszarach, bo wie, że to one decydują o sukcesie, nie stack technologiczny.
Jak my to robimy w JSON Crew
Nasz proces wdrożenia konfiguratora opiera się na tych pięciu checkpointach od pierwszego dnia.
- Tydzień 0-1 (Rozmowa wstępna): siedzimy z handlowcami i konstruktorami, wyciskamy reguły wyceny, audytujemy ERP, mapujemy ścieżkę klienta. Wynik: 15-40 stron dokumentu reguł biznesowych, który klient akceptuje przed kodem.
- Tydzień 1-6 (Build): sprinty dwutygodniowe. Po każdym sprincie handlowiec-ambasador ogląda prototyp i komentuje. Scope jest Fixed Price, każda zmiana poza zakresem to osobny change request.
- Tydzień 6-10 (Wdrożenie + testy): konfigurator na stronie, testujemy z handlowcami klienta na realnych konfiguracjach. Tu wychodzą rzeczy, które w dokumencie wyglądały inaczej niż w rzeczywistości.
- Po launch: pakiet utrzymania z rocznym planem. Owner po stronie klienta agreguje feedback, my dostarczamy release co 2-4 tygodnie.
Portfolio: Akpil (maszyny rolnicze, 57 typów, setki parametrów), Knieja (broń myśliwska, konfiguracja modelu + osady + kalibru + akcesoriów), plus projekt z branży budowlanej. Dziesięć firm produkcyjnych korzysta z naszej platformy JSON Hub, która łączy konfigurator, CRM i ofertowanie w jednym miejscu, bez problemu integracji z ERP.
Pytania, które słyszymy najczęściej
„Mamy już konfigurator, który nie działa. Co teraz?”
Audyt istniejącego konfiguratora – 1-2 dni, bezpłatnie. Sprawdzamy: jakie reguły są w kodzie, jakie w głowie handlowca, co handlowcy realnie używają, gdzie są integracje, co jest zepsute, co da się uratować. Wynik: raport z rekomendacją, albo „uratujemy za X” albo „lepiej zaorać, oto dlaczego”. Nie ciągniemy sprzedaży, jeśli realnie nie da się uratować.
„Wdrożyliśmy, ale handlowcy nie używają. Da się to naprawić?”
Tak, ale zaczynamy od problemu nr 4, nie od technologii. Dwa-trzy warsztaty z handlowcami, żeby zrozumieć dlaczego nie używają. Zwykle to jedna z trzech rzeczy: interfejs zaprojektowany dla admina, brak komunikacji wewnętrznej wartości, albo brak incentive alignment. Każda wymaga innego fix.
„Czy JSON Crew robi projekty, które wymagają wymiany ERP?”
Nie robimy ERP, ale współpracujemy z partnerami w tej dziedzinie. Jeśli Twój ERP to blokada wdrożenia konfiguratora, polecimy partnera i wdrażamy konfigurator równolegle z migracją ERP. To drogie, ale czasem jedyna sensowna droga.
Co zrobić, jeśli rozważasz wdrożenie
|
Zamów rozmowę diagnostyczną 30 minut, bezpłatnie. Przyjdź z dwiema odpowiedziami: 1. Gdzie żyje Twój cennik (PDF, Excel, ERP, głowa handlowca)? 2. Ile ofert miesięcznie robią Twoi handlowcy i w jakim narzędziu? |
Wypełnij formularz |
Na tej podstawie powiemy: w który z pięciu problemów trafiłeś (albo trafisz), który software house warto zapytać o szczegóły, a od którego uciekać.
P.S. Najczęstsza reakcja po audycie istniejącego konfiguratora brzmi tak: „myślałem, że problem jest w kodzie, a okazuje się, że w procesie”. Zawsze. Dlatego 60% problemów to procesy, nie technologia. Dobra wiadomość: procesy da się naprawić szybciej i taniej niż przepisanie systemu od zera.
Najczęstsze pytania
Jakie są najczęstsze problemy przy wdrożeniu konfiguratora?
Pięć najczęstszych: 1) reguły wyceny żyją w głowie handlowca, nie w systemie (handlowiec wie, że klient X dostaje 5% rabatu „bo to klient strategiczny”, ale system nie); 2) scope creep („dodajcie jeszcze wariant Y”) wydłuża projekt z 8 do 18 tygodni; 3) integracja z ERP, który pamięta lata 2011, brak nowoczesnych API; 4) handlowcy nie używają konfiguratora, wracają do Excela; 5) brak planu utrzymania, konfigurator umiera w 12 miesięcy.
Dlaczego wdrożenie konfiguratora się nie udaje?
Najczęściej z powodu nie-technicznych przyczyn. 60% problemów to procesy: brak właściciela reguł wyceny po stronie klienta, brak commitmentu top managementu, brak planu adopcji wśród handlowców (szkolenia, incentive za używanie). Tylko ~40% to technologia, integracje z ERP, performance 3D, edge case-y w regułach. Sygnał czerwony: jeśli na rozmowa wstępna klient nie potrafi wskazać 1 osoby odpowiedzialnej za konfigurator po stronie firmy, projekt jest skazany na śmierć po launch.
Jak uniknąć błędów we wdrożeniu konfiguratora?
Pięć checkpointów przed startem: 1) warsztat z 3-5 handlowcami i wyciągnięcie wszystkich reguł wycen na papier (powinno zająć 2-3 dni); 2) wyznaczenie 1 osoby odpowiedzialnej za konfigurator po stronie klienta (product owner, nie IT); 3) zamknięty scope w specyfikacji, nowe wymagania = formalna zmiana umowy, nie „a, dodajcie jeszcze”; 4) plan adopcji handlowców (szkolenia + KPI używania w pierwszych 90 dniach); 5) plan utrzymania (kto dodaje produkty, kto fixuje bugi, ile godzin/mies. budżetu).
Ile trwa wdrożenie konfiguratora?
MVP custom konfiguratora w JSON Crew: 8 tygodni od podpisania umowy do produkcji. Pierwsza działająca wersja po 3 tygodniach (40% funkcjonalności). Gotowy CPQ SaaS (Tacton, Configure One): 8-16 tygodni wdrożenia (sama konfiguracja jest szybsza, ale integracje z ERP/PIM zajmują tyle samo). Szablon (WP plugin): 1-3 tygodnie. Główne źródło opóźnień to nie development, to dostarczanie danych przez klienta (BOM, cennik, wyjątki) i decyzje wewnętrzne.
Kto powinien być w zespole wdrożeniowym konfiguratora?
Po stronie klienta: 1 product owner (decyzje produktowe, dostarczanie danych, akceptacja milestone-ów), 1 osoba IT do integracji ERP/CRM, 2-3 handlowcy do warsztatu i UAT, 1 osoba zarządu jako sponsor (decyzje strategiczne, rozwiązywanie blokad). Po stronie dostawcy (np. JSON Crew): tech lead, frontend dev (Three.js dla 3D), backend dev (integracje), QA. Bez product owner-a po stronie klienta projekt grzęźnie, nie ma decyzji.
Co zrobić gdy zespół nie używa konfiguratora po wdrożeniu?
Trzy interwencje. Pierwsza: skontaktuj się z handlowcami i zapytaj wprost, dlaczego wracają do Excela, zwykle to konkretny bug („nie wycenia rabatu klienta strategicznego”) lub UX („za dużo kliknięć na prostą wycenę”). Druga: dodaj KPI używania konfiguratora do quartermaster review handlowca (% wycen przez konfigurator vs Excel). Trzecia: jeśli problem jest systemowy, konfigurator naprawdę nie pokrywa case-ów, wróć do specyfikacji i dorób brakujące funkcje. Brak rozwiązania = inwestycja 60 tys. zł leży odłogiem.
O autorze
Jędrzej Siewierski. CEO i współzałożyciel JSON Crew. Od 2024 buduje konfiguratory produktowe dla firm B2B (producenci maszyn rolniczych, broni myśliwskiej, domów modułowych, elektroniki IoT) oraz JSON Hub, własny SaaS łączący CRM, automatyczne ofertowanie i project management. Współautor metodologii cyfrowej transformacji sprzedaży: skracania drogi od zainteresowania do zakupu przez konfigurator + automatyczne ofertowanie + CRM. Stack: Next.js, Three.js, Nest.js, React Native. Kontakt: contact@jsoncrew.com · LinkedIn.
