Demonstracijoje užsakymo duomenys atsiranda lentelėje per kelias akimirkas. Kasdienėje veikloje darbuotojas dar turi patikrinti prekės kodą, išsiaiškinti trūkstamą kiekį ir pataisyti pristatymo datą. Ar įmonė iš tiesų laimi laiko? Tam skirtas bandomasis projektas – ribotos apimties išbandymas su iš anksto sutartais vertinimo kriterijais. Dirbtinis intelektas, arba AI pagal anglišką terminą „artificial intelligence“, čia reiškia sistemas, kurios iš duomenų atpažįsta dėsningumus ir pagal juos pateikia rezultatą.
Pirmasis dokumentas – susitarimas dėl sėkmės
Lietuvos smulkiajai ar vidutinei įmonei prieš bandymą verta viename puslapyje surašyti tikslą, ribas ir sprendimo datą. Tikslas „išbandyti AI“ nepasako, ką matuosite. Tikslesnis klausimas: ar užsakymų duomenų paruošimas tampa greitesnis, išlaikant sutartą tikslumą? Taip pat sutarkite, kokio rezultato pakaktų tęsti darbą, o kokios klaidos stabdytų bandymą. Numatyta pabaigos data ir atsakingas vertintojas padeda išvengti neapibrėžto bandymo, kuris tęsiasi vien todėl, kad niekas nepriima sprendimo.
Toks pokalbis aktualus ir renkantis diegimo partnerį. Dirbtinio intelekto ir verslo procesų automatizavimo sprendimus kurianti „Artifexa“ svetainėje artifexa.ai nurodo, kad sprendimo projektavimo etape aptaria rezultatų vertinimą, o po diegimo sprendimą stebi ir tobulina. Konkretaus bandymo kriterijus įmonei vis tiek reikia suderinti pagal savo darbo sąlygas.
Užfiksuokite darbą iki pokyčio
Įsivaizduokime didmeninę prekybos įmonę, gaunančią užsakymus el. paštu. Tai hipotetinis pavyzdys, nesusijęs su konkrečiu „Artifexa“ klientu. Darbuotojas iš laiškų perkelia prekių kodus, kiekius ir pageidaujamas pristatymo datas į užsakymo ruošinį. Bandomasis sprendimas turėtų pasiūlyti šiuos laukus, o žmogus juos patikrintų prieš patvirtindamas užsakymą. Jei užsakymai jau gaunami vienodos formos lentelėse, duomenis gali pakakti perkelti pagal aiškias taisykles. AI prasminga vertinti ten, kur reikia interpretuoti laisvai parašytą tekstą.
Prieš pakeitimą pamatuokite visą paruošimo darbą: laiško skaitymą, duomenų suvedimą, patikrą ir taisymus. Atskirai žymėkite laukimą, kol klientas pateikia trūkstamą informaciją. Kitaip lėtesnį kliento atsakymą galite palaikyti sistemos problema. Užrašykite ir užsakymų sudėtingumą: vienos prekės laiško nereikėtų tiesiogiai lyginti su ilgu užsakymu, kuriame kelis kartus keisti kiekiai.
Bandymui reikia ir nepatogių laiškų
Testavimo rinkinys – tai iš anksto atrinktų pavyzdžių visuma, kuria tikrinsite veikimą. Įtraukite įprastus užsakymus, lietuviškas santrumpas, neaiškias datas, laiškų grandines ir priedus, jeigu jie patenka į sutartą apimtį. Kiekvienam pavyzdžiui paruoškite žmogaus patikrintą teisingą rezultatą. Susitarkite, kas gali pasiekti bandymo laiškus, kokią informaciją būtina pašalinti ir kada testavimo kopijos bus ištrintos. Rinkinyje palikite tik užduočiai reikalingus duomenis. Trūkstamas kiekis turi likti pažymėtas kaip nežinomas, o ne būti užpildytas spėjimu.
Atskirą dalį pavyzdžių atidėkite galutiniam vertinimui ir nenaudokite sprendimui derinti. JAV Nacionalinio standartų ir technologijos instituto (NIST) vertinimo gairėse rekomenduojama dokumentuoti testavimo rinkinius bei rodiklius ir tikrinti sistemą sąlygomis, artimomis numatomam naudojimui. Praktinė išvada paprasta: vien gražiausių laiškų rinkinys neatsakys, kaip įrankis veiks jūsų kasdienybėje. Rezultatus peržiūrėkite pagal laiškų tipus, kad bendras vidurkis nepaslėptų silpnos vietos.
Į naudą įskaičiuokite ir patikrą
Sutaupytą laiką skaičiuokite iš ankstesnės darbo trukmės atėmę visą naują darbą, įskaitant duomenų tikrinimą ir klaidų taisymą. Prie projekto sąnaudų pridėkite pasirengimą, darbuotojų mokymą, priežiūrą ir sutartus naudojimo mokesčius. Atskirai parodykite vienkartines bei pasikartojančias išlaidas. Skaičiavimui naudokite tą patį užsakymų kiekį ir panašų sudėtingumą abiem darbo būdams. Vėliau įvertinkite, kaip išvada keistųsi sumažėjus arba padidėjus darbo apimčiai. Atlaisvinta darbuotojo valanda savaime dar nereiškia tiek pat sumažėjusių įmonės išlaidų.
Kokybę taip pat vertinkite konkrečiai: ar teisingas prekės kodas, kiekis ir data? Kiek užsakymų teko taisyti? Kurios klaidos galėtų sukelti neteisingą išsiuntimą? Papildomai paklauskite darbuotojų, ar patikra suprantama ir patogi. Jei tikrintojas turi nuolat ieškoti pirminio laiško, demonstracijoje matytas greitis gali neišlikti. Šias pastabas fiksuokite šalia matavimų, kad sprendimas remtųsi ir darbo patirtimi.
Pabaigoje pasirinkite: plėsti, koreguoti ar sustabdyti
Dar prieš bandymą paskirkite proceso šeimininką, kuris patvirtins vertinimo išvadą, darbuotoją, tikrinantį rezultatus, ir žmogų, registruojantį technines problemas. Mažoje komandoje vienas asmuo gali atlikti kelis vaidmenis, tačiau atsakomybės neturėtų likti numanomos. Sutarkite, kas leidžia pakeisti nustatymus ir kas gali laikinai grąžinti ankstesnę darbo tvarką. Keisdami sprendimą, užrašykite, kas pakeista ir kodėl. Jei vienu metu atnaujinsite kelis dalykus, bus sunkiau suprasti pagerėjimo priežastį. Po pataisymo patikrinkite ir anksčiau sėkmingai apdorotus pavyzdžius, kad naujas pakeitimas nesugadintų jau veikiančios dalies.
Jeigu sutarti tikslai pasiekti, numatykite laipsnišką plėtrą ir tolesnę stebėseną. Jei nauda matoma tik daliai laiškų, susiaurinkite apimtį arba koreguokite sprendimą ir kartokite vertinimą. Jei tikrinimo našta panaikina naudą, bandymą galima sustabdyti. Vertingas rezultatas yra ir pagrįstas sprendimas šiuo metu nediegti: įmonė sužino, kokių duomenų, darbo tvarkos ar sprendimo pakeitimų jai dar reikia.