CC BY
852
№ 1 (37) 2012
Т. Е. Сапожкова, канд. экон. наук, доцент МФПУ «Синергия», г. Москва
Сравнительный анализ подходов к моделированию бизнес-процессов
Одними из наиболее важных этапов проектирования информационных систем (ИС) являются анализ бизнес-процессов, а также последующая формализация требований к разрабатываемой системе на основании проведенного анализа. Данные этапы относятся к предпроектному исследованию и составляют фундамент для последующих этапов жизненного цикла ИС.
Введение
Цена ошибок, допущенных на этапе анализа бизнес-процессов, достаточно велика, поэтому проектной команде необходимо уделять особое внимание вопросам моделирования бизнес-процессов, на основе которых будут формулироваться требования к проектируемой системе. Адекватный выбор подхода к моделированию бизнес-процессов и инструментальных средств их описания — залог успешной реализации проекта по разработке информационной системы. На сегодняшний день для моделирования и анализа бизнес-процессов используется методология IDEF0, также ряд ИТ-специалистов рассматривают возможность использования языка UML (и, в частности, диаграммы деятельности) для анализа бизнес-процессов [1, 2, 3, 4]. Кроме того, в последние годы успешно зарекомендовал себя и новый подход к описанию бизнес-процессов — это BPMN (Business Process Modeling Notation, нотация моделирования бизнес-прцоессов). Рассмотрим возможности различных нотаций описания бизнес-процессов на примере комплекса задач по взаимодействию с клиентами в некой организации.
Возможности графических нотаций описания бизнес-процессов
На рисунке 1 приведено описание рассматриваемой задачи в нотации IDEF0.
Как видно из рисунка, используя нотацию IDEF0 для описания бизнес-процес-
сов поставленной задачи, можно получить, с одной стороны, достаточно простую и наглядную диаграмму, которую легко прочитать. С другой стороны, на схеме не видно моментов, касающихся организации обмена данными и логики взаимодействия бизнес-процессов в исследуемой предметной области. То есть в этой нотации невозможно наглядно отобразить условия, при выполнении которых произойдет составление акта приема-сдачи и при которых продолжится выполнение задания. Также нотация не предусматривает специальный графический элемент для иллюстрации объектов данных, которые используются или формируются бизнес-процессами. Однако следует отметить, что в функциональном проектировании логика взаимодействия процессов поддерживается нотацией IDEF3, а описание потоков данных — нотацией DFD (Data Flow Diagram). Но для этого уже необходимо декомпозировать диаграммы IDEF0.
На рисунке 2 представлена диаграмма деятельности языка UML, отражающая основные бизнес-процессы рассматриваемой предметной области. Построение этой диаграммы велось с помощью программного средства Rational Software Architect 7.5.4.
В диаграмме для отображения исполнителей работы (Activity) был выбран элемент Partition (как видно из рисунка, таких элементов три: клиент, менеджер по продажам и мастер).
Необходимым условием анализа бизнес-процессов является их декомпозиция.
№ 1 (37) 2012
S
СО С
<3
Рис. 1. Пример описания бизнес-процесса в нотации IDEF0
Рис. 2. Диаграмма деятельности языка UML
Для возможности декомпозиции все элементы диаграммы, представляющие бизнес-процессы, должны быть реализованы с помощью элемента Structured activity, внутри которого можно создать вложенную диаграмму деятельности (рис. 3).
** "TtuWWir Add LML ► •—■ ЙЫ1МН«*№ K^Zrfctf
у
Add ftjgipm ► ¡Э Aslivity Di^T-im
1 .4, Add Ней L. ...J..... '
Рис. 3. Создание диаграммы деятельности внутри элемента Structured Activity
15
№ 1 (37) 2012
Однако недостаток такой декомпозиции очевиден: необходимо заранее предугадать необходимость декомпозиции той или иной деятельности, чтобы правильно выбрать элемент диаграммы. Результат детального рассмотрения работы «Оформление документов» приведен на рис. 4.
Таким образом, при использовании диаграмм деятельности языка UML для моделирования бизнес-процессов аналитики получают возможность отображения логики взаимодействия и информационного обеспечения бизнес-процессов. Кроме того, используя указанный язык и далее, на протяжении других этапов жизненного цикла информационной системы, у аналитиков, разработчиков и архитекторов появляется возможность интеграции моделей в единый проект. Для этого обычно используются такие CASE-средства, как Rational Rose и Rational Software Architect.
В последнее время все большую популярность завоевывает новый стандарт BPMN (Business Process Modeling Notation) от консорциума OMG1, принятый как стандарт «де-факто» и схожий по своей нотации с диаграммами деятельности UML [3, 5]. g BPMN — графическая нотация для моде-si лирования бизнес-процессов. BPMN из-|| начально был разработан консорциумом g BPMI, а на сегодняшний день поддержива-| ется компанией OMG после того, как эти две g организации объединились. Основная цель | BPMN — поддержка нотации, которая оди-§ наково будет пониматься всеми участника-| ми бизнеса: от бизнес-аналитиков, разра-5 батывающих эскизы процессов, и разра-* ботчиков, реализующих их технологии для § выполнения этих процессов, до бизнесме-|| нов и менеджеров, которые будут управлять § и наблюдать за процессами. | Одно из преимуществ моделирова-! ния бизнес-процессов в BPMN — это воз-
<5 1 Object Management Group (OMG) — международ-
Sg ный некоммерческий консорциум, занимающийся раз-
So работкой и продвижением объектно-ориентированных
tj технологий и стандартов. — Прим. ред.
можность генерации разработанных моделей в BPEL (Business Process Execution Language — язык на основе XML для формального описания бизнес-процессов и протоколов их взаимодействия между собой) с помощью систем класса BPMS (Business Process Management System — инструмент исполнения бизнес-процессов). Процесс построения диаграммы BPMN происходил в среде Rational Software Architect 7.5.4. Результат представлен на рис. 5.
В BPMN предусмотрена возможность описания на одной диаграмме бизнес-процессов, как протекающих внутри организации, так и отражающих взаимодействие компании с объектами внешнего мира (клиенты, поставщики, контрагенты и т. д.). Для реализации этой возможности предусмотрены такие элементы диаграммы, как Pool (позволяет распределять обязанности и иллюстрирует организацию, роль или систему) и Lane (предназначен для иерархического деления элемента Pool). Так, на рис. 5 элемент Pool использовался для отображения объектов «Клиент» и «Организация». С помощью пунктирных стрелок, соединяющих элементы Pool, иллюстрируется взаимодействие организации с объектами внешнего мира, в данном случае с клиентом, формирующим пожелания, которые в виде сообщения поступают менеджеру по продажам для осуществления дальнейших действий. В свою очередь, в элементе Pool «Организация» с помощью элемента Lane выделены два участника бизнес-процессов — это менеджер по продажам и мастер. Диаграмма BPMN поддерживает более широкой выбор логики взаимодействия процессов: в нотации предусмотрены логические операторы «исключающее ИЛИ», «И» и «ИЛИ». В нашем примере используется оператор «исключающее ИЛИ». Блоки диаграммы, подлежащие декомпозиции, построены с помощью элемента Call Activity, а те, которые уже имеют дочерние диаграммы, обозначены символом «плюс», как блок «Оформление документов».
№ 1 (37) 2012
Рис. 4. Диаграмма деятельности для работы «Оформление документов«
В таблице 1 приведено сравнение выбранных нотаций описания бизнес-процессов.
При выборе подхода к описанию бизнес-процессов прежде всего необходимо различать две основные задачи моделирования бизнес-процессов: будет ли это проект по моделированию бизнес-процессов для целей их оптимизации и реинжинирин-
га либо на основании анализа бизнес-процессов предполагается дальнейшая разработка информационной системы для автоматизации деятельности предприятия. Так, в случае проекта по моделированию и реинжинирингу бизнес-процессов целесообразно выбрать нотацию, которая наиболее легко читаема, а результатные диаграммы не «перегружены» графическими элемента-
со
с
¿1
Рис. 5. Описание бизнес-процессов в нотации BPMN
17
№ 1 (37) 2012
ми. В проекте по автоматизации деятельности предприятия перед командой разработчиков встанут вопросы описания функциональных возможностей будущей системы, моделирования структур данных и архитектуры, генерации программного кода. В такой ситуации необходимо сделать выбор в пользу тех нотаций, которые помимо непосредственного отображения бизнес-процессов и их взаимосвязей поддерживают возможность иллюстрации объектов данных (для последующего проектирования структур данных), логики взаимодействия процессов (для более точной реализации требований к системе). В таблице 2 приведены рекомендации по этому выбору.
Актуальные вопросы выбора инструментальных средств моделирования бизнес-процессов
Нотация IDEF0 наиболее хорошо подходит для моделирования бизнес-процессов и их дальнейшего реинжиниринга. Существующие на рынке инструментальные сред-
ства достаточно хорошо поддерживают решение данных задач, к примеру, AllFusion Process Modeler (входящий в пакет программ AllFusion Modeling Suite) наиболее эффективно обеспечивает решение задач реинжиниринга бизнес-процессов, выбора наиболее оптимального варианта организации бизнес-процессов на основе анализа стоимости работ ABC (Activity Based Costing) и на основе свойств бизнес-процессов, определенных пользователем (UDP, User Define Properties). Использование пакета программ AllFusion Modeling Suite для разработки ИС ограничивается возможностью генерации модели данных в выбранную СУБД, что уже осуществляется в среде AllFusion ERwin Data Modeler. В AllFusion Process Modeler для каждой работы диаграммы IDEF0 могут быть описаны права на использование данных, причем объект модели данных также может быть создан непосредственно в данной среде и экспортирован в ERwin Data Modeler. Но отображения объектов данных на диаграммах IDEF0 нет.
Таблица 1
Сравнение основных возможностей нотаций описания бизнес-процессов
Нотация Возможность декомпозиции Исполнители бизнес-процесса Отображение логики взаимодействия работ Отображение объектов данных
IDEF0 Да, для всех блоков Да, стрелки, входящие в нижнюю грань Нет Нет
Activity Diagram (UML) Да, для элемента Structured Activity Области Partition Да, элемент Decision Да, элемент Data Store
BPMN Да, для элемента Call Activity Области Pool, Lane с возможностью иерархического деления Да, элементы Exclusive Gateway, Inclusive Gateway, Parallel Gateway Да, элементы Message, Data Store, Data Object
«
о §
0 &
Ú s
1 I
s
О
! S
s *
«
0
1 с
1 s <0 'S
I S
IS ¡
S
Таблица 2
Рекомендации по выбору используемой нотации описания бизнес-процессов
Нотация Проект по моделированию бизнес-процессов Проект по разработке ИС
IDEF0 Да Возможно
Activity Diagram (UML) Нет Да
BPMN Да Да
№ 1 (37) 2012
Построение диаграмм деятельности (Activity Diagram, UML) обычно является одним из этапов проектирования ИС и ведется в инструментальных средствах, ориентированных на разработку систем с последующей генераций программного кода, таких как IBM Rational Rose, IBM Rational Software Architect и Borland Together. Соответственно, данные средства не предусматривают возможность решения задач оптимизации бизнес-процессов, а описание бизнес-процессов с помощью диаграмм деятельности рассматривается как один из начальных этапов жизненного цикла ИС.
Перечень инструментальных средств, поддерживающих нотацию BPMN, представлен на сайте www.bpmn.org. Среди них имеются как полноценные CASE-средства, так и программы, ориентированные на оптимизацию бизнес-процессов предприятия. Так, Rational Software Architect с версии 7.5.4 стал поддерживать эту нотацию. Программный пакет BizAgi BPM Suite обеспечивает полную поддержку последней версии BPMN 2.0, а также реализует возможность исполнения смоделированных бизнес-процессов по цепочке Model-Execute-Improve (моделирование, исполнение, улучшение). Соответственно, нотация BPMN при использовании соответствующего инструментария одинаково хорошо подходит для решения любых задач моделирования бизнес-процессов.
Заключение
В статье были рассмотрены три нотации описания бизнес-процессов: IDEF0, Activity Diagram (UML) и BPMN. При проведении сравнительного анализа вышеперечисленных нотаций выявлены особенности их использования. Так, нотация IDEF0 не поддерживает иллюстрацию потоков данных и логику взаимодействия, а инструментальные средства построения подобного рода диаграмм подходят для целей моделирования и реинжиниринга бизнес-процессов. Однако отсутствие возможности реализации функциональных IDEF-моделей в объектно-ори-
S
ентированном программном коде сущест- | венно сужает диапазон решаемых с ее по- Ц мощью задач. Диаграммы Activity Diagram (UML) и BPMN поддерживают и описание ^ логики взаимодействия, и отображение объектов данных. Но функциональные возможности инструментальных средств построения Activity Diagram (UML) ориентированы на разработку программного обеспечения, в то время как с помощью инструментальных средств, поддерживающих нотацию BPMN, одинаково успешно можно решать задачи и по моделированию бизнес-процессов, и по автоматизации деятельности предприятия.
Список литературы
1. Алфимов Р. В. Зототухина Е. Б. Описание предметной области с использованием UML при разработке программных систем [Электронный ресурс]. Режим доступа: http://www.uml2.ru/index. php?option=com_content&task=view&id=17&Item id=2.
2. Артамонов И. В. Современные стандарты описания и исполнения бизнес-процессов [Электронный ресурс]. Режим доступа: http://ecm-journal.ru/docs/Sovremennye-standarty-opisanija-i-ispolnenija-biznes-processov.aspx.
3. Волков Ю. Диаграммы для описания бизнес-процессов [Электронный ресурс]. Режим доступа: http://www.pcweek.ru/idea/article/detail.php? ID=73249.
4. Новичков А., Карабанова Г. Моделирование бизнес-процессов автоматизируемой предметной области при помощи диаграмм деятельности (Activity diagram) с использованием RSA [Электронный ресурс]. Режим доступа: http://www.ibm.com/developerworks/ru/library/ r-rsa/index.html.
5. Романов М. Некоторые наиболее известные стандарты описания бизнес-процессов [Электронный ресурс]. Режим доступа: http://ecm-journal.ru/ blog/post/Nekotorye-naibolee-izvestnye-standarty-opisanija-biznes-processov.aspx.
6. Квартани Т., ПалистрантДж. Визуальное моделирование с помощью IBM Rational Software Architect и UML. Пер. с англ. М.: КУДИЦ-ПРЕСС. 2007. — 192 с.
