Wprowadzenie
Od czasu do czasu używam AI do wykonania “przeglądów literatury i opinii”. AI “uczone” na wszelkich dostępnych treściach, całkiem nieźle sobie radzi a podsumowaniami w rodzaju “powszechnej i dostępnej opinii”. Ty razem zadałem pytanie:
Mamy dwa warianty realizacji projektu IT:
- firma zleca napisanie dedykowanej aplikacji dla siebie od razu koderom (Sofware House),
- firma zatrudnia projektanta, a potem zatrudnia SH (koderów) do implementacji.
Porównaj czas i koszty.
Odpowiedź (Google AI mode)
To zestawienie dwóch najczęstszych podejść do budowy software’u. W skrócie: pierwszy model jest szybszy na starcie, ale ryzykowny; drugi wymaga inwestycji na początku, by oszczędzić fortunę później.
Oto konkretne porównanie:
Scenariusz 1: Firma zleca pracę bezpośrednio koderom (bez projektanta)
To podejście typu „budujemy w trakcie projektowania”.
Czas
- Start: Bardzo szybki. Kodowanie zaczyna się niemal od razu.
- Realizacja: Często się przeciąga. Brak makiety i specyfikacji sprawia, że w połowie prac okazuje się, że „to nie tak miało działać”. Deweloperzy muszą kasować kod i pisać go od nowa (tzw. refaktoryzacja).
Koszty:
- Bezpośrednie: Wydają się niższe, bo nie płacisz za etap designu.
- Ukryte: Bardzo wysokie. Godzina pracy programisty jest zazwyczaj droższa niż projektanta. Jeśli programista spędzi 40 godzin na kodowaniu funkcji, która zostanie odrzucona, tracisz dużo pieniędzy.
- Ryzyko: Aplikacja może być niefunkcjonalna lub nieintuicyjna dla pracowników, co generuje koszty wdrożenia i szkoleń.
Scenariusz 2: Najpierw projektant, potem koderzy
To podejście typu „najpierw plan, potem budowa”.
Czas
- Start: Wolniejszy. Przez pierwsze tygodnie/miesiące nie powstaje ani jedna linijka kodu.
- Realizacja: Znacznie szybsza i płynniejsza. Programiści dostają gotową „instrukcję obsługi” (makietę i specyfikację). Wiedzą dokładnie, co mają zbudować, więc rzadziej dochodzi do poprawek.
Koszty
- Bezpośrednie: Wyższy koszt początkowy (wynagrodzenie projektanta).
- Długofalowe: Niższe. Poprawienie błędu w logice na etapie makiety kosztuje „zero”. Poprawienie tego samego błędu w działającym kodzie kosztuje tysiące złotych.
- Zaleta: Masz prototyp, który możesz przetestować na pracownikach, zanim wydasz złotówkę na programistów.
Podsumowanie finansowe
Werdykt: Jeśli aplikacja jest bardzo prosta (np. prosty formularz), można iść prosto do koderów. Przy dedykowanym systemie dla firmy, Scenariusz 2 (z projektantem) niemal zawsze wychodzi taniej i szybciej w ostatecznym rozrachunku.
(koniec odpowiedzi AI)
(powyższy wpis opublikowany także na LinkedIn)
Krótkie podsumowanie
Wygląda na to, że nic się nie zmieniło od dekad. Od ponad 20 lat w IT królują metody agile, jednak wnioski są jednoznaczne i takie same od wielu lat: proste projekty można realizować “z marszu”, jednak każdy inny wymaga uporządkowania, albo będzie klęską.
Poniżej fragment publikacji ze stycznia 2026, której autor: Alistair Cockburn, jest także sygnatariuszem słynnego Agile Manifesto, jest to tak zwany V-model (tu Validation V):
Przedstawiono dwa warianty realizacji projektu IT:
– firma zleca napisanie dedykowanej aplikacji dla siebie od razu koderom (Sofware House),
– firma zatrudnia projektanta, a potem zatrudnia SH (koderów) do implementacji.
Ale system to nie kilkadziesiąt tysięcy linii ale implementacja prawa lokalnego
ale też miedzy narodowego, dostawy unijne, dostawa do kraju o specyficznych wymaganiach.
To nie jest wiedza którą posiada programista to coś więcej.
I właśnie dlatego bardzo wiele projektów ERP kończy się problemami, gdy zarząd lub SH redukuje problem do:
> „napisania aplikacji”.
ERP nie jest przede wszystkim problemem programistycznym.
To jest:
* problem prawny,
* podatkowy,
* procesowy,
* logistyczny,
* organizacyjny,
* audytowy,
* międzynarodowy,
* a dopiero na końcu techniczny.
Programista implementuje reguły.
Ale ktoś musi:
* te reguły znać,
* poprawnie zinterpretować,
* przewidzieć wyjątki,
* rozumieć skutki biznesowe i prawne.
I tu pojawia się fundamentalna różnica między:
# „software engineering”
a
# „enterprise business engineering”.
# ERP implementuje rzeczywistość regulacyjną
Przykładowo zwykła faktura może wymagać uwzględnienia:
* VAT krajowy,
* WDT,
* WNT,
* eksport poza UE,
* odwrotne obciążenie,
* OSS/IOSS,
* split payment,
* KSeF,
* JPK,
* SAD,
* INCOTERMS,
* kursy walut,
* embargo,
* sankcje,
* podwójne opodatkowanie,
* compliance branżowy.
To nie jest „formularz”.
To jest:
# zakodowana wiedza cywilizacyjna państw i organizacji międzynarodowych.
# Dlatego ERP jest bliżej systemów eksperckich niż zwykłych aplikacji
Dobry ERP zawiera:
* tysiące reguł decyzyjnych,
* zależności czasowych,
* wyjątków prawnych,
* mechanizmów walidacyjnych,
* polityk bezpieczeństwa,
* ścieżek audytowych.
W praktyce:
* część tej wiedzy pochodzi od prawników,
* część od księgowych,
* część od logistyków,
* część od audytorów,
* część od praktyków biznesowych.
Programista sam z siebie zwykle tego nie posiada.
# Dlatego „programista ERP” to mylące pojęcie
Najlepsi specjaliści ERP to zwykle hybrydy:
* biznes + technologia,
* prawo + procesy,
* księgowość + integracja,
* logistyka + architektura danych.
I dlatego doświadczeni konsultanci ERP są tak drodzy.
Bo oni:
* rozumieją konsekwencje biznesowe,
* a nie tylko składnię języka.
# Największe ryzyko projektów ERP
To nie błędy kodu.
Tylko:
# błędna implementacja logiki biznesowej.
Bo kod może działać perfekcyjnie technicznie…
…a system:
* źle nalicza VAT,
* błędnie klasyfikuje eksport,
* narusza compliance,
* generuje błędne JPK,
* łamie lokalne regulacje,
* błędnie interpretuje status magazynowy,
* nie zachowuje ścieżki audytowej.
I wtedy problem nie jest „informatyczny”.
Tylko:
* podatkowy,
* prawny,
* finansowy,
* czasem karny skarbowy.
# Dlatego dojrzałe ERP rozwijają:
* kancelarie prawne,
* eksperci podatkowi,
* specjaliści compliance,
* księgowi,
* audytorzy,
* eksperci branżowi,
* architekci procesów,
* dopiero potem developerzy.
# Tu pojawia się ogromna przewaga gotowych ERP
Bo producent:
* zbiera wiedzę z tysięcy wdrożeń,
* aktualizuje przepisy,
* analizuje orzecznictwo,
* wdraża zmiany prawne,
* utrzymuje compliance.
Firma kupuje więc:
* nie tylko software,
* ale ogromny „silnik wiedzy regulacyjnej”.
# Dlatego bardzo niebezpieczna jest narracja:
„Napiszemy sobie własny ERP.”
Przy małym zakresie:
* możliwe.
Ale przy:
* produkcji,
* międzynarodowej logistyce,
* podatkach,
* KSeF,
* compliance,
* wielospółkowości,
* audytach,
* grupach kapitałowych,
to zaczyna przypominać:
# budowę własnego systemu operacyjnego.
Teoretycznie możliwe.
Praktycznie:
* bardzo kosztowne,
* wieloletnie,
* obarczone ogromnym ryzykiem.
# Dlatego najbardziej racjonalny model zwykle wygląda tak:
## 1. Core ERP
Kupujemy „wiedzę standardową”.
## 2. Rozszerzenia
Budujemy:
* przewagę konkurencyjną,
* automatyzację,
* AI,
* optymalizację,
* workflow specyficzny dla firmy.
# I tu pojawia się bardzo nowoczesny kierunek
ERP jako:
# „regulated knowledge platform”.
Czyli:
* system nie jest już tylko bazą danych,
* ale dynamicznym nośnikiem wiedzy prawno-biznesowej.
A AI zaczyna pełnić rolę:
* interpretatora,
* analityka wyjątków,
* asystenta compliance,
* generatora workflow,
* systemu rekomendacji decyzji.
„To nie jest wiedza programisty.”
To jest wiedza:
* organizacyjna,
* prawna,
* ekonomiczna,
* procesowa,
* międzynarodowa,
* branżowa.
A kod jest tylko mechanizmem wykonawczym tej wiedzy.
Pozdrawiam
Antoni Mączka
Owszem, z ta uwagą, że jako ludzie i firmy komunikujemy sie dokumentami, jednym z nich jest np. faktura a split payment to nie faktury a przelewy i rachunkowość w banku. Co do zasady nie przeciążamy treścią pojedynczych dokumentów. Dlatego największa “sztuka” w inżynierii oprogramowanie to zaprojektowanie dla problemu zestawu dokumentów oraz logiki ich tworzenia, walidacji i przepływu.