{"id":1537,"date":"2026-04-16T10:02:23","date_gmt":"2026-04-16T08:02:23","guid":{"rendered":"https:\/\/jsoncrew.com\/?p=1537"},"modified":"2026-04-17T19:07:29","modified_gmt":"2026-04-17T17:07:29","slug":"5-problemow-wdrozenia-konfiguratora","status":"publish","type":"post","link":"https:\/\/jsoncrew.com\/de\/2026\/04\/16\/5-problemow-wdrozenia-konfiguratora\/","title":{"rendered":"5 h\u00e4ufigste Probleme bei der Implementierung eines Konfigurators und wie man sie vermeidet"},"content":{"rendered":"

60% custom konfigurator\u00f3w bez wiedzy domenowej ko\u0144czy si\u0119 pora\u017ck\u0105.<\/strong> 95% system\u00f3w CPQ jest zaprojektowanych dla administrator\u00f3w RevOps, podczas gdy 95% realnych u\u017cytkownik\u00f3w to handlowcy. Wed\u0142ug Standish CHAOS Report tylko 31% projekt\u00f3w IT ko\u0144czy si\u0119 sukcesem – 19% to totalna pora\u017cka.<\/em><\/p>\n

\n\"Zesp\u00f3\u0142
\n<\/figure>\n

Je\u015bli jeste\u015b po kilku miesi\u0105cach rozm\u00f3w z software house’ami albo masz ju\u017c wdro\u017cony konfigurator, kt\u00f3ry nie dzia\u0142a – ten artyku\u0142 jest dla Ciebie. Pi\u0119\u0107 rzeczy, kt\u00f3re zabijaj\u0105 projekty konfigurator\u00f3w, z danymi bran\u017cowymi i realnymi przyk\u0142adami z naszych wdro\u017ce\u0144. I konkretne rekomendacje, jak ich unikn\u0105\u0107.<\/p>\n

<\/p>\n

\n

60% problem\u00f3w to procesy, nie technologia. Tw\u00f3j konfigurator nie padnie przez kod. Padnie przez to, co dzieje si\u0119 wok\u00f3\u0142 niego.<\/p>\n<\/div>\n

<\/p>\n\n\n
\n

Masz ju\u017c konfigurator, kt\u00f3ry nie dzia\u0142a?<\/p>\n

Audyt 1-2 dni, bezp\u0142atnie. Powiemy wprost, czy da si\u0119 uratowa\u0107.<\/p>\n<\/td>\n

\nZam\u00f3w audyt<\/a>\n<\/td>\n<\/tr>\n<\/table>\n

Problem 1: Regu\u0142y wyceny \u017cyj\u0105 w g\u0142owie handlowca (nie w systemie)<\/h2>\n

<\/p>\n

\n
KONFIGURATOR<\/div>\n

Sprawd\u017a czy konfigurator ma sens u Ciebie<\/h3>\n

Ankieta 15 pyta\u0144 (3 min). Po wype\u0142nieniu wiemy oboje, czy jest o czym rozmawia\u0107.<\/p>\n

Wype\u0142nij checklist\u0119 \u2192<\/a>\n<\/div>\n

<\/p>\n

\n

PROBLEM 1 · NAJCZ\u0118STSZY POW\u00d3D OP\u00d3\u0179NIE\u0143<\/p>\n

Cennik w PDF, regu\u0142y wyklucze\u0144 w g\u0142owie konstruktora, 15 lat do\u015bwiadczenia handlowca – nigdzie nie spisane. Software house dostaje niepe\u0142ne regu\u0142y, koduje to co ma, testy wywracaj\u0105 projekt.<\/p>\n<\/div>\n

To najcz\u0119stszy pow\u00f3d, dla kt\u00f3rego projekty konfiguratora ci\u0105gn\u0105 si\u0119 miesi\u0105cami bez zauwa\u017calnych post\u0119p\u00f3w. Firma zg\u0142asza si\u0119 do software house’u, m\u00f3wi: „mamy cennik, mamy warianty, chcemy to zautomatyzowa\u0107”<\/em>. Na pierwszym spotkaniu okazuje si\u0119, \u017ce cennik to 136 stron PDF-a<\/strong> (realny case z naszego wdro\u017cenia dla Akpil), warianty to 16 wersji bazowych razy 30+ opcji dodatkowych, a regu\u0142y wyklucze\u0144 („wa\u0142 oponowy wymaga dyszla transportowego, ale dyszel transportowy jest niekompatybilny z systemem hydraulicznym X”) \u017cyj\u0105 w g\u0142owie konstruktora, kt\u00f3ry pracuje w firmie 15 lat.<\/p>\n

Badania Kickflip na custom configurator development<\/a> pokazuj\u0105: wdro\u017cenia bez wiedzy domenowej maj\u0105 60%+ failure rate<\/strong>. Dlaczego? Bo in\u017cynier, kt\u00f3ry nigdy nie sprzedawa\u0142 agregatu uprawowo-siewnego, nie zgaduje, \u017ce GPS wymaga komputera AK, a znaczniki hydrauliczne nie wsp\u00f3\u0142graj\u0105 z maszyn\u0105 poni\u017cej 3 metr\u00f3w szeroko\u015bci.<\/p>\n

Co si\u0119 dzieje w projekcie:<\/strong> software house dostaje niepe\u0142ne regu\u0142y. Koduje to, co dosta\u0142. Na etapie test\u00f3w okazuje si\u0119, \u017ce system pozwala skonfigurowa\u0107 maszyn\u0119, kt\u00f3rej nie da si\u0119 wyprodukowa\u0107. Rewriting rules = kolejne 2-4 tygodnie. Scope creep gotowy.<\/p>\n

W mi\u0119dzyczasie dyrektor projektu po stronie klienta dostaje telefon od CTO: „kiedy to b\u0119dzie gotowe?”<\/em>. Odpowied\u017a brzmi: „jak dostaniemy pe\u0142ne regu\u0142y od handlowca”<\/em>. Dwa tygodnie p\u00f3\u017aniej to samo pytanie, ta sama odpowied\u017a. Miesi\u0105c p\u00f3\u017aniej ten sam dialog, ale ju\u017c z nut\u0105 frustracji.<\/p>\n

<\/p>\n

\n

Jak tego unikn\u0105\u0107<\/p>\n

Tydzie\u0144 discovery PRZED lini\u0105 pierwszego kodu.<\/strong> U naszych klient\u00f3w zaczynamy od 5-7 dni siedzenia z handlowcami i konstruktorami. Mapujemy nie produkt, tylko \u015bcie\u017ck\u0119 klienta: jak klient pyta, co pyta najcz\u0119\u015bciej, jak handlowiec wycenia, jakie zale\u017cno\u015bci uruchamiaj\u0105 si\u0119 automatycznie. Dokument wyj\u015bciowy to 15-40 stron regu\u0142 w j\u0119zyku biznesowym (nie kodzie) – klient sam go czyta i koryguje. Dopiero po akceptacji dokumentu dotykamy klawiatury.<\/p>\n<\/div>\n

Problem 2: Scope creep \u2014 \u201ea dodajcie jeszcze…”<\/h2>\n

<\/p>\n

\n

PROBLEM 2 · \u201eFEW MONTHS” → 12-24 MIESI\u0118CY<\/p>\n

Zarz\u0105d widzi dzia\u0142aj\u0105cy konfigurator i chce wi\u0119cej: panel dealerski, CRM, aplikacja mobilna. Ka\u017cde \u201ejeszcze jedno” to nowa wycena i nowy termin. Projekt 60k\/10 tyg. ko\u0144czy si\u0119 po 9 miesi\u0105cach za 180k.<\/p>\n<\/div>\n

Tw\u00f3j konfigurator dzia\u0142a. Po trzech tygodniach pokazujesz go zarz\u0105dowi. Zarz\u0105d m\u00f3wi: „\u015bwietnie, ale mo\u017ce dodajmy panel dealerski? A jak ju\u017c b\u0119dziemy przy tym, to modu\u0142 CRM. A integracja z ksi\u0119gowo\u015bci\u0105? No i jeszcze aplikacja mobilna, bo handlowcy je\u017cd\u017c\u0105 do klient\u00f3w”<\/em>.<\/p>\n

Gratulacje, w\u0142a\u015bnie podwoi\u0142e\u015b projekt.<\/strong><\/p>\n

Research Kickflip<\/a> pokazuje typowy scenariusz: founder zak\u0142ada „a few months of development”, realne wdro\u017cenia rozci\u0105gaj\u0105 si\u0119 do 12-24 miesi\u0119cy<\/strong>. Nie dlatego, \u017ce zesp\u00f3\u0142 nie umie. Dlatego, \u017ce scope creep jest realny i niemal nieunikniony.<\/p>\n

Co si\u0119 dzieje w projekcie:<\/strong> ka\u017cde „a jeszcze dodajmy” to nowa wycena, nowy termin, nowa walidacja regu\u0142. Projekt, kt\u00f3ry mia\u0142 kosztowa\u0107 60 000 PLN i sko\u0144czy\u0107 si\u0119 w 10 tygodni, ko\u0144czy si\u0119 po 9 miesi\u0105cach za 180 000 PLN – i nikt nie pami\u0119ta, kto o tym zdecydowa\u0142.<\/p>\n

Najgorsze przypadki, kt\u00f3re widzieli\u015bmy: firma wybra\u0142a ta\u0144szego dostawc\u0119, scope si\u0119 rozla\u0142, dostawca zszed\u0142 z projektu w po\u0142owie. Klient zadzwoni\u0142 do nas po dw\u00f3ch miesi\u0105cach ciszy ze strony poprzedniego zespo\u0142u. System cz\u0119\u015bciowo dzia\u0142a\u0142, handlowcy dawno wr\u00f3cili do Excela, zarz\u0105d chcia\u0142 g\u0142owy dyrektora IT, kt\u00f3ry rekomendowa\u0142 tego dostawc\u0119. Koszt naprawy? Zwykle dwu- do trzykrotno\u015b\u0107 pierwotnego bud\u017cetu<\/strong> – plus miesi\u0105ce straconego czasu na rynku konkurencji.<\/p>\n

<\/p>\n

\n

Jak tego unikn\u0105\u0107<\/p>\n

Fixed Price na MVP, Time & Materials dopiero w fazie 2.<\/strong> Zakres MVP jest zapisany w umowie przed pierwsz\u0105 lini\u0105 kodu. Wszystko poza tym zakresem to „change request” z osobn\u0105 wycen\u0105. Brzmi sztywno? W\u0142a\u015bnie o to chodzi.<\/p>\n

MVP powinien by\u0107 minimalny i gotowy do produkcji<\/strong> – nie „cz\u0119\u015b\u0107 rozwi\u0105zania, kt\u00f3r\u0105 potem dopiszemy”. Zwalidowa\u0142e\u015b kierunek – dopiero wtedy inwestujesz w rozbudow\u0119. Nie dzia\u0142a jak mia\u0142 – nie robisz fazy 2.<\/p>\n<\/div>\n

Problem 3: Integracja z ERP, kt\u00f3ry pami\u0119ta lata 2011<\/h2>\n

<\/p>\n

\n

PROBLEM 3 · KA\u017bDY INTEGRATION POINT = FAILURE MODE<\/p>\n

Stary SAP albo Comarch z 2011 nie ma API. Dev, kt\u00f3ry go konfigurowa\u0142, odszed\u0142 5 lat temu. Konfigurator pokazuje stare ceny, handlowiec sprzedaje poni\u017cej cennika.<\/p>\n<\/div>\n

Tw\u00f3j konfigurator musi rozmawia\u0107 z ERP-em, bo tam siedzi cennik, stany magazynowe i dane klient\u00f3w. Problem: Tw\u00f3j ERP to Comarch XL w wersji z 2011 albo SAP z customizacjami, kt\u00f3re zrobi\u0142 dev, kt\u00f3ry odszed\u0142 pi\u0119\u0107 lat temu. API nie ma. Dokumentacja nie istnieje. Jedyn\u0105 osob\u0105, kt\u00f3ra rozumie data model, jest ksi\u0119gowa, kt\u00f3ra odchodzi na emerytur\u0119 za p\u00f3\u0142 roku.<\/p>\n

Research DigiCommerce na B2B configurator implementation<\/a> identyfikuje: ka\u017cdy integration point to potential failure mode<\/strong>, kt\u00f3ry zepsuje ca\u0142e UX. W praktyce to oznacza, \u017ce jedna zepsuta synchronizacja cennika mi\u0119dzy ERP a konfiguratorem poka\u017ce klientowi b\u0142\u0119dn\u0105 cen\u0119 – i to nie jest hipotetyczne. Widzieli\u015bmy projekt, gdzie handlowiec sprzeda\u0142 maszyn\u0119 15% poni\u017cej realnego cennika, bo konfigurator pokazywa\u0142 star\u0105 wersj\u0119 z marca.<\/p>\n

<\/p>\n

\n

Jak tego unikn\u0105\u0107<\/p>\n

Audyt ERP przed wdro\u017ceniem.<\/strong> Pierwszy tydzie\u0144 dyskusji to nie „jak ma wygl\u0105da\u0107 konfigurator”, tylko „jak wygl\u0105da wasz ERP, gdzie siedzi cennik, kto go aktualizuje, jakie pola s\u0105 \u017ar\u00f3d\u0142em prawdy”. Je\u015bli ERP ma API – synchronizujemy w czasie rzeczywistym. Je\u015bli nie – piszemy custom middleware.<\/p>\n

Alternatywa: budujemy konfiguratory z natywn\u0105 integracj\u0105 z JSON-Hub<\/a> – nasz\u0105 platform\u0105, kt\u00f3ra zast\u0119puje trzy narz\u0119dzia (CRM + ofertowanie + panel dealerski) jednym. Wtedy problem integracji z ERP jest zredukowany do jednego connectora, a nie pi\u0119ciu.<\/p>\n<\/div>\n

Problem 4: Handlowcy nie u\u017cywaj\u0105. Wracaj\u0105 do Excela.<\/h2>\n

<\/p>\n

\n

PROBLEM 4 · 95% USAGE = REPS, DESIGN = ADMINS<\/p>\n

Wyda\u0142e\u015b 80-150k, system dzia\u0142a pi\u0119knie. Po 3 miesi\u0105cach handlowcy dalej licz\u0105 w Excelu. System zaprojektowany dla RevOps, u\u017cywany przez handlowc\u00f3w – fundamentalny misalignment.<\/p>\n<\/div>\n

To najgorszy przypadek. Wyda\u0142e\u015b 80-150 tysi\u0119cy PLN, konfigurator dzia\u0142a, interfejs wygl\u0105da pi\u0119knie. Po trzech miesi\u0105cach od launchu okazuje si\u0119, \u017ce handlowcy dalej licz\u0105 oferty w Excelu. Dlaczego?<\/p>\n

Vendori w analizie „Why CPQ implementations fail”<\/a> wskazuje kluczowy problem: „CPQ is designed for RevOps admins, but 95% of daily usage comes from sales reps”<\/em>. System zaprojektowany dla dyrektora sprzeda\u017cy (kt\u00f3ry chce kontrolowa\u0107 mar\u017ce i raporty) jest u\u017cywany przez handlowca (kt\u00f3ry chce szybko wys\u0142a\u0107 ofert\u0119 klientowi). Fundamentalny misalignment.<\/strong><\/p>\n

Handlowiec, kt\u00f3ry przez 8 lat u\u017cywa\u0142 Excela, ma tam wszystko rozpisane: swoje skr\u00f3ty, swoje makra, sw\u00f3j spos\u00f3b oceny klienta. Konfigurator wymaga od niego nauki na nowo – a Excel dzia\u0142a. W g\u0142owie: „to jest narz\u0119dzie IT, nie moje narz\u0119dzie sprzeda\u017cy”<\/em>. Je\u015bli nikt z zarz\u0105du nie t\u0142umaczy, dlaczego przechodzimy, i nie pokazuje „what’s in it for me” – handlowiec zignoruje.<\/p>\n

<\/p>\n

\n

Jak tego unikn\u0105\u0107<\/p>\n

Handlowcy w zespole projektowym od dnia pierwszego.<\/strong> Nie na ko\u0144cu. Od samego discovery. Dw\u00f3ch-trzech handlowc\u00f3w siada z nami i m\u00f3wi, co ich wkurza w obecnym procesie. Potem, na ka\u017cdym sprincie, ogl\u0105daj\u0105 prototyp i komentuj\u0105.<\/p>\n

Incentive alignment:<\/strong> je\u015bli konfigurator skraca czas wyceny z 3 godzin do 15 minut, poka\u017c handlowcowi, \u017ce zamiast 2 ofert dziennie mo\u017ce wys\u0142a\u0107 8 – a jego prowizja jest od liczby zamkni\u0119tych ofert. To jest wtedy jego narz\u0119dzie, nie IT-ka.<\/p>\n<\/div>\n

Problem 5: Nikt nie zaplanowa\u0142 utrzymania. Konfigurator \u017cyje 12 miesi\u0119cy i k\u0142amie.<\/h2>\n

<\/p>\n

\n

PROBLEM 5 · \u201eZBUDUJEMY I GOTOWE”<\/p>\n

Brak planu utrzymania = po 12-18 miesi\u0105cach konfigurator pokazuje stare ceny, brakuj\u0105ce warianty, zepsute integracje. Handlowiec przestaje mu ufa\u0107. Wraca do Excela.<\/p>\n<\/div>\n

Founder podpisuje umow\u0119 na wdro\u017cenie. Konfigurator idzie do produkcji. Za\u0142o\u017cenie w g\u0142owie: „zbudujemy i gotowe, teraz b\u0119dzie dzia\u0142a\u0142”<\/em>. Miesi\u0105c p\u00f3\u017aniej dodajesz nowy wariant produktu – konfigurator go nie zna. Kwarta\u0142 p\u00f3\u017aniej aktualizujesz cennik – konfigurator pokazuje stare ceny. P\u00f3\u0142 roku p\u00f3\u017aniej integracja z API dostawcy przestaje dzia\u0142a\u0107, bo ten dostawca zmieni\u0142 endpoint.<\/p>\n

Research Kickflip<\/a>: „ka\u017cda godzina sp\u0119dzona na utrzymaniu custom configurator code to godzina, kt\u00f3rej nie sp\u0119dzasz na inicjatywach wzrostu”<\/em>. Ale to jest prawda tylko wtedy, gdy NIE masz planu utrzymania. Je\u015bli masz – utrzymanie jest przewidywalnym kosztem jak abonament na CRM.<\/p>\n

Typowy wzorzec: konfigurator dzia\u0142a \u015bwietnie przez pierwsze 6 miesi\u0119cy. Potem firma rozwija ofert\u0119, ceny si\u0119 zmieniaj\u0105, integracje rdzewiej\u0105. Bez utrzymania, po 12-18 miesi\u0105cach masz system, kt\u00f3ry k\u0142amie<\/strong> – pokazuje stare ceny, brakuj\u0105ce warianty, niedzia\u0142aj\u0105ce opcje. Handlowiec przestaje mu ufa\u0107. Wraca do Excela (patrz: problem 4).<\/p>\n

Realny przyk\u0142ad: klient wr\u00f3ci\u0142 do nas 18 miesi\u0119cy po launch z pytaniem „konfigurator pokazuje stare ceny, handlowcy go nie u\u017cywaj\u0105, co teraz?”<\/em>. Audyt pokaza\u0142, \u017ce cennik nie by\u0142 synchronizowany z nowymi produktami, kt\u00f3re dodali w ci\u0105gu roku, a owner po stronie klienta odszed\u0142 trzy miesi\u0105ce po launch i nikt nie przej\u0105\u0142 koordynacji. Koszt naprawy: dwa miesi\u0105ce pracy + porz\u0105dkowanie cennika, kt\u00f3rego nikt w firmie ju\u017c nie zna\u0142 na pami\u0119\u0107.<\/p>\n

<\/p>\n

\n

Jak tego unikn\u0105\u0107<\/p>\n

Plan utrzymania PRZED podpisaniem umowy wdro\u017ceniowej.<\/strong> Nie po launch. Nie „jak b\u0119dzie potrzeba”. Przed. Typowy roczny koszt: ~20% warto\u015bci projektu<\/strong>.<\/p>\n

Do tego potrzebujesz ownera po stronie klienta<\/strong> – jednej osoby, kt\u00f3ra agreguje feedback. Bez tego dostawca dostaje 15 skrzynek mailowych z „tu co\u015b nie dzia\u0142a” od 15 r\u00f3\u017cnych handlowc\u00f3w. Szczeg\u00f3\u0142y koszt\u00f3w utrzymania w artykule o cenach konfiguratora<\/a>.<\/p>\n<\/div>\n

Podsumowanie: 5 checkpoint\u00f3w przed wdro\u017ceniem<\/h2>\n

Przed podpisaniem umowy z software house’em, sprawd\u017a te pi\u0119\u0107 rzeczy:<\/p>\n

<\/p>\n\n\n\n\n\n\n\n
<\/td>\nCheckpoint<\/td>\nCzerwona flaga je\u015bli…<\/td>\n<\/tr>\n
1<\/td>\nDokument regu\u0142 wyceny<\/strong><\/td>\nSH m\u00f3wi „ustalimy p\u00f3\u017aniej”<\/td>\n<\/tr>\n
2<\/td>\nFixed Price + jasny zakres w umowie<\/strong><\/td>\nZakres w dokumencie „orientacyjnym”<\/td>\n<\/tr>\n
3<\/td>\nAudyt ERP w pierwszym tygodniu<\/strong><\/td>\nSH zak\u0142ada „damy sobie rad\u0119 z integracj\u0105”<\/td>\n<\/tr>\n
4<\/td>\nHandlowiec w zespole od dnia 1<\/strong><\/td>\nSH woli rozmawia\u0107 tylko z IT<\/td>\n<\/tr>\n
5<\/td>\nPlan utrzymania w umowie g\u0142\u00f3wnej<\/strong><\/td>\nUtrzymanie „dogadamy po launch”<\/td>\n<\/tr>\n<\/table>\n

Je\u015bli software house opiera si\u0119 na kt\u00f3rym\u015b z tych punkt\u00f3w – masz sygna\u0142 ostrzegawczy. Dobry partner nie boi si\u0119 transparentno\u015bci na tych pi\u0119ciu obszarach, bo wie, \u017ce to one decyduj\u0105 o sukcesie, nie stack technologiczny.<\/p>\n

Jak my to robimy w JSON Crew<\/h2>\n

Nasz proces wdro\u017cenia konfiguratora opiera si\u0119 na tych pi\u0119ciu checkpointach od pierwszego dnia.<\/p>\n