Сегодня после тренинга Алексея Баранцева, провожая его на родину , имел не большую беседу по поводу BPMS.

Рассказал об небольшом опыте - студенческой дипломной работе - как пытались применить систему для "процессного управления кадровым делопроизводством на базе UNIFY". Идеально ситуация представлялась таким образом. Пусть руководитель подразделения предлагает одобренное им заявление на приме на работу будущего сотрудника (или по совместительству существующего сотрудника). Документ попадает на одобрение руководителю вуза или его заместителю по направлению работы. если заявление одобряется в установленный срок, запускается процесс приема на работу. Естественно есть извещение руководителю подразделения, возможно, с инструкцией для принимаемого. Далее сотрудник отдела кадров оформляет приказ на прием, внося (если необходимо) требуемую кадровую информацию. Система ожидает подтверждения от сотрудника ОК и действий от кадровой учетной системы. Приказ отправляется на подпись и согласование: юристу, экономисту, бухгалтеру, затем ректору или его заместителю. После подписи в установленный срок идет извещение с деталями приема в бухгалтерию в плановый отдел и естественно в кадровую службу. Из кадровой службы идет требуемая выгрузка данных для передачи ее в бухгалтерскую систему по расчету З/п (т.к. системы разные от разных вендоров). Процесс завершается.

Выслушав меня, Алексей высказал сомнение о таком использовании системы BPMS и поделился опытом, который они получили при тестирование таких решений. Ему встречались такие BPMS реализации, которые играют роль системной шины и интегрируют разнородные ИС в единую. Т.е. говорит BPMS скорее должны использоваться "под капотом", чем в том стиле, что я описал.

Мне хотелось бы услышать комментарии по моему вопросу. Скорее всего ответит Анатолий Как же все-таки используют BPMS для чего, есть ли примеры, успешные и неуспешные?

Тут не "или", тут "и". Есть примеры и сторонники первого подхода, его можно назвать human-to-human. Есть - второго, system-to-system. Но это две части одного механизма, и если владеть только одной, то решение получится однобоким. Давно собираюсь написать об этом развернуто, надеюсь все же соберусь.

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

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

Т.е., если я правильно Вас понял, Вы подтверждаете слова Алексея - BPMS - системная шина предприятия, средство интеграции. Вопрос тогда, а зачем именно BPMS. Ну и пусть будет специализированный продукт интеграци, за чем тут система управления бизнес-процессами?

Давно собираюсь написать об этом развернуто, надеюсь все же соберусь.

очень жду

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

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

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

Вы могли бы привести примеры, когда реально это работает и действительно здорово помогает и за счет чего?

За примерами  внедрения лучше обратиться к Анатолю. Могу поделиться опытом выбора варианта реализации проекта, в процессе которого вариант с BPMS был отвергнут.
Стояла задача автоматизации процессов планирования и подготовки отчетности. Из тех требований, которые существовали, следовало, что система должна обладать сложным интерфейсом и логикой обработки данных. Одна из компонентов практически любой BPMS - это конструктор экранных форм, который позволяет быстро создавать экранные формы для ввода данных в рамках процесса. Если объем данных и логика их ввода достаточно просты, возможностей BPMS вполне хватает, если задача более сложна  - возникают трудности. Мы не решились вкладывать время и силы в доработку BPMS,  а купили набор готовых компонент для быстрой разработки экранных форм. Свою систему мы спроектировали так, чтобы позднее можно было ее интегрировать с BPMS системой. Так ввод информации, бизнес логика, хранение данных будут выполняться в нашей системе, а организация правильного процесса работы с информацией будет на стороне BPMS. До этого момента в системе контроль процесса будет выполняться за счет разграничения полномочий пользователей и набора показателей работы каждого пользователя.

За примерами внедрения лучше всего не к Анатолию, а на семинары BPMS.ru. Там разбирают реальные кейсы и "по гамбургскому счету".

Что касается экранных форм - действительно, есть такая проблема. Тут дилемма: либо очень быстро, но при ограниченной сложности презентационной логики, либо несколько более трудоемко, но можно сделать практически все. Универсального ответа не существует, все зависит от задачи. Мы для задач первого типа используем BizAgi, для второго - Unify.

Что касается экранных форм - действительно, есть такая проблема. Тут дилемма: либо очень быстро, но при ограниченной сложности презентационной логики, либо несколько более трудоемко, но можно сделать практически все. Универсального ответа не существует, все зависит от задачи. Мы для задач первого типа используем BizAgi, для второго - Unify.

Многие системы во многом воспринимаются через интерфейс. При этом желательно, чтобы многие действия были максимально автоматизированы, выполнялись быстро, удобно, наглядно и комфортно. Web-интерфейс все равно еще довольно от всего этого далек, а BPMS на сколько я понимаю основан именно на нем.

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

Или в чем проигрыш например использования системы типа 1С8.х, которая активно движется в сторону декларативного программирования интерфейсов, моделирования бизнес-логики, интерфейсам управляемым пользователем?

Многие системы во многом воспринимаются через интерфейс. При этом желательно, чтобы многие действия были максимально автоматизированы, выполнялись быстро, удобно, наглядно и комфортно. Web-интерфейс все равно еще довольно от всего этого далек, а BPMS на сколько я понимаю основан именно на нем.

Чего нельзя сделать в веб-интерфейсе? То, что современные BPMS основаны на нем - это ведь, наверное не прихоть? И все же преимущество, а не недостаток?

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

Или в чем проигрыш например использования системы типа 1С8.х, которая активно движется в сторону декларативного программирования интерфейсов, моделирования бизнес-логики, интерфейсам управляемым пользователем?

"What You See Is What You Run" (имеется в виду схема бизнес-процесса) - принцип BPMS, недостижимый при традиционной разработке.