Еще один часто задаваемый вопрос из форума.

Вопрос - В случае изменения шаблона бизнес-процесса (добавили/удалили активити) что происходит с реальными начатыми по этому шаблону (в предыдущей версии) бизнес-процессами? Что происходит в связи с этим с аналитикой?

Ответ - Большинство BPMS в такой ситуации завершат начатые экземпляры бизнес-процесса по старому шаблону, а новые будут создавать по новому. Это можно считать удовлетворительным решением только если изменение шаблона - плановое. Если же, как часто бывает, процесс зашел в тупик из-за того, что в шаблоне в данном месте не предусмотрели переход или развилку, то все что вам остается, это аварийно завершить данный экземпляр процесса и начать его снова по новому шаблону. Аналитика при этом накрывается.

Однако системы, которые позволяют модифицировать схему процесса “на лету”, существуют. Рекомендуемое чтение по теме:

• Статья Glen Smith из Appian на ebizq.net рассказывает почему важно иметь такую возможность с методологической точки зрения. Если над вами не довлеет жесткая необходимость выявить процесс до мельчайших деталей всех возможных исключений, то вы можете быстрее запустить его в эксплуатацию.
• Keith Svenson из Fujitsu обращает внимание на то, что изменение схему “на лету” принципиально очень сложно реализовать в системах, в которых для исполнения процесса используется BPEL. Fujtsu Interstage BPM позволяет вам отредактировать схему экземпляра процесса точно так же, как и схему шаблона, и при желании, сохранить полученную схему в качестве новой версии шаблона.

За информацией о последней версии конкретной BPMS обращайтесь к отчету BPTrends.

Если редактор бизнес-процессов (моделер) реализован в виде десктопного приложения (а именно так обстоит дело в большинстве систем), то это принципиально ограничивает возможность исправления процесса “на лету”. Если экземпляр процесса застрял, то необходимо иметь возможность оперативно, в онлайне исправить схему. То есть моделер должен быть реализован в виде тонкого клиента. К примеру, в Fujitsu Interstage имеется и десктопная версия моделера, и онлайновая в виде апплета.

В Oracle BPMS (aka BEA AquaLogic BPM aka Fuego) выбран другой путь. В палитре этой системы есть специальный “магический” активити, который может забрать на себя управление с любого активити и/или передать на любой активити. Это решает большую часть проблемы - отсутствие на схеме необходимого перехода.

Но не стоит полагаться только на инструментарий - надо грамотно проектировать схему процесса.

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

BPMInstitute анонсировал презентацию: “Secrets of a Business Process Consultant Shhhhh…Processes, Tools and Techniques that the Pros Use“. Сама презентация на мой вкус слишком пафосна, но один слайд стоит поместить в мемориз (даю вольный перевод, оригинал в английской версии):

Вы когда-нибудь слышали такое -

• “Вам придется вернуться, когда здесь будет Ирина - никто кроме нее не знает что с этим делать”
• “Мы всегда так делали”
• “Они не делают это по-нашему”
• “Это не моя работа”
• “Они только что послали меня к вам, а теперь вы посылаете меня обратно?”
• “Зачем такие сложности?”
• “Вам надо вернуться к ___ за подписью”
• “Когда я подавал ___ в прошлый раз, этого не требовалось”
• “В их департаменте это делается по-другому”
• “Так: кто бы не сказал вам что это неправильно, на самом деле это правильно”

В очередной раз на очередном форуме всплыл этот вопрос:

“Правда можно многие задачи BPM решать с помощью документооборота, также, как и с помощью БД. Правда получится не сильно хорошо…”

Это явный FAQ, поэтому дам-ка я на него развернутый ответ. Сам вопрос переформулирую для общности.

Вопрос - Как разграничить области применения СУБД, ECM и BPMS? Как их сочетать?

Ответ - Вообще говоря, у нас есть:

1. структурированная информация, с которой лучше всего умеют работать СУБД
2. неструктурированная информация (документы), для которой предназначены ECM
3. процессная информация, под которую заточены BPMS

(BPMS используют СУБД, а ECM может использовать СУБД или файловую систему, но мы от этого абстрагируемся.)

Каждый из троицы СУБД-ECM-BPMS способен при необходимости подменить любого из двух собратьев, но естественно, в той или иной степени ублюдочным cпособом:

• СУБД умеют хранить документы в текстовых и двоичных полях, но до полной функциональности ECM не дотягивают (например, в части навигации, поиска по контексту, версионности, разграничения доступа, интеграции с MS Office).
• В СУБД иногда хранят процессную информацию, например создавая для этого таблицу, каждая запись которой описывает очередной шаг обработки документа. Понятно, что это очень примитивное описание по сравнению с диаграммой процесса в BPMS.
• В ECM встраивают workflow-движки, но полноценной BPMS такая реализация проигрывает из-за проприетарных нотации, платформы, средств интеграции, а главное, из-за отсутствия поддержки методологии непрерывного усовершенствования. Проще говоря, в ECM можно реализовать бизнес-процесс, но трудно менять его в требуемом темпе.
• Структурированные данные можно загнать в файл Excel, а файл - в ECM.
• У BPMS есть типизированные атрибуты для хранения структурированных данных, но пользоваться ими можно только в ограниченных объемах - по производительности такой механизм и близко не стоит с непосредственным хранением в СУБД.
• BPMS позволяет прицепить к экземпляру процесса документы, но, как и в случае хранения их в СУБД, сервис по сравнению с ECM будет убогий. К тому же возникает вопрос: как добираться до документов после того, как процесс завершился?

Таким образом, если вы планируете инфраструктуру на перспективу, то вам понадобятся все три компоненты. Если же перед вами стоит задача, ограниченная по функциональности, ресурсам и/или срокам, то вы можете поискать решение “для бедных”, скомпенсировав отсутствие компоненты за счет имеющихся в наличии.

Сбалансируйте вашу стратегию во времени: например, в пилотной стадии BPM-проекта зачастую обходятся встроенными в BPMS средствами хранения документов. Ведь в пилотном проекте главное - в возможно кратчайшие сроки выяснить: а нужно ли нам оно вообще? Если да, то ECM можно и потом прикрутить.

Как в различных реализациях BPMN выглядит шаг процесса, выполняемый людьми? Чисто для иллюстрации возьмем процесс “От обращения до заказа” (Inquiry to Order) с шагами “Сделай это” (Do This, системный), “Согласуй договор” (Negotiate Contract, человеческий), “Сделай то” (Do That, системный) и смоделируем при помощи нескольких популярных инструментов.

» читать дальше