CIO потребують кращого способу обліку роботи ШІ в ІТ

Протягом останніх двох років CIO мають просту мету щодо ШІ в ІТ: впровадити його в організацію, дозволити командам експериментувати і подивитися, де він може покращити надання послуг.

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

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

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

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

Зекономлений час не обов’язково означає заощаджені гроші

Багато розрахунків ROI ШІ починаються з часу як критерію — наприклад, якщо ШІ економить працівнику 30 хвилин на день, компанія може помножити ці хвилини на тисячі працівників і отримати дуже велике число.

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

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

Aviva — хороший приклад. Страхова компанія використала понад 80 моделей ШІ в рамках змін у своїй роботі з позовами і повідомила про скорочення часу оцінки відповідальності на 23 дні та скарг на 65 відсотків. Ці цифри показують керівництву, що змінилося в операції, і дають фінансам те, що можна виміряти.

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

Робота, яку виконує ШІ, — краща відправна точка

Розгляньмо типовий запит на доступ в ІТ. Помічник може підсумувати заявку та підготувати відповідь, тоді як ІТ‑агент перевіряє політику компанії, підтверджує запитувача, отримує схвалення, змінює дозвіл і закриває запит.

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

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

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

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

Але вам також потрібно враховувати людську працю

Система ШІ може розпочати 1 000 запитів на адаптацію та потребувати втручання працівника у 600 з них. Позначення всіх 1 000 як автоматизованих дало б керівництву неправильне уявлення про те, скільки роботи ШІ фактично виконав.

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

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

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

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

Той рівень відповідальності, який отримує ШІ, впливає на економіку

CIO також мають вирішувати, скільки повноважень вони готові надати ШІ.

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

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

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

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

Почніть з роботи, яка вже коштує грошей

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

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

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

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

Коли ШІ починає виконувати роботу, CIO можуть порівняти очікування з реальними результатами. Вони бачать, яку частину роботи виконало ШІ, як часто доводилося втручатися людям і яку вартість мав весь процес.

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