Co zmienia wersja 9

Przejście z ósemki na dziewiątkę dotyczy także technologii, na których działa sklep. PrestaShop 9.0 przeszedł z Symfony 4.4 na Symfony 6.4. To zmiana istotna przede wszystkim dla autorów modułów i osób utrzymujących własne modyfikacje. Kod korzystający ze starszych mechanizmów może wymagać dostosowania, nawet jeśli od strony klienta funkcja ma wyglądać identycznie. Zakres zmian opisuje dokumentacja zmian w PrestaShop 9.0.

Wymagania serwera sprawdzaj dla konkretnego wydania, które zamierzasz wdrożyć. Informacja „hosting obsługuje PrestaShop” jest zbyt ogólna. Potrzebna jest zgodna wersja PHP, odpowiednie rozszerzenia, baza danych i zasoby pozwalające wykonywać importy oraz zadania w tle. Punktem odniesienia jest oficjalna tabela wymagań. Osobno sprawdź PHP obsługujące stronę i PHP uruchamiane przez harmonogram zadań.

Dla właściciela sklepu znaczenie ma wynik: możliwość dalszego utrzymania systemu, dostępność potrzebnych rozszerzeń i działanie procesów sprzedażowych. Nie zakładaj, że aktualizacja sama przyspieszy katalog, naprawi wyszukiwarkę lub uprości pracę magazynu. Takie efekty wymagają osobnej diagnozy i pomiarów przed zmianą oraz po niej.

Największą niewiadomą bywają moduły i motyw

W standardowej instalacji zakres prac można oszacować stosunkowo łatwo. W sklepie rozwijanym przez kilka lat lista modułów nie mówi jeszcze, co naprawdę trzeba przenieść. Moduł płatności mógł dostać lokalną poprawkę, motyw korzystać ze zmienionego koszyka, a integracja z ERP odwoływać się bezpośrednio do bazy. Każdy taki element trzeba rozpoznać przed wyceną.

Deklaracja producenta o zgodności jest dobrym początkiem, ale dotyczy określonej wersji jego produktu. Sprawdź, czy posiadana licencja obejmuje dostęp do tego wydania i czy aktualizacja zachowa konfigurację. Jeżeli ktoś zmieniał pliki modułu, pobranie nowej paczki może usunąć te modyfikacje. Własny kod trzeba porównać z oryginałem i zdecydować, które różnice nadal są potrzebne.

Motyw również wymaga próby. Strona główna może wyglądać poprawnie, podczas gdy wybór kombinacji produktu, walidacja adresu albo płatność na telefonie przestają działać. Przy motywie dedykowanym potrzebne są źródła i instrukcja budowania plików. Przy gotowym motywie liczy się dostępność aktualizacji oraz zgodność dodatków dostarczonych razem z nim.

Jak sprawdzić, na czym stoisz

Przed rozmową o terminie przygotuj inwentaryzację. Dla każdego rozszerzenia zapisz nazwę, wersję, producenta, funkcję biznesową i osobę odpowiedzialną za utrzymanie. Dopisz informację o licencji oraz ewentualnych zmianach. Moduł, którego nikt nie potrafi opisać, wymaga sprawdzenia: może być zbędny, ale może też raz dziennie przekazywać zamówienia do magazynu.

• Ustal dokładną wersję sklepu, PHP, bazy danych i motywu.
• Zbierz listę aktywnych modułów, zadań cyklicznych i połączeń z zewnętrznymi systemami.
• Sprawdź override’y oraz bezpośrednie zmiany w plikach rdzenia.
• Zweryfikuj dostęp do kodu, kopii zapasowych i kont producentów rozszerzeń.
• Opisz nietypowe zasady cen, dostaw, rabatów i obsługi zamówień.

Wynikiem powinien być dokument dzielący elementy na gotowe do przeniesienia, wymagające poprawki, zastąpienia lub usunięcia. Przy każdej niewiadomej potrzebny jest sposób jej wyjaśnienia. Jeśli sklep ma wiele nadpisań, pomocny będzie osobny przegląd override’ów w PrestaShop. Bez tej pracy „aktualizacja” może skrywać przebudowę kilku ważnych funkcji.

Kiedy warto przesunąć termin

Wdrożenie tuż przed najważniejszą kampanią sprzedażową zwiększa koszt ewentualnej pomyłki. Jeśli nie ma pilnej przyczyny bezpieczeństwa, rozsądniej przygotować i przetestować zmianę wcześniej, a przełączenie zaplanować poza szczytem. Przesunięcie terminu powinno jednak mieć konkretną datę i warunki, które trzeba do niej spełnić.

Drugim powodem jest brak zgodności funkcji niezbędnej do sprzedaży. Jeżeli nie działa operator płatności albo integracja przekazująca zamówienia do ERP, sam fakt uruchomienia sklepu na nowym rdzeniu niewiele daje. Najpierw potrzebna jest poprawka, zamiennik lub uzgodniona procedura tymczasowa. Nie zakładaj, że producent zdąży, dopóki nie masz wersji, którą można sprawdzić.

Warto też połączyć prace, jeśli firma już przygotowuje wymianę motywu albo migrację na inną platformę. Dostosowywanie części przeznaczonej za chwilę do usunięcia bywa zbędnym kosztem. Warunkiem takiej decyzji jest możliwość bezpiecznego utrzymania obecnego sklepu do czasu następnego wdrożenia.

Kiedy zwlekanie utrudnia utrzymanie sklepu

Odłożenie aktualizacji nie zatrzymuje zmian u pozostałych dostawców. Hosting aktualizuje środowisko, operator płatności zmienia integrację, a producent modułu rozwija kolejne wydania. Jeśli sklep wymaga coraz większej liczby wyjątków, każdą nową funkcję trzeba najpierw dopasować do starych ograniczeń. Ten nakład powinien pojawić się w porównaniu kosztów.

Sprawdź aktualny status wsparcia używanego wydania i jego zależności. Dostępność poprawek bezpieczeństwa nie wynika z tego, że sklep nadal przyjmuje zamówienia. Gdy pojawia się problem bezpieczeństwa, decyzję o terminie trzeba oprzeć na jego znaczeniu dla danej instalacji i dostępnych zabezpieczeniach, a nie wyłącznie na kalendarzu kampanii.

Porównaj dwa warianty na tym samym okresie: uporządkowanie i aktualizację teraz oraz dalsze utrzymanie wraz z późniejszym przejściem. W drugim wariancie uwzględnij poprawki zgodności, dodatkowe testy i prace, które później trzeba będzie wykonać ponownie. Takie zestawienie daje lepszą podstawę decyzji niż przekonanie, że działającego sklepu nigdy nie należy ruszać.

Jak przygotować bezpieczną aktualizację

Zacznij od kopii plików i bazy oraz próby odtworzenia. Następnie uruchom osobne środowisko testowe. Zablokuj na nim dostęp osób postronnych i indeksowanie, wyłącz wysyłkę do klientów, a płatności oraz integracje przełącz w odpowiedni tryb testowy. Kopia produkcji nie może przypadkiem tworzyć prawdziwych przesyłek ani przekazywać powielonych zamówień.

Na kopii przeprowadź pełną aktualizację i zapisz wszystkie dodatkowe kroki. Testuj procesy: zakup gościnny i po zalogowaniu, kombinacje produktów, rabaty, dostawy, płatności, potwierdzenia operatora, wiadomości oraz eksport do ERP. Sprawdź także anulowanie zamówienia i zwrot. Poproś pracownika obsługi o wykonanie jego zwykłych zadań, bo nie wszystkie wyjątki widać w dokumentacji.

Przed przełączeniem określ moment wstrzymania zapisów, wykonania świeżej kopii i uruchomienia nowej wersji. Ustal, kto podejmuje decyzję o wycofaniu oraz jak zostaną rozliczone płatności przychodzące w tym czasie. Powrót do starej bazy po przyjęciu nowych zamówień wymaga ich zabezpieczenia i uzgodnienia danych. Samo przywrócenie plików nie rozwiązuje tego problemu.

Przed zatwierdzeniem wdrożenia warto też ustalić sposób odbioru. Przygotuj tabelę z nazwą testu, oczekiwanym wynikiem, osobą sprawdzającą i statusem. Jeśli jakiś przypadek nie przeszedł, opisz jego wpływ na sprzedaż. Drobna różnica wizualna i niepoprawne naliczanie ceny nie powinny mieć tej samej wagi. Decyzję o uruchomieniu podejmuj na podstawie tej listy, a nie samego komunikatu, że narzędzie zakończyło aktualizację bez błędu. Zachowaj wyniki próby przy dokumentacji projektu, żeby następny wykonawca wiedział, co rzeczywiście zweryfikowano i które ograniczenia zaakceptowała firma.

Najczęstsze pytania

Czy da się zaktualizować sklep bez przestoju?

Większość przygotowań można wykonać podczas normalnej sprzedaży. Samo przełączenie może wymagać krótkiego wstrzymania zamówień, żeby zachować spójność danych. Obietnica zerowej przerwy wymaga konkretnego rozwiązania technicznego i próby całej procedury.

Co z modułami, których producent już nie rozwija?

Najpierw sprawdź, czy ich funkcja nadal jest potrzebna. Jeśli tak, trzeba znaleźć zamiennik albo zlecić dostosowanie kodu z uwzględnieniem licencji. W obu przypadkach ustal, kto będzie później odpowiadał za poprawki.

Czy aktualizacja wpłynie na pozycje w Google?

Sam numer wersji nie daje gwarancji poprawy ani spadku widoczności. Sprawdź adresy, treści, linki kanoniczne, indeksowanie i odpowiedzi serwera przed wdrożeniem oraz po nim. Jeśli zmieniasz także strukturę URL, potrzebny jest osobny plan przekierowań.

Ile trwa aktualizacja wersji głównej?

Czas zależy przede wszystkim od zgodności rozszerzeń, zakresu własnego kodu i liczby procesów do przetestowania. Wiarygodny termin powstaje po inwentaryzacji oraz próbie na kopii. Sam czas uruchomienia narzędzia aktualizującego jest tylko częścią pracy.

Od czego zacząć decyzję

Poproś wykonawcę o listę przeszkód, plan testów i procedurę przełączenia. Dopiero na tej podstawie zatwierdzaj budżet i termin. Jeśli potrzebujesz pomocy w ustaleniu zakresu, sprawdź migracje i aktualizacje sklepów.

Artykuł PrestaShop 8 czy 9: kiedy aktualizować, a kiedy poczekać pochodzi z serwisu eCommerce Expert.

Zacznij od pracy, którą sklep ma wykonywać

Porównanie platform ma sens dopiero po opisaniu sprzedaży. Sklep z kilkuset produktami może mieć skomplikowany konfigurator, a katalog z tysiącami pozycji opierać się na prostym zakupie pojedynczej sztuki. W pierwszym przypadku trudność leży w logice produktu, w drugim być może w imporcie danych i wyszukiwaniu. Etykieta „mały sklep” ukrywa te różnice.

Przygotuj przykłady prawdziwych zamówień i pokaż, co dzieje się z nimi po zakupie. Kto wprowadza produkt? Skąd pochodzi stan magazynowy? Gdzie powstaje faktura? Co robi obsługa, kiedy klient zmienia adres albo zamawia towar niedostępny od ręki? Platforma powinna pasować do tych odpowiedzi, a nie do samego wyglądu strony.

• Czy treści poradnikowe i strony kampanii są ważną częścią codziennej pracy?
• Jakie typy produktów, warianty i reguły cenowe występują w katalogu?
• Z którymi systemami sklep musi wymieniać dane i w jakim czasie?
• Kto będzie wdrażał aktualizacje i usuwał awarie?
• Jaki budżet firma może przeznaczyć na utrzymanie po uruchomieniu?

Na tej podstawie wybierz kilka scenariuszy do demonstracji. Poproś wykonawców obu wariantów o pokazanie tego samego procesu na podobnych danych. To znacznie więcej mówi o przydatności rozwiązania niż porównanie list funkcji na stronach producentów.

Katalog i warianty produktów

Obie platformy obsługują produkty z wariantami. W praktyce trzeba sprawdzić, jak pracuje się z konkretnym katalogiem: ile istnieje kombinacji, jak zmieniają się ceny, gdzie znajdują się zdjęcia i jak aktualizowane są stany. Dla zespołu zarządzającego asortymentem ważniejszy od samego istnienia funkcji może być czas potrzebny na poprawienie całej grupy produktów.

WooCommerce udostępnia wbudowany import i eksport produktów przez CSV, obejmujący także produkty wariantowe. Zakres i format danych opisuje dokumentacja importera. To przydatne przy standardowym katalogu, ale nie oznacza automatycznej obsługi pól każdego dodatkowego rozszerzenia. Jeżeli produkt ma konfigurację zapisaną przez wtyczkę, sprawdź ją oddzielnie.

Nie przyjmuj arbitralnej granicy, po której WooCommerce przestaje działać, a PrestaShop zaczyna być obowiązkowy. Wydajność zależy również od zapytań do bazy, filtrów, kodu rozszerzeń, cache i infrastruktury. Przeprowadź próbę na reprezentatywnych danych, obejmującą wyszukiwanie, filtrowanie i import podczas ruchu. Pusta instalacja z kilkoma produktami nie odpowie na pytania o docelowy sklep.

Koszt: wdrożenie, rozszerzenia i utrzymanie

W porównaniu wariantów opartych na otwartym oprogramowaniu cena samej platformy jest tylko jedną pozycją. Do budżetu wpisz analizę, motyw, konfigurację, integracje, migrację danych, testy i szkolenie. Osobno policz hosting, aktualizacje, kopie zapasowe, płatne rozszerzenia oraz czas obsługi. Jeśli rozważasz ofertę zarządzaną lub abonamentową, sprawdź dokładnie, co obejmuje jej cena.

Ta sama nazwa funkcji może ukrywać bardzo różny zakres. „Integracja z magazynem” może oznaczać ręczny eksport pliku albo dwukierunkową synchronizację z obsługą błędów. Wycena gotowej wtyczki nie jest porównywalna z budową takiego procesu od podstaw. W obu ofertach wymagaj opisu częstotliwości aktualizacji, odpowiedzialności za awarie i zachowania przy niedostępności drugiego systemu.

Przygotuj koszt trzyletni: uruchomienie, przewidywane odnowienia licencji, utrzymanie i uzgodnione prace rozwojowe. Dodaj czas pracowników wykonujących ręczne czynności, których dany wariant nie automatyzuje. Tani start może być dobrym wyborem, jeśli zakres jest prosty. Powinien jednak wynikać ze świadomego ograniczenia funkcji, a nie z pominięcia kosztów późniejszej obsługi.

Sprzedaż B2B i cenniki

Hasło „obsługuje B2B” wymaga doprecyzowania. Rabat dla grupy klientów, cena uzgodniona dla konkretnego kontrahenta, limit kupiecki i zamówienie zatwierdzane przez kierownika to różne funkcje. Zapisz je oddzielnie. Przy każdej wskaż, czy będzie realizowana przez platformę, rozszerzenie, własny kod czy system ERP.

Najpierw ustal, gdzie powstaje ostateczna cena. Jeśli ERP wylicza indywidualne warunki, sklep powinien otrzymywać jednoznaczny wynik lub stosować uzgodnione reguły. Równoległe naliczanie rabatu w kilku modułach utrudnia kontrolę. Test obejmujący produkt w promocji, rabat kontrahenta i próg ilościowy pokaże więcej niż prezentacja pojedynczego cennika.

Poproś też o demonstrację zmiany warunków handlowych. Sprawdź, kiedy nowa cena pojawi się w katalogu, co stanie się z otwartym koszykiem i jak zostanie zapisane zamówienie. Jeśli proces zakupowy obejmuje wiele ról, negocjacje lub niestandardowe reguły akceptacji, poszerz analizę. Taki przypadek omawia porównanie PrestaShop i Syliusa w B2B.

Utrzymanie i aktualizacje

W WooCommerce utrzymujesz także WordPressa, motyw i pozostałe wtyczki serwisu. W PrestaShop zależności obejmują rdzeń, motyw, moduły oraz własne modyfikacje. W obu przypadkach ważna jest zgodność całego zestawu. Nie wystarczy stwierdzenie, że pojedyncze rozszerzenie ma najnowszą wersję, jeśli jego aktualizacja nie współpracuje z resztą sklepu.

Już przy wyborze platformy ustal sposób pracy: środowisko testowe, harmonogram aktualizacji, test zamówienia i procedurę wycofania zmiany. Sprawdź, czy kopie są przechowywane poza samym serwerem i czy ktoś potrafi je odtworzyć. To zadania, które trzeba uwzględnić w ofercie, nawet jeśli w dniu startu sklep wygląda na bezproblemowy.

Liczy się również możliwość zmiany wykonawcy. Własne konta usług, dostęp do repozytorium i dokumentacja integracji ułatwiają przejęcie projektu. Dostępność wielu specjalistów od danej platformy nie pomoże, jeśli nikt nie otrzyma źródeł zmodyfikowanego motywu albo opisu procesu wdrożenia.

Który wariant pasuje do Twojej firmy

Jeżeli masz rozbudowany serwis na WordPressie, regularnie publikujesz poradniki i chcesz dodać standardową sprzedaż, WooCommerce powinien znaleźć się na krótkiej liście. Jeden panel może uprościć pracę redakcji. Warunkiem jest sprawdzenie, czy obecny motyw i wtyczki nadają się także do obsługi sklepu.

Jeśli budujesz serwis przede wszystkim wokół handlu, a zespół codziennie pracuje z produktami, dostawami i zamówieniami, sprawdź PrestaShop na swoich scenariuszach. Oceń dostępność konkretnych integracji i wygodę panelu dla obsługi. Samo przeznaczenie platformy nie zastępuje demonstracji potrzebnych funkcji.

Przy standardowej sprzedaży i braku osoby odpowiedzialnej za techniczne utrzymanie warto porównać także SaaS. Abonament może uprościć część obowiązków, ale trzeba sprawdzić ograniczenia integracji, możliwość eksportu danych i całkowite opłaty. Jeśli firma ma bardzo nietypowy proces, porównanie tylko dwóch popularnych platform może z kolei nadmiernie zawężać wybór.

Tabela do porównania ofert

Najczęstsze pytania

Czy da się przenieść sklep z WooCommerce na PrestaShop?

Tak, ale migracja wymaga dopasowania danych, funkcji i adresów. Import produktów nie przenosi automatycznie całego sklepu. Szczegółowy zakres opisuje artykuł o migracji z WooCommerce na PrestaShop.

Która platforma jest szybsza?

Bez pomiaru konkretnego wdrożenia nie ma uczciwej odpowiedzi. Porównuj te same scenariusze, wielkość danych i obciążenie. Wynik testu strony głównej nie wystarczy do oceny filtrów i koszyka.

Co z kosztem wtyczek i modułów przy dłuższym utrzymaniu?

Zbierz zasady odnowienia, zakres wsparcia i koszt aktualizacji każdego płatnego dodatku. Dołóż prace potrzebne przy zmianie dostawcy lub utracie zgodności. Sam rachunek za pierwszy zakup nie pokazuje całego kosztu.

Czy wybór platformy wpływa na SEO?

Wpływa na sposób wdrażania zmian, ale nie zastępuje dobrych treści i poprawnej konfiguracji. W obu wariantach sprawdź adresy, indeksowanie, szybkość i możliwość edycji metadanych. Przy zmianie platformy szczególnego planu wymagają dotychczasowe URL-e.

Jeżeli obie oferty wyglądają podobnie, zleć demonstrację najtrudniejszego procesu na swoich danych. Wynik tej próby może rozstrzygnąć wybór przed większym wydatkiem. W uporządkowaniu wymagań pomoże doradztwo e-commerce.

Artykuł PrestaShop czy WooCommerce: którą platformę wybrać pochodzi z serwisu eCommerce Expert.

Porównuj ten sam zakres

Jedna agencja może wyceniać konfigurację gotowego motywu, a druga projekt widoków i ich wdrożenie. Obie pozycje bywają nazwane „projektem graficznym”. Podobnie „integracja z ERP” może oznaczać uruchomienie istniejącego dodatku albo budowę synchronizacji z obsługą wyjątków. Różnica cen nie mówi wtedy jeszcze nic o opłacalności.

Przygotuj wspólną tabelę wymagań. Przy każdej pozycji poproś o oznaczenie: w cenie, poza zakresem, opcjonalne albo wymagające analizy. Dopisz rezultat, który będzie można sprawdzić. Zamiast „obsługa rabatów” zapisz przykład koszyka i zasady naliczania ceny. Zamiast „migracja” wymień produkty, klientów, zamówienia, zdjęcia, treści oraz adresy.

Sprawdź też obowiązki po Twojej stronie. Kto dostarcza opisy i fotografie? Kto czyści dane produktowe? Kto zatwierdza mapę przekierowań? Jeśli wykonawca zakłada otrzymanie gotowych materiałów, a firma spodziewa się ich przygotowania w cenie, harmonogram przestaje być wiarygodny jeszcze przed rozpoczęciem prac.

Prawa do kodu, licencje i dostęp do projektu

Rozdziel trzy sprawy: możliwość korzystania z oprogramowania, dostęp do jego źródeł i prawo zlecenia zmian innej osobie. To różne pytania. Sklep może działać poprawnie, a mimo to jego właściciel nie mieć instrukcji wdrożenia, konta producenta modułu albo źródeł potrzebnych do przebudowania motywu.

Poproś o zestawienie elementów własnych wykonawcy, kodu tworzonego na zamówienie i komponentów zewnętrznych. Przy każdym powinien być opis zasad korzystania, aktualizacji i przekazania. Nie zakładaj, że zapłata faktury automatycznie rozstrzyga wszystkie prawa. Zasady przeniesienia praw oraz licencji wynikają z umowy i przepisów, w tym ustawy o prawie autorskim. Zapisy dotyczące konkretnego projektu warto sprawdzić z prawnikiem.

Od strony organizacyjnej konta domeny, hostingu, płatności i narzędzi analitycznych powinny pozostawać pod kontrolą firmy. Wykonawca może otrzymać własny dostęp. Ustal również dostęp do repozytorium, częstotliwość przekazywania kodu i sposób przechowywania dokumentacji. Możliwość odbioru projektu nie powinna zależeć od tego, czy za rok nadal pracuje przy nim ten sam programista.

Jak będą rozliczane zmiany

Ryczałt ułatwia planowanie wydatków, jeśli zakres i założenia są dobrze opisane. Rozliczenie godzinowe daje więcej swobody przy odkrywaniu wymagań, lecz potrzebuje przejrzystego raportowania i limitów. Model mieszany może łączyć wycenione etapy z osobnym budżetem na zadania, których nie da się jeszcze dokładnie określić.

Zapytaj, co dzieje się po zgłoszeniu nowej potrzeby. Powinien istnieć moment oceny wpływu na cenę i termin oraz osoba zatwierdzająca zmianę. Wykonawca nie powinien dowiadywać się o zgodzie z niejednoznacznej rozmowy, a klient o koszcie dopiero z faktury. Ustal też sposób raportowania wykorzystanego i pozostałego budżetu.

Oddziel poprawienie niezgodności z ustalonym wymaganiem od rozszerzenia funkcji. Przykładowo: jeśli zaakceptowany scenariusz przewiduje rabat po przekroczeniu progu, jego błędne naliczanie wymaga naprawy. Dodanie innego progu dla nowej grupy klientów może być zmianą zakresu. Dobrze opisany przykład odbiorowy pomaga rozstrzygać takie sytuacje bez sporu o znaczenie słowa „rabat”.

Co dokładnie znaczy „gotowe”

Odbiór powinien opierać się na sprawdzalnych scenariuszach. Klient dodaje produkt, wybiera wariant, składa zamówienie, płaci, otrzymuje wiadomość, a zamówienie trafia do systemu obsługi. Potwierdzenie operatora musi zostać prawidłowo zapisane. Sam zrzut ekranu koszyka nie dowodzi, że ten proces działa.

Wymagaj opisania sposobu testowania urządzeń mobilnych, integracji i sytuacji wyjątkowych. Co stanie się po przerwaniu płatności? Jak sklep obsłuży chwilowy brak połączenia z ERP? Kto zobaczy informację o nieprzekazanym zamówieniu? Te pytania odsłaniają zakres, którego nie widać podczas prezentacji najlepszego scenariusza.

Jeśli oferta zawiera obietnicę wydajności, poproś o warunki pomiaru: wielkość katalogu, obciążenie, konfigurację serwera i mierzone widoki. „Szybki sklep” jest oceną, a nie kryterium odbioru. Ustal też, kto dostarcza dane testowe, ile czasu firma ma na sprawdzenie etapu i gdzie zgłasza uwagi.

Na koniec etapu powinny być dostępne działający rezultat, lista znanych ograniczeń i kod odpowiadający wdrożeniu. Jeśli nie można uruchomić projektu poza komputerem autora, jego przejęcie pozostaje trudne niezależnie od jakości prezentacji.

Wsparcie po uruchomieniu

Oddziel naprawę błędów objętych ustaleniami od bieżącego utrzymania oraz dalszego rozwoju. Zapytaj, jak wykonawca traktuje awarię po aktualizacji zewnętrznego modułu albo zmianie API operatora. Nie wszystkie przyszłe problemy wynikają z wad wdrożenia. Oferta powinna wyjaśniać, kto je diagnozuje i według jakich zasad rozlicza pracę.

Czas reakcji nie jest czasem naprawy. Potwierdzenie odebrania zgłoszenia po godzinie nie oznacza przywrócenia płatności w godzinę. Ustal godziny wsparcia, kanał awaryjny, poziomy pilności i sposób eskalacji. Jeśli sklep sprzedaje również w weekendy, sprawdź, czy umowa przewiduje wtedy jakąkolwiek obsługę.

W budżecie utrzymania uwzględnij aktualizacje, monitoring, kopie oraz próby odtworzenia. Dowiedz się, kto kontroluje wygasające licencje i certyfikaty. Zapytaj też o raport: powinno być jasne, jakie prace wykonano, jakie problemy pozostały i co wymaga decyzji właściciela sklepu.

Jak zakończy się współpraca

Warunki przekazania projektu ustal przed podpisaniem umowy. Potrzebne są źródła, aktualna dokumentacja, lista usług, instrukcja wdrożenia i opis integracji. Do tego dochodzą zasady przekazania prac rozpoczętych, ale jeszcze nieodebranych. Forma i skutki zakończenia umowy wymagają sprawdzenia w jej konkretnych zapisach.

Sprawdź, czy przewidziano czas na pytania nowego zespołu i ile będzie kosztował. Przekazanie archiwum bez informacji o konfiguracji może nie pozwolić na odtworzenie środowiska. Dobrym kryterium technicznym jest możliwość uruchomienia kopii przez osobę, która wcześniej nie pracowała przy projekcie.

Jeśli właśnie zmieniasz wykonawcę, osobna lista czynności znajduje się w artykule o przejęciu sklepu po agencji. Warto wykorzystać ją także przy ocenie nowej oferty, zanim pojawią się problemy z dostępami.

Pytania, które możesz wysłać wykonawcom

1. Jakie funkcje i widoki obejmuje podana cena, a jakie są wyłączone?
2. Które założenia trzeba jeszcze potwierdzić przed ustaleniem terminu?
3. Co dokładnie obejmuje każda integracja i kto odpowiada za jej błędy?
4. Jakie dane przenosicie i jak sprawdzicie kompletność migracji?
5. Jakich materiałów oraz decyzji oczekujecie od naszego zespołu?
6. Jak będzie wyceniana i zatwierdzana zmiana zakresu?
7. Jakie scenariusze zdecydują o odbiorze sklepu?
8. Na jakich danych i urządzeniach przeprowadzicie testy?
9. Jakie licencje trzeba odnawiać i kto będzie właścicielem kont?
10. Jakie uprawnienia do kodu i materiały otrzymamy po zakończeniu?
11. Jakie są godziny wsparcia oraz czasy reakcji na awarię sprzedaży?
12. Ile kosztuje utrzymanie i co obejmuje przez kolejne lata?
13. Jak wygląda przekazanie projektu innemu wykonawcy?

Odpowiedzi zachowaj przy finalnej wersji oferty. Jeśli ważne ustalenie padło na spotkaniu, poproś o dopisanie go do dokumentu opisującego zakres. Po kilku miesiącach obie strony mogą inaczej pamiętać rozmowę, a zespół realizujący projekt może nie uczestniczyć w sprzedaży. Pisemny opis przykładu i kryterium odbioru ogranicza to ryzyko.

Najczęstsze pytania

Czy najtańsza oferta zawsze oznacza mniejszy zakres?

Nie. Wykonawca może mieć gotowe rozwiązanie i doświadczenie w podobnym procesie. Poproś jednak o potwierdzenie tych samych wymagań i kosztów utrzymania, zanim uznasz różnicę za oszczędność.

Co powinno znaleźć się w ustaleniach o prawach do kodu?

Trzeba rozróżnić kod dedykowany, komponenty zewnętrzne, źródła i możliwość dalszych modyfikacji. Ustal zakres praw lub licencji oraz moment i warunki ich uzyskania. Prawnik powinien zweryfikować zapis pod kątem konkretnej umowy.

Czy warto płacić za analizę przedwdrożeniową?

Tak, jeśli jej wynikiem będą wymagania, ryzyka i zakres pozwalający porównać warianty. Przed zakupem uzgodnij, jakie dokumenty otrzymasz i czy będzie można wykorzystać je przy wyborze innego wykonawcy.

Jak sprawdzić realizacje agencji?

Zapytaj, za którą część pokazanego sklepu odpowiadała i kiedy wykonywała pracę. Za zgodą klienta poproś o rozmowę dotyczącą komunikacji, rozliczania zmian i wsparcia po starcie. Sam wygląd witryny nie pokazuje jakości współpracy.

Przed wyborem zbierz odpowiedzi w jednym dokumencie i zaznacz niewyjaśnione pozycje. Jeśli potrzebujesz niezależnej oceny zakresu i kolejności prac, sprawdź wsparcie w decyzjach o rozwoju sklepu.

Artykuł Jak ocenić ofertę agencji e-commerce pochodzi z serwisu eCommerce Expert.

Pierwsze 48 godzin: dostępy i kopia

Wyznacz jedną osobę, która zbierze informacje i będzie koordynować zmiany. Jeśli każdy pracownik osobno prosi o reset hasła albo zmienia ustawienia, łatwo stracić orientację. Przygotuj rejestr usług: nazwa, właściciel konta, adres logowania, kontakt do dostawcy, termin odnowienia i osoba mająca dostęp. Haseł nie zapisuj w ogólnodostępnym arkuszu.

Sprawdź domenę i DNS, hosting, panel sklepu, bazę danych, repozytorium, pocztę, operatorów płatności, integracje kurierskie oraz system ERP. Dołącz konta analityczne, narzędzia reklamowe i usługi przechowujące kopie. Dostęp administratora sklepu nie oznacza dostępu do serwera, a możliwość opłacenia hostingu nie musi oznaczać kontroli nad domeną.

Przy odzyskiwaniu kont korzystaj z oficjalnych procedur dostawców i dokumentów potwierdzających uprawnienia firmy. Najpierw sprawdź adresy oraz numery używane do odzyskiwania dostępu. Po uporządkowaniu sytuacji nadaj nowemu zespołowi oddzielne konta. Zmianę haseł i kluczy zaplanuj z uwzględnieniem usług, które ich używają, aby przypadkiem nie zatrzymać synchronizacji.

Wykonaj kopię plików i bazy przed większymi zmianami. Zabezpiecz również logi, konfigurację zadań cyklicznych i ustawienia serwera potrzebne do odtworzenia sklepu. Nie przechowuj archiwum w publicznym katalogu witryny. Jeśli nie masz dostępu technicznego, poproś hosting o zabezpieczenie danych w ramach przysługujących Ci uprawnień.

Co masz, a czego brakuje

Oddziel działającą wersję sklepu od materiałów potrzebnych do jego rozwoju. Na serwerze mogą być pliki PHP, lecz tylko zbudowane i pomniejszone pliki JavaScript oraz CSS. Brakować może źródeł motywu, konfiguracji narzędzi lub skryptu wdrożenia. Kopia serwera jest wtedy cenna, ale nie zastępuje kompletnego projektu.

Sprawdź repozytorium: czy zawiera ostatnią wdrożoną wersję, wszystkie własne moduły i historię zmian? Sam dostęp do pustego albo dawno nieaktualizowanego repozytorium nie wystarczy. Porównanie z produkcją pokaże, czy poprawki były robione bezpośrednio na serwerze i czy można je odtworzyć.

• Zbierz kod dedykowany, źródła motywu i instrukcję jego budowania.
• Odszukaj listę licencji, faktury i konta producentów rozszerzeń.
• Zabezpiecz opis integracji, zadań cyklicznych i automatycznych eksportów.
• Sprawdź, czy istnieje instrukcja wdrożenia i przywracania kopii.
• Zbierz otwarte zgłoszenia, zaakceptowane wymagania oraz niedokończone prace.

Przy brakach zapisz ich skutek. Brak dokumentacji modułu może oznaczać potrzebę analizy kodu. Brak źródeł części interfejsu może wymusić jej odtworzenie. Brak uprawnienia do pobrania aktualizacji dodatku wymaga kontaktu z producentem. Taki opis jest bardziej przydatny niż ogólna ocena, że poprzednia agencja zostawiła bałagan.

Jak ocenić stan sklepu

Nowy wykonawca powinien najpierw uruchomić kopię w odizolowanym środowisku. Trzeba ograniczyć dostęp, wyłączyć prawdziwą wysyłkę wiadomości i odłączyć automatyzacje tworzące dokumenty lub przesyłki. Dopiero na takiej kopii można sprawdzać aktualizacje i wpływ wyłączenia podejrzanych modułów.

Przegląd obejmuje wersję platformy i PHP, rozszerzenia, zmiany w rdzeniu, uprawnienia, kopie oraz sposób wdrażania. W PrestaShop osobnej uwagi wymagają override’y. Lista techniczna powinna zostać powiązana ze sprzedażą: która część odpowiada za ceny, dostępność, płatności i przekazanie zamówień.

Sprawdź zadania wykonywane w tle. Sklep może wyglądać poprawnie, choć od tygodnia nie aktualizuje stanów albo nie odbiera potwierdzeń. Dla każdej integracji ustal kierunek wymiany, częstotliwość, miejsce logów i osobę reagującą na błędy. Zwróć uwagę na procesy uruchamiane dotąd z infrastruktury poprzedniego wykonawcy.

Raport przejęcia powinien podzielić prace według skutków: pilne zagrożenia dla sprzedaży i danych, niezbędne działania utrzymaniowe oraz późniejszy rozwój. Przy każdej pozycji potrzebne są dowód, proponowany rezultat i szacunek z zaznaczoną niepewnością. Sam wiek sklepu nie uzasadnia budowy nowego systemu.

Sprawy formalne do wyjaśnienia

Zbierz umowę, zamówienia, protokoły odbioru, korespondencję i dokumenty licencyjne. Sprawdź, co uzgodniono w sprawie kodu, dostępu do źródeł, modyfikacji oraz przekazania po zakończeniu współpracy. Nie wyciągaj wniosku o prawach do całego projektu wyłącznie z faktury lub faktu korzystania ze sklepu.

Komponenty zewnętrzne mają własne warunki. Moduł kupiony przez agencję może wymagać przeniesienia konta, zmiany przypisania domeny albo nowej licencji; zależy to od zasad producenta i ustaleń z wykonawcą. Poproś o potwierdzenie dla konkretnego produktu. Ogólne zapewnienie, że „wszystko jest opłacone”, nie wyjaśnia dostępu do aktualizacji.

Jeśli trwa spór o kod lub odmowę wydania materiałów, przedstaw prawnikowi dokumenty i dokładną listę braków. Podstawowe regulacje zawiera ustawa o prawie autorskim, ale ocena uprawnień wymaga uwzględnienia konkretnej umowy. Techniczne zabezpieczenie sklepu i dochodzenie roszczeń to odrębne zadania.

Przekazanie bazy nowej firmie wymaga także uporządkowania zasad dostępu do danych osobowych. Zweryfikuj role, dokumentację powierzenia i sposób zakończenia dostępu poprzedniego wykonawcy z osobą odpowiedzialną za ochronę danych. Ustal postępowanie z kopiami roboczymi; obowiązki związane z zakończeniem usług omawia materiał UODO o powierzeniu przetwarzania. Nie przesyłaj pełnej bazy do kilku potencjalnych wykonawców tylko po to, by porównali wycenę.

Jak przygotować przekazanie nowemu zespołowi

Przygotuj krótki dokument opisujący działanie firmy i sklepu. Wymień najważniejsze procesy, terminy kampanii i ograniczenia wdrożeniowe. Dołącz kilka przykładów zamówień z nietypowymi warunkami. Osoba przejmująca sklep musi wiedzieć, jakie zachowanie ma zachować, a nie jedynie jak uruchomić aplikację.

Materiały uporządkuj w czterech grupach: kod i wdrożenia, usługi i dostępy, procesy biznesowe oraz lista problemów. Sekrety przekaż oddzielnie w menedżerze haseł. Każdemu dostępowi przypisz właściciela, a po zakończeniu przejęcia usuń zbędne uprawnienia i nieużywane klucze.

Ustal mierzalny koniec etapu przejęcia. Nowy zespół powinien umieć odtworzyć sklep, wykonać kontrolowane wdrożenie, znaleźć logi awarii i wskazać sposób kontaktu z dostawcami. Powinien również przedstawić listę braków, których jeszcze nie rozwiązano. Przejęcie nie musi oznaczać naprawienia wszystkich historycznych problemów jednocześnie.

Jak ograniczyć zależność od kolejnego wykonawcy

Własne konta i aktualna dokumentacja powinny być elementem zwykłej pracy, a nie pakietem przygotowywanym dopiero przy rozstaniu. Odbieraj kod oraz opis zmian po etapach. Sprawdzaj, czy wdrożona wersja znajduje się w repozytorium i czy wiadomo, jak ją odtworzyć.

Wyznacz po stronie firmy osobę odpowiedzialną za terminy odnowień i dostępów. Uzgodnij regularną próbę przywrócenia kopii oraz aktualizację listy integracji. Nawet dobry wykonawca może zmienić zespół, zakończyć usługę albo być czasowo niedostępny. Sklep powinien mieć udokumentowany sposób działania także w takiej sytuacji.

Przed nową umową wykorzystaj listę pytań do agencji e-commerce. Szczególnie dokładnie sprawdź warunki przekazania projektu i obsługi awarii po starcie.

Ustal także kanał kontaktu na czas przejęcia. Pracownicy powinni wiedzieć, komu zgłaszać brak zamówienia, błędną cenę lub niedziałającą wysyłkę i jakie dane dołączyć. Nowy wykonawca potrzebuje jednej listy zgłoszeń z priorytetami. Bez niej łatwo skupić się na widocznych drobiazgach, podczas gdy poważny problem integracyjny pozostaje w prywatnej korespondencji. Po pierwszym przeglądzie wspólnie zatwierdź kolejność napraw i termin ponownej oceny stanu sklepu.

Najczęstsze pytania

Wykonawca nie oddaje dostępów. Co mogę zrobić?

Zbierz dokumenty, określ brakujące konta i skorzystaj z oficjalnych procedur ich dostawców. Równolegle wyjaśnij z prawnikiem obowiązki wynikające z umowy. Nie próbuj uzyskiwać dostępu do cudzych kont poza procedurą autoryzacji.

Czy moduły kupione przez agencję są moje?

To zależy od licencji, sposobu zakupu i umowy. Sprawdź możliwość korzystania, aktualizacji oraz przekazania obsługi innemu wykonawcy. Potrzebne jest potwierdzenie dla konkretnego rozszerzenia.

Czy trzeba budować sklep od nowa?

Nie. Najpierw trzeba ocenić, czy można go odtworzyć, utrzymywać i rozwijać. Odbudowa może być uzasadniona, ale powinna wynikać z porównania kosztów i ograniczeń.

Ile trwa przejęcie sklepu?

Zależy od dostępów, dokumentacji i stopnia modyfikacji. Rozdziel zabezpieczenie bieżącej sprzedaży od pełnego rozpoznania projektu. Termin drugiego etapu można wiarygodnie ustalić po pierwszym przeglądzie.

Jeśli potrzebujesz pomocy, przygotuj listę dostępów, opis aktualnych problemów i informację o ostatniej kopii. To dobry punkt wyjścia do przejęcia i ustabilizowania sklepu.

Artykuł Sklep porzucony przez wykonawcę: od czego zacząć pochodzi z serwisu eCommerce Expert.

Co w B2B naprawdę komplikuje sklep

Sprzedaż dla firm może przypominać zwykły sklep detaliczny z ceną po zalogowaniu. Może też obejmować wiele oddziałów klienta, różne role kupujących, limity, akceptację przełożonego i negocjowanie części zamówienia. Oba modele noszą nazwę B2B, lecz wymagają innego zakresu wdrożenia.

Przed porównaniem platform opisz reguły na przykładach. Co widzi pracownik kontrahenta, a co jego kierownik? Czy rabat zależy od produktu, ilości, umowy czy salda? Co dzieje się po przekroczeniu limitu kupieckiego? Czy handlowiec może zmienić ofertę i czy klient musi ją ponownie zaakceptować? Te odpowiedzi wyznaczają strukturę systemu.

Uwzględnij także pracę po zakupie. Częściowa dostępność, dostawa z kilku magazynów, podział zamówienia i korekta adresu wpływają na obsługę. Wybór dokonany wyłącznie na podstawie wyglądu katalogu pomija miejsce, w którym zespół może wykonywać najwięcej pracy ręcznej.

Gdzie PrestaShop może wystarczyć

PrestaShop udostępnia ceny specyficzne, które można wiązać między innymi z klientem, grupą i ilością produktu. Producent opisuje ich konfigurację w instrukcji cen specyficznych. Dlatego sama potrzeba indywidualnej ceny nie jest jeszcze argumentem za budową bardziej złożonego rozwiązania.

Jeśli firma ma powtarzalny proces zakupu, jasno ustalone grupy cenowe i integrację z ERP, sprawdź ten wariant w pierwszej kolejności. Potrzebna jest próba na prawdziwych regułach: klient z ceną umowną, próg ilościowy, promocja i zmiana liczby sztuk. Zobacz, czy wynik jest zgodny także po przekazaniu zamówienia do systemu handlowego.

Dodatkowe funkcje mogą wymagać modułów. Przy każdej sprawdź producenta, aktualizacje, zgodność z używaną wersją oraz sposób współpracy z innymi dodatkami. Kilka rozszerzeń nie musi oznaczać problemu. Trudność pojawia się wtedy, gdy kilka niezależnych elementów próbuje jednocześnie decydować o tej samej cenie albo statusie zamówienia.

Nie ustalaj granicy na przykład na stu czy pięciuset kontrahentach. Większa liczba firm stosujących jedną prostą regułę może być łatwiejsza do obsługi niż niewielka grupa z odmiennymi procesami zakupowymi. Znaczenie mają liczba reguł i rekordów, częstotliwość zmian oraz czas odpowiedzi przy konkretnym obciążeniu.

Kiedy warto sprawdzić Syliusa

Sylius jest rozwijany jako framework e-commerce oparty na Symfony, czyli baza do budowy i dostosowania aplikacji handlowej. Tak opisuje projekt jego producent. W analizie wdrożenia warto go rozważyć, gdy nietypowa logika jest stałym elementem działalności i będzie dalej rozwijana.

Przykładem jest organizacja klienta mająca wiele kont, budżety oddziałów i kolejne poziomy akceptacji. Innym może być koszyk przechodzący w ofertę, później negocjowaną i zatwierdzaną. W takim projekcie trzeba opisać stany procesu, uprawnienia i zdarzenia, które je zmieniają. Czytelny model tych reguł ułatwia ocenę kolejnych zmian.

Nie oznacza to, że wszystkie funkcje B2B są dostępne od razu w bezpłatnej edycji. Oferta Sylius Plus obejmuje komercyjne rozszerzenia, w tym B2B Suite oraz obsługę zapytań ofertowych. W wycenie trzeba wskazać, co pochodzi z podstawy, co z płatnego pakietu, a co zostanie napisane. Funkcje i warunki licencji należy potwierdzić dla wybranego wariantu.

Większa swoboda oznacza również więcej decyzji po stronie zespołu. Trzeba zaplanować obsługę treści, integracje, interfejs pracowników i wdrożenia. Nie porównuj standardowej instalacji PrestaShop z nieograniczonym zestawem możliwości, które w Syliusie dopiero powstaną. Porównuj dwie gotowe do wykonania propozycje o tym samym zakresie.

Integracja z ERP: gdzie powstaje ostateczna cena

Najpierw wybierz źródło prawdy dla produktu, stanu, ceny i limitu. Nie musi to być ten sam system dla każdego rodzaju danych, ale odpowiedzialność musi być jednoznaczna. Jeśli ERP ustala warunki handlowe, sklep nie powinien po cichu dokładać konkurencyjnych reguł, których dział sprzedaży nie potrafi potem wyjaśnić.

Ustal zachowanie przy niedostępności integracji. Czy można pokazać ostatnią znaną cenę? Jak długo jest ważna? Czy wolno przyjąć zamówienie, czy tylko zapytanie? Co zobaczy klient, jeśli limit zmienił się między otwarciem koszyka a zatwierdzeniem? Odpowiedzi powinny trafić do wymagań i testów obu wariantów.

Sprawdź również ponawianie operacji. Jeśli połączenie urwie się po zapisaniu zamówienia w ERP, ponowna próba nie powinna tworzyć drugiego dokumentu. Potrzebne są identyfikatory, logi i sposób uzgadniania stanu. Gotowy moduł integracyjny warto oceniać właśnie na takich sytuacjach, a nie tylko na udanym przesłaniu pojedynczego produktu.

Koszt, który widać dopiero podczas rozwoju

Porównaj koszty uruchomienia i trzech kolejnych lat. Wpisz licencje, hosting, utrzymanie, aktualizacje, monitoring oraz planowane zmiany. Dodaj czas pracowników obsługujących wyjątki ręcznie. Jeśli jeden wariant nie realizuje potrzebnego procesu, jego niższa wycena nie opisuje jeszcze kosztu działania firmy.

W PrestaShop część prac może sprowadzać się do konfiguracji i dostosowania modułów. W Syliusie większy udział może mieć własny kod lub komercyjne pakiety. Nie wynika z tego stała różnica cen dla każdego projektu. Sprawdź konkretne oferty, zakres testów i dostępność osób, które będą utrzymywały wdrożenie.

Poproś o wycenę dwóch przewidywanych zmian po starcie. Może to być nowy typ rabatu oraz drugi etap akceptacji zamówienia. Nie chodzi o gwarantowaną cenę na wiele lat, lecz o sprawdzenie, które obszary trzeba będzie przebudować. Architektura korzystna przy pierwszym uruchomieniu może okazać się trudna przy planowanym kierunku rozwoju.

Uwzględnij przejęcie projektu przez inny zespół. Dokumentacja, czytelny kod, testy reguł i powtarzalne wdrożenie mają wartość na obu platformach. Sama popularność technologii nie daje zastępstwa, jeśli całą wiedzę o cenach i integracjach posiada jedna osoba.

Czy B2B potrzebuje headless

Headless oznacza oddzielenie warstwy, z której korzysta klient, od systemu obsługującego handel. Może mieć sens, gdy te same procesy mają zasilać kilka interfejsów lub gdy rozwój frontu wymaga dużej niezależności. Potrzeba powinna być jednak opisana konkretnym zastosowaniem.

Osobny frontend dodaje obszary do utrzymania: logowanie, sesję, koszyk, obsługę błędów, analitykę i zgodność interfejsów. Nie przyspiesza automatycznie wyliczania cen w ERP. Jeżeli jedynym uzasadnieniem jest nowoczesny wygląd, porównaj również rozwiązanie bez rozdzielania aplikacji. Projekt graficzny nie przesądza o architekturze.

Trzecia możliwość: poprawić obecny sklep

Gdy problemem są niespójne reguły albo wolny import, zacznij od ich uporządkowania. Migracja nie ustali za firmę, który cennik obowiązuje i kto zatwierdza wyjątki. Najpierw opisz proces, usuń sprzeczności i sprawdź, czy obecna platforma rzeczywiście stanowi przeszkodę.

Można również wydzielić wybrany obszar, na przykład obliczanie cen, bez natychmiastowej wymiany całego sklepu. To rozwiązanie wymaga własnej analizy dostępności i spójności danych, ale pozwala oddzielić konkretny problem od pełnej migracji. Porównaj jego koszt z uporządkowaniem modułów oraz zmianą platformy.

Jak przeprowadzić porównanie

1. Spisz procesy zakupowe, role klientów i reguły handlowe.
2. Oddziel wymagania obowiązkowe na start od późniejszego rozwoju.
3. Przygotuj przykładowe dane i zamówienia pokazujące trudne przypadki.
4. Zleć wycenę obu wariantów na tej samej liście wymagań.
5. Sprawdź prototyp najbardziej ryzykownego procesu.
6. Porównaj koszt utrzymania, ograniczenia i możliwość zmiany wykonawcy.

Przy każdym wymaganiu wpisz, jak zostanie zrealizowane oraz czego jeszcze nie sprawdzono. Taka tabela pokazuje ryzyko dużo wyraźniej niż długa lista znaków „tak” przy funkcjach. Do oceny odpowiedzi wykorzystaj poradnik jak czytać ofertę agencji e-commerce.

Najczęstsze pytania

Czy Sylius jest droższy w utrzymaniu?

Nie można tego rozstrzygnąć bez zakresu projektu. Własny kod i licencje generują koszty, ale utrzymywanie wielu kolidujących modyfikacji również. Porównaj konkretne procesy i plan rozwoju.

Czy PrestaShop obsłuży ceny indywidualne dla setek kontrahentów?

Sama liczba kontrahentów nie wyklucza tej platformy. Sprawdź sposób zapisu cen, wielkość danych i częstotliwość aktualizacji. Potrzebny jest test importu i zakupów na reprezentatywnym katalogu.

Co z integracją z ERP na obu platformach?

Oceń gotowe połączenie lub zakres budowy własnego. Najważniejsze są obsługiwane dane, błędy, ponawianie operacji i odpowiedzialność za utrzymanie. Nazwa platformy nie zastępuje tych ustaleń.

Czy headless jest potrzebny w B2B?

Nie jest warunkiem sprzedaży firmom. Warto go rozważyć przy uzasadnionej potrzebie oddzielnych interfejsów i niezależnego rozwoju. W pozostałych przypadkach może zwiększyć zakres bez rozwiązania głównego problemu.

Jeżeli decyzja zależy od kilku nietypowych reguł, zacznij od ich opisu i prototypu. W ramach doradztwa e-commerce można porównać warianty przed rozpoczęciem pełnego wdrożenia.

Artykuł PrestaShop czy Sylius w sprzedaży B2B pochodzi z serwisu eCommerce Expert.

Ta zmiana wpływa na cały sposób realizacji projektów. Programista inaczej wykorzystuje doświadczenie, agencja musi ponownie przemyśleć wycenę, a klient może zamówić prace, na które wcześniej brakowało budżetu. Każda z tych stron ma jednak inne zadanie do wykonania.

Doświadczenie przydaje się przy ocenie rozwiązania

W mojej pracy coraz większe znaczenie ma precyzyjne określenie zadania. Model potrzebuje opisu tego, co aplikacja ma robić. Jeśli opis jest niepełny, wygenerowany kod może wyglądać poprawnie, a mimo to rozwiązywać inny problem niż ten, z którym przyszedł klient.

Dlatego po wygenerowaniu kodu muszę wrócić do założeń i ocenić wynik. Tu korzystam z doświadczenia zdobytego przy wcześniejszych wdrożeniach. Pomaga mi rozpoznać błędne rozwiązanie, zanim trafi do sklepu, i zdecydować, co wymaga poprawy. Samo tempo pisania ma w tym procesie coraz mniejsze znaczenie.

Widać to na przykładzie panelu ekspertów PrestaShop, przy którym kiedyś pracowałem. Budowaliśmy go w trzech programistów przez trzy miesiące. Dziś oceniam, że z obecnymi narzędziami zrobiłbym ten sam projekt sam w miesiąc, uwzględniając sprawdzanie kodu. Duża część ówczesnej pracy była powtarzalna i właśnie ją najłatwiej mi teraz przyspieszyć.

Trudniej zacząć od prostych zadań

Przy takim sposobie pracy pojawia się problem nauki zawodu. Początkujący programista zdobywał doświadczenie na prostszych, powtarzalnych zadaniach. Ktoś musiał je wykonać, a junior miał okazję samodzielnie napisać kod i zrozumieć jego działanie.

Kiedy te zadania przejmuje model, od początkującej osoby szybciej oczekuje się oceny gotowego rozwiązania. Tyle że do tej oceny potrzebna jest wiedza, którą wcześniej zdobywało się właśnie przez pisanie. Nie mam jeszcze dobrej odpowiedzi na pytanie, jak powinna wyglądać taka nauka. Widzę natomiast, że dotychczasowa droga wejścia do zawodu wymaga przemyślenia.

Wycena musi uwzględniać nowy sposób pracy

Agencje przez lata opierały wyceny na godzinach programistów. Szacowały czas potrzebny na wykonanie zadań i mnożyły go przez stawkę. Trafność tych szacunków decydowała o tym, ile zostanie z projektu po pokryciu kosztów.

Jeśli część zadań można wykonać kilkukrotnie szybciej, stare kalkulacje przestają odpowiadać rzeczywistemu nakładowi pracy. Jedne agencje obniżają ceny i przyjmują więcej zleceń. Inne utrzymują cenę, mocniej opierając ofertę na zrozumieniu potrzeb klienta i odpowiedzialności za wdrożenie. Są też wykonawcy, którzy nadal wyceniają projekty według dawnych założeń.

Z punktu widzenia klienta liczy się więc wyjaśnienie, co zawiera oferta. Ile czasu zajmie rozpoznanie potrzeb? Jak powstanie kod i kto go sprawdzi? Co wykonawca zrobi, gdy po uruchomieniu pojawi się problem? Sama informacja o korzystaniu z AI nie odpowiada na żadne z tych pytań.

Niższy koszt wykonania otwiera nowe możliwości

Dla właściciela sklepu krótszy czas pracy może oznaczać tańszy moduł, integrację z magazynem albo przebudowę koszyka. Wtedy zmiany odkładane ze względu na koszt stają się możliwe w obecnym budżecie. To bardzo praktyczny skutek rozwoju tych narzędzi.

Oszczędność ma jednak sens wtedy, gdy obejmuje wykonanie działającego rozwiązania wraz z jego sprawdzeniem. Kod da się wygenerować szybko również bez kontroli. Moduł uruchomiony po jednym wieczorze pracy może działać do pierwszej aktualizacji platformy albo nietypowego zamówienia.

Spodziewam się, że takich przypadków będzie coraz więcej w audytach. Ustalenie przyczyny awarii nadal wymaga zrozumienia, co się wydarzyło, i nie staje się tańsze tylko dlatego, że sam kod powstał szybko. Dlatego przy wyborze wykonawcy pytałbym o testy, przegląd kodu i odpowiedzialność za późniejsze naprawy.

Najpierw trzeba wiedzieć, co warto zbudować

Niezależnie od narzędzi sklep potrzebuje rozwiązania dopasowanego do sposobu działania firmy. Model danych trzeba zaprojektować pod jej procesy. Przy integracji z ERP nadal potrzebuję rozmowy z osobą, która wie, dlaczego numer partii trafia do pola uwag. Tego nie wyczytam z przykładu w dokumentacji.

Podobnie jest z decyzją o migracji. Zanim doradzę zmianę platformy, przebudowę sklepu albo pozostawienie obecnego rozwiązania, muszę porównać koszty tych wariantów. AI pomaga w wykonaniu prac, ale bez wiedzy o firmie nie wybierze za klienta właściwego kierunku.

Właśnie dlatego w mojej pracy więcej miejsca zajmują dziś rozmowy, decyzje i ocena wyników. Mogę szybciej zbudować rozwiązanie, więc tym bardziej chcę najpierw ustalić, czy klient rzeczywiście go potrzebuje i czy koszt jego wykonania ma uzasadnienie.

Artykuł AI zmienia nasz świat pochodzi z serwisu eCommerce Expert.

Sklep na PrestaShop miał trzy moduły cenników B2B, kupowane w różnym czasie od różnych producentów. Każdy realizował część zasad naliczania cen, ale nie uwzględniał działania pozostałych. Cena w koszyku potrafiła różnić się od kwoty na fakturze. Wyjaśnienie pojedynczej rozbieżności zajmowało handlowcowi pół dnia.

Analiza przed zakupem kolejnego modułu

Klient chciał wycenić czwarty moduł, który połączy działanie trzech istniejących. Zaproponowałem najpierw dwa tygodnie diagnozy. Opis problemu wskazywał, że potrzebne jest sprawdzenie całego sposobu wyliczania ceny.

Analiza pokazała, że cena zależała od czterech zmiennych: kontrahenta, produktu, wcześniejszych zakupów i salda. Moduły realizowały te zasady niezależnie, obchodząc ograniczenia przyjętego w sklepie modelu danych. Ich połączenie nie zapewniało spójnego wyniku.

Porównanie trzech rozwiązań

Przygotowałem trzy warianty z kosztem, ryzykiem i przewidywanym okresem zwrotu:

• Czwarty moduł oznaczał najmniejszy wydatek, ale oceniałem jego przydatność na około rok.
• Przepisanie zasad cenowych wewnątrz PrestaShop wymagało większej inwestycji i utrzymywania własnego obejścia architektury.
• Osobna usługa naliczająca ceny, a następnie zmiana platformy, była najdroższa, ale pozwalała usunąć źródło rozbieżności.

Do porównania dodaliśmy koszt czasu handlowców i wstrzymanych zamówień w skali roku. Przekraczał różnicę między wariantami. Po uwzględnieniu tej kwoty klient zdecydował się na wydzielenie cen i późniejszą migrację.

Najpierw ceny, potem cały sklep

W pierwszym etapie wydzieliłem obliczanie cen do usługi z API. Dotychczasowy sklep pobierał wynik przez HTTP. Ten etap zajął osiem tygodni i rozwiązał najpilniejszy problem przy zachowaniu bieżącej sprzedaży.

Docelowo sklep został przeniesiony na Syliusa, w którym reguły cenowe można było bezpośrednio opisać w modelu domenowym. Wdrożenie zajęło kolejne pięć miesięcy. Przełączenie nastąpiło po zebraniu półrocznej historii działania usługi cenowej bez rozbieżności.

Wyniki po roku

• Liczba różnic między ceną w koszyku a fakturą spadła z kilkunastu miesięcznie do zera.
• Dodanie reguły rabatowej zajmowało jeden dzień zamiast dwóch lub trzech tygodni oczekiwania na producenta modułu.
• Zamówienia z pliku były obsługiwane bezpośrednio przez sklep, bez zewnętrznego modułu.
• Testy pokrywały 94% logiki cenowej, której błędy bezpośrednio wpływały na rozliczenia.

Dlaczego ten zakres był uzasadniony

O wyborze zdecydowała skala problemu i koszt jego codziennej obsługi. Przy trzydziestu kontrahentach rekomendowałbym pozostanie przy PrestaShop i uporządkowanie modułów. Przy 380 porównanie kosztów uzasadniło zmianę. Migrację warto rozważać po sprawdzeniu, czy tańsze rozwiązanie wystarczy do osiągnięcia celu.

Artykuł Cenniki B2B dla 380 kontrahentów: zmiana sposobu naliczania cen pochodzi z serwisu eCommerce Expert.