Wiedza z praktyki

Notatki z modernizacji systemów, których biznes nie może zatrzymać.

Interesuje mnie nie sama technologia, lecz decyzja, która ogranicza ryzyko i przenosi odpowiedzialność bez utraty ciągłości biznesu.

Każda notatka zaczyna się od rzeczywistego problemu, pokazuje wybrany kierunek i wskazuje dowód produkcyjny. Nie oddzielam rekomendacji architektonicznej od konsekwencji wdrożenia.

01

Strategia modernizacji

Dlaczego przepisanie krytycznego ERP zwykle jest złym pierwszym krokiem

Pełny rewrite łączy największą niepewność techniczną z największym możliwym wdrożeniem.

W słabo udokumentowanym ERP reguły biznesowe są rozproszone między ludźmi, kodem, bazami i plikami. Sprzedaż, zakupy, magazyny oraz dokumenty finansowe nadal muszą działać, więc nie można bezpiecznie zamrozić systemu na czas odtwarzania całej wiedzy.

Najpierw stabilizuję wdrożenia i obserwowalność, mapuję proces oraz źródła prawdy, a następnie przenoszę kompletną odpowiedzialność biznesową do domeny z jawnymi kontraktami. Stara implementacja znika dopiero po zweryfikowanym przełączeniu wszystkich zależności.

W ERP automotive produkcyjne OMS i SCM przejęły kluczowe przepływy, podczas gdy sprzedaż, zakupy i praca magazynów pozostały dostępne. Kolejne domeny są jawnie oznaczone jako prace w toku, a nie ukończone rezultaty.

Zobacz dowody w case study
02

Operational excellence

Jak ryzykowne godzinne wdrożenie legacy stało się odwracalnym procesem trwającym 40 sekund

Modernizacja nie zaczęła się od wymiany aplikacji, lecz od skrócenia i zabezpieczenia okna ryzyka.

Wdrożenia legacy zależały od jednej osoby, trwały około godziny i utrudniały bezpieczne dostarczanie mniejszych zmian. Bez powtarzalnego procesu każda kolejna modernizacja zwiększałaby ryzyko operacyjne.

Proces został zautomatyzowany jako krótka, powtarzalna i odwracalna sekwencja. Stabilizacja wdrożeń, rollback, monitoring oraz backupy poprzedziły wydzielanie kolejnych odpowiedzialności z legacy.

Maksymalny czas odwracalnego wdrożenia spadł z około godziny do 40 sekund, a wydanie legacy stało się krótkim i powtarzalnym procesem.

Zobacz dowody w case study
03

Odpowiedzialność produkcyjna

Observability dla błędów biznesowych, nie tylko serwerów

Sprawna infrastruktura nie wystarcza, jeśli krytyczny proces przestał działać poprawnie.

W środowisku ERP awarie często najpierw zgłaszali użytkownicy. Sygnały techniczne nie dawały wspólnego obrazu zachowania ośmiu systemów legacy, sześciu nowych części ERP i ich infrastruktury.

Stare i nowe komponenty otrzymały wspólną warstwę logów, metryk i alertów, uzupełnioną o widoczność procesów biznesowych. Obserwowalność stała się warunkiem bezpiecznego przełączania odpowiedzialności między domenami.

Sygnał zmienił się ze zgłoszenia użytkownika na automatyczny alert pojawiający się w kilka sekund.

Zobacz dowody w case study

Twój system

Masz podobną decyzję do podjęcia w działającym systemie?

Opowiedz o procesie, ograniczeniu produkcyjnym i awarii, na którą firma nie może sobie pozwolić. Ustalimy, jaki odwracalny krok ma sens jako pierwszy.

Porozmawiajmy o systemie