Чат прозорец, в който някой задава въпрос и получава отговор, изглежда просто. Това, което трябва да се случи отдолу, не е просто. Подпомагане на решения с AI означава, че система комбинира данни от множество източници, поставя ги в правилния контекст и формулира отговор, на който някой се осмелява да действа. Всяка стъпка в тази верига поставя изискване към организацията, което предшества въпроса кой модел или коя платформа се избира.
Модел, който подпомага решения, е толкова добър, колкото данните, които вижда. Това означава, че цифрите от различни системи трябва да използват една и съща дефиниция, че историческите данни са достъпни без някой първо да трябва да ги експортира ръчно, и че е ясно кой източник е меродавен, когато две системи си противоречат. Организациите, които все още не са наред с това, го забелязват едва в момента, когато отговорът на системата не съвпада с това, което хората на терена вече знаеха.
Подпомагането на решения често се намира на кръстопътя на множество отдели: момента, в който информацията трябва да премине от едно място на друго, за да се получи добро решение. Това прави релевантно как координацията между отделите работи във вашата организация, защото система, която дава съвет, който след това остава да лежи между два отдела, не е донесла нищо. Същата логика се отнася и за източниците, с които се захранва съветът: ако тези източници се състоят от документи, които първо трябва да се прочетат и обобщят, преди да може да се направи нещо с тях, въпросът какво изисква четенето и обобщаването на документи от организацията пряко влияе на скоростта и надеждността на съвета, който се получава от това.
Част от подпомагането на решения не се състои от отговаряне на въпрос, който някой активно задава, а от сигнализиране на нещо, което заслужава внимание, преди някой да попита за него. Това поставя различни изисквания от чат прозорец: трябва да има нещо, което непрекъснато наблюдава, разпознава прагови стойности и прави разлика между шум и сигнал, който наистина има значение. Какво изисква това от мониторинга и сигнализирането е въпрос, на който трябва да се отговори отделно, и който иска да знае какво изисква мониторингът и сигнализирането от организацията, вижда, че не става дума само за техника, но и за кой получава сигналите и какво се случва с тях.
Много решения се подготвят в разговори: с клиенти, с доставчици, между колеги. Ако тези разговори не се фиксират по начин, който е използваем повторно, системата, която трябва да подпомага решение, пропуска точно материала, който е формирал повода. Това прави видимо какво изисква фиксирането и проследяването на разговори от организацията, тема, която пряко засяга въпроса дали подпомагането на решения може да се изгради върху нещо, или върху нищо. Който иска да научи повече за какво изисква фиксирането и проследяването на разговори, вижда връзката с качеството на всеки съвет, който по-късно се извежда от тези разговори.
Не е нетипично, че един екип, с един набор от данни и един случай на употреба, показва работеща версия на подпомагане на решения. Това доказва, че е възможно, не че е възможно в цялата организация. Веднага щом втори отдел с други системи, други собственици на данни и други дефиниции иска да се включи, често се оказва, че първата версия е била изработена по мярка точно за онзи един екип. Защо пилотен проект, който работи само в своя ъгъл, не носи резултат, не е тогава въпрос на разочароваща техника, а на основа, която никога не е била положена по-широко. За който иска да прочете повече за това: защо пилотен проект, който работи само в своя ъгъл, не носи резултат обяснява какво липсва между демо и приложение в цялата организация.
Система може да дава най-добре обоснования съвет и все пак да не променя нищо, ако никой не носи отговорност да работи с него. Това е организационен въпрос, не технически въпрос: кой е собственик на съвета, кой оценява дали се изпълнява, и кой обяснява защо веднъж не е бил изпълнен. Без този собственик подпомагането на решения изчезва в категорията на интересни експерименти. Защо демо без собственик не носи резултат, е свързано с тази същата точка, и който иска да следва точната аргументация, може да я намери на защо демо без собственик не носи резултат.
Изискванията, които подпомагането на решения поставя, се отнасят до голяма степен до това какво трябва вече да стои, преди чат прозорецът да може да направи нещо смислено: чисти и достъпни данни, работещо предаване между отдели, структурирано фиксиране на разговори и документи, и ясен собственик за това, което системата дава. Точно затова измерването на зрелостта на hybridresourcing.com разглежда фундаменталните измерения, преди да се стигне до зависимите: организация, IT-инфраструктура и управление на данни определят дали има нещо, върху което да се изгради подпомагане на решения.
Въпросът дали организацията може да носи това е отделен от въпроса каква част от работата действително може да бъде поета от AI. Последното изчислява работният анализ на FTE TO 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.