Sandy Kemsley опубликовала в своем блоге короткую заметку с длинным названием It’s Not About BPM vs. ACM, It’s About A Spectrum Of Process Functionality предложив располагать бизнес-процессы на оси «структурированности». В одном конце этого континуума полностью структурированные процессы, на другом – адаптивные. В середине находятся структурированные процессы, в которых возникают требующие участия человека исключения и адаптивные процессы, включающие в себя несколько структурированных фрагментов.
Я готов согласиться с такой картинкой, но считаю не вполне целесообразным приписывать процессу такую характеристику как «структурированность». На мой взгляд, более уместно говорить о нашем понимании процесса. Глядя на один и тот же процесс мы можем видеть его структурированным или адаптивным, в зависимости от наших предпочтений. Истина же определяется по результатам мониторинга работы бизнес-процесса. Если реальный состав активностей и переходов между ними возникает снова и снова, и они отвечают нашей модели, то мы назовем процесс структурированным. Если наша модель не соответствует реальной жизни, пусть в реальной жизни одни и те же активности повторяются в одном и том же порядке то мы, скорее всего, решим что процесс структурированным не является. Обидимся и будем твердить о том, что нельзя автоматизировать хаос.
Но сегодня я не об этом. То что процесс может стартовать из кейса и то, что в результате необработанных процессом исключений возникает необходимость в открытии кейса – очень полезное наблюдение. Мы говорили об этом на семинаре BPMS.ru 16 марта (см. 8-ой и 14-ый слайд презентации). Я предлагал в качестве best practices поручить обработку исключения структурированного процесса бизнес-аналитику, который разработал этот процесс. В ходе такого кейса бизнес-аналитик будет вынужден либо обработать ситуацию вручную, либо улучшить процесс для предотвращения таких исключений впредь, либо создать новый процесс обработки исключения. В этом случае мы замкнем исполнение процесса и процесс его регулярного улучшения (извините за тавтологию). Т.е. аналитик будет итерационно улучшать процесс на основе реальной деятельности, а не гипотетических требований пользователей.
Запуск бизнес-процесса из кейса так же не относится к какой-то отдельной группе процессов. Любой бизнес-процесс должен откуда-то запускаться. Вот с этим у BPMs решений, построенных на BPMN очевидная проблема. C BPEL процессом все просто. Такой процесс по определению является web-сервисом и вызывается как обыкновенный web-сервис. Я бегло посмотрел несколько решений, намереваясь выяснить, как они запускают экземпляры бизнес-процессов. Проще всего оказалось с Activiti Благодаря своей молодости данный продукт поддерживает только none start event и вызывается исключительно посредством обращения к методу startProcessInstanceByXXX http://www.activiti.org/userguide/index.html#bpmnStartEvents
Intalio кроме пустого стартового события поддерживает запуск процесс по сообщению и правилу http://community.intalio.com/reference-guides/intalio-bpms-designer-bpmn-flow-objects.html#wp1003544
Lombardi предоставляет еще два стартовых события: запуск по таймеру и Start Ad-hoc Event
http://publib.boulder.ibm.com/infocenter/wle/v7r2/index.jsp?topic=/com.ibm.wle.doc/modeling/topic/modeling_events.html
Но наибольшее разнообразие вариантов запуска процесса предоставляет Oracle BPM http://download.oracle.com/docs/cd/E17904_01/doc.1111/e15176/model_bus_procs_bpmpd.htm#CJAEJEFD Особенно радует изображенный на рисунке 6-4 запуск процесса пользователем, посредством ввода данных. Любители нотации BPMN вероятно расстроятся от столь пренебрежительного к ней отношения.
Одним словом, в деле стандартизации вызова process instance дела обстоят не здОрово. Возможно, я чего-то не знаю и работы по унификации запуска экземпляров процессов кем-то ведутся. Если это так, то поделитесь, пожалуйста, информацией.