Двотижневий пілот ШІ запускають як короткий експеримент з умовами, які записані ще до старту. До першого дня треба зафіксувати один процес, його власника, один показник успіху, виміряний стартовий рівень цього показника, дату завершення, перелік того, що під час пілоту не змінюється, і правило, за яким ухвалюється рішення. Пілот вдався, коли показник покращився проти стартового рівня, нових помилок не з'явилося, а власник процесу готовий продовжити. Якщо хоча б одна з цих трьох умов не виконана, пілот усе одно дав корисне знання, але підстав для розширення поки немає.
Коротко
- Пілот ШІ є коротким експериментом на одному процесі, умови якого записують до старту, щоб наприкінці оцінювати результат, а не враження.
- До першого дня фіксують шість пунктів: процес і його межі, власника процесу, показник успіху, стартовий рівень, дату завершення і перелік того, що не змінюється.
- Стартовий рівень вимірюють на кількох звичайних циклах роботи, бо без нього результат пілоту немає з чим порівняти.
- Протягом двох тижнів ШІ працює паралельно з людиною, а реальні документи й рішення залишаються такими, як завжди.
- На чотирнадцятий день власник процесу обирає один із трьох заздалегідь записаних варіантів: продовжити, доопрацювати й повторити або зупинити.
Чим пілот ШІ відрізняється від спроби нового інструменту?
Коли компанія пробує новий інструмент, кілька людей працюють із ним якийсь час, а потім обмінюються враженнями. Хтось задоволений, хтось розчарований, і рішення ухвалюють за настроєм найголоснішого учасника. Пілот влаштований інакше: це експеримент, у якому до старту названо, що саме перевіряється, як це виміряти і що вважатиметься успіхом. Тоді наприкінці команда порівнює цифри зі стартовим рівнем і дивиться на записане правило рішення, а суперечка про відчуття стає непотрібною.
Різниця має практичні наслідки. За прогнозом однієї з аналітичних компаній, приблизно кожен третій проєкт генеративного ШІ, тобто систем, які створюють тексти, таблиці чи відповіді на запит, закидають після пробного етапу. Серед причин називають погану якість даних, слабкий контроль ризиків, зростання витрат і неясну користь для бізнесу. Це прогноз, а не виміряний факт, але остання причина заслуговує на окрему увагу. Неясна користь найчастіше означає, що до старту ніхто не записав, що вважати успіхом, і через два тижні нема з чим порівнювати.
Вибір задачі та опис процесу передують пілоту, тож тут ідеться вже про наступний крок: як провести сам експеримент так, щоб на його завершенні відповідь була очевидною.
Що записати до старту пілоту?
Перед стартом варто скласти коротку картку пілоту на одну сторінку. Вона потрібна, щоб усі учасники однаково розуміли, що відбувається, і щоб наприкінці ніхто не переписував умови заднім числом. У картці мають бути шість пунктів:
- Процес і його межі: що саме входить у пілот, де процес починається і де закінчується, які суміжні задачі залишаються поза ним.
- Власник процесу: людина, яка відповідає за цей процес у звичайному житті компанії і яка наприкінці ухвалює рішення.
- Один показник успіху: величина, за якою оцінюватимуть результат, наприклад час на підготовку документа або кількість правок.
- Стартовий рівень цього показника: значення, виміряне до запуску ШІ на звичайній роботі.
- Дата завершення: конкретний день, коли пілот закінчується і ухвалюється рішення, навіть якщо хтось захоче ще трохи подивитися.
- Що під час пілоту не змінюється: джерело даних, шаблон, учасники, інструмент і налаштування доступу.
Поруч із цими пунктами записують правило рішення: за якого результату пілот продовжують, за якого доопрацьовують, а за якого зупиняють. Правило формулюють через показник і через помилки, щоб воно не залежало від настрою на чотирнадцятий день. Картку підписує або погоджує власник процесу, і з цієї миті умови вважаються зафіксованими.
Як обрати один показник успіху і виміряти стартовий рівень?
Показник успіху має прямо впливати на час або гроші компанії. Найчастіше це години на підготовку певного документа, кількість помилок у результаті, кількість правок, які людина вносить до чернетки, або швидкість відповіді клієнтові. Показник на кшталт задоволеності команди новим інструментом теж цікавий, але він погано відповідає на питання, чи варто вкладатися далі. Краще обрати один показник і виміряти його добре, ніж розпорошитися на кілька й не довести жоден до порівнянних даних.
Стартовий рівень вимірюють до запуску ШІ, на кількох звичайних циклах роботи. Якщо процес повторюється щотижня, працівник кілька разів поспіль записує, скільки часу забрала підготовка і скільки помилок довелося виправляти. Без цього заміру будь-який результат пілоту висить у повітрі: здається, що стало швидше, але ніхто не знає, наскільки й порівняно з чим. Замір варто робити саме на типових циклах, без авралів і нетипових ситуацій, бо інакше стартовий рівень вийде викривленим.
Окремо перевіряють стабільність результату. Для цього ШІ кілька разів дають ті самі вхідні дані й порівнюють відповіді. Якщо на однакових даних він видає помітно різні результати, система ще не готова до роботи в процесі, навіть коли в середньому вона влучає. Людина, яка покладається на інструмент, має знати, що завтра він поведеться так само, як сьогодні. Найзручніше робити такі перевірки спершу вручну, у звичайному чаті з ШІ: порахувати точність, швидкість і вартість на справжніх документах, а в повну автоматизацію вкладатися лише після цього.
Як виглядає двотижневий пілот на плануванні закупівель?
Візьмімо типову ситуацію. Невелика дистриб'юторська компанія щотижня готує замовлення постачальникам на основі залишків на складі й продажів за попередні тижні. Цю роботу виконує відповідальний працівник, і вона забирає помітну частину його тижня. Для пілоту обирають саме цей процес, бо він повторюється регулярно, має зрозумілий результат і власника, який добре його знає.
Пілот проходить у паралельному режимі. Це означає, що ШІ виконує ту саму роботу поруч із людиною, але його результат ніде не використовується як остаточний. ШІ отримує дані про залишки й продажі з одного погодженого джерела і готує свою пропозицію замовлення. Працівник складає замовлення як завжди, своїм звичним способом, а потім порівнює його з пропозицією ШІ і записує, що довелося б виправити. Реальні замовлення постачальникам не змінюються, тож бізнес нічим не ризикує.
Після кожного циклу працівник заповнює короткий журнал пілоту. У ньому три записи: скільки часу забрала робота з пропозицією ШІ, які правки довелося внести і з якої причини. Причини правок особливо цінні: вони показують, чи помиляється ШІ випадково, чи систематично не враховує щось важливе, наприклад сезонність або особливості окремого постачальника. За два тижні такий журнал дає матеріал для рішення значно надійніший за будь-які враження.
У такого пілоту є межі. За два тижні можна виміряти час на підготовку і кількість правок, але не точність прогнозу попиту. Щоб оцінити, чи справді ШІ краще передбачає, скільки товару знадобиться, потрібен довший період, за який встигнуть проявитися і нестачі, і надлишки на складі. Два тижні взагалі підходять лише процесу, який повторюється часто: для рідкісного процесу краще закласти довший строк, інакше вимірювань буде замало для висновку.
Що не можна змінювати під час пілоту?
Під час пілоту фіксують усе, що може вплинути на результат: джерело даних, шаблон документа, склад учасників, сам інструмент і налаштування доступу. Якщо посеред експерименту замінити джерело даних, переробити шаблон і додати нових учасників, наприкінці неможливо зрозуміти, що саме дало покращення чи погіршення. Бажання щось підкрутити на ходу природне, але кожну ідею краще записати в журнал і перевірити в наступному пілоті.
Доступ на час пілоту варто давати лише на читання. Так ШІ бачить дані, потрібні для роботи, але нічого не може змінити в обліку чи відправити від імені компанії. Учасників має бути мало, а сам пілот бажано проводити в пісочниці, тобто в окремому середовищі, де помилки не зачіпають реальну роботу. Розширювати ліцензії, додавати користувачів чи відкривати нові доступи до завершення пілоту не варто, навіть якщо перші дні виглядають переконливо.
Буває, що вже на тесті з'ясовується, що права доступу треба розмежовувати інакше, ніж планували: комусь потрібні інші дані, а комусь, навпаки, не слід бачити частину інформації. Це теж корисний результат пілоту. Набагато дешевше дізнатися про це на малій групі з правами лише на читання, ніж після розширення на всю компанію.
Як на чотирнадцятий день вирішити, чи пілот вдався?
На чотирнадцятий день власник процесу збирає журнал, порівнює показник зі стартовим рівнем і застосовує правило, записане до старту. Варіантів рішення три. Перший: продовжити й обережно розширити, якщо показник покращився, нових помилок не з'явилося, а власник процесу готовий працювати з ШІ далі. Другий: доопрацювати й повторити, якщо користь видно, але є систематичні правки, які можна усунути, змінивши дані, шаблон чи інструкцію для ШІ. Третій: зупинити, якщо покращення немає або ШІ додає помилок, яких раніше не було.
Рішення ухвалюють за записаним правилом, а не за враженням. Буває, що користь на рутинних випадках підтверджується, а на складних ШІ дає розбіжності. Тоді чесне рішення часто полягає в тому, щоб віддати ШІ рутинну частину, а складні випадки залишити людині. Оцінку зручно робити двійковою: кожен критерій або виконано, або ні, без розмитих проміжних оцінок.
У журналі варто тримати окремий рядок для витрат на ліцензії та оплату за використання. Буває, що головною несподіванкою пілоту стає не якість, а вартість: результат влаштовує, але при розширенні на весь обсяг роботи рахунок виходить більшим, ніж очікували. Якщо в пілоті відчувалася ціна помилки, тобто можливі наслідки неправильного замовлення чи відповіді, це теж записують, бо від неї залежить, наскільки широко можна розширювати.
Зупинка пілоту теж є повноцінним результатом. Компанія за два тижні дізналася, що цей процес у цьому вигляді поки не готовий до ШІ, і заощадила гроші, які інакше пішли б на велике впровадження. Нерідко після великого аудиту розумніше запустити кілька дешевих пілотів на інструментах, які компанія вже має, і рухатися далі лише там, де результат підтвердився.
Що робити далі
- Оберіть один процес, який повторюється щонайменше щотижня, і призначте його власника, який наприкінці ухвалить рішення.
- Складіть картку пілоту з шести пунктів і запишіть поруч правило рішення з трьома варіантами: продовжити, доопрацювати й повторити, зупинити.
- Виміряйте стартовий рівень обраного показника на кількох звичайних циклах роботи, ще до запуску ШІ.
- Перевірте стабільність: дайте ШІ ті самі дані кілька разів і порівняйте відповіді, перш ніж починати паралельний режим.
- Підготуйте журнал пілоту з рядками для часу, правок і їхніх причин, а також окремим рядком для витрат на використання.