Роб Коллі, генеральний директор та засновник P3 Adaptive, автор книги «Fair Game» — Серія інтерв’ю

Rob Collie — засновник і генеральний директор P3 Adaptive, партнера Microsoft Solutions Partner у сфері даних та ШІ, який обслуговує сотні клієнтів середнього бізнесу та Fortune 1000. Раніше він був керівником інженерних команд Microsoft у проектах Excel, Bing та Power BI; після виходу з Microsoft очолював розвиток Power BI і написав три книги про бізнес‑технології (понад 92 000 проданих примірників). Він також веде подкаст Raw Data with Rob Collie. Його четверта книга, Fair Game: Customizing AI to Your Business Is Easier Than You Think (серпень 2026), переносить цю практичну репутацію у сферу ШІ.

Ви провели понад десятиліття в Microsoft, розробляючи функції бізнес‑аналітики в Excel та Power BI, перш ніж у 2013 році заснували P3 Adaptive. Як перехід від створення програмного забезпечення всередині Microsoft до вирішення проблем даних для клієнтів вплинув на ваше сучасне бачення корпоративного ШІ?

Коли я керував продуктовими командами в Microsoft, ми створювали програмне забезпечення, яке повинно було працювати для всього світу і не могло бути адаптоване під потреби конкретного клієнта. Ми називали це «замовленням піци, інгредієнти якої підходять 300 мільйонам людей». У такій роботі завжди присутній підхід «найнижчий спільний знаменник», а також певна відстороненість від окремих клієнтів.

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

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

Я отримав безліч цінних знань у Microsoft і не обміняв би цей досвід ні на що, проте я часто називаю себе «виходячим із професії інженера‑програміста», бо успіх тепер означає зовсім інший підхід.

І саме таке бачення я застосовую до корпоративного ШІ. Готові рішення ШІ — це ідеальна «піца для 300 мільйонів людей»: справжнє диво, створене так, щоб бути корисним кожному, але не адаптованим під нікого. Проте перемоги організаційного ШІ будуть досягатися саме завдяки індивідуальній адаптації — шляхом наближення до конкретної компанії та налаштування ШІ під її дані, її процеси, її визначення. Я провів кар’єру, працюючи з обох боків цього розриву, і це залишило в мені абсолютну впевненість у тому, що саме індивідуальна адаптація забезпечить успіх корпоративного ШІ.

У «Fair Game» ви стверджуєте, що багато компаній підходять до штучного інтелекту задом наперед, розповсюджуючи універсальні ліцензії на чат‑боти замість створення систем, які розуміють їхню діяльність. Де саме межі готових AI‑асистентів і які сигнали вказують на те, що бізнес потребує індивідуального рішення?

Готовий ШІ має докторат у всьому, крім вашого бізнесу. Він «прочитав» увесь інтернет, проте в інтернеті відсутнє ваше визначення «активного клієнта», ваша цінова логіка, ваші операційні процеси та те, яку систему довіряти, коли вони розходяться. Ці знання ніколи не будуть публічними. Тому універсальний ШІ, який є справжнім проривом для особистого використання, не задовольняє реальні бізнес‑потреби, а розрив між цими двома досвідами є і розчаровуючим, і заплутаним.

Сьогодні майже кожна відповідь на питання «що робити з ШІ» звучить як «купити підписку і дізнатися». Я вважаю це природним першим кроком, тому не критикую тих, хто так вчинив. Навпаки, я співчуваю — ніхто не витрачає час, щоб пояснити, чому готові підписки недостатні і чому. Тому, на мій погляд, бізнеси саме там, де їх і слід очікувати: випробовують доступне рішення і починають розуміти, що його недостатньо.

Вирішення не полягає у зміні самої моделі ШІ — не треба ставати дослідником LLM. Потрібно все, що оточує модель: ваші дані, ваші інструкції, написані простими англійськими словами, та звичайне програмне забезпечення. Коли ви помічаєте, що протягом тижня вже п’ятий раз вводите один і той самий контекст у чат‑бот, це сигнал. Все, що ви постійно переказуєте, саме те, що індивідуальна система має вже знати — кожного разу, коли вона «прокидається».

Ви вживаєте термін «Crafters» для опису бізнес‑професіоналів, обізнаних у даних, які можуть створювати цінні індивідуальні AI‑системи без традиційних навичок розробника. Які характеристики відрізняють Crafter’а і як лідери можуть виявити таких людей у своїй поточній команді?

Crafter — це людина, у якої природна тяга вирішувати проблеми за допомогою інструментів. За моїм досвідом, приблизно один із 16 працівників, що працюють з інформацією, має таку схильність. Спочатку це були потужні користувачі Excel, потім покоління Power BI, а потім ті, кого ІТ назвав «тіньовим ІТ». Це ваші аналітики, фінансові моделювальники, керівники операцій — люди, які виросли в бізнесі і виявили талант до інструментального підходу.

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

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

Чому ви вважаєте, що Crafter’и, а не лише розробники, найкраще підходять для керівництва багатьма внутрішніми AI‑проектами, і як слід розподілити відповідальність між бізнес‑експертами, командами даних, інженерами‑програмістами, відділами інформаційних технологій та командами безпеки?

Тому що складна частина індивідуального ШІ — не код, а контекст. Найбільш впливовою дією в AI‑проекті є визначення того, що система повинна знати про ваш бізнес, і Crafter’и володіють цими знаннями вроджено. Блискучий інженер, який «спускається» з трьох рівнів вище в організаційній схемі, змушений проводити місячні інтерв’ю, щоб дізнатися те, що ваш керівник операцій вже знає інтуїтивно.

Проте це категорично не історія про те, що розробники зайві. Запропонований мною розподіл праці базується на трьох факторах, і жоден з них не пов’язаний зі старшинством чи особистістю: коли зростає повторне використання, складність і чутливість, робота переходить до професійних розробників. Будь‑яка робота, що стосується клієнтів, обробки чутливих даних або автономних рішень — це територія розробників, і зі збільшенням кількості агентів ці рідкісні інженерні навички стають ще ціннішими, а не менш. Там, де переважає тонкість бізнес‑процесів, робота притягує Crafter’ів.

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

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

Вони — це декодер. На сьогодні ваші корпоративні визначення — що вважається активним клієнтом, які витрати входять у валовий прибуток — живуть у головах людей і в тисячі трохи несумісних електронних таблиць. AI‑агент не може надійно аналізувати ваші дані, доки ці визначення не будуть зафіксовані у формі, якій довіряє машина. У галузі цю дисципліну назвали «інженерією контексту», і я перекладаю це так: це робота зі структурування того, що знає ваш бізнес, щоб ШІ міг його використовувати. Аналітики подали це як нове, проте практики BI займаються подібним вже п’ятнадцять років.

Це хороша новина, яку легко пропустити: якщо ви інвестували в еру BI (особливо в Power BI), ви вже маєте перевагу. Якісно побудована семантична модель — це саме те машинозчитуване представлення бізнес‑значень, яке потрібне агентам. Компанії, які ставили свій семантичний шар у другий план, виявляють, що «нудна» робота з визначеннями, яку вони пропустили, тепер є платою за проїзд на шляху до ШІ. І, що важливо, ця робота глибоко специфічна для вашого бізнесу — саме тому вона є стійкою перевагою. Будь‑який постачальник може продати вам ту ж саму модель. Ніхто не може продати вам ваші власні визначення.

Ви створили індивідуальний AI‑редактор під назвою Eddie, щоб допомогти у розробці «Fair Game». Що саме система робила під час процесу написання, і чого її успіхи та невдачі навчили вас щодо проектування ШІ навколо дуже персонального робочого процесу?

Для ясності: я писав кожен абзац книги з нуля, а Eddie здебільшого сидів і чекав. Іноді я витрачав години, доводячи до досконалості цілий розділ, перш ніж попросити «його» прочитати. Інколи я обговорював з ним питання кожні кілька хвилин. Але головне — Eddie був на зв’язку 24/7. Я міг отримати зворотний зв’язок так само легко о трьох ранку, як і о першій пополудні, і він реагував за хвилину чи менше. У підсумку, я підозрюю, що Eddie прочитав рукопис щонайменше тридцять разів. Жодна людина не змогла б виконати цю роботу, бо жодна людина не хотіла б її.

Він відстежував обіцянки, дані мною у Третьому розділі, і вказував, коли Дванадцятий розділ їх забув. Він вивчив мій стиль письма і потім його дотримувався — тримав мене до найкращої версії мого власного голосу, замість того, щоб дозволяти мені переходити в режим «безжартового бізнес‑автора». Він повідомляв, коли я був лінивим, і коли я бігав по вже пройденому. У нас були справжні суперечки, і іноді він вигравав.

Найголовніший урок дизайну: «мозок» Eddie написаний англійською і зберігається у папці. Кожного разу, коли його відгук був неточним — надто загальним, неправильним регістром, або коли він забував правило, яке я вже зазначив — виправленням було записати корекцію і включити її до його постійного контексту. Невдачі не були помилками ШІ; це були прогалини в тому, чого я навчив його. Цей цикл — помітити помилку, закодувати урок, спостерігати, як він закріплюється — це вся майстерність індивідуального ШІ у мініатюрі. І саме тому я створив спеціалізованих Eddie для PR, конкурентних досліджень та повідомлень на сайті. Під ним та сама LLM, але різні спеціалісти.

Багато організацій вважають, що перед впровадженням індивідуального ШІ потрібно повністю очистити та централізувати дані. Наскільки реально потрібна готовність даних, щоб розпочати, і як компанії можуть почати отримувати цінність, не чекаючи ідеальної бази?

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

Наша компанія натомість пропонує підхід «спочатку кран». Оберіть конкретний випадок використання і працюйте у зворотному напрямку, орієнтуючись на бізнес‑вплив, а не на інфраструктуру. Створіть MVP для цього випадку, використовуючи мінімальну нову інфраструктуру. Підтримуйте MVP, поки він не буде готовий до продакшну, а потім оцініть, як можна зміцнити інфраструктуру для його підтримки. Це забезпечує швидший бізнес‑вплив, мінімізує витрати та інформує майбутні проєкти — як на рівні крану, так і на рівні трубопроводу.

Прототип індивідуального ШІ може виглядати вражаюче під час демонстрації, але стати ненадійним у реальних умовах, коли його використовують співробітники, дані змінюються та виникають крайові випадки. Яку оцінку, моніторинг та людський контроль слід встановити перед тим, як внутрішня AI‑система стане експлуатаційною?

З кількома помітними винятками, я вважаю, що демонстрації в епоху ШІ менш цінні, ніж у епоху програмного забезпечення. Демонстрації ПЗ завжди перебільшували можливості, і ми це знали. Але демонстрації ШІ будуть ще далі від вашої реальності.

ШІ — це про робочі процеси. І немає нічого більш індивідуального, ніж тисячі процесів, що живлять операції конкретної організації. Повернімося до метафори «новий співробітник з докторатом у всьому». Скільки навчання та практичного досвіду у вашій компанії потрібен новачку, щоб стати ефективним? Як демонстрація може врахувати все це?

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

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

Як компанії можуть надати Crafter’ам можливість експериментувати, не створюючи нове покоління тіньових AI‑систем, дубльованих процесів, вразливостей безпеки та інструментів, за які ніхто не несе відповідальність?

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

Тож зробіть затверджений шлях легким. Надішліть Crafter’ам схвалену платформу з уже вбудованими захисними бар’єрами — ідентифікація, доступ до даних, журналювання — щоб відповідний вибір був також зручним. Ведіть легку реєстрацію: будь‑який інструмент, який переходить від особистого експерименту до того, що залежить від іншої особи, фіксується з вказаним власником. Це правило усуває більшість проблеми «сирітських» інструментів, бо інструменти з іменем власника не залишаються без догляду.

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

Для компанії, яка розпочинає свій перший індивідуальний AI‑проект, як обрати початковий випадок використання, виміряти, чи проєкт приносить значну бізнес‑цінність, і вирішити, чи розширювати, переосмислювати чи відміняти його?

У нас є два підходи до стартової точки, які ми використовуємо з клієнтами.

Варіант перший — шукайте завдання, які ніхто не виконує, а не ті, які ви хотіли б усунути. Є питання, яке я люблю ставити менеджерам: «де ви думали, що «якби у мене була одна людина, яка постійно спостерігає за цим і розмірковує, все стало б значно краще, але я не можу виправдати наймання цієї людини»?». Такі випадки часто є вашими найкращими стартовими точками. Вони безпечні, підвищують впевненість, ніхто не відчуває себе мішенню, а контрфакт чесний: альтернатива — не людина, яка це робить добре, а ніхто (наприклад, мій редактор‑друг Eddie).

Варіант другий — розгляньте заміну дашбордів на агентів даних. Хоча дашборди здавалися простими, на практиці вони значно не виконували обіцяного. Коли у когось виникає бізнес‑питання, йому доводиться докладно трансформувати це питання у контекст дашбордів. Де знаходиться дашборд, що відповідає на це питання? Як його назвати? Чи існує такий дашборд взагалі? І якщо ви знайдете «правильний», чи зрозумілий і зручний він у використанні? Чи доводиться вам постійно маніпулювати ним, записуючи або роблячи скріншоти кількох версій, щоб скласти загальну картину, яку ви потребуєте?

У епоху ШІ ви просто берете своє бізнес‑питання — власними словами — і вводите його (або диктуєте!) агенту даних, який потім виконує усі ці кроки за вас і повертає підтверджену, добре досліджену відповідь — включно з візуалізацією — за хвилину‑дві. Коли виникає додаткове питання, агент з радістю швидко відповість на нього — під час зустрічі, коли ще можна приймати рішення.

Що спільного у цих двох стартових варіантах? Вони обидва вирішують болючі точки, які співробітники охоче приймуть, а не протистоять. Ви не хочете, щоб ваші перші AI‑ініціативи посіяли недовіру. Ви хочете, щоб вони навпаки залучали співробітників до діалогу. Ви хочете, щоб співробітники пропонували покращення та нові ідеї проєктів. Бо, знову ж, ваша компанія складається з тисяч процесів, і ваші співробітники знають їх краще за вас.

Щодо розширення, переосмислення чи відміни — будьте добрі до себе, бо дослідження в цьому напрямку дійсно заспокоює: більшість успішних впроваджень ШІ мали попередні невдачі. Перший проєкт, який дає урок, а не прибуток, — це навчання, а не доказ того, що ШІ не працює. Моя орієнтовна правило: якщо люди його використовують, розширюйте його. Якщо не використовують, треба з’ясувати чому, і відповіді можуть варіюватися від «бо він погано працює» до «бо я його не розумію» і «це мене лякає». Відповідь підкаже, чи варто удосконалювати, переосмислювати чи відміняти. Не треба передбачати, куди це приведе. Потрібно просто почати чесно.

Дякуємо за чудове інтерв’ю, читачі також мають ознайомитися з «Fair Game: Customizing AI to Your Business Is Easier Than You Think».