Как выбрать процессы для ИИ-автоматизации: опыт команды Аспро.Cloud

Передать рутину ИИ — не значит автоматизировать все подряд. Команда Аспро.Cloud провела структурированный аудит, выбрала пять приоритетных сценариев и прошла путь от первого запроса до системного результата.

Большинство попыток внедрить ИИ в рабочие процессы начинаются с первого очевидного сценария — например, генерации текстов. Это работает, но оставляет за кадром более ценные возможности: автоматизацию работы непосредственно с данными системы управления.

Команда Аспро.Cloud пошла иначе: сначала аудит и приоритизация, потом — подключение. Методология и результаты — ниже.

Аудит: как найти реальные потери времени

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

Результат: около 20 процессов. Часть оказалась неожиданной: переназначение задач при смене ответственного никто не считал значимой статьей потерь — пока данные не собрали системно.

Фильтрация по двум параметрам:

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

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

Инфраструктура: MCP как стандарт подключения ИИ к бизнес-данным

Для интеграции использовали MCP (Model Context Protocol) — открытый стандарт Anthropic, принятый OpenAI, Google и Microsoft к февралю 2025 года.

Архитектурный принцип: в системе разворачивается MCP-сервер с явным перечнем допустимых действий. Каждый инструмент — одна операция: получить список проектов, создать задачу, изменить статус, найти сделку. Модель работает только через разрешенные инструменты в рамках прав API-ключа. Прямого доступа к базе данных нет.

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

Первый этап: аналитика без риска

Запуск начался с безопасного режима — только чтение данных. Это дало команде время привыкнуть к формату и проверить точность интерпретации до перехода к активным операциям.

Первый практический результат: запрос «Составь сводку по состоянию компании» заменил еженедельный ручной отчет, занимавший 2–3 часа. Аналитический запрос «Что можно улучшить на основе этих данных?» выявил паттерн, который при ручном просмотре легко пропустить: VIP-сегмент формирует 30% оборота при 5% от числа сделок. Для команды это стало сигналом к пересмотру приоритетов в работе с клиентской базой.

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

Второй этап: операции записи и механизм контроля

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

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

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

Постановка задач после совещания: с 40–60 минут до 5–10 минут. Качество задач выросло — исполнители перестали переспрашивать детали.

Контроль счетов: финансовый эффект автоматизации

Наиболее показательный с точки зрения измеримого финансового результата — сценарий контроля выставленных счетов.

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

Ключевой результат — не только экономия времени. Просроченные платежи теперь выявляются в среднем на 10 дней раньше. При регулярных платежах от нескольких клиентов одновременно это прямое влияние на кассовый разрыв.

Масштабирование: что важно учесть

Параллельно с запуском провели два внутренних обучающих блока. Ключевое правило проговаривалось отдельно: не давать разрешение «Да, всегда» на операции с чувствительными данными — только «Да, только сейчас». Через месяц стало стандартом.

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

Итог пяти сценариев первого этапа:

1. еженедельный отчет — с 2–3 часов до 15–20 минут
2. задачи после совещания — с 40–60 минут до 5–10 минут
3. контроль 25+ проектов — с 2–3 часов до 10–15 минут
4. поиск данных в системе — с 10–15 минут до 1–2 минут
5. контроль счетов — с 4 часов до 30–40 минут; просроченные платежи выявляются на 10 дней раньше