Prax

Bez systemu, który działał wcześniej, nie masz danych, na których możesz się oprzeć. Nie wiesz jeszcze, ile zamówień będzie obsługiwać sklep ani jak będzie wyglądać obciążenie magazynu. Dlatego w przypadku Prax zaczęliśmy od innego pytania: co platforma ma nam umożliwić? Kryteria wyprowadziliśmy z celów. W przypadku Prax były 3 kluczowe. Platforma musiała udźwignąć szybki wzrost, obsłużyć równolegle B2B i B2C oraz dać się głęboko zintegrować z istniejącym krajobrazem systemów (ERP, logika cen i akceptacji, procesy kontrolne w checkoucie). Na stole były Magento, Shopify i Shopware.

Za Shopware przemówił przede wszystkim jego mocny ekosystem w Niemczech. Jest tam dużo podobnych wdrożeń, łatwo znaleźć partnerów do integracji, a także developerów, którzy mogą rozwijać platformę nie tylko dziś, ale również w przyszłości. To ważny aspekt, który łatwo przeoczyć. Wybierając platformę, nie wybierasz tylko technologii. Wybierasz też dostęp do wiedzy i specjalistów, których będziesz potrzebować przez kolejne lata.

Magento nie odpadło dlatego, że nie spełniało naszych wymagań. Wręcz przeciwnie - obie platformy były w stanie je spełnić. Chodziło raczej o to, z jakimi kompromisami wiązałby się każdy z tych wyborów. Bo przy wyborze platformy zawsze coś zyskujesz, a coś innego staje się bardziej skomplikowane. Może to być utrzymanie, dodatkowe zależności albo większa złożoność rozwiązania. W przypadku Magento kompromisy dotyczyłyby obszarów kluczowych dla Prax. W Shopware ograniczenia pojawiały się w miejscach, które z perspektywy projektu były mniej istotne. Magento świadomie uwzględniliśmy w analizie, znamy tę platformę od lat i również na niej moglibyśmy zrealizować projekt. Dla tej konkretnej architektury i wymagań Shopware okazał się jednak lepiej dopasowany.

Podobnie było z Shopify. Platforma bez problemu mogłaby obsłużyć wzrost, ale wyzwaniem był sam proces zamówienia: sprawdzanie list sankcyjnych, walidacja numeru VAT UE dla klientów biznesowych czy różne zasady akceptacji zamówień dla B2B i B2C. Im więcej własnej logiki chcesz wprowadzić do checkoutu, tym większej kontroli nad kodem potrzebujesz. Dlatego rozwiązania SaaS szybko przestały być dla nas realną opcją.

Najbardziej wymagająca była weryfikacja list sankcyjnych w checkoucie. Prax sprzedaje narzędzia, które zależnie od przeznaczenia mogą podlegać przepisom o kontroli eksportu. Dane klienta są przy każdym zamówieniu sprawdzane w tle, zanim zamówienie trafi do dalszego procesu. To bezkompromisowe wymaganie musiało wpasować się w proces zakupowy, bez psucia konwersji.

Integracja z ERP poszła zaskakująco sprawnie, mimo że był to nasz pierwszy wspólny projekt z tym partnerem. W dużej mierze zadziałał tu właśnie efekt ekosystemu, który był jednym z powodów wyboru Shopware. Dostawca ERP niedawno realizował już podobny projekt na Shopware, więc mógł wykorzystać gotowe komponenty zamiast zaczynać od zera.

Oprócz integracji przygotowaliśmy też walidację numerów VAT UE dla klientów biznesowych oraz narzędzie do umawiania rozmów ze specjalistami produktowymi. Klient może w nim sprawdzić dostępne terminy i od razu wybrać dogodny dla siebie.

Brak istniejących procesów, na których mogliśmy się oprzeć, był jednocześnie dużą zaletą i wyzwaniem. Zaleta: nie musieliśmy migrować ani odtwarzać procesów wypracowanych przez lata. Wspólnie z biznesem mogliśmy zaprojektować docelowy model działania od podstaw. W przypadku migracji niemal zawsze część dotychczasowych rozwiązań i ograniczeń przechodzi do nowego środowiska. Tutaj mogliśmy tego uniknąć.

Kosztem była kolejność podejmowania decyzji. Kluczowe kwestie - który system jest źródłem danych, który ma dostęp wyłącznie do odczytu, jak przebiegają przepływy danych oraz jak obsługiwane są zwroty i reklamacje - należało ustalić równolegle z pracami deweloperskimi. Dlatego jeszcze przed rozpoczęciem implementacji przeprowadziliśmy wiele warsztatów.

Największym wyzwaniem nie była sama technologia, ale tempo podejmowania decyzji. W krótkim czasie potrzebowaliśmy ustalić wiele kierunków, mając świadomość, że każda błędna decyzja może później oznaczać kosztowne zmiany.

B2B i B2C mogą wyglądać podobnie z zewnątrz, ale pod spodem to dwa zupełnie różne światy. W Praxie najlepiej pokazuje to wartość koszyka. Klient biznesowy wydaje średnio dziesięć razy więcej niż konsument. Przy takich różnicach nie da się po prostu ustawić dwóch cenników i uznać temat za zamknięty.

Widać to m.in. przy płatnościach. Konsument kupujący na fakturę wymaga dodatkowej weryfikacji - np. daty urodzenia i zgodności adresów. W B2B kluczowe jest przede wszystkim sprawdzenie numeru VAT UE. Różnice tego typu pojawiają się w całym procesie: w koszyku, metodach płatności, checkoutcie i zasadach akceptacji zamówienia.

Dlatego sklep B2B i B2C w jednym nie jest połączeniem dwóch kanałów sprzedaży. To jeden sklep, który musi obsłużyć dwa zupełnie różne sposoby robienia zakupów.

Pierwszy commit padł na początku kwietnia, uruchomienie planowaliśmy na pierwszy tydzień października. Wystartowaliśmy pod koniec stycznia. Zespół był świadomie niewielki: kierownik projektu, jeden programista frontendu, jeden backendu i jedna osoba od QA.

Przesunięcie nie wynikało z tempa prac — na planowany termin byliśmy gotowi. Ale start, w którym marka, asortyment i sklep powstają jednocześnie, zależy od więcej niż od samego oprogramowania. Kiedy przesunęły się zależności poza zespołem projektowym, termin przesunął się razem z nimi. Przy launchu nowej marki to część całego procesu.

Całkowity koszt posiadania. Infrastruktura to kwota rzędu kilkunastu tysięcy euro rocznie - przy sklepie tej wielkości to odczuwalny udział w kosztach całkowitych i pozycja, którą przy Shopware najczęściej się niedoszacowuje.

Do tego dochodzą koszty licencji rozszerzeń. Zwłaszcza w obszarze B2B dobre rozszerzenia nie są tanie, a każde kolejne wymaganie podnosi TCO. Gdybyśmy od początku znali pełny zakres wymagań, ważylibyśmy ten punkt mocniej przy wyborze platformy. Nie zmienia to naszej oceny samej decyzji, ale warto mieć świadomość, że pełny koszt rozwiązania jest wyższy, niż sugeruje sama licencja. Realny TCO to także infrastruktura, rozszerzenia i ich utrzymanie - dlatego warto uwzględnić je w budżecie od pierwszego dnia.

Go-live to dla nas nie meta, tylko start kolejnego etapu. Sklep nie jest wtedy „skończony”, a jedynie gotowy do działania. Potem pojawiają się kolejne potrzeby wynikające z codziennej pracy i wspólnie je realizujemy.

Dużą częścią współpracy jest doradztwo. Prax zna swój rynek i produkty, my odpowiadamy za technologię oraz kwestie związane ze zgodnością. RODO i zarządzanie zgodami były na naszej liście od samego początku. To my mamy wiedzieć, o czym trzeba pamiętać i jakie wymagania należy spełnić. Klient nie musi być ekspertem od technologii czy compliance.

Teraz dochodzą kolejne tematy, np. obowiązki dotyczące treści generowanych przez AI. Nie czekamy, aż takie kwestie staną się pilne. Wychodzimy z nimi do klienta wcześniej i pomagamy je zaadresować, zanim pojawi się problem.

Około 80% projektu poszło zgodnie z planem. Pozostałe 20% było związane z zależnościami poza naszym zespołem. I właśnie tutaj widzimy najważniejszą lekcję. Łańcuch dostaw, dostępność zasobów po stronie partnerów czy ścieżki akceptacji - dziś znacznie wcześniej omawialibyśmy z klientem wszystkie tego typu zależności. Bo nawet jeśli wszystko po stronie zespołu działa zgodnie z planem, termin nadal może się przesunąć. Kluczowe jest więc nie tylko dobre zaplanowanie własnej pracy, ale też wcześniejsze nazwanie wszystkiego, co znajduje się poza naszym bezpośrednim wpływem.

Dlatego dziś robimy to już na starcie projektu. Zanim wpiszemy daty do harmonogramu, pytamy o wszystkie zależności zewnętrzne. To prosta rzecz, ale właśnie ona pozwala odróżnić realny plan od planu, który dobrze wygląda tylko na papierze.