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

     ИНСТРУМЕНТАРИЙ

В опубликованной год назад статье "Новый взгляд на описание бизнес-процессов" (см. PC Week/RE, N 34/2005, с. 42), мы рассмотрели описание бизнес-процесса в виде текста (рассказа). Теперь самое время обсудить, как изображать бизнес-процессы на диаграммах (рисунках), какую графическую нотацию выбрать и для чего можно использовать созданные диаграммы.

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

- знакомы нашему клиенту (конечным пользователям автоматизированной информационной системы, далее называемой Системой);

- оперируют понятиями предметной области клиента ("покупатель", "заказ", "оплата" и т. п.).

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

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

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

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

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

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

Цели

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

К этим блок-схемам (диаграммам) мы предъявляем следующие требования.

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

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

2. Во-вторых, мы хотим в результате получить нечто большее, чем просто рисунки: мы хотим построить модель процесса, на основе которой можно сгенерировать не только диаграммы, но и, например, текстовые отчеты о составе модели. Именно поэтому для описания процесса мы уже используем не карандаш и бумагу или их компьютерный аналог - графический редактор типа Adobe Photoshop, а специальные инструментальные средства моделирования. Самые популярные из них - продукты ARIS и BPWin. Не следует, однако, слишком тесно связывать способ описания процессов с конкретным продуктом (если только этот способ не является общепринятым стандартом). Более того, подобная зависимость сегодня уже является недостатком как самого способа описания бизнес-процессов, так и созданной с его помощью модели!

Так какими же качествами должна обладать модель бизнес-процесса?

- Она должна, во-первых, позволять автоматически создавать отчеты о ее составе (например, для оценки затрат на разработку Системы).

- Во-вторых - допускать автоматическую проверку по формальным признакам: в частности, таким, как полнота модели, корректность использования ее элементов, логика связей между ними.

- В-третьих - обеспечивать возможность электронного обмена моделями и диаграммами (а не только "картинками") между различными инструментальными средствами, а также передачу их в Систему.

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

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

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

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

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

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

Верхний уровень в описании процесса разрешения разногласий с помощью голосования по электронной почте

 в нотации BPMN - реального процесса, использовавшегося при коллективной разработке самой спецификации BPMN

При всем моем уважении к историческому интеллектуальному наследию диаграммы IDEF и EPC (подробнее о них см. в [1]) - это продукты той эпохи, когда еще не шла речь о непосредственном исполнении описаний бизнес-процессов Системой (аналогично тому, как компьютер исполняет текст программы). Мы полагаем, что от применения этих диаграмм следует отказаться, в первую очередь потому, что они недостаточно выразительны и точны для исполнения в Системе. Дело не в том, что Система - "тупая", а просто на диаграмме не все необходимое указано, а то, что указано, допускает неоднозначную трактовку.

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

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

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

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

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

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

Сам стандарт BPMN не определяет формата файла для сохранения описания и информационного обмена (в том числе и с Системой), однако уже есть как минимум одна спецификация, описывающая этот формат, - это XPDL. В версии XPDL v.2.00 (www.wfmc.org/standards/docs/TC-1025_xpdl_2_2005-10-03.pdf) явно указано, что одно из ее назначений - служить описанием формата файла для нотации BPMN. Иными словами, XPDL позволяет хранить не только логику процесса (как и BPEL, другая спецификация описания бизнес-процесса, понимаемого машиной), но и его графическое BPMN-представление. Таким образом, формат файла BPMN уже существует, что позволяет "понимать друг друга" различным инструментальным средствам моделирования.

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

Познакомившись более детально со спецификацией BPMN (которую бесплатно может загрузить любой желающий), я наконец-то увидел диаграммы для описания бизнес-процессов такого качества и такого уровня проработки, что их немедленно можно использовать на практике. Да и по отзывам людей, мало знакомых с нотациями моделирования бизнес-процессов, диаграммы BPMN действительно понятны на интуитивном уровне. Для самых "занятых" есть и короткие выжимки из спецификации, похожие на комиксы (www.bpmn.org/Documents/BPMN%20Fundamentals.pdf).

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

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

Некоммерческая международная организация OMG (www.omg.org), являющаяся разработчиком UML, в 2005 г. взяла "под свое крыло" спецификацию BPMN, а в феврале нынешнего опубликовала ее уже как собственную, слегка подкорректировав документ, полученный от BPMI.org, и добавив в него ссылки на OMG [2].

В недавно выпущенном документе (www.omg.org/news/newsletters/OMG-Standard-Spring_2006.pdf) OMG разъясняет свои представления о сервисно-ориентированной архитектуре (SOA) и описаниях бизнес-процессов как части архитектуры, управляемой моделями (Model Driven Architecture). Там же показывается соответствие стандартов OMG (в том числе BPMN и UML) уровням моделей SOA.

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

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

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

Во избежание недоразумений хотел бы отметить, что диаграммы стандарта BPMN не заменяют полностью аналогичные конструкции UML или ARIS. Они предпочтительны именно для описания бизнес-процессов (а не процессов любого типа). Следует помнить, что в реальном проекте одними диаграммами описания бизнес-процессов вам не обойтись: необходимо использовать также методологии процесса разработки (например, Extreme Programming или Rational Unified Process). Но это уже предмет отдельной статьи.

Литература

1. Репин В. В. Сравнительный анализ нотаций 2001. www.interface.ru/fset.asp? Url=/ca/an/danaris1.htm.

2. OMG. BPMN (Business Process Modeling Notation) v.1.0, 2006. www.omg.org/ technology/documents/bms_spec_catalog.htm.

С автором статьи можно связаться по адресу: yvolk@yurivolkov.com.