Когда представляешь процесс тому, кто не знает, что такое BPMN (топы разных компаний очень часто), то дорожки рулят. Объясню. Если выделять цветами, то нужно делать отдельную секцию с расшифровкой какой цвет какую роль означает. Глаза в итоге бегают с этой отдельной секции на процесс и восприятие снижается. Опыт говорит, что для презентации дорожки пока лучше.
На мой взгляд все равно у дорожек есть своя, хоть и узка область применения. Дорожки полезны в случае, когда 1) кол-во участников значительно меньше кол-ва моментов смены исполнителя 2) имеется много параллельных процессов (например, при согласовании), т.е. визуально все равно элементы будут расположены с нормальным заполнением свободного места Что касается подкрашивания - считаю, что это полезно, но опять же - когда участников не так много. Если их становится больше, чем различимых цветов, то ни дорожки, ни цвета уже не помогают - и здесь мы приходит к необходимости расширения нотации - указания ресурсов в виде текста на схеме в определенной единообразной позиции. Сам раньше был против дорожек - еще когда их люди пытались воткнуть даже в EPC. КМК, в идеале первична должна быть модель, а не представление. В этом плане подход того же Archimate с принципом nested-элементов позволяет не меняя модели для каждого случая выбирать наиболее удобное представление (с дорожками, с выносками с стиле EPC, доп. блоками в каждом шаге процесса)
Новые видео от Дениса - и можно жить!) Предложение: сними видос по своей же статье о сравнении FSM и Petri Nets, хм? А то статья хоть и гуд, но все равно непонятно ничего 😅
Это когда автор диаграммы специально на горизонтальной линии располагает самый ожидаемый и очевидный путь развития процесса, "счастливый путь". Очень сильно улучшает пнимаемость процессов
А как решить этот вопрос если диаграмма будет передаваться в ЧБ? Как бы выделять оттенками серого как мне кажется не комильфо, в таком случае, наверное только если иконки делать, но и тут вопрос к читаемости. У меня были случаи когда на экране нет возможности показать и цветная печать не доступна
Дорожки зло! Я часто в текст действия/задачи исполнителя вписываю, например «Инициатор отправляет заявку на согласование», «Сервис проверяет доступность дат», «Руководитель инициатора проверяет заявку» и т.д. Потом и раскрасить можно. Но в раскраске плохо то, что при пяти и более ролях схема пестрая становится.
@@BPMN2ru а расскажи пожалуйста как делать табличное описание процесса. Ведь к схеме прилагается табличка в которой указывается текстовое описание (более подробное чем на схеме). Что в эту таблицу писать нужно: действия, шлюзы, условия? Например условие (ромб) в такой таблице нужно описывать или нет? То же самое с шлюзами И ИЛИ и тд. Какие есть лучшие практики такого описания?
@@BPMN2ru в 4х компаниях в которых я работал к схеме процесса прикладывалась табличка с полями: номер шага процесса, название шага процесса, описание шага процесса. Далее в зависимости от компании были столбцы: входы и выходы процесса, регламентный срок выполнения процесса, название системы в которой выполняются действия и т.д. В итоге в столбце описание я просто более подробно расписывал процесс. Например шаг процесса «проверка и согласование», а в столбце описание был текст: руководитель открывает заявку, проверяет вот эту часть по таким параметрам. Если проверка прошла, то переходим к блоку ХХХ, если роверка не прошла, то переходим к блоку УУУ.». И т.д. Не все пользователи схемы процесса умеют читать ))
Лейны вообще надо запрещать без сертификации какой-то 😅, потому что «бизнес-аналитики» усложняют схемы потому что это «круто». Мы собеседуем 1300 чел ежемесячно и классический паттерн, особенно из «серьезных» компаний - усложнить, сделать кучу квадратиков. А еще много умных бессмысленных слов в кейсах.
@@BPMN2ru Денис, добрый день. По вашим урокам научился bpmn для своих нужд коммуникации в компании(я не аналитик). Благодарю вас! Вопрос по вышиванке из Минска - это какое-то послание к аудитории или просто развлекательный антураж для видео ряда?
Когда представляешь процесс тому, кто не знает, что такое BPMN (топы разных компаний очень часто), то дорожки рулят. Объясню. Если выделять цветами, то нужно делать отдельную секцию с расшифровкой какой цвет какую роль означает. Глаза в итоге бегают с этой отдельной секции на процесс и восприятие снижается. Опыт говорит, что для презентации дорожки пока лучше.
Я против :)
На мой взгляд все равно у дорожек есть своя, хоть и узка область применения.
Дорожки полезны в случае, когда
1) кол-во участников значительно меньше кол-ва моментов смены исполнителя
2) имеется много параллельных процессов (например, при согласовании), т.е. визуально все равно элементы будут расположены с нормальным заполнением свободного места
Что касается подкрашивания - считаю, что это полезно, но опять же - когда участников не так много. Если их становится больше, чем различимых цветов, то ни дорожки, ни цвета уже не помогают - и здесь мы приходит к необходимости расширения нотации - указания ресурсов в виде текста на схеме в определенной единообразной позиции.
Сам раньше был против дорожек - еще когда их люди пытались воткнуть даже в EPC.
КМК, в идеале первична должна быть модель, а не представление. В этом плане подход того же Archimate с принципом nested-элементов позволяет не меняя модели для каждого случая выбирать наиболее удобное представление (с дорожками, с выносками с стиле EPC, доп. блоками в каждом шаге процесса)
О! Вышиванка! Респект💙
Как вариант - исполнители в ресурсах, а дорожки, например, для указания систем, в которых происходит работа.
Всегда делал дорожки. Буду исправляться
Похожее есть в Business Studio, допустим, дорожка одна - отдел, а в свойствах каждой задачи указывается отдельно исполнитель.
Новые видео от Дениса - и можно жить!)
Предложение: сними видос по своей же статье о сравнении FSM и Petri Nets, хм? А то статья хоть и гуд, но все равно непонятно ничего 😅
Я наверное где-то пропустил, но что такое "happy path" (мне так послышалось)?
Это когда автор диаграммы специально на горизонтальной линии располагает самый ожидаемый и очевидный путь развития процесса, "счастливый путь". Очень сильно улучшает пнимаемость процессов
@@BPMN2ru, каким образом это обозначается?
Красиво
Очень хочу подробный ролик как прописывать роли в специально предоставленном функционале по пункту 8.3.12
Спасибо.
Здравствуйте! Для чего тогда использовать дорожки?
Не нужно их вообще использовать
А как решить этот вопрос если диаграмма будет передаваться в ЧБ?
Как бы выделять оттенками серого как мне кажется не комильфо, в таком случае, наверное только если иконки делать, но и тут вопрос к читаемости.
У меня были случаи когда на экране нет возможности показать и цветная печать не доступна
Думаю для такого как раз справедливо дорожки, но я бы ещё на группы посмотрел
Как указать в одном таксе несколько исполнителей?
Никак, это противоречит процессному подходу
тогда закономерный вопрос - как все - таки использовать дорожки. вернее, как Вы их используете
Никак
Привет. А зачем ты отключил функционал данный в своём сервисе?
Теперь у тебя нельзя в сервисе указать роль
Он только для команд, создай команду
Рубаха чёткая!
Дорожки зло! Я часто в текст действия/задачи исполнителя вписываю, например «Инициатор отправляет заявку на согласование», «Сервис проверяет доступность дат», «Руководитель инициатора проверяет заявку» и т.д. Потом и раскрасить можно. Но в раскраске плохо то, что при пяти и более ролях схема пестрая становится.
Согласен про расскрастку. Ещё не рассказал про вариант с группами, но это потом уже как нибудь)
@@BPMN2ru а расскажи пожалуйста как делать табличное описание процесса. Ведь к схеме прилагается табличка в которой указывается текстовое описание (более подробное чем на схеме). Что в эту таблицу писать нужно: действия, шлюзы, условия? Например условие (ромб) в такой таблице нужно описывать или нет? То же самое с шлюзами И ИЛИ и тд. Какие есть лучшие практики такого описания?
@@dimke откуда ты взял про табличку? Вот тут есть на эту тему соображения ua-cam.com/video/T6w12Sjl-mU/v-deo.html
@@BPMN2ru в 4х компаниях в которых я работал к схеме процесса прикладывалась табличка с полями: номер шага процесса, название шага процесса, описание шага процесса. Далее в зависимости от компании были столбцы: входы и выходы процесса, регламентный срок выполнения процесса, название системы в которой выполняются действия и т.д.
В итоге в столбце описание я просто более подробно расписывал процесс. Например шаг процесса «проверка и согласование», а в столбце описание был текст: руководитель открывает заявку, проверяет вот эту часть по таким параметрам. Если проверка прошла, то переходим к блоку ХХХ, если роверка не прошла, то переходим к блоку УУУ.». И т.д.
Не все пользователи схемы процесса умеют читать ))
@@dimke я такого не видел, но звучит логично :)
Так, ладно, задам я…А почему за 9 минут?)))
Да хз, предыдущее вышло около 9 минут, поэтому и серию решил так назвать
Лейны вообще надо запрещать без сертификации какой-то 😅, потому что «бизнес-аналитики» усложняют схемы потому что это «круто». Мы собеседуем 1300 чел ежемесячно и классический паттерн, особенно из «серьезных» компаний - усложнить, сделать кучу квадратиков. А еще много умных бессмысленных слов в кейсах.
тут наверно как в анекдоте или моск. конфу не рекламировать или вышиванку снять
Ну шот прям за уши притянули. Вышиванка из Минска
@@BPMN2ru Денис, добрый день. По вашим урокам научился bpmn для своих нужд коммуникации в компании(я не аналитик). Благодарю вас! Вопрос по вышиванке из Минска - это какое-то послание к аудитории или просто развлекательный антураж для видео ряда?
@@pavelandreev6023 в этот день был день вышиванки, отмечал. Я родом недалеко от тех мест, где принято такую одежду носить.
tl;dr дорожки для лохов, ровные пацаны роли цветом выделяют
День вишиванки на росії ? Ви не безнадійні.
Все рисую с дорожками в бизнес студио, все все прекрасно понимают...процессы, где много участников надо декомпозировать