Покупайте ИИ-инструменты позже: сначала проверьте процессы, данные и время

Почему ИИ-лицензии остаются без использования

Средние компании часто покупают ИИ-инструменты под давлением: надо быстрее двигаться, надо не отставать. Проблема начинается тогда, когда от программы ждут, что она исправит процесс, который никто толком не описал. Если команда не может объяснить, как работа сегодня идёт от запроса до результата, новая лицензия часто становится ещё одной вкладкой, которую люди перестают открывать.

Чаще всего сбой происходит ещё до покупки. Руководитель смотрит на красивое демо и предполагает, что инструмент уберёт задержки. Но в реальной работе процесс по-прежнему проходит через письма, общие таблицы и чаты. Сотрудники продолжают идти старым путём, потому что так быстрее, даже если всё устроено неаккуратно. Они знают обходные способы. Они знают, кому написать, если что-то сломалось.

Эту привычку сложно сломать. Новый инструмент требует, чтобы люди по-другому писали, по-другому сохраняли файлы и по-новому запрашивали согласование. Если новый путь добавляет даже два лишних клика в загруженный день, многие команды тихо возвращаются к старому варианту.

Очень быстро исчезает и ответственность. Один человек подписывает договор, другой приходит на стартовую встречу, а потом после оплаты счета за запуск уже никто не отвечает. Вопросы копятся. Настройки остаются недоделанными. Шаблоны никто не приводит в порядок. Инструмент без владельца очень быстро превращается в софт, который просто лежит без дела.

Годовые планы только усиливают проблему. Скидка выглядит разумно, поэтому команды соглашаются ещё до того, как докажут ежедневное использование. Через три месяца компания уже заплатила за год мест, которые так и не стали частью реальной работы. Дешёвый неиспользуемый софт всё равно остаётся неиспользуемым.

Чаще всего покупатели забывают о времени. Кому-то нужно тестировать подсказки, проверять результаты, исправлять плохие входные данные, отвечать на вопросы команды и каждый день подталкивать людей пользоваться инструментом. Если у никого нет хотя бы нескольких часов в неделю на такую работу, внедрение быстро буксует.

Вот простой пример. Компания на 70 человек покупает ИИ-помощника для написания коммерческих предложений, потому что хочет отвечать быстрее. Но заметки продаж всё ещё приходят в чат, цены всё ещё живут в таблицах, а менеджеры по-прежнему просят правки по почте. Проблема не в инструменте. Компания просто не изменила сам распорядок работы вокруг него.

Когда компании покупают ИИ-инструменты слишком рано, они часто покупают надежду. Гораздо важнее чёткий процесс, один ответственный и подтверждение того, что инструмент используется каждую неделю.

Проверьте процесс до демо

Большинство команд сначала смотрят на инструмент, а потом на работу. Это наоборот. Если хотите, чтобы люди продолжали пользоваться ИИ-инструментом, сначала опишите саму задачу так, как она существует сегодня, ещё до того, как поставщик покажет красивый рабочий сценарий.

Начните с одной реальной задачи и распишите каждый шаг простыми словами. Укажите, кто получает запрос, откуда берётся информация, что копируется в другую систему, кто это проверяет и кто даёт финальное согласование. Пишите скучно и буквально. «Менеджер по продажам отправляет запрос на расчёт, операционный отдел копирует данные в ERP, руководитель утверждает цену, финансы отправляют PDF» — это намного лучше, чем туманный блок-схемный рисунок.

Потом отметьте точки, где теряется время. В средних компаниях задержки чаще всего возникают из-за того, что одни и те же данные перепечатывают, ждут одного менеджера или ищут недостающую информацию в почте, чате и общих папках. Вот это и есть места, которые стоит чинить. Чистые и быстрые шаги обычно не требуют новой лицензии.

Полезно разделить всё на два типа: решение и повторение. Если человек решает, рискован ли пункт договора, здесь нужен контроль человека. Если человек переносит имена, даты, суммы и коды товаров из одной системы в другую, это повторяющийся шаг, и его значительно проще улучшить. Многие команды ждут, что ИИ заменит решение, хотя настоящая потеря времени сидит в обычной передаче данных.

Не полагайтесь на память. Сохраните пять–десять реальных примеров самой работы: формы, письма клиентов, таблицы, сообщения о согласовании, PDF и заметки. Эти примеры покажут, чистые ли входные данные, грязные ли они, не хватает ли полей и много ли там исключений. На демо этого почти никогда не видно.

Сделайте аудит простым. Выпишите каждый шаг от первого входа до финального согласования, укажите, кто его делает и как долго обычно приходится ждать, отметьте, где люди перепечатывают данные, переключаются между инструментами или ищут недостающую информацию, и пометьте каждый шаг как «решение» или «повтор». Потом соберите небольшой набор реальных документов и сообщений.

Сделать это можно за час. Слабые места обычно становятся заметны очень быстро. Иногда проблема вообще не в отсутствии ИИ. Иногда это всего один узкий участок согласования, три версии одной и той же формы или исходные документы, которые приходят в пяти разных форматах. Исправьте это первым делом, и у будущего запуска будет гораздо больше шансов прижиться.

Проверьте исходные данные

Большинство ИИ-проектов ломаются не из-за качества модели, а из-за обычного беспорядка в данных. Если инструмент берёт информацию из плохих записей, он может ответить уверенно и всё равно ошибиться.

Сначала перечислите все места, откуда инструмент будет читать данные. Обычно это CRM, служба поддержки, ERP, таблицы, общие папки и старые выгрузки, которым никто полностью не доверяет, но которыми все до сих пор пользуются.

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

Что обычно ломается

Имена, даты и статусы часто перестают совпадать задолго до того, как это замечают. В одной системе написано «Активен», в другой — «Текущий», а в третьей поле вообще пустое. В одной карточке клиент может быть указан по юридическому названию, а в поддержке — по сокращённому. Тогда ИИ воспринимает это как разных клиентов.

Обычно проблемы такие: пропущенные поля, которые люди оставляют пустыми в спешке, дубли записей с небольшими различиями в написании, устаревшие файлы, которые когда-то скопировали в папку, и разные значения статусов в разных системах.

Именно здесь качество данных для ИИ становится очень практичным вопросом. Если команда не может договориться, что значит «закрыто», «отгружено» или «одобрено», инструмент не сможет угадать правильно.

Проверяйте реальные записи, а не демо-данные

Не полагайтесь на чистую таблицу, подготовленную для продажи. Возьмите десять реальных записей из ежедневной работы. Специально выберите самые неаккуратные: старую карточку, дубль клиента, недозаполненный заказ, тикет без заметок.

Потом проверьте каждую запись в разных системах. Совпадают ли даты? Один и тот же человек везде ли записан одинаково? Рассказывает ли статус одну и ту же историю в продажах, финансах и поддержке?

Такой небольшой тест быстро показывает проблемы. За час команда может узнать о своих данных больше, чем за две недели красивых демо. Если записи не совпадают, сначала исправьте это. Иначе, когда вы покупаете ИИ-инструменты, вы часто просто покупаете более быструю путаницу.

Посчитайте время владельца

Перед покупкой ИИ-инструментов считайте не только счёт за подписку, но и еженедельные часы владельца. Подписка видна сразу. А время, которое нужно, чтобы инструмент действительно приносил пользу, обычно нет.

Кто-то всё равно должен проверять результаты, исправлять ошибки и отвечать на дополнительные вопросы, которые создаёт инструмент. Если менеджер тратит 6 часов в неделю на проверку черновиков и ещё 3 часа на исправление недочётов, это часть реальной стоимости. Если эти часы не учитывать, неиспользуемый софт появляется очень быстро.

Считайте по текущему календарному времени, а не на глаз. Спросите менеджеров и руководителей команд, сколько времени у них уже сейчас уходит на этот процесс каждую неделю. Включите согласования, переделки, переписку и обработку исключений. Задача, которая звучит как «час в день», часто превращается в 8–10 часов в неделю, если учесть всю грязную работу.

Потом назначьте одного человека, который будет владеть инструментом после запуска. ИИ нужен не только логин и короткая демонстрация. Кто-то должен писать подсказки, задавать простые правила, собирать хорошие примеры и обновлять их, когда бизнес меняется. Если этим никто не занимается, инструмент начинает дрейфовать, а качество ответов падает.

Первый месяц требует больше всего внимания. Новые пользователи задают базовые вопросы, пробуют инструмент не там, где надо, и им нужен фидбек о том, как выглядит хороший результат. Заранее заложите время на короткое обучение, быстрые исправления и еженедельный разбор ошибок. День запуска — самая лёгкая часть.

Несколько вопросов быстро показывают скрытую нагрузку. Кто проверяет результат до того, как он попадёт к клиентам, поставщикам или в финансы? Кто исправляет плохие ответы и сколько часов занимает такая доработка? Кто обновляет подсказки, правила и примеры входных данных? Кто обучает команду в первый месяц?

Если у владельца нет этих часов, софт, скорее всего, так и останется без дела. Во многих запусках в среднем бизнесе именно в этом и заключается реальная проблема. С самим инструментом всё было нормально. Компания просто не заложила человеческое время на его нормальную работу.

Сначала выберите одну задачу

Выберите одну задачу с понятным объёмом и понятным финалом. Если она повторяется 20 или 200 раз в неделю, вы быстро увидите изменения. Если никто не может сказать, как выглядит хороший результат, тест начнёт расползаться, а виноватым сделают сам инструмент.

Лучший первый вариант обычно скучный. И это хороший знак. Повторяющаяся работа даёт стабильную базу, а стабильную работу легче улучшать.

Хороший пример — входящие обращения в поддержку. Если команда уже сортирует письма, пишет черновики ответов и прогоняет их через один и тот же этап проверки, ИИ может помочь именно с этой рутиной. Тогда можно измерять простые вещи: скорость ответа, количество ручных правок и число сообщений, которым нужен второй проход.

Не стоит начинать с широких целей вроде «использовать ИИ во всей клиентской поддержке» или «ускорить маркетинг». Такие цели звучат амбициозно, но в них слишком много движущихся частей. Один человек использует инструмент по-своему, другой его игнорирует, и через месяц никто уже не знает, помогли ли расходы.

Хорошая первая задача обычно проходит четыре проверки. Команда делает её одинаково большую часть времени. Входные данные легко найти, а результат — легко оценить. Работа повторяется достаточно часто, чтобы сравнить «до» и «после». И один человек отвечает за итог и может быстро вносить небольшие изменения.

Формулируйте результат простыми словами. «Сократить время на первый черновик с 25 минут до 10» — подходит. «Уменьшить количество ручных ответов на 30 в неделю» — тоже подходит. Общие цели вроде «повысить продуктивность» не помогают, потому что каждый понимает их по-своему.

Если вы сомневаетесь между двумя задачами, выберите ту, где меньше споров. Вам нужен тест, который начинается на этой неделе, а не ещё один проект, который застрянет в планировании. Небольшая победа для среднего бизнеса даст больше, чем большое обещание, которое так и не выйдет за пределы слайдов.

Проведите недельный аудит

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

Пять рабочих дней

В первый день нарисуйте рабочий процесс на одной странице. Начните с триггера, закончите финальным согласованием и отметьте каждую передачу между участниками. Рядом поставьте имя владельца процесса. Если никто не владеет работой, новый инструмент только быстрее разнесёт путаницу.

Во второй день возьмите небольшой набор реальных данных. Обычно достаточно 10–20 записей. Проверьте, есть ли пропущенные поля, дубли, странные имена файлов, старые шаблоны и комментарии, которые понимает только один человек. Красивые демо скрывают грязные входные данные. Повседневная работа — нет.

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

В четвёртый день измерьте человеческую нагрузку. Посчитайте, сколько результатов пришлось править, сколько времени заняла проверка и где инструмент дал сбой. Смотрите и на тихие проблемы: сотрудники копируют данные между системами, исправляют тон, вручную проверяют факты или спрашивают владельца о недостающем контексте. Задача, которая сначала выглядит быстрее, всё равно может съедать 20 минут на проверке.

В пятый день примите простое решение. Покупайте только если тест экономит время, держит качество на стабильном уровне и вписывается в текущий процесс. Отложите покупку, если данные слабые или владельцу всё ещё приходится спасать каждый результат. Измените объём, если инструмент помогает с одной узкой задачей, но не с полным процессом.

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

Ошибки, которые команды совершают до подписания договора

Самая частая ошибка — сначала масштаб, потом проверка. Команда видит красивое демо, увлекается и сразу покупает места для продаж, поддержки, операционного отдела и финансов. Через две недели инструмент использует одна маленькая группа, остальные о нём забывают, а компания платит за софт, который лежит без дела.

Демо от поставщика только усиливает проблему. Обычно там используют чистые данные, короткие задачи и идеальный сценарий. Реальная работа куда сложнее. Имена файлов бывают непоследовательными, согласования занимают время, в карточках клиентов есть пробелы, а люди переключаются между пятью системами, чтобы закрыть одну задачу. Если демо не показывает ваш реальный процесс и ваши реальные данные, оно мало что говорит.

Ещё одна частая ошибка — когда спонсор подписывает договор и потом исчезает из проекта. Одобрение бюджета — это не владение. Кто-то всё равно должен выбрать первый кейс, задать правила, отвечать на вопросы команды, проверять результаты и убирать препятствия. Если никто этим не занимается, использование быстро падает.

Безопасность и соответствие требованиям часто откладывают на конец, потому что это кажется просто бумажной работой. А потом юристы спрашивают, куда уходит информация, кто видит подсказки, как долго хранятся журналы и можно ли сотрудникам использовать данные клиентов в инструменте. В итоге запуск стопорится уже после подписания договора, и это худший момент, чтобы понять, что инструмент не подходит под ваши правила.

Простая дисциплина позволяет избежать многих проблем. Начните с одной команды и одной повторяющейся задачи. Запускайте инструмент на реальных данных, а не на учебных примерах. Назначьте одного человека, который будет вести запуск в течение 30 дней. И заранее пропишите правило остановки ещё до подписи.

Последний пункт важнее, чем думает большинство команд. Если инструмент не экономит заданное количество времени, не снижает число ошибок или не уменьшает очередь за фиксированный тестовый период, его нужно отключить. Среднему бизнесу не нужна ещё одна подписка, которая хорошо звучит на встречах, но в жизни только добавляет работы.

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

Простой пример из среднего бизнеса

Дистрибьютор на 120 человек захотел, чтобы ИИ обрабатывал обычные письма клиентов. На бумаге идея выглядела просто. Каждый день команда получала одни и те же вопросы про заказы, наличие товара, счета и сроки доставки.

Проблема была не в ответах. Проблема была в беспорядке за ними.

Когда команда посмотрела, как письма реально идут через компанию, выяснилось, что есть три отдельные входящие почты. У каждой группы были свои шаблоны. Статусы тоже никто не называл одинаково, поэтому один человек помечал сообщение как «ожидание», другой писал «в процессе», а третий вообще ничего не ставил. Менеджеры тратили больше времени на сортировку и пересылку сообщений, чем на написание ответов.

Это полностью изменило план. Если бы они поспешили купить ИИ-инструменты, система училась бы на смешанных шаблонах, неполных историях переписки и непоследовательных метках. Она, возможно, всё равно писала бы черновики, но сотрудникам пришлось бы перепроверять каждый ответ. Вот так красивое демо превращается в неиспользуемый софт.

Они приостановили покупку и сначала исправили базу. Сложили обычные письма клиентов в одну очередь, привели статусы к единым терминам, назначили одного владельца процесса и убрали дубли шаблонов, оставив только одобренные.

Ничего из этого не выглядело захватывающе, но это убрало настоящий мусор. Когда сообщения стали попадать в одно место и получили понятную систему статусов, команда начала видеть, что приходит, кто за это отвечает и как выглядит хороший ответ.

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

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

Быстрые проверки перед тем, как утвердить расходы

Большая часть бессмысленных расходов на ИИ начинается с расплывчатой задачи. Если никто не может описать её в одном предложении, плюс входные данные и ожидаемый результат, команда ещё слишком рано делает покупку. Загоните работу в простой формат: «взять X, сделать Y, получить Z».

Если и эта формулировка звучит размыто, использование тоже останется размытым. Это самый быстрый аудит процесса для ИИ, который только можно сделать, и обычно за десять минут он показывает настоящую проблему.

Следующий фильтр — данные. Команды часто говорят, что их у них много, а потом выясняется, что каждый отчёт лежит в своей таблице, в своей папке или в своём поле CRM. Если кто-то до сих пор каждое утро вручную чистит одну и ту же выгрузку, инструмент унаследует этот бардак.

Время на проверку так же важно. Руководитель должен за несколько минут оценить выборку результатов и понять, достаточно ли она хороша, нужны ли правки или тест нужно останавливать. Если проверка занимает час, вы ничего не сэкономили. Вы просто переложили работу на другого человека.

Прежде чем утверждать расходы, ответьте на пять простых вопросов. Может ли один человек объяснить точную задачу, исходный материал и конечный результат? Может ли команда получать пригодные данные по обычному графику без ежедневной ручной чистки? Может ли менеджер достаточно быстро оценивать качество, чтобы тест оставался практичным? Можно ли отменить инструмент через месяц, если им почти не пользуются? Можно ли привязать расходы к одной командной цели с конкретной цифрой?

Последнюю проверку люди пропускают постоянно. «Использовать ИИ чаще» — это не командная цель. «Сократить ввод счетов с 6 часов в неделю до 2» — это цель. Финансы могут её отслеживать, а команда — видеть, окупается ли лицензия.

Такая дисциплина скучна, но она работает. И это именно тот толчок, который хороший Fractional CTO должен дать до того, как кто-то подпишет годовой контракт.

Что делать дальше

Завершите аудит до того, как сравнивать поставщиков, тарифы или условия договора. Если начать с перечня функций, вы будете оценивать шоу продаж, а не саму работу. Именно так команды покупают слишком рано и через месяц получают неиспользуемый софт.

Превратите аудит в короткий лист решения. Назовите одну задачу, которую хотите улучшить. Запишите, кто отвечает за неё сейчас. Укажите, на какие исходные данные она опирается. Оцените текущее время, которое тратится каждую неделю. Определите, как выглядит успех через 30 дней.

Затем возьмите самый маленький план, который позволяет провести реальный пилот. Держите тест узким: один процесс, один владелец, одна команда. Небольшой пилот даёт более чистую обратную связь, потому что вы видите реальное использование, реальные ошибки и то, экономит ли инструмент время владельца.

Назначьте дату проверки ещё до начала пилота. Через 30 дней посмотрите вместе на использование, уровень ошибок и данные по времени. Если люди избегают инструмента, не спешите сразу винить обучение. Сначала проверьте, не слишком ли беспорядочный процесс, не слабые ли входные данные и не приходится ли владельцу слишком многое исправлять вручную.

Здесь же может помочь второе мнение. Oleg Sotnikov на oleg.is работает со стартапами и средним бизнесом в области AI-first-разработки, автоматизации, инфраструктуры и поддержки в формате Fractional CTO, и такой ранний разбор часто помогает заметить пробелы в процессе до того, как они превращаются в потраченные впустую лицензии.

Покупайте ИИ-инструменты после всей этой работы, а не до неё. Тогда вы покупаете не надежду. Вы финансируете небольшой тест с понятной целью, реальным владельцем и измеримым результатом.