Jak zbudować system konfiguracji i oferty dla produkcji, który nie kończy się Excelem w przebraniu?

System konfiguracji, ceny i oferty, często nazywany skrótem CPQ, prowadzi klienta lub handlowca od wyboru wariantu, przez cenę, aż do gotowego dokumentu oferty. W prostym sklepie wariant "kolor + rozmiar" wystarczy. W produkcji dla klientów firmowych konfiguracja może oznaczać setki zależności: silnik, materiał, certyfikację, gabaryt, rynek docelowy, napięcie, termin dostawy, rabat kontraktowy, dostępność komponentu, dopuszczalne akcesoria i warunki gwarancji.

Dlatego dobry system konfiguracji i oferty nie zaczyna się od efektownego widoku 3D. Zaczyna się od pytania: kto jest źródłem prawdy dla reguł? Jeśli reguły siedzą w arkuszach, głowach inżynierów i mailach od produkcji, konfigurator tylko przyspieszy tworzenie błędnych ofert. Jeśli reguły zostaną opisane jako część logiki produktu, system może skrócić cykl sprzedaży bez zwiększania ryzyka produkcyjnego.

W GMI Software patrzymy na taki system jak na sprzedaż firmową, zaplecze reguł i połączenia z systemami. MedusaJS może obsłużyć rdzeń sprzedażowy, cenniki, koszyk i kanały sprzedaży. NestJS może utrzymać reguły, walidację, akceptacje, dokumenty oraz połączenia z systemem finansowo-magazynowym, bazą produktów i narzędziami projektowymi. Next.js daje szybki portal klienta lub handlowca, a BabylonJS i WebGL mają sens wtedy, gdy widok 3D pomaga podjąć decyzję, a nie tylko wygląda efektownie.

W wielu firmach pierwsza wersja systemu konfiguracji i oferty jest przepisanym arkuszem kalkulacyjnym: pola wyboru, kilka warunków i dokument oferty na końcu. Przez pierwsze tygodnie wygląda to jak sukces. Potem pojawiają się wyjątki: klient strategiczny ma inną marżę, rynek niemiecki wymaga innego certyfikatu, rama A nie pasuje do silnika B, komponent jest dostępny tylko w zakładzie X, a dział finansowy musi zaakceptować rabat powyżej progu.

Jeśli system nie ma jasno opisanej logiki produktu i procesu, każda taka reguła staje się kolejnym warunkiem w interfejsie albo kolejną kolumną w arkuszu. Po roku nikt nie wie, dlaczego konfiguracja została zablokowana, kto zatwierdził wyjątek i czy dokument oferty zgadza się z tym, co system finansowo-magazynowy może wyprodukować oraz zafakturować.

Lepsze podejście jest inne: osobno trzymasz katalog produktu, reguły zgodności, wycenę, zestawienie materiałowe, ścieżkę akceptacji, dokumenty oferty i połączenia z systemami. Interfejs prowadzi użytkownika przez decyzję. Zaplecze musi umieć powiedzieć, dlaczego dany zestaw jest niemożliwy i co trzeba zmienić, żeby konfiguracja mogła trafić do produkcji.

Pierwsza decyzja techniczna brzmi: czy produkt da się opisać zwykłymi wariantami, czy potrzebuje osobnego silnika reguł. Warianty wystarczą, gdy kombinacje są ograniczone i stabilne. Ograniczenia są potrzebne, gdy wybór jednego komponentu wpływa na dziesięć kolejnych, a reguły wynikają z fizyki produktu, norm, produkcji albo gwarancji.

Salesforce opisuje nowoczesny konfigurator jako system z regułami opartymi o decyzje i ograniczenia. To ważne rozróżnienie. Reguła "jeśli klient jest partnerem złotym, daj rabat" dotyczy wyceny. Ograniczenie "silnik 20 kW nie może występować z ramą aluminiową" dotyczy zgodności produktu. Akceptacja "rabat powyżej 12% wymaga zgody finansów" dotyczy procesu decyzyjnego. Mieszanie ich w jednym miejscu kończy się chaosem.

W rozpoznaniu biznesu, projektu i technologii zaczynamy od drzewa decyzji i macierzy konfliktów. Dla każdej reguły zapisujemy właściciela, źródło prawdy, konsekwencję biznesową i sposób testowania. Reguły bez właściciela nie powinny trafiać do kodu, bo po pierwszym sezonie sprzedaży nikt nie będzie umiał ich bezpiecznie utrzymać.

System konfiguracji bez szybkiej, sprawdzalnej wyceny jest tylko katalogiem. W sprzedaży firmowej cena zależy od klienta, regionu, wolumenu, waluty, rabatu kontraktowego, dostępności komponentów, kosztu materiału, marży minimalnej, opcji serwisowej i terminu dostawy. Oracle podkreśla wycenę w czasie rzeczywistym, wielopoziomowe cenniki, ceny zależne od kanału, promocje oraz akceptacje jako rdzeń takiego procesu.

MedusaJS daje dobrą bazę dla własnej wyceny firmowej: moduł wyceny obsługuje ceny w wielu walutach i regionach, listy cenowe, progi, własne reguły oraz strategię wyboru najlepszej ceny w kontekście. Moduł produktu wspiera warianty, produkty złożone z wielu części oraz ceny progowe. To nie jest gotowy system konfiguracji dla dużej organizacji po instalacji, ale są tam właściwe obszary sprzedażowe, na których można budować.

Najważniejsza zasada: wycena musi być możliwa do sprawdzenia. Handlowiec, dyrektor finansowy i klient firmowy powinni rozumieć, skąd wzięła się cena: lista bazowa, rabat kontraktowy, dopłata za konfigurację, koszt komponentu, rabat progowy, waluta, transport i marża. Jeśli cena jest "magicznym wynikiem", zespół nie zaufa systemowi i wróci do arkuszy.

System konfiguracji i oferty nie powinien zastępować systemu finansowo-magazynowego ani narzędzi projektowych. System finansowo-magazynowy zwykle przechowuje klientów, umowy, stany, zamówienia, faktury, koszt materiału i proces produkcyjny. Baza produktów przechowuje opisy, parametry i treści produktowe. Narzędzie projektowe lub system zarządzania cyklem życia produktu przechowuje dane konstrukcyjne i modele. Konfigurator powinien połączyć te źródła w decyzję handlową, a nie tworzyć kolejną kopię prawdy.

Praktyczna architektura zależy od dojrzałości firmy. Jeśli system finansowo-magazynowy ma stabilne połączenie, konfigurator może pobierać dostępność, koszt i status klienta w czasie zbliżonym do rzeczywistego. Jeśli ten system jest wolny lub trudny, budujemy warstwę połączeń i pamięć podręczną z jasną polityką świeżości danych. Jeśli narzędzie projektowe nie udostępnia danych w sposób automatyczny, zaczynamy od eksportu parametrów i kontroli wersji obiektów 3D lub dokumentacji.

Największe ryzyko to brak kontroli wersji. Oferta wygenerowana w poniedziałek musi dać się odtworzyć w piątek: na jakich regułach, cenach, kosztach i danych produktu powstała? Bez zapisu konfiguracji i ceny każda reklamacja albo renegocjacja staje się śledztwem.

3D jest wartościowe wtedy, gdy zmniejsza niepewność klienta albo koszt obsługi sprzedaży. Dla maszyn, zabudów, mebli modułowych, urządzeń, hal, pojazdów i produktów gabarytowych wizualizacja może pokazać proporcje, kolizje, akcesoria, wariant materiału i konsekwencje wyboru. Dla prostych produktów 3D potrafi być drogim dodatkiem bez wpływu na decyzję.

WebGL pozwala wyświetlać interaktywną grafikę 2D i 3D w przeglądarce bez dodatkowych wtyczek, korzystając z akceleracji sprzętowej urządzenia. BabylonJS daje wygodną warstwę do scen, materiałów, kamer, świateł, interakcji i importu obiektów 3D. W systemie konfiguracji najważniejsze nie jest jednak to, czy widok się obraca, tylko czy wizualizacja jest zgodna z regułami i zestawieniem materiałowym.

Dlatego rozdzielamy widok 3D od silnika decyzji. Wizualizacja pokazuje wynik konfiguracji, ale nie decyduje o kompatybilności. Jeśli użytkownik wybierze niedozwolony zestaw, zaplecze blokuje konfigurację i wyjaśnia powód. 3D aktualizuje się po walidacji, a nie staje się źródłem prawdy.

Najbezpieczniejszy zakres pierwszej wersji to jedna linia produktowa, jeden kanał sprzedaży i ograniczony zestaw reguł, które powodują największy koszt ręcznej obsługi. Nie zaczynaj od wszystkich rodzin produktów, wszystkich rynków, pełnych danych projektowych, wszystkich rabatów i kompletnej automatyzacji produkcji. To prosta droga do rocznego projektu bez wartości po drodze.

Pierwsze wydanie powinno udowodnić trzy rzeczy: użytkownik potrafi skonfigurować produkt bez handlowca, system blokuje konfiguracje niemożliwe do produkcji, a cena i oferta zgadzają się z systemem finansowo-magazynowym oraz zasadami marży. Dopiero potem warto dodawać 3D, samoobsługę dla klientów, portal partnerski, automatyczne akceptacje, generowanie zestawienia materiałowego, połączenia z narzędziami projektowymi i kolejne kanały sprzedaży.

W rozpoznaniu biznesu, projektu i technologii mapujemy zakres jako jedną ścieżkę przechodzącą przez system: od konfiguracji do oferty, zamówienia i przekazania danych do właściwych systemów. Dzięki temu zarząd widzi działający proces, a zespół techniczny testuje najtrudniejsze ryzyka wcześniej: reguły, wycenę, dane finansowo-magazynowe, dokumenty i uprawnienia.

Koszt systemu konfiguracji i oferty nie zależy głównie od liczby ekranów. Zależy od liczby reguł, jakości danych produktowych, gotowości systemu finansowo-magazynowego i połączeń z nim, liczby cenników, wymagań akceptacji, dokumentów oferty, ról użytkowników, języków, walut, zakresu 3D i tego, czy system ma działać jako portal samoobsługowy dla klientów, narzędzie dla handlowców czy oba naraz.

W praktyce sensowny pierwszy zakres dla producenta sprzedającego firmom często zaczyna się od 200 000-450 000 PLN: rozpoznanie biznesu, projektu i technologii, opis logiki produktu i procesu, zaplecze reguł, portal dla klientów firmowych, podstawowa wycena, połączenie z systemem finansowo-magazynowym i bazą produktów, dokument oferty, role użytkowników i testy. 3D, narzędzia projektowe, zaawansowane akceptacje, portal partnerski, wielorynkowość i automatyczne zestawienie materiałowe potrafią istotnie zwiększyć zakres.

Dlatego nie obiecujemy ceny po jednej rozmowie. Najpierw rozpoznajemy reguły produktu, połączenia z systemami, dane, doświadczenie użytkownika, architekturę, ryzyka, priorytety pierwszej wersji i sposób utrzymania. Dopiero wtedy stała cena ma sens, bo budżet wynika z opisanego zakresu, a nie z życzeniowego opisu potrzeby.

Jeśli przygotowujesz system konfiguracji, ceny i oferty, zbierz odpowiedzi przed pierwszą wyceną. To skraca rozpoznanie projektu i szybko pokazuje, czy projekt jest przede wszystkim problemem konfiguracji, wyceny, danych, połączeń z systemami, doświadczenia użytkownika czy zmiany organizacyjnej.

• Która linia produktowa ma największy koszt ręcznej wyceny lub najwięcej błędów?
• Gdzie dziś żyją reguły: system finansowo-magazynowy, Excel, narzędzia projektowe, baza produktów, dokumentacja, wiedza inżynierów?
• Które reguły blokują produkcję, a które tylko wpływają na cenę lub termin?
• Czy system finansowo-magazynowy pozwala bezpiecznie pobierać dane klientów, stanów, cenników, zamówień i faktur?
• Czy potrzebujesz samoobsługi dla klientów, panelu handlowca, portalu partnerskiego czy wszystkich naraz?
• Czy oferta musi generować zestawienie materiałowe, dokument oferty, umowę, proformę, zamówienie lub zadanie produkcyjne?
• Jakie role zatwierdzają rabaty, wyjątki techniczne i nietypowe terminy dostawy?
• Czy 3D zmniejszy liczbę pytań i błędów, czy będzie tylko warstwą marketingową?

GMI nie zaczyna takiego projektu od wyboru biblioteki 3D. Zaczynamy od procesu sprzedaży, marży, danych produktowych, systemu finansowo-magazynowego, ról użytkowników i ryzyk produkcyjnych. Dopiero potem wybieramy technologię: MedusaJS dla rdzenia sprzedażowego, NestJS dla reguł i połączeń z systemami, Next.js dla portalu, PostgreSQL dla danych, BabylonJS i WebGL dla 3D, jeśli realnie pomaga klientowi podjąć decyzję.

Najważniejszy efekt rozpoznania biznesu, projektu i technologii to mapa odpowiedzialności: co jest w systemie finansowo-magazynowym, co w konfiguratorze, co w bazie produktów, co w narzędziach projektowych, co w portalu sklepowym i jak odtworzyć ofertę po miesiącu. Taka mapa pozwala wejść w stałą cenę po rozpoznaniu projektu, a nie udawać, że złożoność produkcji da się wycenić z samego hasła "konfigurator 3D".

Dla klienta oznacza to mniej ryzyka: własność kodu źródłowego, brak uzależnienia od dostawcy, architektura gotowa na połączenia z systemami oraz możliwość rozwijania systemu etapami. Pierwsze wydanie ma dostarczyć działającą ścieżkę od konfiguracji przez cenę i ofertę do zamówienia. Dopiero potem skalujemy produkt, kanały, rynki i automatyzację.