1. Dlaczego rozszerzać low-code zamiast modyfikować rdzeń

Bezpośrednie zmiany w rdzeniu ERP kończą się bólem przy aktualizacjach, lock-inem u dostawcy i kruchą logiką biznesową, której nikt nie chce dotykać. Rozszerzenia low-code proponują inne podejście: pozostaw ERP jako system referencyjny i odpowiedzialny za księgowość, a szybkie zmiany oraz eksperymenty przenieś do elastycznej warstwy wokół niego.

Typowe cele rozszerzeń low-code:

  • dodawanie nowych workflow bez zmian w bazowych tabelach i transakcjach,
  • bezpieczne eksperymenty z UX i procesami pobocznymi,
  • integracje z usługami zewnętrznymi bez wbudowywania ich w silnik ERP,
  • umożliwienie pracy citizen developers (użytkownicy biznesowi tworzący rozwiązania samodzielnie) w jasnych ramach.

2. Wzorzec #1 – Warstwa workflow nad ERP

Najprostszy wariant: ERP pozostaje systemem zapisu, a zatwierdzenia i dodatkowe kroki orkiestruje silnik workflow w low-code. Workflow korzysta z API ERP do odczytu/aktualizacji danych i przechowuje tylko minimalny stan własny.

Dobre zastosowania:

  • akceptacja zapotrzebowań przed utworzeniem zamówienia w ERP,
  • obsługa wyjątków wokół limitów kredytowych, cen i rabatów,
  • ręczne kontrole zgodności, jakości czy ryzyka.

Deklaratywne platformy takie jak lsFusion dobrze się tu sprawdzają: formularze, stany i reguły opisuje się deklaratywnie, a przy zakończeniu kroku wywoływane są API lub procedury ERP.

3. Wzorzec #2 – Aplikacje side-car dla złożonych procesów

Jeśli proces jest zbyt specyficzny lub zbyt dynamiczny jak na standard ERP, można zbudować osobną aplikację low-code typu side-car, która traktuje ERP jako źródło i ujście danych.

Przykłady:

  • dyspozycja produkcji i interfejsy dla hali,
  • specjalizowane narzędzia do zarządzania projektami lub usługami,
  • konfiguratory złożonych produktów.

Aplikacja side-car czyta dane referencyjne (klienci, produkty, ceny) z ERP i zapisuje tylko finalne transakcje (zamówienia, karty pracy, wyniki produkcji). Dzięki temu schema ERP pozostaje czysta, a side-car może ewoluować szybko.

4. Wzorzec #3 – Mikro‑rozszerzenia event-driven

W architekturze event-driven ERP publikuje zdarzenia typu order.created, invoice.posted czy inventory.below_threshold. Komponenty low-code subskrybują je i wykonują niewielkie, jasno zdefiniowane akcje.

Przykłady mikro‑rozszerzeń:

  • wysyłanie powiadomień do komunikatorów lub emaila,
  • tworzenie zadań w systemie ticketowym,
  • przesyłanie zagregowanych danych do analityki i dashboardów,
  • uruchamianie automatycznego generowania dokumentów.

W platformach deklaratywnych takie reakcje opisuje się jako reguły: 

EVENT orderCreated WHEN Orders.status = 'Approved' DO
            createShipment(Orders);
            notifySales(Orders.customer);

Dzięki temu logika rozszerzeń pozostaje czytelna i łatwa do audytu, zamiast być zbiorem przypadkowych skryptów.

5. Wzorzec #4 – Raportowanie low-code i „operacyjny BI”

Użytkownicy ERP często potrzebują szybkich raportów ad-hoc z filtrami, grupowaniem i polami liczonymi. Zamiast przenosić każdy raport do rdzenia ERP, można wystawić widoki tylko do odczytu, a wizualizację i interaktywne cięcia przenieść do warstwy low-code.

Korzyści:

  • biznes może iterować nad raportami bez wdrożeń,
  • dostęp tylko do odczytu redukuje ryzyko przypadkowych zmian danych,
  • logika agregacji może rozwijać się szybciej niż schema ERP.

6. Zasady bezpieczeństwa: jak nie złamać ERP

Moc low-code wymaga dyscypliny. Kilka zasad pomaga chronić rdzeń:

  • Single source of truth. Kluczowe dane finansowe i magazynowe mieszkają w ERP.
  • Jasna odpowiedzialność. Każdy workflow wie, który system za co odpowiada.
  • Wersjonowanie. Aplikacje low-code należy wersjonować i testować jak kod.
  • Kontrola dostępu. W miarę możliwości używaj tych samych ról i uprawnień co w ERP.
  • Monitoring. Loguj i śledź działania low-code, które dotykają danych ERP.

7. Gdzie low-code nie jest dobrym pomysłem

Są obszary, które powinny pozostać w rdzeniu ERP lub w klasycznym developmentcie:

  • logika księgowa i podatkowa,
  • raporty regulacyjne o sztywnych formatach,
  • krytyczne wydajnościowo batch‑procesy na bardzo dużych wolumenach danych,
  • moduły bezpieczeństwa, które zarządzają sekretami lub danymi wrażliwymi.

Podsumowanie

Low-code nie zastępuje ERP — pomaga go rozszerzać i jednocześnie chronić. Dzięki warstwie workflow, aplikacjom side-car, mikro‑rozszerzeniom event-driven i raportowaniu low-code organizacje mogą szybko eksperymentować, zachowując rdzeń ERP stabilnym, aktualizowalnym i przejrzystym.