Участники могут одинаково видеть недостатки текущей работы, но по-разному представлять автоматизацию. Руководитель ожидает готовый результат, сотрудник — удобную очередь задач, а разработчик получает перечень отдельных функций. Расхождения становятся заметны поздно: например, когда нужно решить, что делать с повторным письмом, изменённой заявкой или недоступной CRM.
До оценки и разработки согласуйте целевую модель одной операции. Зафиксируйте начало и завершение процесса, состояния объекта, роли, данные, решения человека и порядок обработки исключений. Такая модель не гарантирует успешного внедрения, но даёт участникам общий предмет для обсуждения и основу для технического задания и приёмки.
Зачем согласовывать целевой маршрут отдельно от аудита и разработки
Аудит отвечает на вопрос, как работа устроена сейчас и где возникают проблемы. Целевая модель описывает будущий порядок: что поступает на вход, какие действия выполняет система, когда подключается человек и какой результат считается завершением. Эти результаты связаны, но не заменяют друг друга.
Работу удобно разделить на этапы:
- Обследовать текущий процесс.
- Согласовать целевую модель.
- Подготовить техническое задание и оценку.
- Проверить ключевой сценарий на прототипе.
- Разработать и принять решение.
BPMN может помочь визуализировать маршрут, но изучать нотацию ради согласования необязательно. Подойдёт таблица состояний или простая схема со стрелками, если участники одинаково понимают её содержание. Техническое задание появляется позже: оно превращает согласованную модель в требования к реализации.
Зафиксировать границы и результат одного процесса
Начните не со всей работы подразделения, а с одной повторяемой операции. Например: обработать заявку на дополнительную интеграцию от получения письма до зафиксированного следующего шага. Такая граница позволяет увидеть маршрут целиком и не смешивать его с продажей, разработкой и сопровождением.
Запишите событие начала, ожидаемый рабочий результат, получателя результата и условия завершения. Отправленное уведомление, новая строка в журнале или успешное выполнение технического сценария ещё не означают, что бизнес-задача завершена. Если сотруднику нужна проверенная карточка заявки, сам факт получения письма не является результатом.
| Поле | Что нужно зафиксировать |
|---|---|
| Входное событие | Какое наблюдаемое событие запускает процесс |
| Исходные данные | Что поступает вместе с событием и чего может не хватать |
| Результат | Что должен получить сотрудник, клиент или следующий процесс |
| Система учёта | Где проверяют состояние и итог операции |
| Владелец процесса | Кто отвечает за правила и разрешает спорные вопросы |
| Участники | Кто вводит данные, принимает решения и получает результат |
| Вне контура | Какие действия сознательно не входят в эту модель |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Граница нужна и для оценки. Формулировка «автоматизировать обработку обращений» допускает десятки трактовок. Формулировка «подготовить карточку заявки, отметить пропуски и передать её специалисту» задаёт проверяемый результат, хотя ещё не описывает техническую реализацию.
Разложить маршрут на состояния и переходы
Состояние показывает, где находится объект с точки зрения работы. Для условной заявки можно использовать названия «Получено», «Нужно уточнение», «Ожидает решения», «Согласовано», «Выполняется», «Завершено» и «Отклонено». Это только пример: названия должны соответствовать языку конкретной команды.
Для каждого состояния ответьте на четыре вопроса:
- Как объект попадает в это состояние?
- Кто и на каком основании переводит его дальше?
- Какие данные и решения сохраняются?
- Что в этот момент видит инициатор?
Не смешивайте три разных события: изменение рабочего состояния заявки, технический статус интеграции и отправку уведомления. Письмо сотруднику может не дойти, хотя заявка уже ожидает решения. И наоборот, уведомление может быть отправлено, хотя запись в рабочей системе не создана. В модели это разные факты.
| Состояние | Условие входа | Ответственный | Допустимый следующий шаг |
|---|---|---|---|
| Получено | Сохранены письмо и идентификатор события | Система или оператор | Проверить данные |
| Нужно уточнение | Не хватает обязательного значения | Назначенный сотрудник | Подготовить и подтвердить вопрос |
| Ожидает решения | Данных достаточно, но нужен вывод специалиста | Уполномоченный специалист | Согласовать, отклонить или вернуть на уточнение |
| Выполняется | Решение принято для определённой версии данных | Исполнитель процесса | Зафиксировать результат или исключение |
| Завершено | Рабочий результат сохранён и доступен получателю | Владелец результата | Закрыть операцию |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Разделить действия системы и решения человека
Система может выполнять действие автоматически, если команда согласовала однозначное правило и предусмотрела исключения. Например, она может зарегистрировать письмо, найти заполненные поля и подготовить карточку. Но решение о технической возможности интеграции, цене или особых условиях остаётся за специалистом клиента, если для него нет утверждённого автоматического правила.
| Этап | Что может подготовить система | Что решает человек |
|---|---|---|
| Регистрация | Сохранить событие, исходный текст и вложение | Разобрать спорную принадлежность обращения |
| Проверка данных | Показать заполненные и отсутствующие поля | Подтвердить запрос на уточнение |
| Техническая оценка | Собрать контекст и передать материалы | Оценить возможность и условия реализации |
| Исполнение | Выполнить разрешённое действие по правилу | Разрешить нестандартное или рискованное действие |
| Завершение | Записать результат и уведомить участника | Подтвердить спорный итог |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
В Power Automate действие Start and wait for an approval запускает согласование и ожидает ответа согласующих перед продолжением потока. Документация Power Automate также описывает последовательное согласование: запросы направляются участникам по очереди, и следующий получает запрос после ответа предыдущего. Это возможности конкретной платформы, а не универсальное свойство любой системы автоматизации.
Даже при наличии такого механизма отдельно спроектируйте содержание запроса, полномочия согласующего, варианты ответа, отмену, замещение и проверку актуальности данных перед исполнением. Документация функции сама по себе не подтверждает, что эти правила уже настроены или подходят вашему процессу.
Определить данные, источники и версии
Для каждого шага перечислите обязательные и необязательные поля, источник достоверного значения, идентификатор объекта и место сохранения результата. Неизвестное значение оставляйте неизвестным: система не должна придумывать контакт, систему клиента или согласованное условие.
| Данные | Источник | Как хранить неопределённость | Для чего нужны |
|---|---|---|---|
| Идентификатор обращения | Почта или система регистрации | Ошибка регистрации требует отдельного состояния | Найти повтор и связать события |
| Контакт отправителя | Исходное письмо или подтверждение сотрудника | «Не указан», без подстановки | Запросить уточнение |
| Описание задачи | Текст и вложение | Сохранить исходник и выделенные сведения раздельно | Передать контекст специалисту |
| Целевая система | Сообщение клиента или уточнение | «Требует подтверждения» | Определить следующий шаг |
| Решение специалиста | Ответ уполномоченного участника | Не считать молчание согласием | Продолжить или остановить маршрут |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Решение человека относится к той версии данных, которую он видел. Поэтому вместе с решением сохраните версию существенных полей, автора и время фиксации. Если после согласования меняются система, объём задачи или другое значимое поле, заранее определите маршрут повторной проверки. Простое продолжение по старому решению может привести к исполнению уже неактуальной заявки.
Power Apps Plans позволяет описать бизнес-сценарий на естественном языке и добавить изображения, включая схему процесса. По документации продукт может сформировать решение с таблицами Microsoft Dataverse, приложениями, сайтами Power Pages, потоками Power Automate и агентами Copilot Studio. Это описание возможностей Power Apps Plans, а не доказательство полноты автоматически созданной модели. Доступность зависит, в частности, от среды, региона, ролей и разрешений; пригодность результата нужно проверять в конкретной среде.
Спроектировать исключения и продолжение работы
Исключение должно становиться наблюдаемой частью процесса, а не исчезать в техническом журнале. Для каждого случая определите состояние, сохранённый контекст, ответственного и допустимые варианты продолжения.
| Исключение | Наблюдаемое состояние | Ответственный | Допустимое продолжение |
|---|---|---|---|
| Неполные данные | Нужно уточнение | Сотрудник процесса | Подтвердить вопрос или закрыть заявку с причиной |
| Противоречивые значения | Требует проверки | Владелец данных | Выбрать источник или запросить подтверждение |
| Повторное событие | Возможный повтор | Оператор либо согласованное правило | Связать с существующим объектом или признать новым |
| Внешняя система недоступна | Ошибка записи | Ответственный за операцию | Безопасно повторить, выполнить вручную или остановить |
| Нет ответа | Ожидает решения | Владелец процесса | Напомнить, заменить согласующего или отменить |
| Данные изменились после решения | Требует повторной проверки | Автор решения или его замещающий | Подтвердить новую версию либо вернуть на уточнение |
| Действие выполнено частично | Частичный результат | Назначенный специалист | Продолжить с сохранённого шага или компенсировать действие |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Защиту от дублей, разграничение прав, безопасный повтор, журнал действий, резервный маршрут и восстановление формулируйте как требования к будущему решению и его проверке. Нельзя считать их доступными и правильно настроенными по умолчанию только потому, что выбрана определённая платформа.
Оформить условный маршрут для совместного разбора
Ниже — синтетический учебный пример. Это не клиентский кейс Switch On AI, не результат выполненного теста и не подтверждение совместимости с конкретной CRM, почтовой системой или тарифом.
Условный процесс обрабатывает заявку на дополнительную интеграцию. На вход поступает письмо клиента с описанием задачи и вложением. Автоматизация регистрирует обращение, ищет связанную карточку или готовит черновик новой, извлекает доступные сведения и отмечает пропуски. Она не назначает цену и не подтверждает техническую возможность интеграции.
| Событие | Состояние | Действие системы | Решение человека | Результат шага |
|---|---|---|---|---|
| Получено новое письмо | Получено | Сохранить исходное сообщение и идентификатор | Проверить спорного отправителя | Обращение доступно для разбора |
| Не хватает обязательных сведений | Нужно уточнение | Подготовить список пропусков и проект вопроса | Проверить вопрос перед отправкой | Зафиксирован запрос на уточнение |
| Сведений достаточно | Ожидает решения | Собрать карточку и материалы | Определить, нужна ли техническая оценка | Назначен следующий ответственный |
| Нужна техническая оценка | Ожидает специалиста | Передать исходные данные и вложение | Оценить возможность и ограничения | Решение связано с версией данных |
| Решение принято | Согласовано или отклонено | Записать автора, версию и следующий шаг | Подтвердить формулировку результата | Участники видят итог и продолжение |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Значимые ветви разбирают отдельно:
- Если данных не хватает, заявка не переходит к оценке. Сотрудник проверяет подготовленный вопрос клиенту.
- Если пришло повторное письмо, система отмечает возможный повтор. Правило объединения или создания новой заявки согласуют заранее.
- Если CRM недоступна, маршрут показывает ошибку записи и не сообщает об успешном сохранении. Допустимость и способ повтора определяют в требованиях.
- Если заявка изменилась после согласования, система связывает изменение с прежней версией и направляет существенные данные на повторную проверку.
- Если вложение повреждено или отправитель неизвестен, объект получает отдельное состояние и ответственного, а не продолжает обычный маршрут вслепую.
Такую таблицу можно обсуждать без доступа к реальному интерфейсу. Её задача — сделать видимыми решения и спорные переходы, а не изобразить уже работающую систему.
Проверить модель до оценки и разработки
Проведите настольный разбор на примерах, которые похожи по форме на рабочие, но разрешены к использованию. Один участник зачитывает входные данные, остальные последовательно объясняют состояние объекта, ответственного, доступный контекст и следующий шаг.
Пройдите обычный маршрут и значимые исключения:
- Полная заявка проходит до результата.
- В заявке не хватает обязательного поля.
- Одно событие поступает повторно.
- Внешняя система недоступна.
- Согласующий не отвечает или отменяет решение.
- Существенные данные меняются после согласования.
Количество примеров определяют варианты маршрута и последствия ошибки, а не произвольная норма. Во время разбора отмечайте переходы, которые участники понимают по-разному; действия без владельца; решения без достаточного контекста; состояния, из которых нет допустимого выхода; и результаты, которые нельзя проверить в рабочей системе.
Модель ещё не готова, если один участник считает заявку завершённой после отправки уведомления, а другой — только после появления проверенной записи. Такое расхождение нужно разрешить в модели, а не оставлять разработчику на выбор.
Передать модель в техническое задание и критерии приёмки
По итогам согласования соберите единый пакет:
- границы процесса и рабочий результат;
- схему состояний и допустимых переходов;
- матрицу ролей и полномочий;
- карту данных, источников и версий;
- правила автоматических действий и решений человека;
- перечень исключений и вариантов продолжения;
- открытые вопросы и предположения для прототипа;
- наблюдаемые критерии результата.
Эти материалы становятся входом для технического задания и оценки. В критериях приёмки описывают не внутреннее обещание «сценарий выполнился», а доступный проверке результат. Например: при недоступной CRM пользователь видит состояние ошибки, исходные данные сохранены, ложного сообщения об успешной записи нет, а дальнейшее действие соответствует согласованному правилу.
Если рассматривается Power Apps Plans, документация допускает создание составного решения с компонентами Power Platform. Но состав, права, лицензии, доступность в регионе и пригодность результата нужно проверить для конкретной среды. Сам перечень компонентов не доказывает, что каждый из них нужен процессу или готов к рабочему запуску.
Switch On AI помогает проектировать и внедрять автоматизацию конкретных операций. На странице услуг по автоматизации можно сравнить форматы решений и подготовиться к первому обсуждению. Для разговора достаточно описать одну операцию, используемые системы, роли, ожидаемый результат и спорные исключения; конфиденциальные данные можно заменить условными.
Обычная последовательность работы: разбор процесса, техническое задание и коммерческое предложение, затем бесплатный прототип ключевого сценария. Прототип не является полноценным внедрением. Стоимость, трудозатраты, подключения, права доступа, эксплуатационные расходы и сопровождение согласуются отдельно. Чтобы обсудить свой процесс, передайте исходные материалы Switch On AI.
Вопросы по этой задаче
Чем проектирование будущего процесса отличается от аудита текущей работы?
Аудит фиксирует фактический порядок работы и его проблемы. Проектирование целевой модели определяет будущий маршрут: состояния, переходы, роли, данные, решения человека, исключения и ожидаемый результат.
Обязательно ли рисовать целевой процесс в BPMN?
Нет. Для согласования подойдёт таблица состояний или простая схема, если участники одинаково понимают границы, переходы, ответственных и результат. BPMN можно использовать как способ визуализации, но статья не требует изучать нотацию.
Кто должен участвовать в согласовании целевой модели?
Нужны владелец процесса, сотрудники, которые выполняют операцию и принимают решения, представитель заказчика автоматизации и специалисты, отвечающие за затрагиваемые системы и данные. Состав зависит от маршрута и полномочий участников.
Как понять, какое решение оставить человеку?
Человеку оставляют профессиональные, спорные и рискованные решения, для которых нет однозначного утверждённого правила. Система может собрать контекст, отметить пропуски и выполнить разрешённое действие, но не должна придумывать условия или подменять специалиста.
Что передать разработчику после согласования модели?
Передайте границы процесса, схему состояний и переходов, роли, карту данных и версий, правила решений, перечень исключений, открытые вопросы и наблюдаемые критерии приёмки. Эти материалы затем уточняются в техническом задании.