Firma projektuje i rozwija zaawansowane środowiska e-commerce, łącząc Magento 2 z dedykowanymi modułami, integracjami oraz mikroserwisami.
Dzisiejszy e-commerce rozwija się dynamicznie, ale wiele dojrzałych firm uderza w technologiczny sufit. Gdzie najczęściej leży problem?
W systemach projektowanych dla wcześniejszego etapu rozwoju firmy. Platforma mogła dobrze spełniać swoją funkcję przez kilka lat, ale później zmieniła się skala sprzedaży, liczba rynków, struktura katalogu oraz sposób pracy zespołu. Jeśli system zostanie w tym samym miejscu, może to stanowić początek kłopotów.
Problem staje się widoczny podczas uruchamiania nowej inicjatywy. Może to być wejście na kolejne rynki, wdrożenie zaawansowanej personalizacji, zmiana polityki cenowej albo automatyzacja obsługi zamówień. Nagle okazuje się, że pozornie prosta modyfikacja wymaga kilku miesięcy prac, wielu obejść i udziału kilku dostawców lub po prostu słyszymy, że się „nie da”.
Wtedy system przestaje być wsparciem dla rozwoju, a zaczyna go blokować. Zamiast pomagać, narzuca firmie swoje ograniczenia. Często kończy się to tak, że zespół odpuszcza świetne pomysły nie dlatego, że nie mają sensu biznesowego, ale po prostu dlatego, że platforma na to nie pozwala. To sygnał, że technologia, która kiedyś działała, stała się dla firmy niewystarczająca.
Często powtarzacie, że jesteście software house’em prowadzącym własny e-commerce. Jak to doświadczenie wpływa na projekty klientów?
W ecom.house nie patrzymy na sklep wyłącznie z perspektywy kodu i listy funkcji. Znamy codzienność sprzedaży internetowej: marżowość, logistykę zwrotów, aktualizację feedów produktowych, problemy z płatnościami, błędne stany magazynowe czy presję pojawiającą się podczas największych kampanii. Takie doświadczenie zmienia sposób prowadzenia rozmowy z klientem. Najpierw chcemy wiedzieć, jaki problem ma zostać rozwiązany, jak obecnie przebiega dany proces i jaki efekt finansowy lub operacyjny ma przynieść zmiana.
Czasami najlepszą rekomendacją wcale nie jest rozbudowana funkcja. Lepszy rezultat może dać uproszczenie procesu albo usprawnienie przepływu danych między ERP, magazynem i sklepem. Potrafimy też otwarcie powiedzieć, że dany pomysł nie zwróci poniesionych nakładów. Kod ma wspierać biznes, a nie być wartością samą w sobie.
Na rynku trwa dyskusja: gotowa platforma abonamentowa czy środowisko open source z dedykowanymi elementami? Jak podjąć właściwą decyzję?
Najpierw trzeba spojrzeć na etap rozwoju firmy. SaaS może być bardzo dobrym wyborem na start lub przy bardzo standardowych procesach. Pozwala szybko uruchomić sprzedaż, przetestować ofertę i ograniczyć koszty początkowe. Przy standardowym modelu biznesowym może też sprawnie działać przez wiele lat. Sytuacja zmienia się wraz ze wzrostem złożoności. Firma prowadzi sprzedaż na wielu rynkach, ma rozbudowaną politykę cenową, kilka magazynów, własne procesy logistyczne i liczne integracje. Wtedy zamknięta platforma coraz częściej wymusza kompromisy. Dochodzą kolejne aplikacje, prowizje oraz zależności od zewnętrznych dostawców.
Środowisko oparte na kodzie opensource takim jak Magento 2 i dedykowanych modułach daje większą swobodę. Firma może rozwijać własną logikę sprzedaży, projektować integracje zgodnie z procesami oraz decydować o kolejności zmian. Nie oznacza to, że każde duże przedsiębiorstwo musi automatycznie migrować z SaaS-u, ale lepiej nie przegapić odpowiedniego momentu, jeśli taka migracja będzie potrzebna.
Jak w praktyce wygląda połączenie gotowego silnika z dedykowanymi aplikacjami webowymi?
Magento 2 traktujemy jako sprawdzony fundament. Silnik zapewnia rozbudowane zarządzanie katalogiem, cenami, zamówieniami, klientami i sprzedażą na wielu rynkach. Nie ma sensu tworzyć tych elementów od podstaw, jeśli mamy gotowy dobry standard, a specyfika biznesu tego nie wymaga. Jednocześnie nie próbujemy zamykać każdego procesu wewnątrz jednego systemu. Jeśli firma potrzebuje zaawansowanego konfiguratora, portalu dla partnerów, nietypowego panelu obsługi zamówień albo aplikacji wspierającej sprzedaż stacjonarną, projektujemy osobny komponent i łączymy go z pozostałymi elementami architektury.
Dzięki temu platforma pozostaje modularna. Poszczególne części można rozwijać, wymieniać i skalować bez przebudowy całego środowiska. Duże znaczenie ma także dokumentacja oraz własność kodu dedykowanych elementów. Klient otrzymuje kod, moduły i dokumentację na zasadach opisanych w umowie. Zmiana partnera technologicznego nie powinna oznaczać utraty możliwości dalszego rozwoju sklepu.
Czy brak vendor lock-in oznacza pełną niezależność?
Pełna niezależność technologiczna właściwie nie istnieje. Każdy system korzysta z bibliotek, frameworków, usług chmurowych, operatorów płatności i zewnętrznych integracji. Ważna jest możliwość świadomego zarządzania tymi zależnościami. Firma powinna wiedzieć, z czego składa się jej środowisko, posiadać dokumentację i mieć dostęp do kodu powstałego na potrzeby projektu. Powinna również móc zmienić dostawcę bez konieczności budowania platformy od początku. Właśnie na tym polega praktyczne ograniczanie vendor lock-in.
Jakie kierunki będą budować przewagę e-commerce w najbliższych latach?
Pierwszy obszar to dalszy rozwój architektury wieloserwisowej. Zwykle pierwszym ruchem jest oddzielenie front-endu od zaplecza budując tzw. PWA, co daje większą swobodę projektowania doświadczenia zakupowego i ułatwia rozwój wielu kanałów. Sama etykieta „headless” nie gwarantuje jednak szybkości ani lepszej konwersji. Tutaj architektura musi odpowiadać na konkretną potrzebę i zostać prawidłowo zaprojektowana, a w dobie AI pozwala na łatwiejszą jej rozbudowę przy dobrej kalibracji niezależnych agentów.
Drugi kierunek to automatyzacja back-office. Nadal spotykamy duże sklepy, w których pracownicy ręcznie przenoszą dane, poprawiają zamówienia albo synchronizują informacje między systemami. Przy rosnącej skali takie działania zwiększają koszty i ryzyko błędów. Integracje ERP, WMS, PIM oraz automatyzacja obiegu danych mogą dać większy efekt niż kolejna zmiana wizualna na stronie.
Trzeci obszar obejmuje analitykę i hurtownie danych. AI może wspierać prognozowanie popytu, analizę kampanii, obsługę klienta, personalizację oraz zarządzanie treściami. Warunkiem są jednak uporządkowane dane i dobrze opisane procesy. Nie da się skutecznie automatyzować chaosu. Najpierw trzeba zbudować solidne podstawy, dopiero później wdrażać bardziej zaawansowane modele.
Z tych trzech rzeczy spodziewam się jednak największego nacisku na modularność i powrót do mikroserwisów. Firmy nie chcą już uzależniać całego rozwoju od jednego rozbudowanego systemu. Wolą łączyć wyspecjalizowane narzędzia w spójny ekosystem i wymieniać poszczególne elementy bez zatrzymywania sprzedaży. Wcześniej jednak takie wyzwanie było trudne i kosztowne, AI bardzo to ułatwia, dając doświadczonym architektom i programistą narzędzia do zapanowania nad większą ilością systemów jednocześnie.
Jaką radę dałbyś liderom e-commerce czującym, że obecna technologia zwalnia rozwój firmy?
Zacząłbym od pauzy i audytu. Nie od natychmiastowej migracji ani wyboru nowego silnika. Najpierw warto sprawdzić, gdzie naprawdę powstają ograniczenia, ile kosztują obecne zależności i jakie inicjatywy biznesowe nie mogą zostać uruchomione. Audyt powinien połączyć perspektywę biznesową, operacyjną i technologiczną. Dopiero wtedy można zdecydować, czy wystarczy uporządkowanie architektury, wymiana pojedynczej integracji, czy potrzebna jest pełna zmiana platformy.
Technologia musi nadążać za ambicją, a nie ją ograniczać. Jeśli każdy nowy pomysł wymaga walki z systemem, kosztownych obejść albo wielomiesięcznego oczekiwania, warto rozpocząć rozmowę o nowej architekturze. Zanim technologiczny dług zacznie bezpośrednio odbierać firmie przychody i możliwości rozwoju.