Az utolsó mérföld — ahol az AI-projektek csendben meghalnak

Van egy befektetési bank, amelyről a Harvard Business Review idén tavasszal írt. Kétszázötven AI-alkalmazás fut a rendszereiben. A copilot-adoptáció kilencvenkilenc százalékos — ez gyakorlatilag teljes lefedettség. Az egyéni produktivitás-javulás kétszámjegyű, amit a belső mérések is alátámasztanak.

A pénzügyi vezető mégsem találja a megtakarítást a számokban.

Nem számviteli hiba. A felszabadult idő egyszerűen eltűnt — alacsony értékű feladatokba szívódott fel, és senki sem tervezte újra, hogy mi kerüljön a helyére.

Ez nem kivétel. A HBR cikke szerint ez az átlag.

Húsz évet töltöttem el a bankszektorban, szinte mindet vezető pozícióban. Ez idő alatt több mint ötszáz digitális fejlesztési projektet támogattam, vagy vezettem — kisebb folyamat-automatizációktól a teljes ügyfélkiszolgálási rendszerek átírásáig. Volt köztük sok, amit büszkén mutattunk be a boardnak. Néhány valóban működött. Azonban több, mint amire szívesen emlékszem, nem — legalábbis nem úgy, ahogyan terveztük.

Az évek alatt kialakult bennem egy érzék arra, mikor fog egy projekt megállni. Nem a bevezetés előtt — akkor még mindenki optimista. Hanem hat-tizenkét hónappal később, amikor a lelkesedés elmúlt, a projekt-csapat feloszlott, és a rendszer ott maradt a napi munkában mint egy idegen tárgy, amit mindenki elkerül.

Most, hogy középvállalatokkal dolgozom, ugyanezt a mintát látom — kisebb léptékben, de ugyanolyan következetességgel.

A HBR cikke nevet adott ennek, amit eddig csak tapasztaltunk. Az "utolsó mérföld" problémájának.

Az utolsó mérföld

A fogalom az ellátási láncból jön. Az utolsó mérföld az a szakasz, amikor a csomag már közel van — elhagyta a raktárt, átment a rendezőn, megérkezett a városba —, de az utolsó darab, a tényleges kiszállítás az ajtóig, aránytalanul drága és nehéz. A teljes logisztikai lánc legköltségesebb része.

Az AI transzformációban ugyanez a dinamika: a technológia megvan, a pilot fut, az adoptációs számok jók — és mégis, a szervezet nem változik. Az utolsó mérföld itt nem fizikai, hanem szervezeti. A folyamatok újratervezése, a szerepkörök átalakítása, az emberek, akik félnek. Ez az a szakasz, ahol a legtöbb projekt csendben meghal.

A HBR hét strukturális súrlódási pontot azonosított. Én ebből hárommal találkoztam a legtöbbet — és azt gondolom, ezek a legfontosabbak.

Az első: a produktivitási illúzió

Az egyéni szintű hatékonyságnövekedés valós. A mérések nem hazudnak: az ember gyorsabban dolgozik, kevesebb manuális lépést tesz meg, kevesebb hibát ejt bizonyos feladatoknál.

De szervezeti szinten ez a nyereség eltűnik.

A HBR egy pénzügyi hálózat esetét írja le, ahol 99 százalékos copilot-adoptáció és kétszámjegyű egyéni produktivitásjavulás mellett a pénzügyi vezető nem talál megtakarítást a mérlegben. A magyarázat egyszerű: a felszabadult idő nem tűnik el — alacsony értékű tevékenységekbe szívódik fel. Senki nem tervezte újra, hogy mi kerüljön a helyére.

Ezt én is láttam. Egy középbanknál bevezettünk egy automatizált dokumentum-feldolgozó rendszert az ügyfélhitel-igénylési folyamatba. Az ügyintézők napi másfél órát nyertek. Hat hónappal később megkérdeztük, mit csinálnak ezzel az idővel. Az emaileket rendezik. Megbeszéléseket tartanak, amiket korábban le kellett mondani az idő hiánya miatt. Segítenek a kollégáknak. Semmilyen teljesítménymutatón nem látszott semmi.

Nem az ő hibájuk volt. Senki sem mondta el nekik, mit kellene csinálniuk a felszabadult idővel. Senki nem tervezte újra a folyamatot arra az esetre, ha az egyik lépés kiesik.

Az AI-bevezetés önmagában nem elég. Valakinek meg kell kérdeznie: ha ez a lépés automatikus lesz, mi legyen helyette? Mi az a magasabb értékű tevékenység, amire most kapacitás nyílik? És ezt nem a technológiai csapatnak kell megkérdeznie — hanem a vezetőnek, aki a szervezetet irányítja.

A második: a törzsi tudás identitásvédelme

Ez az, amiről a legkevesebbet beszélünk. Talán azért, mert kellemetlen.

Minden szervezetben vannak emberek, akik évtizedek alatt felhalmoztak valamit, amit senki más nem tud. Nem csak tudást — pozíciót. Mindenki hozzájuk fordul. Ők az, akik tudják, hogy a szabály mögött mi van, melyik kivétel az igazi kivétel, melyik folyamat az, amit papíron így írtak le, de valójában úgy kell csinálni. Ez a tudás dokumentálatlan, nem átadható, és nagyon értékes.

Az AI ezt fenyegeti.

Nem nyíltan, nem harsányan. Csendben. Ha a rendszer megtanulja a kivételeket, ha a folyamat dokumentált lesz, ha a tudás explicit lesz — mi marad annak az embernek, aki eddig a tudás őrzője volt?

A HBR ezt "törzsi tudás identitásproblémájának" nevezi. Az én megfogalmazásomban: az ember nem a munkafolyamatot védi. A helyét védi.

Volt egy ügyfelem, akinek a szervezetében dolgozott valaki, tizennyolc éven át. Mindenki hozzá fordult — folyamatok, kivételek, a szabály mögötti szabály. Ő volt a rendszer. Amikor elkezdtük az AI-projekt előkészítését, és az egyik lépés a meglévő tudás dokumentálása lett, ez az ember halogatta. Nem mondott nemet. Nem tiltakozott. Csak mindig volt egy fontosabb dolog, egy aktuálisabb tűz, amit előbb el kellett oltani.

Amikor megkérdeztem tőle, mi a valódi akadály, azt mondta: „Ha mindenki tudja, amit én tudok, mi értelme van, hogy én legyek az, aki tudja?"

Ez egy őszinte válasz. Ritka, hogy valaki ennyire nyíltan mondja ki — de a viselkedés mögött szinte mindig ez van.

A megoldás nem a nyomásgyakorlás. A megoldás az, hogy az illető számára is értéket teremtünk az új rendszerben — hogy az ő tudása ne eltűnjön, hanem magasabb szinten hasznosuljon. De ehhez fel kell ismerni a problémát. És ezt sokan nem teszik meg, mert kényelmetlenül néz ki, ha egy szervezetfejlesztési projektről azt mondjuk, hogy az emberek félnek.

A harmadik: a pilot-túltermelés

A HBR egy befektetési bankot említ, ahol kétszázötven LLM-alkalmazás fut. Egy FMCG-vállalatnál százhnyolcöt pilotprojekt fut párhuzamosan, százhnyolcöt országban. Egyik sem vált szabványos működési eljárássá.

Ez nem a tech-ipar sajátossága. Ugyanezt látom középvállalatoknál is — kisebb számban, de ugyanolyan arányban.

A szervezet elindít egy pilotot. Működik. Mindenki lelkes. A vezető büszkén mutatja be a boardnak. Aztán a projekt-csapat szétoszlik, a pilotot senki sem vezeti át éles üzembe, és hat hónappal később ott áll az eszköz valamelyik szerver szegletében, amelyet néhány lelkes ember még használ, a többség már nem.

Miért történik ez?

Részben azért, mert a pilot megmutatja, hogy a technológia működik — de nem tervezi meg, hogyan illeszkedjen a szervezet valódi működésébe. A pilot egy kontrollált környezetben fut, ahol mindenki motivált, ahol van dedikált erőforrás, ahol az akadályokat gyorsan el lehet hárítani. Az éles üzem más. Ott nincs projekt-csapat. Ott a normál munka nyomása alatt kell működnie.

Részben azért is, mert a szervezetek nem tesznek különbséget a „bizonyított lehetséges" és a „megvalósult" között. A pilotot sikerként könyvelik el — holott a pilot csak azt bizonyítja, hogy valami elvileg működhet. Hogy ténylegesen működjön, ahhoz más kell.

A kérdés, ami mindent megváltoztat

A HBR szerzői hét stratégiai pillért javasolnak. Az egyik annyira egyszerű, hogy első olvasásra átcsúszik az ember szeme: „Ha ma építenénk ezt a folyamatot a nulláról, AI-val, hogyan csinálnánk?"

Nem hogyan adjuk hozzá az AI-t ahhoz, ami már van. Hogyan terveznénk meg az egészet elölről.

Ez a kérdés brutálisan feltárja a különbséget a digitalizáció és a transzformáció között. A digitalizáció a meglévő folyamatra rácsavar egy technológiát. A transzformáció megkérdőjelezi, hogy a folyamat jó kiindulópont-e.

A bankszektorban eltöltött évek alatt tanultam valamit: a legfontosabb fejlesztések nem azok voltak, ahol jobban csináltuk, amit eddig csináltunk. Hanem azok, ahol megkérdeztük, kell-e ezt egyáltalán csinálni. Az egyik legnagyobb produktivitásjavulást egy olyan projekt hozta, amely egy folyamatot nem gyorsított meg, hanem megszüntetett — mert kiderült, hogy az csak azért létezett, mert egy régi rendszer egy régi korlátja megkövetelte, és az a korlát már rég nem állt fenn.

A kérdés felvetése könnyű. Megválaszolni nehéz — mert a válasz szinte mindig azt jelenti, hogy valamit le kell bontani, mielőtt felépíthetjük.

Az, ami látható

A HBR cikke egészségügyi biztosítóról ír, ahol az AI gyorsabban hozta felszínre a folyamatok töredezettségét, mint ahogy meg lehetett volna oldani azokat. Nem az AI volt a probléma. Az AI volt az, ami megmutatta, mi volt már eleve probléma.

Ez az AI legfontosabb, legkevésbé reklámozott tulajdonsága: nem megoldja a szervezeti problémákat, hanem láthatóvá teszi azokat. A töredezett folyamat töredezett marad — de az AI fényében hirtelen mindenki látja.

Ebből következik valami, amit fontos megérteni a bevezetés előtt: az AI-projekt nem szoftver-bevezetési projekt. Szervezetfejlesztési projekt, amelynek van egy technológiai vetülete.

Ha így közelítünk hozzá — ha a szervezetfejlesztési kérdéseket ugyanolyan komolyan vesszük, mint a technológiai kérdéseket —, akkor az utolsó mérföld nem eltűnik, de kezelhetővé válik. Ha nem, akkor lesz egy rendszerünk, amelyet senki sem használ, egy pilotunk, amelyre büszkék vagyunk, és egy CFO-nk, aki nem találja a megtakarítást a számokban.

Tíz éve dolgozom középvállalatokkal digitális fejlesztési projekteken. A legtöbb, amivel hozzájárultam a munkájukhoz, nem az volt, hogy megmutattam, melyik technológia a legjobb. Hanem az, hogy megkérdeztem: mire való ez a folyamat, és ha ma kezdenéd, hogyan csinálnád?

A kérdés egyszerű. A válasz ritkán az.

#TeljesEgy