menu

// JAK UNIKNĄĆ BŁĘDÓW PODCZAS IMPLEMENTACJI SAP HYBRIS?

Zakup silnika commercowego nie przesądza o sukcesie – liczy się przede wszystkim jego efektywne wykorzystanie i wdrożenie. Jednak implementacja systemu commerce stanowi spore wyzwanie: od strony procesowej zmiany sięgają najczęściej wielu poziomów czy struktur organizacji. Wiąże się to także z koniecznością zmian nawyków i sposobu myślenia, co już samo w sobie wskazuje na kaliber wyzwania.

Przyjrzyjmy się zatem najczęstszym błędom popełnianym podczas implementacji opartej o system SAP Hybris (znany też jako SAP Commerce Cloud, SAP Commerce, Hybris – nazwy te są stosowane zamiennie).

 

Błąd nr 1: “Potrzebujemy specjalistów od Javy. Hybrisa nauczą się w trakcie projektu”

“Doświadczony programista nauczy się wszystkiego w locie, jeśli zna Javę” (jako wiodący język, o który oparty jest Hybris) – słysząc takie stwierdzenie powinna się nam zapalić czerwona lampka. Zwłaszcza, gdy z takim podejściem budowany jest cały zespół. Można to porównać do doświadczonego kierowcy – wyjeździł setki godzin w samochodzie osobowym, jednak posadzony w bolidzie F1 popełni wiele błędów, a w najgorszym razie rozbije się na zakręcie. Trzeba poznać możliwości pojazdu czy technologii, z którymi ma się do czynienia.

Poznanie platformy i sposobów jej umiejętnego wdrożenia to wiedza i doświadczenie, które trzeba zdobyć. Nie każdy Senior Java Developer ma od razu tytuł Hybris Expert.

Wybierając partnera do implementacji tego rozwiązania w Twojej firmie, pamiętaj:

  • ZAWSZE PYTAJ O DOŚWIADCZENIE PROPONOWANEGO ZESPOŁU – powinno być wyrażone w latach i/lub zrealizowanych projektach. Otrzymane certyfikaty są równie ważne co realna praktyka projektowa. Szczególną uwagę poświęć doświadczeniu osób kluczowych dla podejmowanych decyzji. To ci, którzy mają największy wpływ na technologiczne i procesowe aspekty projektu i/lub kontakt z klientem;
  • O PROPORCJACH – to większość zespołu powinna mieć doświadczenie w danej technologii. Nasza rekomendacja dot. składu to minimum 1/3 członków zespołu projektowego z doświadczeniem w pracy z platformą Hybris popartym zrealizowanymi projektami.

 

 Błąd nr 2: “To tylko prosta zmiana na frontendzie. Jesteśmy agile, damy radę”

Gdyby płacono nam za każdym razem, gdy słyszymy ten tekst, to bylibyśmy milionerami. Często klient sądzi, że dana zmiana jest niewielka i można ją wykonać już, od ręki. Najczęściej odnosi się to do delikatnej modyfikacji na frontendzie – jak zmiana koloru lub położenia Bardzo Ważnego Przycisku Na Stronie (np. “Kup”).

Warto mieć świadomość, jak takie zadanie wygląda jako zadanie z perspektywy klienta i zespołu projektowego. Przyjmijmy założenie, że faktycznie chodzi o proste wymaganie i sama modyfikacja w kodzie to 15 minut pracy jednego programisty (który wie, gdzie należy jej dokonać) oraz że sam zespół projektowy pracuje w metodologii Scrum, czyli w cyklach sprintowych. Poniżej znajdziesz przykładową listę działań niezbędnych do podjęcia w ramach tego zadania.

“PROSTA ZMIANA” – PERSPEKTYWA KLIENTA

  1. Potrzeba zmiany obecnej funkcjonalności
  2. Poinformowanie zespołu o potrzebie zmiany
  3. Testy UAT (User Acceptance Testing) – opcjonalnie (dobra praktyka)
  4. Komunikacja w organizacji, że funkcjonalność została wprowadzona

“PROSTA ZMIANA” – OBOWIĄZKI ZESPOŁU PROJEKTOWEGO

  1. Potrzeba zmiany obecnej funkcjonalności
  2. Poinformowanie zespołu o potrzebie zmiany
  3. Podjęcie decyzji, czy jest na to miejsce w Sprincie – TAK: Możemy robić // NIE: Należy zrezygnować z czegoś, co obecnie jest wykonywane/w planach, i co nie zagrozi osiągnięciu Sprint Goal
  4. Rozpoczęcie implementacji rozwiązania
  5. Testy funkcjonalności
  6. Wprowadzenie poprawek po testach
  7. Ponowne testy funkcjonalności
  8. Zakończenie implementacji
  9. Przygotowanie kandydata paczki produkcyjnej (Release Candidate)
  10. Wgranie paczki Release Candidate na środowisko przedprodukcyjne w celu testów
  11. Testy UAT (User Acceptance Testing) – opcjonalnie, jeśli klient z jakiejś przyczyny nie może ich wykonać
  12. Testy regresyjne i/lub automatyczne, i/lub wydajnościowe systemu
  13. Stabilizacja paczki i ponowne testy – opcjonalnie
  14. Przygotowanie release notes
  15. Wdrożenie na produkcję (Go live)
  16. Smoke testy po wdrożeniu
  17. Komunikacja w organizacji, że funkcjonalność została wprowadzona

Jak widać lista niezbędnych aktywności jest spora, a do ich podjęcia niezbędni są ludzie i czas. Są to zasoby sprintowe, które są określone, ograniczone i mają posłużyć udanemu wytworzeniu Inkrementu oraz osiągnięciu Sprint Goal.

 

Systemy commerce często wiążą się z długofalowymi projektami. Są one rozwijane równolegle z obsługą bieżących zgłoszeń produkcyjnych (błędy, propozycje nowych funkcjonalności). Jak wówczas działać efektywnie?

  • OPCJA 1. Przeniesienie rozwiązywania części zgłoszeń na odpowiedzialność innego zespołu, np. Application Support
  • OPCJA 2. Oddzielenie frontendu od backendu – Popularna teraz architektura oparta o Headless CMS umożliwia separację implementacji części frontendowej od backendowej systemu. Takie podejście umożliwia osobne releasy obu części aplikacji, a w przypadku releasu frontendu nie ma konieczności zatrzymywania serwerów i przechodzenia skomplikowanej procedury deploymentu całej aplikacji.

W kwestii tego, ile czasu zajmie wdrożenie danego rozwiązania i czy wymagana zmiana faktycznie wiąże się z koniecznością niewielkiego nakładu pracy, najlepiej zaufać partnerowi, z którym realizuje się projekt. Doświadczony zespół jest w stanie wycenić tego typu działanie, uwzględniając specyfikę zwinnego podejścia do prowadzenia projektów.

W ENGINIETY często obserwujemy, że błędne myślenie o “niewielkich zmianach” wynika z monolitycznej natury architektury Hybrisa. Z tego powodu opracowaliśmy rozwiązanie dekomponujące tego typu monolit, które oferujemy naszym klientom.


Błąd nr 3: “Aktualizacje są czasochłonne i drogie, więc ich nie robimy”

Natura projektów commerce jest długofalowa. Na pewno więc w którymś momencie wystąpi konieczność przeprowadzenia aktualizacji bibliotek czy narzędzi.

Dwie główne rady dotyczące aktualizacji:

  1. WYKONUJ AKTUALIZACJE
  2. WYKONUJ AKTUALIZACJE NA BIEŻĄCO

Dzięki temu mamy pewność, że nasza wersja systemu jest stabilna, pozbawiona aktualnie znanych błędów oraz mamy do dyspozycji nowe funkcjonalności.

 

„Po co mi aktualizacja, skoro działa”… Teoretycznie – tak. W takim myśleniu zabrakło jednak uwzględnienia tak istotnych kwestii, jak:

  • poprawki krytycznych błędów
  • korzystaniem z nowych funkcjonalności
  • poprawy stabilności i szybkości
  • nowe API przyśpieszające przyszłą implementację

Z perspektywy długoterminowej są to elementy, które przynoszą korzyści – nierzadko na taką skalę, że zyski pokrywają poniesione koszty aktualizacji platformy.

Koszt takich procedur jest niższy niż może się to wydawać na pierwszy rzut oka. W kalkulacji należy uwzględnić szeroko rozumiane zasoby: pieniądze, czas i, przede wszystkim, ludzi. Kluczowe są wiedza i kompetencje zespołu developerskiego – jeśli jest on dobrze skonstruowany, to aktualizacja będzie jednym z typowych zadań, które należy zaplanować i wykonać, tak samo jak implementację nowej funkcjonalności.

 

Błąd nr 4: Hybris jako pudełkowe rozwiązanie vs wymyślanie koła na nowo

Ten punkt mówi o błędnym podejściu klientów do tej technologii i 2 różnych założeniach, których przyjęcie nie wróży sukcesu projektu:

  • „Hybris to gotowe rozwiązanie, które wystarczy skonfigurować i będzie działać wg moich wymagań”
  • „Chcemy nową funkcjonalność, ale nie znamy możliwości platformy, więc piszemy wszystko od zera”

Oba podejścia są niewłaściwe. Z jednej strony Hybris to potężny monolit z całą masą funkcjonalności – rzadko jednak pasują one w 100% do wymagań danego klienta. Każdy ma inne potrzeby, procesy i wytyczne. Aby wdrożyć funkcję dostępną w ramach platformy, wersja “z pudełka” wymaga modyfikacji ze względu na specyficzne potrzeby.

Z drugiej strony jest brak świadomości tego, jakie możliwości daje system. Świadczą o tym sytuacje, w których słyszymy, że daną funkcję należy implementować od zera lub – co gorsza – taniej będzie napisać ją samemu, zaczynając od wersji MVP. Praktyka pokazuje jednak, że jest to kosztowniejsze w długoterminowej perspektywie, a często wersja MVP jest docelową (ze względu na brak czasu na jej dalsze rozwijanie).

Przykłady kwestii, które dotyczą któregoś z powyższych scenariuszy:

  • system promocji produktów – bardzo rozbudowany, nie trzeba pisać go na nowo, może wymagać rozbudowania. Działa wystarczająco dobrze, nie warto pisać go od zera;
  • komponenty CMS-owe do promocji produktów – Hybris posiada bardzo liczne komponenty różnego typu (m.in. karuzele produktów, banery, kafelki do promocji). Można użyć ich praktycznie z marszu lub dostosować do własnych wymagań, tworząc z niewielką pomocą zespołu developerskiego customowe rozwiązanie, którego nie ma nikt inny;
  • zarządzanie produktami – Hybris ma wbudowane narzędzie Product Content Management (PCM), które umożliwia m.in. natywną integrację z SAP ERP lub innym narzędziem z portfolio SAP (SAP Platform Integration do dwustronnej integracji z dowolnym systemem typu 3rd party).

 

Czy to już wszystkie błędy, jakie można popełnić?

Niestety nie. Kompletna lista możliwych różnego typu błędów jest kilka razy dłuższa. Z rozmów na ten temat w naszym zespole wynika, że funkcjonuje pula powtarzających się problemów. Wynikają one głównie z braku doświadczenia zespołu projektowego w zakresie najlepszych praktyk implementacji oraz luk w znajomości możliwości lub ograniczeń wdrażanego frameworku Hybris.

Dlatego podkreślamy: krytycznie ważne jest, aby zespół projektowy był odpowiednio skomponowany – nie tylko pod względem seniority, ale też doświadczenia projektowego. Jednocześnie pamiętajmy, że ktoś w zespole powinien częściowo pełnić funkcję konsultanta. Może to być jedna osoba lub grupa w roli doradcy od tego, co będzie najlepsze dla dobra projektu, jak najefektywniej korzystać z możliwości platformy, z którą pracujemy, i jakie rozwiązania są dobre, a jakich unikać. O to przecież w tym wszystkim chodzi: o sukces projektu, a nie osobiste zwycięstwo jednostki, która stawiała na swoim.

// Partnerzy