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