Участники процесса и потоки

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

Участники и ответственность

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

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

Ход работы и информационные потоки

В процессном описании нужно различать два независимых вопроса:

Вопрос	Что фиксируется	Пример
Как идёт работа?	последовательность шагов, условия, альтернативы, ожидания и завершения	после проверки заявка отправляется на согласование; при отказе возвращается на доработку
Какая информация участвует?	создание, изменение, передача и хранение значимых объектов	заявка передаётся на проверку; платёж получает статус; пользователю отправляется уведомление

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

Границы обмена

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

Например, в процессе оформления заказа клиент подтверждает корзину, система создаёт заказ, платёжный сервис сообщает результат оплаты, а служба доставки получает задание на доставку. У процесса есть и порядок работы, и движение информации: корзина становится заказом, заказ получает статус, результат оплаты влияет на дальнейшие действия, клиент получает уведомление.

Хорошая процессная модель не должна уходить в технические детали вроде SQL-запросов, внутренних методов или конкретных API. На этом уровне важны смысловые действия, ответственность участников, условия перехода и информационные объекты, которые имеют значение для предметной области.

Данные на процессной модели особенно важны для дальнейшей предметной модели. Если в процессе постоянно возникают “заявка”, “подтверждение”, “отчёт”, “статус”, “уведомление”, это не просто подписи. Они могут стать кандидатами в концептуальные классы, атрибуты, состояния или события.

Проверка процессной модели

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

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

Такая проверка делает процесс содержательно полным и помогает подобрать форму, удобную для обсуждения, анализа или реализации.

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