Zarząd średniej firmy produkcyjnej ma za sobą trzy prezentacje. Pierwszy dostawca pokazuje znany system ERP i obiecuje, że „wszystko da się skonfigurować”. Drugi, software house, przekonuje, że firma o tak nietypowym procesie produkcji powinna mieć własny system, szyty na miarę, bez licencji i bez kompromisów. Trzeci proponuje „rozszerzenie” obecnego systemu: dopisanie brakujących funkcji do oprogramowania, które firma i tak już ma. Każda oferta brzmi rozsądnie, każda ma inną cenę i każda zakłada, że decyzja dotyczy całego systemu naraz.
Dyrektor finansowy zadaje pytanie, na które żaden z dostawców nie odpowiada wprost: co z tego będzie działać za siedem lat, kiedy zmienią się przepisy, wersje i ludzie, którzy to budowali?
Ten artykuł jest dla prezesów i dyrektorów finansowych średnich firm, którzy stoją przed decyzją o własnym ERP. Broni stanowiska, z którym nie zgodzi się ani część producentów oprogramowania, ani część software house’ów: rdzeń księgowo-podatkowy kupuj i przyjmuj jego standard procesu, nawet jeśli oznacza to zmianę własnych nawyków; buduj tylko tam, gdzie proces tworzy przewagę, i buduj obok ERP, nie w jego środku. Najdroższym wariantem nie jest ani budowa, ani zakup, tylko modyfikowanie wnętrza gotowego systemu, które w ofertach wygląda na najtańsze.
Dlaczego pytanie „budować czy kupić ERP” prowadzi do złej decyzji?
Bo zakłada, że ERP jest jedną rzeczą, a decyzja zapada raz. W rzeczywistości system ERP w średniej firmie to kilkanaście procesów o zupełnie różnym charakterze: księga główna, rozrachunki, VAT i e-faktury, płace, środki trwałe, zakupy, magazyn, planowanie produkcji, sprzedaż, wycena, logistyka. Część z nich jest identyczna w każdej firmie w kraju i zmienia się wtedy, gdy zmieniają się przepisy. Część jest tym, co odróżnia firmę od konkurencji. Jedna decyzja „budujemy” albo „kupujemy” dla całości oznacza, że w jednej z tych grup popełnia się błąd.
Skala ryzyka jest dobrze opisana. Gartner w prognozie z 2024 roku przewiduje, że do 2027 roku ponad 70% niedawno wdrożonych inicjatyw ERP nie osiągnie w pełni pierwotnych celów biznesowych, a nawet co czwarta zakończy się porażką. To nie są projekty prowadzone przez amatorów. To projekty, w których zbyt często decyzję o architekturze podjęto dla całego systemu, zanim ktokolwiek rozłożył go na procesy.
Pytanie „budować czy kupić” ma też ukrytą trzecią odpowiedź, którą dostawcy nazywają „rozszerzaniem”. Brzmi jak bezpieczny kompromis: kupujemy standard, dopisujemy to, czego brakuje. W praktyce „rozszerzać” znaczy cztery różne rzeczy, od zmiany ustawień po przepisywanie kodu producenta, a różnica w koszcie i ryzyku między nimi jest większa niż między budową a zakupem. Dlatego zamiast jednego pytania warto zadać trzy: które procesy kupić i przyjąć ich standard, które rozszerzyć i w jaki sposób, a które zbudować samemu.
Podobną logikę opisaliśmy wcześniej dla systemów sprzedażowych w tekście o tym, kiedy budowa własnego CRM się opłaca. ERP różni się jednak od CRM w jednym istotnym punkcie: jest systemem, w którym powstają księgi rachunkowe i deklaracje podatkowe. To zmienia rachunek bardziej, niż się wydaje.
Które części ERP są towarem, a które mogą być przewagą?
Dobrym punktem wyjścia jest proste rozróżnienie, które stosują architekci systemów przedsiębiorstwa: procesy, w których firma musi być poprawna, i procesy, w których może być lepsza od innych. W pierwszej grupie liczy się zgodność z przepisami, kompletność i audytowalność. W drugiej liczy się szybkość, elastyczność i to, co klient odczuwa jako różnicę.
Do pierwszej grupy należą niemal zawsze: księga główna i plan kont, rozrachunki z kontrahentami, rozliczenia VAT i obieg e-faktur, płace i kadry, środki trwałe, konsolidacja, raportowanie dla urzędu skarbowego i biegłego rewidenta. Żaden klient nie wybiera dostawcy dlatego, że ten wyjątkowo elegancko księguje faktury kosztowe. Te procesy są towarem: muszą działać, muszą być zgodne z prawem i nie powinny kosztować więcej niż to konieczne.
Do drugiej grupy należy to, co jest specyficzne dla modelu biznesowego. W firmie produkcyjnej może to być planowanie produkcji dla krótkich serii na zamówienie, w dystrybucji — wycena zależna od wielu czynników i dynamiczne rabaty, w logistyce — optymalizacja tras i okien załadunku, w usługach — sposób, w jaki klient zamawia, śledzi i reklamuje. To tutaj nietypowy proces może być powodem, dla którego klienci wybierają właśnie tę firmę.
Między tymi grupami jest pas środkowy: zakupy, magazyn, podstawowa sprzedaż, rozliczanie projektów. W większości firm to też towar, ale w niektórych staje się przewagą. Hurtownia, która obiecuje dostawę w ciągu czterech godzin, może mieć w gospodarce magazynowej coś, czego konkurencja nie ma. Firma, która sprzedaje to samo co inni, ale taniej dzięki dyscyplinie zakupowej, może mieć przewagę w zakupach.
Najczęstszy błąd polega na tym, że firma uznaje za przewagę wszystko, co robi inaczej niż standard. „Robimy to po swojemu” nie znaczy jeszcze „robimy to lepiej”. Wiele odrębności procesowych to po prostu nawyki, które powstały w czasach poprzedniego systemu i przetrwały, bo nikt ich nie zakwestionował. Rzetelny przegląd procesów zwykle pokazuje, że prawdziwie wyróżniających procesów jest kilka, a nie kilkadziesiąt.
Dlaczego księgi głównej i podatków nie warto budować samemu?
Bo koszt własnego rdzenia księgowego nie kończy się w dniu uruchomienia. Prawdziwym kosztem jest utrzymanie zgodności z przepisami, które zmieniają się co roku, czasem kilka razy w roku, i za które odpowiada firma, a nie programista.
Przykład z ostatnich miesięcy jest najlepszą ilustracją. Od 1 lutego 2026 roku faktury ustrukturyzowane w Krajowym Systemie e-Faktur muszą wystawiać podatnicy, których sprzedaż w 2024 roku przekroczyła 200 mln zł z podatkiem, a od 1 kwietnia 2026 roku pozostali, z odroczeniem do końca roku dla najmniejszych, którzy wystawiają faktury na niewielkie kwoty. Firma z gotowym systemem dostała integrację z KSeF w aktualizacji producenta i musiała ją wdrożyć, przetestować i przeszkolić ludzi. Firma z własnym systemem musiała dodatkowo zaprojektować i zbudować integrację, obsłużyć nowy schemat faktury, tryby awaryjne, uprawnienia i odbiór faktur kosztowych, a teraz musi ją utrzymywać przy każdej zmianie schematu.
KSeF nie jest wyjątkiem. Od 2025 roku najwięksi podatnicy CIT, z przychodem powyżej 50 mln euro, oraz podatkowe grupy kapitałowe prowadzą księgi tak, aby przekazać je w strukturze JPK_KR_PD, a kolejne grupy podatników dołączają w następnych latach. Każda taka zmiana wymaga dopasowania planu kont, oznaczeń i eksportu danych. W gotowym systemie producent rozkłada ten koszt na tysiące klientów. We własnym systemie płaci za niego jedna firma, sama, za każdym razem.
Jest też argument audytowy. Biegły rewident badający sprawozdanie firmy z popularnym systemem ERP zna jego mechanizmy kontrolne, logi i raporty. Przy systemie zbudowanym we własnym zakresie musi je poznać od zera, a firma musi wykazać, że system poprawnie księguje, nie pozwala na nieautoryzowane zmiany i zachowuje ślad rewizyjny. To da się zrobić, ale to kolejna praca, która nie tworzy żadnej wartości dla klienta.
Wreszcie argument kadrowy. Księgowość i płace to obszar, w którym zespół finansowy chce pracować w narzędziu, które zna z rynku i do którego łatwo znaleźć ludzi. Nowa główna księgowa, która przychodzi z innej firmy, w ciągu kilku dni odnajdzie się w popularnym systemie. We własnym systemie potrzebuje szkolenia, a jej wiedza nie przenosi się na zewnątrz.
Teza tej sekcji jest więc mocna: nawet firma, która ma wszelkie powody, by budować własny system operacyjny, powinna kupić rdzeń księgowo-podatkowy. Wyjątki istnieją, ale dotyczą firm, dla których oprogramowanie finansowe jest produktem, a nie narzędziem.
Co naprawdę oznacza „rozszerzać” i dlaczego to cztery różne decyzje?
Słowo „rozszerzenie” pojawia się w niemal każdej ofercie wdrożeniowej i prawie nigdy nie jest doprecyzowane. Tymczasem obejmuje cztery poziomy ingerencji, które różnią się kosztem, ryzykiem i tym, co dzieje się przy aktualizacji systemu.
Poziom pierwszy: konfiguracja. Zmiana ustawień przewidzianych przez producenta: plan kont, ścieżki akceptacji, definicje dokumentów, uprawnienia, układ formularzy. Nie wymaga programowania i przeżywa aktualizacje, bo producent je przewidział. To podstawowy sposób dopasowania ERP do firmy i powinien wyczerpać większość potrzeb w procesach towarowych.
Poziom drugi: rozszerzenia w punktach przewidzianych przez producenta. Dodatkowe pola, własne raporty, reguły biznesowe i skrypty uruchamiane w miejscach, które producent udostępnił i obiecał utrzymywać. Wymaga programowania, ale zwykle w ograniczonym, udokumentowanym zakresie. Przeżywa aktualizacje, jeśli korzysta wyłącznie z publicznych interfejsów.
Poziom trzeci: modyfikacje rdzenia. Zmiany kodu lub struktury danych samego systemu, bezpośredni dostęp do tabel, przepisywanie standardowych procedur. Daje największą swobodę i jest najszybszą drogą do „zrobienia tego po swojemu”. Za to przy każdej aktualizacji producenta wymaga ponownej analizy, testów, a często przepisania. Po kilku latach firma ma system, którego nie da się zaktualizować bez dużego projektu.
Poziom czwarty: aplikacje obok ERP. Osobne oprogramowanie, które realizuje proces wyróżniający, ma własny kod i własną bazę danych, a z ERP wymienia dane przez opublikowane API lub kolejki komunikatów. Rdzeń zostaje nienaruszony, a aplikacja może się rozwijać we własnym tempie. To właściwie budowa, ale w granicach, które nie dotykają ksiąg.
Producenci dużych systemów sami doszli do podobnej klasyfikacji. SAP od kilku lat promuje zasadę „czystego rdzenia” (clean core), a w wytycznych opublikowanych w sierpniu 2025 roku klasyfikuje rozszerzenia na poziomach od A do D: od korzystających wyłącznie z opublikowanych interfejsów, najbezpieczniejszych przy aktualizacji, po modyfikacje i bezpośredni dostęp do tabel, obarczone najwyższym ryzykiem. Nie trzeba korzystać z oprogramowania tego producenta, żeby przyjąć tę samą logikę: każde rozszerzenie warto zaklasyfikować, zanim zostanie zamówione.
Praktyczna konsekwencja dla zarządu jest prosta. Zamiast pytać dostawcę, „czy da się to rozszerzyć”, trzeba zapytać, „na którym poziomie to rozszerzenie powstanie i co się z nim stanie przy najbliższej aktualizacji”. Odpowiedź „to będzie modyfikacja, ale niewielka” powinna zapalić czerwoną lampkę.
Dlaczego modyfikacja rdzenia jest najdroższa, choć wygląda na najtańszą?
Bo jej koszt pojawia się później, w innym budżecie i często po odejściu ludzi, którzy ją zamówili. W ofercie wdrożeniowej modyfikacja wygląda jak kilka czy kilkanaście dni pracy konsultanta. W budżecie utrzymania wraca przy każdej aktualizacji, każdej zmianie przepisów i każdej migracji do nowej wersji.
Najbardziej znanym przykładem jest projekt eLWIS w sieci Lidl. Według relacji Consultancy.uk z sierpnia 2018 roku firma przez siedem lat wdrażała system do gospodarki towarowej, po czym go zatrzymała. Prasa branżowa szacowała koszty na około 500 mln euro, choć ani Lidl, ani dostawca tej kwoty nie potwierdzili. Źródłem problemu była rozbieżność między procesem firmy a standardem systemu: Lidl wyceniał zapasy według cen zakupu, a standard oprogramowania dla handlu opierał się na cenach detalicznych. Firma nie chciała zmienić swojego procesu, więc to system dopasowywano do firmy, co pogorszyło wydajność i podniosło koszty. Prezes Lidla napisał wtedy do pracowników, że pierwotnych celów nie da się osiągnąć przy akceptowalnych nakładach.
Drugi przykład jest świeższy. Rada miasta Birmingham, największy samorząd lokalny w Europie, planowała wdrożyć system ERP w chmurze w wersji standardowej, z budżetem 19 mln funtów i 1 mln funtów rezerwy. W trakcie projektu powstały jednak własne dopasowania, w tym mechanizm uzgadniania wyciągów bankowych, który nie działał poprawnie, przez co samorząd przez długi czas nie znał swojej pozycji gotówkowej. Według The Register ze stycznia 2026 roku prognozowany koszt programu sięga 144,4 mln funtów do roku budżetowego 2027/28, a samorząd wdraża system od nowa, tym razem w wersji standardowej, z zewnętrznym produktem do uzgadniania bankowego.
Obie historie dotyczą organizacji dużo większych niż średnia firma, ale mechanizm jest identyczny w każdej skali. Modyfikacja rdzenia zamienia jednorazową decyzję „dopasujmy system do nas” w stały koszt, który rośnie z każdą wersją. Do tego dochodzi efekt kumulacji: pierwsza modyfikacja ułatwia uzasadnienie drugiej, bo „i tak już mamy własną wersję”. Po kilku latach firma płaci licencję za standardowy produkt, z którego standardu nie korzysta.
Problem ujawnia się najwyraźniej przy końcu wsparcia starej wersji. Producenci wyznaczają daty, po których przestają dostarczać poprawki i aktualizacje prawne. Dla jednego z najpopularniejszych systemów ERP na świecie, SAP ECC 6.0, podstawowe wsparcie kończy się 31 grudnia 2027 roku, z możliwością wykupienia wsparcia rozszerzonego do 2030 roku. Firmy, które przez lata modyfikowały rdzeń, odkrywają teraz, że migracja do nowej wersji oznacza inwentaryzację i przepisanie setek zmian. Firmy, które trzymały się standardu, mają przed sobą projekt dużo prostszy.
Jest jeszcze jeden, mniej oczywisty koszt modyfikacji: wiedza. Zmiany w rdzeniu zna zwykle kilka osób u wdrożeniowca. Gdy te osoby odchodzą, firma zostaje z kodem, którego nikt nie rozumie, w systemie, którego producent nie wspiera w tej postaci. To prosta droga do systemu dziedziczonego, tyle że kilka lat po wdrożeniu, a nie kilkanaście.
Kiedy budowa własnego systemu ma sens i czego nawet wtedy nie budować?
Budowa ma sens, gdy spełnione są jednocześnie trzy warunki. Po pierwsze, proces jest rzeczywiście źródłem przewagi, co da się wykazać, a nie tylko zadeklarować: klienci wybierają firmę z powodu, który od tego procesu zależy. Po drugie, gotowe systemy go nie obsługują, nawet po konfiguracji i rozszerzeniach w przewidzianych miejscach, a różnica nie jest kwestią nawyku. Po trzecie, firma jest gotowa utrzymywać to oprogramowanie przez lata, z zespołem, budżetem i właścicielem po stronie biznesu.
Typowe sytuacje, w których te warunki bywają spełnione:
- nietypowy model produkcji, na przykład produkcja jednostkowa na zamówienie z konfiguracją produktu przez klienta, gdzie standardowe planowanie zakłada serie i stałe marszruty;
- wycena jako przewaga: setki zmiennych, kontrakty z indywidualnymi formułami, ceny zależne od kursów surowców, gdzie szybkość i trafność oferty decydują o sprzedaży;
- proces obsługi klienta zintegrowany z operacją, gdzie klient sam zamawia, śledzi i zmienia zlecenie, a te dane od razu wpływają na planowanie;
- duża skala transakcji o prostej strukturze, gdzie licencje naliczane od użytkownika lub transakcji przestają się opłacać, a logika jest na tyle prosta, że własne rozwiązanie jest tańsze w utrzymaniu.
Nawet wtedy nie buduje się całego ERP. Buduje się system operacyjny firmy: planowanie, wycenę, portal klienta, zarządzanie magazynem o nietypowych regułach. Księgi, podatki i płace zostają w kupionym rozwiązaniu, a własny system przekazuje do nich dokumenty i dane przez integrację systemów opartą na jasnych kontraktach danych. Taka architektura zachowuje to, co najcenniejsze w budowie, czyli kontrolę nad procesem wyróżniającym, i to, co najcenniejsze w zakupie, czyli przerzucenie zgodności z przepisami na producenta.
Warto też uczciwie powiedzieć, kiedy budowa nie ma sensu, nawet jeśli dostawca przekonuje inaczej. Gdy argumentem jest głównie koszt licencji, trzeba porównać go z kosztem zespołu, który przez lata będzie utrzymywał własny system; licencja niemal zawsze wychodzi taniej przy procesach towarowych. Gdy argumentem jest „nasz proces jest wyjątkowy”, a nikt nie potrafi wskazać, jaki efekt dla klienta ta wyjątkowość daje, to zwykle nawyk. Gdy argumentem jest niezależność od dostawcy, trzeba pamiętać, że własny system tworzy zależność od własnego zespołu lub od software house’u, który go zbudował. Ogólne kryteria decyzji „kupić czy zbudować” dla dowolnego oprogramowania opisaliśmy w przewodniku po decyzjach build vs buy; w przypadku ERP najważniejsza jest różnica między procesami, które muszą być poprawne, a tymi, które mogą być lepsze.
Jak zmapować procesy, żeby zdecydować osobno dla każdego z nich?
Mapa decyzji ERP nie wymaga wielomiesięcznego projektu analitycznego. Wymaga kilku warsztatów z właścicielami procesów i dyscypliny w zadawaniu tych samych pytań każdemu z nich.
Zacznij od listy procesów na poziomie, na którym zarząd potrafi o nich rozmawiać: kilkanaście, najwyżej dwadzieścia pozycji, od „zamówienie do zapłaty” po „zakup do płatności” i „zamknięcie miesiąca”. Dla każdego procesu zadaj pięć pytań.
- Czy klient odczuwa różnicę, jeśli robimy to lepiej niż konkurencja? Jeśli nie, proces jest towarem.
- Jak często zmieniają ten proces przepisy? Im częściej, tym silniejszy argument za kupionym standardem.
- Czym nasz sposób różni się od standardu rynkowego i dlaczego? Jeśli odpowiedź brzmi „tak zawsze robiliśmy”, różnica jest nawykiem.
- Co się stanie, jeśli przyjmiemy standard? Policz skutek: utracona sprzedaż, wolniejsza obsługa, dodatkowe etaty. Często okazuje się, że skutek jest niewielki albo żaden.
- Kto będzie za to odpowiadał przez najbliższe siedem lat? Proces bez właściciela nie powinien mieć własnego oprogramowania.
Wynik ułóż w trzy kategorie. Przyjmujemy standard: proces obsługuje kupiony system, zmiany tylko przez konfigurację, a firma dopasowuje swój sposób pracy. Rozszerzamy w przewidzianych miejscach: kupiony system plus rozszerzenia z opublikowanych interfejsów, bez modyfikacji rdzenia. Budujemy obok: osobna aplikacja, własny kod, integracja przez API. Czwartej kategorii, „modyfikujemy rdzeń”, nie powinno być na liście domyślnie; jeśli pojawia się, wymaga osobnej, udokumentowanej zgody zarządu z oceną kosztu utrzymania.
W typowej średniej firmie taki przegląd daje rozkład, który zaskakuje uczestników. Większość procesów ląduje w pierwszej kategorii, kilka w drugiej, jeden do trzech w trzeciej. To zupełnie inny obraz niż ten z prezentacji dostawców, w których albo „wszystko da się skonfigurować”, albo „wszystko trzeba zbudować”.
Dobrą praktyką jest wykonanie tej mapy przed rozesłaniem zapytań ofertowych, a nie po. Zapytanie, które mówi, które procesy firma chce przyjąć w standardzie, a które ma zamiar zbudować obok, daje oferty porównywalne. Zapytanie, które mówi tylko „szukamy ERP”, daje oferty, z których każda zakłada inną granicę.
Jakie kryteria decyzji powinien sprawdzić zarząd?
Poniższa tabela zbiera kryteria, które warto sprawdzić dla każdego procesu lub grupy procesów. Nie zastępuje mapy, ale pozwala szybko zobaczyć, który wariant jest naturalny w danym miejscu.
| Kryterium | Kupić i przyjąć standard | Rozszerzyć w przewidzianych miejscach | Zbudować obok ERP | Modyfikować rdzeń |
|---|---|---|---|---|
| Czy proces daje przewagę? | Nie | Częściowo | Tak, da się to wykazać | Rzadko jest to prawdziwy powód |
| Jak często zmieniają go przepisy? | Często (VAT, KSeF, JPK, płace) | Często lub umiarkowanie | Rzadko | Często, co mnoży koszt |
| Odstępstwo od standardu rynkowego | Małe lub wynikające z nawyku | Średnie, w danych lub regułach | Duże, w logice procesu | Dowolne, ale kosztowne |
| Co dzieje się przy aktualizacji | Aktualizuje producent | Zwykle działa, wymaga testów | Niezależna, zależy od kontraktu API | Wymaga analizy i często przepisania |
| Czas do uruchomienia | Najkrótszy | Krótki | Dłuższy, ale etapami | Krótki na początku, długi później |
| Kto utrzymuje przez lata | Producent i partner wdrożeniowy | Zespół wewnętrzny lub dostawca, w małym zakresie | Własny zespół lub stały dostawca | Wąskie grono specjalistów |
| Własność kodu i danych | Dane w systemie producenta, warunki w umowie | Kod rozszerzeń warto mieć na własność | Pełna, jeśli zapisana w umowie | Kod modyfikacji często nieprzenaszalny |
| Ryzyko wyjścia | Zależne od umowy i formatu danych | Umiarkowane | Niskie dla procesu, zależne od integracji | Wysokie |
Najważniejsza w tej tabeli jest ostatnia kolumna. Modyfikowanie rdzenia nie wygrywa w żadnym wierszu poza krótkim czasem pierwszej realizacji. Dlatego warto traktować ją jako wyjątek wymagający uzasadnienia, a nie jako jedną z równorzędnych opcji w ofercie.
Druga uwaga dotyczy wiersza „kto utrzymuje przez lata”. Zarządy często oceniają warianty po koszcie wdrożenia, a decyzję o utrzymaniu zostawiają na później. Tymczasem to utrzymanie przesądza o wyniku. Rozwiązanie, którego nikt nie będzie utrzymywał, jest złe niezależnie od tego, jak tanio zostało zbudowane.
Jak porównać koszty trzech wariantów, zanim powstanie kosztorys wdrożenia?
Na etapie decyzji o architekturze nie ma jeszcze kosztorysu, i dobrze, bo kosztorys bez decyzji o granicach systemu jest zgadywaniem. Można jednak porównać strukturę kosztów i to, jak zachowują się w czasie. To wystarcza, by odrzucić warianty, które nie mają szans się obronić.
Porównanie warto prowadzić w horyzoncie siedmiu do dziesięciu lat, bo tyle zwykle żyje system ERP w średniej firmie. W krótszym horyzoncie budowa i modyfikacje wyglądają lepiej, niż są, bo ich koszty utrzymania jeszcze się nie skumulowały. Ogólną metodykę liczenia całkowitego kosztu posiadania oprogramowania opisaliśmy osobno; tutaj skupmy się na tym, co jest specyficzne dla ERP.
Kupiony standard ma koszt przewidywalny i rozłożony: licencje lub abonament, wdrożenie, szkolenia, okresowe aktualizacje. Największe ryzyko to wzrost cen licencji w kolejnych latach i koszt zmiany sposobu pracy, który ponosi organizacja, a nie budżet IT.
Rozszerzenia w przewidzianych miejscach dodają do tego koszt zbudowania i przetestowania każdego rozszerzenia przy aktualizacji. Ten koszt jest umiarkowany, o ile rozszerzeń jest kilkanaście, a nie kilkaset, i o ile korzystają z publicznych interfejsów.
Aplikacja obok ERP ma koszt podobny do każdego projektu oprogramowania na zamówienie: zespół, czas, utrzymanie. Dla orientacji: według strony usług ARDURA typowy trzyosobowy zespół (dwóch programistów i tester) kosztuje około 62 000–123 000 zł miesięcznie, zależnie od poziomu doświadczenia, a stawki seniorów mieszczą się w przedziale 180–260 zł netto za godzinę. Kluczowa różnica wobec modyfikacji rdzenia polega na tym, że ten koszt rośnie z zakresem aplikacji, a nie z liczbą aktualizacji ERP.
Modyfikacje rdzenia mają koszt, który w ofercie jest najmniejszy, a w czasie rośnie najszybciej. Każda aktualizacja i każda zmiana przepisów wymaga przeglądu wszystkich zmian. Przy migracji do nowej wersji koszt bywa wielokrotnie wyższy niż koszt ich pierwotnego zbudowania.
Szczegółowy budżet wdrożenia ERP, z podziałem na pozycje i sposób jego oszacowania przed przetargiem, to temat na osobny tekst. Na etapie wyboru wariantu wystarczy jedno ćwiczenie: dla każdego procesu z kategorii „budujemy obok” zapisz, ile osób i przez jak długi czas będzie potrzebnych do jego utrzymania po uruchomieniu. Jeśli suma tych etatów przekracza możliwości firmy, granica została postawiona zbyt szeroko.
Jak zabezpieczyć dane, własność kodu i możliwość wyjścia?
Decyzja o ERP to decyzja na lata, więc trzeba z góry zaplanować, jak z niej wyjść. Nie dlatego, że firma planuje zmianę, ale dlatego, że możliwość wyjścia jest najlepszym zabezpieczeniem warunków współpracy. Szerzej o tym mechanizmie pisaliśmy w tekście o tym, jak uniknąć uzależnienia od dostawcy.
Dla kupionego systemu najważniejsze są dane. Umowa powinna określać, w jakim formacie i w jakim czasie firma może pobrać komplet swoich danych, łącznie z historią i załącznikami, oraz ile to kosztuje. Pomaga tu prawo unijne: rozporządzenie w sprawie danych (Data Act) od 12 września 2025 roku nakłada na dostawców usług przetwarzania danych, w tym oprogramowania w modelu SaaS, obowiązki ułatwiające zmianę dostawcy, a od 12 stycznia 2027 roku co do zasady zakazuje pobierania opłat za samą zmianę. Komisja Europejska zaproponowała w pakiecie Digital Omnibus złagodzenie części tych przepisów dla usług tworzonych na zamówienie, więc ostateczny kształt warto sprawdzić przed podpisaniem umowy. Prawo nie zastąpi jednak dobrze napisanej klauzuli o wyjściu.
Dla rozszerzeń i aplikacji budowanych obok najważniejszy jest kod. Umowa z wykonawcą powinna przenosić autorskie prawa majątkowe do kodu na firmę, na wymienionych polach eksploatacji, z obowiązkiem przekazywania kodu źródłowego i dokumentacji na bieżąco, a nie dopiero na koniec współpracy. Kod powinien leżeć w repozytorium firmy, a nie wykonawcy.
Dla integracji najważniejsze są kontrakty danych: opisane interfejsy, formaty komunikatów, zasady wersjonowania. To one decydują, czy za kilka lat da się wymienić jeden element architektury, na przykład kupiony system księgowy na inny, bez przepisywania wszystkiego, co z nim współpracuje. Integracja oparta na bezpośrednim dostępie do tabel ERP jest w praktyce modyfikacją rdzenia, tylko z drugiej strony.
Jeśli firma ma już rozbudowany system z wieloma modyfikacjami i nie wie, w jakim jest stanie, warto zacząć od niezależnego przeglądu. Zanim zarząd zdecyduje, czy rozszerzać obecne rozwiązanie, czy je wymienić, audyt kodu pokaże, ile w nim jest długu technicznego i które zmiany są ryzykowne. W ARDURA audyt kondycji kodu ma stały zakres, trwa 1–2 tygodnie i kosztuje od 18 000 zł.
Jak warianty różnią się w księgach i w budżecie?
Dla dyrektora finansowego wybór wariantu to także decyzja o tym, jak koszty ERP pojawią się w wyniku finansowym. Te różnice warto znać przed posiedzeniem zarządu, bo potrafią odwrócić ocenę wariantów porównywanych tylko po kwocie.
Własny system budowany na zamówienie, do którego firma nabywa prawa, może w wielu przypadkach zostać ujęty jako wartość niematerialna i amortyzowany. Licencje na programy komputerowe na gruncie podatku CIT amortyzuje się przez co najmniej 24 miesiące. Abonament za ERP w modelu SaaS jest zwykle kosztem bieżącym.
Najwięcej zaskoczeń dotyczy kosztów konfiguracji i dopasowania systemu w chmurze. Komitet Interpretacyjny MSSF w decyzji z 2021 roku wskazał, że koszty konfiguracji i dostosowania oprogramowania w modelu SaaS zwykle nie spełniają definicji składnika wartości niematerialnych według MSR 38, bo firma nie kontroluje oprogramowania, które konfiguruje. Dla spółek raportujących według MSSF oznacza to, że duża część kosztu wdrożenia ERP w chmurze trafia w koszty od razu, a nie jest rozłożona w czasie. Firmy stosujące polskie zasady rachunkowości powinny ustalić podejście z biegłym rewidentem.
Wniosek dla zarządu nie jest taki, że któryś wariant jest „księgowo lepszy”. Jest taki, że porównanie wariantów powinno pokazywać zarówno przepływy pieniężne, jak i wpływ na wynik w kolejnych latach, uzgodniony z głównym księgowym. Wariant, który w przepływach jest tańszy, może wyglądać gorzej w wyniku pierwszego roku, i odwrotnie.
Jak podjąć decyzję w ciągu kilku tygodni, zanim podpiszesz umowę?
Decyzja o granicach ERP nie wymaga roku analiz. Wymaga kilku tygodni dobrze ułożonej pracy, która zamieni przeczucia w sprawdzone fakty. Proponowany przebieg wygląda tak.
Tydzień 1–2: mapa procesów. Warsztaty z właścicielami procesów, pięć pytań z wcześniejszej sekcji dla każdego z nich, wstępny podział na trzy kategorie. Wynikiem jest jedna strona, którą zarząd może zatwierdzić albo zakwestionować.
Tydzień 3–4: sprawdzenie standardu. Dla procesów z kategorii „przyjmujemy standard” i „rozszerzamy” — pokaz na rzeczywistych danych firmy, nie na danych demonstracyjnych dostawcy. Celem jest odpowiedź na pytanie, czy standard naprawdę wystarcza i które rozszerzenia są konieczne. Każde rozszerzenie dostaje poziom: konfiguracja, punkt rozszerzenia, modyfikacja, aplikacja obok.
Tydzień 5–6: weryfikacja procesu wyróżniającego. Dla jednego, najważniejszego procesu z kategorii „budujemy obok” — krótka faza discovery: wymagania, architektura, kontrakt integracji z ERP, prototyp kluczowego ekranu lub algorytmu. W ARDURA taka faza w projektach oprogramowania trwa zwykle 1–2 tygodnie i kończy się zakresem oraz architekturą, na podstawie których da się zaplanować dalsze kroki.
Tydzień 7–8: decyzja zarządu. Na stole leżą: mapa procesów z kategoriami, lista rozszerzeń z poziomami, wynik weryfikacji procesu wyróżniającego, struktura kosztów w horyzoncie siedmiu do dziesięciu lat i lista założeń. Zarząd decyduje o granicach systemu i o pierwszym etapie, a nie o całości.
Ten przebieg ma jedną ważną cechę: decyzja o wyborze konkretnego produktu ERP i konkretnego wykonawcy zapada po decyzji o granicach, a nie przed nią. Odwrócenie kolejności, czyli najpierw wybór produktu, a potem dopasowywanie do niego firmy, to najczęstsza droga do modyfikacji rdzenia.
Jeżeli obecny system jest stary i zastanawiasz się, czy go rozszerzać, czy wymieniać, warto dodatkowo porównać opcje opisane w artykule o modernizacji systemów dziedziczonych. Decyzja o granicach ERP i decyzja o losie starego systemu są ze sobą powiązane, ale nie są tym samym.
Jakie są kluczowe wnioski przed decyzją o ERP?
Pytanie „budować czy kupić ERP” jest źle postawione, bo ERP to kilkanaście procesów o różnym charakterze. Dobra decyzja zapada osobno dla każdego z nich, a jej najważniejszym produktem jest granica: gdzie kończy się kupiony standard, a zaczyna własny kod.
Zapamiętaj sześć rzeczy. Po pierwsze, rdzeń księgowo-podatkowy kupuj i przyjmuj jego standard; przepisy, takie jak KSeF i JPK, zmieniają go częściej, niż jakakolwiek firma chciałaby za to płacić sama. Po drugie, rozróżniaj cztery poziomy „rozszerzania” i pytaj dostawcę, na którym z nich powstanie każda zmiana. Po trzecie, traktuj modyfikację rdzenia jako wyjątek wymagający osobnej zgody zarządu, bo jej koszt rośnie z każdą aktualizacją. Po czwarte, buduj tylko tam, gdzie proces daje przewagę, którą da się wykazać, i buduj obok ERP, z integracją przez opublikowane interfejsy. Po piąte, porównuj warianty w horyzoncie siedmiu do dziesięciu lat i z perspektywą wyniku finansowego, nie tylko przepływów. Po szóste, zabezpiecz w umowach dane, kod rozszerzeń i możliwość wyjścia, zanim cokolwiek podpiszesz.
Jeśli potrzebujesz zweryfikować proces, który ma być budowany obok ERP, albo zaprojektować jego integrację z kupionym systemem, zobacz, jak pracujemy w tworzeniu oprogramowania na zamówienie, lub umów rozmowę. Zaczynamy od krótkiej fazy discovery, która kończy się zakresem, architekturą i kontraktem integracji, z którymi można wrócić do zarządu.