Piotr MuchaPrincipal Software Engineer FairyDeck EN / PL Porozmawiajmy o systemie
Menu

Główny case · Zanonimizowany ERP automotive

Modernizacja produkcyjna

Modernizacja krytycznego ERP bez zatrzymywania sprzedaży, zakupów i pracy magazynów.

Produkcyjne OMS i SCM przejęły kluczowe przepływy, wdrożenia legacy są odwracalne, a stare i nowe systemy korzystają z jednej warstwy obserwowalności.

20 tys.
zamówień przetwarzanych miesięcznie
3 mln
SKU w środowisku ERP
40 sekund
maksymalny czas odwracalnego wdrożenia legacy
Bez przestoju
migracja produkcyjnych baz bez przestoju

01

Modernizacja modelu działania, nie tylko kodu.

Środowisko legacy korzystało z osobnych baz, bezpośrednich zapisów między systemami i plików zamiast jawnych kontraktów. Wdrożenia zależały od jednej osoby, błędy najpierw widzieli użytkownicy, a duże zamówienia do dostawców wymagały wielu godzin ręcznej pracy.

Modernizacja zaczęła się więc od stabilności, obserwowalności i odwracalnych wdrożeń. Następnie kompletne procesy przechodziły do domen z jawną odpowiedzialnością, zamiast bezterminowo pozostawać między starym i nowym systemem.

02

Krytyczny system, którego nie można było zatrzymać ani bezpiecznie przepisać.

Stan początkowy

Nieudokumentowane odpowiedzialności i sprzeczne dane

Kilka aplikacji legacy utrzymywało własne dane produktowe i komunikowało się przez dostęp do baz oraz pliki. Decyzje operacyjne były trudne do odtworzenia, a awarie produkcyjne często najpierw zgłaszali użytkownicy.

Ograniczenia

Każdy krok musiał zachować ciągłość biznesu

  • Sprzedaż, zakupy, praca magazynów i dokumenty finansowe musiały pozostać dostępne.
  • Wiedza domenowa była niepełna i rozproszona między ludźmi oraz kodem.
  • Silne sprzężenie czyniło migrację całych procesów bezpieczniejszą niż wydzielanie pojedynczych endpointów.
  • Każde wdrożenie i przejście danych wymagało obserwowalnej drogi wycofania.

Dlaczego nie rewrite

Nieznane reguły biznesowe czynią wymianę big-bang zbyt ryzykowną

Pełne przepisanie łączyłoby najwyższą niepewność techniczną z największym możliwym wdrożeniem. Migracja procesami pozwalała uczyć się z produkcji i zachować jednego właściciela każdej odpowiedzialności.

Osobista odpowiedzialność

Architektura pozostała połączona z implementacją i operacjami.

Łączyłem architekturę systemu, kluczową pracę hands-on i odpowiedzialność produkcyjną przez cały okres przejściowy.

Architektura modernizacji i domen
Wyznaczyłem strategię migracji, granice domen, odpowiedzialność za dane i model komunikacji nowego ERP.
OMS, SCM i usługi wspierające
Zaprojektowałem i wdrożyłem cały OMS. Zaprojektowałem SCM, zbudowałem frontend i dostarczałem późniejsze zmiany; część pierwszego backendu wykonał drugi developer.
Bezpieczna zmiana produkcyjna
Odpowiadałem za decyzje AWS i IaC, automatyzację wdrożeń legacy, platformę obserwowalności oraz migrację produkcyjnych baz.

PIM, WMS, Pricing Engine, Marketplace Integration Service i centralny BI są nadal wdrażane lub projektowane. Opisuję je jako bieżące prace, a nie ukończone rezultaty.

Kluczowe decyzje

Najpierw ograniczyć ryzyko operacyjne, potem zwiększać tempo zmian.

Architektura wynikała z procesu biznesowego i wybierała najmniejszy odwracalny krok przenoszący całą odpowiedzialność.

  1. 01

    Przenoszenie kompletnych procesów

    OMS i SCM przejęły spójne przepływy, zamiast pozostawiać ukrytą odpowiedzialność między implementacjami.

  2. 02

    Stabilizacja przed wydzieleniem

    Automatyczne wdrożenia, rollback, monitoring i backupy zmniejszyły ryzyko okresu przejściowego.

  3. 03

    Komunikacja dobrana do operacji

    REST obsługuje bezpośrednie odpowiedzi, a Kafka i eventy propagują zmiany między domenami.

  4. 04

    Migracja danych pod replikacją

    Dump i restore tworzyły stan bazowy, a replikacja była obserwowana przed kontrolowanym przełączeniem na RDS.

Model dostarczania

Sekwencja operacyjnie kompletnych zmian.

  1. 01

    Stabilizacja i obserwacja

    Zabezpieczenie wdrożeń, dostępu, odtwarzania i sygnałów produkcyjnych wokół systemów, od których firma już zależy.

  2. 02

    Jawna odpowiedzialność

    Mapowanie krytycznych procesów, źródeł prawdy i ukrytych reguł przed wyborem nowej granicy domeny.

  3. 03

    Wydzielenie całego przepływu

    Budowa komponentu, integracja przez jawne kontrakty i przełączenie kompletnej odpowiedzialności biznesowej.

  4. 04

    Weryfikacja i wycofanie

    Pomiar wyniku na produkcji i usunięcie odpowiedzialności z legacy dopiero po przeniesieniu wszystkich zależności.

Zweryfikowane rezultaty produkcyjne

Mniej pracy ręcznej, krótsze okna ryzyka i wcześniejsze sygnały.

Kilka godzin → kilka minut
dla zamówienia obejmującego około 2000 części
Około godziny → maks. 40 sekund
maksymalny czas odwracalnego wdrożenia zamiast około godziny
Zgłoszenie użytkownika → alert w kilka sekund
dla ośmiu systemów legacy, sześciu nowych części ERP i ich infrastruktury
Bazy 12 GB i 59 GB · bez przestoju
dla produkcyjnych baz 12 GB i 59 GB przeniesionych do AWS RDS

Skrócenie obsługi zamówienia jest efektem wspólnego przepływu OMS i SCM. Główna optymalizacja wyboru dostawcy należy do SCM.

Stan obecny

Odpowiedzialności produkcyjne i prace w toku pozostają rozdzielone.

Modernizacja dostarcza wartość przed pełnym wyłączeniem starego ERP. Pozostałe domeny prezentuję przez ich problem i architekturę, a nie przyszłe rezultaty.

Czego to dowodzi

Odpowiedzialność na poziomie Principal w działającym środowisku krytycznym.

Potrafię wejść do słabo udokumentowanego systemu, ustabilizować to, czego biznes nie może zatrzymać, i przełożyć ograniczenia operacyjne na granice domen, kluczową implementację oraz mierzalną zmianę produkcyjną.

Automatyzacja aktualizacji katalogu blisko 10 mln produktów automotive.

Dane dostawców były niepełne i niespójne, a każda aktualizacja katalogu wymagała wielu dni pracy developera. Zaprojektowałem automatyczną architekturę przetwarzającą tygodniowe delty TecAlliance po ich udostępnieniu i utrzymującą aktualny, ustandaryzowany katalog blisko 10 mln produktów.

Modernizacja platformy marketing automation przetwarzającej do około 45 tys. zdarzeń na minutę.

Przy około 1000 zintegrowanych sklepów przetwarzanie eventów na dysku i skalowanie przez dokładanie serwerów osiągały granice niezawodności i kosztów. Platforma przeszła na kolejki oraz skalowalne workery, a krytyczne komponenty PHP i Java były modernizowane etapami.

Twoja modernizacja

Czy Twój ERP jest zbyt ważny, żeby go zatrzymać, i zbyt ryzykowny, żeby zostawić go bez zmian?

Możemy zacząć od procesu krytycznego, niedopuszczalnej awarii i odpowiedzialności, którą trzeba przenieść jako pierwszą.

Porozmawiajmy o modernizacji systemu krytycznego

Wróć do realizacji