Se splača AI rešitev kupiti ali razviti sami?

Ekipa preizkusi AI pomočnika, ki odgovarja na vprašanja iz dokumentov. Prvi odgovori so uporabni. Nekdo predlaga, da odpovedo naročnino na obstoječo rešitev in podobno orodje razvijejo sami. Cena dostopa do modela je precej nižja od računa za celotno storitev.

V tem ponazoritvenem primeru manjka večji del primerjave. Kdo bo vzdrževal povezave do podatkov? Kdo bo poskrbel za pravice dostopa? Kako bo sistem predal vprašanje človeku in kdo bo odpravil napako, ko bo odgovorna oseba na dopustu?

V skupinski razpravi RE:moat #41 se pojavi izkušnja z zamenjavo komercialnega klepetalnika z lastno rešitvijo ter ocena stroškov. Takšna izkušnja je dobro izhodišče za vprašanja, vendar brez podatkov o obsegu, kakovosti in vključenem delu iz nje ne moremo izpeljati splošnega prihranka.

Odločitev med nakupom in lastnim razvojem zahteva primerjavo iste storitve pod podobnimi pogoji. Spodnji okvir je praktična razdelava te teme za ekipe, ki razmišljajo o AI pomočniku ali avtomatizaciji dela.

Najprej napišite, kaj mora rešitev opraviti

Seznam funkcij hitro zavede. Dva ponudnika lahko oba obljubljata odgovarjanje iz internih dokumentov, vendar pod isto oznako ponujata precej različno storitev.

Pred primerjavo cen opišite dejanski potek dela. Kdo zastavi vprašanje? Do katerih podatkov sme dostopati? Kakšen odgovor potrebuje? Kaj se zgodi, če sistem odgovora ne najde ali če si viri nasprotujejo?

Za internega pomočnika bi lahko zapisali naslednje zahteve. To je ponazoritveni primer, ki ga je treba prilagoditi konkretnemu okolju:

• Odgovarja iz potrjenih internih navodil in ob odgovoru pokaže uporabljeni vir.

• Upošteva pravice dostopa posameznega zaposlenega.

• Uporablja veljavno različico navodila in zazna, da odgovora v gradivu ni.

• Nejasno vprašanje pred odgovarjanjem razjasni ali ga preda določeni osebi.

• Omogoča pregled napak in popravljanje gradiva, iz katerega odgovarja.

• Ob nedelovanju obstaja znan način, kako uporabnik nalogo dokonča drugače.

Ločite zahteve, brez katerih rešitve ne morete uporabljati, od funkcij, ki bi bile le dobrodošle. Sicer boste eno možnost zavrnili zaradi lepega dodatka, spregledali pa manjkajočo zaščito podatkov ali neuporaben izvoz.

Cena modela je samo ena postavka

Pri nakupu običajno najprej vidimo naročnino. Pri lastni rešitvi vidimo porabo modela in začetni razvoj. Celotna stroškovna slika potrebuje še delo, ki omogoča redno uporabo.

Vzpostavitev. Zajemite pripravo podatkov, razvoj ali nastavitev, povezave z obstoječimi sistemi, preizkušanje, pregled dostopov in uvajanje uporabnikov. Tudi kupljena rešitev lahko zahteva precej tega dela.

Redno delovanje. Poleg naročnine ali porabe modela vključite gostovanje, shranjevanje, iskanje po podatkih, nadzor, podporo in pregled rezultatov. Preverite omejitve paketov ter stroške pri dejanskem številu uporabnikov in obsegu uporabe.

Spremembe. Nekdo bo posodabljal vire, prilagajal povezave, preverjal vedenje po nadgradnjah in obravnaval nove zahteve. Lastna rešitev ostane vaš izdelek tudi po prvem uspešnem prikazu.

Napake in prekinitve. Upoštevajte čas za raziskovanje napake, popravek podatkov, obveščanje uporabnikov in ročno dokončanje nalog. Vseh posledic ne boste mogli zanesljivo izraziti v evrih. Takšne negotovosti naj ostanejo vidne v odločitvi.

Izhod. Koliko dela zahteva zamenjava ponudnika ali opustitev lastne rešitve? Preverite, kaj lahko izvozite, v kakšni obliki in ali lahko drugi ekipi predate kodo, nastavitve, podatke in dokumentacijo.

Za začetne in tekoče stroške uporabite enako časovno obdobje ter jasno zapišite predpostavke. Porabljene interne ure imajo vrednost, tudi če zanje ne prejmete novega računa. Razvoj rešitve lahko odloži drugo delo, ki ga ista ekipa potrebuje.

Primerjajte opravljeno delo, ne števila odgovorov

Nižja cena odgovora še ne pove, koliko stane opravljena naloga. Če mora zaposleni odgovor pogosto popravljati, poiskati manjkajoči vir ali nadaljevati postopek ročno, se del stroška preseli k njemu.

Pri pomočniku za podporo zato spremljajte, koliko primerov je rešenih pravilno, koliko jih zahteva posredovanje človeka in koliko časa vzame celoten primer. Če je pomočnik namenjen zaposlenim, preverite tudi, ali hitreje pridejo do pravilnega navodila in ali mu lahko sledijo.

Obe možnosti preskusite na primerljivih nalogah. Vključite običajna vprašanja, zahtevnejše primere in situacije, v katerih rešitev odgovora ne bi smela podati. Uspešen odziv je lahko tudi jasna navedba, da podatka ni, skupaj z ustrezno predajo človeku.

Isti nabor primerov uporabite še po spremembah modela, virov ali nastavitev. Tako lažje opazite, če pocenitev poslabša kakovost ali izboljšava enega dela poruši drugega.

Preizkus naj pokaže, katera možnost izpolni zahteve

Začetni preizkus omejite na dovolj majhen del procesa, da lahko rezultate ročno pregledate. Hkrati naj vsebuje zahteve, ki bodo odločale o resnični uporabi. Prikaz z javnimi dokumenti ne pove dovolj o tem, ali rešitev pravilno ločuje dostop do internih podatkov.

Pred začetkom določite:

• katere primere mora rešitev obdelati;

• kaj šteje kot pravilen in uporaben rezultat;

• koliko pregledovanja in popravljanja še dopuščate;

• katere napake pomenijo, da uvedbo ustavite;

• kdo bo po preizkusu vzdrževal rešitev.

Med preizkusom beležite čas ekipe, porabo, napake in nedokončane naloge. Ob koncu primerjajte tudi stroške, ki še niso nastali, vendar bi bili potrebni za uvedbo. Delujoč prikaz brez spremljanja napak, urejenih dostopov ali podpore še ne predstavlja celotne rešitve.

Za stroške uporabite razpon, kadar jih še ne poznate dovolj dobro. Pripravite osnovni scenarij in scenarij z večjo uporabo ali zahtevnejšim vzdrževanjem. Če se odločitev ob majhni spremembi predpostavke obrne, potrebujete več podatkov ali manjšo začetno zavezo.

Rešitev potrebuje odgovorno osebo tudi po zagonu

Pri internih orodjih je pomembno vprašanje, kdo jih zna popravljati. Rešitev, ki jo razume ena oseba, lahko postane težava ob njeni odsotnosti, menjavi vloge ali odhodu.

Pred širšo uporabo preverite, ali lahko drug član ekipe najde dokumentacijo, razume povezave, ponovi preizkuse in odpravi običajno napako. Določite tudi, kdo potrjuje spremembe in kdo lahko začasno ustavi delovanje.

Pri zunanjem ponudniku preverite podporo, odgovornost za posamezne dele storitve in pogoje prenehanja. Pogodba ali paket sama po sebi ne povesta, kako bo potekalo reševanje vašega konkretnega zapleta. Koristno je poznati postopek in meje podpore, preden ste od nje odvisni.

Podobno velja za podatke. Interno razvit uporabniški vmesnik še ne pomeni, da vsi podatki ostajajo znotraj podjetja. Popišite zunanje storitve in dejanske prenose podatkov pri obeh možnostih.

Včasih je smiselna kombinacija

Izbira ni nujno med celotnim komercialnim izdelkom in razvojem vsega od začetka. Ekipa lahko kupi osnovno platformo ter sama pripravi povezavo do svojega procesa, omejen uporabniški vmesnik ali preverjanje rezultatov.

Takšna rešitev je smiselna, kadar obstoječi izdelek dobro pokrije splošne potrebe, posebnost podjetja pa je v manjšem delu postopka. Tudi tu potrebujete jasne meje: kdo vzdržuje povezavo, kdo zagotavlja podporo in kaj se zgodi ob spremembi platforme.

Nakup je vreden resne obravnave, kadar so potrebe običajne, ustrezna rešitev že obstaja in ekipa nima zmogljivosti za njeno dolgoročno vzdrževanje. Lasten razvoj ima več smisla, kadar pomembne zahteve ostajajo nepokrite, ekipa jih zna preveriti in je pripravljena prevzeti trajno skrb za rešitev. V obeh primerih naj odločitev podpira preizkus na dejanskem delu.

Odločitev zapišite tako, da jo lahko pozneje preverite

Na eno stran zapišite izbrano možnost, obvezne zahteve, pričakovane stroške, rezultate preizkusa, odprta tveganja in odgovorno osebo. Dodajte okoliščine, zaradi katerih boste odločitev ponovno odprli: spremembo obsega uporabe, kakovosti, pogojev ponudnika ali razpoložljivosti ekipe.

Tako boste pozneje lahko preverili, ali je rešitev izpolnila pričakovanja. Podatek o nizki ceni modela ostane uporaben, vendar ga boste presojali skupaj z delom in odgovornostmi, ki jih zahteva vaša storitev.

Če se v ekipi odločate, kateri proces podpreti z AI in kako preveriti smiselnost rešitve, si oglejte GenAI izobraževanja FaciliTribe. V povpraševanju opišite proces, sedanji način dela in možnosti, med katerimi se odločate.

Izhodišče članka je skupinska razprava v RE:moat #41. Primer internega pomočnika, stroškovni okvir in postopek preizkusa so uredniška praktična razdelava teme. Članek ne predstavlja preverjene primerjave stroškov konkretnih ponudnikov.