Historia ERP: od MRP do agentowego developmentu

Historia systemów ERP: sześć dekad od MRP do agentów AI

Systemy ERP stały się standardem, ponieważ oprogramowanie szyte na miarę było zbyt drogie. Agenci kodujący AI nie sprawiają, że ERP staje się zbędne. Zmieniają ekonomię oprogramowania budowanego wokół niego.

Dla większości firm wybór nigdy nie był prawdziwym wyborem

Kupić standardowy system ERP i dostosować do niego sposób działania firmy.

Albo zbudować system wokół rzeczywistych procesów i zaakceptować projekt liczony w latach.

Większość organizacji wybierała trzecią drogę: zachować ERP, a jego braki uzupełniać arkuszami, e-mailami, ręcznym przepisywaniem danych i zatwierdzeniami wykonywanymi poza systemem.

Nie wynikało to ze złych decyzji. Wynikało z ekonomii.

Przez sześć dekad koszty tworzenia i utrzymania oprogramowania premiowały standaryzację. Dostawca ERP mógł raz zainwestować w rozbudowany produkt, a następnie sprzedawać go tysiącom klientów. Firma, której procesy nie mieściły się w standardzie, musiała skonfigurować system, zamówić jego modyfikację, dołączyć kolejną aplikację albo zmienić sposób pracy.

To równanie zaczyna się zmieniać.

Nie dlatego, że ERP przestało być potrzebne. Nie dlatego, że AI potrafi samodzielnie zarządzać przedsiębiorstwem. Zmiana jest bardziej konkretna i praktyczna: inżynieria wspierana przez AI może zmniejszyć nakład pracy potrzebny do zbudowania wyspecjalizowanego oprogramowania wokół stabilnego systemu centralnego.

Aby zrozumieć znaczenie tej zmiany, warto najpierw zobaczyć, dlaczego ERP stało się standardem.

01 / POCZĄTEK

MRP rozwiązało jeden trudny problem: co, kiedy i w jakiej ilości wyprodukować lub kupić

Lata 60.–80. XX wieku

Najwcześniejszymi przodkami współczesnych systemów ERP były systemy planowania potrzeb materiałowych, czyli MRP.

MRP łączyło harmonogram produkcji, informacje o zapasach i zestawienia materiałowe, aby obliczyć, jakich komponentów potrzebuje fabryka, w jakiej ilości i w którym momencie. Wdrożenie przeprowadzone w 1964 roku przez Black & Decker jest powszechnie uznawane za jedno z pierwszych zastosowań MRP, które połączyło te zasady planowania z komputerem mainframe. Prace Josepha Orlicky’ego pomogły sformalizować i rozpowszechnić tę metodę.

Systemy te były skuteczne, ponieważ odwzorowywały logikę działania konkretnej fabryki. Były również kosztowne. Infrastruktura obliczeniowa była trudno dostępna, tworzenie oprogramowania wymagało specjalistów, a na wdrożenia mogły sobie pozwolić przede wszystkim duże przedsiębiorstwa produkcyjne.

W latach 80. MRP rozwinęło się w planowanie zasobów produkcyjnych, określane jako MRP II. Zakres systemów rozszerzył się poza dostępność materiałów i zaczął obejmować moce produkcyjne, harmonogramowanie, zakupy oraz inne zasoby potrzebne do prowadzenia produkcji.

Kierunek był już jasny: firmy potrzebowały jednego systemu zdolnego koordynować coraz większą część działalności.

02 / PRODUKT

ERP zmieniło zintegrowane oprogramowanie biznesowe w standardowy produkt

Lata 90.

Gdy systemy planowania zaczęły obejmować nie tylko produkcję, lecz także finanse, sprzedaż, zakupy, kadry i inne obszary działalności, na początku lat 90. pojawiło się pojęcie enterprise resource planning — ERP.

ERP stworzyło coś niezwykle wartościowego: wspólny fundament operacyjny. Zamiast budować każdy obszar działalności oddzielnie, firma mogła kupić zintegrowany pakiet oparty na wspólnych procesach i danych.

Wprowadzony na rynek w 1992 roku system SAP R/3 był ważnym krokiem architektonicznym. Model klient-serwer, graficzny interfejs i obsługa relacyjnych baz danych pomogły przenieść oprogramowanie dla przedsiębiorstw poza epokę systemów mainframe.

Zmiana oprogramowania w standardowy produkt stworzyła jednak strukturalny kompromis.

Produkt zaprojektowany dla tysięcy organizacji nie może od razu odzwierciedlać każdej firmowej ścieżki zatwierdzania, reguły produkcyjnej, struktury danych czy sytuacji wyjątkowej. Konfiguracja obsługiwała typowe różnice. Konsultanci, integracje i dodatkowe oprogramowanie zajmowały się resztą.

ERP stało się standardowym produktem. Nie stało się gotowym rozwiązaniem idealnie pasującym do każdej firmy.

03 / CHMURA

Internet uprościł dostarczanie systemów. Nie rozwiązał problemu dopasowania procesów

Lata 2000.

Architektura internetowa oraz model software-as-a-service zmieniły sposób wdrażania i utrzymywania aplikacji biznesowych. Założony w 1998 roku NetSuite należał do pionierów oprogramowania biznesowego działającego w chmurze i pomógł rozwinąć model dostarczania systemów finansowych oraz ERP przez internet.

Korzyści były realne:

• Mniej infrastruktury utrzymywanej wewnątrz firmy.

• Centralnie dostarczane aktualizacje.

• Dostęp przez przeglądarkę.

• Opłaty abonamentowe zamiast wysokiego jednorazowego kosztu licencji.

Chmura usunęła znaczną część problemów infrastrukturalnych. Nie zlikwidowała różnicy między standardowym produktem a sposobem działania konkretnej organizacji.

Gdy standardowy workflow nie pasował, możliwości nadal były podobne: zmienić proces, zmodyfikować produkt albo podłączyć kolejną aplikację. Każdy dodatkowy system oznaczał więcej przepływów danych, więcej potencjalnych punktów awarii i więcej pytań o odpowiedzialność.

ERP w chmurze stało się łatwiejsze w utrzymaniu. Nie stało się automatycznie łatwiejsze do dopasowania do firmy.

04 / MODULARNOŚĆ

API obniżyły koszt łączenia systemów. Logika biznesowa nadal była indywidualna

Lata 2010.

W latach 2010. infrastruktura chmurowa, dojrzałe frameworki webowe, API i platformy low-code sprawiły, że oprogramowanie biznesowe stało się bardziej modułowe.

Zespoły nie musiały już tworzyć każdej warstwy systemu od zera. Mogły korzystać z gotowych usług uwierzytelniania, baz danych, komponentów interfejsu, platform integracyjnych i infrastruktury wdrożeniowej. Narzędzia operacyjne oraz branżowe produkty SaaS dały również mniejszym firmom więcej alternatyw wobec tradycyjnych pakietów ERP.

Powtarzalne elementy powstawały szybciej.

Trudna część nadal pozostawała specyficzna dla firmy:

• Jakie sytuacje wyjątkowe musi obsługiwać proces?

• Kto może podejmować poszczególne decyzje?

• Który system jest właścicielem określonych danych?

• Co powinno się wydarzyć, gdy standardowa ścieżka zawiedzie?

• Które reguły można zautomatyzować, a które wymagają decyzji człowieka?

Frameworki mogły dostarczyć strukturę. Narzędzia low-code mogły przyspieszyć budowę przewidywalnych workflow. Żadne z nich nie potrafiło samodzielnie odkryć i zrozumieć modelu operacyjnego firmy.

Wąskie gardło przesuwało się z samego tworzenia oprogramowania w stronę zrozumienia organizacji na tyle dobrze, aby można było bezpiecznie zapisać jej zasady w systemie.

05 / GENERATYWNA AI

AI najpierw skróciła czas wykonywania pojedynczych zadań programistycznych

Lata 2021–2023

W czerwcu 2021 roku GitHub uruchomił techniczny podgląd Copilota. Narzędzie mogło wykorzystywać otaczający kod jako kontekst i proponować całe linie lub funkcje.

W listopadzie 2022 roku pojawił się ChatGPT, a w marcu 2023 roku OpenAI zaprezentowało GPT-4.

Zespoły programistyczne szybko zaczęły wykorzystywać modele językowe do tworzenia kodu, wyjaśniania nieznanych fragmentów systemu, generowania testów, refaktoryzacji powtarzalnych implementacji oraz przygotowywania dokumentacji technicznej.

Pierwszy efekt był lokalny. AI przyspieszała wykonywanie pojedynczych zadań, ale nie przejmowała odpowiedzialności za cały system. Architektura, bezpieczeństwo, projektowanie danych, integracje i decyzje produktowe nadal wymagały doświadczonych inżynierów.

AI przyspieszyła produkcję kodu. Nie przejęła odpowiedzialności za rezultat.

06 / AGENTOWE WYTWARZANIE OPROGRAMOWANIA

Agenci kodujący obsługują coraz większą część procesu dostarczania systemu

Od 2024 roku

Kolejnym krokiem nie było lepsze autouzupełnianie. Było nim oprogramowanie zdolne do samodzielnego działania w obrębie całego repozytorium.

Do 2025 roku publicznie dostępni agenci kodujący potrafili analizować istniejący kod, modyfikować wiele plików, uruchamiać testy i narzędzia kontroli jakości, reagować na błędy oraz przygotowywać zmiany do weryfikacji przez człowieka.

Zmieniła się jednostka delegowanej pracy.

Zamiast prosić AI o napisanie jednej funkcji, inżynier może zlecić ograniczone i precyzyjnie opisane zadanie: dodać workflow, wdrożyć integrację, rozszerzyć model danych, przygotować test dla sytuacji wyjątkowej albo zmienić funkcję obejmującą kilka plików.

Praca inżyniera przesuwa się na wyższy poziom:

• Zdefiniowanie problemu i kryteriów akceptacji.

• Kontrolowanie architektury i granic systemu.

• Dostarczenie agentowi odpowiedniego kontekstu.

• Weryfikacja implementacji i wyników testów.

• Podjęcie decyzji, czy zmiana może zostać bezpiecznie wdrożona.

Agenci mogą wykonywać większą część cyklu. Człowiek nadal odpowiada za rezultat.

DOWODY

Wzrost produktywności dzięki AI jest realny, nierówny i łatwy do przecenienia

Nie istnieje jedna uczciwa liczba opisująca wpływ AI na produktywność zespołów programistycznych.

W kontrolowanym badaniu GitHub uczestnicy korzystający z Copilota wykonali jedno precyzyjnie zdefiniowane zadanie programistyczne o 55% szybciej. Wynik pokazuje dużą poprawę w odpowiednich warunkach. Nie oznacza jednak, że każdy projekt będzie realizowany o 55% szybciej.

Randomizowane badanie przeprowadzone przez METR w 2025 roku przyniosło odwrotny wynik w zupełnie innym środowisku. Szesnastu doświadczonych programistów open source wykonało 246 zadań w dobrze znanych im repozytoriach. Gdy mogli korzystać z narzędzi AI dostępnych na początku 2025 roku, realizacja zadań zajmowała im średnio o 19% więcej czasu.

METR kontynuowało badanie z wykorzystaniem nowszych narzędzi. W lutym 2026 roku organizacja poinformowała, że problemy z doborem uczestników i pomiarem czasu nie pozwalają uznać nowych wyników za wiarygodne. Surowe dane sugerowały, że narzędzia stały się bardziej pomocne, ale nie pozwalały na podanie precyzyjnej wartości wzrostu produktywności.

Badanie DORA z 2025 roku prowadzi do najbardziej użytecznego wniosku operacyjnego. Na podstawie odpowiedzi prawie 5000 specjalistów technologicznych opisuje ono AI jako wzmacniacz. Technologia zwiększa przewagę zespołów z jasnymi procesami, dobrymi platformami wewnętrznymi i niezawodnymi mechanizmami kontroli. Jednocześnie pogłębia problemy organizacji, których procesy są chaotyczne.

Te wyniki nie są ze sobą sprzeczne. Dotyczą różnych warunków.

AI jest najbardziej użyteczna, gdy zadanie ma jasno określone granice, kod można automatycznie przetestować, architektura jest kontrolowana, a rezultat zostanie zweryfikowany. Sprawdza się gorzej, gdy wykonanie zadania zależy od nieudokumentowanej wiedzy, system jest silnie powiązany, a zespół nie może szybko ocenić poprawności wyniku.

Szybsze generowanie kodu jest jedynie elementem procesu. Liczy się szybsze i bezpieczniejsze dostarczenie działającego rozwiązania.

CO TO ZMIENIA

ERP może pozostać rdzeniem, a oprogramowanie szyte na miarę obsługiwać różnice

Tradycyjna ekonomia ERP opierała się na rozsądnym założeniu: oprogramowanie dopasowane do konkretnej firmy było kosztowne, ponieważ ludzie musieli opisać, napisać, przetestować i utrzymywać każdy jego element.

To założenie sprawiało, że standaryzacja była konieczna.

Agentowe wytwarzanie oprogramowania nie eliminuje kosztów pracy inżynierskiej. Zmniejsza jednak nakład pracy potrzebny do wykonania odpowiednich elementów implementacji. Dzięki temu wyspecjalizowana warstwa oprogramowania staje się ekonomicznie uzasadniona w większej liczbie przypadków.

Nowy model wygląda następująco:

• ERP pozostaje centralnym systemem ewidencyjnym i źródłem danych.

• Standardowe procesy pozostają w sprawdzonych modułach.

• Procesy specyficzne dla firmy otrzymują dedykowane interfejsy.

• Integracje automatycznie przenoszą dane między systemami.

• Moduły operacyjne są dostarczane etapami.

• Oprogramowanie szyte na miarę rozszerza rdzeń zamiast go zastępować.

Nie jest to przejście od ERP do braku ERP.

To odejście od oczekiwania, że jeden produkt obsłuży wszystko. Stabilny rdzeń może zostać połączony z oprogramowaniem zaprojektowanym wokół tych elementów działalności, które rzeczywiście wyróżniają daną firmę.

Dla operatora przemysłowego może to oznaczać panel planowania uwzględniający rzeczywiste ograniczenia i czasy przezbrojeń, workflow jakościowy zgodny z faktyczną ścieżką zatwierdzania albo interfejs flotowy pokazujący trzy wskaźniki, których standardowa platforma nigdy nie uwzględniała.

Nie chodzi o modyfikowanie wszystkiego.

Chodzi o to, aby przestać wciskać najważniejsze i wyróżniające procesy firmy w generyczny interfejs, jeżeli wyspecjalizowana warstwa może obsłużyć je lepiej.

CZEGO AI NIE ZMIENIA

Trudne decyzje nadal pozostają trudne

AI może wygenerować więcej kodu. Nie może zdecydować, jak powinna działać firma.

Zespół nadal musi ustalić:

• Który proces warto zmienić.

• Który system jest właścicielem poszczególnych danych.

• Gdzie wymagana jest decyzja lub akceptacja człowieka.

• Jak powinny działać uprawnienia i ścieżki audytowe.

• Co ma się wydarzyć, gdy integracja przestanie działać.

• Które sytuacje wyjątkowe mają znaczenie w rzeczywistej działalności.

• Kto będzie właścicielem rozwiązania po jego uruchomieniu.

Wygenerowane testy są przydatne tylko wtedy, gdy wcześniej zdefiniowano właściwe zachowanie systemu. Wygenerowane integracje nadal trzeba sprawdzić na rzeczywistych API, uprawnieniach i danych. Kod wygenerowany przez AI nadal wymaga kontroli bezpieczeństwa, monitorowania oraz odpowiedzialnej weryfikacji.

Kontrola jakości nie zniknęła. Przesunęła się na wyższy poziom procesu.

DECYZJA

Nie pytaj, czy należy zastąpić ERP. Zapytaj, gdzie ERP powinno się kończyć

Przez sześćdziesiąt lat koszty tworzenia oprogramowania kierowały firmy w stronę uniwersalnych systemów. Systemy te przyniosły ogromną wartość. Stworzyły również powtarzający się kompromis: organizacja zyskiwała standaryzację, ale czasami traciła dopasowanie do rzeczywistych operacji.

Praktyczne pytanie w 2026 roku nie brzmi, czy każda firma powinna zbudować własne ERP. Większość nie powinna.

Lepsze pytania brzmią:

1. Które procesy są standardowe i powinny takie pozostać?

2. W których miejscach organizacja regularnie płaci podatek w postaci arkuszy, ręcznego przepisywania danych, akceptacji e-mailowych lub ręcznych uzgodnień?

3. Czy dany workflow jest na tyle ważny, specyficzny i ograniczony, aby uzasadniał stworzenie dedykowanego modułu operacyjnego?

Jeżeli odpowiedź na trzecie pytanie brzmi „tak”, projekt nie musi rozpoczynać się jako wieloletni program wymiany całego systemu. Może zacząć się od jednego problematycznego procesu, jednej kontrolowanej integracji i jednego mierzalnego rezultatu.

Na tym polega zmiana.

ERP pozostaje kręgosłupem organizacji. Oprogramowanie szyte na miarę staje się praktyczne na jego obrzeżach. AI zmienia koszt budowania połączenia między tymi dwoma warstwami.

Na tym modelu opiera się TailoredByte: doświadczeni inżynierowie wykorzystują dostarczanie wspierane przez AI, aby budować wyspecjalizowane oprogramowanie operacyjne w tygodnie — tam, gdzie pozwala na to dobrze określony zakres.

Bez udawania, że architektura, bezpieczeństwo i odpowiedzialność stały się automatyczne.

Najczęściej zadawane pytania

Kiedy powstały systemy ERP?

Współczesne ERP wywodzi się z systemów MRP rozwijanych od lat 60. XX wieku na potrzeby planowania produkcji i zapasów. Pojęcie enterprise resource planning pojawiło się na początku lat 90., gdy systemy te zaczęły obejmować finanse, sprzedaż, zakupy, kadry i inne funkcje przedsiębiorstwa.

Czym różni się MRP od ERP?

MRP koncentruje się przede wszystkim na potrzebach materiałowych i produkcyjnych: co jest potrzebne, w jakiej ilości i w którym momencie. ERP łączy znacznie szerszy zakres funkcji biznesowych za pomocą wspólnych procesów i danych.

Jak chmura zmieniła systemy ERP?

Chmura ograniczyła ilość infrastruktury, którą firmy muszą utrzymywać samodzielnie. Uprościła również dostęp do systemu, aktualizacje i zakup oprogramowania w modelu abonamentowym. Nie rozwiązała jednak automatycznie problemów związanych z integracjami, modyfikacjami i dopasowaniem procesów.

Jak AI zmienia tworzenie systemów ERP?

AI wspiera generowanie kodu, testowanie, dokumentację, refaktoryzację i prace integracyjne. Agenci kodujący mogą również wykonywać wieloetapowe zadania obejmujące całe repozytorium. Może to skrócić odpowiednie elementy procesu dostarczania, ale architektura, reguły biznesowe, bezpieczeństwo i decyzje wdrożeniowe nadal wymagają odpowiedzialności człowieka.

Czy AI zastąpi programistów ERP?

AI prawdopodobnie zmieni rolę programisty, zamiast całkowicie ją usunąć. Inżynierowie będą poświęcać mniej czasu na powtarzalną implementację, a więcej na definiowanie wymagań, kontrolowanie architektury, weryfikowanie rezultatów i zarządzanie jakością.

Czy każda firma potrzebuje własnego systemu ERP?

Nie. Standardowe systemy ERP i produkty SaaS nadal pozostają najlepszym wyborem dla wielu typowych procesów. Oprogramowanie szyte na miarę jest najbardziej przydatne tam, gdzie workflow jest istotny operacyjnie, specyficzny dla organizacji i niewystarczająco obsługiwany przez dostępne produkty.

W którym miejscu Twój ERP przestaje pasować do operacji?

Pokaż nam arkusz, ręczne przekazanie zadania albo ścieżkę zatwierdzania, która nieustannie wraca jako problem.

Podczas jednej 30-minutowej rozmowy powiemy Ci, czy ten proces powinien znaleźć się w ERP, wokół niego, czy w ogóle nie wymaga budowy dedykowanego rozwiązania.

Umów rozmowę o zakresie projektu z TailoredByte.