ERP, które nie zamienia się w drogi hamulec
Dlaczego systemy ERP psują się w podobny sposób: ograniczenia architektoniczne 1C, SAP, Microsoft Dynamics, Odoo i innych platform ERP oraz ich zachowanie przy zmianie reguł biznesowych.
Na podstawie technicznych artykułów na Habr: «Dlaczego lsFusion, a nie 1C?» oraz «Dlaczego nie 1C?» . Dalej — inżynierskie „rozszyfrowanie”: mechanizmy, symptomy, diagnostyka na pilocie i sposoby ograniczania ryzyka.
1.1 Dlaczego ograniczenia architektoniczne ERP ujawniają się podobnie
Większość ERP (1C, SAP, Microsoft Dynamics, Odoo) na początku wygląda stabilnie: danych jest mało, procesy są uproszczone, wyjątki rzadkie, integracje „cienkie”. Ograniczenia architektoniczne w tym momencie są prawie niewidoczne.
Problemy pojawiają się później — gdy firma zaczyna zmieniać reguły. Przyczyna nie tkwi w „złym systemie”, tylko w tym, że typowe ERP są zbudowane wokół podobnych kompromisów: model obiektowy, osobna warstwa raportowania, rozdzielona logika (formularz/serwer/integracje), a także ograniczenia warstwy zapytań i operacji masowych. Przy wzroście danych i liczby wyjątków te kompromisy dają takie same symptomy niezależnie od dostawcy.
Ten materiał nie odpowiada na pytanie „które ERP jest lepsze”. Odpowiada na inne pytanie: gdzie i dlaczego drożeje zmiana reguł oraz jak to rozpoznać przed wdrożeniem produkcyjnym.
1.2 Co uznać za „zmianę reguł”, a nie modyfikację
„Zmiana reguł” to nie „dodać pole” i nie „zrobić nowy raport”. To zmiana, która jednocześnie:
- zmienia zachowanie transakcji (walidacja, księgowanie, statusy, ograniczenia);
- zmienia wskaźniki (marża, koszt własny, limity, stany, ryzyko);
- zmienia kontrolę (blokady, akceptacje, zakazy warunkowe);
- nie może zepsuć raportowania i integracji (CRM/WMS/marketplace/BI).
Jeśli platforma nie utrzymuje tego jako jednego modelu (dane + obliczenia + kontrola), reguła nieuchronnie jest realizowana w kilku miejscach. Wtedy koszt zmiany jest wyznaczany nie przez złożoność formuły, lecz przez liczbę warstw, które trzeba jednocześnie zmienić i zweryfikować.
1.3 Jak czytać tę analizę i co daje w praktyce
Dalej znajdują się konkretne punkty architektoniczne (obiekty, rejestry, zapytania, formularze, blokady, typowanie itd.). Dla każdego punktu używany jest ten sam format:
- Co to znaczy — ograniczenie bez ogólników;
- Jak to się ujawnia w 1C / SAP / Dynamics / Odoo (typowe mechanizmy, a nie „ogólnie trudno”);
- Jaki symptom zobaczysz w eksploatacji (co realnie „boli”);
- Jak sprawdzić na demo/pilocie — pytanie lub scenariusz, który obnaża problem.
Po tej analizie będziesz w stanie szybko odróżniać: „poprawkę reguły” (przewidywalna praca w jednym miejscu) od „poprawki systemu” (wielowarstwowe zmiany z drogą regresją), i z wyprzedzeniem rozumieć, gdzie powstaje zależność od dostawcy lub pojedynczych specjalistów.
-
Jedna reguła — jedno miejsce?
Poproś o pokazanie, gdzie „mieszka” konkretna reguła (np. limit/marża/stany) i ile warstw dotyka. Jeśli to kod + formularz + raport + procedura — zmiany będą drogie. -
Czy istnieje „moment zakończenia” operacji?
Zapytaj, kiedy operacja jest uznawana za ostatecznie wykonaną (commit point) i co dzieje się asynchronicznie po „sukcesie”. Jeśli odpowiedź jest nieostra — spodziewaj się „odroczonych błędów” i ręcznych kontroli. -
Test wyjątków
Dodaj 2–3 wyjątki do typowej logiki. Jeśli od razu pojawiają się „specjalne procedury” — model nie utrzymuje wariantowości. -
Czy regres jest kontrolowany?
Zapytaj, jak sprawdzają, że zmiana reguły nie zepsuła raportów/integracji. Jeśli „sprawdzimy wzrokiem” — będzie bolało. -
Czy da się przewidzieć koszt kolejnej zmiany?
Dobra architektura pozwala z góry powiedzieć: „zmiana dotknie N mechanizmów i jest weryfikowana takimi testami”. Zła — zamienia każdą poprawkę w badanie/śledztwo.
2. Model danych i obliczeń
Ten rozdział dotyczy fundamentu: jak w ERP są zbudowane dane i obliczenia oraz jakie ograniczenia są zaszyte jeszcze przed kodem, formularzami i integracjami. To właśnie tutaj decyduje się, czy reguły biznesowe da się wyrazić jako jeden model, czy też nieuchronnie rozpełzną się po systemie.
2.1 Obiekty: słowniki, dokumenty itd.
Jak to zwykle bywa zrealizowane w ERP
Większość ERP opiera się na modelu obiektowym: słowniki, dokumenty, pozycje, ruchy. Logika biznesowa jest przypięta do cyklu życia obiektu (utworzenie, edycja, księgowanie), a nie opisana jako osobny system reguł.
1C
Metadane (Słowniki, Dokumenty, Rejestry) — podstawa architektury. Kontrole i obliczenia są rozproszone między księgowaniem, modułami formularzy i pomocniczymi handlerami.
SAP
Model obiektowy jest uzupełniany konfiguracją i rozszerzeniami, ale reguła często okazuje się kompozycją standardowego obiektu, kodu niestandardowego i warstwy procesowej.
Microsoft Dynamics
Encje są punktem wejścia, ale logika jest rozproszona między wtyczkami (plugins), automatyzacjami i regułami po stronie klienta.
Odoo
Modele ORM wyglądają spójnie, ale wraz ze wzrostem kastomizacji logika rozchodzi się między modelami, polami obliczanymi (computed fields) i modułami.
Symptom eksploatacyjny: jedna reguła biznesowa jest zaimplementowana w kilku obiektach i warstwach; wyjaśnienie „dlaczego system tak policzył” wymaga znajomości historii wdrożenia.
Jak sprawdzić: poprosić o pokazanie jednej reguły i wszystkich obiektów, w których jest zaimplementowana lub wpływa na zachowanie.
2.2 Nieefektywne pobieranie danych obiektów
Jak to zwykle bywa zrealizowane w ERP
Obiekty są wygodne dla transakcji, ale słabo pasują do złożonych obliczeń. W efekcie dane są pobierane częściowo zapytaniami, częściowo przez obiekty, a obliczenia są składane proceduralnie.
1C
Typowy scenariusz: zapytanie + odczyt obiektów + pętle. Wydajność zależy od dyscypliny programisty.
SAP
Dane są dostępne przez kilka poziomów modelu, co utrudnia kontrolę faktycznych selekcji.
Dynamics
ORM/API łatwo generują wiele wywołań zamiast jednego optymalnego zapytania.
Odoo
ORM ukrywa rzeczywiste zapytania; problemy ujawniają się przy wzroście danych.
Symptom eksploatacyjny: system degraduje wydajność nie od razu, lecz „nagle” — wraz ze wzrostem wolumenu.
2.3 Tabele i widoki: rejestry
Jak to zwykle bywa zrealizowane w ERP
Dla analityki wprowadza się osobną warstwę: agregaty, ruchy, widoki. Powstaje drugie źródło prawdy, różniące się od danych transakcyjnych.
1C
Rejestry to kluczowy mechanizm, ale logika obliczeń często częściowo pozostaje w kodzie.
SAP
Odpowiednik to połączenie ruchów, agregatów i widoków analitycznych.
Dynamics
Agregaty często wynosi się do BI lub hurtowni/witryn.
Odoo
Są typowe agregaty, ale wraz ze wzrostem wymagań pojawiają się widoki SQL i zewnętrzna analityka.
Symptom eksploatacyjny: operacje i raporty rozjeżdżają się, przeliczenia wymagają specjalnych procedur.
2.4 Rejestry są wspierane tylko w bardzo szczególnych przypadkach
O co chodzi
Warstwa analityczna (rejestry/agregaty/witryny) działa dobrze, dopóki reguła biznesowa mieści się w „typowym” wzorcu: stany, obroty, proste przekroje, standardowe okresy. Gdy pojawia się nietypowa semantyka (wyjątki, reguły warunkowe, alternatywne źródła, historyczne „jak było na dzień” według niestandardowej cechy), część logiki przestaje dać się wyrazić w modelu i trafia do kodu/procedur/integracji.
Jak to się ujawnia w standardowych ERP
1C
Rejestry (magazynowe/księgowe/informacyjne) pokrywają wiele scenariuszy, ale realna logika często się rozpada: część — w ruchach przy księgowaniu, część — w zapytaniach raportów (SKD), część — w procedurach przeliczeń. Gdy potrzebny jest „niestandardowy” algorytm (warunkowe przeliczenia, złożone wyjątki, alternatywna wycena), trafia on do kodu proceduralnego i przestaje być częścią jednego modelu.
SAP
Typowe rozliczenia i analityka opierają się na bogatym modelu i mechanizmach rozszerzeń, ale „niestandard” często realizuje się jako miks konfiguracji + rozszerzeń + osobnego modelu analitycznego (albo wyniesienia do osobnej warstwy analityki). W efekcie reguła istnieje w kilku miejscach, a synchronizacja staje się osobnym przedsięwzięciem.
Microsoft Dynamics
W typowym krajobrazie wskaźniki często „rozprowadza się” po warstwach: encje transakcyjne, reguły/wtyczki, widoki raportowe i zewnętrzna analityka. Nietypowe reguły niemal nieuniknienie kończą jako kombinacja: kod + low-code automatyzacje + witryna/BI.
Odoo
Podstawowe agregaty i pola obliczane działają do pewnej złożoności. Dalej pojawiają się: osobne modele dla „pochodnych” wskaźników, widoki SQL, przeliczenia w tle i zewnętrzna analityka. Reguła przestaje być „częścią modelu” i staje się zestawem implementacji.
Symptom eksploatacyjny: część reguł żyje w „modelu” (rejestry/agregaty), a część — w „specjalnych procedurach”. Mała zmiana zaczyna wymagać poprawek w kilku miejscach, a wyjaśnialność „dlaczego tak policzyło” spada.
Jak sprawdzić na demo/pilocie: poprosić o wzięcie jednego wskaźnika (np. dostępny stan/marża/limit) i dodanie 2–3 wyjątków (np. wg typu klienta, magazynu, daty, alternatywnego źródła ceny). Sprawdź, czy pozostaje jeden mechanizm (jedno miejsce/jeden typ mechanizmu), czy reguła „rozpełza się” na kod + raport + przeliczenie + integrację.
2.5 Brak ograniczeń i zdarzeń dla wartości rejestrów
O co chodzi
W wielu ERP ograniczenia i zdarzenia są dobrze zdefiniowane dla operacji (dokument/księgowanie/zapis), ale słabo zdefiniowane dla wartości obliczanych/agregowanych (stany, limity, ratingi, ryzyko). To znaczy: platforma nie daje natywnego mechanizmu w stylu: „jeśli agregat stał się taki — zakaż/powiadom/uruchom reakcję” jako część modelu. Dlatego kontrolę realizuje się proceduralnie: walidacjami przy księgowaniu, kontrolami w tle, raportami-walidatorami i ręcznymi regulaminami.
Jak to się ujawnia w standardowych ERP
1C
Typowa droga — sprawdzanie „na miejscu” przy księgowaniu dokumentu lub w formularzu. Ale agregat (np. limit/stan/rotacja) może zmieniać się nie tylko z jednego dokumentu: z kilku typów operacji, zmian wstecz, przeliczeń, wymian danych. Wtedy kontrola zaczyna się dublować, a „kiedy dokładnie zadziała zakaz” zależy od scenariusza.
SAP
Kontrolę często buduje się przez statusy/procesy/sprawdzenia w transakcjach, a monitoring agregatów — osobnymi mechanizmami (procedury kontroli, raporty, workflow). Formalnie to potężne, ale reguła częściej staje się konstrukcją procesową, a nie deklaratywnym ograniczeniem wartości.
Microsoft Dynamics
Reguły biznesowe i wtyczki wygodnie podpina się pod zdarzenie zmiany encji, ale agregaty zwykle liczy się osobno (tło, integracja, warstwa raportowa). W efekcie „ograniczenie na agregat” realizuje się jako zestaw walidacji + automatyzacji, i trudno je w sposób dowodowy uczynić pełnym (bez luk).
Odoo
Są constraints i onchange na poziomie modeli, ale agregaty często żyją w computed fields, które mogą się przeliczać leniwie/po triggerach/po cron. Dlatego kontrola po agregacie łatwo staje się niedeterministyczna: „czasem łapie, czasem nie”, jeśli nie zbuduje się ścisłej dyscypliny.
Symptom eksploatacyjny: zakazy i kontrola działają „nie zawsze tak samo”: jeden użytkownik łapie ograniczenie od razu, inny — później; część naruszeń wykrywa raport/kontrola po fakcie. Pojawiają się regulaminy „sprawdzajcie ręcznie”.
Jak sprawdzić na demo/pilocie: poprosić o zrobienie ograniczenia na agregat: „nie wolno wysyłać, jeśli sumaryczne ryzyko/limit klienta > X, z uwzględnieniem wszystkich dokumentów i korekt”. Następnie poprosić o pokazanie 3 ścieżek zmiany agregatu (dokument, korekta wstecz, integracja/import) i upewnić się, że ograniczenie działa identycznie we wszystkich trzech scenariuszach.
2.6 W parametrach tabel wirtualnych można używać tylko stałych
O co chodzi
Gdy warstwę analityczną da się parametryzować tylko stałymi (albo bardzo ograniczenie), system nie potrafi „dostosować” obliczeń do kontekstu operacji. W efekcie trzeba: (1) pobierać dane „szerzej, niż trzeba”, a potem filtrować w kodzie/formularzu, (2) tworzyć kopie zapytań/raportów dla różnych wariantów, (3) wynosić część logiki z modelu do warstw proceduralnych. To po cichu podnosi koszt zmian: każdy nowy warunek rodzi nowe kopie.
Jak to się ujawnia w standardowych ERP
1C
Typowy efekt: raport/zapytanie „uniwersalne” tylko z nazwy. Gdy pojawiają się warunki „zależne od kontekstu” (aktualny użytkownik, rola, stan dokumentu, parametry formularza), część filtracji trafia do kodu, a zapytania się kopiuje. Z czasem powstaje „zoo” niemal identycznych raportów/selekcji.
SAP
Warunki kontekstowe często rozwiązuje się konfiguracją, parametrami widoków i warstwami procesowymi, ale wraz ze wzrostem wariantowości pojawia się ten sam wzorzec: różne warianty widoków/zapytań/ról zamiast jednej opisanej reguły. Cena: trudniejsze utrzymanie i ryzyko rozjazdu logiki.
Microsoft Dynamics
Ograniczenia wyrażeń i kontekstu prowadzą do mnożenia widoków/zapytań/flow: „dla tej roli jedno”, „dla tego formularza drugie”. Gdy biznes zmienia regułę, trzeba znaleźć wszystkie kopie i poprawić je jednocześnie.
Odoo
ORM jest wygodny, ale złożony kontekst często prowadzi do: domen/kontekstów na poziomie UI + osobnych metod selekcji w kodzie + SQL dla ciężkich przypadków. Wariantowość filtrów szybko rodzi duplikaty i „lokalne rozwiązania”.
Symptom eksploatacyjny: pojawiają się „prawie identyczne” raporty, listy i selekcje. Mała zmiana warunku (kolejny filtr/wyjątek) zamienia się w serię poprawek: zapytanie, kod formularza, uprawnienia, osobny raport, osobna procedura.
Jak sprawdzić na demo/pilocie: poprosić o realizację tej samej listy/raportu dla 3 kontekstów: (1) dla księgowego, (2) dla menedżera, (3) dla kierownika — z różnymi filtrami i kolumnami, ale z jednym źródłem reguły. Następnie poprosić o zmianę reguły (dodać wyjątek) i zobaczyć, czy zmienia się to w jednym miejscu, czy w kilku kopiach.
3. Warstwa zapytań i praca z danymi
Ten rozdział dotyczy tego, na ile zapytania są zarządzalną częścią architektury ERP. Tu widać, czy logikę biznesową da się wyrażać deklaratywnie i przewidywalnie kontrolować jej koszt, czy też każda zmiana zamienia się w ryzyko wydajności i regresji.
3.1 Zapytania jako samodzielna warstwa systemu
Jak to zwykle bywa zrealizowane w standardowych ERP
W większości ERP zapytania służą do odczytu danych i raportowania. Reguły biznesowe (walidacje, obliczenia, ograniczenia) realizuje się w logice aplikacyjnej: w kodzie obiektów, handlerach, workflow i automatyzacjach. Warstwa zapytań nie jest traktowana jako źródło prawdy dla reguł.
1C
Zapytania są intensywnie używane w raportach i analityce (SKD), ale księgowanie dokumentów i kontrola są wykonywane w kodzie. Ten sam wskaźnik często jest liczony: raz w zapytaniu, drugi raz — w handlerze.
SAP
Obliczenia są rozproszone między CDS View, kod ABAP i konfigurację. Te poziomy są mocne, ale nie tworzą jednego języka reguł.
Microsoft Dynamics
Widoki i FetchXML — do odczytu, reguły biznesowe — w pluginach, flow i skryptach klienckich. Zapytanie nie jest nośnikiem logiki.
Odoo
Zapytania ORM służą do selekcji, a logika jest realizowana w kodzie Python i polach computed.
Symptom eksploatacyjny: nie da się jednoznacznie odpowiedzieć, gdzie dokładnie liczony jest wskaźnik i która wersja formuły jest „główna”.
Jak sprawdzić: poprosić o pokazanie wszystkich miejsc, gdzie używany jest ten sam wyliczenie, i jak zapewnia się ich identyczność.
3.2 Zapytania jako ciągi tekstowe
Jak to zwykle bywa zrealizowane w standardowych ERP
Zapytania i warunki często są definiowane jako tekst: SQL, wyrażenia filtrów, formuły w ustawieniach. Platforma nie potrafi analizować ich struktury i sprawdzać wpływu zmian.
1C
Zapytania — tekstowe. Błędy i zależności ujawniają się dopiero w runtime.
SAP
W standardowych warstwach kontrola jest wyższa, ale custom i integracje szybko prowadzą do konstrukcji tekstowych.
Microsoft Dynamics
Warunki i wyrażenia w flow i konfiguracji formalnie no-code, ale w praktyce tekstowe.
Odoo
Raw SQL rozwiązuje zadania, ale psuje analizę zależności i aktualizacje.
Symptom eksploatacyjny: zmiana schematu danych powoduje błędy „po fakcie”, pojawia się zasada „lepiej tego nie ruszać”.
3.3 Brak przewidywalnej optymalizacji jako części modelu reguł
Jak to zwykle bywa zrealizowane w standardowych ERP
Wydajność zapytań nie wynika bezpośrednio z modelu reguł. Osiąga się ją ręczną optymalizacją, indeksami i doświadczeniem programistów.
1C
Zapytanie może być logicznie poprawne, ale fizycznie nieefektywne.
SAP
Mocna baza danych pomaga, ale złożone modele dają nieoczekiwane plany wykonania.
Microsoft Dynamics
Złożoną analitykę często wynosi się do BI, zamiast optymalizować wewnątrz ERP.
Odoo
ORM ukrywa rzeczywiste plany wykonania, optymalizacja staje się „sztuką”.
Symptom eksploatacyjny: raporty „latają” na teście i degradują na realnych danych.
3.4 Brak rozszerzonych możliwości SQL
Jak to zwykle bywa zrealizowane w standardowych ERP
Obsługa funkcji okiennych, CTE i agregacji warunkowych bywa ograniczona albo wymaga obejść. W efekcie obliczenia rozpadają się na kilka kroków i kod.
Symptom eksploatacyjny: te same formuły są duplikowane, trudno zrozumieć, gdzie dokładnie liczony jest wskaźnik.
Jak sprawdzić: poprosić o pokazanie złożonego wyliczenia zarządczego bez pętli i tabel tymczasowych.
3.5 Brak zapytań do zmian (UPDATE / DELETE / MERGE)
Jak to zwykle bywa zrealizowane w standardowych ERP
Masowe zmiany danych nie są traktowane jako standardowa część języka zapytań. Stosuje się pętle, procedury lub narzędzia zewnętrzne.
1C
Masowe zmiany = iteracja po obiektach i ponowne księgowanie.
SAP
Operacje masowe są możliwe, ale wymagają wysokich kompetencji i ostrożności.
Microsoft Dynamics
Masowe zmiany często wynosi się do ETL i Dataflows.
Odoo
ORM jest wolny dla operacji masowych, raw SQL jest ryzykowny dla utrzymania.
Symptom eksploatacyjny: przeliczenia wykonuje się nocą, uznaje się je za niebezpieczne i rzadkie.
4. Przepływ wykonania i gwarancje spójności danych
Ten rozdział dotyczy gwarancji, a nie wygody. Tego, czy da się formalnie określić moment zakończenia operacji, źródło prawdy i kolejność stosowania reguł biznesowych. Brak formalnych gwarancji prowadzi do błędów, których „nie da się odtworzyć” i podważa zaufanie do danych.
4.1 Rezygnacja z automatycznych blokad
Istota ograniczenia
Wiele ERP poświęca ścisłe blokady na rzecz responsywności interfejsu. W rezultacie platforma nie gwarantuje atomowości operacji biznesowej: kilku użytkowników lub procesów może zmieniać powiązane dane bez jednego punktu synchronizacji.
Gwarancja, której nie ma
Brak formalnego stwierdzenia: „w momencie X dane były spójne i nie mogły zostać zmienione równolegle”.
Symptom eksploatacyjny: rzadkie, nieregularne błędy, których nie da się stabilnie odtworzyć; wyjaśnienie sprowadza się do „równoczesnych działań”.
Jak sprawdzić: poprosić o pokazanie, co dzieje się przy równoczesnej zmianie tego samego obiektu przez kilku użytkowników i gdzie dokładnie jest rejestrowany konflikt.
4.2 Rezygnacja z jednolitego przepływu wykonania
Istota ograniczenia
Logika biznesowa jest rozproszona między klientem, serwerem, procesami w tle i integracjami. W systemie nie ma jednego deterministycznego przepływu wykonania.
Gwarancja, której nie ma
Nie da się formalnie odpowiedzieć: „jakie kontrole i obliczenia zostały zastosowane dokładnie do tej operacji”.
Symptom eksploatacyjny: użytkownik widzi jedno zachowanie, a finalny stan danych jest inny; pojawiają się „niezrozumiałe” odmowy i rollbacki.
Jak sprawdzić: poprosić o pokazanie, które kontrole są gwarantowanie wykonywane na serwerze, które — tylko w UI, i co się stanie przy obejściu interfejsu.
4.3 Rezygnacja z synchroniczności i jednoznacznego commit point
Istota ograniczenia
Dla szybkości operacje wykonuje się asynchronicznie: obliczenia, integracje, przeliczenia wskaźników. Użytkownik dostaje potwierdzenie, ale operacja biznesowa nie jest jeszcze logicznie zakończona.
Gwarancja, której nie ma
Brak jednoznacznego commit point — momentu, po którym można stwierdzić, że operacja jest zakończona, a jej efekt ostateczny.
Symptom eksploatacyjny: duplikaty operacji, „odroczone błędy”, ręczne kontrole i ponowne działania użytkowników.
Jak sprawdzić: zapytać, w którym momencie operacja jest uznawana za zakończoną, jakie działania wykonują się po potwierdzeniu i czy możliwe są rollbacki „wstecz”.
5. Formularze i prezentacja danych
Ten rozdział dotyczy tego, jak użytkownik wchodzi w interakcję z modelem danych i jakie konsekwencje architektoniczne powstają, gdy interfejs przestaje być bezpośrednim odbiciem logiki biznesowej. Tutaj błędy wyglądają jak „czynnik ludzki”, ale ich przyczyna tkwi w budowie systemu.
5.1 Formularze jako osobna warstwa logiki
Jak to zwykle bywa zrealizowane w standardowych ERP
Formularze w ERP rzadko są tylko prezentacją danych. Dodaje się do nich logikę: walidacje, obliczenia, ukrywanie pól, autouzupełnianie, reakcje na zdarzenia. Z czasem formularz staje się kolejnym miejscem, gdzie „mieszkają” reguły biznesowe.
1C
Znaczna część logiki jest realizowana w modułach formularzy: kontrole przy zmianie pól, przeliczenia, zarządzanie dostępnością. Ta logika nie zawsze jest zdublowana na serwerze.
SAP
Logika UI jest rozproszona między scenariuszami ekranów, kontrolami backend i regułami procesowymi.
Microsoft Dynamics
Skrypty klienckie i reguły biznesowe w interfejsie uzupełniają serwerowe wtyczki, tworząc kilka poziomów zachowania.
Odoo
Formularze są względnie proste, ale przy kastomizacji logika zaczyna dublować backend.
Symptom eksploatacyjny: zachowanie zależy od tego, jak dokładnie użytkownik wprowadza dane, przez jaki formularz lub scenariusz.
Jak sprawdzić: poprosić o pokazanie, które kontrole są wykonywane tylko w formularzu i co się stanie przy imporcie danych z pominięciem UI.
5.2 Odejście od WYSIWYG: rozdzielenie interfejsu na zapis i odczyt
Jak to zwykle bywa zrealizowane w standardowych ERP
Tryby podglądu i edycji są realizowane inaczej: inne zdarzenia, inne walidacje, inne obliczenia. Użytkownik widzi jedno, a system zapisuje drugie.
1C
Różne tryby formularza i zdarzenia prowadzą do rozjazdów między prezentacją a zapisem.
SAP
Wieloetapowe ekrany i statusy utrudniają zrozumienie, co dokładnie zostało utrwalone.
Microsoft Dynamics
Część pól jest wyliczana lub aktualizowana asynchronicznie, co tworzy efekt „wizualnego utrwalenia”.
Odoo
Bazowo WYSIWYG jest zachowany, ale przy komplikacji formularzy pojawiają się rozjazdy.
Symptom eksploatacyjny: użytkownik jest pewien, że dane są zapisane, ale system później je zmienia lub cofa.
Jak sprawdzić: poprosić o pokazanie, czy wartość pola na ekranie pokrywa się z tym, co faktycznie zostało zapisane w bazie w momencie zapisu.
5.3 Brak możliwości odwoływania się na listach do atrybutów formularzy i bieżących wartości innych list
Jak to zwykle bywa zrealizowane w standardowych ERP
Listy i formularze żyją w różnych kontekstach. Logika listy jest ograniczona do dostępnych pól danych, a bieżące wartości formularza lub innych list nie są bezpośrednio dostępne.
Skutek
Reguły kontekstowe (zależne od bieżącego wyboru, stanu formularza, powiązanych list) realizuje się obejściami albo dubluje.
Symptom eksploatacyjny: interfejs nie potrafi poprawnie odzwierciedlić realnych ograniczeń i reguł, pojawiają się „niezrozumiałe” zakazy.
Jak sprawdzić: poprosić o realizację reguły zależnej od stanu kilku list, bez dodatkowego kodu i obejść.
5.4 Nadmiarowe poziomy abstrakcji w UI
Jak to zwykle bywa zrealizowane w standardowych ERP
Dla uniwersalności i rozszerzalności interfejs buduje się przez kilka poziomów: metadane → formularze → konfiguracje → scenariusze. Każdy poziom dodaje elastyczność, ale zmniejsza przejrzystość.
Symptom eksploatacyjny: prosta zmiana zachowania formularza wymaga zrozumienia kilku poziomów abstrakcji i dotyka więcej miejsc, niż się spodziewasz.
Jak sprawdzić: poprosić o pokazanie, przez jakie warstwy przechodzi zmiana jednej reguły UI i gdzie dokładnie jest utrwalona.
6. Architektura języka i rozszerzalność
Ten rozdział dotyczy tego, na ile ERP jest w ogóle platformą inżynierską, a nie zestawem narzędzi do konfiguracji. Tutaj rozstrzyga się, czy system da się rozwijać jako bazę kodu z przewidywalnymi zmianami, czy nieuchronnie zamienia się w artefakt wdrożenia, zależny od konkretnych ludzi i ustaleń.
6.1 Brak dziedziczenia i polimorfizmu
Jak to zwykle bywa zrealizowane w standardowych ERP
ERP prawie zawsze operuje rodzinami encji: umowy, zamówienia, usługi, projekty. Jednak w wielu platformach brakuje pełnego modelu dziedziczenia encji biznesowych. W efekcie podobna logika jest kopiowana, a różnice realizuje się przez warunki.
1C
Dziedziczenie jest ograniczone. Typowe podejście — kopiowanie obiektów i późniejsze modyfikacje.
SAP
Możliwości są szersze, ale złożoność modelu prowadzi do tego, że logika encji bazowych i pochodnych rozchodzi się po rozszerzeniach.
Microsoft Dynamics
Rozszerzanie encji jest możliwe, ale polimorfizm częściej się imituje wtyczkami i warunkami.
Odoo
Dziedziczenie jest mocną stroną, ale przy aktywnych override’ach ważne jest kontrolowanie punktów zmiany zachowania.
Symptom eksploatacyjny: reguły się dublują, zmiany w „bazowej logice” wymagają ręcznej synchronizacji.
6.2 Brak jawnego typowania w kodzie
Jak to zwykle bywa zrealizowane w standardowych ERP
Jawne typowanie często jest nieobecne albo osłabione dla elastyczności. Błędy ujawniają się w runtime, a analiza logiki jest możliwa głównie przez doświadczenie.
1C
Słabe typowanie utrudnia analizę dużych konfiguracji i bezpieczny refactoring.
SAP
Typowanie jest mocniejsze, ale ceną jest wysoka złożoność i wymagania wobec kompetencji zespołu.
Microsoft Dynamics
Typy są, ale przy mieszaniu low-code i wtyczek kontrakt zachowania się rozmywa.
Odoo
Dynamiczny Python wymaga ścisłych konwencji, inaczej błędy wychodzą późno.
Symptom eksploatacyjny: zmiany są weryfikowane „na oko”, rośnie liczba błędów regresyjnych.
6.3 Brak modułowości
Jak to zwykle bywa zrealizowane w standardowych ERP
Formalny podział na moduły nie gwarantuje izolacji architektonicznej. Zależności stają się niejawne, a zmiana jednego bloku dotyka sąsiednich.
1C
Moduły wspólne rosną, granice odpowiedzialności się rozmywają.
SAP
Modułowość istnieje na poziomie procesów, ale konfiguracja i rozszerzenia rozmywają granice.
Microsoft Dynamics
Kompozycyjność działa do pewnej skali, potem lokalność zmian zanika.
Odoo
Modułowość jest z natury mocna, ale słaba kontrola zależności zamienia aktualizacje w projekt.
Symptom eksploatacyjny: „małe” zmiany przestają być małe, rośnie zakres regresji.
6.4 Stawianie na programowanie wizualne
Jak to zwykle bywa zrealizowane w standardowych ERP
Low-code i schematy wizualne przyspieszają start, ale słabo się skalują jako nośnik logiki biznesowej. Zależności trudno analizować, reguły trudno testować.
1C
Mechanizmy wizualne mieszają się z kodem, logika się rozprasza.
SAP
Workflow i konfiguracje są mocne, ale śledzenie „dlaczego zadziałało” staje się nietrywialne.
Microsoft Dynamics
Flow są wygodne, ale wraz ze wzrostem zamieniają się w trudny do zarządzania zestaw scenariuszy.
Odoo
Narzędzia wizualne są mniej agresywne, ale przenoszenie logiki z kodu do ustawień daje te same efekty.
Symptom eksploatacyjny: reguły istnieją jako „schematy”, a nie jako jeden model, utrzymanie zależy od konkretnych osób.
7. Model fizyczny i otwartość systemu
Ten rozdział dotyczy tego, na ile ERP jest przejrzyste jako system inżynierski. Nawet przy schludnej logice, dobrych formularzach i dyscyplinie wytwarzania zamknięty lub sztywny fizyczny model danych gwałtownie podnosi koszt zmian, diagnostyki i integracji.
Tu pojawiają się ograniczenia, których nie da się „obejść ładnym kodem” — wynikają z samej konstrukcji platformy.
7.1 Zamknięty model fizyczny danych
Jak to zwykle bywa zrealizowane w standardowych ERP
W wielu ERP fizyczny model danych jest albo ukryty, albo dostępny tylko przez abstrakcje platformy. Programista pracuje z modelem logicznym, nie mając pełnej kontroli nad tym, jak dane są realnie przechowywane i powiązane.
1C
Fizyczna struktura bazy jest generowana przez platformę. Bezpośrednia analiza i optymalizacja są możliwe, ale nie są traktowane jako standardowy sposób pracy.
SAP
Model danych jest formalnie otwarty, ale ekstremalnie złożony. Bez głębokiej ekspertyzy ingerencja jest ryzykowna.
Microsoft Dynamics
W modelu SaaS fizyczna baza jest ukryta. Praca odbywa się przez Dataverse, API i witryny.
Odoo
Model fizyczny jest dostępny, ale moduły i kastomizacja szybko komplikują realny obraz.
Symptom eksploatacyjny: diagnostyka problemów i analiza skutków zmian wymagają specjalistycznej wiedzy lub dostępu, który ma nie zespół, a dostawca albo integrator.
Jak sprawdzić: zapytać, czy można bez obejść przeanalizować realne tabele, indeksy i relacje dla konkretnego wyliczenia.
7.2 Statyczny model fizyczny danych
Jak to zwykle bywa zrealizowane w standardowych ERP
Model fizyczny jest zoptymalizowany pod typowe scenariusze. Zmiana struktury danych albo jest niemożliwa, albo wymaga złożonych migracji i uzgodnień.
1C
Zmiany struktury są możliwe, ale przy dużych wolumenach danych stają się osobnymi projektami.
SAP
Zmiany są dopuszczalne, ale dotykają wielu zależnych obiektów i wymagają ścisłej procedury.
Microsoft Dynamics
Rozszerzanie schematu jest możliwe, ale w ramach ograniczeń platformy SaaS.
Odoo
Model można zmieniać, ale wpływa to na aktualizowalność i kompatybilność modułów.
Symptom eksploatacyjny: zmiana modelu danych jest odkładana, kumulują się „tymczasowe” rozwiązania i dodatkowe tabele.
Jak sprawdzić: poprosić o pokazanie, jak dodaje się nowy wymiar lub encję z uwzględnieniem danych historycznych.
7.3 Zamknięte źródła i licencje
Jak to zwykle bywa zrealizowane w standardowych ERP
Kod źródłowy i wewnętrzne mechanizmy są częściowo lub całkowicie zamknięte. Możliwości analizy i zmian są ograniczone warunkami licencji.
1C
Platforma jest zamknięta, zachowania wielu mechanizmów nie da się zbadać bezpośrednio.
SAP
Kod jest dostępny w ograniczonym zakresie, zmiany wymagają przestrzegania ścisłych zasad.
Microsoft Dynamics
Model SaaS wzmacnia zależność od dostawcy i ogranicza kontrolę niskopoziomową.
Odoo
Open-source rdzeń obniża barierę, ale moduły komercyjne i ekosystem mogą tworzyć nowy lock-in.
Symptom eksploatacyjny: zespół nie może samodzielnie zrozumieć przyczyn zachowania systemu i musi polegać na wsparciu lub partnerach.
Jak sprawdzić: zapytać, które części systemu można analizować, debugować i zmieniać bez udziału dostawcy.
8. Ograniczenia operacyjne i kulturowe
Ten rozdział dotyczy ograniczeń, które formalnie nie są „architekturą”, ale w praktyce decydują, jaką architekturę system może mieć. Licencjonowanie, zasady użycia i postawa dostawcy bezpośrednio wpływają na testowanie, automatyzację, tempo zmian i zależność od uczestników zewnętrznych.
8.1 Licencjonowanie i branding nieprzyjazne dla programistów
Jak to zwykle bywa zrealizowane w standardowych ERP
Licencjonowanie często jest zbudowane wokół użytkowników, środowisk i osobnych komponentów. To ogranicza liczbę środowisk testowych, komplikuje CI/CD i czyni eksperymenty drogimi. Branding i sztywne zasady użycia podkreślają zależność od dostawcy.
1C
Licencje na użytkowników i serwery ograniczają liczbę pełnowartościowych środowisk. Często istnieje jedno „żywe” środowisko, na którym testuje się zmiany.
SAP
Koszt licencji i środowisk sprawia, że każde dodatkowe środowisko wymaga uzgodnień. Automatyzacja testów jest ograniczona.
Microsoft Dynamics
Licencjonowanie SaaS ogranicza dostęp do mechanizmów niskopoziomowych i utrudnia izolowanie eksperymentów.
Odoo
Open-source obniża barierę wejścia, ale moduły komercyjne i usługi mogą narzucać podobne ograniczenia.
Symptom eksploatacyjny: mniej środowisk testowych, poprawki są sprawdzane „na produkcji”, wdrożenia wychodzą rzadziej i ostrożniej, niż potrzebuje biznes.
Jak sprawdzić: zapytać, ile pełnych środowisk można utrzymywać bez dodatkowych licencji i które z nich nadają się do testów automatycznych.
8.2 Krytyczna wada jako suma decyzji architektonicznych
Żadne z opisanych ograniczeń nie jest krytyczne samo w sobie. Problem pojawia się, gdy nakładają się na siebie.
- reguły są rozmazane po obiektach, formularzach i zapytaniach;
- warstwa zapytań nie jest źródłem prawdy;
- brak jasnych gwarancji przepływu wykonania;
- model danych jest zamknięty albo mało elastyczny;
- eksperymenty i testowanie są drogie.
W takim systemie każda zmiana — nawet logicznie prosta — zamienia się w projekt: z analizą skutków, ręczną regresją i zależnością od konkretnych osób.
Symptom eksploatacyjny: zespół unika zmian, biznes przestaje zadawać pytania „czy da się inaczej”, ERP utrwala obecny sposób pracy zamiast wspierać rozwój.
9. Jak sprawdzać ograniczenia architektoniczne na demo i pilocie
Ograniczenia architektoniczne prawie nigdy nie są widoczne w prezentacjach i typowych scenariuszach. Na demo pokazuje się „co system potrafi”, a nie „ile kosztuje zmiana reguł”.
Jedyny wiarygodny sposób — sprawdzać ERP nie po funkcjach, lecz po reakcji na zmiany.
9.1 Trzy zmiany, które warto poprosić o pokazanie
Do weryfikacji wystarczą trzy scenariusze. Ważne nie jest to, że „wyszło”, lecz jak dokładnie to zrobiono.
-
Zmiana reguły z wyjątkami
Na przykład: rabat lub limit, zależne od kilku warunków (typ klienta, obrót, ryzyko, historia). -
Zmiana procesu
Akceptacja nie „po stanowisku”, lecz po danych: kwota, marża, ryzyko, odchylenie od normy. -
Dodanie nowego typu encji
Nowa umowa, usługa lub model rozliczeń, który ma: uczestniczyć w transakcjach, trafiać do raportów i podlegać tym samym regułom kontroli.
Te scenariusze dotykają: modelu danych, obliczeń, formularzy, zapytań, kontroli i integracji — właśnie tam ujawniają się ograniczenia.
9.2 Na co patrzeć podczas demonstracji
-
Ile warstw trzeba było zmienić
Jeden moduł albo formularz — to zmiana reguły. Kilka warstw — to zmiana systemu. -
Gdzie dokładnie opisana jest reguła
Czy da się wskazać jedno miejsce, czy logika jest rozproszona między kodem, formularzami i zapytaniami. -
Jak wyjaśnia się wpływ na raporty
Czy jest jasna odpowiedź, które wskaźniki się zmienią i dlaczego. -
Czy jest weryfikacja regresji
Test, scenariusz albo chociaż formalna checklista, a nie „potem zobaczymy”.
9.3 Typowe „czerwone flagi”
- „Lepiej zrobić to po wdrożeniu”
- „W realnym projekcie zrobilibyśmy inaczej”
- „Tu jest dużo niuansów, na demo się nie da”
- „Da się, ale potrzebny jest osobny projekt”
- „Trzeba sprawdzić, jak to wpłynie na raporty”
Te frazy nie oznaczają, że system jest zły. Oznaczają, że koszt zmian jest jeszcze nieznany i niekontrolowany.
9.4 Co uznać za dobry wynik pilota
Dobry wynik — nie „wszystko zrobiliśmy”, lecz:
- reguła jest opisana w jednym miejscu albo jednym typie mechanizmu;
- widać, jakie dane i obliczenia obejmuje;
- wiadomo, jak sprawdzić regresję;
- zmiana nie wymaga „tajemnej wiedzy” jednej osoby.
Jeśli po pilocie da się odpowiedzieć na pytanie „ile kosztuje kolejna zmiana”, to znaczy, że architekturą da się zarządzać.
10. Podsumowanie
Ta analiza nie jest o „dobrych” i „złych” ERP. 1C, SAP, Microsoft Dynamics i Odoo z powodzeniem działają w tysiącach firm. Problemy zaczynają się nie na etapie wdrożenia, lecz wtedy, gdy biznes zaczyna zmieniać reguły.
Ograniczenia architektoniczne rzadko wyglądają krytycznie pojedynczo. Kumulują się: przez dodatkowe walidacje, punktowe modyfikacje, wyjątki i tymczasowe obejścia. Z czasem to one definiują realny koszt zmian.
Kluczowy wniosek: drogie stają się nie złożone reguły, lecz słabo sformalizowane. Gdy logika jest rozproszona między obiektami, formularzami, zapytaniami, scenariuszami wizualnymi i integracjami, system przestaje być zarządzalny jako spójna całość.
W takiej architekturze powstaje praktyczny lock-in — nie tyle od dostawcy, co od konkretnych ludzi, którzy „pamiętają, jak to działa”.
W kontekście ERP rolę AI często rozumie się zbyt powierzchownie — jako narzędzie podpowiedzi, generowania kodu albo przyspieszania pojedynczych zadań. Ale jego realny efekt architektoniczny ujawnia się gdzie indziej.
AI staje się strategicznym aktywem wtedy, gdy platforma pozwala uczyć model na własnej logice biznesowej, a nie używać go wyłącznie jako zewnętrznego pomocnika.
Jeśli język i model danych ERP są wystarczająco uporządkowane, zwarte i jednoznaczne, firma może nauczyć AI na swoim kodzie i regułach — a potem rozwijać system siłami własnego zespołu, bez stałej zależności od dostawcy lub wąskich specjalistów.
Do tego platforma musi mieć kilka krytycznych właściwości:
- Wysoka gęstość znaczenia — reguły biznesowe wyraża się krótko, bez nadmiarowego kodu.
- Deklaratywność — reguły opisują „co ma być”, a nie „jak dokładnie wykonać”.
- Jeden model — dane, reguły i obliczenia opisuje się w jednym formalizmie.
- Brak „magii” — minimalna liczba niejawnych handlerów, zdarzeń i wyjątków.
W takim systemie AI uczy się szybciej i dokładniej: nie musi analizować tysięcy linii kodu proceduralnego, rozproszonych formularzy, tekstowych zapytań i scenariuszy wizualnych. Model widzi strukturę reguł, a nie historię wdrożenia.
Praktyczna konsekwencja tego podejścia — gwałtowny spadek „kosztu posiadania wiedzy”:
- mniej tokenów i mocy obliczeniowej do trenowania i utrzymania modeli,
- wyższa dokładność analizy zmian i skutków,
- mniejsza zależność od konkretnych osób i wykonawców,
- możliwość utrzymania i rozwoju ERP przez wewnętrzny zespół.
W przeciwnym przypadku — gdy logika biznesowa jest rozmazana po obiektach, formularzach, tekstowych zapytaniach, schematach wizualnych i historycznych wyjątkach — AI nie staje się aktywem strategicznym. Jedynie przyspiesza pracę z chaotycznym systemem, ale nie obniża jego kosztu.
Architektura zrozumiała nie tylko dla ludzi, ale i dla maszyn, to nie „moda” ani marketing. To bezpośrednia droga do obniżenia vendor lock-in i do tego, by ERP rozwijało się razem z biznesem, a nie wymagało za każdym razem zewnętrznej interwencji.
Źródła i linki
Podobne artykuły
Jeśli ważne są praktyczne konsekwencje architektury ERP i ograniczenie zależności od wykonawców — oto kolejne materiały na DevLab Blog: