Kiekviena vadovybė, kuri pradeda dirbti su AI, anksčiau ar vėliau susiduria su šiuo klausimu: kokį sprendimą gali priimti sistema, ir kokį sprendimą turi priimti žmogus. Klausimas skamba paprastai. Atsakymas dažnai nėra paprastas, nes riba nėra pačiame sprendime, o tame, kaip organizacija sutvarkė visa, kas yra aplink jį.
Nėra fiksuoto sąrašo sprendimų, kurie iš principo turi likti žmogaus rankose. Sprendimas atleisti darbuotoją, kredito atmetimas, medicininis įvertinimas: tai pavyzdžiai, kurie dažnai minimi, tačiau priežastis, kodėl jie yra jautrūs, skiriasi nuo organizacijos iki organizacijos. Vienoje institucijoje tai susiję su teisine atsakomybe, kitoje – su rezultato negrįžtamumu, trečioje – su tinkamos paklaidos ribos trūkumu. Kas nukopijuoja sąrašą iš kitos organizacijos, nukopijuoja atsakymą, neuždavęs klausimo.
Kas veikia, tai sprendimo analizė iš esmės: kokia poveikio apimtis, jei kažkas nepavyks, ar rezultatą galima atitaisyti, ir ar yra kas nors, kas gali paaiškinti rezultatą ir už jį atsiskaityti. Šie trys klausimai yra pagrindas to, kas kitur vadinama agentų taisyklėmis: fiksuotomis ribomis, kurios nustato, kada sistema gali tęsti darbą, o kada ji turi sustoti ir įtraukti žmogų.
Didelė pagunda šį klausimą perduoti IT skyriui, tarsi tai būtų nustatymas, kurį konfigūruojate vieną kartą. Tai neveikia, ir priežastis paprasta: agentų taisyklė yra patikima tik tuomet, jei organizacija aplink ją yra sutvarkyta. Jei niekas nežino, kas yra proceso savininkas, niekas negali nustatyti, kas yra eskalavimo taškas. Jei duomenys nėra sutvarkyti, sistema nežino, kada susiduria su išimtimi, kuriai reikia žmogaus. Todėl pamatiniai organizacijos dimensijos – valdymas, infrastruktūra, duomenų valdymas – turi eiti pirmiau klausimo, kokie sprendimai gali būti automatizuoti. Neturint šio pagrindo, kiekviena riba, kurią nustatote, yra riba popieriuje.
Tai tuoj pat paaiškina, kodėl šis klausimas retai kyla vienoje organizacijos vietoje. Vadovybė mato riziką, IT direktorius mato techninį įgyvendinamumą, proceso savininkas mato kasdienę praktiką. Kaip suvesti šias tris perspektyvas kartu, kol automatizacijos tempas netampa nesutarimų šaltiniu, aprašyta kaip vesti pokalbį apie tempą tarp valdybos ir vadovybės. Kas šį klausimą užduoda tik tada, kai pirmasis bandomasis projektas jau veikia, užduoda jį pavėluotai.
„hybridresourcing“ brandumo vertinimas parodo, ar organizacija turi pagrindą, kuris leidžia prasmingai nustatyti tokias ribas. Septynios dimensijos, penki lygiai nuo baseline iki intelligence, ir vertinimo raundas, kuriame keli žmonės vertina nepriklausomai vienas nuo kito. Tas skirtumas dažnai yra naudingiausia dalis: jei personalo direktorė (CHRO) duomenų brandumą įvertina kaip activation, o IT direktorius – kaip baseline, žinote, kad pirmiausia turi vykti pokalbis, kol nebus nustatyta taisyklė popieriuje, kurios niekas negalės įgyvendinti.
Ko vertinimas nedaro – jis nesako, kokį sprendimą jūsų organizacijoje galima automatizuoti. Jis vertina pasirengimą, o ne konkrečios užduoties tinkamumą. Jis pasako, ar organizacija gali atlaikyti tai, ką AI gali padaryti, o ne tai, ką AI konkrečiai perimtų. Šis skirtumas tarp atlaikymo ir perėmimo yra skirtumas tarp AI atlaikymo ir AI perėmimo, ir tai yra skirtumas, kurį šis puslapis sąmoningai išlaiko: vertinimo balas nėra nei leidimas, nei draudimas, tai yra nuotrauka, parodanti organizacijos būklę šiuo metu.
Toks vaizdas pasensta. Organizacija, kuri šiandien duomenų valdymo srityje įvertinta kaip foundation, po metų galėtų būti activation lygyje, arba lygiai taip pat galėjo likti toje pačioje vietoje. Kaip dažnai prasminga atlikti pakartotinį vertinimą ir nuo ko tai priklauso, skaitykite kaip dažnai reikia kartoti brandumo vertinimą. Vienkartinis vertinimas, kuris atsiduria stalčiuje, turi mažai vertės; vertinimas, kuris atnaujina pokalbį vadovybėje, turi.
Vertinimas neišsprendžia nesutarimo jūsų vadovybėje. Jis padaro jį matomą, ir tai nėra tas pats. Jei jūsų valdyba ir vadovybė ilgą laiką nesutaria dėl AI diegimo tempo, priežastis dažnai yra gilesnė nei faktų trūkumas: tai susiję su rizikos tolerancija, su tuo, kas už ką laikomas atsakingu, su tuo, kas nutinka, kai kas nors atsidaro pokalbių langą ir pagalvoja, kad tuo pačiu įsileido AI į organizaciją. Ko nepamatysite, jei pažįstate tik pokalbių langą, yra tiksliai ta organizacijos dalis, apie kurią kalba šis klausimas: infrastruktūra, taisyklės, žmonės, kurie žino, kada sistema turi sustoti. Kodėl jūsų vadovybė nesutaria dėl tempo, paaiškinta šiame puslapyje, ir dažnai naudingiau tą pokalbį pravesti iš anksto, nei laukti, kol bandomasis projektas užstringa ir klausimas iškyla vėlgi.
Šis puslapis kalba apie ribą, kurią nustatote iš anksto: kokį sprendimą turi priimti žmogus, nepriklausomai nuo to, ką sistema techniškai gali. Kai ta riba nustatoma apytiksliai, klausimas persikelia į paties darbo lygmenį: kurios užduotys tos ribos ribose yra tinkamos perduoti, ir kuri funkcijos dalis lieka žmogaus darbu, nepriklausomai nuo organizacijos pasirengimo. Į šį klausimą brandumo vertinimas neatsako. FTE TO AI darbo skanavimas (werkscan) apskaičiuoja pagal kiekvieną užduotį, kurią darbo dalį gali perimti AI, ir tuo susisieja su tašku, kuriame šis puslapis baigiasi: ne ar jūsų organizacija yra pasirengusi, o kas konkrečiai laukia, kad būtų perduota, kai ji tokia bus.
Įrankis, kuriuo tai galėsite pasitikrinti patys, yra kūrimo stadijoje. Kas norėtų atlikti vertinimą, kai jis bus prieinamas, galite užsirašyti į laukiančiųjų sąrašą.
Vraag maar wat er moet staan voordat AI in uw organisatie kan landen.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.