Prax

Kiedy nie ma systemu poprzednika, nie da się wyprowadzić wymagań wobec platformy z liczby zamówień czy rotacji magazynowej. Kryteria wyprowadza się więc z celów. W przypadku Praxu były trzy 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, logiką cen i akceptacji, procesami kontrolnymi w checkoucie. Na stole były Magento, Shopify i Shopware.

Za Shopware przemówiła ostatecznie dojrzałość ekosystemu na rynku niemieckim: duża liczba porównywalnych sklepów działających produkcyjnie, dostępni partnerzy integracyjni i rynek deweloperów, z którego będzie można korzystać także za pięć lat. To twardsze kryterium, niż się na pozór wydaje. Nie decydujesz wyłącznie o oprogramowaniu, tylko o dostępności kompetencji przez cały cykl życia platformy.

W przypadku Magento nie było to wykluczenie, tylko kwestia kompromisów. Obie platformy spełniłyby wymagania — to nigdy nie było przedmiotem sporu. Każdy wybór platformy to wymiana: w jednym miejscu zyskujesz elastyczność, w innym płacisz za nią złożonością, nakładem utrzymaniowym albo zależnościami. Przy Magento kompromisy wypadłyby w obszarach krytycznych dla celów Praxu, przy Shopware tam, gdzie ograniczały projekt mniej. Magento świadomie wzięliśmy pod uwagę — pracujemy z nim od wielu lat i zrealizowalibyśmy ten projekt również na nim. Dla tej konkretnej konfiguracji Shopware był trafniejszym wyborem.

Shopify również udźwignąłby wzrost. Zadecydowały wymagania wobec procesu zamówienia: weryfikacja list sankcyjnych w checkoucie, walidacja numeru VAT UE dla klientów biznesowych, różna logika akceptacji dla B2B i B2C. Im głębiej musisz ingerować w proces zamówienia, tym większej kontroli nad kodem potrzebujesz. Dlatego model SaaS odpadł wcześnie.

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ą więc przy każdym zamówieniu sprawdzane w tle, zanim zamówienie trafi do dalszego procesu — to było wymaganie twarde, nie opcjonalne, i musiało wpasować się w proces zakupowy bez psucia konwersji.

Integracja z ERP przebiegła sprawniej, niż można tego oczekiwać przy partnerze, z którym pracuje się po raz pierwszy. Powód to dokładnie ten sam efekt ekosystemowy, który zaważył na wyborze platformy: dostawca ERP realizował krótko wcześniej inny projekt na Shopware i mógł przenieść gotowe komponenty zamiast zaczynać od zera. Do tego doszła walidacja numeru VAT UE dla klientów biznesowych oraz narzędzie do rezerwacji terminów, dzięki któremu klient wybiera wolny slot na rozmowę z ekspertem produktowym.

To, że nie istniały żadne procesy, na których można by się oprzeć — a to jednocześnie zaleta i koszt. Zaleta: nie musieliśmy migrować wyrosłych przez lata procesów, tylko mogliśmy zaprojektować stan docelowy od podstaw razem z działem biznesowym. Przy migracji prawie zawsze ciągniesz za sobą zaszłości. Tutaj nie.

Koszt leżał w tempie. Decyzje kierunkowe — który system jest wiodący, który ma dostęp tylko do odczytu, dokąd płyną dane, jak przebiegają zwroty i reklamacje — musiały zapadać równolegle z realizacją. Dlatego dużo czasu poświęciliśmy na warsztaty, zanim powstała pierwsza funkcjonalność. Prawdziwe wyzwanie nie było techniczne. Polegało na tym, jak podjąć wiele decyzji kierunkowych w krótkim czasie tak, żeby żadnej z nich nie trzeba było później kosztownie korygować.

Różnic jest wiele i bywają subtelne. Najbardziej widoczna to wielkość koszyka — w Praxie koszyk klienta biznesowego jest mniej więcej dziesięciokrotnie wyższy niż koszyk konsumenta. To zmienia wymagania wobec całego procesu zamówienia, od metod płatności po logikę akceptacji.

Konkretnie widać to przy płatnościach. Jeśli konsument chce kupić na fakturę, weryfikujesz datę urodzenia i zgodność adresu dostawy z adresem rozliczeniowym. U klienta biznesowego z reguły wystarczy sprawdzenie numeru VAT UE. Takie różnice ciągną się przez koszyk, metody płatności i checkout — i są powodem, dla którego sklep obsługujący obie grupy to coś więcej niż sklep z dwoma cennikami.

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 premierze nowej marki to raczej reguła niż wyjątek.

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 znaczy to, że decyzja była błędna. Ale kto ocenia Shopware wyłącznie przez pryzmat kosztu licencji platformy, liczy zbyt wąsko — koszty utrzymania i rozszerzeń należą do kalkulacji od pierwszego dnia.

Trwa dalej w trybie utrzymaniowym i tak było założone od początku. Sklep w dniu startu nie jest gotowy — jest gotowy do startu. Od tego czasu z bieżącej działalności stale wynikają nowe wymagania, które wdrażamy.

Dużą część pracy stanowi doradztwo i taki był podział ról, na który się umówiliśmy: Prax zna swój rynek i swoje produkty, my wnosimy to, czego sklep potrzebuje technicznie i regulacyjnie. Zgodność z RODO i zarządzanie zgodami były częścią wymagań od początku — pilnowanie tego to nasze zadanie, nie zadanie sprzedawcy. Ostatnio doszły obowiązki oznaczania treści generowanych przez AI. Takie tematy zgłaszamy aktywnie, zanim staną się pilne.

Około 80 procent projektu przebiegło bardzo dobrze. Pozostałe 20 procent dotyczyło zależności poza zespołem projektowym — i właśnie tam leży wniosek. Łańcuchy dostaw, zasoby partnerów, ścieżki akceptacji: takie zewnętrzne zależności następnym razem wyłożyłbym na stół razem z klientem jeszcze wcześniej.

Wewnętrznie wszystko może iść zgodnie z planem, a termin i tak się przesunie. Uwidocznienie tych zależności, zanim powstanie harmonogram, to różnica między planem realistycznym a optymistycznym. Wpisaliśmy to na stałe w inicjację projektu i na starcie pytamy wprost o wszystko, co leży poza naszym wpływem.