Описание нотации ARIS еЕРС. Общая структура методологии ARIS. Типовые задачи описания бизнес-процессов

Владимир Репин

Генеральный директор ООО «Владимир Репин Менеджмент»

Член ABPMP Russia

Консультант по управлению

Бизнес-тренер

Кандидат технических наук

Во многих современных системах класса Business Process Management (BPMS) для описания «исполняемых» процессов применяется спецификация BPMN (версия 1, 2). Эта спецификация является, вероятно, лучшей для целей формализации автоматизируемых процессов. Однако для описания и регламентации процессов, исполняемых людьми, она является слишком сложной так же, как и некоторые другие нотации, появившиеся ранее.

В статье рассмотрены проблемы выбора нотаций, адекватных задаче описания и регламентации процессов, исполняемых людьми. Выполнено сравнение нотации ARIS eEPC, «простой блок-схемы » в MS Visio и «Процедуры» Business Studio.

Делаются выводы о целесообразности выбора нотации для комплексного описания и регламентации процессов компании.

Введение

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

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

Если цели проекта сформулированы нечетко, то выбор нотации, скорее всего, будет выполнен ошибочно. Рассмотрим, в качестве примера, следующую формулировку: «Мы хотим описать и автоматизировать наиболее важные бизнес-процессы в BPMS, регламентировать работу всех сотрудников компании и описать требования для доработки существующего программного обеспечения». Такая фраза содержит несколько совершенно разнородных задач:

Описание исполняемых процессов в рамках системы BPM;
Регламентация деятельности сотрудников при помощи внутренних нормативно-методических документов (т. е. создание регламентной базы);
Описание требования к программному обеспечению.

При такой постановке задачи придется, скорее всего, использовать несколько нотаций: BPMN, некоторую нотацию типа Work Flow и, возможно, UML. Использовать какую-то одну нотацию и один инструмент моделирования для эффективного решения этих разнородных задач на практике вряд ли получится.

Нотация BPMN является наиболее удобной (в ряду существующих в настоящее время) для описания «автоматически исполняемых» процессов. Но она не удобна для создания относительно простых схем в регламентирующих документах для сотрудников по следующим причинам:

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

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

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

Нотация ARIS eEPC

Нотация ARIS eEPC была одной из первых нотаций, получившей широкую известность на российском рынке. Она относится к нотации типа Work Flow (поток работ). Особенностями нотации является наличие элементов типа «событие» и наличие операторов логики: «и», «неисключающее или», «исключающее или» (см. Рис. 1).

Рис. 1. Схема процесса в нотации ARIS eEPC

В своем полном варианте, нотация ARIS eEPC содержит очень большое количество графических элементов. Поэтому при выполнении проектов создаются так называемые «методические фильтры» (в рамках «соглашений по моделированию»), которые ограничивают количество типов элементов, доступных пользователям при создании схем процессов. (В некоторых средствах моделирования нотация ARIS eEPC сразу реализована с минимально необходимым набором элементов). Однако даже в этом случае, неопытные пользователи создают схемы такой сложности, которые потом невозможно однозначно воспринять. К таким схемам требуется подробный текстовый комментарий (либо наличие аналитика, способного объяснить схему).

Почему возникает такой эффект? Он является результатом описания множества ветвлений, возникающих при выполнении процесса, при помощи формальных логических операторов. Делать это приходится, придерживаясь определенных строгих правил. В результате появляется громоздкая, формально правильная, но плохо воспринимаемая схема.

Возникает вопрос: а за что, собственно, боролись? Типичная схема в ARIS eEPC:

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

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

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

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

«Простая блок-схема »

Нотация «простая блок-схема » реализована в популярном офисном продукте MS Visio. На Рис. 2. показаны элементы этой нотации и фрагмент соответствующей схемы. В полном объеме рассматриваемая нотация применяется редко.

Вообще, в MS Visio представлено несколько нотаций типа «блок-схема» , которые являются достаточно сложными. Очевидно, по этой причине они не нашли широкого применения, хотя и были включены в набор нотаций, поставляемых с системой.

Нотация «простая блок-схема » в своем самом простом и часто используемом на практике варианте, содержит всего несколько элементов:

Процесс;
Решение;
Ручная операции (реже);
Документ;
Данные;
Стрелка (для отображения связей между объектами схемы).

При помощи рассматриваемой нотации можно показать потоки данных, если необходимо описывать процессы под задачу автоматизации. Но описывать «автоматически исполняемые» в BPM-системе процессы неудобно.

Рис. 2. Нотация «Простая блок-схема » в MS Visio

Рассмотрим некоторые особенности применения «Простой блок-схемы », в частности применение стрелок. На практике, сотрудники компании, формирующие схемы при помощи «Простой блок-схемы » придерживаются двух подходов:

Не именуют стрелки вообще;
Стараются присваивать стрелкам, связывающие элементы схемы, простые и понятные названия;

На Рис. 3 показан пример применения нотации «Простая блок-схема » в одной из компаний. Использованы все пять типов элементов. Тем не менее, схема выглядит вполне читаемой и понятной пользователю — сотруднику компании.

Нотация «Простая блок-схема » при использовании в компаниях часто подвергается различным вариациям:

Изменяется смысл элемента «решение»;
По-разному используют стрелки связей (именуют или не именуют и т. п.);
По-разному используют стрелки связей в сочетании с объектом «документ»;
Прочее.

Интересно, что нотация «простая блок-схема » в том или ином виде часто используется специалистами по менеджменту качества при описании процессов СМК.

Рис. 3. Пример схемы в нотации «Простая блок-схема »

Преимуществами нотации «Простая блок-схема » (с сокращенным до минимума количество элементов) являются:

Простота формирования графических схем процессов;
Интуитивная понятность схем сотрудникам (даже без специального обучения);
Минимальная потребность в обучении сотрудников;
Наличие доступных инструментов для описания процессов (MS Visio, MS Word).

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

Внутренний стандарт использования этой нотации;
Внутренний стандарт формирования, хранения и актуализации файлов со схемами процессов.

В целом, масштабное использование в компании нотации «Простая блок-схема » без современного средства моделирования представляется весьма неэффективным.

«Процедура» Business Studio

На Рис. 4 представлена схема, сформированная в нотации «Процедура» среды моделирования процессов Business Studio (Россия). В рассматриваемой нотации используются следующие условные обозначения:

Процесс;
Решение;
Событие;
Стрелка предшествования (как в классических нотациях класса Work Flow);
Стрелка потока объектов;
Сноска;
Внешняя ссылка.

При построении схем в нотации «Процедура» используются так называемые дорожки («кросс-функциональная» схема), что дает возможность описывать «сквозные» процессы компании.

На примере схемы процесса, представленного на Рис. 4, рассмотрим, каким образом используются стрелки на диаграмме. Стрелка, именованная как «План доставки на следующий день» имеет тип предшествования, т. е. показывает последовательность выполнения действий во времени. Но одновременно она визуально информирует сотрудника, читающего схему, какой документ передается между операциями процесса.

В среде моделирования Business Studio к стрелке можно привязать один или несколько документов. Они не будут видны непосредственно на схеме, но информация об этих документах может быть включена в регламентирующий документ в удобной форме (см., например, таблицу 1).

Рис. 4. Схема процесса в нотации «Процедура» Business Studio

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

На Рис. 4. видно, что по ходу процесса для повышения информативности схемы используются элементы-события («Ежедневно, в 9-00», «В течение дня», «12-00»). Таким образом, информацию о событиях можно показывать как виде специальных элементов, так и путем соответствующего именования стрелок.

Стрелка «Чистовой лист комплектации» с двойным наконечником, выходящая из соответствующей операции, отображает на схеме поток документов. Эта стрелка не осуществляет передачу управления от одной операции к другой, а служит только для обозначения потоков объектов или данных.

В целом, схема процесса в нотации «Процедура» при кажущейся простоте является весьма информативной и удобной для описания. Можно сформулировать следующие преимущества этой нотации (в случае ее использования в Business Studio):

Представлен минимально необходимый набор графических элементов для описания процессов типа Work Flow (поток работ);
Быстрота создания графических схем для целей регламентации;
Возможность повышения информативности схем процессов за счет гибкого использования событий и именованных стрелок (одновременно с возможностью привязки документов к стрелкам и последующей выгрузки информации в регламентирующих документах);
Схемы процессов просты и понятны всем сотрудникам даже без специального обучения;
Простота в обучении (нет необходимости привлекать дорогостоящих специалистов со стороны — обучение можно проводить силами сотрудников отдела орг. развития);
Схемы процессов являются кросс-функциональными, что удобно для описания «сквозных» процессов компании;
Можно выгружать и редактировать схемы в MS Visio (при необходимости).

Среда моделирования Business Studio позволяет достаточно быстро создавать процессную модель компании. Информация о процессах может быть выгружена из системы в виде регламентирующих документов в требуемом формате. Заметим, что в Business Studio есть возможность описывать процессы в нотации ARIS eEPC, нотации IDEF0 и нотации «Процесс» (см. руководство по системе).

В качестве дополнительного примера на Рис. 5. показан фрагмент более сложной схемы, выполненной в нотации «Процедура». Кстати, для повышения информативности стрелки, описывающие несоответствующие результаты («Комплект документов не полный», «Температурный режим нарушен» и др.), показаны красным цветом. Кроме того, на схеме приводятся дополнительные комментарии к некоторым операциям.

Таблица 1. Информация о процессе, представленном на Рис. 4

Рис. 5. Пример схемы в нотации «Процедура» в Business Studio

Выводы

В целом, нотация «Процедура» в версии, реализованной в среде моделирования Business Studio, является более удобной и понятной сотрудникам, чем нотация ARIS eEPC. Она позволяет быстро описывать и регламентировать процессы компании.

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

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

Конечно, можно заставить людей описывать процессы в любых нотациях при помощи совершенно разных средств моделирования, но затраты на внедрение таких нотаций/систем в организации могут быть весьма значительными. Чрезмерно сложная нотация и средство моделирования могут сделать методы процессного управления уделом узкого круга профессионалов из отдела организационного развития или ИТ-отдела, а преимущества процессного подхода не будут реализованы в полной мере.

Общая структура методологии ARIS

http://rudocs.exdat.com/docs/index-62596.html?page=3

Нотация ARIS eEPC расшифровывается следующим образом - extended Event Driven Process Chain – расширенная цепочка процесса, управляемого событиями. Нотация разработана специалистами компании IDS Scheer AG (Германия), в частности профессором Шеером. В следующей таблице 2.3.1 приводятся основные используемые в рамках нотации объекты.

Таблица 2.3.1 Объекты для описания бизнес-процессов в нотации ARIS eEPC.

Помимо указанных в Таблице 2.3.1 основных объектов, при построении диаграммы eEPC могут быть использованы многие другие объекты. На практике применение большого числа объектов различных типов нецелесообразно, так как это значительно увеличивает размер модели и делает ее плохо читаемой. Для понимания смысла нотации eEPC рассмотрим основные используемые типы объектов и связей. На рисунке 2.3.5. представлена простейшая модель eEPC, описывающая фрагмент бизнес-процесса предприятия.

Рис. 2.3.5. Простейшая модель в нотации eEPC

Из рисунка 2.3.5. видно, что связи между объектами имеют определенный смысл и отражают последовательность выполнения функций в рамках процесса. Стрелка, соединяющая Событие 1 и Функцию 1 «активирует» («activates») или инициирует выполнение Функции 1. Функция 1 «создает» («creates») Событие 2, за которым следует символ логического «И», «запускающий» выполнение Функций 2 и 3. Внимательный анализ нотации eEPC показывает, что она практически не отличается от нотации IDEF3. Важнейшим отличием eEPC является наличие объекта «событие» («Event»). Этот объект служит для отображения в модели возможных результатов выполнения функций, в зависимости от которых выполняется та или иная последующая ветка процесса. Нотация eEPC называется, очевидно, расширенной именно вследствие наличия в ней объекта «событие», - в IDEF3 такого объекта нет. При построении модели в ARIS eEPC должны соблюдаться следующие правила:

каждая функция должна быть инициирована событием и должна завершаться событием;

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

На рисунке 2.3.7 показано применение различных объектов нотации ARIS eEPC при создании модели бизнес-процесса.

Рис. 2.3.7. Применение различных объектов при создании модели в нотации eEPC

Из рисунков 2.3.6. и 2.3.7. видно, что бизнес-процесс в нотации eEPC представляет собой последовательность процедур, расположенных в порядке их выполнения. Следует отметить, что реальная длительность выполнения процедур в eEPC визуально отражена быть не может. Это приводит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя будет возложено выполнение двух задач одновременно. Используемые при построении модели символы логики позволяют отразить ветвление и слияние бизнес-процесса. Для получения информации о реальной длительности процессов и визуального отображения загрузки персонала в процессе можно использовать другие инструменты описания, например графики Гантта в приложении MS Project.

На рисунке 2.3.8. представлен бизнес-процесс обработки заказа клиента. Процесс начинается с события «Поступил заказ клиента». Это событие инициирует функцию «Выполнить учет заказа в системе», которую выполняет менеджер Отдела сбыта. Для выполнения работы он использует «Систему учета заказов». Результат выполнения функции отображается событием «Учет заказа выполнен». После этого менеджер по сбыту выполняет функцию «Выполнить анализ на соответствие номенклатуре». Результатом выполнения функции являются два альтернативных события «Заказ соответствует номенклатуре» и «Заказ не соответствует номенклатуре». Процесс ветвится. Для отображения ветвления процесса используется символ логического исключающего «ИЛИ». Функция «Уведомить клиента о невозможности выполнения заказа» может выполняться в двух случаях: если заказ не соответствует номенклатуре, либо производство невозможно. Для отображения на схеме процесса этих вариантов используется символ логического «ИЛИ» и т.д. Как видно из рисунка 2.3.8., схема процесса в ARIS eEPC отличается от схемы в IDEF3 наличием объектов: событий, документов, прикладных систем и должностей. Схема в ARIS визуально представляется более информативной и воспринимается лучше, однако размер этой схемы существенно превышает размер схемы в нотации IDEF3.
Рис. 2.3.8. Пример описания процесса в нотации ARIS eEPC

Введение. Типовые задачи описания бизнес-процессов

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

каких результатов с точки зрения улучшения деятельности организации можно добиться, используя технологии описания и реорганизации бизнес-процессов;
какое программное обеспечение использовать в проекте («ARIS лучше BPwin?», «ERwin лучше ARIS?» и т.п.);
как моделировать процессы с использованием продукта «Х»;
как проводить анализ и выявлять проблемы при помощи продукта «Х»;
какую методологию использовать для описания процессов;
что делать дальше с полученными моделями бизнес-процессов.

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

целей проекта;
требований к информации, характеризующей бизнес-процессы и необходимой для анализа и принятия решений в рамках конкретного проекта;
возможностей CASE-систем по описанию процессов с учетом требований п. 2;
особенностей разрабатываемой/внедряемой информационной системы.

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

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

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

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

Нотация ARIS Organizational Chart

Нотация Organizational Chart является одной из основных нотаций ARIS и предназначена для построения схем организационной структуры предприятия. Как правило, эта модель строится в начале проекта по моделированию бизнес-процессов. В модели отражаются существующие подразделения предприятия в виде иерархической структуры, как показано на рис. 5 .

Модель строится из объектов «Organizational unit», «Position», «Internal person» и др. Заложенные в нотацию виды связей позволяют отразить различные виды отношений между объектами организационной структуры. В представленном на рис. 5 примере «Предприятие» управляется «Директором», при этом используется тип связи «is Organization Manager for». Иерархия подразделений строится при помощи связей типа «is composed of». Кроме того, могут быть указаны должности - «Position» и фамилии реальных сотрудников, их занимающих: «Internal person», а также тип связи «occupies».

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

Нотации, поддерживаемые BPwin 4.0

Описание нотаций IDEF0 и IDEF3

Нотация IDEF0 была разработана на основе методологии структурного анализа и проектирования SADT, утверждена в качестве стандарта США и успешно эксплуатируется во многих проектах, связанных с описанием деятельности предприятий. IDEF0 получила чрезвычайно широкое распространение и является, в частности, стандартом в таких международных организациях, как НАТО и МВФ. Нотация IDEF3 была разработана с целью более удобного описания рабочих процессов (Workflow), для которых важно отразить логическую последовательность выполнения процедур. Объекты нотаций IDEF0 и IDEF3 показаны в табл. 2 и .

Семантика построения моделей IDEF0 и IDEF3 предполагает соблюдение четких правил. Полное описание стандартов IDEF можно найти на сайте http://www.idef.com/ .

Пример описания бизнес-процесса в нотации IDEF0 показан на рис. 8 (соответствует процессу, показанному на рис. 3).

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

В нотации IDEF3, так же как и в нотации ARIS eEPC, используются символы логики, отражающие ветвление процесса. Диаграмма в нотации IDEF3 позволяет представить процесс целиком, причем отслеживается последовательность выполнения операций и логика выполнения процесса.

Описание нотации DFD

Нотация DFD предназначена для описания информационных потоков в обследуемой организации. Объекты нотации DFD показаны в табл. 4 . Наличие объектов «хранилище данных» и двунаправленных стрелок позволяет наиболее эффективно описать документооборот и требования к информационной системе.

Одним из важнейших аспектов описания моделей бизнес-процессов является отражение на модели управляющих воздействий, обратных связей по контролю и управлению процедурой. В нотации ARIS eEPC управление процедурой может быть отражено только при помощи указания входящих документов, которые регламентируют выполнение процедуры, и последовательности выполнения процедур во времени (запускающие события). В отличие от ARIS, в нотации IDEF0 каждая процедура должна иметь хотя бы одно управляющее воздействие (вход управления - стрелка сверху). Если при создании модели в eEPC указывать только последовательность выполнения процедур, не заботясь об отражении управляющих воздействий (например, документов и информации), полученные модели будут иметь низкую ценность с точки зрения анализа и дальнейшего использования. К сожалению, именно эта ошибка наиболее распространена на практике. Создается модель Workflow (поток работы), отражающая простую последовательность выполнения процедур и входящих/исходящих документов, при этом управляющие (контрольные) воздействия на функции в модели не отражаются.

Сравнивая две системы, следует сразу отметить, что для хранения моделей в ARIS используется объектная СУБД и под каждый проект создается новая база данных. Для удобства пользователя модели (объекты моделей) могут храниться в различных группах, организованных в зависимости от специфики проекта. Вполне естественно, что в ARIS предусмотрены различные функции по администрированию базы данных: управление доступом, консолидация и т.п. В BPwin данные модели хранятся в файле, что существенно упрощает работу по созданию модели. Для групповой работы над большими проектами предусмотрено хранение моделей BPwin в репозитарии Model Mart (поставляется отдельно). Model Mart является хранилищем моделей для BPwin и ERwin и использует реляционные СУБД Oracle, Informix, MS SQLServer, Sybase). В нем предусмотрено администрирование, в том числе разграничение прав доступа до уровня объекта модели, сравнение версий, слияние моделей и т.д.

Часто одним из недостатков BPwin сторонники ARIS называют ограничение по количеству объектов на диаграмме. Однако опыт реальных проектов показывает, что для проекта, результаты которого можно реально использовать (критерий - обозримость), количество объектов в базе данных ARIS или модели BPwin составляет 150-300. Это означает, что при 8 объектах на одной диаграмме общее количество диаграмм (листов) в модели составит 20-40. Базы данных ARIS Toolset (как и BPwin), содержащие более 500 объектов, фактически невозможно использовать. Следует подчеркнуть, что модель создается для выделения и анализа проблем, то есть требуется детальное описание наиболее сложных, проблемных областей деятельности, а не тотальное описание всех процессов. Как ни странно, в среде директоров компаний распространено убеждение в том, что детальное описание процессов само по себе представляет ценность и может решить многие проблемы. Но это далеко от истины. Именно понимание того, что нужно описывать и какие аспекты функционирования реальной системы при этом отражать, определяет успех проекта по моделированию бизнес-процессов.

ARIS предоставляет существенно больше возможностей по работе с отдельными объектами модели, но именно вследствие чрезмерного количества настроек работа по созданию модели должна регламентироваться сложной, многоаспектной документацией - так называемыми соглашениями по моделированию. Разработка этих соглашений сама по себе является сложной, дорогостоящей и требующей значительного времени (1-3 месяца) и квалифицированных специалистов задачей. Если проект с использованием ARIS начинается без детальной проработки таких соглашений, то вероятность создания моделей бизнес-процессов, не отвечающих на поставленные вопросы, составляет 80-90%. В свою очередь, BPwin отличается простотой в использовании и достаточно строгой регламентацией при создании диаграмм (стандарт IDEF и рекомендации по его применению, бланк IDEF для создания диаграммы, ограниченное количество обязательно заполняемых полей, ограничение количества объектов на одной диаграмме и т.д.). ARIS, безусловно, является более «тяжелым» инструментом, по сравнению с BPwin, но в итоге это оборачивается значительными трудностями и высокими затратами на его эксплуатацию.

Выводы. Рекомендации по применению систем в зависимости от типовых задач

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

Позиционирование систем можно провести по отношению к решению задачи моделирования бизнес-процессов (рис. 13).

Таким образом, для ведения небольших по масштабам (малые и средние предприятия, 2-5 человек в группе консультантов) и длительности (2-3 месяца) проектов рационально использовать BPwin. Для крупных и/или длительных проектов (например, таких как внедрение системы непрерывного улучшения бизнес-процессов, ISO, TQM) больше подходит ARIS. Следует отметить, в что системе ARIS Toolset неудобно создавать информационные модели, а проектирование и настройка баз данных не предусмотрена. В этом случае подготовительные работы по созданию регламентирующей документации могут занять 1-3 месяца, но это является необходимым элементом последующей успешной работы.

Август-Вильгельм Шеер. Бизнес-процессы: основные понятия, теории, методы. Москва: Просветитель, 1999.

КомпьютерПресс 1"2002

В. Репин, С. Маклаков

Анализ деятельности предприятий и реорганизация бизнес-процессов - чрезвычайно сложная задача, требующая методической и инструментальной поддержки. В последнее время среди бизнес-аналитиков все большую популярность приобретают CASE-средства BPwin (Computer Associates) и ARIS Toolset (ARIS). В настоящей статье дается краткий сравнительный анализ этих средств и рекомендации по их использованию.

Введение. Типовые задачи описания бизнес-процессов

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

каких результатов с точки зрения улучшения деятельности организации можно добиться, используя технологииописания и реорганизации бизнес-процессов;
какое программное обеспечение использовать в проекте («ARIS лучше BPwin?», «ERwin лучше ARIS?» и т.п.);
как моделировать процессы с использованием продукта «Х»;
как проводить анализ и выявлять проблемы при помощи продукта «Х»;
какую методологию использовать для описания процессов;
что делать дальше с полученными моделями бизнес-процессов.

целей проекта;
требований к информации, характеризующей бизнес-процессы и необходимой для анализа и принятия решений врамках конкретного проекта;
возможностей CASE-систем по описанию процессов с учетом требований п. 2;
особенностей разрабатываемой/внедряемой информационной системы.

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

Нотация ARIS eEPC

Нотация ARIS eEPC расшифровывается следующим образом: extended Event Driven Process Chain - расширенная нотация описания цепочки процесса, управляемого событиями. Нотация разработана специалистами компании IDS Scheer AG (Германия), в частности профессором Шеером. В табл. 1 приводятся основные используемые в рамках нотации объекты.

Таблица 1. Объекты нотации eEPC

	Наименование	Описание
1	Функция	Объект «Функция» служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия
2	Событие	Объект «Событие» служит для описания реальных состояний системы, влияющих и управляющих выполнением функций
3	Организационная единица	Объект, отражающий различные организационные звенья предприятия (например, управление или отдел)
4	Документ	Объект, отражающий реальные носители информации, например бумажный документ
5	Прикладная система	Объект отражает реальную прикладную систему, используемую в рамках технологии выполнения функции
6	Кластер информации	Объект характеризует данные как набор сущностей и связей между ними. Используется для создания моделей данных
7	Стрелка связи между объектами	Объект описывает тип отношений между другими объектами, например активацию выполнения функции некоторым событием
8	Логическое «И»
9	Логическое «ИЛИ»	Логический оператор, определяющий связи между событиями и функциями в рамках процесса. Позволяет описать ветвление процесса
10	Логическое исключающее «ИЛИ»	Логический оператор, определяющий связи между событиями и функциями в рамках процесса. Позволяет описать ветвление процесса

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

Рис. 1. Пример модели в нотации eEPC

На рис. 1 видно, что связи между объектами имеют определенный смысл и отражают последовательность выполнения функций в рамках процесса. Стрелка, соединяющая Событие 1 и Функцию 1, «активирует» или инициирует выполнение Функции 1. Функция 1 «создает» Событие 2, за которым следует символ логического «И», «запускающий» выполнение Функций 2 и 3. Нотация eEPC построена на определенных семантических правилах описания:

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

Кроме этих правил, существуют и другие важные правила формирования моделей в ARIS. Эти правила можно изучить при помощи методического материала «Методы ARIS», который устанавливается на компьютер одновременно с демо-версией продукта.

На рис. 2 показано применение различных объектов ARIS при создании модели бизнес-процесса.

Рис. 2. Пример применения объектов ARIS для описания бизнес-процессов

Каждый объект в системе ARIS Toolset, которая поддерживает метод описания бизнес-процессов ARIS, имеет определенный набор атрибутов. Пользователю предлагается воспользоваться стандартными атрибутами для описания объектов или ограниченным количеством пользовательских атрибутов.

Из рис. 1 видно, что бизнес-процесс в нотации eEPC представляет собой последовательность процедур, расположенных в порядке их выполнения. Следует отметить, что реальная длительность выполнения процедур в eEPC не может быть отражена визуально. Это приводит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя будет возложено одновременное выполнение двух задач. Используемые при построении модели символы логики позволяют отразить ветвление и слияние бизнес-процесса. Для получения информации о реальной длительности процессов необходимо использовать другие инструменты описания, например графики Ганта в системе Microsoft Project.

Таким образом, при помощи нотации eEPC ARIS можно описывать бизнес-процесс в виде потока последовательно выполняемых работ (процедур, функций). Примеры моделей, сформированных с использованием ARIS eEPC, показаны на рис. 3 и 4.

Рис. 3. Описание процесса обслуживания клиента процесса

Рис. 4. Описание процесса анализа и согласования заявки клиента

Нотация ARIS Organizational Chart

Рис. 5. Модель организационной структуры предприятия

Нотация ARIS Information Flow

Нотация Information Flow является аналогом нотации DFD (см. ниже) и используется при построении схем потоков данных или документов между функциями бизнес-процессов предприятия, как показано на рис. 6.

Рис. 6. Фрагмент диаграммы ARIS Information Flow

Простота нотации ограничивает области ее полезного применения. Основными объектами нотации являются «Function» (используется также при построении моделей бизнес-процессов) и «Information Flow» - информационный поток (рис. 7).

Рис. 7. Нотация ARIS Information Flow

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

Нотации, поддерживаемые BPwin 4.0

Описание нотаций IDEF0 и IDEF3

Таблица 2. Объекты нотации eEPC

	Наименование	Описание
Нотация IDEF0
1	Работа (Activity)	Объект служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия. Изображается прямоугольником. Имя работы должно отображать процесс, действие. Для того чтобы работа могла быть смоделирована, должно пройти какое-то время от начала до окончания работы и должны быть затрачены какие-то ресурсы
2	Стрелка входа	Стрелка рисуется входящей в работу слева и описывает входящие документы, информацию, материальные ресурсы, необходимые для выполнения функции и изменяемые работой
3	Стрелка выхода	Стрелка рисуется исходящей из работы справа и описывает результаты выполнения работы - исходящие документы, информацию, материальные ресурсы. В нотации IDEF0 каждая процедура должна обязательно иметь не менее одной стрелки выхода
4	Стрелка управления	Стрелка рисуется входящей в работу сверху и описывает управляющее воздействие, например распоряжение, нормативный документ и т.д. В нотации IDEF0 каждая процедура должна обязательно иметь не менее одной стрелки управления
5	Стрелка механизма	Стрелка рисуется входящей в работу снизу и описывает так называемые механизмы, то есть ресурсы, необходимые для выполнения процедуры, но не изменяющие в процессе ее выполнения свое состояние. Примеры: сотрудник, станок и т.д.
6	Стрелка вызова	Стрелка рисуется исходящей из работы вниз и является ссылкой на другую модель работы. В BPwin такая стрелка используется для слияния и расщепления моделей

Таблица 3. Объекты нотации IDEF3

	Наименование	Описание
Нотация DFD
1	Работа	Объект служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия. Изображается прямоугольником. Имя работы должно отображать процесс, действие
2	Объект ссылки (Referent)	Объект, используемый 1) для описания ссылок на другие диаграммы; 2) ссылок на другие работы; 3) ссылок на объекты; 4) для пояснения логики ветвления стрелок на перекрестках; 5) различных комментариев к функциям и перекресткам
3	Перекрестки	Логические операторы (5 типов - синхронное и асинхронное «И», синхронное и асинхронное «ИЛИ», исключающее «ИЛИ»), определяющие взаимосвязь между функциями в рамках процесса. Позволяют описать ветвление процесса
4	Стрелки	Три типа стрелок, позволяющих описать последовательность выполнения процессов, а также потоки информации и объектов

Пример описания бизнес-процесса в нотации IDEF0 показан на рис. 8 (соответствует процессу, показанному на рис. 3).

Рис. 8. Пример описания бизнес-процесса в нотации IDEF0

На рис. 9 показан пример описания бизнес-процесса в нотации IDEF3 (соответствует процессу, показанному на рис. 4).

Рис. 9. Пример описания бизнес-процесса в нотации IDEF3

Описание нотации DFD

Нотация DFD предназначена для описания информационных потоков в обследуемой организации. Объекты нотации DFD показаны в табл. 4. Наличие объектов «хранилище данных» и двунаправленных стрелок позволяет наиболее эффективно описать документооборот и требования к информационной системе.

Таблица 4. Объекты нотации DFD

	Наименование	Описание
Нотация DFD
1	Работа (Activity)	Объект служит для описания функций по обработке информации, выполняемых подразделениями/ сотрудниками предприятия
2	Объект ссылки	Объект ссылки моделирует объект, воздействующий на систему извне
3	Хранилище данных	Хранилище данных моделирует место хранения информации - архив, база данных, репозитарий и т.д.
4	Стрелка	Стрелка показывает потоки информации, движение документов, перемещающихся вместе как один пакет. Стрелка может быть двунаправленной, то есть показывает поток информации по данному маршруту в обе стороны

На рис. 10 показан пример диаграммы DFD.

Рис. 10. Пример описания документооборота в нотации DFD

Для более детального описания и проектирования информационной системы совместно с BPwin может быть использован ERwin - CASE-средство, позволяющее создавать и воссоздавать модель данных. Связь модели процессов BPwin и модели данных ERwin производится посредством импорта словаря сущностей и атрибутов из ERwin в BPwin. В модели процессов каждой стрелке может быть поставлен в соответствие набор сущностей и атрибутов, а каждой работе - набор правил использования данных. Такая взаимосвязь моделей процессов и данных позволяет детально описать соответствие данных и их потребителей и тем самым исключить ошибки, которые могут возникать при создании и внедрении информационных систем.

Организационные диаграммы (Organizational Chart) в BPwin 4.0

Организационные диаграммы BPwin (рис. 11) являются аналогом организационных диаграмм ARIs и так же, как и в ARIS, предназначены для описания иерархии подчинения в организациях.

Рис. 11. Пример организационной диаграммы в BPwin

Для создания организационной диаграммы в BPwin необходимо предварительно в словарях внести следующую информацию.
Изображения (bitmaps), если на организационной диаграмме предполагается использовать иконки.
Группы ролей - могут соответствовать структурным подразделением. В примере на рис. 10 показаны группы ролей «Дирекция», «Бухгалтерия» и «Цех № 1».
Роли - могут соответствовать должности. В примере на рис. 10 показаны роли «Ген. директор», «Бухгалтер», «Технолог» и др.
Ресурсы - могут соответствовать фамилии конкретной персоны.

После создания словаря BPwin позволяет с помощью диалогов-гидов создать иерархию подчинения, включающую группы ролей, роли и ресурсы. В диаграммах IDEF0, IDEF3 и DFD каждой работе может быть назначен исполнитель-ресурс из словаря ресурсов. Роли и ресурсы могут быть также использованы при создании диаграммы Swim Lane - разновидности диаграммы IDEF3, на которой в виде отдельных полос показываются зоны ответственности служащих предприятия при выполнении технологических операций.

Сравнительный анализ нотаций ARIS и IDEF приводится в табл. 5.

Таблица 5. Объекты нотаций ARIS, IDEF0 и IDEF3

	Критерии сравнения
1	Принцип построения диаграммы/логика процесса		Принцип доминирования (см. стандарт IDEF0)	Временная последовательность выполнения процедур
2	Описание процедуры процесса	Объект на диаграмме	Объект на диаграмме	Объект на диаграмме
3	Входящий документ
4	Входящая информация		Стрелка входа, стрелка управления	Используется отдельный объект для описания (Объект ссылки типа Object или стрелка Object flow)
5	Исходящий документ	Используется отдельный объект для описания («документ»)	Стрелка выхода	Используется отдельный объект для описания (Объект ссылки типа Object или стрелка Object flow)
6	Исходящая информация	Используется отдельный объект для описания («кластер», «технический термин»)	Стрелка выхода	Используется отдельный объект для описания (Объект ссылки типа Object или стрелка Object flow)
7	Исполнитель процедуры	Используется отдельный объект для описания («позиция», «организационная единица»)	Стрелка механизма
8	Используемое оборудование	Используется отдельный объект для описания	Стрелка механизма	Нет (может быть отражен в модели только привязкой объекта ссылки)
9	Управление процедурой	Нет. Может быть отражено только символами логики и событий (последовательность выполнения процедур) и/или указанием входящих документов	Стрелка управления	Только временная последовательность выполнения процедур и логика процесса
10	Контроль выполнения процедуры	Нет. Может быть отражен указанием входящих документов	Стрелка управления	Нет (может быть отражен в модели только привязкой объекта ссылки).
11	Обратная связь по управлению/контролю		Стрелка управления	Нет
12	Обратная связь по входу	Нет. Может быть отражена только символами логики (последовательность выполнения процедур)	Стрелка входа	Нет

На рис. 12 функция 4 является контрольной и служит для проверки результатов работы, выполняемой функциями 2 и 3. Но данная модель не отвечает на вопросы:

каким образом осуществляется управляющее воздействие на функции 2 и 3? Показан только тот факт, что по ходу процесса возможен возврат и повторное выполнение функций 2 и 3; информация об этой обратной связи может быть
раскрыта только в виде описания в атрибутах объектов модели;
какие документы (например, нормативы), распоряжения, внешние условия (например, влажность воздуха в помещении), регламентируют выполнение функций?

Рис. 12. Недостатки описания бизнес-процесса в ARIS eEPC

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

Таким образом, нотация ARIS eEPC является расширением достаточно простой нотации IDEF3. Для адекватного описания процесса управления в нотации eEPC необходимо заранее договориться о том, как будут отражены в модели документы (информация), регламентирующие выполнение процедур процесса.

Функциональные возможности продуктов ARIS и BPwin

Функциональные возможности инструментальных средств моделирования ARIS Toolset и BPwin можно корректно сравнивать только по отношению к определенному кругу задач. В данном исследовании рассматривается задача формирования моделей (описания) бизнес-процессов предприятия. Каждая из рассматриваемых систем имеет свои преимущества и недостатки. В зависимости от решаемых задач эти преимущества могут как усиливаться, так и наоборот, ослабевать. То же самое можно сказать и о недостатках: недостаток системы в рамках одного проекта может не быть таковым в рамках другого. Например, отсутствие четких соглашений по моделированию управляющих воздействий в рамках eEPC ARIS может привести к созданию моделей, не отвечающих на поставленные вопросы, в то время как нотация IDEF0 системы BPwin позволяет решить эту задачу. С другой стороны, процедура, выполняемая одним сотрудником, может быть более адекватно описана при помощи eEPC ARIS, чем при помощи IDEF0 или IDEF3 BPwin. Сравнение функциональных возможностей систем приводится в табл. 6.

Таблица 6. Сравнение функциональных возможностей ARIS Toolset 5.0 и BPwin 4.0

	Возможности/ Инструментальная среда	ARIS Toolset 5.0	BPwin 4.0
1	Поддерживаемый стандарт	(частично - DFD, ERM, UML)	IDEF0, IDEF3, DFD
2	Система хранения данных модели	Объектная база данных	Модели хранятся в файлах. Возможно создание репозитария на основе реляционной СУБД с помощью ModelMart
3	Ограничение на размер базы данных		Нет. Размер базы данных ограничивается вычислительными ресурсами
4	Возможность групповой работы	Есть. Используется ARIS Server	Есть. Используется ModelMart
5	Ограничение на количество объектов на диаграмме	Нет	Для DFD и IDEF3 - нет. Для IDEF0 ограничено рекомендациями нотации
6	Возможность декомпозиции	Неограниченная декомпозиция. Возможна декомпозиция на различные типы моделей	Неограниченная декомпозиция. Возможен переход на другую нотацию в процессе декомпозиции
7	Формат представления моделей	Не регламентируется	Стандартный бланк (каркас) IDEF с возможностью его отключения
8	Удобство работы по созданию моделей	Сложная панель управления, есть выравнивание объектов, есть undo	Простая панель управления, нет выравнивания объектов, нет undo
9	UDP - свойства объектов, определяемые пользователем	Большое, но ограниченное количество свойств; количество типов ограничено	Количество UDP не ограничено. Количество типов ограничено (18)
10	Возможность анализа стоимости процессов	Есть. Возможность использовать ARIS ABC	Упрощенный ABC - анализ стоимости по частоте использования в процессе. Возможность экспорта в Easy ABC
11	Генерация отчетов	Создание отчетов на основе стандартных и настраиваемых пользователем макросов Visual Basic	RPTwin, возможность визуальной настройки отчетов, включая расчет по формулам с использованием UDP
12	Сложность разработки нестандартных отчетов	Сложно	Просто
13	Экспорт отчетов		Реализован экспорт отчетов в MS Office, текстовый файл, RTF, HTML
14	Связь с моделью данных	Возможность построения ERD-диаграмм, для экспорта необходимо дополнительное программное обеспечение	Реализована связь с моделью данных ERwin. Каждой стрелке может быть поставлен в соответствие набор сущностей и атрибутов
15	Описание доступа к данным	Нет	Для каждой работы могут быть описаны права на использование данных. Объект модели данных может быть создан непосредственно в среде BPwin
16	Описание сопутствующей документации	Есть, поддержка OLE	С помощью UDP типа command с каждой стрелкой связывается любой документ, который может быть загружен с помощью Windows - приложения. Запуск приложения проводится непосредственно из среды BPwin

Различные ситуации применения инструментальных средств моделирования бизнес-процессов и их экспертная оценка по 5-балльной шкале показаны в табл. 7.

Таблица 7. Оценка применимости ARIS Toolset 5.0 и BPwin 4.0 для задач моделирования бизнес-процессов

Задача/Инструментальная среда	ARIS Toolset 5.0
Разовый проект по описанию бизнес-процессов, например: описание одного бизнес-процесса с точки зрения контроля и управления; описание функциональных возможностей новой системы управления на верхнем уровне	3	5
Длительный (непрерывный) проект по описанию деятельности компании с различных точек зрения (организационная структура, структура документов, большой объем базы данных процессов и т.д.)	5	4
Разработка системы автоматизации: описание функциональных возможностей системы; создание логической модели данных; связь модели процессов и модели данных; создание физической модели данных; генерация кода приложения.	3 3 - -	5 BPwin + ERwin + Paradigm Plus

Рис. 13. Оценка эффективности ARIS Toolset и BPwin

Интернет-сайт www.finexpert.ru
Интернет-сайт
Интернет-сайт www.idef.com
С.В.Маклаков. BPwin и ERwin. CASE-средства разработки информационных систем. Москва: Диалог-МИФИ, 2000, 256с.
Д.А. Марка, К. МакГоуэн Методология структурного анализа и проектирования. Москва, 1993.
«Методы ARIS». Файл pdf, более 1000 стр. Поставляется вместе с демо-версией системы ARIS Toolset.
Август-Вильгельм Шеер. Бизнес-процессы: основные понятия, теории, методы. Москва: Просветитель, 1999.

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

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

Функции в модели ARIS EPC запускаются событиями, например, «Счет поступил на согласование», и событиями оканчиваются, например, «Счет согласован» или «Счет не согласован». Если в результате исполнения функции имеется только один вариант дальнейшего выполнения бизнес-процесса, т.е. в результате формируется только одно событие, после которого идет следующая функция, событие между этими функциями может не рисоваться.

Модель бизнес-процесса нотации ARIS EPC обязательно начинается и заканчивается одним, или несколькими событиями или интерфейсами в другие модели бизнес-процессов. Для отражения интерфейсов используются специальные объекты «Интерфейс процесса» — тип объекта «Функция».

При создании модели ARIS EPC могут возникнуть ситуации, когда один и тот же документ является исходящим для одной функции и входящим для следующей. В этих случаях для улучшения эргономики модели допустимо использования одного представления документа с одной входящей связью (от функции, в которой он создается или корректируется) и одной исходящей связью (к функции, которой он используется).

Модель EPC не может быть несвязной, т.е. расположение на модели, одного объекта, не связанного с остальными, является ошибкой.

Расположение документов относительно функций как правило следующее, слева сверху – входящие, слева снизу – исходящие документы, исполнителей, как правило располагают справа от функции.

На модели ARIS EPC указывается следующая информация:

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

Правила именования события в ARIS EPC

Имя события (Event) должно содержать существительное и описание изменения состояния в виде отглагольной формы. Пример: «Сделка исполнена».

Правила именования функции в ARIS EPC

Для наименования функции (Function) необходимо использовать ее реальное название. Имя должно состоять из двух частей – отглагольного существительного, описывающего выполняемую функцию, и существительного, показывающего объект, над которым он выполняется. Наименование функции состоит из краткого наименования объекта, начинающегося с заглавной буквы, например, «Поиск контактов клиента».

Правила именования роли/должности в ARIS EPC

Наименование бизнес-роли (Person Type) должно соответствовать сути возлагаемых на исполнителя обязанностей. Как правило, наименование содержит фразу «Ответственный за …». Наименования должностей (Position) пишутся в соответствии со штатным расписанием.

Правила именования документов

Объект соответствует документу (Information Carrier) (в бумажном и/ или электронном виде). Для наименования документов (независимо от используемого символа) необходимо использовать их реальное название.

Правила именования информационных систем в ARIS EPC

Для наименования информационных систем (Application system type) следует использовать их устоявшиеся названия.

Правила именования интерфейса процесса

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