С чего начинается… бизнес-процесс

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 дела обстоят не здОрово. Возможно, я чего-то не знаю и работы по унификации запуска экземпляров процессов кем-то ведутся. Если это так, то поделитесь, пожалуйста, информацией.

С чего начинается… бизнес-процесс: 6 комментариев

  1. вах вах… какая далекая мысль )
    до BPEL мне еще явно далеко… а вот если говорить о человеческих процессах, то я нашел 3 возможных старта:
    1. Обращение — когда есть конкретное лицо заинтересованное в результате, например Иванов Иван или ООО «Веники»
    2. Задание — когда конкретного лица нет, а есть абстрактное лицо типа организации или общества
    3. Событие — когда возникает сущность, требующая реакции или записи, не зависящая от нашей воли. Выход новой версии ПО от поставщика, эпидемия гриппа, ураган.

    Эти 3 сущности могут быть основанием друг для друга. Одна может создаваться на основе другой. Эти сущности могут быть основаниями для старта процессов. Записи о них могут в дальнейшем анализироваться для принятия решений.
    Других сущностей для старта процесса я не нашел. Все остальные являются подклассами этих.
    Или я ошибаюсь?

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

      В первом случае, процесс зачастую стартует сразу с некоторой активности, например, пользователь заполняет форму. На мой взгляд, в таких ситуациях не надо рисовать некое фиктивное стартовое событие. Есть, конечно, запуск процессов по таймеру, но это как раз понятный случай. Во втором варианте, когда процесс стартует по внешнему событий рисование пустого стартового события в BPMN нотации уместно, но тогда и надо говорить, что это программный интерфейс. Что такое события сообщения, события условия и события сигналы и как их реализовывать в информационных системах вообще не ясно.

      Я думаю, что это проблема BPMN. Проблема, вызванная тем, что разработчики стандарта с одной стороны хотели сделать что-то универсальное и понятное бизнес-пользователю, а с другой стороны те же самые авторы стандарта хотят «исполняемости» написанных на BPMN процессов.

      1. у нас явно проблемы с пониманием друг друга )
        давайте синхронизировать картины мира )
        1. как я понимаю есть жестко компьютерные техники моделирования будь то UML или BPEL
        2. есть техники моделирования на стыке разума и компьютера: BPMN
        3. а есть описание процессов абстрактного характера. компьютеры абстрактно думать не умеют. этот уровень нужен людям.

        Я смотрю на процессы как на последовательность действий с точки зрения человека и за базу беру процессы без компьютеров. Там нельзя применить BPEL и даже BPMN применять очень тяжело.
        Там нужны техники описания, описать которые я пока не могу (но мне понравилась техника ACM которую я нашел на этом блоге).
        И вот именно на этом, абстрактном уровне… можно выделить те 3 варианта старта, которые я назвал: обращение, событие, задание.

        Обращение может быть в виде сигнала или сообщения, если говорить в понятиях BPMN. То же событие может быть получено через условие, сигнал, таймер…
        Если брать другие нотации, то там будут другие варианты стартов. Но все они в моем понимании сводятся к этим 3-м абстрактным сущностям.

        Но если брать этот абстрактный уровень, который лучше воспринимается людьми… то можно ли говорить об этих 3-х вариантах старта как базовых?

        Далее, можно при использовании BPMN или BPEL уходить в конкретные варианты старта на том или ином языке. Но мне во-первых это кажется вторичным, во-вторых сложным, а в третьих редко применимым.
        Я вот сейчас выстраиваю комплексную ИС, с ECM, ERP, BI, ITSM, web 2.0. И до сих пор не понял где мне может понадобиться нотация BPMN или тем более BPEL. Вероятно у меня не тот уровень проблемы… или не тот размер ИС. Но вот потребность в классификации вариантов старта на человеческом, абстрактном языке уже явно назрела. А потребности классификации стартов на языке BPMN или BPEL до сих пор не вижу. И хочу понять причину этого…

    2. [отвечаю на эту запись из-за ограничений уровней вложенности сообщений в блоге]

      Это не мы с вами запутались. Это BPM-сообщество (консультанты, вендоры, участники Object management group) запуталось и всех остальных запутало 🙂
      Давайте разбираться:
      BPEL — чисто компьютерная технология. Практически язык программирования. Для людей не применим.
      UML и BPMN — стандарты графической нотации принятые этой самой OMG. Как вы метко заметили, находятся они на стыке разума и компьютера, а потому и не подходят толком ни для компьютеров, ни для людей.
      Мой опыт показывает, что наиболее приемлемый для людей способ описания бизнес-процессов предложен Алистером Коберном http://wp.me/pRljZ-4r По форме, это текстовое описание состоящее из ряда разделов и набора правил В нем, кстати, инициирующее процесс событие(триггер) вообще выносится в отдельный раздел. Классификация стартов процесса «обращение, событие, задание» вполне разумно.

      Относительно выстраивания комплексной ИС. Я думаю, что не BPMN не BPEL здесь не понадобятся. Я думаю, что здесь более уместны подходы «архитектуры предприятия» (enterprise architecture). Чуть позже напишу небольшую запись в блог о текущем состоянии EA

  2. я тут вот что еще подумал… )
    1. здесь речь идет о 2-х подходах к моделированию процесса: структурирование и адаптивность от событий.
    2. думаю что что это оба дополняющие друг друга подхода )

    В системе BusinessStudio выделяется 2 основые модели процесса: Процесс и Процедура.
    Процесс может включать в себя другие процессы или процедуры. А Процедура начинается с какого либо события.

    И вот если брать эту методику… тогда все встает на свои места.

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

    Пример:
    1. Фирма ООО «Веники не вяжем, а ИТ-аутсорсим»
    2. В целом ее деятельность можно назвать процессом. Назовем этот процесс: «А0. Управление ИТ»
    3. Далее, нам этот процесс нужно разделить на составляющие подпроцессы. Вот тут то нам на выручку и приходит MECE. Техника правильного структурирования объектов.
    4. Ну скажем его можно декомпозировать на: А1. Поддержка услуг, А2. Предоставление услуг и А3. Обеспечение
    5. На этом уровне в А1 уже можно выделять события и реакции в соответствии с ITIL: обращение, инцидент, изменение, релиз…, а например А3 все еще достаточно большой, чтобы искать в нем события, потому его нам надо дальше декомпозировать по той же технике.
    6. Его опять же декомпозируем не с бухты барахты, а в соответствии с ИСО 9000, по перспективам: А3.1. Связь с общественностью (обеспечивает рост клиентуры), А3.2. Управление ресурсами (дает эффективность в части затрат), А3.3. Управление персоналом (чтобы все умные и красивые были), А3.4. Управление процессами (дает эффективность в части результатов, качество и информацию)

    И так далее. Пока событий не видно, применяем технику структурирования MECE для описания действий, а в качестве нотации моделирования мне тут нравится применять IDEF0.
    А как только начинаем наталкиваться на события, то применяем технику ACM для описания действий, а в качестве нотации мне тут больше всего нравится BPMN.

    1. Я посмотрел сайт BusinessStudio. Мне понравились формы описания процессов, но все же процесс и процедура трактуется несколько своеобразно. В традиционном понимании процесс — последовательность активностей; функция — множество схожих активностей, выполняемых, как правило, одним подразделением; а процедура… я не знаю точного определения. Из моего опыта, процедура — это регламент одного или нескольких процессов или подпроцессов. Здесь же процедура — набор рекомендаций по выполнению конкретной активности или же процесса

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *