Pokalbio langas, kuriame kažkas užduoda klausimą ir gauna atsakymą, atrodo paprastas. Kas turi vykti po tuo, nėra paprasta. Sprendimų palaikymas su AI reiškia, kad sistema sujungia duomenis iš kelių šaltinių, įdeda juos į tinkamą kontekstą ir formuluoja atsakymą, kuriuo kažkas drįstų vadovautis veikdamas. Kiekvienas žingsnis šioje grandinėje kelia organizacijai reikalavimą, kuris eina prieš klausimą, kuris modelis ar platforma bus pasirinkta.
Modelis, kuris palaiko sprendimus, yra tik toks geras, kokie yra duomenys, kuriuos jis mato. Tai reiškia, kad skaičiai iš skirtingų sistemų turi laikytis tos pačios apibrėžties, kad istoriniai duomenys yra pasiekiami be to, kad kažkas juos pirmiausia turėtų rankiniu būdu eksportuoti, ir kad yra aišku, kuris šaltinis yra autoritetingas, kai dvi sistemos vienai kitai neprieštarauja. Organizacijos, kurios šito dar nėra sutvarkiusios, tai pastebi tik tuo momentu, kai sistemos atsakymas neatitinka to, ką žmonės aikštėje jau žinojo.
Sprendimų palaikymas dažnai yra kelių skyrių sankirtoje: momente, kai informacija turi persikelti iš vienos vietos į kitą, kad iš to išeitų geras sprendimas. Todėl svarbu, kaip koordinacija tarp skyrių veikia jūsų organizacijoje, nes sistema, kuri duoda patarimą, kuris tada užstringa tarp dviejų skyrių, nedavė nieko. Ta pati logika taikoma šaltiniams, kuriais patarimas yra maitinamas: jei tie šaltiniai susideda iš dokumentų, kuriuos pirmiausia reikia perskaityti ir apibendrinti, kad su jais būtų galima ką nors nuveikti, tada klausimas, ko dokumentų skaitymas ir apibendrinimas reikalauja iš organizacijos, tiesiogiai įtakoja greitį ir patikimumą patarimo, kuris iš to išeina.
Dalis sprendimų palaikymo nesusideda iš atsakymo į klausimą, kurį kažkas aktyviai užduoda, o iš to, kad signalizuojama apie kažką, kas verta dėmesio, prieš tai, kai kažkas apie tai paklausia. Tai kelia kitokius reikalavimus nei pokalbio langas: turi būti kažkas, kas nuolat stebi, atpažįsta ribines vertes ir atskiria triukšmą nuo signalo, kuris tikrai turi reikšmę. Ko tai reikalauja iš monitoringo ir signalizavimo yra klausimas, kurį reikia atsakyti atskirai, ir tas, kas norėtų sužinoti, ko monitoringas ir signalizavimas reikalauja iš organizacijos, pamato, kad kalbama ne tik apie techniką, bet ir apie tai, kas signalus priima ir kas su jais toliau daroma.
Daug sprendimų yra paruošiami pokalbiuose: su klientais, su tiekėjais, tarp kolegų. Jei tie pokalbiai nėra fiksuojami taip, kad būtų pakartotinai naudojami, sistemai, kuri turi palaikyti sprendimą, trūksta tiksliai medžiagos, kuri sudarė priežastį. Tai atskleidžia, ko pokalbių fiksavimas ir tolesnis stebėjimas reikalauja iš organizacijos - tema, kuri tiesiogiai susijusi su klausimu, ar sprendimų palaikymas gali statyti ant kažko, ar ant nieko. Tas, kas norėtų daugiau sužinoti apie tai, ko pokalbių fiksavimas ir tolesnis stebėjimas reikalauja, pamato ryšį su kiekvieno patarimo, kuris vėliau iš tų pokalbių išvedamas, kokybe.
Nėra neįprasta, kad viena komanda, su vienu duomenų rinkiniu ir vienu naudojimo atveju, parodo veikiančią sprendimų palaikymo versiją. Tai įrodo, kad tai gali veikti, bet ne tai, kad tai gali veikti visoje organizacijoje. Kai antras skyrius su kitomis sistemomis, kitais duomenų savininkais ir kitomis apibrėžtimis norės prisijungti, dažnai pasirodo, kad pirmoji versija buvo pritaikyta tiksliai tai vienai komandai. Kodėl pilotinis projektas, kuris veikia tik savo kampelyje, nieko neduoda, tada nėra techninio nusivylimo klausimas, o klausimas apie pagrindą, kuris niekada nebuvo sukurtas plačiau. Tas, kas apie tai norėtų daugiau paskaityti: kodėl pilotinis projektas, kuris veikia tik savo kampelyje, nieko neduoda paaiškina, kas trūksta tarp demonstracijos ir pritaikymo visoje organizacijoje.
Sistema gali duoti geriausiai pagrįstą patarimą ir vis tiek nieko nepakeisti, jei niekas neprisiima atsakomybės su juo dirbti. Tai organizacinis, ne techninis dalykas: kas yra patarimo savininkas, kas įvertina, ar jo laikomasi, ir kas paaiškina, kodėl jo kartą nesilaikyta. Be to savininko sprendimų palaikymas atsiduria įdomių eksperimentų kategorijoje. Kodėl demonstracija be savininko nieko neduoda, susijusi su tuo pačiu dalyku, ir tas, kas norėtų sekti tikslų argumentavimą, gali jį rasti kodėl demonstracija be savininko nieko neduoda.
Reikalavimai, kuriuos kelia sprendimų palaikymas, didžia dalimi susiję su tuo, kas turi būti sutvarkyta jau anksčiau, kad pokalbio langas galėtų padaryti kažką reikšmingo: švarūs ir pasiekiami duomenys, veikiantis perdavimas tarp skyrių, struktūruotas pokalbių ir dokumentų fiksavimas, ir aiškus savininkas tam, ką sistema pateikia. Tai tiksliai priežastis, kodėl hybridresourcing brandumo vertinimas žiūri į fundamentalias dimensijas prieš tai, kai kalbama apie priklausomas: organizacija, IT infrastruktūra ir duomenų valdymas nustato, ar yra kažkas, ant ko galima statyti sprendimų palaikymą.
Klausimas, ar organizacija tai gali pakelti, yra atskiras nuo klausimo, kurią darbo dalį galima faktiškai perleisti AI. Tai antra apskaičiuoja FTE TO AI darbo skanavimas kiekvienai užduočiai: kokia darbo dalis gali būti perleista, ir su kokiomis sąlygomis. Kur šis puslapis aprašo, kas turi būti sutvarkyta, kad sprendimų palaikymas galėtų funkcionuoti, darbo skanavimas aprašo, kas, kai tas pagrindas jau yra, konkrečiai pasikeičia paties darbo srityje.
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.