ERP na zamówienie czy dostosowany gotowy ERP?

Według Mesterséges Intelligencia Központ Kft., firmy programistycznej z Budapesztu, gotowy ERP sprawdza się, jeśli procesy można dopasować do standardu, a ERP na zamówienie wtedy, gdy firma działa inaczej albo dostosowanie zagrażałoby już aktualizacjom.

W skrócie: są trzy drogi: gotowy ERP w niezmienionej postaci; gotowy ERP skonfigurowany i uzupełniony w punktach rozszerzeń udostępnionych przez producenta; oraz ERP na zamówienie. Im głębiej trzeba by ingerować w rdzeń gotowego systemu, tym bardziej opłaca się wydzielić część specyficzną do osobnego modułu albo zbudować własny system. Niezależnie od wybranej drogi przejście etapami, poprzedzone czyszczeniem danych, wiąże się z mniejszym ryzykiem niż jednorazowa, duża zmiana.

Czym jest ERP?

ERP (enterprise resource planning, czyli system zarządzania przedsiębiorstwem) łączy podstawowe procesy firmy w jednym systemie. Według definicji Microsoftu ERP to oprogramowanie do zarządzania działalnością, które pomaga organizacjom zintegrować ich podstawowe procesy, takie jak finanse, łańcuch dostaw, produkcja, zasoby ludzkie, zakupy i zarządzanie projektami (Microsoft: What is ERP?).

W praktyce wartość ERP polega na tym, że te same dane powstają tylko raz: z przychodzącego zamówienia powstaje wydanie z magazynu, z niego faktura, a z faktury zapis księgowy i należność. Jeśli te kroki odbywają się w osobnych programach i arkuszach kalkulacyjnych, dane wędrują ręcznie, a razem z nimi wędrują błędy. Śledzenie klientów i sprzedaży to obszar pokrewny, ale wymagający osobnej decyzji; piszemy o nim w artykule Kiedy opłaca się stworzyć CRM na zamówienie?.

Trzy drogi do systemu ERP

Pytanie „na zamówienie czy gotowy” to w rzeczywistości wybór spośród trzech możliwości. Granica między nimi nie jest ostra, ale różnica w kosztach, aktualizacjach i zależności jest znacząca.

Gotowy ERP w niezmienionej postaci

Firma wdraża gotowy produkt i dostosowuje swoje procesy do jego standardowego działania. Sprawdza się to dobrze, gdy procesy są typowe, a firma jest gotowa zmienić utarty sposób pracy. Zaletą jest szybszy start i aktualizacje dostarczane przez producenta; wadą jest natomiast to, że wszystko, czego produkt nie obejmuje, nadal odbywa się w arkuszach kalkulacyjnych albo ręcznie.

Gotowy ERP skonfigurowany i rozszerzony

Większość wdrożeń zatrzymuje się gdzieś tutaj. Warto odróżnić trzy rzeczy, bo z punktu widzenia możliwości aktualizacji oznaczają one coś zupełnie innego:

Konfiguracja (ustawienia): korzystanie z możliwości przewidzianych przez producenta, bez programowania, na przykład w zakresie przepływów pracy, poziomów zatwierdzania, pól, wzorów dokumentów i uprawnień.
Rozszerzenie (extension): nowa funkcja dodana przez wspierane i udokumentowane przez producenta punkty rozszerzeń i interfejsy, bez zmiany własnego kodu produktu.
Modyfikacja (dostosowanie rdzenia): przepisanie własnego kodu lub obiektów producenta albo ich skopiowanie i przepisanie. Daje to najwięcej swobody, ale według dokumentacji samych producentów wiąże się z największym ryzykiem przy aktualizacjach (zob. niżej).

ERP na zamówienie

System opiera się na własnych procesach i modelu danych firmy, a powstaje tylko to, co jest naprawdę potrzebne. Nie ma fabrycznego rdzenia, który trzeba by aktualizować, a o dalszym rozwoju decyduje zamawiający. W zamian trzeba zorganizować prace programistyczne, eksploatację i utrzymanie, czy to z własnym zespołem, czy z wykonawcą na podstawie umowy. Ogólnemu porównaniu oprogramowania na zamówienie i gotowego poświęcony jest artykuł Oprogramowanie na zamówienie czy gotowe rozwiązanie (SaaS)?.

Dlaczego liczne dostosowania utrudniają aktualizacje?

Producent gotowego ERP regularnie wydaje poprawki i nowe wersje. Jeśli firma zmodyfikowała kod producenta, przy każdej aktualizacji trzeba sprawdzić, czy modyfikacja nadal działa, a często także ją przepisać. Do tego samego wniosku dochodzi dokumentacja dużych producentów:

SAP: zgodnie z podejściem „clean core” (czysty rdzeń) rozszerzenia należy ściśle oddzielać od aplikacji SAP i łączyć z nią przez dobrze zdefiniowane, odporne na aktualizacje interfejsy; bezpośrednią modyfikację lub kopiowanie obiektów standardowych producent uważa za bardziej problematyczne, ponieważ po każdym pakiecie poprawek lub aktualizacji może to wymagać gruntownego ponownego testowania (SAP Learning: Introducing the Clean Core Approach).
Microsoft Dynamics 365: w przypadku produktów Finance, Supply Chain i Commerce producent uzasadnia model oparty na rozszerzeniach tym, że chmura i częste aktualizacje wymagają mniej inwazyjnego dostosowywania, dzięki czemu aktualizacje rzadziej wpływają na rozwiązania tworzone na zamówienie; w tych produktach rozszerzenia są jedynym sposobem dostosowania, a nadpisywanie kodu aplikacji (overlayering) nie jest obsługiwane (Microsoft Learn: Extensibility home page).
Odoo: według dokumentacji bazy danych zawierającej moduły na zamówienie nie można zaktualizować, dopóki moduły te nie zostaną przygotowane dla wersji docelowej, a za zgodność odpowiada osoba utrzymująca dany moduł (Odoo: Upgrade).

Wniosek jest w przypadku SAP i Microsoftu ten sam: rdzeń powinien pozostać nienaruszony, a to, co w firmie specyficzne, powinno znaleźć się w dającym się wydzielić rozszerzeniu albo w osobnym module, który komunikuje się z gotowym systemem przez udokumentowany interfejs; w przypadku Odoo to utrzymanie modułów na zamówienie decyduje o tym, kiedy można zaktualizować system. Jeśli potrzebna specyfika jest tak duża, że nie da się już tego czysto rozwiązać, jest to mocny sygnał przemawiający za ERP na zamówienie albo modułem na zamówienie.

Specyfika węgierska: NAV Online Számla, fakturowanie, bank, sklep internetowy

ERP węgierskiej firmy musi współpracować także z węgierskimi systemami. Najważniejszy jest NAV Online Számla, system węgierskiego urzędu skarbowego (NAV) do raportowania danych z faktur online: według informacji NAV od 4 stycznia 2021 r. obowiązkowe jest przesyłanie danych o każdej fakturze, fakturze korygującej i fakturze anulującej, do której mają zastosowanie zasady fakturowania węgierskiej ustawy o VAT (NAV: Online Számla).

Obsługiwaną wersją połączenia między systemami (interfejsu maszynowego) jest wersja 3.0 (sprawdzono 17 października 2026 r.). Zgodnie ze specyfikacją interfejsu program do fakturowania musi przekazywać dane automatycznie, bez odrębnej ingerencji człowieka w ramach procesu; NAV przetwarza przesłane dane asynchronicznie, a obowiązek przekazania danych nie jest uznawany za wykonany, dopóki program nie upewni się, że przetwarzanie się powiodło, i nie otrzyma komunikatu potwierdzającego dotyczącego danej faktury (NAV Online Számla: dokumentacja). NAV od czasu do czasu zmienia specyfikację (zmienioną wersję opublikował także w sierpniu 2026 r.), dlatego połączenie trzeba utrzymywać.

Co zazwyczaj musi obsługiwać ERP węgierskiej firmy i co podłączamy:

NAV Online Számla: przesyłanie danych faktur przez interfejs maszynowy, sprawdzanie wyniku przetwarzania i obsługa błędów.
Serwisy do fakturowania: jeśli fakturowanie pozostaje w zewnętrznym serwisie, połączenie przez jego interfejs.
Banki: import wyciągów bankowych i transakcji, dopasowywanie wpływów do faktur.
Sklep internetowy: synchronizacja zamówień, stanów magazynowych i cen między sklepem internetowym a ERP.
Firmy kurierskie i inne systemy: nadawanie paczek, istniejący CRM, poczta e-mail i kalendarz.

Przy wyborze gotowego ERP warto zapytać, czy produkt ma węgierską lokalizację, kto utrzymuje połączenie z NAV, gdy zmienia się specyfikacja, i jak wygląda połączenie z węgierskimi bankami i serwisami do fakturowania. W ERP na zamówienie te same połączenia są częścią prac programistycznych. O łączeniu systemów piszemy szerzej na stronie Automatyzacja procesów.

Tabela decyzyjna

Kryterium	Gotowy ERP w niezmienionej postaci	Rozszerzony gotowy ERP	ERP na zamówienie
Dopasowanie do procesów	firma dostosowuje się do standardowych procesów	większość standardu pasuje, kilka punktów jest specyficznych	działanie firmy znacząco odbiega od standardu
Start	zazwyczaj szybki, jeśli wystarcza konfiguracja	dłuższy ze względu na tworzenie rozszerzeń	wymaga czasu na prace programistyczne, może startować etapami
Aktualizacje	dostarcza je producent, przy niewielkim ryzyku	rozszerzenia trzeba sprawdzać przy każdej aktualizacji	harmonogram ustala zamawiający, wykonuje je wykonawca
Procesy specyficzne	tylko za pomocą ustawień	w punktach rozszerzeń lub w osobnym module	dowolna logika biznesowa
Integracje	za pomocą konektorów producenta i jego partnerów	konektory i integracje na zamówienie	z każdym systemem, którego interfejs lub dane są dostępne
Struktura kosztów	opłata licencyjna lub abonamentowa na warunkach producenta	licencja oraz tworzenie i utrzymanie rozszerzeń	prace programistyczne, eksploatacja i dalszy rozwój
Zależność	od producenta i przyszłości produktu	od producenta i partnera tworzącego rozszerzenia	mając kod źródłowy, można kontynuować prace z innym wykonawcą
Dla kogo?	dla firmy o typowym sposobie działania, która chce szybko wystartować	dla tych, dla których standard jest dobrą podstawą, ale w kilku punktach działają inaczej	dla tych, których sposób działania lub integracje są nietypowe

Częste jest też rozwiązanie mieszane: gotowy ERP pozostaje do finansów i księgowości, a specyficzne procesy firmy, na przykład indywidualne harmonogramowanie produkcji lub ustalanie cen, działają w osobnym module na zamówienie, który komunikuje się z gotowym systemem przez interfejs.

Przejście ze starego systemu

Projekt ERP rzadko zaczyna się od czystej kartki: istnieje stary program, gotowy system albo zestaw arkuszy kalkulacyjnych, w których przechowywane są dane z wielu lat. Kroki przejścia:

Analiza: jakie dane, procesy i połączenia istnieją oraz co dziś odbywa się w arkuszach kalkulacyjnych, poza systemem.
Inwentaryzacja i czyszczenie danych: uporządkowanie zdublowanych klientów, niekompletnej kartoteki towarowej i nieaktualnych pozycji jeszcze przed migracją.
Mapowanie danych: dokąd w nowym systemie trafia każde stare pole i co dzieje się ze starymi, zamkniętymi pozycjami.
Migracja próbna: stare dane trafiają do środowiska testowego, gdzie kluczowi użytkownicy sprawdzają je na prawdziwych przypadkach.
Uruchomienie produkcyjne etapami: moduł po module lub oddział po oddziale, ewentualnie z krótkim równoległym działaniem starego i nowego systemu, aby codzienna praca się nie zatrzymała.
Opieka powdrożeniowa: usuwanie błędów, dodatkowe szkolenia i eksploatacja po uruchomieniu produkcyjnym.

Nie trzeba wymieniać wszystkiego naraz. Często realną drogą jest umieszczenie nowego modułu najpierw obok starego systemu i wymiana danych między nimi przez interfejs, dopóki starej części nie da się wycofać.

Ryzyka i sposoby ich ograniczania

Zbyt duży pierwszy etap: jeśli wszystko startuje naraz, jeden błąd zatrzymuje całą firmę. Warto zacząć od dobrze wyodrębnionego modułu.
Nieuporządkowane dane: błędne dane pozostaną błędne także w nowym systemie. Czyszczenie danych jest częścią projektu, a nie zadaniem na później.
Ukryte procesy: wiele ważnych kroków istnieje w arkuszach kalkulacyjnych albo w głowie jednego pracownika. Analiza musi ujawnić także je.
Brak kluczowych użytkowników: jeśli osoby wykonujące codzienną pracę nie biorą udziału w projektowaniu i testowaniu, obok systemu nadal żyje arkusz kalkulacyjny.
Błędy integracji: połączenia z NAV, bankiem i sklepem internetowym wymagają rejestrowania zdarzeń i sygnalizowania błędów, aby zablokowana synchronizacja nie pozostała niezauważona.
Jednostronna zależność: przekazanie pełnego kodu źródłowego i dokumentacji gwarantuje, że system będzie można później dalej rozwijać także z innym wykonawcą.

Gdzie sztuczna inteligencja pomaga w ERP?

Duże modele językowe, czyli ChatGPT od OpenAI, Claude od Anthropic i Gemini od Google, są przydatne tam, gdzie dotąd człowiek czytał, przepisywał lub redagował:

Dokumenty: odczytywanie danych z przychodzących faktur, dokumentów dostawy i zamówień oraz ich zapisywanie w postaci przygotowanej do sprawdzenia.
Poczta e-mail: przetwarzanie przychodzących wiadomości e-mail z zamówieniami i przygotowanie projektu odpowiedzi.
Pytania o dane: pytanie zadane systemowi zwykłym językiem, na przykład o to, którzy klienci mają przeterminowane faktury.
Sygnalizowanie odchyleń: wyróżnianie nietypowych pozycji do sprawdzenia, na przykład zamówienia, które bardzo odbiega od wcześniejszych zamówień klienta.

Tam, gdzie pomyłka kosztuje pieniądze, AI proponuje, a zatwierdza człowiek. O podłączaniu modeli i ochronie danych piszemy na stronie Integracja AI.

Nasze doświadczenie

Obecnie tworzymy duży system ERP i CRM; nie ujawniamy nazwy klienta ani produktu. W ERP rzadko najtrudniejsze są ekrany: to model danych, uprawnienia, integracje i przejęcie starych danych decydują o tym, czy pracownicy będą korzystać z systemu, czy obok niego nadal będą prowadzić arkusz kalkulacyjny.

Częste pytania

Kiedy opłaca się stworzyć ERP na zamówienie?

Wtedy, gdy działanie firmy znacząco odbiega od tego, na czym opierają się gotowe systemy ERP, a firma chce tę odmienność zachować; gdy trzeba połączyć wiele systemów, a nie ma do nich gotowych konektorów; albo gdy potrzebne dostosowanie wymagałoby już modyfikacji fabrycznego rdzenia. Jeśli gotowy ERP obejmuje większość procesów za pomocą ustawień, zazwyczaj jest on szybszą drogą, o czym mówimy już podczas pierwszej konsultacji.

W jakim stopniu można dostosować gotowy ERP?

Na wiele sposobów, ale nie jest obojętne, w jaki sposób. Ustawienia (konfiguracja) i wspierane przez producenta punkty rozszerzeń mają niewielki wpływ na aktualizacje; modyfikacja kodu producenta może natomiast przy każdej aktualizacji powodować dodatkową pracę. Dokumentacja dużych producentów, SAP i Microsoftu, zaleca pozostawienie rdzenia nienaruszonego i wydzielanie rozszerzeń; według dokumentacji Odoo warunkiem aktualizacji jest utrzymanie modułów na zamówienie.

Jakie ryzyko wiąże się z licznymi dostosowaniami?

Przede wszystkim takie, że aktualizacje stają się drogie i ryzykowne: przy każdej nowej wersji modyfikacje trzeba sprawdzić i często przepisać, a u niektórych producentów aktualizacji nie da się nawet przeprowadzić, dopóki części na zamówienie nie zostaną przygotowane dla nowej wersji. Ponadto firma uzależnia się od partnera tworzącego rozszerzenia. Jeśli uzasadnia to skala dostosowań, warto porównać ich koszt z kosztem modułu na zamówienie lub ERP na zamówienie.

Jak przebiega przejście ze starego systemu?

Zaczyna się od analizy, czyszczenia danych i mapowania danych, potem następuje migracja próbna w środowisku testowym, a następnie uruchomienie produkcyjne etapami: moduł po module albo z krótkim równoległym działaniem starego i nowego systemu. Po uruchomieniu produkcyjnym następują usuwanie błędów i eksploatacja. Stary system może przez pewien czas działać obok nowego, połączony z nim przez interfejs.

Czy podłączają Państwo NAV Online Számla?

Tak. Dane faktur przesyłamy przez interfejs maszynowy NAV, sprawdzamy wynik przetwarzania i obsługujemy błędy zgodnie z wymogami specyfikacji interfejsu NAV. W ten sam sposób podłączamy zewnętrzne serwisy do fakturowania, banki i sklep internetowy.

Jak możemy pomóc?

Mesterséges Intelligencia Központ Kft. tworzy na zamówienie systemy ERP, CRM i back-office, przygotowuje moduły i integracje na zamówienie do gotowych systemów oraz łączy je za pomocą sztucznej inteligencji. Pierwsza konsultacja jest bezpłatna, a jeśli wystarczy gotowy ERP, również to mówimy. Rozmiar funkcjonalny tworzonego oprogramowania mierzymy w punktach funkcyjnych COSMIC (ISO/IEC 19761), a na tej podstawie powstają oferta i harmonogram; metodę opisuje strona Wycena. Na życzenie zawieramy umowę o zachowaniu poufności (NDA), a po przekazaniu zapewniamy również eksploatację i utrzymanie. Kwestie kodu źródłowego i praw do korzystania reguluje umowa.

Szczegóły znajdą Państwo na stronie Oprogramowanie biznesowe. Jeśli chcieliby Państwo porozmawiać z nami o swoim systemie, prosimy do nas napisać, korzystając z danych kontaktowych podanych na stronie Kontakt.