Digital Experience/
E-commerce

Spójne doświadczenie marki w digitalu. Jak zbudować architekturę Digital Experience Platform (DXP)?

By oferować spójne, spersonalizowane doświadczenia użytkownika potrzebujesz wysiłku całej organizacji - nie tylko marketingu, sprzedaży czy działu digital. W jaki sposób dostarczyć im narzędzia, które pozwolą zrealizować ten cel? Czy potrzebujesz jednej centralnej platformy, czy lepiej zbudować ekosystem? Poniżej opisuję trzy możliwe drogi.

Czym jest spójne doświadczenie użytkownika? 

Temat cyfrowego doświadczenia użytkownika (“digital experience”) to Święty Graal transformacji cyfrowej. Wiele mówi się o tym, że to właśnie ono decyduje o sukcesie lub porażce tych wysiłków. Czym jest zatem spójne doświadczenie użytkownika? 

Najłatwiej scharakteryzować je jako przeciwieństwo doświadczenia niespójnego, a więc takiego, które w różny sposób komunikuje lub inaczej obsługuje (lub nie obsługuje wcale) ten sam aspekt interakcji z użytkownikiem w różnych kanałach i na różnych etapach ścieżki użytkownika. Jeśli zatem: 

  • nazwa danej usługi lub produktu na stronie informacyjnej jest inna niż na formularzu zamówienia - doświadczenie jest niespójne
  • konto użytkownika w sklepie internetowym istnieje obok konta do obsługi reklamacji lub konta dla programu lojalnościowego - doświadczenie jest niespójne 
  • cena produktu w sklepie internetowym różni się od jego ceny w sklepie stacjonarnym - doświadczenie jest niespójne 
  • firma utrzymuje odrębnie serwis informacyjny oraz sklep - doświadczenie jest niespójne
  • pracownik call-center nic nie wie o zamówieniu internetowym klienta - doświadczenie jest niespójne 
  • system transakcyjny wylogowuje użytkownika po kliknięciu na link do strony informacyjnej - doświadczenie jest niespójne
  • itd. 

Dlaczego spójne doświadczenie użytkownika jest takie ważne? 

Są trzy główne powody dlaczego spójne doświadczenie użytkownika jest takie ważne: 

  • Konwersja - każda, absolutnie każda niespójność na ścieżce użytkownika, obniża konwersję, gdyż powoduje konsternację użytkownika i zniechęca go od kontynuacji procesu. Kilka takich niespójności sprawia, że konwersja drastycznie spada.  
  • Retencja - powracający klient to najtańszy klient - nawet 5 razy tańszy w stosunku do pozyskania nowego. Złe doświadczenia użytkownika na jednym z etapów jego ścieżki zakupowej zniechęcają jednak do ponownego korzystania z usług firmy.  
  • Lojalność - dobre doświadczenie marki w cyfrowym świecie przekładają się na lojalność klienta wyrażoną w gotowości do zapłacenia wyższej ceny za produkt lub usługę, do skorzystania z nowej oferty i polecenia marki swoim znajomym.  

Jak doświadczenie użytkownika wiąże się ze ścieżką użytkownika?

Doświadczenie użytkownika jest organicznie związane ze ścieżką klienta (“customer journey”), gdyż jej etapy określają, z jakimi elementami ekosystemu cyfrowego firmy styka się użytkownik, a zatem jakie ma doświadczenia na każdym etapie. Etapy te zależą od specyfiki danej branży oraz sytuacji danej organizacji - jej modelu biznesowego oraz organizacyjnego oraz dojrzałości cyfrowej. Wspólnym mianownikiem, pod który można podciągnąć większość organizacji i w pewnym sensie kanonicznym modelem ścieżki klienta jest scenariusz składający się z 3 kroków:

  1. Budowanie zaangażowania (Engagement) - na tym etapie użytkownik zapoznaje się z firmą i jej ofertą, poszukuje informacji, porównuje różne opcje zakupu, zapoznaje się z opiniami innych klientów / użytkowników. Kluczową rolę odgrywa tutaj atrakcyjny kontent (treść, zdjęcia, video) dostępny zarówno w serwisach własnych jak i w mediach społecznościowych.  
  2. Cyfrowa rejestracja (Onboarding) - na tym etapie następuje użytkownik staje się klientem, co wiąże się często z nabyciem pierwszego produktu. W zależności od branży ten proces może być głęboki, związany z weryfikacją tożsamości klienta( tak jest w przypadku bankowości), jak i płytki (w przypadku jednorazowego zamówienia w sklepie internetowym). 
  3. Samoobsługa (Self-Service) - na tym etapie mamy do czynienia z zarejestrowanym użytkownikiem, który samodzielnie korzysta z platformy / ekosystemu firmy w celu zaspokajania własnych potrzeb, np.: bankowości internetowej i mobilnej, platformy B2B commerce, rozwiązania klasy e-BOK, etc. Na tym etapie pojawia się też istotny wymiar relacji z klientem - jego lojalizacja przez różnego typu działania i programy.   

Dlaczego tak trudno zbudować spójne doświadczenie na całej ścieżce użytkownika?

Nasze doświadczenie pracy z dużymi firmami nauczyło nas, że są trzy strukturalne powody, dla których mają one problem w zbudowaniu rozwiązania zapewniającego spójne doświadczenie użytkownika. Są to:

  • Silosy - duże firmy są zorganizowane silosowo. W kontekście rozważań o ścieżce użytkownika, często jest tak, że obszar Engagement jest w gestii marketingu, zaś Onboarding to domena sprzedaży lub też departamentu odpowiedzialnego za dany segment klientów. Z kolei zaś obszar Self-Service to domena działu obsługi klienta/ Customer Happiness z dużą reprezentacją działu IT (gdy chodzi o core'owy system firmy).
    Do tego czasami dochodzi zespół e-commerce, który rozwija sklep internetowy, często pod odrębną domeną i brandingiem. Każdy z silosów, odpowiedzialny za własny wycinek ścieżki zakupowej, ma swoje wąsko zakreślone cele i KPIs.
  • Segmenty klientów - Duże organizacje obsługują zwykle wiele segmentów rynku i klientów. Każdy z nich ma nieco inne wymagania i potrzeby. Co więcej potrzeby danego segmentu klientów różnią się często między krajami. Każdy z segmentów i każdy z rynków to zwykle kolejne silosy organizacyjne. Budowanie jednego rozwiązania dla tak złożonej sytuacji rodzi wyzwania zarówno dla architektury rozwiązania, jak i w zakresie jego implementacji.
  • Zróżnicowane technologie na ścieżce klienta - gdy przyglądamy się z bliska poszczególnym etapom ścieżki klienta, to okazuję że każdy z nich wymaga innego wsparcia technologicznego:
    • Engagement to domena treści, publikowanej zarówno w kanałach własnych jak i mediach społecznościowych. Zarządzanie treścią wspierają wyspecjalizowane systemy klasy CMS, Headless CMS, PIM oraz DAM. 
    • Onboarding to często złożony, wielokrokowy proces, który musi spełniać szereg wewnętrznych wymagań i zewnętrznych regulacji. Fundamentem technologicznym takiego rozwiązania jest zwykle silnik workflow lub też też aplikacja dedykowana. 
    • Self-Service to obszar, w którym użytkownik może dokonywać złożonych operacji on-line (zamówienia, zlecenia, reklamacje, etc.), co wymaga integracji z wewnętrznymi systemami organizacji poprzez architekturę szyny integracyjnej (ESB), usług/mikrousług lub API. W obszarze tym coraz częściej realizowana jest dosprzedaż i lojalizacja użytkowników, co rozszerza spektrum niezbędnej technologii w kierunku Headless CMS i Marketing Automation.

Digital Experience Platform (DXP): obietnica spójnego doświadczenia 

Przełamanie strukturalnych problemów, o których mowa wyżej przynosi DXP (Digital Experience Platform) - nowa architektura rozwiązań cyfrowych. W skrócie DXP to rozwiązanie, które oferuję spójne i spersonalizowane doświadczenie użytkownika na całej jego cyfrowej ścieżce. Przez DXP rozumie się zarówno architekturę IT (kilka, kilkanaście elementów, z których buduje się kompletne rozwiązanie), jak i wyspecjalizowane platformy, które pokrywają sobą wymagane funkcjonalności. 

Oczywiście, sama technologia nie rozwiązuje problemów organizacyjnych, takich jak silosowość czy rozproszenie danych o użytkowniku. Jednakże koncepcja DXP, o ile jest skutecznie realizowana, pozwala skupić wysiłki wielu jednostek organizacyjnych na wspólnym celu - najlepszym doświadczeniu użytkownika końcowego i na optymalizacji wszystkich inicjatyw cyfrowych. 

Aby lepiej zrozumieć architekturę DXP, oprócz uwzględnienia etapów ścieżki użytkownika, pomocne będzie wprowadzenie podziału na trzy warstwy technologiczne: 

  • Experience - na tym poziomie budowane są interfejsy użytkownika oraz renderowane strony, który widzi użytkownik. Najbardziej naturalnym narzędziem do tworzenia tej warstwy są platformy CMS, gdyż dysponują mechanizmami tworzenia stron w modelu WYSIWYG (Page Builder, Studio). Alternatywną drogę wobec powyższego jest pójście drogą budowania rozwiązania custom w oparciu o popularne technologie front-end’owe dla programistów typu React, Angular lub Vue.
  • Ustrukturalizowane dane -  w tej warstwie funkcjonują zasoby cyfrowe, wykorzystywane w różnych kontekstach w ekosystemie cyfrowym. Zwykle jest to baza produktów obsługiwana przez rozwiązania klasy PIM (Product Information Management), ustrukturalizowany content wspierany przez rozwiązania klasy Headless CMS lub moduły klasycznych platform CMS. Są to też zasoby cyfrowe typu zdjęcia, filmy, wspierane przez DAM (Digital Asset Management). W tej warstwie można też ulokować bazy użytkowników zarządzane przez rozwiązania klasy IAM (Identity and Access Management).
  • Procesy - w tym obszarze przetwarzana jest logika biznesowa związana procesami wspierającymi użytkowników. Może być ona realizowana w oparciu o systemy klasy BPM (Business Process Management), wyspecjalizowane silniki branżowe, w tym najczęściej stosowany Headless Commerce lub architekturę dedykowanych mikroserwisów lub usług. W ten obszar można też wpisać procesy związane z zarządzaniem kampaniami realizowane zwykle przy wykorzystaniu narzędzi klasy Marketing Automation. Z procesami wiąże się aspekt integracji z systemami wewnętrznymi. Sama warstwa integracji nie jest częścią architektury DXP choć warunkuje jego funkcjonowanie. 

Mając powyższe na uwadze można rozważyć trzy bazowe scenariusze budowy rozwiązania klasy DXP: 

  1. Składanie “z klocków”, 
  2. Wdrożenie produktu klasy DXP,  
  3. Oparcie się na architekturze mikroserwisów. 

1. Składanie DXP z klocków (composable DXP)

Ta architektura zakłada, że architektura DXP składana jest z klocków, czyli niezależnych systemów, przy czym za pełen experience użytkownika na całej jego ścieżce odpowiada platforma CMS. Schemat logiczny takiej architektury wygląda następująco:  

gdzie:

  • CMS – Content Management System – odpowiada za zarządzanie wieloma site’ami i inicjatywami cyfrowymi oraz pozwala tworzyć poszczególne strony lub ekrany  w oparciu o ustandaryzowane komponenty / widgety wizualne, które stanowią techniczną implementację design systemu danej organizacji. Dzięki tym funkcjom oraz wsparcia segmentacji i personalizacji, dojrzały system CMS pozwala na bardzo elastyczne kształtowanie doświadczeń użytkowników przez marketerów przy minimalnym zaangażowaniu osób technicznych. Te właściwości platform klasy CMS sprawiają, że coraz częściej przebrandawiają się one na systemy klasy DXP. Dla potrzeb niniejszego opracowania pozostaniemy przy tradycyjnym rozumieniu tej kategorii. 
  • Headless CMS – narzędzie do tworzenia i strukturalizacji treści dla środowiska omnikanałowego. Występuje jako odrębny komponent technologiczny lub jako rozszerzenie klasycznych platform CMS (wtedy mamy do czynienia tzw. Hybrydowym CMS-em). 
  • PIM – Product Information Management – platforma wspierająca zarządzanie informacją produktową i udostępnianie ich wielokanałowo.  
  • DAM - Digital Asset Management - platforma do zarządzania plikami multimedialnymi - zdjęcia, video, prezentacje, pliki do pobrania. Zwykle część CMS-a (dlatego na schemacie przyjęto kolor zielony, tak jak dla CMS-a). Może być też odrębnym wyspecjalizowanym komponentem technologicznym lub rozszerzeniem PIM-a.
  • Marketing Automation - narzędzia tej klasy do obecnie bardzo wszechstronne platformy, które dotykają każdej z warstw powyżej.  Najpełniej jednak rola Marketing Automation wyraża się w zarządzaniu kampaniami marketingowymi, dlatego na schemacie ten komponent umieściliśmy w obszarze procesów. Dodatkowo narzędzie to wystąpi w obszarze Experience będąc bazą dla personalizacji oraz obsługując niektóre z interakcji z użytkownikami (np.: komunikaty marketingowe, mailingi) oraz Ustrukturalizowanych Danych - wnosząc w ten obszar Customer Data Model oraz assety cyfrowe używane w kampaniach reklamowych.   
  • BPM/Aplikacje/Mikroserwisy – ten obszar DXP jest najtrudniejszy do zdefiniowania, gdyż ma charakter wysoko customowy. Możliwa jest realizacja logiki procesów biznesowych w oparciu o silnik BPM, jako aplikacje dedykowane obsługujące dany aspekt biznesowy lub jako mikroserwisy. Optymalnie byłoby, aby te podsystemy było tworzone w modelu headless, pozostawiając warstwę F/E systemowi CMS. Rzeczywistość jest jednak taka, że systemy tej klasy mają ograniczenia, które mogą wymuszać budowę dedykowanych aplikacji front-end’owych.
  • IAM – Identity and Access Management – to istotny element architektury DXP odpowiadający za autoryzację użytkowników i prawa dostępu do różnych elementów ekosystemu DXP. 

Oczywiście nie we wszystkich przypadkach wystąpią wszystkie powyższe elementy, a często też mogą dochodzić nowe, wyspecjalizowane narzędzia.

Ciekawym wariantem powyższej architektury jest architektura dla e-commerce, w sytuacji gdy potrzebna jest atrakcyjna, bogata i zróżnicowana prezentacja produktów, której nie można uzyskać przy użyciu silników e-commerce. Architektura ta przybiera wtedy następujący kształt: 

Gdzie: 

  • PIM również realizowany jest przez platformę Headless Commerce 
  • Headless Commerce to platforma udostępniająca usługi / API dla potrzeb warstwy Experience.  
  • IAM zastępowany jest przez moduł zarządzania użytkownikami z platformy Commerce. 

Powyższe architektury, niezależnie od wariantu, są optymalne dla firm, które:

  • mają skomplikowane usługi, produkty lub proces ich nabycia i w związku z tym wymagają bogatej  oprawy komunikacyjnej i marketingowej i elastyczności w tym zakresie
  • prowadzą wiele inicjatyw cyfrowych – serwisów, sklepów, landing pages, site’ów branowych
  • działają na wielu rynkach geograficznie i branżowo
  • mają wiele brandów
  • mają wiele segmentów klientów potrzebujących zindywidualizowanego podejścia  

W powyższych przypadkach dojrzała platforma CMS zintegrowana z elementami całego ekosystemu DXP jest potężnym narzędziem kształtowania doświadczenia użytkownika w rękach marketerów. 

 

DXP składane z klocków

Zalety:

Wady:
  • wykorzystanie najlepszych i najlepiej dopasowanych do potrzeb komponentów technologicznych w swojej klasie
  • rozwiązanie można wdrażać krok po kroku, dodając i integrując poszczególne elementy
  • zachowanie inwestycji już poczynionych - jeśli pewne z elementów są już wdrożone (np. e-commerce czy CMS, z których jesteśmy zadowoleni), możemy je wpasować  w architekturę DXP
  • możliwość wymiany komponentów technologicznych w zależności od potrzeb i rozwoju technologii bez potrzeby zastępowania całego rozwiązania, co pozwala na organiczny rozwój i elastyczne dopasowywanie się do kontekstu biznesowego
  • docelowa architektura może być skomplikowana i wymagać wielu integracji pomiędzy komponentami technicznymi
  • konieczność zarządzania wieloma projektami wdrożeniowymi
  • trudne utrzymanie
  • konieczność śledzenia roadmapy wielu produktów i trendów technologicznych

2. Wdrożenie produktu klasy DXP

Drugim podejściem do wdrożenia rozwiązania wspierającego spójne doświadczenie użytkownika jest zastosowanie gotowej, out-of-the-box platformy klasy DXP. Platforma tego typu pokrywa większość komponentów funkcjonalnych opisanych powyżej w wariancie 1 (DXP składane z klocków) w jednym produkcie, który choć jest otwarty na integracje stanowi monolit. Do kategorii DXP dążą obecnie produkty klasy CMS, e-commerce i Marketing Automation, przez to nie jest to kategoria jednorodna i produkty bardzo się od siebie różnią. 

Oto jak widzi kategorię DXP Gartner obecnie (za rok 2021):

Źródło: Gartner report: Magic Quadrant for Digital Experience Platforms

A to spojrzenie Forrester na ten sam temat:

Źródło: The Forrester Wave™: Digital Experience Platforms (DXPs), Q3 2021

Większość z produktów prezentowanych w obu zestawieniach wyrasta z platform CMS (WCM) lub zbliżonego obszaru -  Adobe, Acquia, EPIServer, Sitecore, Liferay, Bloomreach, Magnolia, Kentico, etc. Część wyrasta z e-commerce - SAP, Oracle i silnie jest związanych z ecosystemem budowanym wokół własnych platform ERP przez te dwie korporacje. Oferta Salesforce z kolei budowana jest wokół systemu CRM tej firmy.  

Grupa odbiorców takich produktów jest prawie identyczna jak w przypadku DXP składanego „z klocków”, przy czym zmieniają się zalety i wady rozwiązania: 

DXP jako monolit

Zalety:

Wady:
  • ograniczenie liczby wdrażanych narzędzi i integracji między nimi
  • łatwiejsze utrzymanie – jedna platforma
  • skupienie wysiłków na jednym projekcie wdrożeniowym
  • “outsourcing” śledzenia nowych trendów technologicznych i rynkowych
  • silny Vendor Lock In - cały ekosystem digital zależy od jednego narzędzia
  • duża bariera wejścia – wszystkie
  • elementy ekosystemu wdrażane są na raz
  • stratne wdrożenie - zwykle istniejące już elementy ekosystemu cyfrowego będą zastępowane przez nową platformę
  • poszczególne elementy platformy mogą nie być optymalne lub wiodące w swojej klasie
  • trudny upgrade ze względu na konieczność upgrade’u całej platformy
  • zwykle wysokie koszty licencji
  • ryzyko utknięcia w “ślepej uliczce” technologicznej
  • trudność wdrażania innowacji

 

Ten wariant będzie optymalny dla firm, które chcą dokonać skoku na głęboką wodę, zastępując większość wdrożonych narzędzi w obszarze customer exprience.

3. DXP w oparciu o mikroserwisy 

Trend dekompozycji wielkich monolitycznych platform w kierunku mikroserwisów (usług) wynika z konstatacji, że logika biznesowa w nich zawarta, niezbędna jest nowych zastosowaniach. Wynikają one zarówno z pojawiania się nowych kanałów komunikacji (np.: mobile, social, voice, augmented reality, etc.) jak i ewolucji firm w kierunku modelu omnichannel, co również powoduje powstawanie nowych cyfrowych punktów kontaktu użytkownika z organizacją. 

Powyższą architekturę można zilustrować następująco: 

Jeśli chodzi o aplikacje frontowe zasygnalizowane powyżej, chcę opisać trzy najczęściej występujące przypadki:

  • PWA/SPA Storefront – jest to zwykle framework JavaScript w oparciu o popularne technologie React.js, Vue.js, Angular.js, napisany pod kątem zastosowań e-commerce. Taki framework jest dobrą bazą do szybkiego zbudowania dedykowanego rozwiązania i szczególnie sprawdzi się w scenariuszach B2C, zwykle dosyć powtarzalnych.   
  • Custom Front –  rozwiązanie w pełni dedykowane napisane w języku skryptowym - ostatnio najczęściej wybierany jest React.js. Sprawdza się dobrze tam, gdzie przypadki użycia są specyficzne np.: B2B commerce, aplikacje self-service, bankowość i finanse, firmy usługowe o złożonych procesach. Często w ramach użycia React.js wdraża się komponenty wizualne reprezentujące Design System, które są następnie reużywane przez developerów do tworzenia nowych aplikacji, zachowujących spójność z całością ecosystemu digital organizacji i obniżających koszty wdrożenia.  
  • CMS – najbardziej dojrzałym i dającym najwięcej możliwości marketerom jest zbudowanie warstwy doświadczenia użytkownika w oparciu o platformę CMS. W takim rozwiązaniu kluczowe zbudowanie reużywalnych komponentów wizualnych, zintegrowanych z mikrousługami. W oparciu o tę bazę, marketerzy korzystając z narzędzi typu Page Builder, Form Builder lub Studio mogą budować poszczególne strony lub ekrany rozwiązań cyfrowych.  Zaś przy użyciu klasycznych funkcji CMS-a typu Site Management mogą tworzyć nowe serwisy, sklepy i inicjatywy cyfrowe. Ten typ frontu sprawdzi się wszędzie tam gdzie bogate doświadczenie użytkownika jest kluczem do konwersji, retencji i lojalizacji klientów - czyli szczególnie dla firm usługowych oraz dla tzw. experience driven commerce. 

Architektura DXP w oparciu o mikroserwisy z pewnością jest konkurencją wobec klasycznych monolitycznych platform e-commerce i to one są pierwszą ofiarą tego trendu. Stąd też się bierze obecna popularność produktów klasy headless commerce. 

Jednakże największą ofiarą mikroserwisów będą systemy klasy ERP. W ERP-ach “uwięziono” logikę biznesową, która jest kluczowa w kształtowaniu doświadczenia użytkownika w kanałach cyfrowych. Jest to zwykle informacja produktowa, ceny, promocje, stany magazynowe, logistyka, płatności, etc. Rewolucja cyfrowa wymusza “wyniesienie” tej logiki z ERP do nowej warstwy, bliższej realnym przypadkom użycia w świecie cyfrowym. Logika ta raczej nie będzie odtwarzana w nowym monolicie, który stałyby się kolejną pułapką, ale właśnie w architekturze mikroserwisów, które w połączeniu z aplikacjami frontowymi staną się sercem transformacji cyfrowej firm. Skuteczne wdrożenie architektury mikroserwisów oznacza ograniczenie roli, a nawet rozpad systemów ERP na wyspecjalizowane systemy dziedzinowe (finanse i księgowość, logistyka, zarządzanie magazynem, planowanie produkcji, etc.) klasy Systems of Record. 

Architektura mikroserwisów jest optymalna dla największych firm, które mają odpowiednią skalę, rozwinięty model omnichannel, wiele inicjatyw cyfrowych czy też realizują różne modele biznesowe (B2B, B2C, B2B2C). Dodatkowo są gotowe na przejście na model ciągły model rozwoju aplikacji wspierający współpracę wielu zespołów deweloperskich i dostawców IT. Transformacja w tym kierunku wymaga jednak dużych kompetencji inżynierskich i architektonicznych oraz uporządkowania procesów wytwórczych oprogramowania. 

 

DXP w oparciu o mikroserwisy

Zalety:

Wady:
  • elastyczność kształtowania ekosystemu cyfrowego
  • reużywalność komponentów technologicznych i możliwość ich łatwiejszej wymiany
  • łatwość adaptacji do nowych trendów technologicznych
  • możliwość równoczesnej pracy wielu zespołów deweloperskich oraz wielu dostawców IT
  • ograniczenie roli systemów ERP / core-owych
  • ograniczenie kosztów licencji
  • niski Vendor Locking
  • możliwość wdrożenia etapowego
  • duża bariera wejścia ze względu na nowy model architektury, procesów wytwórczych i utrzymania oprogramowania
  • stratne wdrożenie - zwykle istniejące już elementy ekosystemu cyfrowego będą zastępowane przez nową architekturę
  • konieczność zarządzania wieloma zespołami i dostawcami

 

Każda organizacja wypracowuje własną drogę do dostarczania swoim klientom optymalnych doświadczeń, do przełamywania silosów i prawdziwej, głębokiej transformacji cyfrowej. Ważne, by skoncentrować się na celu i budować narzędzia bądź ekosystem narzędzi na jego miarę.