наличие документации должно подразумевать то что она будет обновляться, по другому к сожалению ни как
BPMS системы к сожалению не освободили нас от этого)

Захман говорит о необходимости этого реестра, а не о методе его организации, как я понял.

Но нужно выбрать правильный уровень детализации.

только добавили работы, новые подразделения, постоянные обновления. Потом породили софт для всего этого — бизнес студии и арисы.  а потом и движки bpm

Хм, не видел такого. Но полную версию не читал.
Реестр процессов может быть полезен. Для определенных задач. Зачем он нужен в твоем случае?

Хм, не видел такого. Но полную версию не читал.
Реестр процессов может быть полезен. Для определенных задач. Зачем он нужен в твоем случае?

Коллеги, добрый вечер!

Сейчас я формирую список бизнес-процессов в своей компании согласно схеме Захмана. Искал примеры в сети, но везде описывается только основной посыл, но нет однозначных ответов или примеров. Скорее всего потому, что у каждой компании свой подход.
Итак вот я наткнулся на следующие проблемы:
- Как следует группировать процессы? По отделам? По документам/объектам? По направлениям? Нужно ли их группировать вообще?
- Процессы учитывают реализацию? Например, непонятно как действовать в случае, если процесс может проходить через разные интерфейсы, у которых разные оунеры. Это один процесс с несколькими оунерами и надо уточнять, какой из них за какой интерфейс отвечает? Или оунер всегда должен быть один?
- Какие данные должны сопровождать каждый процесс? Оунер, список стейкхолдеров, схема процесса, ссылки на реализацию? Или это уже перебор и нужен только оунер?
- Можно ли формировать список бизнес процессов  в RMS? RMS в моём случае имеет обязательные объекты folder-document-section-use case/procedure-requirement. Кажется, что подобная структура не подходит, хотя и позволяет повторно использовать объекты.

И в конце, возможно у кого-то будет пример списка?

Спасибо!

документация - это постоянная работа с ней, постоянное ее обновление, она всегда будет недостаточно полной и недостаточно актуальной
не получится один раз написал и забыл, ее всегда надо обновлять, это должно быть частью процесса
иначе она быстро деградирует и пользы от нее 0

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

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

вопрос к диаграммам или и к описательной части?

Предлагаю выбрать одну причину и разобрать ее

К описательной части. К диаграммам вопросов нет - в них можно описать всё на любом уровне.
Вопрос в том, описывать ли процесс верхнего уровня "Принять и обработать заказ", указывая что он состоит из 6-ти субпроцессов. Или же описывать 6 субпрцоессов, а из них компоновать большие процессы?

Всё-таки хорошо было сказано выше, что процесс должен приносить некую прибыль. В этом случае надо описывать только целостные процессы, которые влияют на клиента тем или иным образом.

К описательной части. К диаграммам вопросов нет - в них можно описать всё на любом уровне.
Вопрос в том, описывать ли процесс верхнего уровня "Принять и обработать заказ", указывая что он состоит из 6-ти субпроцессов. Или же описывать 6 субпрцоессов, а из них компоновать большие процессы?

Всё-таки хорошо было сказано выше, что процесс должен приносить некую прибыль. В этом случае надо описывать только целостные процессы, которые влияют на клиента тем или иным образом.