Dažniausiai problema yra ne technologija. DI modelių kokybė per pastaruosius metus išaugo tiek, kad techninis pajėgumas retai yra ribojantis veiksnys. Grąža prarandama sprendimo pasirinkimo, proceso ir diegimo etapuose. Pateikiame dažniausias priežastis, kurias pastebime praktikoje.
Pradedama nuo įrankio, o ne nuo problemos
Tipinė projekto pradžios seka yra tokia: priimamas principinis sprendimas, kad įmonė turi pradėti naudoti dirbtinį intelektą, ir tik tada ieškoma, kur jį pritaikyti. Toks eiliškumas iš esmės lemia mažą grąžą, nes sprendimas diegiamas ne ten, kur yra didžiausias nuostolis, o ten, kur technologiją paprasčiausia pritaikyti.
Grąžą duodantys projektai pradedami atvirkščiai – nuo konkretaus proceso, kuris jau dabar kainuoja pinigus. Klientų užklausų rūšiavimas, sutarčių tikrinimas, dokumentų duomenų nuskaitymas, ataskaitų rengimas iš kelių sistemų. Pirmiausia nustatoma, kiek darbo valandų procesas užima ir kiek klaidų sukelia per mėnesį, ir tik tada sprendžiama, ar DI yra tinkamas įrankis. Neretai paaiškėja, kad tinkamesnė ir gerokai pigesnė priemonė yra įprasta proceso automatizacija be jokio DI.
Nėra rodiklio, pagal kurį būtų vertinama grąža
Jei prieš projektą nebuvo išmatuota, kiek laiko užima esamas procesas, po projekto nebus su kuo lyginti. Vertinimas tokiu atveju tampa subjektyvus: komanda mini didesnį patogumą, vadovai – bendrą pagerėjimo įspūdį, o finansų padalinys mato tik sąskaitą už licencijas.
Prieš diegimą tikslinga fiksuoti bent kelis paprastus rodiklius: vidutinį užklausos apdorojimo laiką, per mėnesį apdorojamų dokumentų skaičių, klaidų dalį, procese dalyvaujančių darbuotojų valandas. Šie rodikliai nebus visiškai tikslūs, tačiau jų pakanka, kad po trijų ar šešių mėnesių būtų galima pagrįstai atsakyti, ar investicija atsipirko.
Duomenys nėra tokios kokybės, kaip buvo manoma
Tai dažniausia techninė nesėkmės priežastis. Įmonė turi duomenų, tačiau jie išsibarstę tarp kelių sistemų, nesuvienodinti, dalinai užpildyti, o svarbi informacija saugoma laisvo teksto komentarų laukuose arba lokaliuose failuose.
DI sprendimas šios problemos neišsprendžia – jis ją tik atskleidžia. Rezultatas būna prognozės ir atsakymai, kurie techniškai korektiški, tačiau praktiškai netikslūs, todėl darbuotojai jais nustoja pasitikėti. Tokiais atvejais didžiausią grąžą duoda ne DI, o ankstesnis etapas: duomenų sutvarkymas, sistemų integracija ir vienos patikimos informacijos versijos sukūrimas. Būtent šis darbas dažniausiai ir praleidžiamas, nes jo rezultatas įmonėje mažiau matomas.
Sprendimas neintegruotas į darbo procesą
Atskirai veikiantis įrankis, į kurį reikia atskirai prisijungti ir atskirai įvesti duomenis, praktikoje naudojamas retai. Praėjus pirmosioms savaitėms, darbuotojai grįžta prie įprasto darbo būdo, nes jis reikalauja mažiau veiksmų.
Grąža atsiranda tada, kai DI funkcija veikia toje vietoje, kur darbas jau vyksta – įmonės valdymo sistemoje, klientų aptarnavimo platformoje, dokumentų valdymo sprendime. Skirtumas tarp įrankio įsigijimo ir funkcijos veikimo esamame procese paprastai ir yra skirtumas tarp nulinės ir realios grąžos.
Vertinamos tik diegimo, o ne eksploatacijos išlaidos
Bandomasis projektas dažnai kainuoja nedaug, todėl sprendimas priimamas lengvai. Tačiau pagrindinė sąnaudų dalis atsiranda vėliau: modelių naudojimo mokesčiai proporcingai apimčiai, rezultatų kokybės stebėjimas, atnaujinimai pasikeitus procesui, palaikymas, saugumo ir asmens duomenų apsaugos reikalavimų užtikrinimas.
Vertinant grąžą būtina skaičiuoti bent trejų metų bendrą nuosavybės kainą. Dalis projektų, pirmaisiais mėnesiais atrodančių pelningai, ilgesniu laikotarpiu tampa nuostolingi vien dėl to, kad nebuvo įvertintas išlaidų augimas didėjant naudojimo apimtims.
Neįvertinamas darbuotojų pasirengimas
DI sprendimas pakeičia darbo turinį – dažniausiai iš atlikimo į tikrinimą. Tai reikalauja kitų kompetencijų ir kitokio atsakomybės paskirstymo. Jei darbuotojams nepaaiškinama, kaip vertinti sistemos rezultatą, kada juo galima pasitikėti ir kas atsako už klaidą, susiformuoja viena iš dviejų kraštinių situacijų: arba viskas tikrinama iš naujo ir laiko sutaupoma nedaug, arba netikrinama nieko ir didėja klaidų rizika.
Mokymai, aiškios naudojimo taisyklės ir apibrėžta atsakomybė kainuoja nedaug, tačiau tiesiogiai lemia, ar sprendimas bus naudojamas taip, kaip buvo suplanuota.
Iš karto imamasi per didelio masto
Bandymas viena iniciatyva pertvarkyti visą klientų aptarnavimą arba visą dokumentų valdymą lemia ilgą projektą, didelį dalyvaujančių šalių skaičių ir vėluojantį rezultatą. Kol projektas įgyvendinamas, pasikeičia ir įmonės prioritetai, ir pačios technologijos.
Praktikoje geriau veikia priešinga logika: pasirenkamas vienas siauras, dažnai pasikartojantis ir aiškiai išmatuojamas atvejis, jis įgyvendinamas per kelias savaites, išmatuojamas rezultatas ir tik tada priimamas sprendimas dėl išplėtimo. Toks būdas leidžia apriboti galimos klaidos kainą.
Ką tikslinga patikrinti prieš pradedant projektą
Prieš skiriant biudžetą DI sprendimui, naudinga atsakyti į šešis klausimus:
Kokį konkretų procesą tobuliname ir kiek jis kainuoja įmonei šiandien?
Kokį rodiklį turi pagerinti sprendimas ir kokia yra jo esama vertė?
Ar duomenys, kurių reikės sprendimui, yra prieinami, pilni ir vienoje vietoje?
Kurioje sistemoje ir kurioje darbo proceso vietoje darbuotojas naudos rezultatą?
Kiek sprendimas kainuos per trejus metus, įskaitant naudojimo ir palaikymo išlaidas?
Kas įmonėje atsako už rezultato tikrinimą ir kokybę?
Jei bent į kelis iš šių klausimų atsakymo nėra, tikėtina, kad problema, kurią reikia spręsti pirmiausia, nėra susijusi su dirbtiniu intelektu.
Vertinimo logika, kurios dažniausiai pritrūksta
Investicijoms į DI verta taikyti tuos pačius kriterijus, kaip ir bet kuriai kitai investicijai į įrangą ar naują darbo vietą. Praktikoje taip nutinka retai: kadangi technologija nauja, sprendimas dažnai priimamas remiantis demonstracija, o ne skaičiais. Jei paslaugos teikėjas negali įvardyti, kurį rodiklį sprendimas pagerins ir kaip tas pagerėjimas bus išmatuotas, tai yra pakankama priežastis projekto nepradėti arba pirmiausia susitarti dėl mažesnės apimties darbų.
Antras dažnai praleidžiamas elementas – iš anksto sutartas peržiūros momentas. Prieš pradedant darbus tikslinga nustatyti datą, pavyzdžiui, po trijų mėnesių nuo paleidimo, kada bus priimtas vienas iš trijų sprendimų: plėsti, keisti arba stabdyti. Būtent stabdymo sprendimo nebuvimas yra priežastis, dėl kurios nepasiteisinę bandomieji projektai įmonėse tęsiasi metus ir ilgiau, kaupdami licencijų ir palaikymo išlaidas be jokios grąžos.