CPQ w produkcji: wycena i konfiguracja z danymi z SAP
Opublikowano: 18 września 2026
W firmie produkującej na zamówienie oferta na skonfigurowany produkt powstaje kilka dni. Handlowiec pyta technologa, czy dana kombinacja opcji jest wykonalna, potem controlling liczy cenę, a na końcu ktoś sprawdza, czy komponenty będą dostępne w terminie. Narzędzia klasy CPQ obiecują skrócenie tego do minut, ale obietnica trzyma się tylko wtedy, gdy reguły konfiguracji, ceny i dostępność w konfiguratorze są tymi samymi, które zna SAP. Jeśli są kopią, oferta jest szybka i co jakiś czas błędna, a błąd wychodzi dopiero na produkcji.
Co się zmieniło po stronie Salesforce
Firma, która wybiera narzędzie do wyceny w Salesforce w 2026 roku, trafia na zmianę produktową. Salesforce ogłosił, że Salesforce CPQ jest w fazie końca sprzedaży, ale nie końca życia: obecni klienci mogą odnawiać licencje, dokupować użytkowników i dostają wsparcie, ale rozwój skupia się na następcy, czyli Revenue Cloud Advanced, który wraz z rozliczeniami tworzy pakiet nazwany w 2025 roku Agentforce Revenue Management. Salesforce podaje na tej samej stronie, że około 15% klientów nowego produktu to firmy, które przeszły ze starego CPQ, i zapewnia, że migracja nie jest wymuszona.
Różnica między produktami jest istotna dla integracji z SAP. Stary CPQ to pakiet zarządzany z konfiguratorem opartym na regułach i pakietach SKU. Nowy produkt jest zbudowany natywnie na platformie z podejściem API-first: osobne moduły katalogu produktów, wyceny opartej na tabelach decyzyjnych i procedurach, konfiguratora z silnikiem reguł ograniczeń, zarządzania transakcjami oraz rozliczeń. Dla architekta oznacza to, że dane z SAP można wstrzykiwać do konkretnego modułu przez API, zamiast obchodzić pakiet.
Od lipca 2025 roku w tym pakiecie działa też agent do tworzenia ofert. Salesforce deklaruje na własnym przykładzie skrócenie czasu przygotowania oferty o 75%, ale to wynik podany przez dostawcę o własnym wdrożeniu, więc traktuj go jako kierunek, nie jako benchmark. Agent, który składa ofertę, sięga do tych samych reguł i cen co człowiek, więc poprawność jego ofert zależy od integracji z SAP.
Gdzie mieszka prawda o produkcie
W firmie produkcyjnej z SAP wiedza o tym, co da się wyprodukować i za ile, jest w trzech miejscach systemu. Reguły wariantów w konfiguracji wariantowej, klasycznej LO-VC albo Advanced Variant Configuration w S/4HANA, często budowane przez lata przez technologów. Ceny w rekordach warunków cenowych z rabatami, skalami i okresami ważności. Dostępność w kontroli ATP, która zna alokacje i ochronę zapasów.
SAP ma zresztą własny konfigurator sprzedażowy: w Magic Quadrant Gartnera dla CPQ opublikowanym w styczniu 2026 roku SAP CPQ jest liderem ósmy rok z rzędu. Wybór Salesforce do wyceny w firmie z SAP nie wynika więc z braku alternatywy, tylko zwykle z tego, że handlowcy już pracują w Salesforce i tam jest historia klienta, szanse sprzedaży i prognoza. Konsekwencją tego wyboru jest pytanie, które rozstrzyga cały projekt: kto jest właścicielem reguł konfiguracji.
Trzy wzorce i ich koszty
Z projektów widać trzy sposoby połączenia konfiguratora w Salesforce z SAP, o rosnącej złożoności i malejącym ryzyku rozjazdu.
Reguły i ceny przepisane do Salesforce. Konfigurator w Salesforce ma własny model produktu, własne reguły ograniczeń i własny cennik, a SAP dostaje gotowe, skonfigurowane zamówienie. To najszybsze wdrożenie i najczęstszy powód późniejszych problemów, bo każda zmiana w LO-VC albo w cenniku wymaga ręcznego odbicia w Salesforce. W firmie ze stu aktywnymi cechami wariantu i kwartalnymi zmianami cen rozjazd jest kwestią miesięcy, a nie lat.
Interfejs w Salesforce, silnik z SAP. SAP udostępnia na BTP usługę konfiguracji wariantowej, która replikuje bazę wiedzy LO-VC lub AVC do chmury i konfiguruje produkty interaktywnie, oraz usługę wyceny pracującą na danych cenowych replikowanych z S/4HANA. Standardowo korzystają z nich SAP Commerce Cloud i SAP CPQ, ale SAP opisuje też własne aplikacje jako dopuszczonych konsumentów, co otwiera drogę dla Salesforce. Reguły są utrzymywane raz, w SAP, a Salesforce tylko je wywołuje. Kosztem jest licencja na usługi BTP i praca nad interfejsem użytkownika, bo Salesforce dostaje wynik konfiguracji, a nie gotowy ekran.
Symulacja zamówienia w SAP. Najprostszy wariant po stronie logiki: Salesforce składa ofertę, a przed jej wysłaniem wywołuje w S/4HANA symulację zamówienia sprzedaży, która zwraca wycenę, wynik kontroli kredytowej i dostępność bez zapisywania dokumentu. Reguły konfiguracji nadal trzeba mieć w Salesforce, ale cena i termin są zawsze z SAP. Ten wzorzec dobrze działa dla produktów o umiarkowanej liczbie wariantów, gdzie ryzyko leży w cenie i terminie, a nie w wykonalności.
Wybór między drugim a trzecim wzorcem zależy od tego, ile reguł wykonalności ma produkt. Część z nich istnieje tylko w głowach technologów i wychodzi dopiero przy próbie ich spisania.
Od oferty w Excelu do konfiguratora
Jeśli Twoja firma jest gdzieś na tej drodze, na konferencji porównasz swój etap z innymi producentami, którzy łączą sprzedaż z SAP.
Zarejestruj się za darmo ↗Co płynie między systemami
Niezależnie od wzorca kilka strumieni danych jest stałych. Dane podstawowe produktów wychodzą z SAP i budują katalog w Salesforce. Ceny i rabaty, jeśli mają być w Salesforce, idą z rekordów warunków cenowych razem z okresami ważności i skalami. Dostępność sprawdza się przez API zaawansowanej kontroli ATP, które uwzględnia alokacje i ochronę zapasów, a nie sam stan magazynu. Zaakceptowana oferta staje się zamówieniem przez API Sales Order, a numer dokumentu SAP wraca do Salesforce, żeby handlowiec widział status bez logowania do ERP.
Gotowe treści integracyjne istnieją, ale są starsze niż nowy produkt Salesforce. MuleSoft Accelerator for SAP zawiera scenariusz quote-to-cash, w którym S/4HANA jest systemem odniesienia dla warunków cenowych, Salesforce pobiera cenę netto i stan zapasów, a szansa sprzedaży zamienia się w zamówienie SAP, ale scenariusz jest napisany dla starego Salesforce CPQ. Dla Revenue Cloud Advanced gotowego pakietu z SAP nie znaleźliśmy, więc przy nowym produkcie należy liczyć na własną pracę nad mapowaniem.
Na co uważać
Pierwsza pułapka to dane podstawowe. Konfigurator ujawnia każdy błąd w kartotece materiałowej: brakującą cechę, nieaktualną cenę, komponent bez daty ważności. Firmy, które najpierw uruchomiły CPQ, a potem porządkowały dane, zwykle wyłączały część reguł na kilka miesięcy. Pisaliśmy osobno, dlaczego jakość danych jest warunkiem każdego projektu, który ma automatyzować decyzje.
Druga to czas odpowiedzi. Symulacja zamówienia w S/4HANA jest wywołaniem synchronicznym, a SAP wykonuje dla każdej pozycji pełną procedurę cenową z dostępem do rekordów warunków i osobną kontrolę dostępności. Dla oferty z kilkoma pozycjami trwa to sekundę lub dwie, dla koszyka z kilkuset pozycjami w dystrybucji części zamiennych może trwać dziesiątki sekund, a wywołanie po drodze przechodzi jeszcze przez platformę integracyjną i jej limity czasu. Handlowiec to zaakceptuje, klient w portalu samoobsługowym już nie. Zwykle rozwiązuje się to trzema sposobami: ceny listowe buforuje się w Salesforce i SAP pyta się tylko przy finalizacji, dużą ofertę dzieli się na porcje wysyłane równolegle, a kontrolę ATP ogranicza do pozycji konfigurowalnych, bo dla części katalogowych wystarczy stan z replikacji. Każdy z tych sposobów wprowadza kopię danych, którą trzeba odświeżać, więc to wybór między szybkością a świeżością, a nie rozwiązanie problemu.
Trzecia to zmiany inżynierskie. Nowa wersja komponentu w SAP unieważnia część konfiguracji w otwartych ofertach, a Salesforce o tym nie wie, jeśli integracja przenosi tylko nowe dane, a nie zmiany. Wzorzec z silnikiem po stronie SAP rozwiązuje to samoczynnie, wzorce z kopią reguł wymagają procesu, w którym technolog powiadamia sprzedaż, podobnie jak zmiana na hali wymaga powiadomienia planowania przy integracji SAP z MES.
Czwarta dotyczy agentów. Agent w Salesforce składający oferty sięga do tych samych interfejsów co człowiek, więc bez dostępu do symulacji w SAP poda cenę z kopii cennika i nikt tego nie zauważy, dopóki zamówienie nie trafi do SAP z inną wartością.
FAQ
Czy Salesforce CPQ przestaje działać?
Nie. Salesforce ogłosił koniec sprzedaży dla nowych klientów, ale nie koniec życia produktu: obecni klienci mogą odnawiać licencje, dokupować użytkowników i dostają wsparcie oraz poprawki. Nowe funkcje trafiają do Revenue Cloud Advanced, a migracja nie jest wymuszona.
Czy reguły konfiguracji produktu trzeba utrzymywać w dwóch miejscach?
Nie, jeśli konfigurator w Salesforce korzysta z usług konfiguracji wariantowej i wyceny SAP na BTP, które replikują bazę wiedzy LO-VC lub AVC z S/4HANA. Jeśli reguły są przepisane do Salesforce, trzeba je utrzymywać podwójnie i zaplanować proces synchronizacji zmian, bo rozjazd pojawia się w ciągu miesięcy.
Czy wycena w Salesforce może pobierać ceny z SAP w czasie rzeczywistym?
Tak, przez symulację zamówienia sprzedaży w S/4HANA, która zwraca wycenę, kontrolę kredytową i dostępność bez zapisywania dokumentu. Wywołanie jest synchroniczne i dla ofert z setkami pozycji trwa dziesiątki sekund, więc wykonuje się je przy finalizacji, a w trakcie pracy handlowca korzysta z cen listowych zbuforowanych w Salesforce.
Czy CPQ ma sens, gdy każda oferta wymaga wyceny inżynierskiej?
Częściowo. Dla produktów projektowanych pod zamówienie konfigurator obsłuży powtarzalną część oferty, czyli standardowe moduły, usługi i warunki handlowe, a część inżynierską przekaże jako pozycję do wyceny ręcznej. Zysk jest mniejszy niż w produkcji wariantowej, ale nadal skraca obieg oferty i porządkuje dane, które trafiają do SAP.