Jak wygląda wdrożenie Magento 2? Proces od wyboru agencji do utrzymania

Po instalacji Magento mamy platformę e‑commerce, a nie gotowy system sprzedaży konkretnej firmy.

Magento zapewnia fundament pod katalog produktów, klientów, ceny, promocje, koszyk, zamówienia czy treści CMS. Trzeba jednak zdecydować, jak te mechanizmy mają działać w danym biznesie.

Weźmy producenta, który prowadzi sprzedaż detaliczną i jednocześnie obsługuje dystrybutorów. Cena detaliczna może być inna niż cena partnera B2B. Dostępność produktu może wynikać z ERP albo WMS. Opisy mogą pochodzić z PIM. Po złożeniu zamówienia dane mają trafić do ERP, a później Magento powinno otrzymać informację o statusie realizacji.

Sam sklep jest wtedy jednym z kilku systemów:

Właśnie dlatego zakres wdrożenia nie powinien powstawać wyłącznie jako lista ekranów i funkcji.

Dla producentów dochodzą dodatkowo kwestie sprzedaży D2C, B2B, dystrybutorów, katalogów produktowych i systemów wewnętrznych. Szerzej opisaliśmy je w materiale Magento 2 dla producenta.

Pierwsze rozmowy z wykonawcami są dużo bardziej konkretne, jeżeli firma potrafi odpowiedzieć przynajmniej na podstawowe pytania:

• kto będzie kupował w sklepie,
• czy sprzedaż obejmie B2C, B2B, D2C czy kilka modeli naraz,
• na ilu rynkach ma działać platforma,
• jakie systemy są już używane w firmie,
• gdzie znajdują się produkty, ceny i stany,
• co ma zostać przeniesione ze starego sklepu,
• jakie procesy są nietypowe,
• które funkcje są potrzebne przy pierwszym uruchomieniu.

Nie chodzi o napisanie własnej specyfikacji technicznej przed spotkaniem z agencją. Od tego jest analiza. Firma powinna natomiast wiedzieć, jaki problem chce rozwiązać.

„Chcemy Magento” daje wykonawcy znacznie mniej informacji niż:

„Sprzedajemy D2C w Polsce, za rok chcemy wejść do Niemiec, mamy 40 tysięcy SKU, ERP jest źródłem cen i stanów, dane produktowe trzymamy w PIM i chcemy uruchomić osobną ścieżkę dla dystrybutorów”.

Drugi opis pozwala już zacząć rozmowę o architekturze.

Przy Magento sama umiejętność tworzenia sklepów internetowych nie wystarcza. Im bardziej system jest zintegrowany z firmą, tym większe znaczenie mają doświadczenie z samą platformą, integracjami, migracjami i późniejszym utrzymaniem.

Przy porównywaniu agencji sprawdzilibyśmy przede wszystkim kilka rzeczy.

W prostym sklepie część decyzji da się podjąć szybko. W większym projekcie próba rozpoczęcia developmentu bez wcześniejszej analizy zwykle oznacza, że najważniejsze pytania wrócą później, kiedy zmiany będą już droższe.

Analiza ma odpowiedzieć między innymi na pytania:

• kto korzysta z platformy,
• jak przebiega sprzedaż,
• które procesy zostają poza Magento,
• gdzie są źródła danych,
• jakie integracje są potrzebne,
• co podlega migracji,
• co musi znaleźć się w pierwszej wersji,
• co można odłożyć na kolejny etap.

Przy bardziej złożonych projektach osobna analiza przedwdrożeniowa e‑commerce pozwala zamknąć te decyzje przed rozpoczęciem głównych prac.

To jeden z tematów, które bardzo łatwo przeoczyć.

Firma ma ERP, PIM i Magento. Każdy z tych systemów przechowuje informacje o produktach. Nie oznacza to jednak, że każdy powinien móc swobodnie zmieniać wszystko.

Przykładowy podział może wyglądać tak:

Bez ustalenia właściciela danych prędzej czy później pojawi się pytanie, dlaczego ERP pokazuje jedną wartość, PIM drugą, a klient w sklepie widzi trzecią.

Ten temat powinien być zamknięty przed rozpoczęciem integracji.

Gdy procesy i źródła danych są już opisane, można projektować architekturę.

W tym miejscu ustala się między innymi:

• strukturę Website, Store i Store View,
• rynki i języki,
• katalogi,
• waluty,
• źródła cen,
• sposób synchronizacji stanów,
• integracje,
• frontend,
• wyszukiwanie,
• środowiska,
• infrastrukturę.

Warstwa wizualna jest bardzo ważna, ale we wdrożeniu Magento pojawia się dopiero po wielu decyzjach dotyczących tego, jak sklep ma działać.

Projekt obejmuje zwykle między innymi:

• nawigację,
• wyszukiwanie,
• kategorie,
• filtry,
• kartę produktu,
• koszyk,
• checkout,
• konto klienta,
• treści CMS,
• widoki mobilne.

Frontend może być przygotowany na różne sposoby. W nowych projektach jedną z dostępnych opcji jest Hyvä, czyli alternatywna warstwa frontendowa dla Magento 2.

Nie każdy projekt wymaga rysowania każdej strony od pustej kartki. Jeżeli proces zakupowy jest standardowy, wykorzystanie przygotowanego systemu komponentów może skrócić projekt i pozostawić większą część budżetu na elementy specyficzne dla firmy.

Tak działa między innymi AURORA ONE, czyli wdrożenie Magento 2 z frontendem Hyvä w określonym zakresie.

Przy projekcie z niestandardową ścieżką zakupową, rozbudowanym konfiguratorem albo szczególnymi wymaganiami UX zakres będzie wyglądał inaczej.

Kod Magento nie powinien być rozwijany bezpośrednio na działającym sklepie.

Projekt potrzebuje procesu, który pozwala tworzyć zmianę, sprawdzić ją przed produkcją, a dopiero później udostępnić klientom.

W praktyce pojawiają się środowiska developerskie, testowe lub stagingowe oraz produkcja. Dokładna architektura zależy od projektu.

Kod powinien być wersjonowany w repozytorium. Dzięki temu wiadomo, jaka wersja znajduje się na danym środowisku, kto wprowadził zmianę i co dokładnie trafiło na produkcję.

Adobe w swojej dokumentacji również opisuje przejście od developmentu przez Staging do Production (otwiera się w nowej karcie) i zaleca pełne przetestowanie wdrożenia przed produkcją.

Nie każdą potrzebę trzeba programować.

Przy wymaganiu warto najpierw sprawdzić cztery możliwości:

1. 01Magento obsługuje je w standardzie,
2. 02wystarczy konfiguracja,
3. 03istnieje sensowne rozszerzenie,
4. 04potrzebny jest własny development.

Skrajności są kosztowne.

Pisanie od zera funkcji, która już istnieje w Magento, zwykle nie ma sensu. Instalowanie kolejnego modułu do każdego drobnego wymagania również potrafi stworzyć problem.

Każde dodatkowe rozszerzenie staje się częścią systemu, który później trzeba aktualizować, testować i sprawdzać przy zmianach wersji Magento.

Integracja działa nie tylko wtedy, gdy dane poprawnie przeszły z systemu A do systemu B.

Musi być wiadomo, co stanie się, gdy po drodze wydarzy się coś nieprzewidzianego.

Wyobraźmy sobie taki przypadek:

1. 01Magento wysyła zamówienie do ERP.
2. 02ERP zapisuje zamówienie.
3. 03Odpowiedź ERP ginie po drodze.
4. 04Magento nie wie, że operacja się udała.
5. 05Próbuje wysłać zamówienie ponownie.

Jeżeli integracja nie potrafi rozpoznać, że ten komunikat został już obsłużony, w ERP może pojawić się duplikat.

Dlatego przed uznaniem integracji za odporną trzeba sprawdzić między innymi:

• retry,
• idempotency,
• monitoring,
• timeouty,
• błędne dane,
• częściowe przetworzenie,
• sposób ponowienia operacji.

Podobnie trzeba zdecydować, które operacje wykonują się synchronicznie, a które mogą przejść przez kolejkę. Wolny ERP nie powinien automatycznie powodować, że klient przez kilkanaście sekund czeka na każdą stronę sklepu.

To właśnie takie szczegóły mają często większy wpływ na stabilność projektu niż sama liczba integracji.

Jeżeli Magento zastępuje istniejącą platformę, do projektu dochodzi migracja.

Do przeniesienia mogą być:

• produkty,
• warianty,
• atrybuty,
• kategorie,
• klienci,
• adresy,
• historia zamówień,
• treści CMS,
• blog,
• dane SEO,
• adresy URL.

Pierwsze pytanie powinno jednak brzmieć:

Które z tych danych nadal są potrzebne?

Stary system często zawiera lata zmian, nieaktualne rekordy, powielone kategorie, błędne atrybuty albo rozwiązania stworzone tylko dlatego, że poprzednia platforma miała określone ograniczenia.

Migracja jest dobrym momentem, żeby część z tego uporządkować.

Cały proces przeniesienia danych, integracji i adresów opisujemy szerzej na stronie dotyczącej migracji sklepu na Magento 2.

Na tym etapie pierwszy raz trzeba spojrzeć na sklep jak na całość, a nie zbiór ukończonych zadań.

Nie wystarczy otworzyć stronę główną, produkt i checkout.

Trzeba przejść rzeczywiste scenariusze.

Klient niezalogowany składa zamówienie. Klient zalogowany używa kodu rabatowego. Płatność zostaje odrzucona. Produkt przestaje być dostępny. ERP przez chwilę nie odpowiada. Klient B2B posiada własny cennik. Zamówienie ma zostać wysłane w dwóch paczkach.

Testowane powinny być między innymi:

Adobe ma osobne checklisty przed uruchomieniem (otwiera się w nowej karcie), obejmujące między innymi konfigurację produkcyjną, testy i przygotowanie launchu.

Tester może sprawdzić, czy rabat naliczył się zgodnie ze specyfikacją.

Nie zawsze będzie jednak wiedział, że określona grupa dystrybutorów zgodnie z wewnętrzną polityką firmy nigdy nie powinna móc łączyć tego rabatu z promocją sezonową.

Dlatego przed uruchomieniem potrzebny jest UAT, czyli User Acceptance Testing.

Zespół klienta sprawdza wtedy system z perspektywy codziennej pracy i realnych procesów biznesowych.

Najlepiej, gdy robią to osoby, które faktycznie będą później korzystać z platformy: e‑commerce, sprzedaż, magazyn, obsługa klienta czy marketing.

Przy istniejącym sklepie uruchomienie przypomina bardziej operację migracyjną niż publikację nowej strony internetowej.

Trzeba ustalić moment, w którym:

• zatrzymywane są zmiany w starym sklepie,
• wykonywana jest ostatnia migracja danych,
• uruchamiane są produkcyjne integracje,
• zmieniane są DNS,
• wykonywane są testowe zamówienia,
• sprawdzane są płatności,
• zaczyna działać monitoring.

Potrzebny jest również plan na sytuację, w której któryś z krytycznych elementów nie zadziała.

Kto podejmuje decyzję o kontynuowaniu launchu? Kiedy wykonujemy rollback? Kto kontaktuje się z operatorem płatności? Kto sprawdza ERP?

Adobe w swojej dokumentacji fazę launchu (otwiera się w nowej karcie) traktuje jako osobny etap obejmujący deployment produkcyjny, konfigurację bezpieczeństwa, weryfikację usług i monitoring wydajności.

Sklep musi działać na infrastrukturze dobranej do jego charakterystyki.

Znaczenie mają między innymi:

• ruch,
• wielkość katalogu,
• liczba wersji sklepu,
• ciężar importów,
• wyszukiwarka,
• kolejki,
• integracje,
• wymagania dotyczące dostępności.

Nie każdy sklep potrzebuje rozbudowanej architektury chmurowej. Jednocześnie przypadkowy hosting dobrany wyłącznie na podstawie ceny może stać się wąskim gardłem całego projektu.

Przykładowe podejście do VPS, serwera dedykowanego i AWS opisaliśmy na stronie hostingu Magento 2.

Pierwsze dni produkcji pokazują rzeczy, których środowisko testowe nie zawsze potrafi odtworzyć.

Pojawiają się prawdziwi klienci, rzeczywisty ruch, pełny katalog, realne zamówienia i wszystkie zewnętrzne systemy działające jednocześnie.

W tym okresie szczególnie uważnie obserwuje się:

• błędy aplikacji,
• checkout,
• płatności,
• integracje,
• kolejki,
• indeksy,
• wydajność,
• zasoby serwera.

Po launchu część problemów będzie zwykłymi błędami do poprawienia. Część okaże się nową potrzebą biznesową, która wcześniej nie była widoczna.

I tutaj kończy się etap wdrożeniowy, a zaczyna codzienne życie sklepu.

Działający Magento wymaga opieki technicznej.

W zależności od ustalonego zakresu utrzymanie może obejmować:

• monitoring,
• reagowanie na awarie,
• aktualizacje Magento,
• poprawki bezpieczeństwa,
• aktualizacje modułów,
• analizę błędów,
• kontrolę integracji,
• administrację techniczną,
• reagowanie na zmiany prawne wymagające zmian w sklepie.

Samo określenie „support Magento” niewiele mówi.

Firma powinna wiedzieć, co jest monitorowane, kiedy dostępny jest zespół i jak wygląda procedura w przypadku krytycznej awarii.

W Aurora Creation ten obszar jest wydzielony jako AURORA CARE: utrzymanie Magento 2, monitoring i SLA.

SLA opisuje sposób reagowania na zdarzenia.

Najczęściej określa między innymi:

• godziny dostępności,
• klasy incydentów,
• czas reakcji,
• zasady eskalacji,
• kanał zgłoszeń.

Innego poziomu zabezpieczenia potrzebuje sklep D2C, który prowadzi sprzedaż przez całą dobę, a innego portal B2B używany przez kontrahentów głównie w dni robocze.

SLA powinno więc wynikać z konsekwencji biznesowej awarii, a nie z potrzeby posiadania możliwie najwyższego pakietu.

Granica jest stosunkowo prosta.

Jeżeli checkout, który do tej pory działał, zaczyna generować błąd, mamy problem utrzymaniowy.

Jeżeli firma chce dodać nową metodę składania zamówienia, funkcję dla handlowców albo konfigurator produktu, jest to rozwój.

Do rozwoju zaliczymy na przykład:

• nową integrację,
• kolejny rynek,
• przebudowę karty produktu,
• nowy proces B2B,
• automatyzację operacji,
• rozbudowę konta klienta.

W Aurora Creation zaplanowany rozwój istniejących sklepów jest prowadzony w ramach AURORA EVOLUTION, a bieżące utrzymanie pozostaje osobnym zakresem.

To rozdzielenie jest praktyczne także po stronie klienta. Awaria zamówień ma inny priorytet niż pomysł marketingu na nową sekcję karty produktu.

Agencja nie jest w stanie sama zdecydować, jakie warunki handlowe ma dostać dystrybutor. Klient z kolei nie powinien być zmuszony projektować architektury integracji.

Podział odpowiedzialności może wyglądać na przykład tak:

Najwięcej problemów pojawia się zwykle tam, gdzie odpowiedzialność została pozostawiona „domyślnie”.

Nie ma jednego czasu wdrożenia Magento.

Projekt o gotowym zakresie i niewielkiej liczbie zależności może zostać uruchomiony stosunkowo szybko. Platforma B2B połączona z ERP, PIM i WMS, z migracją dużego katalogu i kilkoma rynkami, będzie zupełnie innym przedsięwzięciem.

Na czas wpływają przede wszystkim:

• funkcje niestandardowe,
• liczba integracji,
• gotowość API,
• jakość danych,
• zakres migracji,
• liczba rynków,
• proces UX/UI,
• testy,
• czas potrzebny na decyzje po stronie klienta.

Dlatego pytanie „ile trwa Magento?” niewiele pomaga.

Znacznie lepsze jest:

Ile potrwa realizacja tego konkretnego zakresu i od jakich zależności zależy termin?

Podobnie wygląda kwestia ceny.

Koszt projektu może obejmować:

• analizę,
• projekt UX/UI,
• frontend,
• konfigurację,
• development,
• moduły,
• integracje,
• migrację,
• testy,
• infrastrukturę,
• utrzymanie.

Dwie oferty mogą różnić się o kilkadziesiąt procent i nadal obie być racjonalne, jeżeli obejmują inny zakres.

Właśnie dlatego przy porównywaniu ofert trzeba zejść poziom niżej niż suma na końcu dokumentu.

Wyobraźmy sobie dwie oferty.

W pierwszej znajduje się jedna linia:

Integracja ERP: 15 000 zł.

W drugiej zakres został rozpisany na produkty, ceny, stany, zamówienia, kontrahentów, statusy, kolejkę, ponowienia i monitoring.

Nie mamy jeszcze podstaw, żeby stwierdzić, która oferta jest droższa.

Najpierw trzeba sprawdzić, czy obie rzeczywiście obejmują to samo.

Przy każdym większym elemencie projektu powinno dać się odpowiedzieć na trzy pytania:

• Co dokładnie zostanie wykonane?
• Czego nie ma w zakresie?
• Po czym poznamy, że zadanie zostało zakończone?

To znacznie lepszy sposób porównywania ofert niż zestawienie samych stawek godzinowych.

Zmiana agencji w trakcie projektu nie oznacza automatycznie, że wszystko trzeba napisać od początku.

Najpierw trzeba sprawdzić, co rzeczywiście istnieje.

Przy przejęciu interesują nas między innymi:

• kod,
• repozytorium,
• konfiguracja,
• środowiska,
• moduły,
• integracje,
• infrastruktura,
• dane,
• dokumentacja,
• otwarte zadania.

Dopiero po takim przeglądzie można podjąć decyzję, które elementy zachować, które poprawić i czy coś trzeba wykonać ponownie.

Aurora Creation prowadzi takie projekty jako osobny zakres: dokończenie rozpoczętego sklepu Magento 2.

Dobrze przygotowany projekt nie kończy się sytuacją, w której klient dostał sklep i dane dostępowe.

Firma powinna wiedzieć:

• gdzie znajduje się kod,
• jak wygląda architektura,
• które systemy są źródłem danych,
• jak wdraża się zmiany,
• gdzie działa produkcja,
• kto odpowiada za infrastrukturę,
• kto monitoruje sklep,
• kto reaguje na awarie,
• jak wykonywane są aktualizacje,
• jak zgłaszany jest rozwój.

W Aurora Creation poszczególne potrzeby są z tego powodu rozdzielone.

Nowe projekty mogą być realizowane między innymi jako AURORA ONE lub jako indywidualne wdrożenia Magento. Działający sklep może przejść pod AURORA CARE, a nowe zadania rozwojowe trafiają do AURORA EVOLUTION.

Wdrożenie, utrzymanie i rozwój dotyczą tej samej platformy, ale rozwiązują różne problemy.

I właśnie ten moment można uznać za zakończenie wdrożenia.

Nie dzień, w którym Magento zostało zainstalowane.