Kodėl DI projektai žlunga: penkios priežastys, dėl kurių 42 % įmonių atsisako savo DI iniciatyvų

2025 m. S&P Global apklausė įmones apie jų DI programas, ir 42 % teigė atsisakiusios daugumos savo iniciatyvų. Vidutinė įmonė buvo nutraukusi 46 % savo bandomųjų projektų. Tai sritis, kurioje dirbame, ir atsakymas į klausimą, kodėl AI projektai žlunga, yra paprastesnis, nei leidžia manyti rinkodara. Priežastys kasdieniškos ir kartojasi.

Du skaičiai, kuriuos verta žinoti planuojant biudžetą

Pirmasis yra S&P skaičius. Antrasis yra iš tų pačių metų MIT NANDA ataskaitos: projektai, kuriami su išorės partneriu, pasiekia diegimą maždaug 67 % atvejų, o kuriami viduje 33 %. Kokio partnerio reikia ir kiek kainuoja agentūra, laisvai samdomas specialistas ir savas inžinierius, yra atskiras klausimas nuo to, ar partnerio apskritai reikia. Skirtumas daugiausia susijęs su sutartimi. Mokamas išorės projektas turi darbų apimtį, terminą ir žmogų, kuris negauna užmokesčio, kol sistema neveikia; vidinis bandomasis projektas viso to neturi, nebent kas nors to primygtinai reikalauja.

Mūsų pačių patirtis remiasi tik mūsų sukurtomis sistemomis, o tokios imties per maža, kad vadintume išvada, todėl laikykite tai hipoteze. Kiekviena vis dar veikianti mūsų sistema atsako į klausimą, kurį kas nors jau užduodavo kas savaitę, ir nė viena nebuvo pradėta kaip „platforma“. Atrodo, kad didžiąją dalį to, kas paprastai priskiriama technologijos pasirinkimui, iš tikrųjų lemia aiški darbų apimtis.

Sudėjus apklausų skaičius ir mūsų patirtį, ilgai veikiantys projektai panašūs: jie maži, trumpi, ir už juos atsako žmogus, kuris negauna užmokesčio, kol sistema neveikia.

Demonstracija įrodo mažiau, nei atrodo

Beveik už kiekvieno žlugusio projekto, kurį mus kvietė gelbėti, buvo veikianti demonstracija. Kažkas stebėjo, kaip sistema atlieka darbą, ir pritarė. Demonstracija buvo tikra, bet vyko sąlygomis, kurios po susitikimo daugiau nepasikartoja.

Demonstracija veikia su dešimčia tvarkingų, specialiai atrinktų įrašų. Išbandomas vienas, sėkmingas scenarijus. Kiekvieną vykdymą stebi žmogus, ir jei kas nors atrodo ne taip, jis paleidžia iš naujo, kol niekas kitas nepastebėjo. Niekas neskaičiuoja tokenų.

Realiame darbe būna visa kita. Štai kas pasikeičia pirmąjį pirmadienį:

• Įrašai atkeliauja be kai kurių laukų. Užklausa, kuri kliento veiklos sritį skaitė iš CRM lauko, dabar 30 % atvejų gauna tuščią eilutę, o modelis, norėdamas padėti, sritį išgalvoja.
• Ta pati įmonė atsiranda tris kartus, užrašyta šiek tiek skirtingai. Dublikatų šalinimo darbų apimtyje nebuvo, nes demonstracijos duomenyse dublikatų nebuvo.
• Žmonės naudoja sistemą taip, kaip kūrėjas neįsivaizdavo: į vienam sakiniui skirtą lauką įklijuoja visą laiškų grandinę, atsako į automatinį pranešimą tikėdamiesi žmogaus, į klausimą „taip ar ne“ atsako trimis pastraipomis, įkelia atspausdintos formos nuotrauką.
• Tiekėjas pakeičia duomenų struktūrą. Jo pusėje pervadintas laukas sugadina susiejimą Jūsų pusėje, ir niekas apie tai nepraneša.
• Niekas nestebi. Vykdymas, kuris demonstracijoje būtų buvęs pastebėtas ir paleistas iš naujo, dabar nukeliauja klientui.

Kiekvienas iš jų yra konkretus gedimas su konkrečiu sprendimu, o ne abstrakti rizika iš rizikų registro. Taip atrodo įprasta realaus darbo kasdienybė, ir projektas, kuris nebuvo tam suprojektuotas, su ja vis tiek susidurs, tik jau prieš klientą, antrą mėnesį.

Penkios žlugimo priežastys

1. Nėra atsakingo žmogaus

Dažniausia ir mažiausiai techninė priežastis. Automatizacija sukuriama, veikia demonstracijoje ir niekam nepriklauso. Ją inicijavęs žmogus grįžta prie savo tiesioginio darbo. Po šešių savaičių pasikeičia API, automatizacija tyliai sustoja, ir niekas to nepastebi, kol vėl neiškyla problema, dėl kurios ji buvo sukurta. Sistema be atsakingo žmogaus anksčiau ar vėliau sustos, tik dar nežinia kada.

Kraštutinė šio atvejo versija mus pasiekia reguliariai. Pusė mūsų vertintų taisymo darbų prasidėjo vienodai: kūrėjo nebebuvo, o visos paskyros, kuriose veikė sistema, buvo jo vardu. OpenAI raktas, automatizavimo platformos prisijungimas, Google Cloud projektas, domenas. Vienu atveju klientas matė, kaip automatizacija stringa valdymo skydelyje, bet neturėjo jokių prisijungimo duomenų, kad kas nors galėtų ją atidaryti. Tas projektas žlugo ne dėl techninio gedimo. Jis žlugo, nes niekas už jį nebeatsakė, o žmogus, kuris atsakė, nebeatsakinėjo į laiškus. Jei dabar esate tokioje padėtyje, praktinius žingsnius rasite straipsnyje ką daryti, kai laisvai samdomas specialistas dingsta.

2. Gedimai pagal nutylėjimą nematomi

Automatizacijos genda tyliai. Baigia galioti prieigos tokenas, pervadinamas formos laukas, modelio atnaujinimas pakeičia elgseną, ir apie tai žino tik pačios platformos valdymo skydelis. Būtent šį gedimą randame dažniausiai, kai automatizacija po paleidimo tyliai nustoja veikti.

Mus pakvietė pažiūrėti potencialių klientų paskirstymo workflow, kuris didžiąją ketvirčio dalį sugesdavo maždaug kartą per dieną. Jo klaidų įspėjimai buvo siunčiami į Slack kanalą, suarchyvuotą prieš kelis mėnesius. Niekas nebuvo matęs nė vieno. Pirmas ženklas, kad kažkas negerai, buvo pardavėjo klausimas, kodėl konkretaus potencialaus kliento užpildyta forma niekam nepateko, o iki to laiko workflow jau didžiąją ketvirčio dalį metė potencialius klientus.

Garsūs gedimai dar ne blogiausia. Pavojingiausias atvejis yra vykdymas, kuris baigiasi sėkme nieko nepadaręs: filtras grąžina nulį eilučių, visi po juo esantys mazgai praleidžiami, nes nėra ką daryti, o platforma vykdymų žurnale pažymi žalią varnelę. Jūsų stebėsena, jei ją turite, rodo 100 % sėkmę. Tam skirtas atskiras puslapis, workflow veikia, bet nieko nevyksta, nes toks gedimas padaro daugiau žalos nei atviros klaidos. Susijęs atvejis, kai automatizacija nustojo veikti, dažniausiai paprastesnis, nes bent kas nors skundžiasi.

Paklauskite bet kurio tiekėjo, kaip sužinosite, kad sistema sugedo. Jei jis neatsako, tai irgi atsakymas.

3. Automatizuojamas ne tas procesas

Įmonės atsisako sąskaitų priminimų automatizacijos, kuri sutaupytų apie 1 800 € per mėnesį (sumos perskaičiuotos eurais apytiksliai: 1 $ ≈ 0,92 €), ir finansuoja „DI platformą“, kuri gražiai atrodo pranešime spaudai. Didysis projektas turi dešimt integracijos taškų, nesutartus sėkmės kriterijus ir devynių mėnesių terminą, kitaip tariant, dešimt būdų žlugti.

Yra ir subtilesnė versija, į kurią pakliūva net atsargios įmonės. Jei trys skyriaus žmonės tą patį procesą atlieka trimis skirtingais būdais ir niekada to nesuderino, automatizacija tą nesutarimą tiesiog įrašo į programinę įrangą. Tada vienas žmogus rezultatus laiko teisingais, o kitas klaidingais, ir ginčas, kuris turėjo įvykti susitikime, virsta skundais sistemai, kurios niekas nenori ginti. Automatizacija procesą padaro greitesnį ir nuoseklesnį, bet nepasako, ar procesas buvo teisingas.

Tai stipriausias argumentas mokėti už diagnostiką prieš mokant už sistemos kūrimą. Žmogus iš šalies turi pasėdėti su darbą atliekančiais žmonėmis, užrašyti, kas iš tikrųjų vyksta, o ne kas parašyta proceso aprašyme, ir užfiksuoti nesutarimus raštu, kol juos keisti dar pigu. Tai DI galimybių audito darbas, o jo rezultatus išvardijame straipsnyje ką apima mokamas auditas.

Mažiausiai įspūdinga mūsų prižiūrima sistema yra dokumentų generatorius hidrogeologijos įmonei. Ji rengia techninius gręžinių dokumentus. 2026 m. rugpjūčio duomenimis ji yra sugeneravusi 168 dokumentus ir saugo 349 gręžinių duomenis, vienas kliento darbuotojas tikrina jos rezultatus, o klientas grįžo užsakyti antros sistemos. Konferencijose apie ją niekas nekalbės, ir būtent todėl ji veikia.

4. Įrankis naudojamas ten, kur jis netinka

Kalbos modeliai atpažįsta ir atkuria dėsningumus. Projektai žlunga, kai modelis naudojamas ten, kur reikia 100 % tikslumo be žmogaus patikros: savarankiški kainodaros sprendimai ar bet kas, kur viena klaida kainuoja daugiau nei mėnuo teisingų rezultatų. Sprendimas slypi proceso sandaroje. Modelis rengia juodraštį, žmogus tvirtina, ir taip lieka tol, kol klaidų dažnis neišmatuotas su realiais duomenimis, o tam ir skirtas verslo automatizacijų testavimas.

Modelis retai būna problema. Mūsų kasdien veikiančiose sistemose, įskaitant balso administratorių, atsiliepiantį į tikrus skambučius, incidentai, dėl kurių kam nors teko keltis naktį, kilo dėl pasibaigusių prisijungimų, užklausų limitų, netvarkingų įvesties duomenų ir trečiosios šalies sutrikimo. Arčiausiai modelio gedimo buvo agentas, nustojęs naudoti įrankį po prompto pakeitimo, o tai yra gerai žinoma konfigūracijos problema.

5. Niekas kas mėnesį neskaičiuoja naudos

Bandomieji projektai vertinami pagal tai, ar jie veikia, o realiai naudojamos sistemos pagal tai, ar jos atsiperka. Jei niekas negali pasakyti kažko panašaus į „liepą sistema apdorojo 640 įrašų ir sutaupė apie 53 valandas“, sistemos vertė yra tik įspūdis, o įspūdis per biudžeto svarstymus pralaimi. Taip pusiau apleisti projektai išsilaiko ištisus ketvirčius: prenumeratos apmokamos, o naudos niekas neskaičiuoja.

Kai kurių gedimų neįmanoma rasti vien iš aprašymo

Į klausimus apie matomą klaidą kartais galima atsakyti vien iš aprašymo, nes klaidos tekstas ar HTTP būsenos kodas susiaurina paiešką. Į klausimus apie tai, ko nėra, negalima. „Veikia, rodo sėkmę, nieko neatkeliauja“ yra simptomas, kurio priežastis slypi vykdymų istorijoje: duomenyse kiekviename žingsnyje ir tame vykdyme, kai filtras pirmą kartą nieko negrąžino.

Kartą čia buvome įdėję forumų statistiką šiai minčiai pagrįsti ir dukart suklydome, todėl ją pašalinome. Argumentas teisingas ir be jos. Niekas, skaitantis aprašymą, nemato Jūsų vykdymų istorijos, todėl diskusija prisipildo spėlionių. Projektus dažniausiai sužlugdo būtent tylūs gedimai, ir todėl pagalbos susitarimas, apimantis prieigą prie Jūsų vykdymų istorijos, yra geresnis už tokį, kuris apima tik el. pašto adresą.

Eksploatacijos išlaidos atsiranda po paleidimo

Sistema gali veikti nepriekaištingai ir vis tiek būti išjungta ketvirtą mėnesį, nes kūrimo kaina buvo vienas skaičius, dėl kurio visi susitarė, o eksploatacijos kaina buvo daug smulkių mokesčių, kurių niekas niekam nepriskyrė. Tokenų išlaidos, kurios auga kartu su apimtimi, o ne pagal pasiūlymą. Telefonijos minutės balso agentui, kur skirtumas tarp 40 sekundžių ir keturių minučių skambučio lemia visą maržą, todėl balso agento išlaidoms reikia atskiro skaičiavimo. n8n ar Make operacijų mokesčiai, skaičiuojami už kiekvieną vykdymą, net jei jis nieko nepadaro. Serveris, stebėsena, klaidų sekimas, duomenų bazė, domenas.

Atskirai nė vienas iš jų nėra brangus. Kartu tai mėnesio suma, kurią kas nors turėjo įtraukti į biudžetą prieš paleidimą, o visas išlaidas aprašome straipsnyje eksploatacijos kaštai, apie kuriuos niekas nekalba. Projektas, kuris kuria tikrą vertę, bet kainuoja 300 € per mėnesį, kurių niekas neplanavo, peržiūrint išlaidas pralaimės projektui, kuris nieko nekuria ir nieko nekainuoja.

Kaip atrodo ilgai veikiantis projektas

Sistemos, kurios sėkmingai veikia pirmuosius metus, iš išorės atrodo gana panašiai. Kiekviena turi konkretų žmogų, kuriam būtų nemalonu, jei ji suges, įspėjimą, kurį gauna gyvas žmogus vis dar veikiančiame kanale, ir kas mėnesį pateikiamą skaičių, kurį supranta ir ne techninės komandos žmonės.

Prieš paleidimą į paruoštumo kontrolinio sąrašo klausimus atsakoma konkrečiai, o ne ketinimais: kieno paskyrose saugomi prisijungimo duomenys, kas nutinka, kai tiekėjo API grąžina 500, kur saugomi žurnalai, kas gauna pranešimą 2 val. nakties ir ką su juo turi daryti. Po paleidimo kažkam mokama už stebėjimą. Tai ir yra tikrasis priežiūros sutarties turinys, todėl prieš pasirašydami tokią sutartį perskaitykite, ką ji turi apimti: sutartis, apimanti tik klaidų taisymą, tylių gedimų neišsprendžia.

Kai esamos sistemos išgelbėti nebeįmanoma, pirmas žingsnis yra nuspręsti, ar ją taisyti, ar kurti iš naujo, ir apie tai rašome straipsnyje taisyti ar kurti sugedusią DI sistemą iš naujo.

Kaip nepatekti į tuos 42 %

1. Pirmiausia užsakykite mažą įrodymą. Vieną skausmingą procesą, kurio kainą galima išmatuoti, už iš anksto sutartą kainą, nes fiksuota, o ne valandinė kaina priverčia susitarti dėl darbų apimties dar prieš išlaidas. Jei 4 600 € kainuojanti sistema negali įrodyti savo vertės, didesnė programa jos irgi neįrodys, tik ilgiau užtruks tai pripažinti.
2. Nustatykite 90 dienų ribą ir iš anksto numatykite, kada projektą nutrauksite. Jei iki tol sistema nekuria išmatuojamos vertės, sustabdykite ją arba perpus sumažinkite jos apimtį. Išlyga iš mūsų pačių darbo: vienas dabartinis mūsų projektas laukia, kol trečioji šalis atvers savo API, ir griežta 90 dienų riba jį sužlugdytų dėl priežasčių, nesusijusių su darbų apimtimi. Dėl išorinių kliūčių laikrodį sustabdykite ir tai užfiksuokite.
3. Prieš kurdami nuspręskite, kokį rodiklį matuosite kas mėnesį. Apdoroti įrašai, sutaupytos valandos, reagavimo laikas, paveiktos pajamos. Įrašykite mėnesio ataskaitą į sutartį, nes būtent ją turėtų pateikti ir priežiūros sutartis, kai sistema jau veikia. Jei tiekėjas tam priešinasi, jis Jums netiesiogiai sako, ką, jo manymu, parodys tas skaičius.
4. Pirmą dieną paskirkite atsakingą žmogų. Jei negalite, dar nesate pasiruošę, ir sąžiningas tiekėjas Jums tai pasakys.
5. Prieš pasirašydami paklauskite, kaip tiekėjas sužinos, kad kas nors sugedo, ir kaip Jūs sužinosite, kad jis tai žino. Kitus klausimus rasite straipsnyje ko paklausti prieš samdant DI agentūrą.

Mūsų nuomone, atsisakytų projektų skaičiai labiau kalba apie tai, kaip automatizacija dažniausiai perkama (didelė, miglota ir neišmatuota), o apie pačią technologiją jie pasako mažai. Jei norite pradėti nuo mažo, išmatuojamo įrodymo, nemokamos konsultacijos metu ieškome paprasto proceso, kurio naudą galima išreikšti skaičiumi, o po jos gausite raštišką pasiūlymą, kuriame tas skaičius užfiksuotas.