CC BY-NC-ND
180
СРАВНИТЕЛЬНЫЙ АНАЛИЗ ЯЗЫКОВЫХ СРЕДСТВ, ПРИМЕНЯЕМЫХ В МЕТОДОЛОГИЯХ БИЗНЕС-МОДЕЛИРОВАНИЯ
Э.А. Бабкин,
профессор Национального исследовательского унивеситета «Высшая школа экономики», В.П. Князькин,
студент магистратуры факультета «Бизнес информатика и прикладная математика» Нижегородского филиала НИУ ВШЭ,
М.С. Шиткова,
студент аспирантуры Нижегородского филиала НИУ ВШЭ,
Адрес: г. Нижний Новгород, ул. Большая Печерская, д. 25/12.
E-mail: eababkin@hse.ru.
Основной целью данной статьи является проведение критического анализа языковых средств моделирования бизнес процессов, на основе разработанного ранее авторами метода. Полученные результаты исследования помогут нам определить наиболее значимые функциональные возможности языковых средств, а также оценить их применимость к задаче моделирования административных регламентов. В заключении статьи будут представлены результаты сравнения методологий моделирования и определены шаги для будущих исследований данной предметной области.
Ключевые слова: бизнес-процесс, административное моделирование, языки моделирования, электронное правительство.
1. ВВЕДЕНИЕ
В течение последних пяти лет идет активное обсуждение базовых принципов изменения формы и методов работы органов государственной власти РФ в ходе реформы административного управления. Ключевую роль в решении этой задачи отводится современным информационным технологиям. Основой для эф-
фективного применения которых в целях поддержки административных реформ является совокупность информационных моделей, определяющих организационно-функциональную структуру органов власти, целевые установки, существующую и планируемую инфраструктуру. На основе таких моделей становится возможным разработка электронных регламентов, имитационное моделирова-
ние, комплексный анализ существующих административных регламентов и определение требований к разрабатываемым информационным системам.
Деятельность органов власти имеет специфику, которая не позволяет просто копировать традиционные методы информационного анализа и моделирования бизнес-процессов, известные в теории и на практике (методология ARIS, IDEF). Поэтому чрезвычайно актуальной становится задача объективного выбора адекватной методологии моделирования, позволяющей проводить дальнейшую модификацию в соответствии с принципиальными целями и задачами административного моделирования.
В этой работе с использованием ранее разработанного метода сравнительного анализа языковых средств и программного обеспечения [1] проводится сравнение нескольких методологий, наиболее известных в области бизнес-моделирования. Полученные результаты исследования позволяют определить наиболее значимые функциональные возможности языковых средств моделирования бизнес процессов, а также оценить их применимость к задаче моделирования административных регламентов.
2. СРАВНЕНИЕ ЯЗЫКОВ И ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
2.1. Языки моделирования организационной структуры
2.1.1 ARIS. Organizational chart
Методология ARIS предполагает описание организационной структуры с помощью создания диаграммы (Organizational chart), представляющей собой древовидную структуру компании, отображающую должности, отделы, конкретных людей и т.п. [2,3]
Модель строится из объектов «Organizational unit», «Position», «Internal person» и др. Заложенные в нотацию виды связей позволяют отразить различные виды отношений между объектами организационной структуры. Иерархия подразделений строится при помощи связей типа «is composed of». Кроме того, могут быть указаны должности — «Position» и фамилии реальных сотрудников, их занимающих: «Internal person», а также тип связи «occupies».[3]
Нотация не поддерживает добавление атрибутов к элементам диаграмм. Подобная функциональность могла бы сделать модель более наглядной, заменив некоторые типы связей, к примеру «occupies»
на атрибут «занимаемая должность». Также в Organizational chart отсутствует явное разделение на роли.
В целом, можно сказать, что нотация Organizational Chart методологии ARIS не очень проста для понимания, не слишком наглядна и избыточна за счет наличия множества видов связей и объектов. На одной диаграмме одновременно отображается и модель и мета-модель (должности и фамилии реальных сотрудников вместе с типами объектов).
2.1.2 PICTURE.
Organizational list
Как таковой графической нотации построения организационной диаграммы в методологии PICTURE [8,9] не существует, хотя программный продукт для моделирования деятельности организации предоставляет возможность описать орг. структуру при помощи составления иерархического списка сотрудников, с указанием должностей и организационных подразделений.
Функциональность, предоставляемая методологией, проста для понимания, но не слишком наглядна, так как отсутствует графическое представление. Явным плюсом в данной нотации является возможность добавления большого количества атрибутов к элементам, например, средней почасовой оплаты сотрудника.
2.1.3 ГосМастер.
Организационно-функциональная модель
Методология, лежащая в основе Гос-Мастера, предполагает описание организационной структуры с помощью создания иерархически упорядоченной и взаимосвязанной системы организационных звеньев и представлена в виде организационнофункциональной модели (ОФМ) организации.
ОФМ — это электронная модель, в которой с помощью классификаторов (определяющих смысловой содержание понятний модели) отражены организационная структура, функции, исполняемые ОГВМС в установленных сферах деятельности, и распределение ответственности за их реализацию по организационным звеньям [4,7]. В ОФМ используется классификаторы: административно-штатная структура, ролевая структура и сотрудники.
Административно-штатная структура отражает оргструктуру органа власти на уровне структурных подразделений, отделов и должностей. Ролевая
структура содержит как постоянные и ситуативные роли. Классификатор сотрудники отображает личный состав сотрудников подразделений органа власти и должностных лиц.
В целом, наглядность нотации, представленной в методологии Гос-Мастер, и доступность ее для понимания не вызывает каких-либо сомнений. С точки зрения «избыточности» модели, в Гос-Мастере существует ряд ограниченных и однозначных функциональных блоков. Возможность добавления различных видов атрибутов к классификаторам уточняет их и делает модель более информативной.
2.2. Языки моделирования функциональной структуры
2.2.1 ARIS. Function Tree
В методологии ARIS для описания основных функций организации используется нотация Function Tree. [3]
Функции представляются в виде дерева, где на самом верхнем уровне описываются наиболее сложные функции. В последствии производится декомпозиция до базовых функций, находящихся на нижнием уровне дерева. Нотация поддерживает различные виды связей между функциями (подчиняется по способу выполнения; подчиняется по объекту; подчиняется по процессу) [3], но это не является большим плюсом. Данный аспект, скорее можно отнести к избыточности методологии.
В целом языковое средство Function Tree достаточно просто для понимания и наглядно, даже не смотря на некоторую избыточность с точки зрения различных видов связей и отсутствия атрибутов.
2.2.2 IDEF. IDEF0
Методология IDEF предполагает описание функциональной модели организации с помощью стандарта IDEF0, представляющего систему в виде набора взаимосвязанных функций.
В основе IDEF0 лежит четыре основных понятия:
♦ Функциональный блок, представляющий собой конкретную функцию в рамках рассматриваемой системы. Существует четыре типа объектов, применяемых для описания входов и выходов: inputs (входы), control (управление), outputs (выходы) и mechanism (механизм).
♦ Интерфейсная дуга отображает элемент системы, обрабатываемый функциональным блоком или оказывающий влияние на функцию, отображенную функциональным блоком.
♦ Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. Уровень детализации процесса определяется непосредственно разработчиком модели.
♦ Глоссарий набор определений, ключевых слов и т.д., которые характеризуют объект, отображенный элементом.
Графический язык IDEF0 достаточно прост и гармоничен, однако степень наглядности и доступности построенных моделей не высока. Отсутствует возможность добавления атрибутов к элементам модели.
2.2.3 ГосМастер.
Организационно-функциональная модель
Методология Гос-Мастер предполагает описание функциональной модели организации с помощью организационно-функциональной диаграммы (ОФМ)[4], состоящей из классификаторов: сфера деятельности, функция, программная деятельность, проекты, административные действия.
Созданные классификаторы и проекции достаточно наглядны и просты для понимания всем пользователям системы. Более точная конкретизация функциональных особенностей системы достигается посредством декомпозиции определенных функций.
2.3. Языки моделирования бизнес-процессов
2.3.1 ARIS. eEPC (extended Event Process Chains)
еEPC — гибкий язык моделирования, лежащий в основе описания структуры процессов в методологии ARIS [2], являющийся расширением языка ЕРС.
Как сказано в [5] «EPC — это направленный граф событий и функций, содержащий различные логические коннекторы, которые позволяют моделировать альтернативный и параллельный ход процессов. Выполнение процесса определяется логическими операторами OR, AND и XOR. Главным достоинством EPC является простота использования и понимания.»
Однако зачастую модели, построенные с помощью данной методологии являются достаточно громоздкими и запутанными, так как в языке представлен слишком ограниченный набор элементов.
Громоздкость моделей делает их сложночитаемыми и трудно визуализируемыми.
Основными элементами ЕРС являются события и функции. События описывают начальные и конечные состояния функции, которая моделирует задачи в процессе. Наличие событий позволяет осуществить проверку логической правильности создания моделей — если событие после функции не несет определенной смысловой нагрузки, то функция является лишней. [3]
Нотация еЕРС поддерживает декомпозицию функций на более низкие уровни (создание иерархических функций), а также добавление организационных элементов, определяющих роль, ответственную за выполнение определенной функции. Организационную составляющую процесса можно представить с помощью 8ш1ш1апе$, расположив их вертикально или горизонтально.
Существует возможность отображения материальных и документальных потоков, но не поддерживается их классификация по различным типам (например, заявки, внутреннюю документацию, документы, поступившие от клиентов и т.п.). Есть возможность добавления аннотаций к объектам, но не атрибутов.
2.3.2 IDEF. IDEF3
IDEF3 — подход к описанию процессов, рассматривающий последовательность выполнения и причинно-следственные связи между ситуациями и событиями.
IDEF3 предназначен для описания бизнес -процессов нижнего уровня и содержит объекты
— логические операторы, с помощью которых показывают альтернативы и места принятия решений и в бизнес-процессе, а также объекты — стрелки, с помощью которых показывают временную последовательность работ в бизнес-процессе.
Нотация не является интуитивно понятной, что представляет сложность для пользователей, не являющихся экспертами в области моделирования
Одним из основных принципов моделирования является декомпозиция — на диаграмме не должно быть более 5-7 функций, чтобы она не была перегруженной. Данный принцип предполагает наглядность получившихся моделей.
Нотация не предоставляет возможности отображения организационной структуры и информационных объектов, участвующих в процессе.
2.3.3 DEMO. Process Model
В методологии DEMO для описания бизнес-процессов используется Process Model [14, 15].
Описание процессов (ОП) организации описывает пространство состояний и пространство переходов в К-мире (К-мир (координационный)
— это один из двух миров, в котором акторы в организации производят изменения [16]). ОП также описывает для каждого шага процесса информацию, используемую для исполнения этого шага. В качестве удобного дополнения, ОП повторяет сведения из ОК о том, какая акторная роль исполняет своё обязательство. Эти сведения определяют области ответственности для каждой ак-торной роли.
Наиболее специфичной чертой описания процессов несомненно является изображение глубинной структуры процессов в организации, вне зависимости от того, как они реализованы [15]. Это резко отличает ОП от традиционных подходов к описанию процессов, таких как IDEF3, сети Петри или eEPC. На самом деле, то, что получается в результате применения этих подходов, вряд ли даже заслуживает названия «деловых процессов» (business process), потому что это какие-то другие процессы, никоим образом не учитывающие социальной природы организации [16, 17].
2.3.4 UML. Activity Diagram
UML Activity Diagram часто используется в качестве инструмента моделирования бизнес-процессов, а также логики сценария вариантов использования программных продуктов. Во многих случаях диаграммы активности UML являются объектно-ориентированными аналогами диаграмм потоков данных и блок схем языка UML.
По набору функциональных элементов UML Activity Diagram практически идентичен нотации EPC, но не поддерживает концепт данных и промежуточных состояний.
2.3.5 PICTURE. PICTURE
PICTURE — это предметно-ориентированный язык моделирования процессов, специфичных для сектора государственного администрирования [8,9]. Использование данной методологии предоставляет возможность моделирования всего множества процессов, существующих в организации [8].
Основной конструкцией PICTURE является набор из 24 блоков, представляющих собой функции в области государственного управления. Каждый блок имеет свой тип, характеризующий семантику функции. Специфичные свойства и дополнительные факты для блока определяются атрибутами блока.
Данные в модели представлены с помощью концепции обрабатываемого объекта, также имеющего определенный тип, что позволяет произвести классификацию данных.
Альтернативное выполнение процесса реализовано с помощью «вариантов». С применением данного подхода появляется возможность отображать статистику о частоте использования каждого варианта.
Нотация предполагает наличие хотя бы одного подпроцесса (выполняется определенной ролью) для каждой модели, что поддерживает принцип декомпозиции.
2.3.6 ГосМастер. Модель Административного процесса
Для описания и моделирования процессов в методологии Гос-Мастер [4] используется классификатор Административный процесс, имеющий тесную взаимосвязь со многими классификаторами общей моделируемой системы организации таких, как: Организационно-штатная структура, Ролевая структура, Функции и т.п. Связь осуществляется с помощью средства описания — проекция.
Описание процессов осуществляется непосредственно владельцами процессов, а не специалистами в бизнес-моделировании. В связи с этим, создаваемые модели удобны для понимания и визуального представления.
2.4. Языки моделирования структуры данных
2.4.1 ARIS. eERM (extended Entity Relationship Model)
В качестве нотации для моделирования структур данных в методологии ARIS используется расширенная модель «сущность-связь» — eERM. Основной целью построения модели данных является отражение структуры информации, которая обрабатывается в бизнес-процессе организации [5].
Нотация позволяет выполнять классификацию типов сущностей, идентифицируя и ассоциируя
их в соответствии с определенными признаками. Один объект будет идентичным другому, если он описан теми же свойствами [5]. Но подобная функциональность не отражает в полной мере нужной в нашем случае логики.
Нотация ERM, лежащая в основе eERM, используемой в ARIS является широко применяемой для создания модели данных. Она проста для понимания и достаточно наглядна. Нотация еERM наиболее часто используется при детальном проектировании баз данных, когда требуется указать все существующие сущности вместе с атрибутами и связями. Для задачи административного моделирования хотелось бы использовать более упрощенный вариант языковых средств, позволяющих моделировать структуру данных на более высоком уровне абстракции.
2.4.2 DFD
Диаграммы потоков данных (Data Flow Diagram) используются для документирования механизмов передачи и обработки информации в моделируемой системе. Диаграммы DFD обычно строятся для наглядного отображения текущей работы системы документооборота организации.
Диаграмма потоков данных дает общую картину того, какие данные используются и какие функции выполняются системой документооборота и позволяет выявить слабые места организации.
Нотация DFD эффективно применяется для описания как потоков документов, так и потоков материальных ресурсов (в том числе на одной и той же диаграмме).
2.4.3 DEMO. State Model
К методу описания модели данных в подходе DEMO можно отнести так называемую модель описания состояний (State Model) с тесной привязкой к модели описания процессов (Process Model).
Описание состояний (ОС) является источником знания о «продуктивном» мире [14]. Это делает его на практике очень подходящей к нескольким основным приложениям:
♦ ОС является идеальным исходным пунктом разработки и поддержки словаря данных организации. Оно поставляет стабильное ядро такого словаря, обеспечивая не только концепты (понятия), важные для организации, но и помогая определить наилучшие концепты.
♦ В отличие от традиционных моделей данных, описание состояний строится вокруг основных типов объектов, в основном являющихся категориями. Эти типы объектов входят в качестве переменных в типы результатов отдельных типов трансакций. Эта особенность способствует проектированию баз данных, основанному на конкретных типах результатов. Таким образом, описание состояний предельно важно для подходов быстрой прикладной разработки (RAD).
♦ Соединение типов результатов с типами создающих их трансакций обеспечивают основу для осмысленного обсуждения вопросов владения данными.
2.4.4 UML.
Диаграмма классов
Диаграмма классов языка UML описывает структуру проектируемой информационной системы, демонстрируя ее классы, их атрибуты, методы и зависимости между классами [14].
Нотация предоставляет возможность отображения различных видов связей между сущностями, но отсутствует возможность их классификации.
Диаграмма классов UML на наш взгляд является не слишком подходящей для рассматриваемой задачи, так как данное языковое средство предо -ставляет возможности слишком детального проектирования данных, что является излишним. В тоже время отсутствует возможность классификации сущностей и атрибутов.
2.4.5 PICTURE
Концепция данных представлена в модели процессов с помощью обрабатываемого объекта. Обрабатываемый объект описывает с «чем» имеет дело определенный функциональный блок и что является результатом выполнения административного процесса. [8] Обрабатываемый объект описывает информацию, документы, сообщения, имеющие отношение к выполняемой функции.
Обрабатываемый объект имеет некоторый набор атрибутов (название, количество страниц, способ получения и т.п.), и определенный тип (документ, сообщение), позволяющий выполнить классификацию объектов.
Очевидным недостатком нотации является невозможность создания отдельной модели. Это же является причиной отсутствия явных связей между элементами данных.
Доступность для понимания и простота использования достаточно высока. Язык PICTURE является предметно-ориентированным, поэтому классификация объектов и существующие атрибуты позволяют наиболее полно описать предметную область.
3. АНАЛИЗ
В второй части статьи подробно были рассмотрены языковые средства каждой из анализируемых методологий. Для получения общей оценки методологии в соответствии с выбранными критериями оценки было решено проставить числовые оценки по каждому из критериев для каждой нотации методологии.
Шкала оценки была выбрана от 0 до 2, где 0 — полное не соответствие критерию, а 2 — полное соответствие. Оценки были выставлены на основе мнения авторов статьи и мнения экспертов в области бизнес-моделирования.
Для подсчета общей оценки методологии каждому из критериев был назначен вес равный 1, в случае, если критерий носит положительный характер, или -1, в случае отрицательного характера критерия. В последствии можно пересмотреть веса критериев в соответствии с их важностью для области применения методологии.
В табл. 1 представлены оценки нотаций для создания организационных моделей. Лучшей по результатам оценки является PICTURE, хотя как таковой нотации в методологии и нет.
В табл. 2 представлены оценки языковых средств для создания функциональных моделей. Лучшими оказались методологии IDEF и ГосМа-стер, языковые средства, применяемые в данных методологиях являются более наглядными и понятными, нежели функциональная модель методологии ARIS.
С точки зрения моделей бизнес-процессов (табл. 3) наиболее удобной является методология PICTURE. В ней же лучше всего представлена модель данных (табл. 4). Нотация, используемая в методологии понятна, удобна, проста в использовании и отражает все необходимые аспекты моделирования.
С точки зрения программного обеспечения, наиболее подходящим, с учетом цены, фукнциональ-ных возможностей, удобства пользования и т.п., является платформа ARIS (табл. 5.).
Таблица 1.
Оценки языковых средств для моделирования оргструктуры.
Доступность для понимания
ARIS
(Organizational
chart)
1\1/А
DEMO
(Constructional
Model)
\А
PIKTURE ГосМастер
(Organizational (ОФМ)
List)
\А
2
1
Наглядность получившейся модели
\А
И/А
И/А
Избыточность
И/А
И/А
\А
Возможность создания иерархий
И/А
И/А
И/А
Возможность реализации, типов связей между элементами
И/А
И/А
И/А
Разделение на роли
И/А
\А
И/А
Разделение на отделы
И/А
И/А
И/А
Разделение на должности
И/А
И/А
И/А
Отображение конкретных сотрудников организации
И/А
И/А
И/А
Возможность добавления атрибутов
И/А
И/А
И/А
Сумма с учетом весов
12
МЛ
N/A
N/A
13
13
2
0
2
2
2
2
0
2
0
2
2
2
2
2
2
2
2
2
2
0
2
Таблица 2.
Оценки языковых средств для моделирования функциональной структуры
Вес ARIS (Functional List) IDEF (IDEF0) | DEMO UML PIKTURE (Organizational List) ГосМастер (ОФМ)
Доступность для понимания 1 2 1 N/A И/А 1\/А 1
Наглядность получившейся модели 1 2 1 N/A И/А 1\/А 1
Избыточность -1 1 1 N/A И/А 1\/А 1
Возможность выполнения декомпозиции 1 0 2 N/A И/А 1\/А 2
Возможность добавление атрибутов 1 0 1 N/A И/А 1\/А 1
Сумма с учетом весов 3 4 N/A N/A 4
11587723
Таблица 3.
Оценки языковых средств для моделирования бизнес-процесов
Вес ARIS (eEPC) IDEF (IDEF3) DEMO (Process Model) UML (Activity Diagram) PICTURE ГосМастер (Модель администра- тивного процесса)
Доступность для понимания 1 1 1 2 2 2 1
Наглядность получившейся модели 1 1 2 2 2 2 1
Избыточность -1 1 1 2 0 0 1
Возможность выполнения декомпозиции 1 2 2 2 2 2 2
Отображение организационных элементов (с помощью Роо!з/8ш1т1апе) 1 2 0 2 2 0 2
Отображение информационных объектов 1 2 0 2 0 2 1
Возможность добавления атрибутов 1 0 1 2 0 2 1
Сумма с учетом весов 7 5 10 8 10 7
Оценки языковых средств для моделирования структуры данных
Таблица 4.
Доступность для понимания
ARIS IDEF DEMO UML PICTURE ГосМастер
(eEPC) (DFD) (State Model) (Class Diagram)
И/А
Наглядность получившейся модели
И/А
Избыточность
И/А
Возможность классификации данных
И/А
Поддержка.видов связи между элементами
И/А
Возможность добавления атрибутов
И/А
Сумма с учетом весов
МЛ
2
2
2
2
0
0
0
0
2
2
2
2
2
0
2
2
2
2
6
5
5
5
7
11587723
Таблица 5.
Оценки программного обеспечения, одерживающего выбранные методологии
Вес ARIS (ARIS Platform) IDEF (CA ERwin Process Modeler) DEMO (XeMod Modeler) UML (Rational Software Architect) PIKTURE ГосМастер (ПМК Гос-Мастер)
Полная стоимость владения 1 0 0 1 1 0 2
Наличие локализации 1 2 2 0 2 0 2
Сопровождение 1 2 2 1 2 0 1
4. ВЫВОДЫ
Основнью целью нашего исследования являлось рассмотрение и анализ выбранных языковых средств бизнес-моделирования. Анализ методик моделирования проводился в соответствии с выбранными нами критериями. Объектом сравнения являлся набор моделей, которые наиболее важны при моделировании бизнес-процессов организации, а также программные продукты, которые поддерживают рассмотренные нотации бизнес-моделирования. Анализ проводился с учетом того, что основной областью применения данных методик является государственный сектор, который имеет некоторые особенности и специфику моделирования процессов организаций.
В качестве предмета проведения исследования были выбраны методологии общей направленности: ARIS, IDEF, UML, и предметно-ориентированные: PICTURE и Гос-Мастер.
Итоговые результаты сравнения можно увидеть на графике (рис. 1).
Если более подробно рассмотреть таблицу сравнения методологий, то можно сделать вывод, что каждая методология имеет свои недостатки и преимущества. Стоит особо отметить и тот факт, что предметно-ориентированные методологии, которые создавались для решения определенного типа задач (административного моделирования) имеют сравнительное преимущество в рамках локализации под конкретные нужды, наглядности и
ОЦЕНКИ МЕТОДОЛОГИЙ
45
40
35
30
25
20
15
10
5
0
1 1—
У hr ll_l HI и
1 п г-. -г 1 - II i 1 ï
ш
Тип модели
Рис. 1. Итоговые результаты сравенния яыковых средств и программного обеспечения.
■ ARIS
□ IDEF
□ DEMO
■ UML
□ PICTURE
□ CD О ГО S О О
зельский комитет по банковскому надзору. Высшее руководство как финансовых, а в последнее время все чаще и нефинансовых структур, все большее внимание уделяет развитию системы управления операционными рисками. Причиной этого является, во-первых, снижение операционных потерь
— это повышение эффективности бизнеса. Во-вторых, управление операционными рисками (ОР)
— один из способов управления изменениями предприятия, осуществляемый через совершенствование бизнес-процессов и технологий. Ведь уровень ОР есть мера качества любого бизнес-процесса, а главным фактором риска является несовершенство применяемых предприятием технологий. Операционный риск критичен для тех направлений бизнеса таких крупных коммерческих компаний, которые характеризуются:
♦ долгосрочными контрактными обязательствами;
♦ значительными объемами поставок;
♦ большими оборотами денежных средств;
♦ высокой степенью внутренних изменений;
♦ сложной системой технической поддержки.
Таким образом, отечественным компаниям, осуществляющим внешнеэкономическую деятельность (экспортно-импортные операции с стратегически важными сырьевыми товарами) необходимо внедрять процедуры управления операционными рисками. Внешнеэкономическая деятельность осуществляется на основе контракта и регулируется законами «О государственном регулировании внешнеторговой деятельности»; «О валютном регулировании и валютном контроле»; «О таможенном тарифе»; «Об иностранных инвестициях»; «Таможенный кодекс Российской Федерации». Мировой опыт свидетельствует о том, что даже в промышленно развитых странах существует объективная необходимость государственного регулирования внешнеэкономической деятельности. Государство призвано, прежде всего, защищать интересы своих производителей, принимать меры для увеличения объемов экспорта, привлечения иностранных инвестиций, сбалансирования платежного баланса, валютного регулирования, и, что особенно важно, — принимать законодательные акты, устанавливающие правила осуществления ВЭД, и контролировать их неукоснительное соблюдение.
Следовательно, недостаточное внимание к управлению операционными рисками такой Компании может привести как к убыткам вследствие невы-
полнения полностью или частично контрактных условий с Контрагентом, так и к убыткам вследствие нарушения действующего Законодательства.
Определение операционного риска
Операционный риск — это широкое понятие, включающее в себя множество факторов — технических, финансовых, человеческих. Эффективность деятельности компании определяется эффективностью бизнес-процессов, которая, в свою очередь, во многом определяется их сопровождением. Современные бизнес-процессы сложны и в разработке, и в поддержке. Поэтому от того, насколько эффективно они контролируются и сопровождаются, зависит большинство операций.
Существует множество определений операционного риска, но все они сводятся к тому, что операционный риск — это риск возникновения прямых и/или косвенных убытков в результате ошибок или намеренных действий сотрудников, недостатков внутренних процедур, технологических сбоев, функционирования информационных систем и технологий, а также вследствие воздействия внешних событий непосредственно направленных на Компанию.
Исходя из внешнеэкономической деятельности Компании, различают следующие операционные риски, возникающие в рамках внешнеторговых сделок по обеспечению выполнения контрактных обязательств:
■ф’ риск персонала — риск возникновения потерь, связанных с недостаточной компетенцией сотрудников, задержками и/или неисполнением своих обязанностей и внутренних положений Компании;
Ф риск технический — риск возникновения потерь, связанных со сбоями и ошибками в программном обеспечении, остановками или сбоями в работе 1Т, систем передачи информации, внутренними инцидентами в сфере информационной безопасности, остановками и сбоями коммуникационных систем, безопасности здания;
Ф технологический риск — риск возникновения потерь, связанных с ошибками при разработке инструкций, политики, регламента и бизнес -процессов, нечеткой регламентации должностных прав и обязанностей;
Ф иные риски — риски возникновения потерь, связанных с юридическими рисками (несовершенство
законодательства, влияние регулирующих органов и несоответствие документов Компании законодательству), криминалом, прочими угрозами, исходящих из внешней среды, связанные с техногенными и природными катаклизмами.
При управлении ОР возникает несколько концептуальных проблем.
Во-первых, в отличие от рыночного и кредитного рисков, ОР является внутренним риском для Компании, что определяет его специфику. Практически невозможно собрать обобщенную информацию о таких потерях.
Во-вторых, рыночный и кредитные риски можно количественно измерить, определить их вероятность, размер ущерба, а также степень влияния отдельных факторов. В случае ОР такую взаимосвязь нелегко установить. Поэтому операционный риск-менеджмент в меньшей степени использует количественные методы анализа, а основывается преимущественно на создании системы внутреннего контроля и внутренней инфраструктуры для предотвращения таких рисков вообще.
В-третьих, значительные операционные потери -относительно редкое явление (но возможное). Такие маловероятные события находятся «в хвосте» статистического распределения, т.е. за пределами разумного доверительного интервала. В связи с этим использование статистических методов, таких как operational value at risk, является проблематичным из-за малой репрезентативности данных для анализа.
Таким образом, применение статистических моделей для управления ОР весьма ограничено. Однако эти риски можно минимизировать путем повышения контроля за всеми сферами деятельности Компании и разработки грамотных процедур осуществления бизнес-процессов.
Для анализа и оценки ОР рассматриваемой Компании применялась восходящая модель (bottom-up model), разработанная «снизу вверх», с точки зрения подразделений и бизнес-процессов. Основное внимание уделялось причинам возникновения ОР, которые могут привести к негативным последствиям.
Анализ операционных рисков включает идентификацию рисков и их описание.
Идентификация рисков — процесс выявления рисков, характерных для определенного вида деятельности Компании, и определения их характеристик.
Анализ и оценка бизнес-среды Компании
В основе качественной оценки операционных рисков лежит методика экспертной оценки риска, представляющая собой алгоритм принятия решений о степени рискованности параметров внутренней бизнес-среды Компании:
Параметры бизнес-среды:
♦ Бизнес-Линия — это направление внешнеэкономической деятельности Компании, в результате которой Компания получает доход.
♦ Бизнес-процесс — это специфически упорядоченная во времени и пространстве совокупность действий (работ, заданий), проводимых для достижения поставленных целей или исполнения установленных функций подразделения (задач сотрудника), с указанием начала и конца, точным определением входов и выходов.
♦ Бизнес-функция — логически завершенное и функционально обособленное действие (работа, задание), являющееся составной частью бизнес-процесса, проводимое конкретным сотрудником (подразделением) Компании. В реализации бизнес-функции могут участвовать одновременно несколько сотрудников.
Для оценки внутренней бизнес-среды Компании строится бизнес-карта. Вся деятельность Компании разбивается на основные направления (Бизнес-Линии). Бизнес-карта представляет собой структурную модель бизнес-процессов и бизнес -функций для каждой Бизнес-Линии. Построение модели бизнес-процессов осуществляется по итогам интервьюирования структурных подразделений, задействованных в реализации Бизнес-Линии. Для дальнейшей идентификации операционных рисков все бизнес-процессы группируются в блоки по видам деятельности в рамках рассматриваемой Бизнес-Линии. Далее проводится категоризация и оценка блоков по степени критичности их влияния на бизнес Компании. Критериями для оценки степени критичности влияния блоков на бизнес Компании являются результаты операционных событий, возникающих при реализации бизнес-процессов, входящих в рассматриваемый блок. Одной из типичных методологических ошибок идентификации ОР является попытка собрать и «задокументировать навсегда» ВСЕ возможные риски Компании. Такой подход к решению задачи идентификации и оценки ОР нецелесообразен и зачастую ведет к необоснованным трудозатратам. Конструктивным представляется подход последо-
удобства визуального представления бизнес процессов, более четкой и прозрачной реализации организационной структуры и т.п. перед универсальными методологиями. Но с другой стороны,
общеизвестные методологии имеют преимущества с точки зрения поддержки методологий теоретической базой, формальной семантикой и практическим применением в реальных проектах. ■
Литература
1. Бабкин Э.А., Князькин В.П., Шиткова М.С. Разработка метода проведения сравнительного анализа языков бизнес-моделирования //Бизнес-Информатика №3(13) — 2010 г с.41-46
2. Репин В. ARIS Toolset/BPwin: выбор за аналитиком // КомпьютерПресс.-2002.-№1
3. Davis R., Brabandere E. ARIS Design Platform. Springer; London, 2007. 364p
4. Методология и инструменты административного моделирования/ [Д.В. Кудрявцев и другие]. — М. — 2007. 61с.
5. Моделирование бизнеса. Методология ARIS. / Каменнова М., Громов А., Ферапонтов М., Шматалюк А.//|МетаТехнология, 2001. 327 с.
6. CA’s official web-site [Электронный ресурс]. — Режим доступа: http://www.ca.com (Дата обращения: 15.12.09)
7. Официальный сайт федеральной целевой программы «Электронная Россия» [Электронный ресурс]. — Режим доступа: http://www.elrussia.ru/orgmodel (Дата обращения: 15.12.09)
8. Becker, J. Pfeiffer, D. and Ackers, M. A Process Modeling Language for the Public Sector — the PICTURE Approach.// Wybrane Problemy Elektronicznej Gospodarki, Lodz. — 2007. — p. 271-281.
9. Becker J., Bergener P., Pfeiffer D. Migrating Process Models between PICTURE and BPMN/EPC.// Wybrane Problemy Elektronicznej Gospodardsky; Lodz, 2008. — p. 260-270.
10.0bject Management Group. UML 2.2 Superstructure Specification [Электронный ресурс]. — Режим доступа: http://www.omg.org/spec/UML/2.2/Superstructure/PDF/ (Дата обращения: 20.01.10)
11.PICTURE Group, Group Final Project Documentation [Электронный ресурс]. — Режим доступа: http:// www.picture-eu.org/deliverables/deliverables_wp7.shtml (Дата обращения: 10.01.10)
12.IDS Scheer Groups’ official web-site [Электронный ресурс]. — Режим доступа: www.ids-scheer.com (Дата обращения: 26.12.09)
13.IBM’s official web-site [Электронный ресурс]. — Режим доступа: http://www.ibm.com/ (Дата обращения: 25.12.09)
14.Dietz J.L.G. Enterprise Ontology and Enterprise Architecture — how to let them evolve into effective complementary notions // GEAO Journal of Enterprise Architecture. — March 2007. — vol. 2, nr. 1 p. 210 — 262
15.Dietz J.L.G. Enterprise Ontology and Enterprise Architecture — how to let them evolve into effective complementary notions // GEAO Journal of Enterprise Architecture. — March 2007. — vol. 2, nr. 1. p. 121 — 149
16.Dietz J. Enterprise Ontology: Theory and Methodology. N. Y.: Springer, 2006. 243p.
17.A. van Renssen. A Generic Extensible Ontological Language: Design and Application of a Universal Data Structure. Delft University; Delft : Delft University Press, 2005. 238p.
