Вибір між готовим ШІ-продуктом і рішенням під вашу компанію визначають два питання: наскільки процес описаний, повторюваний і має власника, а також де лежать дані, у якому вони стані та чи є до них доступ. Якщо процес типовий, а дані зберігаються в стандартних системах, розумно почати з готового продукту. Якщо процес типовий, але правила у вас свої, підходить налаштування готового рішення. Розробку під себе разом із партнером варто розглядати тоді, коли процес зрілий, приносить відчутні гроші, відрізняє компанію від конкурентів, а дані вже зібрані. У кожному з цих випадків остаточне рішення ухвалюють після перевірки на власних даних, бо демо показує найкращий випадок на чужих.
Коротко
- Гарне демо ШІ-продукту показує, як рішення працює на підготовлених даних постачальника, і мало говорить про те, як воно поведеться у вашій компанії.
- Зрілий процес має описану послідовність кроків, повторюється з однаковими вхідними даними і має власника, який відповідає за результат.
- Перед покупкою треба зʼясувати, де лежать дані, наскільки вони повні й узгоджені та чи може рішення отримати до них доступ без ручного перенесення.
- Готовий продукт підходить для типового процесу на стандартних даних, налаштування потрібне там, де процес типовий, але правила у вашій компанії свої.
- Будь-який вибраний шлях підтверджують пілотом на кілька тижнів із реальними випадками компанії та заздалегідь записаними критеріями успіху.
Чому гарне демо ШІ-продукту погано передбачає результат у вашій компанії?
Демо готують для того, щоб продукт виглядав найкраще, і це нормальна практика продажу. Для показу беруть охайні документи, повні записи, типові запити клієнтів і сценарій, який команда постачальника проганяла десятки разів. У вашій компанії все виглядає інакше: частина рахунків приходить фотографією з телефона, клієнти пишуть упереміш у месенджері та на пошту, а менеджери заповнюють картки в обліковій системі кожен по-своєму. Модель, яка добре впоралася з охайним набором, на такій сировині починає помилятися, і саме тут зʼявляються помилки, яких на показі ніхто не бачив.
Друга причина полягає в тому, що демо показує окрему операцію, а цінність для бізнесу дає весь процес. Розпізнати лист клієнта і запропонувати відповідь вміє багато продуктів. Набагато складніше довести цю відповідь до відправки з правильною ціною, урахувати знижку для постійного клієнта, передати замовлення на склад і не загубити звернення, яке прийшло вночі. Ці стики між кроками і системами на показі зазвичай пропускають, бо вони залежать від того, як влаштована саме ваша компанія.
Тому демо корисне як знайомство з можливостями, а судити за ним про результат не можна. Правильне питання до постачальника звучить так: чи готовий він показати роботу продукту на ваших документах, ваших листах і ваших записах, включно з найгіршими випадками, які трапляються щотижня.
Як оцінити зрілість процесу перед вибором ШІ-рішення?
Зрілість процесу оцінюють за кількома ознаками, і кожну з них можна перевірити без технічних знань. Перша ознака стосується опису: чи можна записати послідовність кроків так, щоб нова людина виконала роботу без постійних уточнень. Якщо кожен співробітник робить ту саму роботу по-своєму, ШІ отримає кілька суперечливих зразків і відтворить цю плутанину швидше та в більшому обсязі.
Друга ознака стосується повторюваності. Процес, який відбувається щодня з однаковими вхідними даними, наприклад обробка заявок або звірка рахунків, добре підходить для автоматизації. Процес, де кожен випадок особливий і вимагає переговорів, краще залишити людині, а ШІ використовувати як помічника для підготовки чернеток і пошуку інформації.
Третя ознака стосується власника. У зрілого процесу є людина, яка відповідає за результат, знає типові помилки і має право змінювати правила. Без такої людини впровадження зависає на першому ж спірному питанні, бо ніхто не може вирішити, як агент має діяти у винятковій ситуації. Четверта ознака стосується вимірювання: ви знаєте, скільки часу займає процес зараз, скільки в ньому помилок і скільки він коштує. Без цих чисел ви не зможете оцінити, чи принесло нове рішення користь.
Якщо процес не проходить хоча б двох перевірок із чотирьох, вибирати продукт ще зарано. Спершу варто описати процес, призначити власника і почати вимірювати, а вже потім шукати рішення.
Які питання про дані треба поставити до того, як щось купувати?
Перше питання стосується місця зберігання. Дані можуть лежати в обліковій системі, у системі роботи з клієнтами, у пошті, у таблицях на особистих ноутбуках, у месенджерах або взагалі на папері. Готові продукти добре працюють зі стандартними системами, до яких вони вже вміють підключатися. Якщо ж важлива частина інформації живе в розрізнених таблицях і чатах, будь-якому рішенню знадобиться попередня робота зі збирання даних в одне місце.
Друге питання стосується стану даних. Подивіться, чи є дублікати клієнтів, чи заповнені обовʼязкові поля, чи збігаються суми в різних системах і скільки існує версій того самого звіту. Модель не виправить погані дані сама, вона зробить на їхній основі впевнений, але хибний висновок.
Третє питання стосується доступу. Зʼясуйте, чи може рішення читати дані автоматично через програмний інтерфейс обміну, тобто через спосіб, яким дві системи передають інформацію без участі людини, чи хтось мусить щодня вивантажувати файли вручну. Ручне перенесення зʼїдає більшу частину вигоди. Окремо уточніть, хто має право бачити які дані, де постачальник їх зберігає, чи використовує для навчання своїх моделей і чи зможете ви забрати свої дані, якщо відмовитеся від продукту. Ця стаття містить загальну навчальну інформацію, тому для свого випадку щодо персональних даних і договору з постачальником зверніться до юриста.
Коли достатньо готового ШІ-продукту, а коли його треба налаштувати під себе?
Готового продукту достатньо, коли процес однаково влаштований у більшості компаній, а дані лежать у поширених системах. Типова ситуація: розшифрування записів зустрічей, сортування вхідної пошти, підготовка чернеток відповідей клієнтам на загальні питання, зведення стандартних звітів. Тут постачальник уже зібрав досвід багатьох клієнтів, і ваша компанія отримує цей досвід одразу, без витрат на розробку. Головна перевага такого шляху полягає у швидкості: перші результати можна побачити за кілька тижнів.
Налаштування потрібне, коли процес загалом типовий, але правила у вас свої. Ваша знижкова політика, ваші умови доставки, ваша градація клієнтів або ваші вимоги до формату документів відрізняють вас від середнього клієнта постачальника. У такому разі ви берете готове рішення і додаєте до нього базу знань із вашими правилами, шаблони документів, ролі доступу і точки, де людина підтверджує дію перед виконанням. Саме тут часто опиняються компанії малого й середнього бізнесу.
Межу між двома шляхами видно на пілоті. Якщо готовий продукт без змін правильно обробляє переважну більшість ваших випадків, налаштування не потрібне. Якщо помилки повторюються і повʼязані з вашими власними правилами, рішення варто залишити і налаштувати під ці правила.
Коли розробка ШІ-рішення під компанію виправдана?
Розробку під себе має сенс розглядати тоді, коли виконуються кілька умов одночасно. Процес зрілий і стабільний, тобто він описаний, має власника і не змінюється щомісяця. Процес приносить відчутні гроші, і помітне покращення в ньому відбивається на виручці або витратах компанії. Процес відрізняє вас від конкурентів, тобто саме в ньому полягає причина, з якої клієнти обирають вашу компанію. Дані для нього вже зібрані, узгоджені і доступні.
Коли всі ці умови виконано, власне рішення дає перевагу, якої немає в конкурентів із готовим продуктом. Воно враховує ваші правила повністю, працює з вашими системами напряму і залишається вашим активом. Разом із цим ви берете на себе відповідальність, якої в готового продукту немає: підтримку, оновлення під нові моделі, виправлення помилок і команду, яка все це знає. Цю роботу треба закладати в бюджет на кілька років уперед, разом з етапом запуску.
Найдорожча помилка на цьому шляху полягає в розробці під незрілий процес. Компанія вкладає гроші в систему, яка точно відтворює сьогоднішній безлад, а за пів року процес змінюється, і рішення доводиться переробляти. Тому розробку зазвичай починають після того, як готовий або налаштований продукт показав межі своїх можливостей саме на цьому процесі.
Як перевірити вибраний шлях на пілоті з власними даними?
Пілот, тобто обмежене випробування рішення в реальній роботі, триває кілька тижнів і охоплює один процес. До початку запишіть, що вважатимете успіхом: скільки часу має займати операція, яку частку помилок ви готові прийняти і скільки рішення може коштувати. Без цих критеріїв наприкінці пілоту залишаться лише враження, а враження в кожного учасника будуть різні.
Для перевірки беріть реальні випадки компанії за останні місяці, включно з найскладнішими: неповні документи, нестандартні запити, суперечливі дані з різних систем. Протягом пілоту людина перевіряє кожен результат рішення і записує, де воно помилилося і чому. Паралельно процес виконується звичним способом, щоб було з чим порівнювати.
Наприкінці пілоту можливі чотири висновки. Готовий продукт впорався, і його можна впроваджувати. Продукт впорався частково, і помилки повʼязані з вашими правилами, тому його треба налаштувати. Продукт не впорався, хоча процес зрілий, а дані зібрані, і тоді варто розглядати розробку під себе. Або пілот показав, що проблема лежить у самому процесі чи даних, і спершу доведеться навести лад там.
Що робити далі
- Виберіть один процес, який повторюється щодня, і запишіть його кроки так, щоб новий співробітник міг виконати роботу без уточнень.
- Призначте власника цього процесу і зафіксуйте, скільки часу він займає зараз, скільки в ньому помилок і скільки він коштує.
- Складіть перелік джерел даних для процесу, перевірте їхній стан і зʼясуйте, чи можна отримати до них автоматичний доступ.
- Попросіть постачальника показати продукт на ваших реальних документах і записах, включно з найскладнішими випадками.
- Проведіть пілот на кілька тижнів із заздалегідь записаними критеріями успіху і за його підсумком вирішіть, чи купувати, налаштовувати або розробляти рішення.