Главное не результат, главное процесс

BPM-блог Анатолия Белайчука

Изменение бизнес-процесса “на лету”

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

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

Ответ - Большинство 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) выбран другой путь. В палитре этой системы есть специальный “магический” активити, который может забрать на себя управление с любого активити и/или передать на любой активити. Это решает большую часть проблемы - отсутствие на схеме необходимого перехода.

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

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

09.02.09 | Заметки | , , ,    

Комментарии (5)

  1. kmmbvnr 11.02.09 08:02

    Нда самая распространная операция, в итоге оказыается боольшим гемороем…

  2. Кузин Сергей 05.11.09 13:28

    Выходит, что одна из основных проблем - всё же неграмотное проектирование процессов.

  3. Anatoly Belychook 05.11.09 13:38

    Согласен, проблема в том, что процессы проектируют не боги :)

  4. Владимир 13.02.10 16:35

    Анатолий,
    хотел бы уточнить по поводу конечного автомата - не подскажете, в каких BPMS можно реализовать такую схему? или Вы имели в виду некое абстрактное описание (не исполняемую модель) смены статусов, которое просто структурирует набор собственно процессов?

  5. Anatoly Belychook 13.02.10 17:11

    Владимир

    Пример схемы такого процесса приведен в моей статье в “Открытых системах”: http://www.osp.ru/os/2009/01/7197856/, рис.4: http://www.osp.ru/data/211/241/1241/036_1_1.gif. По-хорошему, надо было бы раскрыть этот паттерн тут на блоге, тем более, что эта идея с тех пор получила некоторое развитие. Никак не соберусь. Впрочем, мы с коллегами собираемся рассказать об этом на семинаре BPMS.ru, предположительно в апреле.

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

    Хотите спросить, что такое приличная BPMS? Это такая BPMS, которая позволяет реализовать те паттерны, которые вам нужны :)

    А идеальной BPMS называется приличная BPMS, не позволяющая реализовать антипаттерны, которые вам не нужны :)

Комментирование закрыто

Copyright © 2008-2024 Анатолий Белайчук. Спасибо Wordpress и Yahoo.  Контент  Комментарии