Комментарии к записи: Новый рубеж BPM: динамические процессы

Автор: Garth Knudson

Garth Knudson — Fri, 06 Nov 2009 14:21:00 +0000

Anatoly, good article. HandySoft has spent about 5 years developing the market for dynamic/unstructured process execution. In 2004 we have many customers approach us to add more flexibility into process design and development. They needed to branch out of structured activities into ad-hoc tasks in order to gather information and get approvals. We built into BizFlow the ability to jump out of an activity to assign an ad-hoc task. The assignee could task another in a serial fashion. The following year a couple large Govenment agencies engaged HandySoft to extend ad-hoc tasking from simple serial activities into parallel processes in order to manage large, unwieldy projects. These agencies had to revert to email to manage projects, but with email they quickly lost visibility into action status and control over collaboration, deadlines, and follow-up. They wanted to keep the project within BizFlow becuase with BizFlow they have complete process visibility. And with BizFlow they can add rules that govern both structured and dynamic workflows. We worked with them to release a dynamic tasking application in 2006. In 2007 we incorporate the external tasking application directly into BizFlow. Now BizFlow BPM enable structured, ad-hoc and dynamic process execution.

If you would like a demo, please let me know. We would like to get a customer in Russia to use the product.

Автор: Кузин Сергей

Кузин Сергей — Thu, 05 Nov 2009 11:14:41 +0000

“На самом деле всё не так, как в действительности” Что ж, остаётся только подождать, чтобы увидеть, во что это выльется…

Автор: Anatoly Belychook

Anatoly Belychook — Thu, 05 Nov 2009 10:36:54 +0000

В заметке я привел два примера заранее непредсказуемых процессов. Похожи они на проекты? Как-то не очень. На классические повторяющиеся процессы впрочем тоже. Они одновременно и уникальные, и типовые: по составу шагов - типовые, а по последовательности - уникальные. Термин Гартнер “knowledge worker process” неплохо отражает суть дела. Повторюсь: на мой взгляд, это гибрид не процессов и проектов, а процессов и того, что называется “problem tracking”. Хотя гибриды процессов и проектов в природе тоже бывают, это отдельная интересная тема.

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

“Теоретически, никакой разницы между теорией и практикой. На практике, однако, разница имеется.”

Автор: Кузин Сергей

Кузин Сергей — Thu, 05 Nov 2009 10:24:45 +0000

Похоже, что вторые (непредсказуемые) являются просто вариантами того, что называется “проектами”? Каждый раз уникальны, много неопределённости… Возможно, проблема в том, что у меня понятие процесса всё же связано с некоторыми повторяющимися действиями (конечные автоматы как способ рассмотрения состояний бизнес-объектов), поэтому “непредсказуемые” в данную категорию у меня не попадали. Если же состояния объекта заранее неизвестны, то, возможно, в таких случаях и возникают “непредсказуемые” процессы. Говорят, что хорошим примером непроцессной деятельности является работа юридического отдела.

Автор: Anatoly Belychook

Anatoly Belychook — Thu, 05 Nov 2009 10:03:41 +0000

Сергей

Я бы все-таки разделял процессы часто изменяющиеся и процессы в принципе заранее не предсказуемые.

Вы похоже говорите о первых. Но методы борьбы с ними известны: это изменение процессов “на лету” (http://mainthing.ru/ru/item/163/), использование бизнес-правил и различные варианты позднего связывания подпроцессов (последняя тема еще ожидает раскрытия тут на блоге). Мы это все применяем на практике.

А вот как быть со вторыми? Ожидания тут подогревается прогрессом в средствах коллективной работы, происходящему благодаря вебу. Хочется среды, в которой можно было бы обмениваться сообщениями наподобие почты или скорее форума, но при этом чтобы был контроль ответственного и сроков решения задачи и чтобы эта среда гладко стыковалась с движком BPM. Я себе это представляю как гибрид системы баг-трекинга и BPMS.

Автор: Кузин Сергей

Кузин Сергей — Thu, 05 Nov 2009 09:44:44 +0000

Коллеги, затронута волнующая тема:
1. С одной стороны, частое изменение БП характерно для организаций, находящихся на функциональной стадии развития; при этом инициаторами таких изменений чаще всего выступают руководители функциональных подразделений; численность самой организации обычно невелика; полагаю, что динамические БП чаще всего в таких организациях и должны возникать как ответ на неустойчивые БП;
2. С другой стороны, наибольший выигрыш, видимо, появляется всё же при переходе от управления процессами к процессному управлению, в котором BPMS, по идее, должна проявить себя в лучшем виде как способ быстрого внедрения поддержки БП;
3. Динамические процессы не являются ли результатом слабой работы аналитиков, не способных спроектировать корректно выполнение “реальных процессов”?

Автор: Anatoly Belychook

Anatoly Belychook — Sun, 01 Nov 2009 21:53:07 +0000

Никита

Спасибо за интересный комментарий. Аналогии между организациями и живыми организмами вполне уместны и параллели между геномом и шаблонами процессов пусть с оговорками, но провести можно. Ваша идея “естественного отбора” экземпляров процессов перекликается с автоматическим выявлением процессов (automatic process discovery), которое пропагандируют некоторые вендоры. Правда, что это такое на практике я пока не разбирался.

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

Автор: Никита Сушко

Никита Сушко — Sun, 01 Nov 2009 20:36:23 +0000

Благодарю Вас, Анатолий!

Динамические бизнес-процессы это - очень интересно.
То, что разработчики идут по правильному пути, закладывая в свои “конструкторы” возможности “ручного управления”, отклонения экземпляров процессов от шаблонов, элементы wiki и проч. - правильно, хотя бы потому, что так усторены и биологические объекты.
Среди генов, ответственных за выработку антител у нас есть как относительно константные, так и те, частота изменений которых выше на порядки. Есть интересные наблюдения, говорящие о том, что в неблагоприятных условиях некоторые организмы вносят “направленные” изменения в ДКН (см. напр. http://medbiol.ru/medbiol/genexp/000a72c8.htm). В любом случае, структура генома такова, что позволяет уживаться как константным так и бастроизменяющимся последовательностям. Наличие последних - туз в рукаве с точки зрения приспособления к быстро меняющимся внешним условиям.

Что касается реализации в системах, глубоко не копал, увы, буду исправляться. Однако думается, чтобы “горшочек варил”, поддержка динамических процессов должна закладываться одновременно или даже РАНЬШЕ, чем поддержка шаблонных. А сами шаблоны в таком случае должны получаться из прошедших “отбор” экземпляров динамических процессов.

Можно возразить - создавать шаблоны нужно после проектирования процессов “на бумаге”. Однако, тогда теряется скорость, а главное, есть соблазн отказаться от поддержки ad-hoc процессов “на данном” этапе, либо навсегда.

Вот такие мысли, извиняюсь за сумбур.
Статья как всегда замечательная.

Автор: Anatoly Belychook

Anatoly Belychook — Mon, 26 Oct 2009 12:56:47 +0000

Дима

Подход 1 оптимален для процессов, меняющихся раз в месяц - раз в квартал.

BRE и CEP, на мой взгляд, актуальны в основном для процессов с высокой степенью автоматизации.

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

Управлять заранее непредсказуемыми процессами BPMS пока только учатся. Положим, мне понравился ролик HandySoft, но вендор этот у нас неизвестен, цена не детская… Если бы мне пришлось решать такую задачу, я бы попробовал использовать готовый продукт класса problem tracking.

Автор: Дима

Дима — Mon, 26 Oct 2009 10:14:42 +0000

Анатолий, как вы думаете, какая из инициатив развития БПМ реально важна и уменьшает разрыв между разработкой и бизнесом, давая возможность реально управлять процессами меняющимся чаще чем раз в квартал, принося выгоды, которые обещает BPM дисциплина:

1. Единое средство разработки процессов с различными представлениями для разработчика, аналитика, бизнес аналитика с возможностью отрисовки форм и моделирования процессов.
2. Движки бизнес правил и бизнес событий - как средство упрощающее управление процессами для бизнеса
3. Модной идеей были заявлены BPA “Средства обнаружения процессов”
4. Собственно то, о чем вы пишете. Сегмент процессов срок изменений которых от одного месяца до ежедневного изменения. Или процессы которые надо изменять во время выполнения.

Вы правильно затрагиваете вопрос о развитии, т.к. похоже наступает момент когда “тянуть” все новомодные направления развития не у всех хватает сил.