Готовность процесса к автоматизации проверяется до договора и до первого доступа к данным. Прямой ответ такой: процесс готов, если у него есть владелец, шаги повторяются в одном порядке, входные данные существуют и структурированы, правила вывода сформулированы, исключения известны, интерфейсы систем доступны, а результат описан так, что его можно принять или отклонить. Если закрыты пять пунктов из семи, задачу можно считать рабочей и браться за неё.
Отдельного технического задания для такой проверки не нужно. Руководитель описывает процесс своими словами: кто выполняет, что делает руками, в каких системах лежит данные и какой результат ждёт. Дальше проверка сводится к семи вопросам, на которые можно ответить за один-два разговора с отделом и ИТ.
Готовность процесса к автоматизации: чек-лист из семи проверок
Чек-лист автоматизации процесса удобно держать в виде таблицы: один процесс — одна строка по каждому пункту, со статусом «закрыто / частично / нет». Семь пунктов такие: владелец процесса, повторяемость шагов, входные данные, правила вывода, исключения и спорные случаи, интерфейсы систем и доступы, критерий готового результата.
Пункты не равноценны. Владелец и критерий результата — обязательны: без них невозможно ни оценить пользу, ни принять работу. Остальные можно закрывать по ходу разбора, но если данных нет вообще, а интерфейсы недоступны, сроки и бюджет будут неопределёнными.
Владелец процесса и повторяемость шагов
Владелец — тот, кто отвечает за результат процесса и может менять порядок работы. Не наблюдатель и не «группа заинтересованных», а конкретный руководитель или специалист. У него спрашивают, как процесс идёт сейчас, где он ломается и какой результат считается правильным.
Повторяемость проверяется просто: одинаково ли отдел делает одинаковые заявки, заказы или обращения. Если два сотрудника обрабатывают одни и те же письма по-разному, автоматизация закрепит одну из версий, и это будет случайная версия. Сначала фиксируют способ работы, который считается правильным, и только потом передают его агенту или скрипту.
Входные данные: что должно существовать до старта
Данные для автоматизации проверяют по трём вопросам: где лежат, в каком виде и кто ими владеет. Типичный набор — 1С, CRM, почта, файловые хранилища, внутренние базы и таблицы, по которым сотрудники переносят информацию руками.
Важно не количество данных, а их пригодность. Нужны реальные примеры документов, писем или записей из систем — несколько штук на типовой случай и по одному на редкий. Если примеров нет, значит, процесс ещё не сложился как повторяемый. Если данные лежат в переписке и личных таблицах, их сначала собирают в одно место, и это отдельная работа, а не бесплатное дополнение к автоматизации.
Правила, исключения и спорные случаи
Правило — формулировка вида «если клиент прислал счёт без договора, отправляем на согласование». Таких правил в живом процессе обычно десятки, и они живут в головах сотрудников. Задача проверки — вытащить их на бумагу хотя бы в виде списка.
Отдельно фиксируют исключения: что делать с неполными заявками, нестандартными суммами, конфликтными клиентами. И главное — что считать спорным случаем. Спорный случай агент не решает сам, а передаёт назначенному сотруднику. Чем раньше список спорных случаев составлен, тем меньше правок после запуска.
Интерфейсы систем, доступы и ограничения ИБ
Проверка интерфейса — практическая, а не бумажная. Система считается доступной, если удалось получить данные на чтение через существующий интерфейс: API, OData, выгрузку, почтовый ящик или доступ к хранилищу. Если доступа нет, интеграция превращается в отдельный проект и удорожает задачу.
Сразу фиксируют и ограничения по безопасности: какие классы данных можно передавать внешним моделям, а какие должны оставаться на сервере заказчика. Площадку и каналы доступа согласуют с ИТ и ИБ до того, как агент увидит первый документ. Доступы выдаются на чтение и с минимальными правами, пароли и ключи передаются отдельно по защищённому каналу, а не в рабочей переписке.
Критерий готового результата и контроль человека
Критерий результата отвечает на вопрос: как отдел поймёт, что работа сделана правильно. Хороший критерий проверяем: «ответ отправлен клиенту в течение рабочего дня и содержит согласованный прайс» — можно принять. «Агент помогает менеджерам» — принять нечего.
Вместе с критерием описывают точки контроля человека. Есть операции необратимые — отправка письма клиенту, изменение записи в CRM, списание. Их выполняют по подтверждению, а действия агента журналируют. Граница между «делает сам» и «ждёт подтверждение» определяется до сборки, а не после первого инцидента.
Пример: как выглядит проверка одного процесса
Это пример-сценарий, а не опубликованный кейс клиента. Отдел продаж обрабатывает входящие заявки с сайта: менеджер копирует заявку из почты в CRM, проверяет наличие товара в 1С, готовит ответ и вручную ставит задачу на звонок.
По чек-листу выходит так. Владелец — руководитель отдела продаж, он же согласует порядок обработки. Повторяемость высокая: заявки обрабатываются одинаково, различается только состав данных. Входные данные лежат в трёх местах: почта, CRM и 1С, у каждого есть интерфейс, доступ подтверждён на чтение. Правила известны частично: известно, как отвечать на типовые вопросы, но нет правила по нестандартным суммам. Исключения не описаны, спорные случаи менеджеры решают сами. Критерий результата есть: ответ клиенту отправлен, сделка создана, задача на звонок поставлена.
Вывод по примеру: процесс подходит для автоматизации, но первым сценарием будет подготовка черновика ответа с проверкой остатков, а не отправка письма клиенту. Отправку оставляют на подтверждении человека, пока не собраны правила по нестандартным суммам.
Этапы внедрения, риски и проверка результата
Большое внедрение не начинается, пока не проверены процесс, данные и интерфейсы. Порядок работ обычно такой: описание задачи, оценка, договор и доступы, сборка, проверка, запуск и сопровождение. На шаге оценки проверяют, подходит ли задача для ИИ, и называют состав работ, диапазон часов и лимит бюджета; если ИИ здесь не нужен, это фиксируют письменно. Каждый шаг заканчивается проверяемым результатом, и остановиться можно после любого из них — порядок опубликован в разделе «Как проходит внедрение».
Основные риски связаны не с технологией. Это процесс без владельца, «плавающие» правила, недоступные интерфейсы, слишком широкий охват на старте и отсутствие критерия результата. Отдельно учитывают ограничения ИБ и стоимость сторонних ресурсов: серверы, лицензии, платные модели оплачиваются отдельно и согласуются заранее.
Проверить результат можно заранее заданными сценариями: типовые, ошибочные и рискованные. До выпуска в отдел агент работает в стендовой группе, его действия журналируются, спорные случаи уходят человеку. По итогам месяца вы получаете отчёт и акт: что изменилось в работе отдела, какие сценарии проверены, сколько часов записано. Полный порядок расчёта и правила приёмки описаны в разделе «Прайс».
С чего начать прямо сейчас: возьмите один процесс — тот, что болит сильнее всего — и заполните по нему семь пунктов чек-листа. Пустые клетки покажут, нужен ли разбор. Дальше можно описать задачу на аудит процессов и консультации, свериться с порядком работ на странице как проходит внедрение и уточнить стоимость по открытому прайсу. Если нужен разговор без формальностей — контакты OfficeForge.
Частые вопросы
Что значит готовность процесса к автоматизации?
Это состояние, при котором процесс можно описать однозначно: у него есть владелец, шаги повторяются в одном порядке, входные данные существуют и структурированы, правила и исключения известны, интерфейсы систем доступны, а результат принят по заранее согласованному критерию. Если хотя бы два пункта не закрыты, сначала приводят в порядок процесс, а не автоматизацию.
Можно ли автоматизировать процесс без регламента и описания?
Да, но регламент придётся получить в ходе разбора: через интервью с руководителем и сотрудниками, разбор реальных документов и фиксацию шагов на схеме. Если процесс каждый раз делается по-своему, автоматизировать нечего — сначала фиксируют способ работы, который считается правильным.
Какие данные нужны для оценки процесса для ИИ?
Несколько реальных примеров документов, писем или записей из систем, которые участвуют в процессе, плюс понимание, где они хранятся и кто ими владеет. Доступ нужен на чтение и с минимальными правами; пароли и ключи передаются отдельно по защищённому каналу.
Как понять, что задача подходит для ИИ, а не для обычной автоматизации?
ИИ нужен там, где входные данные неоднородны, а решение требует разбора текста, контекста или переписки: классификация обращений, черновики ответов, извлечение данных из документов, поиск по базе знаний. Если шаг сводится к переносу чисел из формы в форму, его закрывает обычная интеграция без модели.
Сколько стоит проверка готовности процесса?
Разбор процесса оплачивается по часам из прайса, учёт идёт с шагом 0,5 часа, диапазон часов и лимит бюджета фиксируются письменно до старта. Актуальные ставки и порядок расчёта опубликованы в разделе «Прайс».
Официальные материалы по теме
Для терминов, возможностей интерфейсов и требований безопасности используем первичные материалы разработчиков и профильных организаций.