Jak zbudować międzynarodową platformę e-commerce?
Jak zaprojektować międzynarodowy e-commerce? Wyzwania związane z architekturą platformy
11 lip 2019 / 7min
Decyzje dotyczące architektury systemu i jego wewnętrznej logiki niosą ze sobą poważne konsekwencje. Przekładają się na wszystkie aspekty późniejszego funkcjonowania platformy: od problemów utrzymania i zapewnienia wydajności, przez realizację celów biznesowych, po jakość doświadczeń użytkowników końcowych.
Dokonywanie tych wyborów jest łatwiejsze, gdy mamy duże doświadczenie w realizacji takich projektów. Dlatego chcemy podzielić się kilkoma dobrymi praktykami w projektowaniu systemów, działających na skalę międzynarodową.
W artykule analizujemy dylematy, które pojawiają się na początku projektu tworzenia międzynarodowego e-commerce.
Dowiesz się:
- czym się kierować, wybierając między platformą out-of-the-box a rozwiązaniem szytym na miarę,
- dlaczego duży, międzynarodowy system e-commerce powinien być w jednej, ale wewnętrznie podzielonej instancji,
- jak podzielić funkcje systemu na uniwersalne i charakterystyczne dla poszczególnych rynków (core i country-specific),
- kiedy warto sięgnąć po mikrousługi,
- o czym pamiętać, planując roll-outy na kolejne kraje.
Platforma out-of-the-box czy custom?
To pytanie pada zwykle na początku projektu. Odpowiedź na nie zależy przede wszystkim od tego, jaki jest Twój model biznesowy. W mniejszym stopniu dotyczy skali oraz liczby krajów, które obsługujesz.
Upraszczając, rozwiązania pudełkowe (out-of-the-box) sprawdzą się, gdy:
- Twój biznes ma standardowy charakter i nie masz unikatowych, wyjątkowych procesów;
- działasz w sektorze B2C, gdzie nie ma tak skomplikowanych mechanizmów zamawiania jak w B2B (często obejmujących złożone schematy składania zamówień, zamówienia wielostronne,negocjacje cenowe, indywidualne warunki dla poszczególnych klientów/partnerów, odroczone lub kredytowane płatności i wiele innych specyficznych dla danej branży funkcji);
- Twój zespół nie ma dużego doświadczenia w analogicznych projektach, co pozwoliłoby bezpiecznie przeprowadzić proces budowy systemu od zera.
Gotowa, pudełkowa platforma ma szereg zalet:
- prostsza, mniej złożona analiza: ponieważ mając już bazę, nie musisz tworzyć całego systemu od zera, skupiając się tylko na dopasowaniu go do Twoich potrzeb;
- szybsze wdrożenie w wersji podstawowej;
- mniejsze ryzyko: rozwiązanie pudełkowe pokrywa bazowe potrzeby, stanowi więc dobry punkt wyjścia do dalszych działań.
Niestety, z zaletami platformy pudełkowej wiążą się również pewne wady. Największą z nich jest to, że korzystając ze standardowej platformy, trudniej wyróżnić się na rynku. Ponadto, każda gotowa platforma ma swoją własną filozofię i wewnętrzną logikę – dopasowywanie ich do Twoich potrzeb i procesów może być kosztowne.
Rozwiązania szyte na miarę są z kolei optymalne dla firm działających w niestandardowych branżach, w których proces zakupowy oraz relacje z klientami mają nieco bardziej złożony charakter. Najczęściej ma to miejsce w obszarze B2B.
W takim wypadku modyfikacje i dobudowywanie nowych funkcji do rozwiązania pudełkowego mogą okazać się po prostu zbyt czasochłonne. Wówczas lepszym rozwiązaniem byłoby zbudować od zera własną platformę, która byłaby skrojona dokładnie na potrzeby naszej firmy.
Wybór gotowej platformy w sytuacji specyficznych wymagań biznesowych ma również inne długookresowe konsekwencje. Ze względu na ilość dedykowanego kodu, upgrade systemu do nowej wersji platformy jest zwykle dużym wyzwaniem technologicznym. Często też kierunek rozwoju platformy przyjęty przez jego twórcę nie odpowiada specyficznym potrzebom danego wdrożenia.
W zilustrowaniu alternatywy „custom czy out-of-the-box” pomaga analogia z branży budowlanej. Jeśli chcemy zbudować dom, możemy skorzystać z gotowego projektu lub zatrudnić architekta, który przygotuje dedykowany projekt. Oczywiście dom według dedykowanego projektu będzie lepiej dostosowany do naszych potrzeb, ale cały proces będzie bardziej wymagający zarówno dla nas, jak i firmy budowlanej (musimy precyzyjnie określić potrzeby). Dlatego większość osób decyduje się na projekt z katalogu (z niewielkimi zmianami), ale architekci, będący ekspertami w swojej dziedzinie, przeważnie mieszkają w domach według własnego, zindywidualizowanego projektu.
System jedno- czy wieloinstancyjny?
Kolejne pytanie, jakie należy sobie zadać na etapie projektowania systemu, dotyczy liczby jego instancji.
System e-commerce może składać się z:
- kilku instancji, kiedy istnieje kilka niezależnych systemów, np. każdy obsługujący jeden z krajów, a systemy te pracują w innych lokalizacjach i na innych zasobach hostingowych (zwykle takie rozwiązanie stosuje się w przypadku systemów ERP). Wówczas wyłączenie jednej instancji nie wpływa na działanie pozostałych.
- jednej instancji, co oznacza, że system jest jeden, wspólny, działający w jednej lokalizacji na jednym zestawie zasobów hostingowych. Przerwa utrzymaniowa oznacza niedostępność systemu dla wszystkich krajów.
UWAGA: wiele instancji nie oznacza, że każdy system ma osobny kod źródłowy. Kod źródłowy systemu powinien zawsze być jeden wspólny (o podziale na „core” i „country-specific” piszemy dalej). Nawet w przypadku wielu instancji zakładamy, że są one budowane z jednego, wspólnego repozytorium kodu źródłowego.
System wieloinstancyjny zapewnia szereg korzyści istotnych dla systemu międzynarodowego.
Umożliwia bowiem instalację platform poszczególnych krajów lub grup krajów w odrębnych podsystemach hostingowych lub nawet odrębnych lokalizacjach. W rezultacie uzyskujemy:
- bezpieczniejszy model wdrażania nowych wersji aplikacji – nowa wersja aplikacji może być uruchamiana dla jednego kraju, a następnie po stabilizacji rolowana na pozostałe kraje;
- możliwość ustalenia odrębnych przerw konserwacyjnych dla różnych krajów i dostosowanie ich do lokalnego czasu;
- obniżenie ryzyka strat w przypadku awarii – awaria będzie dotyczyć tylko części rynków uruchomionych w danej instancji;
- wykonanie instalacji systemu bliżej lokalnego rynku i uzyskanie lepszej wydajności systemu;
- spełnienie lokalnych wymagań dotyczących przetwarzania danych osobowych.
System zaimplementowany w jednej instancji umożliwia z kolei optymalizację kosztów zarówno infrastruktury, jak i pracy związanej z administracją. Możemy go również wewnętrznie podzielić logicznie w taki sposób, że da się w razie potrzeby wyodrębnić jego część, np. dotyczącą wybranego kraju lub grupy krajów. Pozwala to elastycznie dopasowywać się do nieoczekiwanych zmian (nawet geopolitycznych).
W 2015 roku w Federacji Rosyjskiej weszły w życie nowe przepisy regulujące przetwarzanie danych osobowych obywateli tego kraju. Zgodnie z nimi międzynarodowe firmy działające na terenie Rosji i Kazachstanu muszą zapisywać dane swoich klientów na serwerach znajdujących się na terenie Federacji. Musieliśmy w związku z nowym prawem wydzielić ze scentralizowanej infrastruktury udostępnianej w Europie Środkowo-Wschodniej procesy związane z rejestracją i działalnością obywateli FR do odrębnego data center znajdującego się na terenie tego kraju. Projekt polegał m.in. na uruchomieniu nowej instalacji całego środowiska e-commerce na terenie Federacji Rosyjskiej, które byłoby w jak największym stopniu niezależne od infrastruktury utrzymywanej w Warszawie.
Jeśli zdecydujesz się na model jednoinstancyjny, warto rozważyć, jak ma wyglądać jego podział logiczny. W razie potrzeby pozwoli to na wyodrębnienie jednej z jego części, np. tej, która dotyczy jakiegoś wybranego kraju lub grupy krajów. W efekcie, bez trudu dopasujesz się do nieoczekiwanych zmian rynku.
Funkcje core i country-specific
Dobrą praktyką przy tworzeniu systemu międzynarodowego jest podział funkcjonalności systemu na:
- funkcje bazowe (core), czyli uniwersalne, wspólne dla wszystkich krajów;
- country-specific, czyli uzależnione od charakteru danego rynku.
Do funkcji core’owych należą funkcje obsługujące procesy takie same dla wszystkich krajów. Należą do nich m.in.:
- przeglądanie katalogu produktów (o widoczności produktów decyduje się na poziomie bazy danych, ale mechanizm przeglądania pozostaje wszędzie ten sam),
- ścieżka zakupowa, koszyk;
- ogólne mechanizmy marketingowe;
- mechanizmy upsell i cross-sell;
- system CMS.
Tego typu funkcje tworzą wspólny dla wszystkich rynków rdzeń systemu. Z kolei różnić się będą:
- języki (wiąże się z tym też różna długość słów w poszczególnych językach, a czasami nawet kierunek czytania!);
- waluty;
- wymagania prawne;
- obowiązki informacyjne;
- metody płatności;
- metody dostawy;
- rozwiązania logistyczne;
- systemy ERP.
Funkcje te należy oprogramować jako opcje, które mogą być włączane bądź wyłączane w zależności od obsługiwanego kraju.
Jak odróżnić funkcje core od country-specific?
Na etapie projektowania systemu często nie mamy wystarczającej wiedzy o użytkownikach, procesie zakupowym oraz kontekście poszczególnych krajów, by określić wiążąco, które dokładnie funkcje powinny należeć do logiki bazowej systemu, a które są charakterystyczne dla poszczególnych rynków. Dlatego rekomendujemy następującą ścieżkę postępowania:
- Stworzenie wersji MVP systemu i pierwsze wdrożenie. Wersja ta zawiera tylko podstawowe funkcje, niezbędne do działania biznesu. Na tym etapie często nie potrafimy jeszcze zdecydować, które funkcje należą do obszaru „core”, a które są specyficzne dla poszczególnych krajów. Na pierwsze wdrożenie warto wybrać kraj, który nie jest krytyczny z perspektywy biznesowej. Po uruchomieniu następuje faza stabilizacji – intensywnej obserwacji systemu oraz podwyższonej gotowości do reagowania na pojawiające się problemy czy potrzeby. Przez okres ok. 2 miesięcy zbieramy feedback od realnych użytkowników, co pozwala zweryfikować założenia i wprowadzić pierwsze optymalizacje.
- Pogłębiona analiza i wydzielenie funkcji country-specific. Działający w jednym kraju system stanowi punkt wyjścia do rozmów z osobami odpowiedzialnymi za sprzedaż online w kolejnych krajach. Odnosząc się do już działającego systemu, ownerzy mogą łatwiej wskazać, jakie funkcje istniejącej platformy będą wykorzystywać, które wymagają niewielkich zmian, a jakie należy dodać jako specyficzne dla danego rynku. Warto przy tym uważnie analizować wymagania spływające z wielu rynków, gdyż powtarzające się potrzeby mogą stać się zalążkiem nowych funkcji core’owych.
- Developowanie funkcji oraz wdrożenia w kolejnych krajach. Bazując na pogłębionej analizie możemy przystąpić do stworzenia ostatecznej wersji systemu i jego wdrożenia we wszystkich krajach (roll-out). Możliwe jest również zastosowanie modelu zwinnego lub iteracyjnego, w którym pogłębiona analiza poprzedza każde wdrożenie. Taki proces zapewnia spójność systemu. Kolejne wdrożenia maksymalizują użycie istniejących i powstających funkcji core’owych (a z każdym roll-outem na kolejny kraj rośnie biblioteka takich funkcji). Unikamy jednocześnie rozszerzania systemu o funkcje specyficzne dla danego rynku, które nie byłyby używane w innych krajach.
Wydzielanie mikrousług
Tak, jak warto odseparować funkcje uniwersalne od zmiennych, warto również wydzielić niektóre moduły do odrębnych aplikacji/mikrousług.
Z takim podejściem wiążą się następujące korzyści:
- uproszczenie samego systemu e-commerce;
- naturalne unikanie powiązań typu „spaghetti” w ramach systemu e-commerce;
- zastosowanie technologii najlepszych dla danego rozwiązania (system e-commerce, szczególnie budowany w oparciu o platformę nie daje takiej elastyczności);
- możliwość korzystania z wydzielonych usług nie tylko przez system e-commerce, ale i przez inne systemy IT.
Dla przykładu – jeżeli działasz w B2B, masz dużą bazę produktów, a każdemu z klientów biznesowych oferujesz indywidualną cenę, pojawia się problem wyliczania cen, które użytkownik zobaczy w systemie e-commerce. Przechowywane w postaci statycznej zajęłyby zbyt dużo miejsca.
Gdy system e-commerce zaciąga ceny bezpośrednio z ERP, proces z kolei trwa zbyt długo. Wówczas model wyliczania cen warto przenieść do osobnej mikrousługi. Taka aplikacja może służyć jednocześnie systemowi e-commerce, systemowi CRM, aplikacjom wspierającym ofertowanie, skutecznie odciążając przy tym system ERP oraz izolując aplikacje frontowe od niedostępności systemu ERP.
Roll-outy jako osobne projekty
Często nie docenia się skali przedsięwzięcia, jakim jest roll-out na kolejny kraj. Wydaje się, że skoro system jest gotowy i napisany, to samo jego uruchomienie na nowym rynku nie będzie wielkim problemem. W praktyce okazuje się jednak inaczej, ponieważ wdrożenie w nowym kraju jest zawsze osobnym projektem. Wymaga zespołu, który będzie razem pracować i uwzględni wiele zadań, które nie są ściśle technologiczne, a raczej menedżersko-procesowe.
Mogą to być na przykład:
- analiza funkcji specyficznych dla kraju i zebranie wymagań biznesowych;
- analiza wymagań dla nowych interfejsów integracyjnych lub zmian w istniejących;
- development nowych funkcji, i interfejsów integracyjnych, rzadziej – przenoszenie funkcji z „core” do „country-specific”;
- przygotowanie tłumaczeń i lokalizacja systemu;
- dopasowanie produktów;
- testy integracyjne;
- testy wydajnościowe;
- przeszkolenie użytkowników.
Nie jest to kompletna lista zadań. Chodzi nam raczej o wskazanie, jak bardzo są one złożone oraz jak szeroki zakres obejmują. Dlatego nie należy redukować roll-outu do kwestii technologii.
Międzynarodowy e-commerce: wyzwanie o ogromnej skali
Tworzenie międzynarodowego systemu e-commerce (czy systemu, który będzie można w przyszłości rozbudować o kolejne rynki) to wyzwanie zupełnie innego kalibru niż budowa platformy, która będzie działała tylko w jednym kraju. Musimy wówczas wziąć pod uwagę bardzo wiele elementów na poziomie zarówno architektury czu UX, ale także wybierając między rozwiązaniem out-of-the-box a szytym na miarę.
Jeśli rozważasz platformę pudełkową, upewnij się, że zapewni ona elastyczność przy budowaniu funkcji specyficznych dla poszczególnych krajów. Często bowiem platformy OOTB oferują ograniczone wsparcie działalności międzynarodowej i pokrywają tylko niektóre potrzeby międzynarodowego systemu e-commerce.
Rozwiązanie e-commerce to poważna decyzja i wybór na lata. Rozwiązanie powinno kompleksowo wspierać międzynarodową ekspansję biznesu.