Все о системах управления бизнес-процессами
 
Почитать
Поговорить
Побродить
Завершить


Вход в систему

Забыли пароль?


     
Диаграммы для описания бизнесс-процессов

Литература:

Юрий Волков

В предыдущей статье, «Новый взгляд на описание бизнес-процессов» [1], мы рассмотрели описание бизнес-процесса в виде текста (рассказа). А сейчас мы обсудим: как графически изображать бизнес-процессы на диаграммах (рисунках), какую графическую нотацию выбрать, и для чего можно использовать созданные диаграммы.

Для наших последующих рассуждений важно уточнить, что мы говорим об описании не любых процессов, а именно процессов «уровня бизнеса», которые:

  • знакомы нашему Клиенту (конечным пользователям автоматизированной информационной системы, далее называемой Системой)
  • оперируют понятиями предметной области Клиента («покупатель», «заказ», «оплата» и т.п.)

В «разряд» бизнес-процессов не попадают, в частности, процессы, описывающие: техническую реализацию Системы и взаимодействие её компонентов («серверов», «баз данных», «классов», «объектов» и т.п.).

Хочу сразу сказать, что текстовое и графическое представления не нужно рассматривать как взаимоисключающие альтернативы: они дополняют друг друга. С одной стороны, на диаграмме в принципе удаётся разместить существенно меньше информации, в т.ч. пояснений, чем в текстовом документе. А с другой стороны: графическое представление обладает большей наглядностью, помогая понять сложную логику и увидеть общую картину процесса.

Мы подходим к тому, что перед тем, как обсуждать различные варианты графических описаний, нужно определиться с целями, которые мы ходим достигнуть, начиная «рисовать» процессы.

Описание бизнес-процессов как один из этапов автоматизации

Данный раздел предназначен для тех, кто почувствовал неудобство (или ещё более сильные эмоции), увидев «плавность» перехода к разговору о «Системе» в контексте описания бизнес-процессов.

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

Примечательно, что в работе [2], сравнивавшей различные диаграммы описания бизнес-процессов пять лет назад, задачи «описания бизнес-процессов» и «разработки системы автоматизации» считались различными задачами, для решения которых бизнес-процессы описывались с помощью различных методов и диаграмм. За прошедшие годы индустрия информационных технологий не только разработала и выпустила в виде спецификаций новые методы описания бизнес-процессов (и соответствующие диаграммы), но и реализовала возможность автоматизированных систем исполнять бизнес-процессы. Сегодня существуют не только коммерческие «движки исполнения бизнес-процессов», но и аналогичные продукты, распространяемые сообществом Open Source, что делает исполнение бизнес-процессов Системой доступным для всех. Эти перемены позволяют приблизить людей бизнеса к автоматизированным системам, сократить время и затраты на автоматизацию и т.п. ... Для нас же в рамках темы данной статьи важно то, что «формирование модели (описания) бизнес-процессов» — это не конечная цель (проекта, Клиента...), а лишь один из шагов к Системе, исполняющей (полностью или частично) данные бизнес-процессы.

Цель

  • Во-первых, мы хотим получить рисунки («блок-схемы»...), которые мы сможем использовать во время презентаций и обсуждений, а также которыми мы снабдим (дополним) текстовые документы, описывающие процессы: те текстовые документы, которые станут основой для проектирования Системы.     

    К этим рисункам (диаграммам) мы предъявляем следующие требования:
    • Они должны достаточно подробно и точно описывать логику процесса. Настолько подробно и точно, насколько это нам нужно в каждом конкретном случае. При этом для различных сочетаний требований к «подробности и точности» мы хотим использовать одни и те же диаграммы.
    • Они должны быть понятны, причём одинаково, различными людьми, заинтересованными в работе с этими рисунками. Это, в первую очередь, люди бизнеса (Клиенты, сотрудники организации), чью работу мы описываем, а также «мы» сами: бизнес-аналитики, консультанты и т.п.. В идеале, любой человек, знакомый с использованным нами способом описания процесса (в частности, с его «графической нотацией»), но не обязательно знакомый с нами и нашими предпочтениями, должен правильно понимать то, что мы изобразили.
  • Во-вторых, мы хотим получить от результата нашего труда нечто большее, чем просто рисунки: мы хотим построить «модель» процессов, из которой можно получить не только рисунки, но и, например, текстовые отчёты о составе модели и т.п. Поэтому для описания процесса мы уже используем не карандаш и бумагу или их компьютерный аналог: программу — «рисовалку» типа Adobe Photoshop, — а специальное «инструментальное средство моделирования». Традиционно под этим термином известны продукты ARISи BPWin, однако не следует ассоциировать способ описания процессов с конкретным продуктом. Более того, зависимость от конкретного продукта сегодня уже является минусом как самого способа описания бизнес-процессов, так и созданной нами модели!

А теперь поподробнее: так что же конкретно «большее» мы хотим получить от модели бизнес-процессов:

  • Модель должна позволять автоматически создавать отчёты о её составе (например, для оценки затрат на разработку Системы)
  • Она должна допускать автоматическую проверку по формальным признакам: в частности, проверку корректности использования элементов модели, логики их связей, полноты модели.
  • Она должна обеспечивать возможность электронного обмена моделями и диаграммами (а не только «картинками») между различными инструментальными средствами моделирования (а, следовательно, и между людьми), а также передачу их в Систему.
  • Она должна быть достаточно полной и строгой для автоматизированного исполнения соответствующего бизнес-процесса (проигрывания его сценариев) как для целей тестирования (с использованием тестовых исходных данных, внешних событий и т.п.), так и для реального использования, т.е. для «промышленной эксплуатации» описаний бизнес-процессов в Системе.
  • Иметь обратную связь с Системой: при внесении в Систему изменений (в т.ч. уточнений), они должны автоматически отражаться в модели. В результате, кардинально меняется назначение модели и жизненный цикл её использования: она продолжает «жить» и после завершения (активного этапа) разработки Системы.

Без обратной связи от Системы модель постепенно отстаёт от того, что работает в Системе на самом деле, и поэтому модель «умирает»: становится неактуальной, а потому — ненужной. На синхронное внесение в модель тех изменений, которые вносятся в работающую Систему по требованию Клиента (и, возможно, самим Клиентом), обычно нет ресурсов. И даже в том случае, если такие изменения вносятся, они могут содержать ошибки, быть неполными и т.п. как следствие любых ручных операций.

И наоборот: наличие обратной связи от Системы к её модели замыкает контур управления Системой, делает реальностью циклическую разработку (round — trip engineering), которая сейчас является необходимым элементом любой серьёзной среды разработки автоматизированных систем.

Достоинство модели бизнес-процессов по сравнению с «моделями компонентов Системы» (к которым нас приучил язык UML) в том, что модель бизнес-процессов создаётся на другом, более высоком, уровне абстракции и позволяет бизнес-аналитикам и клиентам непосредственно участвовать в развитии Системы во время её промышленной эксплуатации, работая в команде на своём уровне понимания: на бизнес-уровне Системы. Т.е. в данном случае для внесения в Систему достаточно большой группы изменений: тех изменений, которые относятся к уровню бизнеса и его логики, — Клиенту уже не нужно самому быть программистом или использовать программиста в качестве переводчика его мыслей на язык машины (и наоборот: с языка машины на язык бизнеса).

Начинаем выбирать диаграммы

Наше желание использовать для описания бизнес-процессов диаграммы, одинаково понимаемые различными людьми, заставляет нас выбирать из небольшого числа общеизвестных диаграмм, в частности: IDEF, EPC (eEPC), диаграмм деятельности UML и диаграмм BPD, определённых спецификацией BPMN [3].

При всём моём уважении к интеллектуальному наследию, диаграммы IDEF и EPC (подробнее о них см. в [2]) — это продукты той эпохи, когда ещё не шла речь о непосредственном исполнении описаний бизнес-процессов Системой (аналогично тому, как компьютер исполняет текст программы). Я не хочу начинать полемику по поводу достоинств и недостатков этих и других достаточно традиционных нотаций: в данном случае решение отказаться от этих диаграмм мы принимаем, в первую очередь, потому, что эти диаграммы не предназначены для того, чтобы быть достаточно выразительными и точными для исполнения в Системе. Не потому, что Система — «тупая», а просто потому, что на диаграмме не всё необходимое указано, или указано неоднозначно.

Да, видя сегодняшний прогресс в области автоматизации исполнения бизнес-процессов, можно «доработать» любой тип диаграмм, добавив или уточнив всё необходимое. Можно написать некие «макросы» для экспорта описания бизнес-процесса в формат, понимаемый машиной... Но всё это будут наши собственные «заплатки», имеющие узкое применение и низкое качество.

Прошло то время, когда спецификации описания бизнес-процессов создавались для собственных нужд: сегодня такой роскоши (или такого убожества) не могут позволить себе даже IBM и Microsoft. Спецификации разрабатываются и открыто обсуждаются годами, причём этим уже не занимаются сами корпорации: для того, чтобы международное сообщество не похоронило эти «закрытые спецификации» только из-за их закрытости. Разработка глобальных спецификаций (открытых стандартов) — удел международных некоммерческих организаций (консорциумов), в которые входят представители всех заинтересованных сторон. В результате рождаются документы (толстые книжки), которые читают в основном методологи и разработчики инструментальных средств моделирования. Но как раз благодаря этим «толстым книжкам» мы имеет определённость и однозначность понимания диаграмм.

Например, как отмечают специалисты (в частности, в [2]), работа по созданию модели eEPC, должна регламентироваться «Соглашением о моделировании», составляемым командой проекта до начала собственно моделирования. Без «Соглашения о моделировании» ценность созданной модели будет минимальна. Если у Вас возникнет вопрос: «как правильно изобразить на диаграмме eEPC то-то или то-то», то по-настоящему авторитетного ответа Вам не найти (если вообще Вы найдёте какой-либо ответ). В результате, Вы делаете модель так, как сами считаете правильным, и без Ваших комментариев модель становится, мягко говоря, малоценной.

Одно время я сам удивлялся: почему после того, как команда профессионалов описала процессы и создала диаграммы, по ним невозможно реализовать работающую Систему, а необходимо повторно обходить всех «носителей знаний» о бизнес-процессах и создавать «другое описание бизнес-процессов» для того, чтобы реализовать Систему. Причина проста: это свойство самой нотации, в данном случае, eEPC. Диаграмма eEPC — это не описание того, _как_ работает бизнес-процесс, а _декларация_ того, что будет происходить, кто участвует в процессе и т.п. Я не говорю, что это не нужно. Более того: при описании нетривиальных бизнес-процессов необходимо создавать дополнительные документы. Например, не обойтись без тезауруса (словаря) предметной области; может быть необходимо описание (в том числе, в виде диаграмм) структуры организаций, участвующих в бизнес-процессах и т.п. — В данном случае я просто констатирую факт «недостаточности» диаграмм eEPC.

Диаграммы деятельности (activity diagrams) UML тоже используются для описания бизнес-процессов. Хотя в самой спецификации UML диаграммы деятельности не оперируют понятиями бизнеса, для описания бизнес-процессов энтузиасты придумали специальные расширения к этой спецификации, называемые «профилями». Профили, по сути, являются теми же «соглашениями о моделировании», о которых мы говорили выше, со всеми их недостатками. Дополнительно о том, почему мы не выбираем диаграммы деятельности UML, см. ниже в разделе «OMG о графической нотации моделирования бизнес-процессов».

BPMN (Business Process Modeling Notation) [3] — спецификация, содержащая графическую нотацию описания бизнес-процессов на диаграммах, называемых BPD (Business Process Diagram, что дословно переводится просто как «диаграмма бизнес-процессов»). Эта спецификация разработана организацией Business Process Management Initiative (BPMI) в 2001-2004 годах с учётом множества ранее существовавших диаграмм (в т.ч. всех, упомянутых выше). Основной целью данной разработки было получение нотации, легко понимаемой всеми пользователями: от бизнес-аналитика, создающего первые наброски описаний процессов, к техническим специалистам, отвечающим за реализацию этих процессов в Системе, и, наконец, до людей бизнеса, которые управляют этими процессами и контролируют их работу.

Сама спецификация BPMN не определяет формата файла, в котором можно сохранять описание и которым можно обмениваться (в том числе, и с Системой), однако уже есть как минимум одна спецификация, описывающая этот формат — это XPDL. В спецификации XPDL v.2.00 [4] явно указано, что одно из её назначений — служить описанием формата файла для нотации BPMN. Т.е. XPDL позволяет хранить не только логику процесса (как и BPEL, другая спецификация формата описания бизнес-процесса, понимаемого машиной), но и его графическое BPMN-представление. Таким образом, формат файла BPMN уже существует, что позволяет «понимать друг друга» различным инструментальным средствам моделирования.

Спецификация BPMN — это книга размером в триста страниц, которая просто заполнена графическими иллюстрациями её применения с подробными комментариями: всего около 130 рисунков! Кроме того, спецификация содержит подробный пример описания завершённого и реального процесса: процесса разрешения разногласий с помощью голосования по электронной почте (см. Рис. 1). Это процесс, который реально работал в организации BPMI при разработке самой спецификации.

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

Увидев книгу со спецификацией BPMN (которую бесплатно может загрузить себе любой желающий), я понял, что наконец-то нашёл диаграммы для описания бизнес-процессов такого качества и такого уровня проработки, что их уже сейчас можно использовать на практике. По отзывам людей, мало знакомых с нотациями моделирования бизнес-процессов, диаграммы BPMN действительно понятны уже интуитивно, а для непрофессионалов в области моделирования они вообще не отличаются от диаграмм деятельности UML. Для самых «занятых» есть и короткие выжимки из спецификации, похожие на комиксы, например [5].

Что касается инструментальных средств, которые можно использовать для создания BPMN-моделей, то открытость и проработанность данной спецификации приводит к их активному появлению (а чаще, к добавлению возможности создания BPMN-моделей в существующих средствах). На сегодня таких инструментальных средств — десятки. Есть, в том числе, и бесплатные версии программ, выполняющие функции от моделирования бизнес-процессов до их исполнения Системой (например, Intalio).

OMG о графической нотации моделирования бизнес-процессов

Некоммерческая международная организация OMG www.omg.org является разработчиком спецификации UML.

В 2005 году OMG взяла «под своё крыло» спецификацию BPMN, а 1 февраля 2006 года OMG опубликовала эту спецификацию уже как свою собственную, слегка переформатировав документ, полученный от BPMI.org, и добавив в него ссылки на OMG..., см. [3].

В своём весеннем 2006 года выпуске новостей ([6], стр.3) OMG описывает своё видение сервисно-ориентированной архитектуры (SOA) и описаний бизнес-процессов, как части архитектуры, управляемой моделями (MDA). При этом указано соответствие стандартов OMG (в т.ч. BPMN и UML) уровням моделей (уровням окружения) SOA.

Так вот BPMN, согласно OMG, применяется на самом верхнем уровне — уровне бизнес-процессов, а UML — на уровне компонентов программного обеспечения для описания интерфейсов между компонентами программного обеспечения и бизнес-сервисами.

В итоге, сферы применения BPMN и UML однозначно разделены самим (нынешним) разработчиком обеих спецификаций. Следовательно, в частности, можно уверенно использовать спецификацию BPMN для моделирования бизнес-процессов, не боясь её замены или вытеснения диаграммой деятельности UML.

OMG планирует «подвести под BPMN» метамодель (сейчас она называется «OMG Business Process Specification MetaModel» (BPDM, сокращение от «Business Process Definition Metamodel»)), оперирующую понятиями уровня бизнес-процессов, а не уровня программного обеспечения. И только там, где есть пересечения c уже существующей метамоделью UML 2, предполагается использовать элементы метамодели UML 2 в метамодели BPDM. В этом, пожалуй, и состоит очень существенное отличие диаграмм BPMN от диаграмм деятельности UML: разная семантика элементов моделей. И именно поэтому правильно моделировать бизнес-процессы, используя диаграммы, обладающие соответствующим смыслом (семантикой), т.е. BPMN в данном случае.

А нарисовать «похожие» диаграммы можно, конечно, и с помощью диаграмм деятельности UML, можно потом и экспортировать эти модели в BPEL (и в BPMN), но это уже будет «моделированием снизу вверх»...

Заключение

Я не скрываю своего выбора в пользу диаграмм бизнес процессов (BPD), определённых спецификацией BPMN [3]. На сегодняшний день это именно те диаграммы, которые можно использовать для моделирования любых бизнес-процессов (исключения, если и существуют, то только подтверждают это).

И ещё раз хочу повторить, чтобы не возникало недоразумений: диаграммы BPMN «заменяют» не «весь UML», также как и не «весь ARIS». Диаграммы BPD, определённые спецификацией BPMN, необходимо использовать именно в части описания бизнес-процессов (а не любых «процессов») вместо «диаграмм деятельности UML», «диаграмм eEPC программы ARIS» и т.п. При этом, в проекте автоматизации бизнес-процессов одними диаграммами описания бизнес-процессов Вам не обойтись. Что ещё должно быть сделано и создано — предмет «методологии процесса разработки», например, XP (Extreme Programming — Экстремальное программирование) или RUP (Rational Unified Process — Унифицированный процесс Rational). Но это уже предмет отдельной статьи.

Успехов Вам в моделировании бизнес-процессов!

Москва, август-сентябрь 2006 года.

Литература

[1] Юрий Волков. “Новый взгляд на описание бизнес-процессов” www.yurivolkov.com.

[2] В.В.Репин. “Сравнительный анализ нотаций” www.interface.ru.

[3] www.omg.org. “Business Process Modeling Notation” www.omg.org

[4] www.wfmc.org. “XPDL (XML Process Definition Language), v.2.00, 2005” www.wfmc.org.

[5] Stephen A. White. “BPMN Fundamentals” www.bpmn.org.

[6] www.omg.org. “The OMG standard. Volume 2, Issue 1. Spring 2006” www.omg.org.

Источник: Диаграммы для описания бизнес-процессов. Волков Юрий Ольгердович, 2006.

Главная | О проекте | Введение | Софт | Литература | Форум | Семинары | Ссылки | Архив новостей | Подписка на RSS-каналы | Карта сайта | Авторские права | Версия для печати