Aktualizacja platformy eCommerce często zaczyna się niewinnie. Kończy się wsparcie dla danej wersji oprogramowania, trzeba podnieść poziom bezpieczeństwa, dostawca płatności publikuje nową integrację, zmieniają się wymagania przeglądarek albo biznes chce wdrożyć funkcję, której obecna architektura już nie obsłuży.

Na początku wygląda to jak standardowy projekt. Wystarczy podnieść wersję, sprawdzić działanie wdrożenia, przeprowadzić testy i wrócić do normalnej pracy. W większych organizacjach rzadko jest tak prosto.

Po kilku tygodniach analizy okazuje się, że aktualizacja dotyka znacznie większego obszaru niż sam eCommerce. Trzeba sprawdzić integracje z ERP, płatnościami, kurierami, systemem magazynowym, narzędziami marketing automation, porównywarkami cen, systemem lojalnościowym, PIM-em, POS-em albo marketplace'ami. Trzeba przejrzeć moduły, customowy kod, checkout, promocje, konta klientów, dane produktowe, ceny, stany magazynowe i proces obsługi zamówień. Wycena, która miała dotyczyć „podniesienia wersji”, zaczyna przypominać koszt nowego wdrożenia.

I właśnie wtedy warto zadać najważniejsze pytanie: dlaczego zwykła aktualizacja stała się tak dużym projektem?

Aktualizacja ujawnia prawdziwy stan platformy

W codziennej pracy wiele problemów pozostaje niewidocznych. Serwis działa, zamówienia wpadają, kampanie są uruchamiane, zespół eCommerce wdraża kolejne zmiany. Jeżeli pojawia się potrzeba nowej funkcji, dopisuje się kod, dodaje moduł albo buduje obejście. Z perspektywy biznesu wszystko idzie do przodu.

Problem pojawia się wtedy, gdy przez lata kolejne zmiany dokłada się do systemu bez regularnego porządkowania fundamentów. Każda integracja, każdy moduł i każda indywidualna modyfikacja stają się częścią większej układanki. Po czasie nikt nie patrzy już na platformę jak na jeden produkt technologiczny. To raczej zbiór zależności, decyzji, kompromisów, wyjątków i rozwiązań dopisanych pod konkretne potrzeby biznesu.

Dopóki nie trzeba wykonać większej aktualizacji, ten model może działać. Ale większy update wymusza konfrontację z całą historią rozwoju systemu.

Wtedy wychodzi na jaw, które elementy są zgodne z obecną wersją platformy, które wymagają przebudowy, które zostały napisane pod poprzednią architekturę, które moduły nie są już rozwijane, a które integracje działają tylko dlatego, że ktoś kiedyś dopisał niestandardową logikę. Aktualizacja przestaje być prostą operacją techniczną. Zaczyna przypominać audyt całego eCommerce.

Największym kosztem bywa ryzyko

Koszt aktualizacji łatwo wpisać do budżetu. Trudniej policzyć ryzyko, które pojawia się po drodze. W większym eCommerce platforma sprzedażowa jest częścią codziennej operacji firmy. Jeżeli po aktualizacji nie działa płatność, nie synchronizują się stany magazynowe albo checkout ma błąd w jednym scenariuszu dostawy, skutki odczuwa nie tylko dział IT. Problem przechodzi do sprzedaży, obsługi klienta, logistyki, finansów i marketingu.

Ryzyko rośnie szczególnie wtedy, gdy firma przez długi czas odkładała aktualizacje. Zmiany, które mogły być wdrażane małymi etapami, kumulują się w jednym dużym projekcie. Zespół musi jednocześnie poradzić sobie z nową wersją platformy, kompatybilnością modułów, zmianami w customowym kodzie, testami regresji, poprawkami błędów i zabezpieczeniem ciągłości sprzedaży.

Takie projekty często mają własną dynamikę. Im więcej zależności, tym trudniej oszacować zakres. Im większy zakres, tym większe ryzyko opóźnień. Im dłuższy projekt, tym więcej zmian pojawia się w biznesie jeszcze przed jego zakończeniem. W efekcie aktualizacja, która miała uporządkować technologię, zaczyna blokować rozwój.

To jeden z powodów, dla których firmy odkładają update'y. Nie dlatego, że nie wiedzą, że są potrzebne. Często wiedzą to bardzo dobrze. Odkładają je, bo pamiętają poprzednie doświadczenia: tygodnie testów, niestabilne środowiska, problemy po wdrożeniu, długą listę wyjątków i obawę, że coś krytycznego przestanie działać w najgorszym możliwym momencie.

Open source daje swobodę, ale wymaga dojrzałego utrzymania

Platformy open source są atrakcyjne, bo dają dużą elastyczność. Można korzystać z gotowych modułów, rozwijać własne funkcje, wybierać dostawcę, modyfikować kod, budować indywidualne procesy i dopasowywać system do specyfiki firmy.

Ta elastyczność jest realną wartością. Szczególnie na początku, kiedy organizacja chce szybko uruchomić sklep, wykorzystać gotowe komponenty i uniknąć wysokich kosztów licencyjnych.

W dużej skali pojawia się jednak drugie oblicze tego modelu. Każdy moduł trzeba utrzymać. Każdą zmianę trzeba testować w relacji do innych zmian. Każdy customowy element trzeba sprawdzić po aktualizacji. Każdą integrację trzeba zabezpieczyć przed skutkami ubocznymi. Jeżeli odpowiedzialność jest rozproszona między platformę, firmę wdrożeniową, twórców modułów, hosting i wewnętrzny zespół IT, rośnie trudność zarządzania całym środowiskiem. W praktyce problem rzadko polega na tym, że czegoś nie da się zrobić. Dużo częściej chodzi o to, ile kosztuje utrzymanie tego, co zostało zrobione wcześniej.

Gotowy moduł może przyspieszyć wdrożenie konkretnej funkcji. Ale po roku lub dwóch latach trzeba sprawdzić, czy nadal jest wspierany, czy działa z nową wersją platformy, czy nie koliduje z innymi rozszerzeniami, czy jego aktualizacja nie wymaga zmian w customowym kodzie. Przy kilku modułach jest to zadanie techniczne. Przy kilkudziesięciu staje się procesem zarządzania ryzykiem.

Wycena aktualizacji powinna uruchomić szerszą rozmowę

Moment, w którym firma otrzymuje dużą wycenę aktualizacji, często traktowany jest jak problem budżetowy. Pojawia się pytanie, czy można zrobić taniej, szybciej albo etapami. To naturalne, ale zbyt wąskie podejście.

Duża wycena aktualizacji może być sygnałem, że firma powinna porównać kilka scenariuszy dalszego rozwoju. Nie chodzi od razu o decyzję o zmianie platformy. Chodzi o zrozumienie, czy aktualizacja poprawi sytuację na kolejne lata, czy tylko przesunie problem w czasie.

Warto sprawdzić, czy po zakończeniu projektu system będzie łatwiejszy w dalszym rozwoju. Czy kolejne aktualizacje będą mniejsze i bardziej przewidywalne. Czy poprawki bezpieczeństwa, nowe funkcje, bugfixy i optymalizacje będą częścią stałego modelu utrzymania. Czy dostawca bierze odpowiedzialność za całość, czy tylko za wybrany fragment. Czy istnieje proces testów automatycznych, możliwość szybkiego wycofania zmiany i środowisko pozwalające wdrażać poprawki bez wielotygodniowego napięcia operacyjnego.

Jeżeli odpowiedzi są niejasne, sama aktualizacja może nie wystarczyć. Firma może zapłacić dużo za doprowadzenie platformy do aktualnego stanu, ale bez zmiany modelu utrzymania za jakiś czas wróci do podobnego punktu.

Ciągły rozwój zmienia ekonomię platformy

W nowoczesnym eCommerce rozwój nie odbywa się już w kilkuletnich cyklach. Zmieniają się zachowania klientów, kanały sprzedaży, wymagania integracyjne, przepisy, metody płatności, narzędzia analityczne i oczekiwania wobec szybkości działania sklepu. Platforma, która przez długi czas nie jest regularnie aktualizowana, zaczyna tracić zdolność do szybkiej reakcji.

Dlatego coraz ważniejszy staje się model, w którym aktualizacje są stałą częścią działania platformy, a nie osobnym projektem wycenianym dopiero wtedy, gdy system zaczyna odstawać od rynku.

CI/CD, testy automatyczne, modularna architektura i przewidywalny proces utrzymania nie są dodatkami technicznymi dla zespołu IT. Ich biznesowa wartość polega na tym, że zmniejszają napięcie wokół zmian. Pozwalają wdrażać je częściej, w mniejszych porcjach, z lepszą kontrolą jakości i możliwością szybszej reakcji, jeżeli coś zachowa się inaczej niż zakładano.

W takim modelu platforma nie starzeje się skokowo. Nie dochodzi do sytuacji, w której po kilku latach trzeba nadrabiać zaległości jednym dużym ruchem. Zmiany są częścią bieżącego rytmu rozwoju eCommerce.

Dla organizacji oznacza to większą przewidywalność. Dla zespołu eCommerce — mniej projektów awaryjnych. Dla zarządu — lepszą kontrolę nad kosztem technologii w dłuższym horyzoncie. Dla klientów — stabilniejsze doświadczenie zakupowe.

Co w tej sytuacji powinien zrobić biznes?

Najważniejsze jest to, żeby nie patrzeć na aktualizację wyłącznie jak na pozycję w budżecie IT. W większej organizacji update platformy sprzedażowej wpływa na przychód, ciągłość działania, bezpieczeństwo, szybkość wdrażania zmian i zdolność firmy do reagowania na rynek.

Jeżeli aktualizacja jest niewielka, dobrze zaplanowana i wpisana w normalny proces utrzymania, prawdopodobnie wystarczy ją wykonać. Jeżeli jednak wycena rośnie, zakres jest niejasny, dostawca nie chce brać odpowiedzialności za część elementów, a zespół wewnętrzny obawia się wpływu projektu na sprzedaż, warto zatrzymać się przed podjęciem decyzji.

W takiej sytuacji porównanie aktualizacji z alternatywnym scenariuszem wdrożenia nowej platformy nie jest fanaberią. Jest elementem odpowiedzialnego zarządzania technologią sprzedażową.

Bo czasem najdroższy nie jest sam update. Najdroższe jest utrzymywanie modelu, w którym każda większa zmiana po kilku latach znów staje się projektem wysokiego ryzyka.

Zobacz jak zbudowaliśmy platformę eCommerce na https://merce.com/platforma.