Magento 2 – co to jest i do czego służy?

Magento 2 to platforma e‑commerce pozwalająca zbudować sklep internetowy wokół procesów konkretnej firmy. Obsługuje mechanizmy sprzedaży, katalog produktów, klientów, ceny, promocje, zamówienia, treści oraz komunikację z zewnętrznymi systemami.

Samo oprogramowanie stanowi punkt wyjścia. Działający sklep powstaje dopiero po zaprojektowaniu katalogu, procesu zakupowego, integracji, frontendu, infrastruktury i zasad późniejszego utrzymania.

Magento może odpowiadać za:

• prezentację oferty i przeprowadzenie klienta przez zakup,
• logikę cen, promocji, koszyka i zamówień,
• obsługę kont klientów oraz uprawnień,
• wymianę danych z ERP, PIM, WMS, CRM i usługami zewnętrznymi.

Standardowa instalacja zawiera mechanizmy potrzebne do prowadzenia sprzedaży. Można zarządzać produktami, kategoriami, cenami, klientami, koszykiem, zamówieniami, promocjami i treścią.

Firma nadal musi określić, jak te mechanizmy mają działać w jej modelu biznesowym. Sposób naliczania cen może zależeć od grupy klienta. Dostępność może pochodzić z kilku magazynów. Produkty mogą być opisane w PIM, a zamówienia przekazywane do ERP lub WMS.

Dopiero suma tych decyzji tworzy system, który można bezpiecznie uruchomić.

Miesięczny abonament platformy SaaS i koszt sklepu na Magento opisują inne modele odpowiedzialności. SaaS dostarcza przygotowany produkt z określonym zakresem zmian. Magento daje większą kontrolę nad systemem, ale wymaga zaprojektowania, wdrożenia i utrzymywania jego architektury.

Dwie rzeczy nie należą do standardu Open Source i nie należy ich do niego wliczać: rozszerzenie B2B z indywidualnymi katalogami i kontami firmowymi jest elementem Adobe Commerce, a część narzędzi marketingowych i usług Adobe działa wyłącznie w wersji komercyjnej. Zakres obu linii porównujemy niżej w tym artykule.

Architektura Magento pozwala zmieniać katalog, ceny, promocje, checkout, konta klientów i komunikację z systemami zewnętrznymi. Zakres ingerencji jest większy niż w wielu zamkniętych platformach.

Każda zmiana staje się jednak częścią sklepu. Trzeba ją testować, dokumentować, zabezpieczać, rozwijać i uwzględniać podczas aktualizacji.

Pytanie „czy da się to zaprogramować?” zwykle daje niewiele informacji. Decyzja powinna wynikać z wartości procesu, kosztu alternatywy oraz wpływu na późniejsze utrzymanie.

Dojrzałość projektu Magento widać po liczbie świadomych decyzji, a nie po liczbie indywidualnych funkcji.

Dwa sklepy korzystające z tej samej wersji Magento mogą wymagać zupełnie innego nakładu pracy.

Pierwszy może opierać się na standardowych mechanizmach, aktualnych modułach i udokumentowanych integracjach. Drugi może zawierać wiele modyfikacji wykonanych przez różne zespoły, zależności od niewspieranych bibliotek oraz synchronizacje, których nikt nie monitoruje.

Koszt kolejnej funkcji zależy wtedy od jakości fundamentu. Prosta zmiana może wymagać wcześniejszego uporządkowania kodu albo odtworzenia wiedzy o przepływie danych.

Magento może obsłużyć wymagany proces. O koszcie rozwoju często decyduje sposób, w jaki proces został wcześniej zaimplementowany.

B2C

Sprzedaż sklepu internetowego bezpośrednio do klienta indywidualnego: otwarty katalog, jedna cena widoczna dla wszystkich i standardowa ścieżka zakupowa.

B2B

Sprzedaż do firm z procesami takimi jak indywidualne ceny, katalogi, konta firmowe i integracje biznesowe. Wymaga ról użytkowników, limitów i akceptacji zamówień.wdrożenie B2B na Magento 2

D2C

Sprzedaż prowadzona bezpośrednio przez producenta lub markę do klienta końcowego, obok albo zamiast kanału dystrybucyjnego.wdrożenie D2C na Magento 2

Magento wprowadza większą swobodę projektowania systemu, ale wymaga budżetu na analizę, development, hosting, aktualizacje i utrzymanie.

Platforma SaaS może być bardziej racjonalna, gdy firma ma prosty katalog, standardowy checkout, niewiele integracji i chce szybko rozpocząć sprzedaż. Dotyczy to również organizacji, które nie mają obecnie osoby odpowiedzialnej za rozwój produktu e‑commerce.

Wysoki obrót, kilka tysięcy produktów, nieaktualny wygląd sklepu ani planowana kiedyś ekspansja nie uzasadniają samodzielnie wyboru Magento.

Najdroższy projekt często powstaje wtedy, gdy podstawowe decyzje biznesowe trafiają do zespołu programistycznego dopiero podczas realizacji.

Magento 2

Powszechnie używane określenie obecnej generacji technologii Magento. Nie jest nazwą produktu, który się kupuje — obie linie poniżej są Magento 2.

Magento Open Source

Otwartoźródłowa wersja platformy, której kod może być rozwijany i dostosowywany do indywidualnych potrzeb projektu. Bez opłaty licencyjnej.

Adobe Commerce

Komercyjna platforma Adobe rozwijana w tym samym ekosystemie technologicznym i wyposażona w dodatkowe możliwości przeznaczone dla bardziej rozbudowanych zastosowań. Nie jest synonimem Magento Open Source: Adobe publikuje dla obu linii osobne informacje o wydaniach.

Magento Open Source udostępnia otwarty kod i podstawowe mechanizmy e‑commerce. Adobe Commerce rozwija ten sam fundament o komercyjne funkcje oraz usługi Adobe. Aktualny zakres produktu warto sprawdzać przy każdym wyborze rozwiązania, bo oferta i wersje platformy są rozwijane (dokumentacja Adobe (otwiera się w nowej karcie)). Decyzja nie powinna kończyć się na porównaniu ceny licencji — trzeba sprawdzić, ile będzie kosztować wdrożenie oraz późniejsze utrzymywanie potrzebnych procesów w obu wariantach.

Wersja bez standardowej opłaty licencyjnej może okazać się droższa, jeżeli firma musi samodzielnie odtworzyć i przez lata utrzymywać rozbudowane procesy. Adobe Commerce może być nieuzasadnione, jeżeli większość jego możliwości nie będzie używana.

ERP

Ceny, stany magazynowe, zamówienia i dokumenty. Najczęściej to ERP jest źródłem prawdy, a sklep odbiorcą.

PIM

Dane produktowe i zasoby cyfrowe dla wszystkich kanałów sprzedaży. Gdy katalog jest rozproszony, źródłem bywa osobna platforma — na przykład Pimcore.

WMS

Kompletacja, wysyłki i stany w rozbiciu na magazyny.

CRM

Dane klientów, historia kontaktu i procesy sprzedażowe po stronie handlowców.

Marketplace

Publikacja oferty i odbiór zamówień z platform sprzedażowych.

Systemy płatności

Bramki, raty, płatności odroczone i rozliczenia — przez moduły operatorów.

Systemy logistyczne

Przewoźnicy, punkty odbioru, etykiety i śledzenie przesyłek.

Marketing automation

Zdarzenia z zachowania klienta, segmenty i komunikacja wychodząca.

Dla każdej integracji trzeba ustalić zakres danych, kierunek wymiany, częstotliwość, właściciela procesu i sposób obsługi błędów. Bez tych informacji integracji nie da się rzetelnie wycenić ani utrzymać.

Oprogramowanie

Magento Open Source nie ma opłaty licencyjnej. Adobe Commerce jest produktem komercyjnym z opłatą roczną ustalaną przez Adobe indywidualnie.

Wdrożenie

Analiza, projekt UX/UI, konfiguracja platformy i development tego, czego nie ma w standardzie. Największa pozycja w większości projektów.

Frontend

Projekt i implementacja warstwy, którą widzi klient. Może powstać na Hyvie, co skraca prace i poprawia wydajność względem domyślnego motywu.

Integracje

Połączenia z ERP, PIM, WMS, CRM, płatnościami i logistyką. Wyceniane osobno, bo każde zależy od API drugiej strony.

Migracja

Jeżeli projekt zastępuje istniejący sklep: przeniesienie katalogu, kont i historii zamówień oraz zabezpieczenie widoczności w wyszukiwarkach.

Hosting

Magento wymaga infrastruktury przygotowanej pod tę platformę — nie działa sensownie na współdzielonym hostingu.

Utrzymanie i rozwój

Aktualizacje, poprawki bezpieczeństwa, monitoring i dalszy development po uruchomieniu.

Zakres i warunki obu ścieżek opisaliśmy w usługach Magento 2 oraz w usługach Shopify.

Aurora Creation udostępnia działające demo Magento Open Source z przykładowymi danymi. Możesz przetestować zarówno storefront, jak i panel administracyjny i samodzielnie sprawdzić podstawowe funkcje platformy.

Panel Magento pozwala zarządzać produktami, cenami, klientami, zamówieniami i treścią. Nie oznacza to, że wszystkie te dane powinny powstawać w sklepie.

W przykładowej architekturze ERP może odpowiadać za ceny i dokumenty handlowe, PIM za informacje produktowe, WMS za realizację magazynową, a CRM za pracę zespołu sprzedaży. Magento korzysta z potrzebnych danych podczas zakupu i przekazuje zamówienie do dalszej realizacji.

Konkretny podział zależy od procesów firmy. Jeżeli cena może być edytowana w ERP i Magento, trzeba wskazać wartość nadrzędną. Jeżeli stany pochodzą z kilku magazynów, potrzebna jest reguła rezerwacji. Gdy dane produktowe są zmieniane w PIM i panelu sklepu, trzeba określić kierunek synchronizacji.

Integracja jest umową dotyczącą odpowiedzialności za dane.

1. 01

   Kto jest właścicielem danych?

   Dla produktów, cen, stanów, klientów, zamówień i statusów realizacji trzeba wskazać system źródłowy. Brak tej decyzji prowadzi do powstawania kilku wersji tej samej informacji.

2. 02

   Które procesy rzeczywiście odróżniają firmę?

   Część procesów jest źródłem przewagi. Inne powstały przez ograniczenia wcześniejszego oprogramowania. Nowa platforma nie musi odwzorowywać wszystkich dotychczasowych operacji — automatyzacja zbędnego procesu tylko przyspiesza pracę, która nadal nie wnosi wartości.

3. 03

   Co wymaga kodu indywidualnego?

   Jeżeli standardowy mechanizm albo sprawdzony moduł obsługuje większość wymagań, trzeba porównać koszt brakującego zakresu z wieloletnim kosztem własnego rozwiązania. Modułu też nie warto wybierać wyłącznie na podstawie ceny — liczy się jego jakość, aktualizacje, kompatybilność i wpływ na resztę systemu.

4. 04

   Jak będą testowane i publikowane zmiany?

   Projekt powinien mieć środowisko testowe, określony proces publikacji, zakres QA i sposób reakcji na błędy. Testy wykonywane przed pierwszym uruchomieniem nie zabezpieczają kolejnych aktualizacji i funkcji.

5. 05

   Kto odpowiada za sklep po uruchomieniu?

   Firma musi wiedzieć, kto zajmuje się monitoringiem, infrastrukturą, kopiami zapasowymi, aktualizacjami bezpieczeństwa, błędami i dalszym rozwojem. Odkładanie tych prac stopniowo zwiększa ryzyko kolejnych zmian.

Rozmiar e‑commerce można opisywać przychodem, ruchem, liczbą produktów, zamówień, rynków, integracji albo pracowników. Żaden z tych parametrów samodzielnie nie przesądza o wyborze platformy.

Większa elastyczność ma uzasadnienie, gdy procesy są trwałą cechą modelu biznesowego i będą rozwijane przez kolejne lata.

Magento jest przeznaczone dla firm, których procesy sprzedażowe przestały mieścić się w ograniczeniach prostszych systemów.

Frustracja związana z obecnym sklepem jest sygnałem do analizy, ale nie wystarcza do wyboru Magento.

Źródłem problemu może być technologia, sposób wdrożenia, jakość danych, architektura integracji albo organizacja pracy po stronie firmy. Migracja rozwiązuje ograniczenia platformy — nie zastępuje decyzji dotyczących cen, logistyki, danych produktowych i odpowiedzialności zespołów.

Może stworzyć warunki do uporządkowania tych obszarów, jeżeli zostaną uwzględnione w analizie i architekturze rozwiązania.