| |
Статьи | |
Автор: Волков Юрий Ольгердович, yvolk@yurivolkov.com
В предыдущей статье, "Новый взгляд на описание бизнес-процессов" [1], мы рассмотрели описание бизнес-процесса в виде текста (рассказа). А сейчас мы обсудим: как графически изображать бизнес-процессы на диаграммах (рисунках), какую графическую нотацию выбрать, и для чего можно использовать созданные диаграммы.
Для наших последующих рассуждений важно уточнить, что мы говорим об описании не любых процессов, а именно процессов "уровня бизнеса", которые:
В "разряд" бизнес-процессов не попадают, в частности, процессы, описывающие: техническую реализацию Системы и взаимодействие её компонентов ("серверов", "баз данных", "классов", "объектов" и т.п.).
Хочу сразу сказать, что текстовое и графическое представления не нужно рассматривать как взаимоисключающие альтернативы: они дополняют друг друга. С одной стороны, на диаграмме в принципе удаётся разместить существенно меньше информации, в т.ч. пояснений, чем в текстовом документе. А с другой стороны: графическое представление обладает большей наглядностью, помогая понять сложную логику и увидеть общую картину процесса.
Мы подходим к тому, что перед тем, как обсуждать различные варианты графических описаний, нужно определиться с целями, которые мы ходим достигнуть, начиная "рисовать" процессы.
Данный раздел предназначен для тех, кто почувствовал неудобство (или ещё более сильные эмоции), увидев "плавность" перехода к разговору о "Системе" в контексте описания бизнес-процессов.
Необходимость создания описаний бизнес-процессов может возникнуть в любой области человеческой деятельности, в том числе и там, где об автоматизированных системах только слышали. Но поскольку современный бизнес немыслим без его автоматизации, то в этой статье мы будем считать, что любое описание бизнес-процессов рано или поздно, непосредственно или в результате цепочки действий, будет отражено (воплощено, реализовано) в автоматизированной системе, а участники бизнес-процесса (люди, организации, другие системы...) станут пользователями этой Системы.
Примечательно, что в работе [2], сравнивавшей различные диаграммы описания бизнес-процессов пять лет назад, задачи "описания бизнес-процессов" и "разработки системы автоматизации" считались различными задачами, для решения которых бизнес-процессы описывались с помощью различных методов и диаграмм. За прошедшие годы индустрия информационных технологий не только разработала и выпустила в виде спецификаций новые методы описания бизнес-процессов (и соответствующие диаграммы), но и реализовала возможность автоматизированных систем исполнять бизнес-процессы. Сегодня существуют не только коммерческие "движки исполнения бизнес-процессов", но и аналогичные продукты, распространяемые сообществом Open Source, что делает исполнение бизнес-процессов Системой доступным для всех. Эти перемены позволяют приблизить людей бизнеса к автоматизированным системам, сократить время и затраты на автоматизацию и т.п. ... Для нас же в рамках темы данной статьи важно то, что "формирование модели (описания) бизнес-процессов" - это не конечная цель (проекта, Клиента...), а лишь один из шагов к Системе, исполняющей (полностью или частично) данные бизнес-процессы.
1. Во-первых, мы хотим получить рисунки ("блок-схемы"...), которые мы сможем использовать во время презентаций и обсуждений, а также которыми мы снабдим (дополним) текстовые документы, описывающие процессы: те текстовые документы, которые станут основой для проектирования Системы.
К этим рисункам (диаграммам) мы предъявляем следующие требования:
2. Во-вторых, мы хотим получить от результата нашего труда нечто большее, чем просто рисунки: мы хотим построить "модель" процессов, из которой можно получить не только рисунки, но и, например, текстовые отчёты о составе модели и т.п. Поэтому для описания процесса мы уже используем не карандаш и бумагу или их компьютерный аналог: программу - "рисовалку" типа 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 (http://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. Волков Ю.О. "Новый взгляд на описание бизнес-процессов". "PC Week/Russian Edition", №34 2005г., стр.42, 55 http://yurivolkov.com/articles/New_view_on_business_process_description_ru.html.
2. Репин В.В. "Сравнительный анализ нотаций", finexpert.ru, 2001. http://www.interface.ru/fset.asp?Url=/ca/an/danaris1.htm.
3. OMG. BPMN (Business Process Modeling Notation) v.1.0, 2006 http://www.omg.org/technology/documents/bms_spec_catalog.htm.
4. WfMC. XPDL (XML Process Definition Language), v.2.00, 2005 http://www.wfmc.org/standards/docs/TC-1025_xpdl_2_2005-10-03.pdf.
5. Stephen A. White. "BPMN Fundamentals", 2005, http://www.omg.org/docs/pm/05-12-06.ppt
6. The OMG standard. Volume 2, Issue 1. Spring 2006. http://www.omg.org/news/newsletters/OMG-Standard-Spring_2006.pdf.
7. Волков Ю.О. Презентация "Что дают предприятию новые стандарты описания бизнес-процессов", март 2007.
 |
Где ещё можно почитать на русском языке о системах управления бизнес-процессами и об описании бизнес-процессов: http://bpms.ru/ |
Последнее изменение: 30 ноября 2006 г.
Первый вариант данной статьи опубликован 26 сентября 2006 г. в "PC Week/Russian Edition", №35 (545) 2006г., стр. 39-40, http://www.pcweek.ru/themes/detail.php?ID=73249&phrase_id=14809.
