Чому штучний інтелект у ролі «пілотів» не може бути широко впроваджений і як компанії можуть це виправити

Вступ

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

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

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

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

Це не завжди означає, що початковий проєкт ШІ був погано розроблений.

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

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

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

1. Успішний пілотний проект не гарантує готовності до впровадження у виробництво

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

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

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

Однак повсякденні бізнес-операції рідко бувають настільки передбачуваними.

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

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

Після впровадження вона отримує рахунки-фактури від сотень постачальників.

Деякі документи скановані неякісно. Інші містять різні валюти, відсутні номери замовлень на закупівлю або мають незвичне оформлення.

Тепер штучний інтелект може потребувати більше ручного виправлення, ніж очікувалося.

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

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

2. Реальні бізнес-дані створюють несподівані проблеми

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

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

Виробничі системи повинні працювати з інформацією, зібраною в ході повсякденної ділової діяльності.

Ці дані можуть містити дублікати записів, застарілі відомості, пропущені поля та несумісні формати.

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

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

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

Товар може здаватися доступним в одній системі, тоді як інша система показує, що його немає в наявності.

Штучний інтелект не може надійно вирішувати кожну суперечність без чітких бізнес-правил.

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

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

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

3. Існуючі бізнес-системи можуть не взаємодіяти між собою безперебійно

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

Розробники можуть завантажувати зразки файлів вручну або підключати ШІ до тимчасової бази даних.

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

Для впровадження у виробництво потрібне щось більш надійне.

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

Такі зв’язки створюють нові виклики.

Штучний інтелект-помічник з продажу може виявити перспективного потенційного клієнта, але зазнати невдачі під час спроби оновити дані в CRM.

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

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

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

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

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

4. Випробування в виробничому середовищі мають охоплювати не лише точність

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

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

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

Припустимо, що під час тестування ШІ-асистент обробляє 20 розмов із клієнтами.

Він може відповідати швидко й точно.

Але що станеться, коли 500 клієнтів спробують скористатися ним у піковий час?

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

План тестування в умовах реального середовища повинен охоплювати кілька аспектів:

• Точність у реальних умовах: чи може система обробляти неповну, нетипову або неправильно відформатовану інформацію?
• Продуктивність: чи надійно вона реагує при збільшенні навантаження?
• Інтеграція: чи може вона коректно обмінюватися інформацією з підключеними бізнес-додатками?
• Безпека: чи захищає вона конфіденційну інформацію та дотримується обмежень доступу?
• Обробка збоїв: що відбувається, коли модель штучного інтелекту або інша служба стає недоступною?
• Людська перевірка: чи можуть співробітники виправляти помилки та брати на себе складні випадки?

Ці тести повинні відображати, як саме бізнес використовуватиме систему.

Компанія також повинна узгодити прийнятні показники продуктивності перед запуском.

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

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

5. Ризики безпеки зростають, коли ШІ використовує більше людей

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

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

Це створює додаткові обов’язки щодо забезпечення безпеки.

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

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

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

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

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

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

6. Нечіткість відповідальності ускладнює вирішення виробничих проблем

Під час пілотного проекту розробники часто ретельно стежать за роботою системи.

Якщо щось йде не так, команда проекту може розслідувати та виправити проблему.

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

Хто реагуватиме, якщо система перестане працювати поза робочим часом?

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

Хто оновлюватиме бізнес-інформацію, коли змінюватимуться політики компанії?

На ці питання потрібно дати відповіді ще до впровадження.

Продуктивна система ШІ повинна мати чітко визначені обов’язки серед технічних та бізнес-команд.

Розробники можуть вирішувати проблеми з програмним забезпеченням, тоді як керівники відділів перевіряють, чи приносить ШІ корисні бізнес-результати.

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

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

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

7. Витрати можуть швидко зрости після впровадження

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

З виробничими системами може бути інакше.

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

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

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

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

Перед розширенням бізнесу слід оцінити повні операційні витрати.

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

Вони також повинні порівняти ці витрати з вигодою, яку приносить система.

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

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

8. Поступове впровадження знижує виробничі ризики

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

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

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

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

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

Наступним кроком може стати впровадження системи в одному відділі або серед невеликої групи користувачів.

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

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

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

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

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

Кожен план впровадження також повинен містити пояснення, як повернутися до попереднього процесу, якщо щось піде не так.

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

Це запобігає повній зупинці важливої бізнес-операції через технічну несправність.

9. Штучний інтелект потребує моніторингу після запуску

Запуск системи штучного інтелекту не означає, що розробка та тестування завершені.

Бізнес-інформація змінюється. Клієнти ставлять нові запитання, співробітники дотримуються оновлених процедур, а пов’язане програмне забезпечення отримує оновлення.

Ці зміни можуть вплинути на ефективність роботи штучного інтелекту.

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

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

Вони також повинні збирати відгуки від користувачів системи.

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

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

Регулярний моніторинг допомагає командам виявляти ці проблеми на ранній стадії.

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

Заключні думки

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

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

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

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

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

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