Grena LTD – stabilizacja i modernizacja platformy B2B oraz integracja z ERP

Wprowadzenie:

Klient: Grena Ltd. (Wielka Brytania)
Branża: produkcja wyrobów medycznych, dystrybucja B2B
Zakres: inżynieria aplikacji, modernizacja infrastruktury, stabilizacja platformy, integracja z ERP, bieżący rozwój funkcji
Strona: grena.co.uk

Kontekst:

Grena Customer Portal to platforma B2B, z której korzystają międzynarodowi dystrybutorzy jednorazowych narzędzi chirurgicznych, obsługujący klientów w Wielkiej Brytanii, Holandii, Japonii, Serbii, Portugalii i Europie Środkowo-Wschodniej. Działa na mocno zmodyfikowanym stosie WordPress/WooCommerce, głęboko zintegrowanym w czasie rzeczywistym z systemem ERP klienta – Microsoft Dynamics 365 Business Central. Zamówienia, oferty, dane klientów, cenniki i stany magazynowe przepływają między oboma systemami w sposób ciągły.

Gdy przejmowaliśmy platformę, była kluczowa dla działania firmy, ale w praktyce nikt już nie brał za nią odpowiedzialności technicznej. Pierwotny programista nie był już dostępny, a system przerósł konfigurację, z myślą o której go napisano.

Wyzwanie:

Klient zgłosił się do nas, ponieważ wprowadzanie zmian na platformie stało się powolne i ryzykowne. Krótki audyt potwierdził, że widoczne objawy – kruche wdrożenia, problemy z dostarczalnością e-maili, niewyjaśnione awarie synchronizacji z ERP – były wierzchołkiem znacznie głębszego problemu. Kod był rozproszony w ponad dziesięciu autorskich wtyczkach WordPress, bez dokumentacji, testów i jasnej strategii branchowania. Nie istniało rozdzielenie konfiguracji aplikacji od danych operacyjnych.

Wydania odbywały się ręcznie. Nie było CI/CD, monitoringu błędów na produkcji ani zgodności środowisk deweloperskiego i produkcyjnego. Infrastruktura działała na przestarzałym oprogramowaniu systemowym; wcześniejsza próba aktualizacji w miejscu zepsuła platformę i trzeba ją było wycofać. Integracja z Business Central w przypadkach brzegowych zawodziła po cichu, co czasem kończyło się utratą zamówień bez żadnego powiadomienia.

Cele:

Rozwiązanie:

Wzięliśmy pełną odpowiedzialność techniczną za platformę – kod, infrastrukturę, wydania, incydenty i roadmapę technologiczną – i pracowaliśmy jako zespół zintegrowany z procesami biznesowymi i operacyjnymi klienta.

Zaczęliśmy od ograniczenia najpilniejszych ryzyk operacyjnych. Wspólnie z działem IT klienta uruchomiliśmy osobne środowisko deweloperskie będące wierną kopią produkcji (1:1), aby prace infrastrukturalne można było przetestować z wyprzedzeniem, a następnie przeprowadziliśmy migrację systemu operacyjnego i środowiska PHP do aktualnych, wspieranych wersji – w kontrolowanym, etapowym procesie. Zdiagnozowaliśmy i naprawiliśmy brakujące moduły PHP oraz błędnie skonfigurowany sterownik bazy danych, które od miesięcy po cichu psuły generowanie plików PDF i część integracji z ERP. Zadania cykliczne przenieśliśmy na właściwe konto serwisowe, eliminując całą kategorię cichych awarii.

Od tego momentu prace toczyły się kilkoma równoległymi torami, ułożonymi tak, by każdy kolejny etap był bezpieczniejszy i tańszy.

Najważniejsze działania

• Najpierw siatka bezpieczeństwa – CI/CD w GitHub Actions we wszystkich repozytoriach, z bezpiecznymi wdrożeniami na oba środowiska; mechanizm trybu serwisowego, który pozwala wdrażać zmiany na produkcję w godzinach pracy, z dostępem dla zespołu przez białą listę adresów IP; pełne przywrócenie zgodności środowisk deweloperskiego i produkcyjnego.
• Uniezależnienie od jednego programisty – systematyczna refaktoryzacja, która uwolniła kod od założeń powiązanych z poprzednim środowiskiem programistycznym; przeniesienie konfiguracji do panelu administracyjnego; zastąpienie zaszytych w kodzie kont neutralnymi kontami serwisowymi należącymi do klienta.
• Monitoring produkcji – dedykowany logger poczty rejestrujący każdy e-mail transakcyjny wraz z nadawcą, odbiorcą, treścią i statusem dostarczenia, tam gdzie wcześniej nie było żadnego zapisu; log synchronizacji zamówień z możliwością ręcznego ponowienia; monitor kondycji systemu, który cyklicznie sprawdza wszystkie punkty integracji.
• Wzmocnienie integracji z ERP – walidacja na poziomie pól i kontrolowane przycinanie danych do limitów Business Central, co zapobiega cichej utracie zamówień w przypadkach brzegowych; cache’owanie błędów połączenia, aby chwilowe niedostępności bazy danych nie wywoływały kaskady ponownych połączeń; kontrola współbieżności zadań cyklicznych; limity synchronizacji zamówień na cykl, które zapobiegają narastaniu kolejki.
• Przygotowanie do rozbudowy w modelu multi-tenant – wyniesienie z kodu zaszytych na sztywno identyfikatorów tabel ERP, nazw firm i endpointów usług sieciowych; automatyczne wykrywanie i cache’owanie różnic w identyfikatorach GUID między tenantami Business Central; przystosowanie architektury do obsługi kolejnych marek na tym samym silniku, z niezależnymi bazami danych, cennikami i logiką biznesową.
• Migracja ERP w trakcie działania – gdy Microsoft w jednym z dużych wydań Business Central usunął endpointy SOAP na rzecz REST/OData V4, dostosowaliśmy platformę do nowej wersji bez zatrzymywania produkcji; kluczowe integracje przenieśliśmy z wycofanych codeunitów na alternatywne endpointy stron, a pełne przejście na REST zaplanowaliśmy i wyceniliśmy.
• Ciągłe dostarczanie nowych funkcji – nowe raporty, logika gwarancyjna, usprawnienia systemu opinii, regionalne reguły wysyłki i wiele więcej – wdrażane równolegle z modernizacją, dzięki czemu firma nigdy nie musiała wybierać między stabilnością a rozwojem.

Jak pracowaliśmy:

Na co dzień działaliśmy jako zespół inżynierski platformy, a nie zewnętrzny dostawca. Programista był włączony w proces produktowy klienta dzięki codziennej komunikacji na Slacku i cotygodniowym spotkaniom statusowym z project managerem. Odbywały się też spotkania z najwyższym kierownictwem – rzadziej, przy przeglądach kamieni milowych lub decyzjach strategicznych. W pełni odpowiadaliśmy za incydenty produkcyjne – od alertu, przez diagnozę, po działania zapobiegawcze. Decyzje o kierunku technicznym platformy należały do nas i zapadały w dialogu z biznesem.

W przypadku incydentów bezpieczeństwa wspieraliśmy dział IT klienta w koordynowaniu reakcji, diagnostyce i wdrażaniu środków naprawczych, w tym rotacji danych uwierzytelniających, wzmocnieniu szyfrowania, limitach połączeń i zamknięciu pozostałych ścieżek dostępu.

Efekt:

W trakcie współpracy sytuacja techniczna i operacyjna platformy zdecydowanie poprawiła się we wszystkich obszarach.

• System operacyjny, PHP i ERP – wszystko zaktualizowane do bieżących, wspieranych wersji i zmigrowane w trakcie działania przy minimalnych przestojach
• 0 → 100% zautomatyzowanych wydań we wszystkich repozytoriach
• Od zera do pełnego monitoringu produkcji (log poczty, log synchronizacji zamówień, monitor kondycji) tam, gdzie wcześniej nie było żadnego
• Gotowość na multi-tenant – architektura przygotowana na kolejne marki na tym samym silniku
• Z minut do sekund – w przypadku kilku cyklicznych operacji synchronizacji z ERP, po optymalizacji zapytań i współbieżności

Nowe funkcje są wdrażane w przewidywalnym tempie. Przypadki brzegowe w integracji z ERP – takie, które wcześniej kosztowały firmę pojedyncze zamówienia – są teraz wychwytywane na etapie walidacji albo wyraźnie logowane, gdy wystąpią.

Aplikacja pozostaje tym samym produktem, na którym opiera się biznes – teraz jednak działa na aktualnym stacku technologicznym, jest monitorowana, wdrażana automatycznie, gotowa na multi-tenant i znacznie mniej podatna na awarie niż wcześniej.

Opinia klienta