Джейсон Воян, генеральний директор KMS Technology — серія інтерв’ю

Джейсон Воян — генеральний директор KMS Technology, має близько трьох десятиліть досвіду створення та масштабування компаній у сфері корпоративних технологічних послуг. Він став співзасновником Thirdera і керував компанією до її придбання Cognizant, раніше очолював глобальний напрям ServiceNow в Accenture, а також обіймав керівні посади в Cloud Sherpas та IBM Global Services. Його робота зосереджена на трансформації підприємств, операційних моделях і перетворенні досягнень у сфері ШІ на вимірювані бізнес-результати.

KMS Technology — компанія у сфері цифрової інженерії, даних і ШІ, яка допомагає організаціям створювати програмне забезпечення, модернізувати застосунки, зміцнювати основи для роботи з даними та впроваджувати ШІ в промислову експлуатацію. Її послуги охоплюють технічний консалтинг, розроблення продуктів, інженерію даних та інтелектуальну автоматизацію робочих процесів. У цьому інтерв’ю Воян обговорює «економіку виконання», розрив між пілотними проєктами зі ШІ та його впровадженням у промислову експлуатацію, повноваження агентів ухвалювати рішення, а також те, як компанії можуть оцінювати прогрес за наскрізними результатами.

Ви присвятили три десятиліття створенню та масштабуванню технологічних організацій для корпоративного сектору: від розбудови Navigis і керівництва глобальним напрямом ServiceNow в Accenture до створення Thirdera, а тепер — роботи на посаді генерального директора KMS Technology. Як цей досвід сформував ваш погляд на трансформацію підприємств і що привабило вас у завданні допомогти організаціям перейти до моделі, у якій ШІ є основою їхньої діяльності?

Я почав кар’єру в IBM Global Services, керуючи наданням послуг великим корпоративним клієнтам. Потім були Navigis, Cloud Sherpas, Accenture, Thirdera та Cognizant — майже весь цей час я працював в екосистемі ServiceNow.

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

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

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

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

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

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

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

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

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

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

Кожен робочий процес проходить однаковий ланцюжок етапів: Інформація, Інсайт, Рішення та Виконання.

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

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

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

Тож фінансуйте робочі процеси, а не інструменти, і почніть з іншого запитання. Не «Як підвищити продуктивність цього працівника на 20%?», а «Яка робота більше не має потребувати координації з боку людей?»

Оскільки ШІ переходить від допомоги працівникам у виконанні окремих завдань до автономного виконання цілих робочих процесів, як організаціям слід переосмислити наявні процеси, структури ухвалення рішень і моделі підзвітності?

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

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

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

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

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

Роль керівництва змінюється: замість координації роботи воно проєктує системи, які її виконують.

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

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

Створення. Компанія Evergreen Telehealth хотіла створити платформу телемедицини на основі агентного ШІ та стандарту FHIR для медичних даних, але на ринку не було нічого подібного. Працюючи за підходом, у якому ШІ закладено в основу, і використовуючи Claude на всіх етапах — від визначення вимог і проєктування до розробки й тестування, — наша команда разом з інженерами Evergreen створила основну платформу: від задуму до запуску у виробничому середовищі за 75 робочих днів. До неї увійшли три застосунки (вебверсія, iOS та Android), чотири чинні інтеграції (електронні медичні картки, перевірка особи, платежі та аптека) і два агенти, розгорнуті у виробничому середовищі. Керівну роль у цій моделі відігравали люди, а ШІ прискорював роботу. Агенти створювали чернетки історій користувачів, генерували код і запускали тести. Інженери відповідали за архітектуру, зіставлення клінічних даних і кожне важливе рішення.

Модернізація. Інший приклад: компанії, що розробляє програмне забезпечення для морської галузі, потрібно було замінити платформу, яку вона понад 20 років експлуатувала на власній інфраструктурі. Компанія не могла дозволити собі тривалу традиційну перебудову системи, перш ніж інвестори побачать прогрес, тож ми провели шеститижневу розробку на основі агентного ШІ з чітко обмеженим терміном. Вимоги клієнта завантажили як контекст, завдяки чому агенти створювали рішення відповідно до специфікації, а не просто генерували код. За приблизно 800 командних годин команда виконала від 35 до 45 відсотків обсягу робіт, передбаченого мінімально життєздатним продуктом (MVP), тоді як початкова оцінка становила від 6 000 до 8 000 годин. Агенти написали код і понад 5 000 модульних тестів. Інженери встановлювали обмеження й оцінювали якість.

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

Ми не просто швидше пишемо код. Ми змінюємо обсяг роботи, який може виконати команда.

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

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

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

Це головний виклик. У більшості компаній проблема не в ШІ, а в розрізненості систем, яку ШІ зробив неможливою ігнорувати.

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

Тому основи важливіші за модель. Насамперед потрібні чотири складові:

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

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

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

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

Я б почав зі зміни самого запитання. Не «Чи може ШІ це зробити?». Відповідь дедалі частіше — так. Краще запитати: «Хто надав йому дозвіл діяти?»

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

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

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

Мета — не залучати людину до кожного циклу. Мета — залучати її до потрібних циклів. Дані дають контекст. Моделі міркують. Агенти виконують. Люди визначають повноваження та несуть відповідальність за наслідки.

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

Найбільше мене навчила інтеграція. У Cloud Sherpas, а згодом в Accenture і Cognizant я роками об’єднував організації. Різні культури, моделі надання послуг, системи стимулювання й регіони мали працювати як єдиний бізнес платформ.

Технології рідко ставали обмеженням. Ним була операційна модель.

Три уроки безпосередньо стосуються трансформації за допомогою ШІ.

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

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

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

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

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

Рівень впровадження та заощаджений час — це показники ресурсів. Вони свідчать, що люди користуються інструментом, але не показують, чи працює бізнес швидше.

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

Я б зосередився на трьох типах показників:

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

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

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

Вимірюйте час від потреби до результату. З’ясуйте, де робота затримується. Усуньте причину затримки.

Як, на вашу думку, зміняться взаємини між ШІ, корпоративним програмним забезпеченням і працівниками впродовж наступних трьох-п’яти років? Чи уявляєте ви майбутнє, у якому системи, створені на основі ШІ, докорінно замінять традиційні корпоративні робочі процеси, і що керівникам бізнесу варто робити вже сьогодні, щоб підготуватися до такого переходу?

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

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

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

Компанії, які сприймають ШІ як інструмент, підвищать ефективність. Компанії, які перебудують свою роботу навколо нього, здобудуть стратегічну перевагу. ШІ — це не стратегія. Стратегія — її реалізація.

Дякуємо за чудове інтерв’ю. Читачам, які хочуть дізнатися більше про виконання корпоративних процесів на основі ШІ, інтелектуальні робочі процеси та перехід від пілотних проєктів із ШІ до промислової експлуатації, варто відвідати KMS Technology.