Kada DI neverta diegti: šeši požymiai, kad reikia sustoti

Didžioji dalis tekstų apie DI versle aiškina, kodėl reikia pradėti. Šis aiškina, kada nereikia. Ne todėl, kad DI neveiktų, o todėl, kad ir veikianti technologija neatsiperka, jei pritaikoma ne toje vietoje. Šeši požymiai žemiau yra tie, kuriuos matau dažniausiai. Bet kurio vieno pakanka, kad sustotumėte ir pergalvotumėte.

Verta pradėti nuo to, ko sustojimas nereiškia. Microsoft 2025 m. Work Trend Index, parengtas iš 31 000 darbuotojų 31 šalyje apklausos, nurodo, kad 81% apklaustų vadovų tikėjosi agentus reikšmingai integruoti į savo DI strategiją per artimiausius 12–18 mėnesių. Tendencija reali. Bet ta pati ataskaita mini, kad tuo metu 24% jau buvo įdiegę DI visoje organizacijoje, o 12% tebebuvo bandymų stadijoje. Skirtumas tarp šių dviejų grupių paprastai yra ne technologijos pasirinkimas, o tai, ar buvo atsakyta į klausimą, kurias užduotis apskritai verta liesti. Sąrašas žemiau yra apie tai.

1. Procesas vyksta rečiau nei kartą per savaitę

Automatizacija atsiperka per pasikartojimą. Jei procesas vyksta kelis kartus per metus, žmogus jį atliks greičiau, nei jūs spėsite paaiškinti sistemai, ką daryti. Pirmiausia suskaičiuokite valandas per mėnesį. Jei skaičius mažas, sustokite čia.

2. Niekas negali papasakoti, kaip procesas turi vykti

Jei trys žmonės procesą atlieka trimis skirtingais būdais ir visi trys yra „teisingi“, sistema neturi ką automatizuoti. Ji automatizuos vieną iš trijų versijų, o kiti du žmonės ją apeis. Pirmiausia susitarkite, kaip procesas turi vykti, užrašykite tai, ir tik tada kalbėkite apie automatizaciją. Dažnai vien šis susitarimas sutaupo daugiau nei bet kokia sistema.

Tai nėra vien mano pastebėjimas. McKinsey Global Institute 2025 m. lapkričio tyrime vertinama, kad vidutiniame diegimo scenarijuje iki 2030 m. JAV kasmet galėtų būti sukuriama apie 2,9 trln. dolerių vertės, bet su sąlyga: organizacijos turi perprojektuoti darbo eigas, o ne atskiras užduotis. Procesas, kurio niekas negali aprašyti, negali būti perprojektuotas. Jis gali būti tik apstatytas įrankiais.

3. Duomenys yra popieriuje, nuotraukose ar žmonių galvose

DI sistemai reikia duomenų, kuriuos ji gali perskaityti. Jei sąskaitos ateina kaip nuotraukos telefonu, o užsakymai užrašomi sąsiuvinyje, pirmasis žingsnis yra ne DI, o duomenų surinkimas į vieną vietą. Tai nuobodus, bet būtinas darbas, ir jį reikia padaryti prieš bet kokį bandymą.

4. Klaidos kaina didesnė už sutaupytą laiką

Kiekviena sistema klysta. Klausimas yra, kiek kainuoja viena klaida. Jei sistema rūšiuoja el. laiškus ir suklysta, kažkas pastebės ir pataisys. Jei sistema pati siunčia pasiūlymus klientams su kainomis ir suklysta, vienos klaidos kaina gali viršyti metų sutaupymą. Tokiais atvejais sprendimas yra ne atsisakyti automatizacijos, o palikti žmogų patvirtinti kiekvieną sprendimą. Jei tai neįmanoma, nedarykite.

Harvard Business Review aprašo, kaip Salesforce valdo savo klientų aptarnavimo agentus: atskiras žmogus, kurio darbas yra stebėti agentų rodiklius ir elgseną per švieslentes ir stebėsenos įrankius. Tai teisingas modelis, bet jis kainuoja. Jei jūsų procese klaidos kaina tokios priežiūros nepateisina, tas procesas nėra kandidatas.

5. Užtektų paprastos taisyklės

Nemaža dalis „DI projektų“ yra taisyklės, kurias galima užrašyti vienu sakiniu: jei suma didesnė nei X, siųsti vadovui; jei laiške yra žodis „sąskaita“, perkelti į aplanką. Tokias taisykles įgyvendina bet kuris automatizavimo įrankis be jokio DI, greičiau, pigiau ir be klaidų. DI reikalingas tada, kai taisyklės neįmanoma užrašyti, nes sprendimas priklauso nuo konteksto.

6. Nėra kam sistemos prižiūrėti

Sistema, kurios niekas neprižiūri, nustoja veikti per kelis mėnesius: pasikeičia el. laiškų formatas, atsinaujina programa, pasikeičia tiekėjo sąlygos. Jei įmonėje nėra žmogaus, kuris galėtų skirti kelias valandas per mėnesį ir kuris supranta, ką sistema daro, ji taps dar vienu dalyku, kuris „kažkada veikė“. Perdavimas ir apmokymas yra ne priedas prie projekto, o sąlyga, kad jis turėtų prasmę.

Ką daryti vietoj to?

• Pirmiausia suskaičiuokite valandas ir klaidos kainą. Tai užtrunka vieną popietę ir atsako į pusę klausimų.
• Susitarkite dėl vieno proceso aprašo. Dažnai tai pats naudingiausias projekto rezultatas.
• Išbandykite paprastą taisyklę be DI. Jei ji išsprendžia didžiąją dalį atvejų, likusius gali daryti žmogus.
• Jei vis tiek atrodo, kad DI reikia, išbandykite su tikrais duomenimis prieš statydami sistemą. Bandymas yra pigiausias būdas sužinoti tiesą.

Sustojimas nėra atsilikimas. Perskaitykite šešis požymius dar kartą ir pažymėkite, kurie galioja jūsų procesui. Jei nė vieno, turite kandidatą. Jei bent vienas, turite užduotį, kurią reikia atlikti prieš bet kokį įrankį.

Būtent tam skirtas įvertinimo etapas: atsakyti į klausimą, ar verta, prieš išleidžiant pinigus atsakymui, kaip.

Pastaba dėl duomenų: cituojami tyrimai yra tarptautiniai, 2025–2026 m., ir Lietuva tarp atskirai apklaustų rinkų nenurodyta. Tendencijos kryptis aktuali, tikslūs procentai jūsų rinkoje gali skirtis.