не начинайте со списка возможностей нейросети
формулировка «где нам применить ии» почти всегда рождает слишком широкий разговор. команда перечисляет продажи, поддержку, документы, аналитику, генерацию контента — и ни одна задача не становится достаточно конкретной, чтобы её проверить.
полезнее спросить иначе: какую повторяемую работу люди делают руками прямо сейчас — и по каким признакам понимают, что сделали её хорошо?
так разговор переходит от технологии к процессу. а процесс — единственное, что ии умеет ускорять.
пять фильтров хорошей первой задачи
1. работа повторяется
если задача возникает каждый день или каждую неделю, на ней можно собрать примеры, увидеть типовые ошибки и измерить изменение. редкий процесс для первого пилота подходит плохо: проверка растягивается на месяцы, а эффект не отличить от случайности.
2. есть реальные примеры
нужны не инструкции, а история: входы и хорошие результаты. для квалификации заявок — сами обращения и решения менеджеров. для документов — исходные данные, шаблоны и принятые версии. для отчётности — источники цифр и готовые сводки.
десять примеров — достаточно, чтобы начать разговор. тридцать-пятьдесят обычно лучше показывают разнообразие процесса. точное число зависит от того, сколько в процессе исключений.
3. результат можно проверить
«ответ должен быть качественным» — не критерий. нужны наблюдаемые признаки: обязательные поля заполнены, числа сходятся с источником, использован нужный шаблон, спорный случай ушёл человеку.
если два опытных сотрудника не могут договориться, что считать хорошим результатом, — автоматизация сначала унаследует их разногласия. проверено.
4. ошибка контролируема
хорошая первая система готовит черновик, сортирует, извлекает данные, находит пробелы, предлагает действие. важное решение подтверждает человек.
ручную проверку не обязательно оставлять навсегда. но в начале она даёт обратную связь и страхует процесс, пока реальное качество агента ещё неизвестно.
5. у процесса есть владелец
нужен человек, который знает реальные обходные пути (а не регламент двухлетней давности), даст примеры и найдёт время проверить пилот. без владельца даже технически рабочая версия зависает между подразделениями — и виноватым назначат ии.
быстрая таблица оценки
оцените каждого кандидата по шкале от 0 до 2.
| критерий | 0 | 1 | 2 |
|---|---|---|---|
| частота | реже раза в месяц | несколько раз в месяц | каждую неделю или чаще |
| примеры | почти нет | есть разрозненные | есть набор входов и результатов |
| проверка | только субъективное мнение | есть часть правил | понятны признаки хорошего результата |
| цена ошибки | высокая и незаметная | найдётся, но позже | ошибка сразу видна и обратима |
| владелец | никто не отвечает | участвует нерегулярно | есть человек, который проверит |
8–10 баллов — хороший кандидат для разбора. 5–7 — сначала стоит уточнить правила или собрать данные. низкая оценка не значит, что автоматизация невозможна, — она значит, что этот процесс будет дорогим способом начать.
пример: входящие заявки
слишком широкая цель: «ии должен увеличить продажи».
проверяемый участок:
- получить текст заявки и источник;
- найти обязательные сведения;
- сверить со стоп-факторами;
- подготовить краткую сводку;
- предложить следующий вопрос;
- передать решение менеджеру.
в таком виде можно взять прошлые заявки, сравнить результат агента с действиями команды и увидеть, где правила работают нестабильно.
пример: подготовка документа
слишком широкая цель: «ии пишет коммерческие предложения».
проверяемый участок:
- получить карточку клиента и выбранный продукт;
- проверить наличие обязательных данных;
- заполнить утверждённый шаблон;
- отметить места, где информации не хватило;
- дать ссылки на использованные источники;
- отправить черновик сотруднику.
система здесь не придумывает условия сделки. она снимает механическую сборку и делает пробелы заметными.
какие процессы лучше не брать первыми
плохим стартом обычно становятся задачи, где:
- нет повторяемого входа;
- хороший результат зависит от личных переговоров;
- правила меняются под каждого клиента;
- примеры нельзя безопасно выделить;
- ошибка сразу создаёт финансовое или юридическое обязательство;
- команда ждёт полностью автономную работу с первого дня.
иногда такой процесс можно автоматизировать частично: не принимать решение, а собирать контекст для человека. это скромнее звучит в презентации, зато работает.
что должно получиться после разбора
достаточный результат — одна схема и несколько решений:
- фиксированный вход и выход;
- список доступных данных;
- критерии качества;
- место ручной проверки;
- тестовый набор;
- условие, при котором пилот продолжается или останавливается.
если после разговора всё ещё обсуждается «умный помощник для отдела» — задача пока не стала проектом. вернитесь к пяти фильтрам.