nexoma:) реально не получил, но в ходе беспробудного лазания по инету, видел демку, вроде даже российская. там рисовали б-п схему, потом к ней добавляли формочки, а потом эти формочки заполнялись данными, а на б-п схеме для администратора было видно по какому пути пошел бизнес-процесс.
а внешне обычная справочная система, как отправил в рейс автобус по х-маршруту с х-водителем на х-дату-время с получением отметки о выпуске из гаража и отметки о состоявшемся рейсе.Подозреваю, что речь идет об этом .
P.S. Только это не российская система... :)

БредятинаЗначит БП - это всего лишь процесс управления информациейСогласен. С одной небольшой оговоркой на тему "всего лишь". Это не просто процесс процесс управления информацией, это процесс управления информации, способный легко и быстро ИЗМЕНЯТЬСЯ в соответствии с концепцией Деминга. Без такой способности цикл PDCA не сможет крутиться.

БредятинаИ это банальная часть корпоративной системы, которая поддерживается в корпоративной БД, как и любая другая ее часть. А вовсе не отдельная система, которую нужно как-то интегрировать. Так что постановка вопроса ориентирована на бесполезную архитектуру:)Видите ли, корпоративные системы, как правило, нацелены на "жесткие" БП. Один раз сделал - и не дай бог затем трогать. Естественно, чтобы "провернуть" хотя бы один цикл PDCA, требуется "раздолбать бетон" и соорудить новую "бетонную стену". Если бы КИС позволяла легко и просто вносить изменения в описание БП, автоматически документируя и изменения и сам БП, и получать приложение с изменившимися процессами управления информации, BPM-системы было бы гораздо менее востребованы, либо не были бы востребованы вовсе.

БредятинаВсе проблемы нужно решать с помощью данных, а не приложений. Это ключевой момент.Дело не только и не столько в данных. Дело в так называемых "длинных транзакциях", которые могут продолжаться месяцами. На любой момент времени, на который бы Вы ни взялись изменять БП, может находиться некоторое количество уже исполняющихся БП, причем, исполняющихся на различных фазах БП, который подлежит изменению. "Уважающие себя" BPM-системы имеют встроенные средства для "разруливания" и стыковки новых экземпляров БП и тех, которые были запущены до изменения схемы БП. В жестких системах таких средств не предусмотрено. И тривиальная SQL-ная команда Alter table таких средств тоже не предусматривает. Не говоря уже о том, что СУБД не поддерживают "длинные транзакции", только "короткие" (ACID).

Бредятина,

Ну, отказаться потенциально можно вообще от всего. В предельном случае отказ от вообще всего сводится к суициду. :)

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

Просто хочу напомнить, что концепции технологических процессов тоже когда-то не было. Каждый оружейник, к примеру, изготавливал не только ружья по собственной технологии, но и каждое отдельное ружье даже у одного и того же мастера получалось уникальным. По этой причине выход из строя какой-либо детали ружья приводил к невозможности заменить ее унифицированным ЗИП. Приходилось либо полностью менять ружье, либо заказывать запчасть тому же мастеру, который изготовил ружье. Потом появилась унификация деталей и формализованные технологические процессы. Потом появились методы управления качеством технологических процессов, применимость которых Деминг расширил до процессов управленческих. Так в чем Вы видите бесполезность? В унификации? В методах управления качеством? Или вообще во всём? Ответ, пожалуйста, обоснуйте. А то, знаете ли, неприятно лицезреть ответы в стиле "всё это чушь", и точка. Это слишком универсальный ответ для того, чтобы быть ответом в обсуждении на серьезном уровне.

БредятинаGaryaТак в чем Вы видите бесполезность? В унификации? В методах управления качеством? Или вообще во всём? Ответ, пожалуйста, обоснуйте.
В создании отдельных специализированных систем. Которое аргументируется сложностью создания корпоративной системы. Давайте уж тогда использовать n систем путем их интеграции с помощью n+1 системы, и сопровождения и развития n+1 системы со всеми вытекающими последствиями. Деминг ведь этого не хотел:) Он просто размышлял об одном из аспектов функционирования предприятия. И хорошо. Это не повод создавать и использовать BPMS.А я согласен. :)
Было бы здорово, если бы КИС обладали такой гибкостью, как BPM-системы, и при этом позволяли бы решать весь комплекс задач, которые решают ERP и PDM. Вот только когда это будет...

А пока этого нет, приходится довольствоваться тем, что BPMS, ERP и PDM - это разные системы.

ViPRosGaryaБредятина,
механизмов управления "длинными транзакциями" (когда многомесячная их длинна объективно определяется длиной производственного цикла и логистическими задержками)
давай разберем этот пример
детализируй, пжальста, что тут есть "длинная транзакция", как им управляет бпмс и что дает управление имДлинная транзакция - это некоторое законченное действие в системе ведения бизнеса. К примеру, поступил заказ от потенциального покупателя, он должен быть обработан, выслано встречное предложение, проведена процедура согласования. Если консенсус не достигнут, до заключения договора не доходит (конец транзакции), если достигнут, заключается договор, и требуется отслеживать озвученные в нем параметры. Под заказ покупателя должно быть произведено несколько заказов поставщикам, которые опять же завязаны на процедуры согласования. Далее требуется отслеживать сроки по каждому из них и реагировать на отсутствие информации, которая должна появиться к определенному моменту. Отследить движение ТМЦ, поступление корректно оформленных документов, зафиксировать информацию для маректиноговых структур, для иных целей... Если реализация и завершение взаиморасчетов считается неким законченным актом, то в нормальном режиме это завершение "длинной транзакции".

"Длинная транзакция" может распараллеливаться, параллельная обработка может сходиться опять в последовательную, в определенных узлах должны иметься функции автоматизированного контроля, чтобы ничто не было упущено. Должны быть таймауты, реагирование на те или иные события (а вдруг заболеет ключевой исполнитель?). Должны быть заранее проработаны способы отката "длинной транзакции". К примеру, если заказчик сделал заказ и оплатил аванс, а потом вдруг передумал и отказался - какие могут быть варианты прерывания транзакции а) если мы уже понесли расходы, связанные с обработкой заказы и б) если еще их не понесли? Само собой, в шаблон типового договора должны быть включены подобные нюансы, речь о другом - о том, чтобы эти нюансы, если произошли некие события, автоматизировано отслеживались и отрабатывались в нужном ключе.
Потоки управления могут распараллеливаться, образовывать циклы, содержать процедуры компенсации (для отката транзакции), сливаться в одном месте, взаимодействовать синхронно и асинхронно, изменять свои режимы в зависимости от тех или иных событий... Для предприятия с численностью сотрудников более 3-5 человек просто нарисовать их и при этом не ошибиться - уже проблема. А ошибиться очень легко. Легко вогнать какую-нибудь обработку в вечный цикл, либо забыть обработать какой-нибудь статус и загнать процесс "в космос". Легко допустить ошибку синхронизации процессов. Специальные средства проектирования процессов и автоматического контроля их логической целостности не позволяют допускать подобных ошибок - уже на уровне семантики графической модели БП. А продуманные средства компенсации "длинных транзакций" позволяют сосредоточиться на описании компенсационных процедур для элементарных действий. Откат всей "длинной транзакции" происходит корректно вне зависимости от того, сколько процессов в ней распараллелено, сколько уже операций выполнено, и сколько осталось выполнить.

ViPRosдлинная транзакция ничем не отличается от короткой :)Отличается.
1. Длинная транзакция может оставаться незаконченной между несколькими перезагрузками сервера. Это не приводит ни к ее накату, ни к ее откату.
2. У длинной транзакции, в отличии от короткой, нет предопределенных системой механизмов компенсации (возврата в исходное состояние).

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

Не все явления в объективной реальности можно откатить. Бумагу, опущенную в шредер, наврядли удастся вернуть в первоначальное состояние. Даже если действие "опустить бумагу в шредер" оформлено в виде операции "длинной транзакции".

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

Поэтому после отката "длинной транзакции" не гарантируется, что система будет приведена в то же состояние, которое она имела до начала длинной транзакции.

ViPRos,

Вот, почитай про механизмы компенсации, заложенные в нотации BPMN.

А мне концепция, заложенная в BPMN, нравится. Я полагаю, что не нравится она тем, кто ее до конца не понял. :) Даже если искренне полагает, что понял, скорее всего, ошибается, если думает, что это чушь и в этом нет необходимости. :)

Механизмы отката "длинных транзакций" в BPMN содержат средства автоматизированной обработки, которые позволяют связать очень сложные цепочки действий по компенсации транзакции в логически корректную последовательность, которая получается таковой (то есть, корректной) как бы "сама собой", и при этом полностью описывающей все варианты прерывания транзакции. Даже если БП состоит из десятков подпроцессов, каждый из которых в свою очередь состоит из еще некоторого количества подпроцессов, даже если прервать основной процесс может ошибка во вложенном на втором уровне подпроцессе, который может несколько раз "вызываться" (как подпрограмма) в разных местах основного процесса, даже если общее количество мест и причин, по которым может произойти прерывание, исчисляется сотнями, спроектированный в "хорошем стиле" БП корректно отработает огромное количество процедур компенсации вне зависимости от причины и места прерывания процесса и уровня вложенности процессов. При этом не требуется во всех деталях расписывать маршруты обработки для всех варианты прерывания - такое расписывание привело бы к гигантской паутине управляющих воздействий, а в BPMN ее удается избежать благодаря концепции, похожей на "стек". Действия, для которых прописана процедура компенсации, всегда обрабатываются в обратном порядке тому как на них попал поток управления. Как при вызове подпрограмм программист не вникает в алгоритм "правильного возврата" из подпрограммы, точно так же разработчик вложенных БП не вникает в нюансы взаимодействия вложенного БП с родительским БП, в маршруты компенсации по прерываниям, которые могут произойте где угодно и почему угодно. Нотация BPMN линиями прорисовывает далеко не всё, что на самом деле может отработано! Это событий-ориентированная концепция! Она позволяет при разработке маршрутов компенсации не вникать мозгами во взаимодействия множества различных действий по компенсации, число которых может измеряться сотнями, а сосредоточиться на каждом шаге БП на компенсации исключительно самого этого шага.

Получается подход, аналогичный подходу в модульном программировании. Разработчик БП, следующий "хорошему стилю", сосредотачивает своё внимание, как правило, не более чем на 5-6 аспектах в один момент времени. При этом он получает описания БП, которые возможно охватить взглядом и быстро понять, что они делают и как - и убедиться при этом в их корректности. И при этом сложная совокупность БП позволяет описать достаточно сложную, запутанную логику, которая "целиком" ни в один мозг не влезет, но сформирует корректно работающее приложение, реализующее задумки тех, кто рисовал БП, именно в том виде, в котором они нарисованы. Это очень важно - получить именно то, что ты нарисовал, а не толи то, что нарисовал, толи нет - и потом еще искать, в каком месте алгоритма содержится ошибка, которая приводит к тому, что алгоритм отрабатывает не так, как нарисованная схема БП.

Вот скажите, Бредятина, не считаете ли Вы ООП простым "запутыванием понятий"? К чему все эти "заумные понятия" абстрагирования, инкапсуляции, полиморфизма, наследования? Зачем использовать вызовы подпрограмм, может быть, проще просто написать If Статус="Приплыли" then GoTo МеткаКакБыВозвратаИзПодпрограммы ? :)

iscrafmПоэтому и говорить о них корректно только в указанном контексте, заботится о какой-то синхронизации"Заботиться о какой-то синхронизации" приходится не в силу нотации BPMN, а в силу объективной потребности и появления способов эту потребность реализовать. В суровой реальности многие процессы имеют совершенно разный ритм . Возникновение потребности в пасте Гойя может привязаться к заказу ж/д-контейнера, а может и не привести. Понятно, что ради 100 грамм пасты Гойя заказывать ж/д-контейнер нет никакого смысла. Грузовой автомобильный, впрочем, тоже. Желательно скомплектовать некоторое количество того, в чем возникла потребность таким образом, чтобы за один прием привезти много-чего. При этом потребность в различных частях этого самого "много чего" может возникать, в среднем, 1 раз в минуту. А контейнер может заказываться, в среднем, 1 раз в неделю. Одновременно, нельзя допустить, чтобы неукомплектование контейнера привело бы к остановке производства на неделю из-за того, что на него не доставили своевременно 100 грамм пасты Гойя, не так ли?

Процессы, формирующие потребность, имеют ритм, существенно отличающийся от ритма процессов заказа транспорта - не потому, что в BPMN так придумали, а ОБЪЕКТИВНО . Я привел пример только пары таких процессов, на самом деле могут одновременно работать десятки процессов с разными ритмами взаимодействующие между собой СЛАБО ("слабое" взаимодействие отличается от "сильного" как раз тем, что связывает между собой процессы, работающие в разном ритме).

И тут настал опять черед аналогий в ИТ-сфере. Может быть зря напридумывали все эти мютексы, семафоры, нити, потоки для многопоточной обработки? Зачем всё усложнять? Почему не реализовать всё в одном линейном алгоритме безо всяких распараллеливаний и асинхронности? Ну, ежели объективной потребности в этом нет?.. :)