Сопоставьте действие процесса и бизнес-объект: по какому признаку аналитик различает их на модели?
Действие изменяет состояние объекта или запускает работу и потому имеет исполнителя, длительность и результат. Бизнес-объект — это предмет работы или данные, с которыми выполняются действия; сам по себе он ничего не делает. На модели действие обычно выражается глаголом, а объект — существительным.
В ранних схемах процессов часто смешивали операции, документы и результаты работы. Это делало модели понятными на бытовом уровне, но непригодными для расчёта времени, ответственности и автоматизации.
Стандартизированные подходы к моделированию, включая BPMN, разделяют поток работ и информацию, которой эти работы обмениваются. Такое разделение нужно, чтобы последовательность процесса не зависела от того, какой документ или объект сопровождает работу.
Если обозначить бизнес-объект как действие, модель начинает описывать не работу, а её предмет. Например, шаг «Заявка» не отвечает на вопросы: кто обрабатывает заявку, что именно делает сотрудник и какой результат завершает шаг.
Такая ошибка искажает длительность процесса, распределение ответственности и оценку автоматизации. Аналитик может ошибочно посчитать документ отдельной операцией или пропустить реальную работу — проверку, согласование, регистрацию либо передачу.
Сначала нужно задать проверочный вопрос: можно ли назвать элемент действием с исполнителем и наблюдаемым результатом? Если да, это кандидат на операцию процесса. Примеры: «Проверить заявку», «Согласовать договор», «Зарегистрировать обращение».
Если элемент обозначает предмет, данные или результат работы, это бизнес-объект: «Заявка», «Договор», «Платёжное поручение». Он связывается с действиями как вход, выход или изменяемая информация, но не заменяет последовательность работ.
Важна граница между объектом и его состоянием. «Заявка» — объект, а «Заявка проверена» — его состояние или результат действия. Если изменение состояния существенно для маршрута, его нужно показать через действие, событие или условие — в зависимости от используемой нотации и цели модели.
Практический тест состоит из трёх вопросов:
Если на эти вопросы нет ответа, элемент, вероятно, является объектом, состоянием или событием, а не действием. При этом чрезмерная детализация тоже вредна: не каждое изменение поля нужно превращать в отдельную операцию. Уровень детализации выбирают по цели модели — анализ времени, ответственности, автоматизации или соответствия регламенту.
В модели обработки договора был показан маршрут «Заявка → Договор → Оплата». Заказчик считал, что процесс описан полностью, но команда не могла определить, где происходят проверка реквизитов и согласование условий.
Рассматривались два варианта. Первый — оставить объекты как шаги: он сохранял краткость, но скрывал исполнителей, длительность и контрольные точки. Второй — заменить их действиями: «Проверить заявку», «Подготовить договор», «Согласовать договор», а документы показать как входы и результаты. Этот вариант был подробнее, зато позволял оценить задержки и зоны ответственности.
Выбрали второй вариант. В результате обнаружили, что основная задержка возникает не при подготовке договора, а во время его согласования. Объект «Договор» остался в модели как результат и вход для последующих действий, а не как самостоятельная операция.
Он может быть связан с действиями, но не должен задавать последовательность вместо них. Последовательность показывает, какие работы выполняются и в каком порядке; объект показывает, какая информация или материальный результат передаётся между работами.
Нет. Название «Проверка заявки» содержит существительное, но обозначает работу. Поэтому важна не только грамматическая форма, а наличие исполнителя, результата и измеримого изменения. И наоборот, «Заявка зарегистрирована» может описывать состояние, а не действие.
Нет. Объект следует включать, если он влияет на маршрут, ответственность, контроль, интеграцию или результат процесса. Если документ не помогает ответить на вопрос анализа, его детализация только перегружает модель и создаёт ложное впечатление точности.