Analiza przedwdrożeniowa Magento polega na opisaniu, jak sklep ma obsługiwać produkty, ceny, dostępność i zamówienia oraz po czym poznamy, że działa poprawnie. Najłatwiej przygotować wymagania na jednym produkcie i jednym zamówieniu: wskazać źródła danych, oczekiwany wynik synchronizacji z ERP i sprawdzalny warunek odbioru. Tak powstaje podstawa do ustalenia zakresu prac.
Przed wdrożeniem Magento 2 warto przygotować taki przykład wspólnie z osobami odpowiedzialnymi za sprzedaż, magazyn i obsługę zamówień. Nie musisz znać budowy systemu. Potrzebujesz odpowiedzi na pytania: kto zmienia dane, gdzie je zmienia i co po tej zmianie powinien zobaczyć klient oraz pracownik firmy.
Co powinna rozstrzygnąć analiza przedwdrożeniowa Magento?
Dokument wymagań powinien łączyć potrzebę biznesową z możliwym do sprawdzenia rezultatem. Zdanie „sklep ma być zintegrowany z ERP” nie mówi, czy chodzi o pobieranie cen, przekazywanie zamówień, aktualizację dostępności czy wszystkie te działania. Nie określa też, co stanie się po błędzie albo ręcznej zmianie danych.
Dobre wymaganie wskazuje konkretny przypadek, granice odpowiedzialności systemów i sposób weryfikacji. Powinno również ujawniać niewiadome, zamiast przedstawiać je jako uzgodnione funkcje. Jeśli wykonawca nie potwierdził obsługi danego procesu przez konektor, zapisz go jako wymaganie do weryfikacji.
Nie zaczynaj od spisywania wszystkich ekranów panelu. Najpierw przejdź drogę od utworzenia produktu przez publikację oferty do obsługi zamówienia. Dopiero wtedy łatwiej ocenisz, które ustawienia, integracje i dodatkowe funkcje są rzeczywiście potrzebne.
Jak opisać jeden produkt: SKU, Attribute Set i Store View?
Wybierz produkt reprezentatywny dla sprzedaży, ale na początek możliwie prosty. W naszym przykładzie będzie to pojedynczy kubek sprzedawany na sztuki, bez wyboru wariantów. To model do przygotowania wymagań, a nie opis istniejącego sklepu czy możliwości konkretnego konektora.
- Zapisz SKU produktu. Przyjmijmy
KUBEK-BIALY-01. SKU to identyfikator produktu; ustal, jaki identyfikator odpowiada mu w ERP i czy oba systemy używają tej samej wartości. Jeżeli wartości są różne, wykonawca powinien opisać sposób ich powiązania. - Wskaż Attribute Set. Zestaw atrybutów określa, jakie pola służą do opisu produktu. Dla przykładu nazwij go
Kubkii wymień potrzebne dane: pojemność, materiał oraz możliwość mycia w zmywarce. Zaznacz, które pola są obowiązkowe w procesie publikacji. - Określ Store View. Widok sklepu może służyć między innymi do prezentowania treści w określonym języku. Zapisz nazwę lub kod docelowego widoku oraz oczekiwaną nazwę i opis produktu. Nie zakładaj, że każde pole da się ustawiać niezależnie dla każdego widoku.
- Przypisz odpowiedzialność za pola. Opis może przygotowywać osoba obsługująca sklep, a dane magazynowe mogą pochodzić z ERP. Dla każdego pola wskaż miejsce edycji i oczekiwane zachowanie podczas kolejnej synchronizacji.
Dopisz również warunek publikacji: czy produkt bez materiału ma zostać zatrzymany do uzupełnienia, czy może pojawić się w sklepie z niepełnym opisem. To decyzja biznesowa, której techniczne wykonanie trzeba uzgodnić. Sama obecność pola w zestawie atrybutów nie opisuje całego procesu kontroli danych.
Jeden produkt nie pokryje wszystkich wyjątków. Jeżeli sprzedajesz także warianty rozmiarowe, zestawy lub towary wymagające odmiennej obsługi magazynowej, przygotuj dla nich kolejne karty. Zachowaj ten sam schemat, aby różnice były widoczne przed wyceną i rozpoczęciem prac.
Który system odpowiada za cenę i stan magazynowy?
Dla każdej informacji ustal system nadrzędny, czyli miejsce, którego dane mają rozstrzygać wynik synchronizacji. Nie wystarczy napisać, że cena znajduje się zarówno w Magento, jak i w ERP. Trzeba wskazać, gdzie wolno ją zmieniać i która wartość ma obowiązywać po wymianie danych.
W przykładzie przyjmujemy jako wymaganie, że ERP odpowiada za cenę podstawową i dane o zapasie, a Magento za opis produktu. To proponowana reguła dla ćwiczenia, nie uniwersalny model integracji. Firma stosująca promocje w sklepie potrzebuje dodatkowego ustalenia, jak promocja współistnieje z ceną przesyłaną z ERP.
| Obszar | Założenie w przykładzie | Co wymaga potwierdzenia |
|---|---|---|
| Cena podstawowa | Wartość pochodzi z ERP | Właściwy cennik, waluta i zakres obowiązywania ceny |
| Dostępność | Wynika z uzgodnionych danych magazynowych ERP | Magazyny, rezerwacje i sposób wyliczania ilości do sprzedaży |
| Nazwa i opis | Redagowane w Magento | Czy synchronizacja pozostawia te pola bez zmian |
| Identyfikacja | SKU wiąże produkt z kartoteką ERP | Mapowanie identyfikatorów i reakcja na brak dopasowania |
Szczególnie dokładnie opisz dostępność. Fizyczny zapas, towar zarezerwowany i ilość możliwa do kupienia nie muszą oznaczać tego samego. W wymaganiu podaj, którą informację pobieramy i jak ma wpływać na możliwość złożenia zamówienia.
Przy planowaniu integracji Magento z ERP zapisz też regułę konfliktu. Jeśli pracownik ręcznie zmieni cenę w sklepie, kolejna synchronizacja może ją nadpisać, pozostawić albo zgłosić rozbieżność — oczekiwane zachowanie trzeba wybrać i sprawdzić. Bez tej decyzji obie strony mogą inaczej rozumieć poprawne działanie.
Jak przejść od produktu do jednego zamówienia?
Przygotuj scenariusz z danymi początkowymi, które można odtworzyć w środowisku testowym. Załóżmy, że dla wybranego SKU uzgodniona ilość dostępna do sprzedaży wynosi 12 sztuk, a klient zamawia 2 sztuki. Cenę oznacz jako wartość A, bez wpisywania przypadkowej kwoty do dokumentu.
- Sprawdź stan początkowy. Produkt ma właściwy SKU, zestaw atrybutów, treść w docelowym Store View oraz cenę A. Zapisz oczekiwaną dostępność i upewnij się, że test nie korzysta z pozostałości wcześniejszych zamówień.
- Zmień cenę w systemie nadrzędnym. Ustaw wartość B i wykonaj synchronizację zgodnie z projektowanym sposobem działania. Sprawdź cenę widoczną dla klienta, a nie wyłącznie wartość w panelu administracyjnym.
- Złóż zamówienie na 2 sztuki. Zapisz SKU, ilość, cenę jednostkową, rabaty, dostawę i identyfikator zamówienia. Do próby wykorzystaj uzgodnione dane testowe.
- Zweryfikuj rezultat w ERP. Wskaż, jaki obiekt ma powstać i jakie informacje powinien zawierać. Rodzaj dokumentu, moment przekazania zamówienia i wymagane pola pozostają do potwierdzenia przez wykonawcę.
- Sprawdź dostępność po obsłudze zamówienia. Jeśli uzgodniona reguła zakłada pomniejszenie ilości do sprzedaży o zakupione sztuki i nie występują inne operacje, oczekiwany wynik wynosi 10. Ustal moment, w którym ten rezultat ma być widoczny, oraz sposób uniknięcia podwójnego pomniejszenia.
Nie łącz automatycznie przyjęcia zamówienia w ERP ze zmianą jego statusu w sklepie. To osobne zdarzenia, które mogą wymagać osobnych reguł. Zapisz, jaki status ma zobaczyć obsługa i klient oraz czy jego zmiana powinna uruchamiać powiadomienie.
Wzór karty wymagania z warunkiem odbioru
Poniższy wzór można skopiować do dokumentacji projektu. Każda karta powinna obejmować jedną sprawdzalną potrzebę, dzięki czemu łatwiej ją zatwierdzić, wycenić i odebrać. Wartości w nawiasach należy uzupełnić wspólnie z wykonawcą przed realizacją.
Identyfikator i cel: WYM-01 — przekazanie zamówienia z Magento do ERP bez ponownego ręcznego przepisywania pozycji.
Dane początkowe: produkt KUBEK-BIALY-01, Attribute Set Kubki, Store View [kod widoku], cena B, dostępność 12 sztuk. Powiązanie z kartoteką ERP zostało sprawdzone, a wymagane dane zamówienia są uzupełnione.
Zdarzenie uruchamiające: zamówienie na 2 sztuki osiąga [uzgodniony status lub inne zdarzenie]. Wymaganie obejmuje [rodzaj zamówień]; inne przypadki pozostają poza zakresem tej karty.
Oczekiwany wynik: w ERP powstaje [uzgodniony obiekt] z właściwym produktem, ilością i ceną. Magento zachowuje powiązanie z wynikiem przekazania w [uzgodnionym miejscu], a dostępność zmienia się zgodnie z ustaloną regułą.
Warunek odbioru: po wykonaniu scenariusza rezultat pojawia się w [uzgodnionym czasie]. Osoba odbierająca porównuje identyfikatory, ilości, ceny i dostępność w obu systemach; ponowienie tego samego przekazania nie tworzy drugiego zamówienia w ERP.
Dowód i odpowiedzialność: protokół zawiera identyfikatory testowych rekordów, czas wykonania oraz wynik porównania. Test zatwierdzają [osoba po stronie firmy] i [osoba po stronie wykonawcy].
Kwestie do potwierdzenia przez wykonawcę: obsługiwany moment eksportu, typ obiektu w ERP, mapowanie pól, kontrola duplikatów, sposób ponawiania i miejsce prezentowania błędów. Każdy punkt otrzymuje odpowiedź: dostępne w uzgodnionym zakresie, wymaga dodatkowych prac albo nie jest obsługiwane.
Jakie próby błędów dopisać do odbioru?
Poprawne przejście zamówienia to dopiero część weryfikacji. Powtórz test przy chwilowej niedostępności ERP, braku dopasowania SKU oraz ponownym przesłaniu tego samego zamówienia. Dla każdej próby zapisz, kto zauważy problem i jak bezpiecznie wznowi obsługę.
Oczekiwaniem może być widoczny komunikat dla administratora, zachowanie zamówienia do ponowienia i brak duplikatu po odzyskaniu połączenia. Są to wymagania do uzgodnienia, a nie domniemane funkcje wybranego rozwiązania. Wykonawca powinien wskazać, które mechanizmy zapewnia konektor, a które wymagają dodatkowej konfiguracji lub prac.
Jeżeli rozwijasz działający sklep, poprzedź ustalenia sprawdzeniem jego obecnej konfiguracji. Audyt istniejącego Magento 2 może pomóc ustalić, jakie moduły i integracje już wpływają na ceny, stany oraz zamówienia. Dzięki temu nowa specyfikacja uwzględni rzeczywisty punkt startowy.
Jak zamknąć analizę przed rozpoczęciem wdrożenia?
Przejrzyj każdą kartę z osobą, która później odbierze daną funkcję. Sprawdź, czy potrafi ona wykonać test i samodzielnie rozpoznać poprawny wynik. Jeżeli potrzebuje dopowiedzeń autora dokumentu, kryterium wymaga uzupełnienia.
Oddziel wymagania konieczne do uruchomienia sprzedaży od funkcji planowanych na później. Przy nierozstrzygniętych kwestiach wskaż osobę odpowiedzialną i moment podjęcia decyzji. Nie pozostawiaj pustych pól dotyczących zakresu integracji jako milczącej zgody na dowolną interpretację.
Zmiany po zatwierdzeniu kart zapisuj wraz z ich wpływem na zakres, harmonogram i odbiór. Dokument ma odzwierciedlać aktualne ustalenia, aby właściciel sklepu i wykonawca sprawdzali ten sam rezultat. To szczególnie ważne, gdy podczas prób ujawnią się ograniczenia danych lub konektora.
Jak SISL może pomóc w przygotowaniu integracji?
SISL zajmuje się wdrożeniami, audytami i integracjami Magento 2, w tym połączeniem z Comarch ERP Optima przez własny konektor. Jeśli planujesz takie połączenie, sprawdź integrację Magento z Comarch ERP Optima i przygotuj opis produktu oraz zamówienia według powyższego wzoru. Zakres obsługi konkretnego procesu należy potwierdzić przed przyjęciem go do realizacji.
Najczęstsze pytania
Co przygotować do analizy przedwdrożeniowej Magento?
Przygotuj przykładowy produkt, zamówienie oraz opis obecnego obiegu danych między sklepem, magazynem i ERP. Dodaj listę osób podejmujących decyzje o cenach, dostępności i obsłudze zamówień. Przydatne są także przykłady błędów, które nowe wdrożenie ma wyeliminować.
Czy analizę przedwdrożeniową Magento można zacząć bez wybranego ERP?
Tak, można opisać proces sprzedaży, dane produktu i oczekiwane rezultaty obsługi zamówienia. Szczegóły wymiany danych pozostaną jednak otwarte do czasu wyboru ERP i sposobu połączenia. W dokumentacji trzeba wyraźnie oddzielić zatwierdzone wymagania biznesowe od założeń wymagających sprawdzenia.
Jak zapisać kryterium odbioru integracji Magento z ERP?
Kryterium powinno wskazywać dane początkowe, czynność testową i wynik widoczny w każdym systemie. Trzeba również ustalić termin osiągnięcia tego wyniku oraz dowód wykonania testu. Sam komunikat o udanej synchronizacji nie potwierdza poprawności ceny, dostępności ani zamówienia.
Czy gotowy konektor zastępuje analizę przedwdrożeniową?
Gotowy konektor może realizować część potrzebnej wymiany danych, ale jego zakres trzeba porównać z wymaganiami sklepu. Nazwa integracji nie potwierdza obsługi konkretnego rodzaju produktu, procesu magazynowego ani sposobu ponawiania operacji. Te elementy wymagają potwierdzenia w dokumentacji lub próbie działania.