Форум Сообщества Аналитиков
Общий раздел => Теория моделирования и нотации => IDEF ARIS BPMN и пр. => Тема начата: Сергей Наумов от 03 Декабря 2008, 14:01:06
-
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
-
Посмотрите пжл диаграммку. Сделайте замечания.
-
Сергей
Ошибка по форме - у Вас message flow внутри одного пула, так не бывает. А прежде чем делать замечания по существу, необходимо знать что Вы хотели изобразить.
Прокомментируйте пожалуйста - что вы пытались смоделировать этой диаграммой?
-
Прокомментируйте пожалуйста - что вы пытались смоделировать этой диаграммой?
Действительно, поскольку пока процесс не очень сложный, восприятие его через текст вполне однозначно. Напишите небольшой рассказ на тему получения продукции у фирмы Ромашка неким клиентом
-
Прокомментируйте пожалуйста - что вы пытались смоделировать этой диаграммой?
Фирма ромашка - производственная фирма. Производит туфли на заказ.
Фирма состоит из трех подразделений:
Продажи
Производство
Закупки.
Общий процесс выглядит так:
Клиент размещает заказ на изготовление туфлей.
Менеджер принимает заказ и передает его в производственный цех.
Считаем что производственный цех обладает неограниченными ресурсами рабочей силы и сразу начинает выполнять заказ.
По мере того, как материалы заканчиваются производство заказывает необходимые материалы у отдела закупок, который в свою очередь заказывает их у поставщиков.
-
1. Процессы "от обращения до заказа" и "от заказа до оплаты" лучше сделать независимыми. Бывает ведь так, что клиент приходит сразу с готовым заказом? Бывает. Хотя бы поэтому надо разделить. То есть: "от обращения до заказа" - один пул, "от заказа до оплаты" - другой, сообщение между ними под названием "заказ" позволяет стартовать второй из первого.
2. В описанной Вами схеме "прием заказа" и "производство" - два последовательно исполняемых подпроцесса процесса "от заказа до оплаты". В реальной жизни это будут два асинхронных процесса.
3. У подпроцесса "производство" есть шаг "проверить запас сырья", за которым следует проверка "больше норматива?". Если нет, запускается сообщение, которое направляется в пул "приобретение сырья", соответствующий одноименному процессу. Работать до полного исчерпания запаса, а потом ждать пока пройдет закупка сырья - плохая идея. Почему "приобретение сырья" должно быть отдельным процессом - объяснять надо?
-
АБ,
Правильно ли я понял, что на диаграмме мы должны показать в виде ПУЛА внешние сущности и процессы?
-
Правильно ли я понял, что на диаграмме мы должны показать в виде ПУЛА внешние сущности и процессы?
Совершенно верно. На схеме осталось переименовать пулы. "Продажи", "Производство", "Закупки" - это дорожки.
-
ИМХО ценность такой диаграммы = 0. Это лучше тогда изобразить на Д Взаимодействия (Collaboration Digram) UML
-
ИМХО ценность такой диаграммы = 0.
Ценность такой диаграммы без диаграмм, раскрывающих внутренности процессов, действительно равна нулю. Но и ценность диаграмм с внутренностями без этой диаграммы, как показывают опыты Сергея, также близка к нулю.
Это лучше тогда изобразить на Д Взаимодействия (Collaboration Digram) UML
Это дело вкуса. Я иногда использую для этих целей DFD: не всегда (и даже не часто) процессы оказываются связаны событиями (сообщениями), иногда связь осуществляется по данным. Например, процесс обработки клиентских заказов постоянно подсыпает записи в таблицу производственных заказов, а процесс планирования производства периодически забирает из нее пачку накопившихся заказов. А DFD придуман как раз чтобы иллюстрировать связи по данным.
-
http://www.scienceforum.ru/2013/61/2495
-
http://www.scienceforum.ru/2013/61/2495
Это что? Реклама себя?