ERP automotive
Modernizacja krytycznego ERP: sprzedaż, zakupy i magazyny.
20 tys.Principal Software Engineer · Modernizacja legacy · Architektura ERP
Modernizuję krytyczne systemy ERP i legacy bez zatrzymywania biznesu.
Biorę odpowiedzialność na poziomie Principal — od decyzji architektonicznych po implementację najtrudniejszych elementów i bezpieczne wdrożenia produkcyjne.
Zweryfikowane wyniki z produkcji
- 20 tys.
- zamówień / miesiąc
- 3 mln
- SKU w ERP
- 40 sekund
- maks. czas wdrożenia legacy
- Bez przestoju
- migracja baz produkcyjnych
- 45 tys./min
- zdarzeń marketingowych / min
Wyniki pochodzą z różnych projektów. Pełny kontekst i zakres osobistej odpowiedzialności opisuję w case studies.
Certyfikat AWS
Wybrane projekty
Jak pracuję
Modernizacja oparta na ciągłości biznesu.
Krytycznego systemu legacy nie trzeba przepisywać jednocześnie. Najpierw zabezpieczam jego działanie i odtwarzam wiedzę o procesach. Następnie wydzielam kompletne procesy w domenach o jawnych granicach.
- Rozumiem krytyczną ścieżkę
Zaczynam od procesu biznesowego i ograniczeń produkcji.
- Modernizuję odwracalnymi krokami
Ograniczam ryzyko przez obserwowalne, etapowe zmiany.
- Odpowiadam za efekt na produkcji
Łączę architekturę z wdrożeniem i utrzymaniem.
Stabilizuję → Obserwuję → Mapuję → Wydzielam → Zastępuję
Ciągłość biznesu
- Stabilizuję
Zabezpieczam wdrożenia, backupy, dostęp i największe punkty awarii.
- Obserwuję
Dodaję metryki, logi, alerty i widoczność procesów biznesowych.
- Mapuję
Odtwarzam procesy, zależności, źródła prawdy i ukryte reguły.
- Wydzielam
Przenoszę kompletny proces do domeny z jawnymi kontraktami.
- Zastępuję
Przełączam ruch, weryfikuję wynik i wycofuję starą implementację.
Główna realizacja · ERP dla branży automotive
Modernizacja krytycznego ERP bez zatrzymywania sprzedaży, zakupów i pracy magazynów.
Duża hurtownia części samochodowych była zależna od kilku nieudokumentowanych, silnie powiązanych systemów legacy. Wdrożenia były ryzykowne, dane różniły się między bazami, awarie zgłaszali użytkownicy, a duże zamówienia do dostawców wymagały wielu godzin ręcznej pracy.
Zamiast proponować przepisanie wszystkiego od zera, zaprojektowałem modernizację całymi procesami biznesowymi. Produkcyjne SCM i OMS przejęły kluczowe przepływy, wdrożenia stały się odwracalne, środowisko trafiło na zarządzaną infrastrukturę AWS, a stare i nowe systemy otrzymały wspólną warstwę obserwowalności.
Przeczytaj pełne case studyZweryfikowane rezultaty
- Kilka godzin → kilka minut
- dla zamówienia liczącego około 2000 części
- Około godziny → maks. 40 sekund
- dla odwracalnego wdrożenia legacy
- Zgłoszenie użytkownika → alert w kilka sekund
- dla 14 komponentów systemowych i ich infrastruktury
- Bazy 12 GB i 59 GB · bez przestoju
- przeniesione z infrastruktury on-premise do AWS RDS
Mapa modernizacji
- Legacy ERPProdukcja
- OMSProdukcja
- SCMProdukcja
- AWSProdukcja
- ObservabilityProdukcja
- PIMW budowie
- WMSW budowie
- Pricing EngineW budowie
- Marketplace IntegrationW budowie
- Central BIW budowie
Gdy zmiana staje się ryzykowna
Systemy krytyczne rzadko psują się jednego dnia. Stopniowo stają się wolniejsze, bardziej ryzykowne i trudniejsze do zmiany — aż firma nie może dłużej tego ignorować.
- 01
Legacy jest zbyt ważne, żeby je wyłączyć, i zbyt ryzykowne, żeby je zmieniać.
- 02
Wdrożenia i incydenty zależą od jednej osoby.
- 03
Zamówienia, produkty i stany różnią się między systemami.
- 04
Zespół potrzebuje odpowiedzialności na poziomie Principal, a nie kolejnego dostawcy.
Sposoby współpracy
Zacznijmy od ryzyka, które trzeba ograniczyć jako pierwsze.
- 01Legacy Exit Map na 90 dni i 12 miesięcy.
Audyt modernizacji legacy
Audyt o stałym zakresie: systemy, procesy krytyczne, źródła prawdy i ryzyko operacyjne.
- 02System bezpieczniejszy w utrzymaniu i zmianie.
Stabilizacja i doskonałość operacyjna
Powtarzalne wdrożenia, próby kontrolne, monitoring stanu, bezpieczne wycofanie zmian, obserwowalność, kopie zapasowe i odtwarzanie.
- 03Kompletne procesy wydzielone w domenach o jawnych granicach.
Architektura ERP i dostarczanie etapami
Granice domen, odpowiedzialność za dane, kontrakty, wdrożenie i wycofywanie starych elementów całych procesów ERP.
- 04Bezpośrednia odpowiedzialność techniczna tam, gdzie ryzyko jest największe.
Partner architektoniczny na poziomie Principal
Decyzje architektoniczne, niezależny przegląd i bezpośrednia pomoc w implementacji bez dokładania kolejnej warstwy zarządczej.
Wybrane rezultaty
Zakres odpowiedzialności opisany równie jasno jak rezultat.
Produkcja
Jeden model zamówienia dla krytycznych przepływów
B2B, telefon, warsztaty i cross-dock korzystają z jednego modelu kanonicznego z idempotencją, wersjami roboczymi, backorderami, dokumentami i pełną historią.
Odpowiedzialność Piotra: Zaprojektowany i zaimplementowany w całości przez Piotra.
Produkcja
Wybór dostawcy oparty na cenie i realnej dostępności
Formaty czterech dostawców są normalizowane do jednego modelu; wygrywa najniższa dostępna cena, a dostawca bez dostępnego towaru nie jest wybierany.
Odpowiedzialność Piotra: Piotr zaprojektował architekturę oraz wykonał frontend i późniejsze zmiany; drugi developer uczestniczył w początkowej implementacji backendu.
Zakończone
Produkcyjne bazy przeniesione bez przestoju
Bazy MariaDB o rozmiarach 12 GB i 59 GB przeniesiono z infrastruktury on-premise do AWS RDS po tygodniu obserwowanej replikacji.
Odpowiedzialność Piotra: Piotr samodzielnie przeprowadził migrację.
Produkcja
Automatyczne przetwarzanie zmian katalogowych
Katalog blisko 10 milionów produktów przeszedł z wielodniowej aktualizacji wymagającej developera do procesu uruchamianego automatycznie po udostępnieniu nowej delty.
Odpowiedzialność Piotra: Piotr zaprojektował architekturę; implementację wykonali inni developerzy.
Odpowiedzialność na poziomie Principal
Architektura nie powinna kończyć się w chwili przekazania do implementacji.
Jestem Piotr Mucha — Principal Software Engineer i architekt pracujący bezpośrednio przy implementacji, z doświadczeniem w ERP, e-commerce, automatyzacji marketingu, integracjach finansowych, platformach AWS i zastosowaniach AI.
Pracuję bezpośrednio nad architekturą, najtrudniejszymi fragmentami implementacji i ryzykiem produkcyjnym. Gdy potrzebna jest większa przepustowość, FairyDeck może dobrać specjalistów bez rozmywania mojej osobistej odpowiedzialności za realizację.
Inżynieria wspierana przez AI
AI może skrócić pętlę inżynierską. Nie zastępuje odpowiedzialności.
Korzystam z narzędzi agentowych tam, gdzie wersjonowanie, przegląd, testy i możliwość wycofania zmian tworzą audytowalny proces pracy.
Produkcja · 8 developerów
Model-agnostic CLI dla zespołu inżynierskiego
GitHub pozostaje źródłem prawdy, a reguły są wersjonowane, odwracalne i obecnie synchronizowane ręcznie.
Zakończony · 6 developerów
Sześciomodułowy program inżynierski
Planning, subagenci, skills, hooks, MCP, walidacja end-to-end i review dla zespołu z niewielkim wcześniejszym doświadczeniem.
W toku · Metoda inżynierska
Agentic SDLC oparty na weryfikacji
Trwałe plany, małe porcje pracy, testy, porównania w przeglądarce i jawne pętle weryfikacji.
Product Lab
Praca nad własnymi produktami konfrontuje decyzje architektoniczne z realnymi ograniczeniami produkcji i R&D.
Produkcja · realni użytkownicy
Senioruj.pl
Platforma dla silver economy zaprojektowana i zbudowana end-to-end przez Piotra.
Aktywnie rozwijany
Home Medicine
Aplikacja Flutter do skanowania leków, miejsc przechowywania, dat ważności i dawkowania, z danymi przechowywanymi wyłącznie lokalnie i transferem przez QR.
Aktywne R&D · bez użytkowników
Kivvi-click
Audytowalny produkt do zbierania zdarzeń, podglądu na żywo, wysyłki e-maili i wybranych automatyzacji, oparty na PHP, PostgreSQL, czystym JavaScript i CSS.
Wiedza
Notatki robocze z modernizacji systemów krytycznych.
W przygotowaniu
Dlaczego przepisanie krytycznego ERP zwykle jest złym pierwszym krokiem
W przygotowaniu
Jak ryzykowne godzinne wdrożenie legacy stało się odwracalnym procesem trwającym 40 sekund
W przygotowaniu
Observability dla błędów biznesowych, nie tylko serwerów
FairyDeck · Piotr Mucha
Czy Twój system jest zbyt ważny, żeby go wymienić, i zbyt ryzykowny, żeby zostawić go bez zmian?
Opowiedz, co system obsługuje, co czyni go ryzykownym i co musi się zmienić. Pierwsza rozmowa służy ustaleniu, czy właściwym krokiem jest audyt, stabilizacja czy stałe wsparcie architektoniczne na poziomie Principal.
Porozmawiajmy o systemieRozmowa może odbyć się w trybie NDA. Na pierwszym spotkaniu nie potrzebuję dostępu do kodu źródłowego.