Dlaczego ERP są takie, jakie są

Każdy system ERP obiecuje to samo. Jeden program, który spina całą firmę w jedną całość. Po kilku latach rzeczywistość wygląda inaczej. ERP pilnuje księgowości i zakupów, obok niego stoi siedem innych narzędzi, a właściciel pół dnia ręcznie przenosi dane między nimi.

Powód nie sprowadza się do jednego złego wyboru. U podstaw leży jeden mechanizm, który wraca w kilku przebraniach. Kiedy jeden system trzyma całą prawdę o firmie, to samo, co czyni go cennym, czyni go silosem. Skoro masz całą prawdę, kontrola nad nią staje się najbardziej opłacalną strategią. Dostawcy ERP nie zaczynali jako klatki. Doszli do zachowań w kształcie klatki, bo własność prawdy premiuje kontrolę. Poniżej te same siły w kilku odsłonach.

1. Paradoks jakości modułów

Dostawca ERP rozkłada siły na kilkanaście dziedzin naraz. Jego moduł CRM jest słabszy od Salesforce. Magazynowy słabszy od wyspecjalizowanych systemów WMS. Kadrowy słabszy od dedykowanych programów do HR. Stoi za tym zwykła matematyka podziału zasobów. Zespół budujący zintegrowany kombajn zawsze przegra na głębokości z zespołem, który całe życie poświęca jednej dziedzinie. Dlatego firmy kupują ERP do finansów i zakupów, gdzie naprawdę jest mocny, a do reszty dokładają lepsze narzędzia z osobna. Obiecana jedność rozpada się od pierwszego dnia.

2. Rosnące koszty wypychają w rozdrobnienie

Cennik ERP jest modułowy z założenia. Licencja podstawowa obejmuje rdzeń księgowy. Każdy kolejny moduł, czyli produkcja, CRM, magazyn czy kadry, to osobna pozycja z własną licencją, wdrożeniem i konsultingiem. Pełne wdrożenie SAP-a albo Oracle w średniej firmie potrafi kosztować od dwustu do pięciuset tysięcy dolarów, zanim system w ogóle zacznie realnie pracować. Mniejsza firma staje przed wyborem bez dobrego wyjścia. Może płacić za moduły, które są przeciętne, albo wziąć lepsze narzędzia osobno i stracić obiecaną integrację. Większość wybiera to drugie. Wysoki rachunek widać najłatwiej, ale korzeń problemu leży głębiej, w customizacji i w modelu danych, o których za chwilę.

3. Uzależnienie od dostawcy jest wbudowane w model

Tu leży sedno sprawy. Uzależnienie od dostawcy jest wpisane w model biznesowy ERP. Dostawcy budują je na pięciu poziomach naraz. Umowy są wieloletnie i odnawiają się automatycznie. Dane leżą w zamkniętych formatach, bez eksportu w całości. Integracje prowadzi się przez firmowy, zamknięty pośrednik zamiast przez standardowe API. Procesy w firmie zastygają wokół założeń narzędzia. Wiedza i nawyki zespołu przywiązują się do jednego systemu. Każdy kolejny rok podnosi koszt wyjścia. Dostawca wie, że firma na dwieście osób nie przełknie nieudanej migracji, więc przewaga w negocjacjach na stałe leży po jego stronie.

Audyty licencyjne pokazują to wprost. Oracle naliczał opłaty za Javę od liczby wszystkich pracowników, także tych, którzy z niej nie korzystają. SAP dolicza za niedolicencjonowanie po pełnym cenniku, z wsteczną opłatą za utrzymanie. Egzekucję widać też w sądach. SAP wygrał z Diageo sprawę o „dostęp pośredni", a Celonis pozwał SAP o stawianie technicznych barier w dostępie klienta do własnych danych.

4. Interfejs przecieka ze środka systemu

Najgłębsza przyczyna siedzi w modelu danych. ERP zbudowano wokół prawdy księgowej, czyli zapisu podwójnego. Sztandarowy „Universal Journal" w SAP S/4HANA, czyli tabela ACDOCA, to wciąż skonsolidowane zapisy podwójne, czyli model księgowy. Dzielenie się danymi nigdy nie było jego celem. Badacze od dekad proponowali modele otwarte na współdzielenie, jak REA. Dostawcy je odrzucali, bo przebudowa „oznaczałaby ogromne przepisywanie kodu ERP, na co nie ma zgody ze względu na koszty". Model nigdy nie został przeprojektowany pod dzielenie się danymi, ponieważ to za drogie.

Stąd bierze się krucha integracja. Interfejs integracyjny jest tylko cienkim odbiciem wewnętrznej struktury. Kiedy zmienia się środek, pęka interfejs. Przy przejściu z ECC na S/4HANA SAP ograniczył i zmienił dostępne IDoki, „bo model bazy danych pod S/4HANA jest inny". Moduły FI i CO scalono w ACDOCA, tabele klientów i dostawców połączono w Business Partner, numer materiału rozszerzono z osiemnastu do czterdziestu znaków. Mapy EDI u klientów po prostu przestają działać albo, co gorsza, działają po cichu źle. Taki interfejs jest odbiciem wnętrza i rusza się razem z nim. Stałej umowy o kształcie danych tam nie ma.

Polskie systemy, jak Enova, Comarch, Subiekt czy Macrologic, dokładają do tego swój wiek. Powstały, zanim REST API stało się standardem, przy założeniu, że to one są środkiem świata. Integracja oznacza dziś rozszyfrowywanie nieopisanych interfejsów, opłacanie zamkniętego pośrednika albo czytanie wprost z tabel w bazie. Kiedy system powstaje jako jedyny w firmie, dogadywanie się z innymi nigdy nie trafia wysoko na listę priorytetów.

5. Wdrożenie traktowane jak linia mety

To wraca w rozmowach z praktykami raz za razem. ERP rusza, integrator pakuje się i wychodzi, a system od tego dnia zaczyna się sypać. Ludzie wracają do Excela, bo w ERP najprostsza rzecz wymaga zbyt wielu kliknięć. Nikt nie pielęgnuje systemu jak żywego organizmu. Procesy zastygają wokół ograniczeń narzędzia, a po trzech latach zmiana systemu przestaje mieć ekonomiczny sens, bo najpierw trzeba by przeprojektować całą firmę.

Skala tego problemu jest policzalna. Gartner szacuje, że około siedemnastu tysięcy klientów SAP ECC, czyli mniej więcej połowa bazy, nie zdąży przed końcem wsparcia w grudniu 2027 roku, a jako główną barierę wskazuje ciężką customizację. Około sześćdziesięciu procent migracji wchodzi po terminie albo ponad budżet. Sam SAP ma na tę chorobę nazwę, „Clean Core", i tłumaczy, że wbudowany własny kod czyni system „trudnym w utrzymaniu i drogim w aktualizacji, a każdą aktualizację zmienia w ryzykowny, czasochłonny projekt". Dostawca opisuje własną słabość we własnej mapie drogowej.

6. Założenie monolitu

ERP projektowano przy założeniu, że jeden dostawca jest właścicielem całego modelu danych w firmie. Z takiego założenia wynika prosto, że system nie umie spokojnie żyć obok innych. A żyć obok innych musi, bo w realnej firmie stoi w towarzystwie siedmiu czy ośmiu narzędzi. Wtedy rolę spinacza przejmuje właściciel i pół dnia przenosi informacje z systemu do systemu. Problem, który ERP miał rozwiązać, staje się trwałym stanem firmy.

7. Najtrudniejsze pytanie brzmi: kto jest właścicielem znaczeń

Programy „jednej wersji prawdy" i zarządzania danymi podstawowymi upadają mniej więcej w trzech czwartych przypadków. Powody są w przeważającej części organizacyjne. Analitycy Forrestera ujmują to wprost: ryzyko rośnie, gdy dział IT przejmuje na własność nie tylko narzędzie, ale też definicje i reguły biznesowe, które powinny pochodzić od ludzi z biznesu. To, co znaczy „Klient" i „Zamówienie", razem z polami, regułami i akcjami, ląduje w IT albo u dostawcy. Hydraulika okazuje się tu najłatwiejsza. Najtrudniejsze jest to, kto jest właścicielem znaczeń. Rozpoznawanie i scalanie duplikatów bywa trudne technicznie, ale o upadku projektu i tak przesądzają czynniki ludzkie.

Pętla, która to przypieczętowuje

Najlepszy dowód, że rzecz jest strukturalna, daje sam SAP. ERP nie poradził sobie z halą produkcyjną. Recenzenci w Gartnerze pisali wprost, że system „nie sprawdzał się na produkcji". Odpowiedzią SAP-a jest kolejna warstwa spinająca, SAP Digital Manufacturing Cloud, sprzedawana jako „warstwa łącząca ERP z fizyczną produkcją", bo „tradycyjny ERP nie radził sobie ze śledzeniem w czasie rzeczywistym tego, co dzieje się na hali". Warstwa spinająca rodzi kolejne warstwy spinające. Dostawca sam pokazuje ten los w ruchu.

Wzorzec w pigułce

ERP obiecuje jedność → koszty rosną, moduły rozczarowują → firma i tak dokupuje osobne narzędzia → ERP zostaje wyspą księgową → dostawca pobiera rentę z uzależnienia → właściciel zostaje w pułapce, a dane dalej są rozbite.

Obietnica jedności nie była technicznie fałszywa. Zawiodła z powodów ekonomicznych i organizacyjnych, wpisanych w ten model biznesowy.

Co z tego wynika

Firma potrzebuje warstwy, która jest elastyczna, ma porządne API, trzyma dane w otwartym formacie i spokojnie żyje obok systemów, które już ma. Takiej, którą sztuczna inteligencja potrafi czytać i na której potrafi działać. O tym, jak ją zbudować, piszemy w Przedstawiamy Generative Layer Uplink. Zasady, które trzymają tę warstwę z dala od pułapek ERP, zebraliśmy w Proklamacjach GLU.

Źródła

• Dyskusja praktyków o tym, czemu firmy i tak kupują osobne narzędzia: r/ERP
• Całkowity koszt posiadania ERP: Fidelio ERP
• Przewodnik po uzależnieniu od dostawcy ERP: Tier2 Systems
• Dlaczego wdrożenia ERP sypią się po starcie: r/ERP