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 |
Problem 1: Reguły wyceny żyją 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ń discovery 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: founder 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 discovery. 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.
Founder 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.
Podsumowanie: 5 checkpointów przed wdrożeniem
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 (Discovery): 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.
