Bevezetés
Ne cserélj ERP-t. Építs rá.
Aki két évet költött egy rendszer bevezetésére, nem akar újabb migrációt. Miért a meglévő rendszerekre építés az egyetlen járható út, és hogyan csináljuk.
Van egy mondat, ami után minden AI-ajánlat halott:
Ehhez először le kellene cserélni azt a rendszert.
Ha a cégnél valaki két évet és sokmillió forintot költött egy ERP bevezetésére, ez a mondat nem technikai javaslat. Ez annak a bejelentése, hogy az illető munkája hiábavaló volt.
Miért nem működik a migráció-alapú ajánlat
Mert valaki felelős érte. Az a rendszer valakinek a projektje volt. A lecserélése az ő értékelése.
Mert a költség nem a licenc. Az igazi költség az adatmigráció, a betanítás, a párhuzamos üzem és a hat hónap csökkent teljesítmény. Ezt mindenki tudja, aki egyszer átélte.
Mert a kockázat összeadódik. Egy AI-bevezetés önmagában is új és bizonytalan. Ha migrációval kötöd össze, akkor két bizonytalan projekt szorzatát kapod.
Amit helyette csinálunk
A meglévő rendszer marad az igazság forrása. Köré épül egy réteg, ami
- kiolvassa, ami kell (API-n, vagy amit a rendszer tud),
- elvégzi a munkát, ami ma kézzel megy,
- és visszaírja az eredményt ugyanoda, ahova a kolléga is írná.
A felhasználó szempontjából a NetSuite marad NetSuite, az SAP marad SAP. Csak a mezők egy része már ki van töltve, amikor odaér.
Ez a legerősebb érv az elfogadtatásnál. Nem kell új felületet megtanulni, nem kell jogosultságokat újratervezni, nem kell a betanítást újrakezdeni.
Az integrációs valóság
A gyakorlatban négy szinten lehet egy rendszerhez kapcsolódni, csökkenő sorrendben.
1. Dokumentált API. A legjobb eset. Verziózott, támogatott, tesztelhető.
2. Nem dokumentált, de létező API. A legtöbb modern rendszernek van belső API-ja, amit a saját felülete használ. Használható, de a szállítóval tisztázni kell, hogy nem sérti-e a szerződést.
3. Adatbázis-szintű olvasás. Sok helyen ez a leggyorsabb út a kiolvasásra. Írásra viszont ritkán jó ötlet: megkerüli az alkalmazás üzleti logikáját.
4. Felületi automatizálás. Végső eset. Működik, de törékeny: minden felületfrissítés eltörheti. Ha ide kényszerülünk, az auditban külön kiírjuk a fenntartási költséget, hogy ne később derüljön ki.
A legtöbb magyar középvállalatnál vegyes kép van: az ERP-hez van API, az iktatóhoz nincs, a Excel-táblákhoz meg minek.
Hogy ne legyen belőle gubanc
Két szabályt tartunk.
Az üzleti logika nem az integrációban lakik. Az adapter csak fordít: onnan olvas, ide ír. Amit a rendszer csinál, az külön van. Így ha egyszer tényleg lecserélitek az ERP-t, egy adaptert kell újraírni, nem a rendszert.
Minden írás naplózva és visszavonható. Amit a rendszer beírt, arról tudni kell, hogy ő írta be, mikor, és mi alapján. Ha valami félremegy, ki kell tudni szedni — anélkül, hogy kézzel kellene átnézni háromezer tételt.
Mit mondj a szponzorodnak
Ha belül próbálod eladni, ez a keret működik:
Nem nyúlunk a rendszerhez, amit bevezettél. Ráépítünk egy réteget, ami elvégzi azt a munkát, amit ma emberek gépelnek át egyik felületről a másikra. Ha nem válik be, kikapcsoljuk, és minden marad, ahogy volt.
Az utolsó tagmondat a legfontosabb. A visszafordíthatóság az, ami eladja.
Kapcsolódó: miért bukik meg az AI-pilotok többsége.
Kérdések ehhez a témához
Mi van, ha a rendszernek tényleg nincs API-ja?
Akkor is van út: adatbázis-szintű olvasás, ütemezett export-import, vagy végső esetben felügyelt felületi automatizálás. Ez utóbbi törékenyebb, ezért az auditban külön jelezzük a kockázatát és a fenntartási költségét.
Nem lesz így technikai adósság a régi rendszer köré építve?
A réteg, amit építünk, szándékosan leválasztható. Az üzleti logika nálunk van, nem az integrációban — ha egyszer tényleg lecserélitek az ERP-t, az adaptert kell újraírni, nem az egészet.
Ez nálatok hogy néz ki?
Ha ez a probléma ismerős, kezdjük egy folyamattal. Írjátok meg, melyik részleg viszi el a legtöbb kézi munkaórát — visszaírunk egy konkrét javaslattal.