Headless Commerce – co to właściwie oznacza?

Zanim wybierzesz „uniwersalne” rozwiązanie, zatrzymaj się na chwilę i pomyśl o tym, jak chciałbyś widzieć swoje systemy sprzedaży za 3-5 lat? Co się może w tym czasie zmienić i jak często, a raczej jak szybko, będziesz musiał dokonywać modyfikacji, aby nadążać za konkurencją? Patrząc na najlepszych – Amazon dokonuje aktualizacji swoich aplikacji średnio co 11.7 sekundy, a Netflix czyni to nawet kilka tysięcy razy dziennie – mam przekonanie, że modne ostatnio powiedzenie „Change or die” ma swoje uzasadnienie.

---

Przez wiele lat uważano, że aby zapewnić sobie udaną ścieżkę do sprawnej architektury sprzedaży oraz spełnienia oczekiwań klienta, najlepiej jest tworzyć dedykowane systemy informatyczne all-in-one. Bardzo często ofiarą tego procederu padały poczciwe systemy ERP, rozbudowywane o kolejne moduły – np. zarządzania informacją produktową, czy zarządzania kontrahentami. W tamtym czasie kierunek ten wydawał się słuszny – wszak jeden kompleksowy system nadrzędny gwarantował zgodność doświadczeń konsumentów we wszystkich kanałach. Bardzo często taka ścieżka prowadziła jednak również do tzw. łańcuszka „coraz”… Coraz większe koszty serwisowania, coraz bardziej skomplikowaną strukturę danych, coraz bardziej kosztowny rozwój, coraz większe ryzyko awarii w trakcie modyfikacji i coraz większe uzależnienie od jednego dostawcy systemu. Skutek? Coraz częściej biznes dostosowywał swoje cele i działania do posiadanych narzędzi… A powinno być odwrotnie, nieprawdaż?

Wystarczy przykładową ścieżkę klienta (Rys. 1), aby zrozumieć jak ważne jest nie tylko zapewnienie spójności doświadczeń na każdym etapie podejmowania decyzji zakupowej, ale także personalizacji user experience względem specyfiki danego kanału komunikacji:

O co chodzi z tym headless e-commerce?

Headless e-commerce to koncepcja całkowicie odwracająca uprzedni porządek rzeczy. Zamiast tworzyć jedno rozbudowane rozwiązanie, które niby spełnia nasze oczekiwania, ale jest obarczone ciężarem już wprowadzonych modyfikacji i wyższym kosztem utrzymania, możemy wykorzystać szereg niezależnych, wyspecjalizowanych w swoich dziedzinach aplikacji, które współpracują ze sobą w ramach jednej architektury integracji opartej o API Driven Platform (tzw. Szyna Danych). Dzięki temu jesteśmy w stanie osiągać znacznie lepsze rezultaty:

• Personalizację UX, dzięki wykorzystaniu narzędzi stricte dedykowanych dla specyfiki danego kanału komunikacji oraz umożliwieniu ich niezależnego rozwoju.
• Elastyczność, dzięki budowie architektury skalowalnej, łatwiejszej do modyfikacji bez konieczności myślenia jak drobne zmiany mogą wpłynąć na pozostałe elementy.
• Bezpieczeństwo, dzięki niższym kosztom utrzymania oraz mniejszemu ryzyku awarii krytycznej, wynikającej z niedostępności danego zasobu – np. tymczasowy brak dostępu do zasobów ERP nie wyłączy sklepu internetowego.
• Standaryzację procesów, dzięki budowie jednej struktury danych w obiegu zmniejszamy koszt wymiany/dodawania nowych komponentów do już istniejącej architektury.

Drzewiej – jedna głowa, by wszystkimi rządzić…

Zestawmy obie koncepcje na jednym z popularnych scenariuszy. Otóż dana firma posiada platformę e-commerce B2B i myśli o wdrożeniu platformy B2C. Platforma B2B ma już swoje lata, a jej użytkownikom nie zależało dotychczas aż tak bardzo na wielu kwestiach UI/UX – innymi słowy, miała służyć jako prosta alternatywa do szybkiego zamówienia z góry wybranych przez kontrahenta produktów. Jednakże, jak wielu z nas przekonało się w praktyce, w przypadku Klientów B2C taki model funkcjonowania się nie sprawdzi. Do tego dochodzi oczywiście aspekt konsumeryzacji B2B, więc i ten obszar wypadałoby rozwinąć, jak i również pomyśleć o automatyzacji procesów, które jeszcze kilka lat temu możliwe były do realizacji jedynie manualnie.

Omawiana architektura przedstawia się w aktualno-hipotetycznej sytuacji w sposób zgodny z Rys. 2. Wszystkie dane produktowe, klientów oraz zamówień są przechowywane na platformie e-commerce z wbudowanym panelem CMS i jednym frontem aplikacji.

Jakie nasuwa się pierwsze naturalne rozwiązanie? Wymieniamy platformę e-commerce na bardziej nowoczesne i kompleksowe rozwiązanie – np. z opcją multistore dla B2B i B2C w obrębie jednej aplikacji. Tworzymy skomplikowane importery danych do inicjalnego zasilenia bazy nowej platformy oraz nowe metody integracji z systemami, rozbudowujemy na miarę wizji biznesowej, ingerując w kod źródłowy. I gotowe.

Problem w tym, że proces implementacji nowej platformy zajął od kilku do nawet kilkudzisięciu miesięcy, w trakcie których standardy rynkowe poszły naprzód. Okazuje się, że to, co w naszej opinii miało onieśmilić konkurencję, w praktyce pozwoliło ją ledwie dogonić. A że niestety nie objawił się jeszcze na świecie prawdziwy e-Nostradamus, nie byliśmy w stanie w pełni przewidzieć zmian technologicznych, które nadciągną w międzyczasie. W efekcie koszty modyfikacji i utrzymania rozwiązania rosną. Rezultat? W ciągu 3-5 lat znowu znajdujemy się w punkcie wyjścia… Tymczasem można działać zwinniej.

Obecnie – co kilka głów, to nie jedna…

Opierając się na tym samym przykładzie, załóżmy, iż tworzymy modularną archiktekturę, składającą się z całkowicie osobnej warstwy front-endowej i back-endowej. Są one połączone w oparciu o jeden, rozbudowany webservice magazynujący i synchronizujący dwukierunkowo dane pomiędzy wszystkimi systemami. W obrębie back-endu rozbijamy wcześniejszego molocha na mniejsze aplikacje – przykładowo:

• PIM – system Product Information Management – centralne repozytorium danych produktowych, odpowiedzialne za zarządzanie informacjami o produkcie.
• B2C – platforma e-commerce B2C, zawierająca logikę sprzedaży B2C.
• B2B – platforma e-commerce B2B, zawierająca logikę sprzedaży B2B.
• CMS – zarządzanie układem/layoutem treści na obu platformach.
• ERP – system odpowiedzialny za gospodarkę magazynową i ceny oraz order managment.
• CRM – system odpowiedzialny za zarządzanie danymi kontrahentów oraz ich segmentację i promocje rabatowe per klient/grupa.

Zgodnie z tym założeniem, każdy z wymienionych powyżej systemów jest nadrzędny dla swojej dziedziny i synchronizuje dane dwukierunkowo z pozostałymi systemami, w celu zapewnienia ich spójności. Aby zapewnić szybszą wymianę danych, zakładamy ich standaryzację w ramach szyny danych odpowiedzialnej za przyjęcie, przetworzenie i przesłanie informacji do wskazanego źródła/medium (Rys. 3).

Jakie możliwości daje CMS?

W tym przypadku każdy z frontów platformy może stanowić osobną część ekosystemu, zarządzaną z poziomu jednego CMS’a. Innymi słowy CMS może pobierać dane z pozostałych systemów i przetwarzać je do odpowiednich formatów layoutu dla poszczególnych mediów (np. strona internetowa, sklep internetowy etc.). Dodajmy, że w razie potrzeby każdy z frontów może stanowić osobną aplikację, składającą się z kilku warstwowych, osobno zarządzanych elementów, aby uzyskać świadomość, jak niskopoziomowe mogą to być integracje.

API-first approach

Wszystko opiera się na koncepcji API-first approach, którą śmiało wykorzystują dwaj wspomniani na początku tekstu liderzy swoich branż – Amazon oraz Netflix. Dzięki temu właściciel nie jest uzależniony od jednego dostawcy, a każdy z działów firmy może dostosowywać narzędzie to swoich potrzeb lub wymieniać je (w razie konieczności) znacznie niższym kosztem i w krótszym czasie. Takie podejście zapewnia pracownikom – specjalistom w swoich dziedzinach – dostęp do najlepszych narzędzi sprawiając, że potencjał kreatywności nie zostanie zgaszony przez mierny potencjał technologiczny.

Omnichannel Experience 3.0

Początkowo koncepcja API Driven Platform powstała przede wszystkim z myślą o kanale online, gdzie potrzeba błyskawicznej reakcji na rynkowe zmiany, zachowania klientów oraz działania konkurencji jest znacznie wyższa od rynku tradycyjnego. Jednakże nic nie stoi na przeszkodzie, aby stosować ją w przypadku developmentu całej architektury Omnichannel i skrzyżować ze sobą aplikacje odpowiedzialne za program lojalnościowy, info-kioski etc. etc. Wszystko zgodnie z koncepcją Big Data, a jednocześnie z większymi możliwościami dostosowania treści do sposobu i kanału komunikacji z Klientem. Posługując się więc chwytliwą ostatnio w marketingu retoryką – mamy do czynienia z Omnichannel Experience 3.0.

OpenSource najlepszym rozwiązaniem dla Headless Omnichannel…

Niezależnie od tego, czy mamy do czynienia z architekturą opartą o nadrzędność jednego systemu, czy też wymianę danych pomiędzy wieloma systemami dziedzinowymi, koszt utrzymania rozwiązań dedykowanych jest zazwyczaj znacznie większy niż przypadku gotowych rozwiązań wspieranych przez producenta. Te ostatnie mają jednak pewną wadę – zazwyczaj żadne gotowe rozwiązanie nie spełnia wszystkich oczekiwań biznesowych, a sam rozwój – ze względu na jedyne źródło wparcia – bywa bardzo kłopotliwy.

Utrzymanie pełnej skalowalności systemu

Z pomocą przychodzą rozwiązania open-source, posiadające otwarty kod oprogramowania, które można niemal dowolnie modyfikować pod wymagania danej organizacji. Robiąc to z głową, bez większych ingerencji w kod źródłowy, można zachować pełną skalowalność systemu oraz nadal korzystać z dobrodziejstw aktualizacji producenta bez większych nakładów prac. Takie podejście pozwala na znaczne ograniczenie kosztów utrzymania aplikacji, przy jednoczesnym stałym jej rozwoju.

Optymalizacja kosztów

Co więcej, rozwiązania pokroju Magento, czy Pimcore posiadają duży ekosystem partnerów, co zapewnia użytkownikom dostęp do wielu gotowych modułów rozbudowując warstwę funkcjonalną. Innymi słowy, stwarza to również okazję do optymalizacji kosztów rozwoju.

Czy warto stracić głowę już teraz?

Każdą inwestycję trzeba dostosować do skali biznesu. Nie ma sensu tworzyć od razu zaawansowanej architektury składającej się z wielu dziedzinowych aplikacji, jeśli nie widzimy perspektyw na szybki zwrot z inwestycji.

Relacje między systemami

Na szczęście możemy to robić stopniowo – np. na początku może to być prosta architektura składająca się z platformy e-commerce, systemu typu PIM oraz systemu ERP. Oczywiście w takim przypadku nadrzędnym systemem będzie ERP. Niemniej zakładając, że połączenie pomiędzy systemami odbywałoby się za pośrednictwem Szyny danych, nic nie stoi na przeszkodzie, aby z czasem przenosić ciężar zarządzania wybranymi obszarami commerce na kolejne aplikacje wpinane do architektury. Przy tym oczywiście wcale nie wywracając naszej organizacji do góry nogami, a dodając po prostu do niej kolejne rozszerzenia.

Minimum viable product

Praktyka niejednokrotnie pokazała, że kluczem do sukcesu jest budowanie skalowanej architektury z właściwym dla skali danego biznesu minimalnym zakresem funkcjonalnym (tzw. MVP – minimum viable product) oraz jej zwinny rozwój pod kątem aktualnych potrzeb Klienta. To już jednak opowieść na zupełnie inną okazję.