Architektura Zero-Trust — dlaczego nie ruszamy Twojego ERP

Pół miliarda euro na oprogramowanie, które nigdy nie zadziałało

Lidl

Wydał 580 milionów euro na wdrożenie SAP-a. Siedem lat pracy, setki konsultantów, niezliczone godziny warsztatów, migracji danych, testów. A potem projekt trafił do kosza. Cały. Bo system nie pasował do sposobu, w jaki Lidl zarządza zapasami. I zamiast zmienić system, próbowano zmienić Lidla.

Birmingham City Council

Zabudżetował 46 milionów funtów na Oracle Cloud ERP. Końcowy rachunek: 114 milionów.

Gartner szacuje, że 70% wdrożeń ERP nie osiągnie założonych celów biznesowych do 2027 roku. Panorama Consulting mówi wprost: tylko 23% wdrożeń uznaje się za udane.

Te liczby nie dotyczą małych firm z garażowymi systemami. Dotyczą największych organizacji na świecie, z budżetami IT liczonymi w dziesiątkach milionów, z zespołami złożonymi z najlepszych specjalistów. A mimo to — porażka za porażką.

Dlaczego o tym piszemy w artykule o architekturze Zero-Trust? Bo odpowiedź na te porażki to punkt wyjścia naszej filozofii.

Skąd pochodzi termin i co naprawdę oznacza

Zero Trust narodził się w cyberbezpieczeństwie. Idea jest prosta i bezwzględna: nie ufaj nikomu. Nie ufaj użytkownikowi, który jest w sieci firmowej — może to nie on. Nie ufaj urządzeniu, które było bezpieczne wczoraj — dziś mogło zostać skompromitowane. Każdy dostęp weryfikuj. Każdy. Za każdym razem.

Rynek rozwiązań Zero Trust w cyberbezpieczeństwie osiągnął 22–34 mld USD w 2024 roku (Grand View Research: 34,5 mld USD, Kings Research: 19,3 mld USD). CAGR wynosi 16–17%. Ponad połowa firm z listy Fortune 500 wdraża lub planuje wdrożenie Zero Trust. To nie moda. To odpowiedź na rzeczywistość, w której 57% incydentów bezpieczeństwa w 2022 roku stanowiły cyberataki (IT Governance).

Ale w QA10 wzięliśmy tę zasadę — „nie ufaj, weryfikuj” — i zastosowaliśmy ją do czegoś innego. Do integracji systemów.

Zero Trust w wydaniu QA10: nie ruszaj tego, co działa

Twoje ERP działa. Może nie idealnie. Może jest za wolne, może interfejs pamięta czasy Windows XP, może raporty trzeba wyciągać ręcznie. Ale działa. Twoi ludzie znają ten system. Procesy są w nim zakodowane — nie tylko w sensie informatycznym, ale w sensie organizacyjnym. Ktoś wie, że faktura z dostawcą X idzie inną ścieżką niż z dostawcą Y, bo trzy lata temu ustalono wyjątek, który nigdzie nie jest zapisany, ale wszyscy o nim wiedzą.

Teraz wyobraź sobie, że wymieniasz ten system na nowy. Wszystkie te nieformalne ścieżki, te niby-błędy, które w praktyce są obejściami — znikają. Dane trzeba zmigrować. Format się nie zgadza. 49% organizacji ma problemy z migracją danych podczas wdrożeń ERP — i to nie są problemy, które widać na etapie planowania. Pojawiają się trzeciego dnia po uruchomieniu, kiedy okazuje się, że tysiąc rekordów z historycznymi cenami zniknęło w nicości.

Nasza filozofia jest odwrotna. Nie wymieniamy. Nadbudowujemy.

Architektura Zero-Trust w QA10 oznacza: budujemy warstwę inteligencji nad Twoimi obecnymi systemami. ERP zostaje. WMS zostaje. CRM zostaje. Nasza warstwa czyta z nich dane, analizuje je, automatyzuje procesy — ale nie zmienia ani jednej linii kodu w Twoim oprogramowaniu. Działamy obok, nie wewnątrz.

Dlaczego? Bo nie ufamy, że wymiana systemu pójdzie gładko. Dane mówią, że nie pójdzie. 55–75% wdrożeń ERP kończy się niepowodzeniem. To nie pesymizm — to inżynierska ostrożność.

Jak to wygląda w praktyce

Weźmy konkretny scenariusz. Firma produkcyjna z 200 pracownikami. ERP sprzed ośmiu lat — działa, ale nie rozmawia z systemem magazynowym. Dane o stanach magazynowych trzeba ręcznie weryfikować co rano. Dwa razy w miesiącu ktoś wysyła towar, którego fizycznie nie ma na regale, bo stan w systemie nie zdążył się zaktualizować.

Tradycyjne podejście: wymień ERP, zintegruj z WMS, zmigruj dane. Koszt? Od kilkuset tysięcy do kilku milionów złotych. Czas? 9–18 miesięcy w optymistycznym scenariuszu. Ryzyko? Patrz statystyki powyżej.

Podejście Zero-Trust QA10: budujemy warstwę pomiędzy. Nasz system czyta stany z ERP i z WMS-a jednocześnie, porównuje je w czasie rzeczywistym, flaguje rozbieżności i — jeśli reguły na to pozwalają — koryguje automatycznie. ERP dalej działa jak działał. WMS dalej działa jak działał. Żaden użytkownik nie musi się przeuczać. Żadne dane nie są migrowane. A problem z wysyłką nieistniejącego towaru znika pierwszego dnia.

To jest sedno Zero-Trust w naszym rozumieniu: system bazowy nie jest „zaufany” — jest monitorowany, weryfikowany i uzupełniany z zewnątrz. Tak jak w cyberbezpieczeństwie nie ufasz użytkownikowi w sieci, tak my nie ufamy, że ERP daje Ci pełny obraz sytuacji. Weryfikujemy go danymi z innych źródeł. Ciągle.

Trzy powody, dla których nadbudowa wygrywa z wymianą

Pierwszy — czas. Nadbudowa nad istniejącym systemem to tygodnie. Wymiana ERP to miesiące, często lata. W tym czasie biznes nie stoi w miejscu — rynek się zmienia, klienci odchodzą, konkurencja wdraża to, co Ty dopiero planujesz.

Drugi — ryzyko. Nadbudowa nie dotyka danych źródłowych. Najgorsze, co może się zdarzyć, to że nowa warstwa nie zadziała — ale stary system dalej funkcjonuje. Przy wymianie ERP najgorsze, co może się zdarzyć, jest dużo gorsze. Lidl może potwierdzić.

Trzeci — ludzie. Zmiana systemu oznacza przeszkolenie wszystkich użytkowników. To nie jest prezentacja na sali konferencyjnej. To tygodnie frustracji, spadek produktywności, opór — bo człowiek, który od pięciu lat wie, gdzie kliknąć, nagle musi się tego nauczyć od nowa. Nadbudowa minimalizuje tę zmianę. Użytkownik widzi nowe funkcje, ale fundament, na którym pracuje, pozostaje ten sam.

Kiedy wymiana systemu ma sens — bo czasem ma

Bylibyśmy nieuczciwi, gdybyśmy twierdzili, że nadbudowa jest odpowiedzią na wszystko. Nie jest.

Jeśli Twój ERP jest tak stary, że producent zakończył wsparcie techniczne — żadna nadbudowa nie zmieni faktu, że pracujesz na tykającej bombie. Jeśli architektura systemu uniemożliwia wyciąganie danych w jakimkolwiek formacie — nie mamy czego czytać. Jeśli organizacja przechodzi fundamentalną zmianę modelu biznesowego — nowy system może być jedyną drogą.

Ale te sytuacje są rzadsze, niż sugeruje branża IT, która żyje z wdrożeń. W większości przypadków, które widzimy — a pracujemy z firmami produkcyjnymi, logistycznymi, usługowymi — obecne systemy wystarczą jako fundament. Potrzebują inteligentnej nadbudowy, nie wymiany.

Zero-Trust jako sposób myślenia, nie tylko jako technologia

Jest coś głębszego w filozofii Zero-Trust, co wykracza poza architekturę IT. To sposób myślenia o złożoności.

Duże wdrożenia IT kończą się porażką nie dlatego, że technologia zawodzi. Forbes podaje, że 54% zakłóceń technologicznych wynika ze złego zarządzania, a tylko 3% z problemów technicznych. Systemy się nie psują. To ludzie podejmują złe decyzje o zakresie projektu, o harmonogramie, o tym, ile zmian organizacja jest w stanie wchłonąć naraz.

Zero-Trust mówi: nie próbuj zmienić wszystkiego naraz. Nie zakładaj, że wielka wymiana pójdzie gładko. Buduj przyrostowo. Weryfikuj na każdym kroku. Daj ludziom czas na adaptację. Każdą nową warstwę testuj w izolacji, zanim połączysz ją z resztą.

To nie jest ostrożność kogoś, kto boi się zmian. To ostrożność inżyniera, który wie, ile kosztuje brak ostrożności. 580 milionów euro to dobra lekcja poglądowa.

I właśnie dlatego każde wdrożenie RPA, każda automatyzacja w architekturze QA10, każdy moduł process mining i każdy projekt TRL 9 — wszystko dzieje się w paradygmacie nadbudowy. Nie ruszamy tego, co działa. Czytamy, weryfikujemy, uzupełniamy.