Декомпозиция процессов
Любой процесс можно описать слишком крупно или слишком мелко. Слишком крупное описание выглядит как “обработать заявку” и не показывает, что реально происходит. Слишком мелкое превращается в инструкцию из десятков технических действий. Декомпозиция нужна, чтобы найти рабочий уровень детализации.
В основе структурного проектирования процессов лежат несколько базовых конструкций: последовательность, ветвление, цикл и декомпозиция. Эти конструкции применимы не только к программному коду. Их удобно использовать для описания процессов информационной системы: обработка заявки, согласование документа, регистрация обращения, оформление заказа, выдача пропуска.
Нисходящее проектирование идёт от общего процесса к деталям. Сначала фиксируется крупная работа: “оформить заказ”. Затем она разбивается на подпроцессы: выбрать товары, проверить наличие, оформить доставку, выполнить оплату, подтвердить заказ. Такой подход удобен, когда общий результат понятен, но нужно аккуратно раскрыть внутреннюю структуру.
Восходящее проектирование идёт от известных простых действий к более крупным процессам. Такой подход полезен, когда отдельные операции уже понятны, но нужно собрать их в целостную работу. Например, в организации уже есть регистрация, проверка, согласование и уведомление, но нужно понять, как они складываются в единый процесс.
Хороший подпроцесс должен отвечать на несколько вопросов:
| Вопрос | Зачем нужен |
|---|---|
| С чего подпроцесс начинается? | определить вход или триггер |
| Чем подпроцесс заканчивается? | зафиксировать результат |
| Кто несёт ответственность? | не потерять участника процесса |
| Какие данные используются? | связать процесс с предметной областью |
| Какие правила применяются? | показать условия и ограничения |
| Можно ли проверить выполнение? | отделить процесс от расплывчатого описания |
Например, “проверить заявку” — нормальный подпроцесс, если известно, какие данные проверяются, кто проверяет, какие правила применяются и каким результатом всё заканчивается: заявка принята, отклонена или отправлена на доработку. “Работа с заявкой” — плохой подпроцесс, потому что он не имеет ясной границы.
Проектирование вширь помогает сначала построить основной успешный путь, а затем добавлять альтернативы. Это снижает риск утонуть в исключениях раньше, чем понятен нормальный процесс. После того как основной поток стабилен, к отдельным шагам добавляются ветвления: что если данных недостаточно, что если участник отказался, что если внешняя система недоступна.
Декомпозиция также помогает связать процесс с дальнейшими моделями. Отдельные действия могут стать кандидатами на операции, данные на потоках — кандидатами в предметные объекты, а повторяющиеся проверки — бизнес-правилами.
Уровень декомпозиции зависит от цели материала. Для обсуждения с заказчиком достаточно показать крупные этапы: подача, проверка, согласование, исполнение, закрытие. Для проектирования сценария нужно раскрыть условия и альтернативы внутри этапов. Для технической реализации понадобится ещё более точное понимание операций, но это уже не должно перегружать бизнес-описание процесса.
Признак хорошей декомпозиции — возможность свернуть подпроцесс обратно в один шаг без потери общего смысла. Если подпроцесс нельзя назвать понятным глаголом с результатом, его границы выбраны неудачно.