Jak zbudowaliśmy cykl życia przychodów ze sprzętu POS i subskrypcji

Transakcja sprzedaży wyposażenia punktu sprzedaży przestaje być prosta, gdy jedna umowa obejmuje terminale, skanery, drukarki, urządzenia płatnicze, subskrypcje oprogramowania, instalację, szkolenia i wsparcie. Każda pozycja może podlegać innym regułom konfiguracji, warunkom umowy, etapom realizacji i harmonogramom fakturowania. Jeśli architektura łączy wyłącznie rekordy CRM z rekordami ERP, firma nadal nie może wiarygodnie śledzić, co zostało sprzedane, zaakceptowane, dostarczone, zainstalowane, zafakturowane, zmienione lub odnowione.

Dla amerykańskiego dostawcy technologii dla handlu detalicznego wdrożyliśmy obsługę całego cyklu przychodowego dla sprzętu POS w Salesforce i SAP. W tym artykule wyjaśniamy decyzje projektowe opisane w pełnym studium przypadku wdrożenia: odpowiedzialność poszczególnych systemów, modelowanie produktów, konfigurację, ustalanie cen, koordynację realizacji zamówień, dostawy, rozliczenia i zmiany po sprzedaży.

Kluczowa decyzja projektowa

Potraktowaliśmy projekt jako wdrożenie architektury przychodowej, a nie odrębne wdrożenie CPQ. Każda decyzja handlowa musiała zachować użyteczność dla zespołów i systemów odpowiedzialnych za realizację zamówień, księgowość oraz bieżące relacje z klientem.

Jakie problemy miało rozwiązać wdrożenie

Klient przeniósł swój dział sprzedaży z HubSpot do Salesforce Sales Cloud, natomiast SAP pozostał platformą do planowania zasobów przedsiębiorstwa. Podstawowa integracja katalogu synchronizowała informacje o produktach, ale nie zapewniała niezawodnej ścieżki od zamknięcia szansy sprzedaży przez przyjęcie zamówienia, dostawę, instalację i fakturowanie aż po odnowienie.

Mieszane modele przychodowe

Jedna transakcja musiała uwzględniać jednorazową sprzedaż sprzętu, oprogramowanie na określony czas, cykliczne wsparcie, usługi oraz różne częstotliwości rozliczeń.

Ryzyko związane z konfiguracją

Trudno było zarządzać zgodnością komponentów i zależnościami między ich ilościami bez tworzenia setek niemal identycznych handlowych SKU.

Brak spójności w realizacji

Zamknięta szansa sprzedaży nie potwierdzała, że SAP przyjął zamówienie ani że zakończono prace magazynowe, dostawę i instalację.

Rozproszona obsługa zmian u klienta

Dodatkowe lokalizacje, rozszerzenia, rezygnacje i odnowienia obsługiwano jako nową sprzedaż zamiast jako zmiany w istniejących zasobach i subskrypcjach.

Projekt łączył zatem wdrożenie Salesforce z integracją i projektowaniem modelu operacyjnego. Celem nie był jeden uniwersalny system źródłowy, lecz jeden nadrzędny właściciel każdej domeny danych i kontrolowana wymiana zdarzeń w cyklu życia.

Architektura: warstwa handlowa połączona z operacjami

Wdrożyliśmy Salesforce Agentforce Revenue Management jako warstwę handlową opartą na Salesforce Sales Cloud. SAP pozostał nadrzędnym źródłem danych podstawowych produktów fizycznych, kosztów zakupu, stanów magazynowych, wysyłek i zapisów księgowych. Powstały projekt łączył możliwości rozwiązań chmurowych bez zacierania granic między sprzedażą, realizacją operacyjną a księgowością.

1. Przypisaliśmy odpowiedzialność według domen danych

Zaczęliśmy od modelu odpowiedzialności na poziomie pól. Dopuszczaliśmy zsynchronizowane kopie, ale każda wartość zachowywała jedno nadrzędne źródło. Wspólne identyfikatory, daty obowiązywania i informacje o wersjach wiązały ofertę handlową w Salesforce z odpowiadającym jej materiałem fizycznym w SAP.

Dane kosztowe z SAP synchronizowano z Salesforce na potrzeby obliczania marży, ale pozostawały one nieedytowalne poza SAP. Tę samą zasadę pierwszeństwa jasno określonej odpowiedzialności stosujemy w kontrolowanej integracji SAP z Salesforce.

2. Oddzieliliśmy produkty od modeli sprzedaży i rozliczeń

Terminal POS, trzyletnia subskrypcja oprogramowania i roczne wsparcie mogą znaleźć się w tej samej ofercie, choć każde z nich podlega innym zasadom. Osobno modelowaliśmy to, czym jest produkt, a osobno sposób jego sprzedaży i fakturowania.

Model produktu

Produkty fizyczne, oprogramowanie, usługi, atrybuty, relacje i identyfikatory wymagane na dalszych etapach procesu.

Model sprzedaży

Zobowiązania jednorazowe lub na określony czas, w tym daty rozpoczęcia i zakończenia oraz zasady odnawiania.

Model rozliczeń

Terminy i częstotliwość wystawiania faktur, określane niezależnie od długości zobowiązania handlowego.

Dzięki temu rozdzieleniu przychody ze sprzętu, przychody cykliczne, całkowita wartość umowy, okresy subskrypcji i przyszłe zobowiązania pozostawały widoczne bez rozbudowywania katalogu o każdy możliwy wariant handlowy.

3. Konfigurowaliśmy poprawne rozwiązania przed ustaleniem ich cen

Kompletne rozwiązanie dla handlu detalicznego mogło obejmować terminal, skaner, drukarkę paragonów, terminal płatniczy, oprogramowanie POS, subskrypcję systemu zarządzania zapasami i wsparcie. Odwzorowaliśmy to rozwiązanie za pomocą pakietów, atrybutów produktów, reguł zgodności, wymaganych komponentów, wykluczeń i zależności ilościowych.

Reguły Advanced Configurator mogły wymagać dodania komponentu, wykluczać niedopuszczalną kombinację, ukrywać nieistotną opcję, wyświetlać komunikat kontekstowy lub działać w obrębie całej transakcji. Punkt kontroli celowo umieściliśmy na wczesnym etapie: niepoprawnie skonfigurowane rozwiązanie nigdy nie powinno trafiać do ustalania cen, zawierania umowy, składania zamówienia ani realizacji.

Dlaczego miało to znaczenie

Konfiguracja nie była wyłącznie funkcją ułatwiającą pracę sprzedawcy. Ograniczała przyrost liczby SKU i chroniła zespoły magazynowe oraz instalacyjne przed wyjątkami na dalszych etapach procesu, których można było uniknąć.

4. Scentralizowaliśmy ustalanie cen i objęliśmy wyjątki kontrolą

Zamodelowaliśmy procedury ustalania cen i korekty w Salesforce, aby produkt, konfiguracja, ilość, umowa z klientem, kraj, okres subskrypcji i warunki promocji mogły składać się na spójny wynik handlowy. SAP dostarczał aktualne dane kosztowe, zapewniając wgląd w marżę.

Oddzieliliśmy również obliczoną cenę od rabatu wnioskowanego przez handlowca. Dzięki temu reguły zatwierdzania mogły uwzględniać rabat, marżę, wartość transakcji i inne czynniki handlowe. Standardowe transakcje przebiegały bez zbędnej ingerencji, natomiast większe odstępstwa trafiały do odpowiedniej osoby zatwierdzającej ze sprzedaży, działu handlowego lub finansów.

Te mechanizmy kontroli wdrożyliśmy za pośrednictwem Salesforce Revenue Cloud jako część szerszego cyklu życia, a nie jako odrębne obliczenia powiązane wyłącznie z ofertą.

5. Zachowaliśmy ustalenia handlowe na etapie zamówienia i realizacji

Oferta zawierała więcej niż ilość i cenę jednostkową. Zachowywała daty, zależności, wymagania dotyczące realizacji, harmonogramy rozliczeń i zobowiązania związane z odnowieniem, tak aby zamówienie i systemy obsługujące dalsze etapy mogły opierać się na tych ustaleniach bez konieczności ich odtwarzania.

1. Skonfiguruj poprawne połączenie sprzętu, oprogramowania, usług i wsparcia.
2. Oblicz ceny i marże, a następnie skieruj do zatwierdzenia wyłącznie wyjątki spełniające odpowiednie kryteria.
3. Aktywuj zamówienie zachowujące uzgodnione warunki, daty, ilości i zależności.
4. Użyj Dynamic Revenue Orchestrator do utworzenia planu realizacji, zadań, kamieni milowych i działań API.
5. Pozwól SAP zarządzać zapasami i wysyłką oraz przekazywać status do Salesforce.
6. Śledź instalację za pomocą Salesforce Field Service wraz z pozostałymi elementami planu realizacji.

Dynamic Revenue Orchestrator zapewnił działom sprzedaży i operacji wspólny wgląd w prace bez zmuszania zespołów magazynowych do rezygnacji z SAP. Dostawa pozostała też odrębnym etapem od instalacji: otrzymanie urządzenia nie oznaczało, że klient był gotowy do korzystania z kompletnego rozwiązania.

Inny przykład koordynacji prac operacyjnych w Salesforce znajdziesz w opisie tego, jak klient wykorzystał Sales Cloud i Field Service do połączenia działań sprzedażowych i serwisowych.

6. Generowaliśmy faktury w Salesforce i księgowaliśmy je w SAP

Wykorzystaliśmy Salesforce Billing Engine do generowania faktur na podstawie uzgodnionych harmonogramów i odpowiednich operacyjnych kamieni milowych. Dane z faktur trafiały następnie do SAP w celu zaksięgowania, z zachowaniem wyraźnego podziału: Salesforce obsługiwał generowanie faktur handlowych, a SAP prowadził ewidencję księgową.

Powiązanie zobowiązania handlowego z kamieniami milowymi dostawy i rozliczeń dało też działowi finansowemu solidniejszą podstawę do ustalenia, co zostało sprzedane, dostarczone i zafakturowane oraz co było gotowe do objęcia procesem ujmowania przychodów. Wdrożenie nie zastępowało polityki rachunkowości ani nie zakładało, że samo wystawienie faktury oznacza ujęcie przychodu.

7. Uwzględniliśmy zmiany umów i odnowienia w architekturze

Relacja z klientem trwała po złożeniu pierwszego zamówienia. Nowy sklep, dodatkowe urządzenia, przejście na wsparcie premium, rezygnacja lub odnowienie zmieniały istniejące warunki handlowe.

Skonfigurowaliśmy funkcje zarządzania transakcjami wokół zasobów i subskrypcji klientów. Zespoły mogły pracować na podstawie tego, co klient już posiadał, zachowywać historię cyklu życia oraz wprowadzać zmiany umów, rozszerzenia, rezygnacje i odnowienia bez odtwarzania pierwotnej konfiguracji od zera.

Ta sama podstawa może w przyszłości obsługiwać zobowiązania zwiększające się etapami lub opłaty zależne od wykorzystania, ale traktowaliśmy je jako przyszłe możliwości projektowe z odrębnymi wymaganiami dotyczącymi pomiarów, wyceny, rozliczeń i księgowości — nie jako automatyczne efekty początkowego wdrożenia.

Wnioski z wdrożenia hybrydowych modeli przychodów

• Zacznij od biznesowego cyklu życia i modelu odpowiedzialności za dane, a nie od poszczególnych ekranów Salesforce.
• Dla każdej istotnej wartości wyznacz jednego właściciela będącego źródłem referencyjnym i zadbaj, by zsynchronizowane kopie nie miały takiego statusu.
• Oddziel modele produktów, sprzedaży i rozliczeń, aby sprzęt i subskrypcje mogły współistnieć bez nadmiernego rozrastania się katalogu.
• Blokuj nieprawidłowe konfiguracje, zanim spowodują sytuacje wyjątkowe w wycenie, zamówieniach, magazynie lub instalacji.
• Zachowuj daty, zależności, kamienie milowe i zobowiązania przy każdym przekazaniu pracy do kolejnego etapu.
• Projektuj pierwszą sprzedaż i posprzedażowy cykl życia łącznie; zmiany umów i odnowienia nie są przypadkami marginalnymi.
• Jasno określaj odpowiedzialność za rozliczenia handlowe, realizację operacyjną i księgowość.

Powiązane studium przypadku synchronizacji danych Salesforce–SAP pokazuje, dlaczego aktualne dane ERP i jednoznaczna, rzetelnie realizowana odpowiedzialność za dane są warunkami automatyzacji dalszych etapów.

Wdrożenie działało jako jedna architektura przychodów: modelowanie produktów kształtowało konfigurację, konfiguracja wpływała na wycenę, oferta kształtowała zamówienie i jego realizację, rozliczenia podążały za warunkami handlowymi i kamieniami milowymi, a zasoby klienta wyznaczały zasady każdej późniejszej zmiany.