З чого почати впровадження ШІ в компанії, якщо ви не знаєте, що автоматизувати

Власник ІТ-компанії описав ситуацію з боку підрядника дослівно так:

“Приходять і кажуть, а давайте, короче, типо, там, AI мені зараз, там, я не знаю, на 30-40% зменшить мої розходи, там, умовно кажучи, да, зробіть мені, короче, прикрутіть мені AI.”

А далі, за його словами, починається глухий кут: розробники чекають, що клієнт прийде з бізнес-завданням і скаже, що саме треба робити, а клієнт чекає, що розробники самі скажуть, який бізнес-процес у нього треба оптимізувати.

Так от, обидві сторони мають рацію і обидві стоять. Це найчастіший сценарій, з яким я стикаюсь, і він не про технології взагалі.

Далі розберемо, як за одну зустріч дістати з команди список конкретних задач, і чому починати треба не з процесів, а з людей.

Чому запит формулюється неправильно

Запит “впровадити ШІ” це не задача, а напрямок. Задача звучить інакше: у нас щомісяця приходить стільки-то звернень, кожне забирає стільки-то хвилин, ми хочемо скоротити це вдвічі.

Різниця не в формулюванні, а в тому, що друге можна порахувати, а перше ні. Поки задача не порахована, ви не знаєте ні бюджету, ні окупності, ні того, чи потрібна вам розробка взагалі.

Один із учасників банківського воркшопу поставив питання, яке показує, наскільки далеко можуть заходити роздуми без конкретної задачі: якщо сервіс, який раніше надавала людина, повністю автоматизувати, чи готовий клієнт платити ту саму комісію, розуміючи, що це робить робот. Питання цікаве, але воно з іншого рівня, і відповідати на нього до того, як у вас є перша працююча автоматизація, немає сенсу.

Автоматизація не завжди дешевша

Перед тим як шукати задачі, варто зняти одне припущення, яке ламає розрахунки.

Співвласник агенції з лідогенерації розповів мені свій замір: сорсити дані через сервіси коштує дорожче, ніж людині відбирати вручну. У його сорсерів два неправильні профілі з тисячі відібраних контактів, а по автоматичних сервісах іноді виходить до пʼятдесяти відсотків нерелевантних профілів. Тобто людська праця в його випадку і дешевша, і точніша.

Звідси простий фільтр: автоматизація виграє там, де задача масова, однотипна і терпима до помилки. Там, де важлива точність на кожній одиниці, вона програє.

Як за одну зустріч зібрати список задач

Це вправа, яку я проводжу на перших воркшопах, і вона працює краще за будь-який аудит процесів.

Просите кожного учасника відповісти письмово на три питання. Не в загальному вигляді, а про цей тиждень:

• яку задачу ви робили цього тижня більше одного разу

• скільки приблизно хвилин вона забрала загалом

• що саме в ній найнудніше

Далі збираєте всі відповіді в один список і групуєте. Частина задач обовʼязково повториться в різних людей і різних відділів, і саме вони і є вашим списком на автоматизацію.

Що дає ця вправа, крім списку. Люди самі називають свою рутину, і це знімає частину опору на етапі впровадження. Не весь: людський фактор лишається навіть там, де асистент уже працює і ним користуються тисячі разів. Ну і ви отримуєте цифри в хвилинах одразу, а не після окремого замовленого дослідження.

Що з цим списком робити далі

Список сортується не за бажанням, а за трьома ознаками.

Частота. Задача, яка повторюється щодня, важливіша за ту, що раз на місяць, навіть якщо друга виглядає болючішою.

Обсяг. Скільки сумарно годин на місяць вона з’їдає по всій компанії, а не в однієї людини.

Ціна помилки. Якщо помилка коштує дорого, задача йде не в автоматизацію, а в асистента з обовʼязковою перевіркою людиною.

У фінтех-команді такий перелік дав 21 задачу, і цінність була не в кількості, а в тому, що їх стало видно і можна було розставити за пріоритетом.

Чому починати треба з людей, а не з процесів

Тут варто бути прямим, бо це найдорожча помилка з усіх.

Одна компанія прийшла до мене по агентів. Далі виявилось, що співробітники мають нульове розуміння і бачення, а оцифрованих процесів немає, тобто будувати нема на чому. Керівництво ухвалило рішення спочатку зробити документообіг і оцифрувати дані, і тільки потім повертатись до автоматизації.

Моя методологія через це виглядає так: спочатку навчити співробітників користуватись ШІ, потім асистенти, скіли і кастомні помічники, і тільки коли цього перестає вистачати, агенти й автоматизації.

Причина не в педагогіці. Якщо люди не вміють користуватись інструментом, вони не можуть ні поставити задачу підряднику, ні перевірити результат, ні помітити, що рішення працює неправильно.

Три ознаки, що вам поки не потрібна розробка

Перевірте себе перед тим, як замовляти:

• процес не описаний, і нова людина не повторить його без вашої участі

• задача відбувається рідше, ніж кілька разів на тиждень

• усередині компанії немає людини, яка відповідатиме за рішення після здачі

Якщо хоч один пункт ваш, замовляти розробку рано. Дешевше навчити команду і подивитись, скільки рутини зникне без жодного проєкту.

Яку задачу брати першою

Після того як список зібраний, зʼявляється спокуса взяти найболючіше. Це помилка.

Перша задача вибирається не за болем, а за трьома ознаками: результат видно за тиждень, ціна помилки низька, і про результат можна розповісти всередині компанії без довгих пояснень.

Причина проста. Перший пілот працює не на економію, а на довіру. Якщо він вийшов, наступні задачі люди приносять самі. Якщо перший пілот був складний і провалився, будь-яка наступна ініціатива в компанії отримує вже готовий аргумент проти.

Тому найболючіша задача береться другою або третьою, коли в команди вже є власний приклад того, що це працює. А от відкладати її назовсім не варто: якщо після трьох легких пілотів ви так і не підійшли до головного процесу, ви автоматизували дрібниці і не зрушили нічого.

Кого ставити відповідальним

Питання, яке в більшості компаній вирішується за замовчуванням і неправильно: відповідальним стає той, кому найцікавіше.

Ентузіаст потрібен, але одного його мало. Якщо все тримається на одній людині, рішення живе рівно до її відпустки.

Робоча конфігурація виглядає так: людина з боку бізнесу, яка розуміє процес і може сказати, що результат правильний, плюс людина з боку ІТ або аналітики, яка збирає технічну частину, плюс керівник, який ухвалює рішення про бюджет і пріоритет.

А от чого точно не варто робити, так це віддавати весь напрям в ІТ-відділ. Тоді задачі формулюються технічно, а користуватись мають інші люди, і між цими двома групами зʼявляється рівно той глухий кут, з якого ця стаття починалась.

Чого не варто робити в перші три місяці

Короткий перелік типових витрат, яких можна не робити.

• Не купуйте ліцензії на всю компанію одразу. Спочатку зрозумійте, хто справді користується, і масштабуйте від цього

• Не замовляйте великий аудит процесів. Перелік задач дістається з команди за одну зустріч, а аудит займає місяці і дає той самий результат у гарнішому оформленні

• Не ставте ціль у відсотках економії. Тридцять-сорок відсотків це не задача, а гасло. Задача це конкретний процес і конкретний час на ньому

• Не робіть пілот силами тільки ентузіастів. Вони отримають результат там, де звичайний співробітник його не отримає, і ви ухвалите рішення за неправильними даними

Ну і саме основне: не починайте з розробки, поки не спробували закрити ту саму задачу навченою людиною. І майже завжди виявляється, що частина переліку закривається без жодного проєкту.

Головне про старт впровадження

Запит “прикрутіть нам AI” не має відповіді, бо в ньому немає задачі. Задача дістається з команди за одну зустріч трьома питаннями про цей тиждень. Далі список сортується за частотою, обсягом і ціною помилки. Ну і саме основне: автоматизація не завжди дешевша за людину, і це варто рахувати до того, як платити.

Як виглядає компанія, де почали з людей і команда сама побачила свої задачі, можна подивитись у кейсі виробництва. Приклад пріоритизованого переліку це фінтех, а робота з одним департаментом замість усієї компанії це маркетингова команда METRO.

Моя межа тут стала: ми вчимо, а не розробляємо, тому глибокі автоматизації йдуть до ваших же спеціалістів. Формати і ставки на сторінці послуг.