Это уже происходит в некоторых отраслях - например производство карбона: заказчик выкупает у производителя 1 линию на 10 лет, чтобы обеспечить постоянство качества и непрерывность поставки в необходимых объемах

Here is my vision of templates and patterns: http://mainthing.ru/item/292/ Please also pay attention to the comments.

If I was going to present a BPMN diagram for a specific task e.g. accounts payable then it’d be a template. A pattern is something more generic, like resource planning in the post above. Whatever resources one is dealing with - machine, production line, budget, manager’s time etc. - he/she would hopefully find presented diagrams useful. Hence they are patterns for me, not templates.

Regarding template reuse - I believe Scott Francis answered your question at http://www.bp-3.com/blogs/2010/11/design-patterns-in-bpm-lost-cause/ “Of course, many people misunderstand the point of patterns. They wonder why there is still so much work to do! But patterns are not libraries of code – they’re patterns of design and code. Its like knowing how to tie a square knot. Although you know the pattern, you still have to tie the knot each time you want to use it. Design patterns are much the same way.”

Kind regards
Anatoly

Why you call patterns when these are templates?

What do you suggest to provide some persistence in order to template reuse?

Regards

Alberto.

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

Производственные компании пока еще не продают клиентам свои мощности так же, как авиакомпании кресла или кинозал билеты. Хотя в принципе могли бы. Кстати, интересная мысль. Но достаточно революционная.

И с комфортностью не так однозначно: улыбаются не все, а именно что исполнители. Для пассажира комфортнее такси, которое везет когда надо пассажиру, а не по расписанию. Об этом подробнее в заключительной статье http://mainthing.ru/ru/item/417/

Спасибо за комментарий.

“Выполнить платеж” я сделал автоматической задачей (service task), предполагая, что у нас есть какая-то система клиент-банк, в которую мы отправляем заявки на платеж, успешно прошедшие через наш процесс. Как там дальше эта система работает - с участием оператора или автоматически отправляет поручения в банк - это уже не наше дело. Но можно было изобразить и ручную задачу, для данного примера это не принципиально.

Понятно желание Андрея Гордиенко решить задачу под названием “раздача заданий” универсальным способом, но это не из реальной жизни, в этой задаче слишком много параметров, причем слишком разных для каждой группы процессов.

Note I say above “if that is possible”. The usual case when it is not possible is when there is not a 1:1 correspondence of the instances of the “subprocesses” and make the subprocess a loop or MI does not work. Maybe this is what you mean by “different rhythms”. I think my formulation regarding what the instance represents is more precise, although admittedly it is a concept some business people may have trouble with at first. But, if a modeler can’t understand what a process instance means, maybe that person should not be doing BPMN.

Re “fixing” the business about pools and participants in the spec, no that will never happen. It was not accidental. I filed more than one JIRA bug against it in the drafting, and the dark forces of the “participant” view just ignored them. There is much that is counterproductive in the spec, and this is just one example. Anyway, BPMN 2.0 is finished, the team is exhausted, and I would not expect a revision anytime soon.

Keep up the good work, Very few people are writing about how to use BPMN correctly, and I applaud you for it.

Nothing to sorry, process design is a creative work yet, so each person may have his/her own style. Actually I am surprised with your interpretation of my post about the FRAP process pattern. This post demonstrates that the popular association between pool and participant is NOT correct.

Thanks,
AS