Что автоматизировать первым: как выбрать процесс и проверить, нужен ли ему AI

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

Как сравнить кандидатов и выбрать один

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

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

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

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

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

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

Как проверить, нужен ли процессу AI

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

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

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

Если остаётся работа со свободным текстом, стоит уточнить, что именно не получилось решить проще. Возможно, нужно подготовить разные формулировки на основе согласованных сведений. Это основание проверить AI, но само наличие текста ещё не доказывает его необходимость. В NIST AI RMF Playbook рассмотрение жизнеспособных альтернатив без AI входит в рекомендации по управлению рисками.

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

Условный пример: черновик коммерческого предложения

Рассмотрим вымышленную ситуацию — не кейс kAIros и не результат проведённого испытания. Менеджер готовит коммерческое предложение по согласованному запросу клиента. У него есть разрешённые к использованию исходные данные, утверждённые позиции, цены и условия.

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

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

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

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

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

Какие затраты учитывать и где появляется экономия

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

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

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

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

Как провести пилот и принять решение

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

Для пилота стоит выбрать ограниченный участок и сопоставимые задачи с одинаковыми требованиями к принятому результату. Если проверяется вариант с AI, сравнить его с уже найденным простым вариантом. Удобные случаи не должны быть единственными: нужны и те исключения, которые предполагается обрабатывать в заданных границах. Повторное выполнение знакомой задачи тем же менеджером нужно отметить отдельно — такое сравнение не отделяет пользу инструмента от знакомства с заданием.

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

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

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

Условия остановки тоже согласуют до запуска. В примере с предложением основанием может стать неподтверждённое условие в тексте, которое не удаётся надёжно выявлять при проверке. Другие основания — нарушение согласованного обращения с данными, невозможность проверить результат или превышение установленного предела затрат. Ответственному нужно иметь возможность прекратить использование нового варианта и вернуть ручной порядок, а затем разобрать причину. NIST отдельно описывает механизмы и ответственность за отключение или замену AI, если его работа не соответствует предназначению.

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

Карточка выбранного процесса

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

• Процесс и границы: что запускает работу; какой результат принимается; какие действия остаются за пределами пилота.
• Почему выбран первым: наблюдаемая ручная работа и ограничения; чем этот кандидат сейчас удобнее для проверки, чем остальные.
• Исходное измерение: период и число случаев; активное время, ожидание, исправления и исключения; откуда взяты сведения и чего пока не хватает.
• Данные: необходимые исходники, место хранения, доступность для выполнения и проверки, разрешённый способ использования.
• Ошибки и исключения: что считается ошибкой; кто её обнаруживает; возможные последствия; кто разбирает случай и как возвращается к ручной работе.
• Вариант без AI: шаблон, готовая функция или правила; что они закрывают и какое ограничение осталось. Если их достаточно, AI не добавляется.
• Шаг AI, если он нужен: конкретное действие модели, доступные ей сведения, запреты и способ проверки человеком.
• Затраты и ожидаемая польза: разовая подготовка, внедрение, регулярная проверка, поддержка и переделки; время и денежные расходы раздельно; куда предполагается направить высвобождённое время.
• План пилота: сопоставимые случаи, критерий принятия результата и критерий успеха, согласованные пределы качества и затрат, ответственный за измерение и решение, дата разбора, условия остановки.
• Решение после проверки: что фактически получено; продолжить, упростить, изменить границы или остановить; какие наблюдения стали основанием.

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

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

Обсудить задачу

Источники

• Microsoft: Recommendations for implementing automation — рекомендации по эксплуатации Power Platform: выбор процедурных задач, готовые инструменты, сопровождение и передача контекста человеку.
• Anthropic: Building effective agents — выбор простого решения для приложений с языковыми моделями и причины ограничивать сложность.
• NIST AI RMF Playbook — Map — последствия ошибок и границы применения AI.
• NIST AI RMF Playbook — Measure — метрики, условия испытания и границы выводов.
• NIST AI RMF Playbook — Manage — альтернативы без AI, решение о продолжении и ответственность за отключение.

Использованы сохранённые тексты источников, полученные 16 октября 2026 года. Способ сравнения кандидатов и форма карточки — рекомендации редакции; источники не устанавливают универсальный рейтинг процессов.