Что я проверяю до того, как предлагаю бизнесу AI

«Нам нужен AI» — понятное желание. Но для меня это ещё не постановка задачи.

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

Я работаю в IT с 2003 года: корпоративные системы, интеграции, аналитика, автоматизация. В работе с AI опираюсь на тот же принцип: сначала разобраться в процессе и договориться о результате, затем выбирать инструменты.

Вот что я проверяю до предложения проекта.

1. Какую проблему мы собираемся решить

«Ускорить отдел продаж» — слишком широко. «Менеджер долго готовит ответ на входящий запрос» — уже ближе к задаче.

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

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

Первый вопрос: что станет лучше, если проект сработает? Ответ должен быть понятен человеку, который будет принимать работу.

2. Как процесс устроен на самом деле

Регламент полезен, но мне важно пройти путь реальной задачи вместе с сотрудником. Посмотреть, какие окна он открывает, что переносит вручную, у кого спрашивает и где ждёт.

Допустим, обработка заявки занимает два дня. Самой работы в ней — полчаса, остальное время заявка лежит между отделами. Ускорение написания текста не устранит эту очередь.

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

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

3. Есть ли более простое решение

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

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

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

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

4. На какие данные будет опираться система

Фраза «у нас всё есть в документах» требует уточнения.

Где актуальная версия? Кто отвечает за изменения? Какие сведения можно использовать для ответа клиенту? Как разрешаются противоречия между прайсом, CRM и перепиской?

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

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

На выходе нужен конкретный перечень источников, ответственных и ограничений.

5. Что произойдёт, если AI ошибётся

Черновик внутренней заметки, ответ клиенту и изменение заказа имеют разную цену ошибки.

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

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

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

6. Сходится ли экономика с учётом проверки

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

Условный пример: вручную операция занимает 12 минут. С помощником подготовка занимает 2 минуты, ещё 4 минуты — проверка и исправления. Экономия составляет 6 минут, а не 10. На 300 таких операциях это 30 часов в месяц. Это арифметический пример, а не результат клиентского проекта.

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

Я хочу видеть эту связь до расчёта окупаемости. А если проверка AI-ответа занимает почти столько же времени, сколько выполнение задачи вручную, пользу решения нужно пересмотреть.

7. Кто будет отвечать за работу после запуска

У процесса должен быть владелец со стороны бизнеса. Человек, который может уточнить правила, оценить результат и решить, что менять.

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

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

8. Как мы проверим результат пилота

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

Например, для помощника менеджера можно проверить подготовку черновиков ответа на входящие запросы. До запуска договориться:

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

Конкретные пороги зависят от процесса. Их нужно записать до пилота, пока результат ещё неизвестен.

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

С чего я предлагаю начать

Перед обсуждением AI попробуйте закончить одну фразу:

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

Если фраза пока не складывается, первый шаг — разобрать процесс и собрать исходные данные.

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

Учебная развилка: одинаковая жалоба, разные решения

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

Соберите маршрут одного ответа

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

Результат обследования — объяснение задержки, проверяемая гипотеза и минимальный эксперимент. Учебная развилка не описывает опыт конкретного клиента и не обещает эффект внедрения.