Dikobraz GreyУважаемые форумчане, я попытался разграничить для себя понятия BPM системы и WorkFlow системы, но так и не смог определить четкой границы. Термин "workflow" неоднозначен: есть т.н. "traditional workflow" образца 1990-х (пример: Lotus Notes), а есть "BPM workflow", он же "human-oriented BPM", он же "pure-play BPM". От традиционного отличается, как уже было указано в комментариях, поддержкой замкнутого цикла (графическое моделирование - исполнение - анализ), поддержкой стандартов (BPMN/XPDL), системным подходом к интеграции (на основе SOA). ( Возвращаясь к теме roundtrip )

Dikobraz GreyНасколько я понимаю BPM система включает в себя WorkFlow систему(в том или ином виде). При этом мне встретилось утверждение об идентичности WorkFlow и BPM систем при условии, что в BPM "больше внимания уделяется автоматически выполняемым шагам бизнес-процесса и мониторингу бизнес-процессов". Хотелось бы услышать ваше мнение о разнице между BPM и WorkFlow системами или услышать чёткое определение (если оно существует) каждой и них. Workflow, даже в современном BPM-варианте, сам по себе способен решать только ограниченные задачи типа заключения договора, обработки заявления на выдачу кредита и т.п. Ограниченность workflow в том, что он ориентирован на синхронное, последовательное исполнение шагов: делай раз - делай два. Беда в том, что жизнь устроена сложнее. ( Почему Workflow «не тянет» )

BPM ориентирован на задачи более амбициозные: BPM - это средство реализации процессного подхода, и в качестве такового обязан автоматизировать сквозные бизнес-процессы типа "от заказа до оплаты". Если же пристально взглянуть на такой процесс, то увидим, что он распадается на ряд workflow-подпроцессов, которые взаимодействуют друг с другом достаточно нетривиальным образом: асинхронно, с обменом сообщениями, с порождением нескольких подпроцессов и ожиданием их завершения и т.д. Например, если мы - завод, то за заказом клиента следует не изготовление, а заказ производству. Производство, следуя собственному ритму, собирает все накопившиеся заказы, планирует и изготавливает требуемое. Для решения задачи координации асинхронно исполняемых подпроцессов workflow подходит плохо. Зато хорошо подходит другая ипостась BPM - system-to-system. ( Семь заблуждений из области исполнения бизнес-процессов )

Резюмирую: BPM включает worflow, но это только половина решения задачи управления процессами. Вторая половина - system-to-system BPM, который удачно дополняет возможности традиционного workflow. Human + System BPM вместе позволяют решать задачи принципиально более актуальные с точки зрения бизнеса: не "автоматизировать канцелярию", а управлять сквозным бизнес-процессом, начинающимся и заканчивающимся на клиенте.

Dikobraz GreyТакже просьба поделиться информацией о статьях по развитию WorkFlow (не BPM) систем. Ну какое у них может быть развитие? Примерно такое, как у навигационных СУБД после появления на рынке реляционных: все срочно прилепили себе лэйбл "BPM".

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

С этого места можно подробнее?

GaryaДля технологического процесса требуется точность синхронизации, обеспечивающая, например, подставку поддона под падающую в него деталь. И способность обрабатывать отклики в реальном времени. BPM-системы такую синхронность обеспечить не могут.

Да ладно. Обеспечить биржевую торговлю с временем отклика в миллисекунды может, а падение детали не может... Было бы желание.

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

ViPRosАБ,
т.е. такие вещи спокойно можно реализвать на BPMS какой нить?

В принципе можно и медведя на велосипеде научить ездить. Для более квалифицированного ответа информации маловато. Нужно представлять себе не только что это за процесс, но и чего мы хотим добиться, реализуя его в BPMS.

ViPRosпостроить оптимальную сеть процессов
пришел заказ, нажали на кнопку и получили - что купить, скоко купить, где купить, кто перевезет, куда перевезет, скоко надо бабок что бы оплатить у кого купить и кто перевезет, где их брать, когда брать, когда платить, как делать, где делать, кому делать, когда делать,.....
Ну так это классика, под такие вещи в основном и заточено.

ViPRosну покажи для одной детали :)
это ж важно

Да пожалуйста: http://www.youtube.com/watch?v=YOBj4Y4ofDE

ViPRosАБ,
смотрю блин честно
пка что кроме визуального программирования нифига не вижу

BPMS = визуальное моделирование процессов
+ визуальное моделирование данных
+ визуальное программирование форм
+ бизнес-правила
+ оргструктура
+ процессный движок
+ мониторинг и аналитика
+ интерфейсы SOA

Ну да, первые пять пунктов при желании можно назвать визуальным программированием.
Только я не понял почему Вы так об этом говорите, как будто это что-то плохое :)

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

ViPRosАБ,

потому что визуальное программирование подход для простых вещей

А что, разве принцип keep simple things simple кто-то отменял?

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

Во втором мастер-классе есть фрагмент где немного пишется код.

ViPRosвот я свимлайн вижу исполнителя по моему, так вот в одной дорожке только ОДИН испольнитель? или я не то понял?
Не понял. А сколько должно быть?

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

ViPRosне вижу возможности создать процесс из типовых процессов по определенным политикам автоматически
Придется поверить на слово что такая возможность есть.

ViPRosне вижу возможности масштабирования процесса (это когда я закаываю не один автомобиль а 5)
Одна заявка на несколько автомобилей большого смысла не имеет, а заказ на покупку из нескольких товарных позиций - это стандарт. А как же.

ViPRosАБ,

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

ViPRosАБпропущено...

Фундаментальных для чего ?
для описания процесса :)

Я много видел и описаний, и методологий, и нотаций процессных - процессоров и оптимальных партий не встречал нигде.

ViPRosисполнителеей может быть много чек, станок,инструмент, оснастка,....)
И...? Возвращаясь к теме: в чем проблема с дорожками (swimlane)?

ViPRosя на свадьбу дочери заказал несколько одинаковых крайслера
Вы сомневаетесь, что процесс можно доработать на случай заказа нескольких автомобилей?

ViPRosпосмотрел почти все
остался при своем - программирование и только, никакой автоматизации

(перефразируя) ...а если подумать, то и автоматизация тоже фигня