Всяко ръководство, което започва да работи с AI, рано или късно се сблъсква с този въпрос: кое решение може да вземе система, и кое решение остава при човек. Въпросът звучи просто. Отговорът често не е такъв, защото границата не се намира в самото решение, а в това, което организацията е организирала около него.
Не съществува фиксиран списък с решения, които по дефиниция трябва да останат човешки. Решение за уволнение, отказ на кредит, медицинска преценка: това са примери, които често се споменават, но причината, поради която са чувствителни, се различава по организация. При една институция става дума за юридическа отговорност, при друга за необратимостта на резултата, при трета за липсата на добра граница на грешка. Който копира списък от друга организация, копира отговор без да е поставил въпроса.
Което наистина работи, е да разглобите самото решение: какво е въздействието, ако се обърка, поправим ли е резултатът, и има ли човек, който може да разкаже и обоснове резултата. Тези три въпроса са основата на онова, което на друго място се наричат правила за агенти: установени граници, които определят кога система може да продължи да работи и кога трябва да спре и да включи човек.
Изкушението е голямо да се прехвърли този въпрос на ИТ, като че ли е настройка, която конфигурирате веднъж. Това не работи, поради една проста причина: правило за агент е надеждно само ако организацията около него е в ред. Ако никой не знае кой е собственик на процес, никой не може да определи кой е точката за ескалация. Ако данните не са в ред, система не знае кога среща изключение, което изисква човек. Фундаменталните измерения на организацията — управление, инфраструктура, управление на данни — затова предхождат въпроса кои решения могат да бъдат автоматизирани. Без тази основа всяка граница, която начертаете, е граница само на хартия.
Това е и причината, поради която този въпрос рядко живее на едно място в организацията. Ръководството вижда риска, ИТ директорът вижда техническата осъществимост, собственикът на процеса вижда ежедневната практика. Как да съберете тези три гледни точки, преди темпото на автоматизация да се превърне в източник на разногласие, е описано в как да проведете разговора за темпото между надзорния съвет и изпълнителното ръководство. Който поставя този въпрос едва когато първият пилотен проект вече тече, го поставя твърде късно.
Измерването на зрелостта на hybridresourcing показва дали организацията има основата, необходима за да начертае тези граници по смислен начин. Седем измерения, пет нива от baseline до intelligence, и кръг на нанасяне на точки, в който няколко човека оценяват поотделно. Тази разлика в оценките често е най-полезната част: ако CHRO постави зрелостта на данните на activation, а ИТ директорът на baseline, знаете, че първо трябва да се проведе разговор, преди да се напише правило на хартия, което никой не може да изпълни.
Което измерването не прави, е да каже кое решение във вашата организация може да бъде автоматизирано. То измерва готовност, не подходящост на конкретна задача. То ви казва дали организацията може да поеме онова, на което AI е способен, не какво AI би поел конкретно. Тази разлика между поемане на тежест и поемане на задача е разликата между понасяне на AI и поемане на AI, и тя е разграничение, което тази страница съзнателно поддържа: резултат от измерването не е нито разрешение, нито забрана, той е снимка на състоянието, в което организацията се намира в момента.
Тази снимка застарява. Организация, която днес получава оценка foundation за управление на данни, може след година да бъде на activation, или също така да е останала на място. Колко често е смислено да се измерва отново, и от какво зависи това, можете да прочетете в колко често трябва да се повтаря измерване на зрелостта. Еднократно измерване, което изчезва в чекмедже, има малка стойност; измерване, което рестартира разговора в ръководството, има.
Измерването не разрешава разногласието във вашето ръководство. То го прави видимо, а това не е същото. Ако вашият надзорен съвет и изпълнителното ръководство отдавна са в разногласие относно темпото на приемане на AI, причината често е по-дълбока от липса на факти: става дума за готовност за поемане на риск, за кой за какво носи отговорност, за какво се случва, когато някой отвори чат прозорец и мисли, че с това е внедрил AI в организацията. Онова, което не виждате, ако познавате само чат прозореца, е точно тази част от организацията, за която става дума в този въпрос: инфраструктурата, правилата, хората, които знаят кога система трябва да спре. Защо вашето ръководство е в разногласие относно темпото, е обяснено на тази страница, и често е по-полезно първо да се проведе този разговор, отколкото да се изчака пилотен проект да се провали и въпросът все пак да излезе на масата.
Тази страница разглежда границата, която начертавате предварително: кое решение остава при човек, независимо от това какво система е технически способна да поеме. Веднага след като тази граница е приблизително установена, въпросът се измества към самата работа: кои задачи в рамките на тази граница са подходящи за предаване, и коя част от една функция остава, независимо от организационната готовност, човешка работа. На този въпрос измерването на зрелостта не отговаря. Работният анализ на FTE TO AI изчислява за всяка задача коя част от работата може да бъде поета от AI, и по този начин се свързва с точката, в която тази страница завършва: не дали вашата организация е готова, а какво конкретно стои на масата за предаване, щом е готова.
Инструментът, с който сами картографирате това, е в процес на изграждане. Който желае да направи измерването веднага щом стане достъпно, може да се запише в списъка на чакащите.
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.