Comments 7
Уважаемый автор, согласно правилам "читаемости" моделей бизнес-процессов, выполненных с использованием нотаций, ориентированных на process flow, ваша модель "ToBe" плохо читаема.
Согласно этим правилам, на одной диаграмме должно размещаться не больше 10 значимых элементов модели бизнес-процесса.
Пересмотрите вашу модель, используйте другие виды диаграмм BPMN - collaboration diagram, choreograpy diagram, чтобы показать взаимодействие между процессами и ролями. Прибегните к разбиению вашей диаграммы процесса на подпроцессы, наконец, чтобы улучшить читаемость.
Спасибо за ваш совет, я при необходимости, рассмотрю его.
А можете, пожалуйста, скинуть ссылку на правила "читаемости" моделей бизнес-процессов, на которые вы ссылаетесь?
Хороший фреймворк, с помощью него действительно проще повысить вероятность того, что продуктом будут пользоваться.
Скажите, по вашему опыту, как быть в такой ситуации:
ТЗ составлено очень подробно, но многие user stories конфликтуют между собой
ПМИ только по БП не согласовывают, нужно проверить выполнение всех требований, даже абсурдных
Частью БП заказчика управляют стейкхолдеры, которые напрямую не заинтересованы во внедрении
Я понимаю, что это скорее про проджект менеджмент. Но всё же, был ли у вас опыт решения подобных ситуаций?
Прошу прощения за долгий ответ.
В действительности нет какого волшебного средства, кроме как работать с требованиями и конфликтами требований. Тут главное проработать от кого идет требования и какие требования цепочкой зависят от него. Потом решать с владельцами требований. Если все застопорилось, то выносить на руководителя и собирать вече )
Потому что через бизнес-процессы лучше доходит