1. Зачем нужно событие "Multiple start"
2. Зачем нужно промежуточное событие "Link Event"
3. Чем отличается конечное событие "Cancel end" и "Terminate end" от просто "END"?
4. Правильно ли я построил высокоуровневую модель бизнес процессов? Если нет - то как надо.

1. Зачем нужно событие "Multiple start"
Нуждо для того, чтобы сказать, что начало может "возбуждаться" с помощью Message и Timer и Rule

2. Зачем нужно промежуточное событие "Link Event"
Для возможности перехода между страницами например, см:
http://www.bpmn.org/Documents/OMG%20BPMN%20Tutorial.pdf

3. Чем отличается конечное событие "Cancel end" и "Terminate end" от просто "END"?
Просто конец - это нормальный конец, остальные же концы получаются в результате исключений (либо отмены либо ошибки)

4. Правильно ли я построил высокоуровневую модель бизнес процессов? Если нет - то как надо?
Нет. Вообще любая Д БПМН должна иметь начало и конец. От дорожки не может идти message flow.

Спасибо БАС! Как всегда развернуто и подробно:)
Но вот по пункту 4 остались вопросы.

>> От дорожки не может идти message flow.

Я изобразил не дорожку, а ПУЛ и согласно описанию нотации от пула прекрасно могут идти потоки сообщений.

Еще вопрос:
Если каждый процесс должен иметь начало и конец - тогда
как отобразить на диаграмме процессов верхнего уровня непрервный цикл производства?!

Я изобразил не дорожку, а ПУЛ и согласно описанию нотации от пула прекрасно могут идти потоки сообщений.

Ну тогда можно Просто до этого нигде такого не видел и не использовал

Еще вопрос:
Если каждый процесс должен иметь начало и конец - тогда
как отобразить на диаграмме процессов верхнего уровня непрервный цикл производства?!

Ну, во-первых, начало всегда есть - это создание фирмы. И как ни странно, конец тоже бывает ... хотя последнее вряд ли захотят увидеть вши Бизнес-эксперты Так что можно нанести и начало и конец и перед концом поставить условие - кирдык или не кирдык, если не кирдык, то идем на Продажу.
С другой стороны Продажа, Производство и Закупка - это 3 параллельных БП. Т.о. я бы предпочел их изобразить 3мя группами БП и в них уже расписывать сначала верхоуровневую ДБП, а потом уже детализированную Д каждого БП внутри группы БП. Т.е. получаем иерархию:
1. ГБП Продажа + ДБП Продажи
1.1. БП 11 + ДБП 11
1.2. БП 12 + ДБП 12
1.3. ...
2. ГБП Производства + ДБП Производства
2.1. БП 21 + ДБП 21
2.2. БП 22 + ДБП 22
2.3. ...
3. ....

> 3. Чем отличается конечное событие "Cancel end" и "Terminate end" от просто "END"?
> > Просто конец - это нормальный конец, остальные же концы получаются в результате исключений (либо отмены либо ошибки)

Дело не в том, в результате чего они получаются - дело в том какие последствия они вызывают:
- Cancel End вызовет соответствующий обработчик в вызывающем процессе. Кроме того, Cancel End - асинхронное событие.
- Compensation вызывает обработчики ко всем activity в рамках прерываемого процесса, для которых предусмотрен соответствующий обработчик.
- Terminate End принудительно завершает все потоки в данном процессе/подпроцессе. Если у вас до этого процесс распараллелился, то при обычном end-е одного из потоков другой будет продолжать исполнение, а при terminate он помрет.

Первые два представляют больше теоретический интерес, а третий - вполне рабочий event.

> 4. Правильно ли я построил высокоуровневую модель бизнес процессов? Если нет - то как надо?

Формально правильно, по существу - нет. Процессы столь выскокого уровня не бывают синхронными. Производство не ждет, пока отдел продаж что-то продаст, и не начинает работу после продажи. В реальности отдел продаж формирует производственные заказы и ждет их выполнения. Процесс производства с некоторой периодичностью сканирует заказы и выполняет их. То есть у вас должен быть не один, а несколько асинхронно исполняющихся и обменивающихся между собой сообщениями процессов. Общее правило: Уровень сквозного процесса моделируется не оркестровкой, а хореографией!

> > Нет. Вообще любая Д БПМН должна иметь начало и конец.

Неверно. Процесс может не иметь ни начала, ни конца. Не может иметь только начало или только конец.

> > От дорожки не может идти message flow.

Неверно. На рисунке изображена не "дорожка" (lane), а "бассейн" (pool). А от него / к нему только message flow и могут идти.

Бас,

>>С другой стороны Продажа, Производство и Закупка - это 3 параллельных БП. Т.о. я бы предпочел их изобразить 3мя группами БП и в них уже расписывать сначала >>верхоуровневую ДБП, а потом уже детализированную Д каждого БП внутри группы БП. Т.е. получаем иерархию:


Ну а почему бы не изобразить все три группы в виде ПУЛОВ ? Мне кажется так получается вполне наглядно. А внутри пулов мы уже можем изображаем процессы.
И еще вопрос. Есть в BPMN какие либо правила, регламентирующие правила переноса входящих потоков на процессы нижнего уровня. Например, если в задачу входит 3 потока сообщений - все три должны быть представлены на процессах, декомпозирующих задачу?

> 4. Правильно ли я построил высокоуровневую модель бизнес процессов? Если нет - то как надо?

Формально правильно, по существу - нет. Процессы столь выскокого уровня не бывают синхронными. Производство не ждет, пока отдел продаж что-то продаст, и не начинает работу после продажи. В реальности отдел продаж формирует производственные заказы и ждет их выполнения. Процесс производства с некоторой периодичностью сканирует заказы и выполняет их. То есть у вас должен быть не один, а несколько асинхронно исполняющихся и обменивающихся между собой сообщениями процессов. Общее правило: Уровень сквозного процесса моделируется не оркестровкой, а хореографией!

Спасибо за ответ.
Я извиняюсь за собственную тупость. Но не могли бы Вы пояснить фразу "Общее правило: Уровень сквозного процесса моделируется не оркестровкой, а хореографией!" ?

> Ну а почему бы не изобразить все три группы в виде ПУЛОВ ? Мне кажется так получается вполне наглядно. А внутри пулов мы уже можем изображаем процессы.

И в результате Вы получите ОДНУ диаграмму, содержащую ВСЕ процессы?

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

Естественно, потоки сообщений должны соответствовать друг другу, но надеяться на то, что инструментарий будет аккуратно это контролировать, я бы не стал.

Определения (вольные):
- Оркестровкой называется координация исполнения шагов в рамках одного процесса, выполняемая при помощи control flow.
- Хореографией называется координация асинхронного исполнения нескольких процессов, выполняемая при помощи message flow.
- Сквозным бизнес-процессом называется процесс, начинающийся и заканчивающийся на внешнем заказчике и проходящий через несколько служб предприятия. Примеры: 'product-to-lead', 'lead-to-order', 'order-to-cash'.

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

Анатолий немного повторил, что я написал вторым письмом

Неверно. Процесс может не иметь ни начала, ни конца. Не может иметь только начало или только конец.

Энто как? Можно пример.

Энто как? Можно пример.

Насколько я помню, шаг не имеющий входного control flow считается start, не имеющий выходного - end. Так по спецификации, но естественно best practice все-таки явно рисовать start и end.

Еще один, экзотический вариант - подпроцесс, в который как в мешок накиданы несколько шагов, вообще не соединенные control flow, без start и end. Так в BPMN моделируется (убого, конечно) ad-hoc процесс.

О последнем я уже подумал после того как написал

Все мои познания в BPMN почерпнуты из тренинга Брюса Силвера. Уже кидал ссылку на слегка урезанный, но годный конспект его тренинга. Видимо невредно повторить:
https://wiki.sdn.sap.com/wiki/display/BPX/Process+Modeling+with+BPMN+-+Article+Series

Посмотрите пжл диаграммку. Сделайте замечания.