Ami megfordult
A megírás ára leesett, a döntés logikája még nem követte
Húsz éven át egyszerű volt a szabály a közepes és nagy cégeknél. Amit a piacon meg lehetett venni, azt megvették, mert a saját fejlesztés lassú volt, drága, és a belső IT sorában mindig akadt fontosabb feladat. Kivétel csak az volt, ami a cég valódi versenyelőnyét adta, és ott is inkább egy külső fejlesztőházra bízták a munkát.
Ez a számtan az elmúlt egy évben borult fel. A kódoló ügynökök, a Claude Code és társai, ma már egy jó belső elemző vagy egy tapasztaltabb kontrollingos kezében is működő alkalmazást adnak ki, nem csak egy fejlesztő kezében. Egy belső riportfelület, egy jóváhagyási munkafolyamat vagy egy raktári beosztó táblázat, amihez régen három hónap és egy beszerzési eljárás kellett, ma egy vagy két hét munka.
A McKinsey augusztusi State of AI felmérése számszerűsítette is, amit a projektjeimen hónapok óta látok. A megkérdezett szervezetek 32 százaléka legalább egyszer már úgy döntött, hogy nem vesz meg egy szoftvert vagy funkciót, mert kódoló ügynökkel házon belül megépíti. Azoknál a cégeknél, amelyek az AI-ból már mérhető eredményt termelnek, ez az arány közel a fele.
A döntési szokások viszont a régiek maradtak. A beszerzés továbbra is licencet, szerződést és szállítói kockázatot vizsgál, a saját építést pedig senki nem vizsgálja, mert papíron nincs mit. Szerződés, számla és jóváhagyási kör sem keletkezik. Éppen ettől lesz veszélyes.
A rejtett oldal
Amit a prototípus ára nem mutat meg
A két hetes prototípus a kódírás költségét mutatja. Egy üzleti szoftver teljes költségének viszont ez a kisebbik része, és ez a régi szoftveres szabály az ügynökök korában is érvényes maradt. A nagyobbik részt a birtoklás adja. Frissíteni kell, ha változik a mögötte lévő adatforrás. A jogosultságokat kezelni kell, amikor belép vagy kilép egy kolléga. Az auditor pedig egyszer megkérdezi, ki fért hozzá az adatokhoz és mikor, és erre valakinek válaszolnia kell.
Az egyik pénzügyi holding kontrolling csapatánál ezt a saját bőrünkön tanultuk meg. A csapat egyik tagja fél év alatt négy kis alkalmazást épített, egy konszolidációs segédet, egy költséghely ellenőrzőt és két riportfelületet. Mind működött, és a csapat szerette őket. Aztán a kolléga átment egy leányvállalathoz, és kiderült, hogy a négy alkalmazásból kettőt senki nem tud elindítani, mert a hozzáférési kulcsok az ő gépén voltak, a dokumentáció pedig a fejében.
Ismerős minta, csak gyorsabb. Így halmozódtak fel a kilencvenes és kétezres években a senki által nem értett Excel makrók és Access adatbázisok, amelyek egy részét a nagyobb cégek ma is cipelik. A különbség annyi, hogy ami akkor évekig épült, az most hetek alatt.
Amikor ezt végigszámoltuk a holdingnál, a saját építés még mindig olcsóbbnak jött ki, mint a piaci alternatíva. Csak nem tizedannyiba került, ahogy elsőre gondolták, hanem nagyjából a felébe. Ez még mindig jó üzlet, de egészen más döntés.
Hol van értelme
Mit építsen meg a cég, és mit vegyen meg továbbra is
Azt tapasztaltam, hogy a jó döntés ritkán az eszközön múlik. Sokkal inkább azon, milyen természetű a feladat, amit a szoftver elvégez. A saját építés ott hoz valódi hasznot, ahol a cég folyamata eltér a piaci átlagtól, és a dobozos termék ezt a különbséget csak kompromisszumokkal tudná lekövetni.
Egy 400 fős logisztikai cégnél a raktári műszakbeosztás volt ilyen. A piaci termék egy általános beosztási logikát kínált, a cégnél viszont három telephely, két szakszervezeti megállapodás és egy nagyon egyedi szezonális csúcs miatt minden hónapban kézzel kellett felülírni a gép javaslatát. A kódoló ügynökkel épített belső eszköz ezt a helyi logikát tudta, és a műszakvezetők két hét után már nem nyúltak hozzá utólag.
A mérlegelésnél négy jel szól a saját építés mellett.
- A folyamat a cégre szabott, és ez a sajátosság értéket termel, nem csak megszokás.
- A felhasználói kör belső és szűk, néhány tucat ember, nem ügyfelek ezrei.
- A szabályozási tét alacsony, nincs mögötte hatósági adatszolgáltatás vagy tanúsítási kötelezettség.
- A működés gyakran változik, és a szállítói fejlesztési ciklusra várni lassabb lenne.
Ahol ezek fordítva állnak, ott a vásárlás marad a jobb út. Bérszámfejtést, főkönyvet, számlázást vagy bármit, ami a NAV felé ad adatot, nem építenék házon belül akkor sem, ha az ügynök egy délután alatt összerakna egy működő változatot. Ezeknél nem a funkció a drága, hanem a jogszabályváltozások követése és a felelősség, amit a szállító átvállal. Ugyanez áll a biztonsági és identitáskezelő rendszerekre, ahol egy apró hiba költsége sokszorosa bármilyen licencdíjnak.
A kettő között van egy szürke sáv, és itt dől el a legtöbb vita. Egy CRM kiegészítő, egy ajánlatkészítő vagy egy belső tudásbázis felülete egyszerre lehet a cégre szabott és üzletileg érzékeny. Ilyenkor azt javaslom az ügyfeleimnek, hogy a vásárolt rendszer maradjon a gerinc, és a saját építés csak a szélein dolgozzon. A főkönyv, a CRM vagy az ERP adja az adatot és a jogosultságot, a kódoló ügynökkel írt réteg pedig azt a néhány képernyőt vagy automatizmust, amit a szállító sosem fog a cég kedvéért megírni. Így a kockázatos rész egy felelős szállítónál marad, a gyorsan változó rész pedig házon belül, ahol a változtatás napokban mérhető. Az egyik ügyfelemnél ez a felosztás azt is eldöntötte, hogy az IT mit tart meg magának. A gerincrendszerekhez ők nyúlnak, a peremre épülő alkalmazásokat viszont az üzleti oldal is építheti, egy közös szabálykönyv mentén.
Ami közben elszaporodik
Az árnyék szoftver, a shadow AI kistestvére
Korábban írtam arról, hogy a tiltott AI használat a legtöbb cégnél már jelen van, akár engedik, akár nem. A kódoló ügynökökkel ennek egy új változata jelent meg. A kollégák nemcsak használják az AI-t, hanem alkalmazásokat is építenek vele, és ezek egy része csendben üzleti folyamatot kezd kiszolgálni.
Egy kreatív ügynökségnél, ahol 35 fő dolgozik, egy belső leltár során kilenc ilyen mini alkalmazás került elő. A többségük ártalmatlan volt, egy időkövető, egy briefgenerátor, egy prezentációs sablonkezelő. Az egyik viszont ügyfelek kampányadatait tartotta egy nyilvánosan elérhető linken, jelszó nélkül, mert a készítője a gyors megosztást tartotta szem előtt, és eszébe sem jutott, hogy ez kockázat. Senki nem követett el rosszhiszemű hibát. Egyszerűen senki nem nézte meg.
Ebből a projektből azt vittem tovább, hogy a tiltás itt sem működik jobban, mint a chat eszközöknél. A kollégák azért építenek, mert gyorsabban akarnak dolgozni, és ez jó szándék. Ami működik, az egy könnyű regisztráció. Minden belső alkalmazásnak legyen neve, gazdája, egy mondatos leírása arról, milyen adatot kezel, és egy helye, ahol a cég látja, hogy létezik. Ez egy közös táblázatban is elkezdhető, és már az első hónapban megmutatja, hol van valódi kockázat.
A döntési kör
Négy kérdés, mielőtt a prototípusból éles rendszer lesz
A legtöbb bajt nem az okozza, hogy egy cég saját eszközt épít. Az okozza, hogy a prototípus észrevétlenül átcsúszik éles használatba, anélkül hogy bárki kimondaná, mostantól ez egy üzleti rendszer. Az ügyfeleimnél ezért egy rövid kapu került a kettő közé, amin minden belső alkalmazásnak át kell mennie, mielőtt egy csapatnál több ember kezdené használni.
- Ki lesz a gazdája két év múlva, ha a mostani készítője már máshol dolgozik?
- Mi történik a folyamattal, ha holnap reggel leáll, és mennyi idő alatt lehet visszaállni a régi módszerre?
- Milyen adat megy át rajta, és ki fér hozzá ma, a tervezett hozzáférésen túl?
- Mennyi a belső órák valós ára három évre vetítve, a karbantartást és a frissítéseket is beleszámolva, a megvásárolható alternatíva teljes költségéhez képest?
Ha az első kérdésre nincs név, a többit nem is nézzük. Ez a legegyszerűbb szűrő, és a tapasztalatom szerint a belső alkalmazások harmadát már itt visszaküldi prototípus státuszba. Nem azért, mert rosszak, hanem mert egyetlen ember fejében élnek.
A negyedik kérdésnél a legtöbb cég elcsúszik, mert a belső munkaórát ingyenesnek érzi. Egy kontrollingos vagy elemző órája nem ingyenes, csak nem jelenik meg külön számlán. Amikor egy gyártócégnél ezt először kiszámoltuk egy belső minőségügyi nyilvántartásra, kiderült, hogy a karbantartás évi költsége nagyjából a vásárolt termék licencdíjának kétharmada lett volna. Végül megvették a terméket, és a belső prototípus a követelményspecifikáció alapja lett, amivel a bevezetés a szokásosnál jóval gyorsabban ment.
A beszerzési asztalnál
Az új alkupozíció, amit a szállítók is érzékelnek
Van a jelenségnek egy kevésbé látványos, de pénzben jól mérhető hatása. A saját építés lehetősége akkor is megváltoztatja a tárgyalást, ha a cég végül nem él vele. A bevezetőben említett licencmegújításon a szállító az első körben még tartotta az árat. Amikor a prototípus bemutatója után a beszerzési vezető elmondta, hogy a cég komolyan fontolgatja a saját utat, a második ajánlat harmincöt százalékkal alacsonyabb lett, és bekerült egy rugalmasabb kilépési feltétel is.
A szállítók ezt a nyomást a saját számaikon is látják. A dobozos szoftverek egy részénél, főleg a vékony, néhány képernyőből álló eszközöknél, a vevő ma reálisan fel tudja tenni a kérdést, hogy mit kap a licencért azon túl, amit egy jól megírt belső eszköz tudna. A jó szállító erre a felelősségvállalással, a támogatással és a folyamatos fejlesztéssel válaszol. A gyengébbje árengedménnyel.
A magyar közép- és nagyvállalatoknál azt látom, hogy ez a helyzet még csak most kezd tudatosulni. A beszerzés ritkán tud a belső prototípusokról, az IT pedig ritkán ül ott a licencmegújításoknál. Ahol a kettő egy asztalhoz kerül, ott a szoftverportfólió egy része két év alatt a cég saját folyamatára szabott, belül karbantartott eszközökre cserélődik, a többiért pedig a cég kevesebbet és jobb feltételekkel fizet.
A kódoló ügynök így végül nem a fejlesztési költséget írja át a legjobban, hanem azt, hogy ki ül erősebb pozícióban a szerződés aláírásakor, és ezt a pozíciót az a cég tudja kihasználni, amelyik előbb tisztázza, mit akar valóban a sajátjának tudni.