Найшвидший спосіб змарнувати сесію з планування AI-рішення — почати розмову про моделі. Учасники обговорюють можливості, інструменти й те, що технічно можливо, — а за годину всі натхненні, проте ніхто не наблизився до проєкту, який справді варто реалізувати. Сесія здавалася продуктивною, але не дала результату.
Команди, які отримують від такої сесії найбільше, діють навпаки. Вони приходять із описом роботи, а не з переліком технологій. Вони знають, які процеси працюють повільно, де розпорошені дані та які обмеження впливатимуть на рішення, — і спрямовують розмову на ці факти. Така сесія потрібна не для того, щоб вирішити, чи використовувати AI. На ній визначають, що насправді варто автоматизувати, а якість цього рішення залежить від інформації, з якою команда приходить на зустріч.
Починайте з роботи, а не з моделі
Найпоширеніша вступна фраза невдалої сесії — «ми хочемо використати AI». Це звучить як відправна точка, але насправді веде в глухий кут, бо описує засіб, а не проблему. Застосування AI у процесі, який і так працює добре, дає лише дорогу демонстрацію. У процесі, який щотижня забирає в команди години, AI може створити реальну цінність.
Тому найважливіша підготовка відбувається до будь-якого дзвінка: випишіть, де робота справді гальмує. Запитання, які люди ставлять знову й знову. Звіти, на складання яких іде пів дня. Дані, розподілені між надто багатьма системами. Рішення, що щоразу потребують ручного пошуку. Клієнтські чи внутрішні запити, які потрібно передавати між командами, перш ніж їх почнуть опрацьовувати.
Кожен із цих прикладів важливіший за назву будь-якої моделі, бо описує витрати, які бізнес уже несе. Завдання сесії — знайти кілька процесів, де автоматизація найшвидше компенсує ці витрати. Для цього спочатку потрібно чітко назвати самі процеси.
«Ми хочемо використати AI» — не відправна точка. «Цей процес забирає в нас шість годин на тиждень» — відправна точка. Працювати можна з конкретною проблемою, а не з абстрактним бажанням.
Що це означає для вас: перед сесією випишіть п'ять місць, де робота регулярно зупиняється або сповільнюється. Якщо назвати п'ять не вдається, спочатку варто з'ясувати, де саме виникають проблеми, і лише потім проєктувати рішення.
Спочатку визначте системи, а вже потім проєктуйте рішення
Коли ви визначили процеси для розгляду, перелічіть системи, яких стосується кожен із них. Архітектурні деталі поки не потрібні — достатньо загального переліку: CRM, ERP, бази даних, таблиці, пошта, Slack, Drive, Notion, SharePoint та внутрішні інструменти без документації. Що агенту потрібно буде прочитати, записати чи запустити, щоб виконати роботу в кожному процесі?
Це важливо, бо саме системи часто визначають успіх або невдачу AI-проєкту. Модель рідко є найскладнішою частиною. Найскладніше — забезпечити надійний доступ до актуальних даних із належним розмежуванням прав. Простий на схемі процес може виявитися дуже складним, якщо потрібні дані зберігаються у трьох не інтегрованих між собою системах. І навпаки, амбітний процес може бути простим у реалізації, якщо все необхідне міститься в одній добре підтримуваній CRM.
Ідеальна діаграма не потрібна. Достатньо загальної схеми, яка допоможе відрізнити просту інтеграцію двох систем від процесу, що охоплює шість систем, зокрема застарілу базу з обмеженим доступом. Ця відмінність впливає на вартість, терміни й ризики проєкту значно більше, ніж вибір моделі.
Найскладніша частина AI-проєкту — рідко модель. Майже завжди це надійний доступ до актуальних даних із належним розмежуванням прав.
Що це означає для вас: для кожного обраного процесу складіть перелік задіяних систем і позначте ту, доступ до якої буде найскладнішим. Саме вона часто визначає реальний обсяг робіт.
Обговоріть обмеження заздалегідь — вони допоможуть сформувати реалістичне рішення
Є спокуса не згадувати про обмеження на початку, ніби визначення меж зробить проєкт менш амбітним. Насправді обмеження — найцінніші вихідні дані для сесії: вони допомагають відхилити невдалу ідею до початку дорогої реалізації.
Підготуйте все, що визначає межі можливого: правила доступу, вимоги до захисту чутливих даних, нормативні вимоги, етапи погодження, системи зі складним доступом і перелік команд, чия згода обов'язкова. Це не перешкоди, а інформація, що перетворює розмиту ідею на реалістичну архітектуру. Обмеження, визначене під час сесії, стає проєктним рішенням. Те саме обмеження, виявлене посеред розробки, стає дорогою несподіванкою.
Якісна сесія не оминає обмеження, а враховує їх у рішенні. Етап погодження — не перешкода, а точка, де агент передає справу людині. Вимога щодо захисту чутливих даних — не стіна, а умова, яку потрібно врахувати в системі керування доступом. Завчасно названі обмеження роблять підсумкове рішення реалістичним.
Обмеження, назване під час сесії, стає проєктним рішенням. Те саме обмеження, виявлене посеред розробки, стає дорогою несподіванкою.
Що це означає для вас: сприймайте обмеження як корисні вихідні дані, а не як недоліки. Нормативні вимоги й обмеження доступу, про які не хочеться говорити, часто допомагають зберегти проєкт реалістичним.
Визначте, що саме означатиме покращення
Останню частину підготовки пропускають найчастіше: потрібно завчасно визначити, що означатиме успіх. Мета сесії — не «додати AI», а досягти вимірюваного покращення конкретного робочого процесу. Ключове тут — можливість виміряти результат.
Корисні показники успіху конкретні й спостережувані: заощаджений час на тиждень, швидші відповіді, менше ручного передавання завдань, вища якість відповідей, менше звернень до фахівців або прозоріший контроль процесу. Завчасне визначення цих показників дає змогу згодом перевірити результат. Проєкт із чітким «до» і «після» можна оцінити. Проєкт, визначений лише як «використати тут AI», можна хіба що обговорювати.
Якщо ви можете описати поточний і бажаний стани, на сесії буде все потрібне, щоб перетворити розрив між ними на практичний план реалізації. Якщо ви не можете описати, як має покращитися процес, він, імовірно, ще не готовий до автоматизації.
Що це означає для вас: для кожного обраного процесу напишіть одне речення про стан «до» й одне про стан «після». Якщо «після» важко описати конкретно, проблему варто уточнити до початку розробки.
Перші кроки
Результат сесії залежить від підготовки. Щоб отримати практичний план, а не лише заряд ентузіазму, перед дзвінком зробіть три речі:
- Говоріть про проблеми, а не про бажання використати AI. Підготуйте п'ять процесів, які забирають у команди найбільше часу. Конкретну проблему можна розв'язати; абстрактне прагнення — ні.
- Складіть карту систем і позначте найскладнішу. Для кожного процесу перелічіть, що агент має прочитати, записати чи запустити, і позначте систему, інтеграція з якою буде найважчою. Вона часто визначає реальний обсяг робіт.
- Опишіть «до» і «після». Одним реченням визначте поточні витрати й бажаний результат. Якщо результат можна виміряти, його можна перетворити на конкретний план реалізації.
Сесія з планування AI-рішення починається не з моделі. Вона починається з роботи, яку команда повторює щотижня, систем, від яких ця робота залежить, наявних обмежень і чіткого бачення бажаного результату. Підготуйте ці чотири складові — і вибір моделі стане найпростішою частиною розмови, як і має бути.