ViPRos,

Прикольно. :) Правда, я не совсем понял, что там делают разнообразные "скорости". В BPMN скорость событий определяется собственно самими событиями, которые по факту произошли и были зарегистрированы в системе.

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

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

То что касается описательной части в BPMN подразделяется на "оркестровку" и "хореографию". Возможность выстроить активити в некие последовательности - это "оркестровка", но ею всё не заканчивается. Потому что, очень важный нюанс, разные процессы исполняются в разных собственных ритмах. Если бы ритм для всех-всех-всех процессов был один и тот же, можно было бы обойтись и одной только оркестровкой. Но одна из фишек BPMN - это взаимодействие процессов, работающих в РАЗНЫХ ритмах. И эта фича имеет колоссальную важность, потому что в реальной жизни реальные процессы действительно имеют разные ритмы. В частности, процессы кадрового подразделения могут инициированы процедурами поиска кандидатов на разные должности (один экземпляр такого процесса - запуск в работу поиска конкретного кандидата на вакантное место), ритм работы которых никак не связан с ритмом, в частности, производства. Ритм производства, в свою очередь, может быть оптимизирован под ритмы работы смен и оборудования, а ритмы исполнения клиентских заказов определяться фактами поступления таких заказов. То есть, эти два процесса получаются работающими в связке, но при этом каждый в своем ритме. Процессы стратегического и тактического планирования могут вносить коррективы в работу процессов производства, с одной стороны опираясь на статистику имеющихся клиентских заказов, с другой стороны на данные по фактической загрузке ресурсов на производстве - и балансировать нагрузку добавляя заказы под прогнозный спрос. Но сам процесс анализа и формирования таких заказов тоже имеет собственный ритм, который определяется внутренними регламентами. Возможность увязать между собой груды разных процессов, работающих в разных ритмах - это очень важная фишка BPMN. Ведь это только кажется, что так легко увязать процессы, работающие в разных ритмах. Ну отправил один процесс "сигнал" в некую точку другого. А в этой точке может быть как десяток имеющихся экземпляров собственного процесса, так и ни одного - и вот этот "сигнал" должен как-то нормально отработать и в том, и в другом случае, а не только когда управляющее сообщение отправляется по принципу один_экземпляр-в-один_экземпляр. А может быть и еще "хитрее" - 5_экземлпляров-в-13_экземлпяров.

Очень важная фишка BPMN - возможность настройки rollback-ов. Длинные транзакции, в отличие от "коротких" (которые из концепции ACID) по умолчанию "безоткатные". Но ведь в любой реальной деятельности очень часто многое идет не так как бы этого хотелось или как было запланировано. Поэтому, ПМСМ, возможность настроить отдельное направление "что-то пошло не так" на любых фазах процесса таким образом, чтобы корректно происходила компенсация и завершение экземпляра процесса - это тоже, ПМСМ, очень важная компонента. Что особо важно, такие rollback-и получаются автоматически-корректными для вложенных друг в друга процессов и активити. Откат элементарной операции нижнего уровня может автоматически привести к откату еще 10 транзакций более высокого уровня, вложенных друг в друга, и при этом все они отработают в корректной последовательности АВТОМАТИЧЕСКИ, при этом у настройщика шаблона процесса нет необходимости пропускать через свой мозг все варианты взаимодействия процессов, вызывающих друг друга (вложенных друг в друга), возможности использования одного и того же подпроцесса разными материнскими процессами. И, что немаловажно, так же и при взаимодействии разных процессов, работающих в разных ритмах (взаимодействующих посредством "хореографии"). Если на текущем уровне процесса откаты всех ативити настроены, то откаты будут гарантировано работать корректно при любом числе вложенных процессов и любых взаимодействиях процессов между собой, и откаты будут транслироваться из одних процессов в другие и приводить одни процессы к завершению, другие к изменению траектории, на третьи могут не повлиять никак. Однако, если все вариации откатов попытаться "пропустить через мозг" и настроить их в явном виде, мозг, боюсь просто лопнет... :) А BPMN - нет. :)

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

Вообще, распараллеливание в BPMN - это такая особая технологическая фишка, ценность которой не осмыслена до конца даже многими из тех, кто ее придумал. Это принципиально новая технология распараллеливания процессов, которая позволяет распараллеливать "дофига чего", взаимодействующего самым сложным образом. Мьютексы, семафоры и прочие фишки многопоточного программирования просто отдыхают на фоне этой технологии. Она позволяет, в том числе, получить не "немножко-кое-где" распараллеленные вычисления а везде-где-только-возможно распараллеленные. И может применяться не только для управления бизнес-процессами, но и управления технологическими процессами, и процессами собственно вычислений (по сути, это разновидность технологического процесса). Для многоядерных компов эта технология, будучи реализованной на уровне ОС, может сотворить технологическую революцию. Разработчики ОС, к сожалению, об этом просто не в курсе.

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

GaryaВозможность выстроить последовательность разнообразных активити - вижу. Для "процессов" это важный аспект, но не единственный из важных. Особую ценность имеет возможность модифицировать шаблон уже работающего процесса таким образом, чтобы все исполняющиеся экземпляры процесса (которые, возможно, находятся на разных фазах исполнения) продолжили нормально исполняться и не "сломались", даже если часть из них находится на фазах "длинной транзакции", которые исключаются из очередной редакции шаблона процесса.Хочу особо подчеркнуть - это одна из ключевых "ценностей" ИТ-инструментария, ориентированного на целый ряд управленческих методологий. В частности, на управленческую концепцию кайдзен. На принципы постоянного и регулярной оптимизации процессов из SixSigma, в стандартах ISO 9000:2000, TQM и т.п.
"Кастомизация" - не предшествует "эксплуатации" ПО, как считалось прежде. Они просто "живут вместе", и при этом не должны друг другу мешать.

GaryaРаспараллеливание - еще одна важная фишка BPMN. Один экземпляр процесса может автоматически "размножиться" на множество экземпляров, исполняющихся асинхронно (по объектам, по исполнителям еще по чему-либо). Каждый из дочерних "размножившихся" при этом может оказаться на разных фазах исполнения, когда один из них завершит работу. "Размножившиеся" экземпляры потом могут быть собраны опять в один процесс (а могут и не собираться) - и тоже разными способами.Представьте себе - в языках программирования есть две модификации цикла FOR - FOR_последовательного_перебора (традиционный) и FOR_параллельный, для которого вычисления запускаются одновременно-параллельно, в каждом потоке вычисления с собственным значением переменной цикла. При этом в описательной части цикла указывается, выход из параллельного цикла FOR осуществляется при выполнении заданного условия одновременно для всех потоков вычислений и после завершения их всех, либо для одного любого из потоков, и тогда остальные потоки должны автоматически прерваться, если есть потребность, то с компенсацией... Представляете, какие можно вещи творить с помощью такого цикла?

ViPRosМодификация регламентных процессов - (для этого тоже нужны регламенты :)) была всегда и регламент их актуализации тоже (возьми хотя бы Гостовские понятия - Извещение об изменениях и вступление изменений в силу).:)
Я видел BPMS, в которой документирование изменений процессов производилась автоматически по мере внесения в процессы изменений. Согласование модификации процесса в соответствующих инстанциях и у руководителей также может быть реализовано в виде процесса. После того как новый релиз "отдеплоился", новые экземпляры процесса стартуют по шаблону нового релиза, а ранее запущенные по умолчанию продолжают исполняться по шаблону старого релиза. При этом "деплоинье" нового релиза не требует остановки работы системы и/или выгоняния из системы работающих в ней пользователей.
Автодокументирование изменений, в том числе, автоматически уведомляет всех исполнителей о внесенных в шаблон процесса изменениях. Кроме того, когда конкретный исполнитель получает какую-то конкретную задачу в рамках конкретного бизнес-процесса, он может открыть описание этого бизнес-процесса в формате вообще-регламента и в формате схемы BPMN, а также на схеме BPMN увидеть подсвеченную траекторию, по которой конкретная задача "свалилась" уже в рамках конкретного экземпляра процесса, и посмотреть, что когда и каким образом в этом экземпляре кто сделал до него (если ему это интересно). Таким образом, даже если пользователь "проспал" уведомление об изменении регламента, в котором ранее, например, не был задействован, а теперь стал задействован, то когда он получает конкретную задачу, он при ее получении может ткнуть мышкой во всё, что связано с регламентами и ознакомиться с ними.

ViPRosНикто процессы вручную (кроме жестких, невычислимых графов, где последовательность процессов указывается явно) не стыкует.В "хореографии" как раз стыкуют. Согласовывает "хореографию" то лицо, которое имеет соответствующий административный ресурс и может принимать решения в отношении процессов, участвующих во взаимодействии.
Для стыковки в процессы встраиваются специальные компоненты - "сигналы" и "сообщения", и соответствующие "обработчики событий" на факты получения "сигналов" и "сообщений". Они могут, в частности, передавать данные между процессами, например, собрать статистику по исполняющимся экземплярам, достигшим какой-то фазы процесса (или не достигшим) в другой процесс. Могут сделать так, что какой-то процесс будет "притормаживать" свои экземпляры на какой-то фазе до тех пор пока не получит "отмашку" от другого процесса. Ну и много других вариантов...

Однако, ты прав в том, что вся эта "хореография" связана с жестко формализованными регламентами.


ViPRosТут есть 2 основополагающих принципа генерации процессного графа для достижения цели:
1. Явные связи
2. Вычислимые связи

1. Используется тогда, когда потребность процесса Клиента невозможно вычислить, так как она не задана или задана не полностью
2. Это основной метод построения. Практически любой Процесс имеет определенную потребность, которая подпитывает его входы.
входы подпитываются Потоками, которые могут нести информационные, материальные, финансовые и.. потоки.BPMN позволяет реализовать инициирование (создание) экземпляра процесса в момент когда Клиент озвучил свою потребность. Либо "пропустить далее" какие-то экземпляры текущего процесса, если он это сделал или "откатить", если он этого не сделал, например, за определенный промежуток времени (для чего задействуется элемент "таймер"). В общем, возможности там весьма обширные.