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