Вопрос на самом деле не праздный.

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

IDEF0 (или SADT), IDEF3, DFD, eEPC, VAC

Кроме того для этой цели вполне сгодятся, например:

обычные блок-схемы, диаграммы деятельности и последовательности UML.

История возникновения тех или иных графических нотация весьма поучительно, но ... остановимся на BPMN.

BPMN возник не так давно, в 2005 году. На Википедии сказано достаточно ясно:

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

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

BPMN определяет набор правил, однако стоит ли строго следовать этому набору нетехническим специалистам?

К чему это я? Насколько строго бизнес-аналитикам следует следовать правилам нотации? И каковы эти правила, если учесть тот факт, что нотация будет использоваться только для отображения бизнес-процессов, и никогда, как модель, отображаемая в исполняемый код BPEL.

Т.е. стоит ли строго следовать правилам - где message flow, а где control flow?

Что лучше использовать pool или lane для отображения участников процесса (сотрудников, отделы, службы, системы)?

Существует ли набор ясных, определенных и однозначных правил и рекомендаций, как следует использовать BPMN именно бизнес-аналитикам?

Вопрос на самом деле не праздный.

Мало сказать не праздный - вопрос назревший и перезревший.

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

Начнем с того, что BPMN, строго говоря, уже больше не нотация. Точнее, не только нотация. Начиная с версии 2.0, BPMN расшифровывается не как "business process modeling notation", а как "business process modeling AND notation". Несколько другой коленкор.

Далее, BPMN - вещь, которая принципиально (по построению) имеет не одно, а множество разных назначений. Трансляция в BPEL - далеко не единственное, и даже не главное, хотя большие вендоры ("банда трех": IBM, Oracle, SAP) и пытается в этом всех убедить. Википедия в данном случае права, да и спецификация тоже достаточно определенно это говорит.

BPMN определяет набор правил, однако стоит ли строго следовать этому набору нетехническим специалистам?

Проблема BPMN скорее не в избытке, а в недостатке правил. (Это следствие отмеченной выше многоплановости.) Чтобы эффективно им пользоваться, необходимо выработать для себя (для организации) определенный стиль: какими конструкциями пользуемся, какими нет.

Т.е. стоит ли строго следовать правилам - где message flow, а где control flow?

"Счастье - это когда тебя понимают". Исходя из этого не стоит использовать, скажем, сообщения внутри одного пула.

Что лучше использовать pool или lane для отображения участников процесса (сотрудников, отделы, службы, системы)?

А вот это - дело вкуса или избранного стиля моделирования. Право на жизнь могут иметь разные стили (естественно, при условии непротиворечия стандарту и внутренней логичности). Я лично использую дорожки для отображения участников и пулы для отображения процессов. Могу объяснить почему именно так, но не в формате комментария на форуме, извините.

Существует ли набор ясных, определенных и однозначных правил и рекомендаций, как следует использовать BPMN именно бизнес-аналитикам?

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

В сентябре 2010 я, Анатолий Белайчук, планирую провести в Москве тренинг по теории и практике использования BPMN.

Планируется, что тренинг будет состоять из двух частей.

• Первая часть - начальная: изучение нотации, типовых паттернов, моделирование простеньких учебных задач. Тестирование, сертификация.
• Вторая часть - углубленная: моделирование задачи из реальной практики преподавателя или (предпочтительно) студента (типа курсовой работы). Сертификация.

Продолжительность каждой части - один день, причем не подряд. Скажем, в одну субботу начальный курс, в следующую - углубленный. (Можно ограничиться только первым, но на второй без успешного прохождения первого записаться нельзя.)

Тренинг будет платным. Сумму пока назвать не готов, извините. Но члены Сообщества аналитиков получат скидку.

Особую скидку получат те, кто угадают инструмент, который будет использоваться в тренинге. Ответы давать тут. (Естественно, не больше одного ответа от одного участника.) Срок - неделя, т.е. до 24:00 субботы 10 июня. В воскресенье узнаем победителей.

Интересное предложение, попробую поиграть.

Рискну предположить -  BizAgi

Срок - неделя, т.е. до 24:00 субботы 10 июня. В воскресенье узнаем победителей.

Анатолий, живем вчерашним днем?

Анатолий, живем вчерашним днем?

Как всегда, лето проходит слишком быстро.

А вот как бы нам втянуть в эту дискуссию Ирину Иванову, которая на семинаре в Киеве рассказывала про нотацию BPMN?

Материалов по BPMN в интернете полно. Доклады, статьи, книги, онлайновые тренинги - что угодно. Но несмотря на это изобилие, уровень грамотности в этой области остается очень низким. Что там далеко ходить - даже BPMS-вендоры делают такие ляпы, что диву даешься.

Причин, на мой взгляд, две: во-первых, необходима практика. Не просто изучение элементов, но и того, как и где их применять. Сначала на задачках из учебника, потом на задачках из жизни. Нужны не презентации и лекции, а лабораторки и курсовики по BPMN.

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

Ранее, я ответил очень кратко. Я понимаю, что Вы, Анатолий, призываете нас принять учатстие в семинаре-тренинге.
Но не надейтесь, так просто отделаться:)

Пытать, конечно, не буду, но все-таки хотелось получить Ваше мнение, и мнение других по этому вопросу.

Начнем с того, что BPMN, строго говоря, уже больше не нотация. Точнее, не только нотация. Начиная с версии 2.0, BPMN расшифровывается не как "business process modeling notation", а как "business process modeling AND notation". Несколько другой коленкор.

А в чем нюанс? Нотация как я понимаю определяет правила представления информации, а моделирование предполагает что? Правила построения моделей? А чем одно отличается от другого? Строгостью параметризации и формализации?

Далее, BPMN - вещь, которая принципиально (по построению) имеет не одно, а множество разных назначений. Трансляция в BPEL - далеко не единственное, и даже не главное, хотя большие вендоры ("банда трех": IBM, Oracle, SAP) и пытается в этом всех убедить. Википедия в данном случае права, да и спецификация тоже достаточно определенно это говорит.

Ну мне известно как минимум два, а какие есть еще?

Проблема BPMN скорее не в избытке, а в недостатке правил. (Это следствие отмеченной выше многоплановости.) Чтобы эффективно им пользоваться, необходимо выработать для себя (для организации) определенный стиль: какими конструкциями пользуемся, какими нет.

Да, но есть ведь стандарт, все-таки гибкость, гибкостью, но не в разрез понятности и отчуждаемости?

"Счастье - это когда тебя понимают". Исходя из этого не стоит использовать, скажем, сообщения внутри одного пула.

Вот вот, как раз в этом самом и дело. Нет, конечно, приведенный Вами пример, не используется, но я, например, часто вижу такие модели: есть несколько участников процесса, которые разделены по пулам. Так вот, зная, что между пулами возможны только сообщения - автор диаграммы делает так - он описывает некоторую последовательность действий, рисует события и задачи, но вся это последовательность соединяется сообщениями, управляющий поток только по пулам, при этом у одного участника может быть начальное событие и одна задача, далее идет сообщение другому пулу, где это сообщение входит в другую задачу, далее может идти парочка задач внутри этого пула, потом сообщением управление возвращается первому пулу, там чудесным образом возникает точка принятия решения или новая задача, т.е. вся последовательность процесса распеделена по разным пулам и соединяется между оными сообщениями(пунктирными линиями). Автор говорит - мы так понимаем и нам так нравится - Это нормально?

А вот это - дело вкуса или избранного стиля моделирования. Право на жизнь могут иметь разные стили (естественно, при условии непротиворечия стандарту и внутренней логичности). Я лично использую дорожки для отображения участников и пулы для отображения процессов. Могу объяснить почему именно так, но не в формате комментария на форуме, извините.

А какой формат Вам  подойдет? Что я должен предпринять? Переписка? Скайп?

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

Если какие-то артефакты этого автора для изучения?

Спасибо

Ранее, я ответил очень кратко. Я понимаю, что Вы, Анатолий, призываете нас принять учатстие в семинаре-тренинге.
Но не надейтесь, так просто отделаться:)

Ну как призываю... Дело сугубо добровольное. Я пытаюсь убедить, что в этом предмете невозможно профессионально разобраться, не потратив существенное время (и деньги) на полноценный тренинг.

Пытать, конечно, не буду, но все-таки хотелось получить Ваше мнение, и мнение других по этому вопросу.
А в чем нюанс? Нотация как я понимаю определяет правила представления информации, а моделирование предполагает что? Правила построения моделей? А чем одно отличается от другого? Строгостью параметризации и формализации?

Вот что значит постить на форум заполночь :-o Если быть совсем точным, то "Business Process Model and Notation". Суть дела в том, что раньше специфицировалась только нотация, понимаемая как значки и правила их комбинирования, теперь в дополнение к этому - структура модели, которая стоит за этими значками.

Ну мне известно как минимум два, а какие есть еще?

Примеры использования BPMN -

• High-level non-executable Process Activities (not functional breakdown)
• Detailed executable Business Process
• As-is or old Business Process
• To-be or new Business Process
• A description of expected behavior between two (2) or more business Participants—a Choreography.
• Detailed private Business Process (either executable or non-executable) with interactions to one or more external
Entities (or “Black Box” Processes)
• Two or more detailed executable Processes interacting
• Detailed executable Business Process relationship to a Choreography
• Two or more public Processes
• Public Process relationship to Choreography
• Two or more detailed executable Business Processes interacting through a Choreography

Вот вот, как раз в этом самом и дело. Нет, конечно, приведенный Вами пример, не используется, но я, например, часто вижу такие модели: есть несколько участников процесса, которые разделены по пулам. Так вот, зная, что между пулами возможны только сообщения - автор диаграммы делает так - он описывает некоторую последовательность действий, рисует события и задачи, но вся это последовательность соединяется сообщениями, управляющий поток только по пулам, при этом у одного участника может быть начальное событие и одна задача, далее идет сообщение другому пулу, где это сообщение входит в другую задачу, далее может идти парочка задач внутри этого пула, потом сообщением управление возвращается первому пулу, там чудесным образом возникает точка принятия решения или новая задача, т.е. вся последовательность процесса распеделена по разным пулам и соединяется между оными сообщениями(пунктирными линиями). Автор говорит - мы так понимаем и нам так нравится - Это нормально?

Что значит "нормально"? Это корректно с точки зрения стандарта. Всего лишь нерационально с чьей-то точки зрения. Но если человек привык пользоваться инструментом, который только так и позволяет моделировать процесс (не будем указывать пальцем), то кто ему указ? Ему можно только посоветовать расширить кругозор и сравнить, потому что скорее всего, он просто не представляет как можно моделировать по-другому.

А какой формат Вам  подойдет? Что я должен предпринять? Переписка? Скайп?

Я сказал какой формат мне подойдет: мне нужно день (лучше два) полноценного общения в аудитории. Я собираюсь излагать цельную концепцию использования BPMN. Конкретную, предметную, практичную. В переписке я могу ответить на конкретный вопрос (и отвечаю, Вы знаете), но это не спасает положение.

Если какие-то артефакты этого автора для изучения?

Есть, Гугл Вам в помощь.

Спасибо

Пока не за что.

Что значит "нормально"? Это корректно с точки зрения стандарта. Всего лишь нерационально с чьей-то точки зрения. Но если человек привык пользоваться инструментом, который только так и позволяет моделировать процесс (не будем указывать пальцем), то кто ему указ? Ему можно только посоветовать расширить кругозор и сравнить, потому что скорее всего, он просто не представляет как можно моделировать по-другому.

Понимаете, если Вы мне нарисуете в IDEF0 блок без управления - я как рецензент отмечу это как ошибка (ошибка нотации, смысловая ошибка)

Вы, конечно, можете приписать где-то, что это не IDEF0 - а просто я использую инструмент.

С другой стороны, вы - студент и вас обучали BPMN и, надеюсь, правильно. Правильно, это значит, не противореча стандарту. Вы приходите в отрасль и вдруг видите, что нотация используется неправильно с вашей точки зрения (ситуация правда может быть и обратной).

Где они - критерии?

Понимаете, если Вы мне нарисуете в IDEF0 блок без управления - я как рецензент отмечу это как ошибка (ошибка нотации, смысловая ошибка)

Ну это ошибка аналогичная потоку сообщений внутри одного пула. Ловится что тут, что там.

С другой стороны, вы - студент и вас обучали BPMN и, надеюсь, правильно. Правильно, это значит, не противореча стандарту.

Вот что значит "обучали BPMN"? Рассказывали какие в нем есть ромбики-кружочки? Толку-то от такого обучения? Вы лично что имели в виду под "моделировать правильно", когда инициировали эту дискуссию - "формально правильно"? Или правильно в смысле "с пользой для дела"? Это не одно и то же.

Я лично собираюсь обучать не ромбиков-кружочков (от их количества реально свихнуться можно), а тому, как при помощи BPMN выявлять процессы, производить их декомпозицию, моделировать их с прицелом на исполнение (вообще говоря, не прибегая к трансляции в BPEL), какими паттернами пользоваться и какими анти-паттернами не пользоваться... Студент должен знать что он может делать при помощи BPMN, а если забыл какой вариант кружочка ему нужен - не грех и в шпаргалку заглянуть.

Вы приходите в отрасль и вдруг видите, что нотация используется неправильно с вашей точки зрения (ситуация правда может быть и обратной). Где они - критерии?

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

Вот что значит "обучали BPMN"? Рассказывали какие в нем есть ромбики-кружочки? Толку-то от такого обучения? Вы лично что имели в виду под "моделировать правильно", когда инициировали эту дискуссию - "формально правильно"? Или правильно в смысле "с пользой для дела"? Это не одно и то же.

Я бы хотел оттолкнуться о "формально правильно" и перейти к "с пользой для дела". Поскольку часто то, что "неформально неправильно" - имеет пользу только для того кто рисует.

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

Конечно, синтаксису в первую очередь. Семантике так просто не научишь. Но это тоже самое, если учить английский и потом игнорировать порядок слов и лепить все как придется. Человек думает, что передает семантику, а реально double Dutch.

Мне кажется одно без другого не существует, одно определяет форму представление, другое содержание.

Я вовсе не призываю использовать все "красивости", должен быть минимальный набор и точный смысл использования элементов.

Я лично собираюсь обучать не ромбиков-кружочков (от их количества реально свихнуться можно), а тому, как при помощи BPMN выявлять процессы, производить их декомпозицию, моделировать их с прицелом на исполнение (вообще говоря, не прибегая к трансляции в BPEL), какими паттернами пользоваться и какими анти-паттернами не пользоваться... Студент должен знать что он может делать при помощи BPMN, а если забыл какой вариант кружочка ему нужен - не грех и в шпаргалку заглянуть.

Прекрасно, я не думаю, что кому-то нужно знать, как эти кружочку рисовать. Важно знать когда, почему и как...

Навеяло:

Пить можно всем.
Необходимо только
знать где и с кем.
За что, когда и сколько.

Попытка №2. Process Modeler for Microsoft Visio by itp commerce. В принципе это было у меня в голове также.

Попытка №2. Process Modeler for Microsoft Visio by itp commerce. В принципе это было у меня в голове также.

Один игрок - один вариант ответа!