Rengeteget írnak arról, hogyan kell elindítani egy AI projektet. Arról szinte semmit, hogyan kell abbahagyni. Pedig a tanácsadói munkám egyik legnehezebb pillanata mindig ugyanaz, amikor a vezetővel szemben ülve azt kell mondanom, hogy ezt itt most érdemes lezárni. Nem azért, mert az AI nem működik, hanem mert ez a konkrét próbálkozás nem visz sehova.
A leállítás azért ilyen nehéz, mert a cégeknél a kudarc kimondása személyes kockázat. Aki elindította a projektet, az a nevét adta hozzá. Aki most leállítaná, az mintha azt mondaná, hogy tévedtünk. Ezért inkább mindenki hallgat, a projekt pedig nem hal meg, csak lassan elalszik. Ez a legdrágább kimenetel, mert nem szabadít fel se pénzt, se figyelmet, se embert.
Miért nehezebb ez az AI-nál, mint máshol
Egy hagyományos beruházásnál viszonylag hamar látszik, ha nem működik. A gép nem termel, a szoftver nem indul el, a szám nem jön ki. Az AI projekteknél ez a visszajelzés sokkal homályosabb, és ennek három oka van.
Az első, hogy az AI szinte mindig produkál valamit. Ad választ, ír szöveget, összefoglal. Ettől a projekt élőnek tűnik akkor is, ha a kimenetét senki nem használja igazán. Egy demó mindig működik, és ez sokáig el tudja fedni, hogy a napi munkába semmi nem került be.
A második, hogy a technológia gyorsan változik, és ez örök reményt ad. Mindig jön egy új modell, egy új verzió, amitől majd jobb lesz. Ez a várakozás önmagában képes évekig életben tartani egy halott projektet, mert mindig van indok a következő körre.
A harmadik, hogy az AI körül presztízs van. Egy AI projekt leállítása a szervezet szemében gyakran úgy néz ki, mintha a cég lemondana a jövőről. Ezért a vezetők inkább hagyják futni, mint hogy magyarázkodniuk kelljen. Pedig a valóság ennek pont az ellenkezője. Az a szervezet komoly, amelyik meg tudja különböztetni a jó és a rossz próbálkozást.
Az öt jel
Az évek alatt kialakult egy nagyon egyszerű ellenőrzőlistám. Ha ezek közül több is igaz, akkor a projekt nem fejlődik, hanem vonszolja magát.
A használat nem nő, hanem fogy. A bevezetés utáni első hetekben mindig van lelkesedés. A kérdés az, mi történik a harmadik hónapban. Ha a rendszert egyre kevesebben nyitják meg, és a lelkes kezdők is visszaszoknak a régi módszerre, akkor nem képzési probléma van. A megoldás egyszerűen nem elég jó ahhoz, hogy megérje használni.
Mindig ugyanaz a néhány ember tartja életben. Ha a projekt kizárólag két-három elkötelezett kolléga energiájából működik, és a szabadságuk alatt megáll, akkor nem rendszert építettünk, hanem függőséget. Az ilyen megoldás előbb vagy utóbb megszűnik, csak épp akkor, amikor ők kilépnek.
A haszon minden méréskor odébb csúszik. Ez a legárulkodóbb jel. Az elején három hónapról beszéltünk, aztán fél évről, most meg arról, hogy a következő verzió majd hozza. Ha a megtérülés dátuma mindig ugyanannyira van a jövőben, mint az elején, akkor nem közeledünk hozzá.
A rendszer körül nő a kézi munka. Sokszor látom, hogy a bevezetés után valaki elkezdi utólag javítgatni az AI kimenetét. Ha ez a javítgatás egyre több időt visz, és lassan több munkát ad, mint amennyit a rendszer megspórol, akkor a projekt negatív irányba fordult. Ilyenkor a szervezet már a gépet szolgálja ki, nem fordítva.
Senki nem tudja megmondani, ki a gazdája. Ha megkérdezem, ki felel ma ezért a rendszerért, és mindenki egymásra néz, akkor a projekt gyakorlatilag árván maradt. Az árva rendszer nem fejlődik, csak romlik, mert a világ változik körülötte, ő meg nem.
Egy példa a gyakorlatból
Egy hazai szolgáltató cégnél dolgoztam, ahol másfél éve élt egy belső AI megoldás a dokumentumok feldolgozására. Amikor odakerültem, a vezetés azt kérte, segítsek továbbfejleszteni. Az első két hét után viszont más javaslattal álltam elő.
Ami kiderült, az szinte tankönyvi volt. A rendszert a bevezetéskor negyven kolléga használta, mostanra öt. Az öt közül négy ugyanabban a csapatban ült, és ők is főleg azért, mert az egyik vezetőjük kérte. A megtérülésről szóló becslés háromszor csúszott. És senki nem tudta megmondani, ki dönt ma a rendszer sorsáról, mert az eredeti projektgazda időközben másik területre került.
Nem továbbfejlesztést javasoltam, hanem lezárást. Nehéz beszélgetés volt, mert a cég sok pénzt tett bele. De amikor végigvettük, mennyi figyelmet és mennyi belső kapacitást köt le havonta ez a félig működő rendszer, kiderült, hogy a leállítás nem veszteség, hanem felszabadítás. A csapat energiája átkerült egy sokkal szűkebb, de valóban fájó feladatra, és ott néhány hét alatt látszott az eredmény, amire másfél évet vártak.
Leállítás és szüneteltetés nem ugyanaz
Fontos különbséget tenni. Nem minden akadozó projektet kell megszüntetni. Van, amikor a helyes döntés a szüneteltetés, és ez két esetben igaz.
Az egyik, amikor a projekt azért áll, mert egy külső feltétel hiányzik, például az adat még nincs rendben, vagy egy másik rendszer cseréje folyik. Ilyenkor a munka nem rossz, csak korai. Ezt érdemes tisztán kimondani, dokumentálni, és időpontot adni neki, mikor nézzük meg újra.
A másik, amikor a technológia tényleg nem tud még valamit, amire szükség lenne. Itt viszont vigyázni kell, mert ez a leggyakoribb önáltatás is. A különbség abban van, hogy meg tudod-e nevezni a konkrét képességet, ami hiányzik. Ha igen, az szüneteltetés. Ha csak annyi hangzik el, hogy majd jobb lesz, az halogatás.
A leállítás akkor a helyes döntés, amikor nem egy külső feltételen múlik a dolog, hanem magán az elképzelésen. Ha a feladat, amire a rendszert kitaláltuk, valójában nem elég fájó, vagy nem is illik AI-ra, akkor hiába várunk. Ott nem az idő fog segíteni.
Hogyan állítsd le jól
A leállításnak van egy rossz és egy jó módja. A rossz az, amikor a projekt egyszerűen eltűnik a napirendről, senki nem beszél róla többet, és fél év múlva már csak egy fizetett licenc emlékeztet rá. Ez a szervezet tanulási képességét is rombolja, mert nem születik belőle semmi.
A jó leállításnak négy eleme van. Kimondod, hogy vége, világosan, hogy mindenki tudja. Kikapcsolod a költségeket, tehát a licenceket és az infrastruktúrát, mert ezek maguktól nem szűnnek meg. Összeszeded, mi az, ami megmarad belőle, és ez fontosabb, mint elsőre látszik. Végül elmondod a szervezetnek, mit tanultunk.
Ami megmarad, az szinte soha nem a szoftver. Sokkal inkább az adat, amit rendbe tettetek közben, a folyamat, amit végre leírtatok, és a tudás, ami a csapatban lerakódott. Egy jól lezárt AI projekt után a cég általában jobb helyzetben van, mint előtte, még akkor is, ha maga a rendszer megszűnt. Ezt viszont ki kell mondani, különben senki nem érzi így.
Mit mondj a csapatnak
A leállítás kommunikációja legalább annyira számít, mint maga a döntés. Aki hónapokig dolgozott a projekten, az joggal érzi úgy, hogy az ő munkáját minősítik. Ha ezt nem kezeled, a következő projektnél már senki nem fog lelkesen beszállni, mert megtanulták, hogy a végén úgyis kudarc lesz belőle.
Két dolgot érdemes tisztán kimondani. Az egyik, hogy a döntés a feladatról szól, nem az emberekről. A csapat jól dolgozott egy olyan felvetésen, ami menet közben nem igazolódott, és ez a kísérletezés természetes velejárója. A másik, hogy mi lesz a felszabaduló kapacitással. Ha ezt nem mondod meg, mindenki a legrosszabbra gondol, és a bizonytalanság többet árt, mint maga a leállítás.
A cégeknél, ahol ezt jól csinálják, a lezárás egy rövid, nyilvános összefoglalóval zárul arról, mit tanultunk. Nem hibakeresés, hanem tényleges tanulság, például hogy melyik feladattípusra nem való az AI, vagy milyen adatállapot mellett nincs értelme belevágni. Ez a néhány mondat többet ér a szervezetnek, mint a félbehagyott rendszer maga.
A leggyakoribb hiba a leállítás után
Van egy visszatérő minta, amit érdemes elkerülni. A cég leállítja a projektet, aztán néhány hónap múlva ugyanaz az elképzelés visszatér, új néven, új szállítóval, mintha semmi nem történt volna. Ilyenkor a szervezet nem tanult, csak felejtett.
Ez ellen egyetlen dolog véd, ha a lezárásnál rögzítitek, mi volt a valódi ok. Ha az ok az volt, hogy a feladat nem elég fájó, akkor egy másik szállító sem fogja megoldani. Ha az ok az adat állapota volt, akkor a következő próbálkozás előtt az adatot kell rendbe tenni, nem eszközt választani. Ez a néhány sor megspórolhat egy második, ugyanolyan drága kört.
Ugyanígy érdemes rögzíteni azt is, mi az, ami működött. Szinte minden félbehagyott projektben van egy részlet, ami valóban jó volt, csak épp a rossz keretben. Ha ezt megőrzitek, a következő nekifutás nem a nulláról indul.
Amit egy vezető ebből átvehet
A legfontosabb, hogy a leállítás lehetőségét már az induláskor be kell építeni. Ha a projekt elején rögzítitek, mit vártok, mikorra, és mi az a szint, ami alatt lezárjuk, akkor a későbbi döntés nem személyes kudarc lesz, hanem egy előre megbeszélt szabály alkalmazása. Ez a különbség aközött, hogy valakinek be kell ismernie a tévedését, és aközött, hogy a csapat egy megállapodás szerint jár el.
Érdemes emellett rendszeresen feltenni a kérdést, hogy ha ma kellene dönteni, elindítanánk-e újra ezt a projektet. Ha a válasz nem, akkor a folytatásnak nincs más indoka, mint a már beletett pénz, ami a leggyengébb érv a világon, mert az a pénz így is, úgy is elment.
Az a szervezet, amelyik képes leállítani, gyorsabban is halad. Mert a kapacitása nem oszlik szét tíz félkész próbálkozás között, hanem oda kerül, ahol tényleg működik. A tapasztalatom szerint azok a cégek jutottak a legmesszebbre az AI-jal, ahol nem az volt a cél, hogy minden elindított projekt sikeres legyen, hanem az, hogy a rosszakról gyorsan kiderüljön, hogy rosszak.
kdconsulting.hu · [email protected]