В.В.Репин
Оглавление
- Введение. Типовые задачи
описания бизнес-процессов.
Требования к описанию бизнес-процессов предприятий.
- Описание
нотации ARIS eEPC.
- Описание
нотации IDEF0, IDEF3.
- Сравнительный анализ нотаций
ARIS и IDEF.
- Функциональные возможности
продуктов ARIS и BPwin.
- Выводы. Рекомендации по
применению систем в зависимости от типовых задач.
Введение. Типовые задачи
описания бизнес-процессов. Требования к описанию бизнес-процессов предприятий.
Основная
задача данного аналитического исследования состоит в том, чтобы ответить на ряд
вопросов, возникающих у руководителей и специалистов в начале проекта по
моделированию и реорганизации бизнес-процессов предприятия. Наиболее часто в
этом случае задают следующие вопросы (по степени важности для спрашивающих):
- какое программное обеспечение использовать в проекте
(«ARIS лучше BPwin?», «ERwin лучше ARIS?» и т.п.);
- как моделировать процессы с использованием продукта
«Х»?;
- как проводить анализ и выявлять проблемы при помощи
продукта «Х»?;
- какую методологию использовать для описания процессов?
В настоящее
время на российском рынке представлено достаточно большое количество CASE-систем,
многие из которых позволяют, так или иначе, создавать описания (модели)
бизнес-процессов предприятий. Очевидно, что выбор системы в значительной мере
определяет весь дальнейший ход проекта. Рациональный выбор системы возможен при
понимании руководством компании, и ее специалистами нескольких аспектов:
- целей проекта;
- требований к информации, характеризующей
бизнес-процессы и необходимой для анализа и принятия решений в рамках
конкретного проекта;
- возможностей CASE-систем по описанию процессов с учетом
требований п.2.
Говорить о
преимуществе той или иной системы/нотации бессмысленно, пока не определены тип
и рамки проекта, основные задачи, которые данные проект должен решить. В
настоящем исследовании сделана попытка провести сравнение наиболее популярных
нотаций, используемых для описания бизнес-процессов, и двух систем,
поддерживающих эти нотации. Предполагается, что данное исследование послужит
основанием для дискуссии, посвященной проблемам эффективного применения
CASE-систем для описания и анализа бизнес-процессов предприятий.
Описание
бизнес-процессов проводится с целью их дальнейшего анализа и реорганизации.
Целью реорганизации может быть внедрение информационной системы, сокращение
затрат на выпуск продукции, повышение качества обслуживания клиентов, создание
должностных и рабочих инструкций при внедрении стандартов ISO-9000 и т.д. Для
каждой такой задачи существует определенные параметры, определяющие набор
критических знаний по бизнес-процессу. От задачи к задаче требования к описанию
бизнес-процессов могут меняться. В общем случае, модель бизнес-процесса должна
давать ответы на следующие вопросы:
- какие процедуры (функции, работы) необходимо выполнить
для получения заданного конечного результата;
- в какой последовательности выполняются эти процедуры;
- какие механизмы контроля и управления существуют в
рамках рассматриваемого бизнес-процесса;
- кто выполняет процедуры процесса;
- какие входящие документы/информацию использует каждая
процедура процесса;
- какие исходящие документы/информацию генерирует
процедура процесса;
- какие ресурсы необходимы для выполнения каждой
процедуры процесса;
- какая документация/условия регламентирует выполнение
процедуры;
- какие параметры характеризуют выполнение процедур и
процесса в целом.
Описание
бизнес-процесса формируется при помощи нотации и инструментальной среды,
позволяющих отразить все указанные выше аспекты. Только в этом случае модель
бизнес-процесса окажется полезной для предприятия, т.к. ее можно будет
подвергнуть анализу и реорганизации.
Описание нотации ARIS eEPC
Нотация ARIS
eEPC расшифровывается следующим образом - Extended Event Driven Process Chain –
расширенная нотация описания цепочки процесса, управляемого событиями. Нотация
разработана специалистами компании IDS Scheer AG (Германия), в частности профессором
Шеером. В следующей таблице приводятся основные используемые в рамках нотации
объекты.
|
№
|
Наименование
|
Описание
|
Графическое представление
|
|
1
|
Функция
|
Объект «Функция» служит для описания функций (процедур, работ),
выполняемых подразделениями/сотрудниками предприятия.
|

|
|
2
|
Событие
|
Объект «Событие» служит для описания реальных состояний системы,
влияющих и управляющих выполнением функций
|

|
|
3
|
Организационная единица
|
Объект, отражающий различные организационные звенья предприятия
(например, управление или отдел)
|

|
|
4
|
Документ
|
Объект, отражающий реальные носители информации, например
бумажный документ
|

|
|
5
|
Прикладная система
|
Объект отражает реальную прикладную систему, используемую в
рамках технологии выполнения функции
|

|
|
6
|
Кластер информации
|
Объект характеризует данные, как набор сущностей и связей между
ними. Используется для создания моделей данных
|

|
|
7
|
Стрелка связи между объектами
|
Объект описывает тип отношений между другими объектами, например
– активацию выполнения функции некоторым событием
|

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

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

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

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

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

Рисунок 2.
Каждый
объект в системе ARIS Toolset, которая поддерживает метод описания
бизнес-процессов ARIS, имеет определенный набор атрибутов. Пользователю
предлагается воспользоваться стандартными атрибутами для описания объектов или
ограниченным количество т.н. пользовательских атрибутов.
Из рисунка 1
видно, что бизнес-процесс в нотации eEPC представляет собой последовательность
процедур, расположенных в порядке их выполнения. Следует отметить, что реальная
длительность выполнения процедур в eEPC визуально отражена быть не может. Это
приводит к тому, что при создании моделей возможны ситуации, когда на одного
исполнителя будет возложено выполнение двух задач одновременно. Используемые
при построении модели символы логики позволяют отразить ветвление и слияние
бизнес-процесса. Для получения информации о реальной длительности процессов
необходимо использовать другие инструменты описания, например графики Ганта в
системе MS Project.
Таким
образом, при помощи нотации eEPC ARIS можно описывать бизнес-процесс в виде
потока последовательно выполняемых работ (процедур, функций). Пример моделей,
сформированных с использованием ARIS eEPC, показаны на рисунках 3-4.

Рисунок 3.

Рисунок 4. Увеличить рисунок
Описание нотации IDEF0, IDEF3
Нотация
IDEF0 была разработана на основе методологии структурного анализа и
проектирования SADT, утверждена в качестве стандарта США и успешно эксплуатируется
во многих проектах, связанных с описанием деятельности предприятий. Нотация
IDEF3 была разработана с целью более удобного описания рабочих процессов (Work
Flow), для которых важно отразить логическую последовательность выполнения
процедур. Нотации IDEF0 и IDEF3 используют следующие объекты.
|
№
|
Наименование
|
Описание
|
Графическое представление
|
|
Нотация IDEF0
|
|
1
|
Модуль поведения (UOB)
|
Объект служит для описания функций (процедур, работ),
выполняемых подразделениями/сотрудниками предприятия.
|

|
|
2
|
Стрелка слева
|
Стрелка описывает входящие документы, информацию, материальные
ресурсы, необходимые для выполнения функции.
|

|
|
3
|
Стрелка справа
|
Стрелка описывает исходящие документы, информацию, материальные
ресурсы, являющиеся результатом выполнения функции.
|

|
|
4
|
Стрелка сверху
|
Стрелка описывает управляющее воздействия, например
распоряжение, нормативный документ и т.д. В нотации IDEF0 каждая процедура
должна обязательно иметь не менее одной стрелки сверху, отражающей
управляющее воздействие.
|

|
|
5
|
Стрелка снизу
|
Стрелка снизу описывает т.н. механизмы, т.е. ресурсы,
необходимые для выполнения процедуры, но не изменяющие в процессе ее
выполнения свое состояние. Примеры: сотрудник, станок и т.д.
|

|
|
Нотация IDEF3
|
|
1
|
Модель работы (UOW)
|
Объект служит для описания функций (процедур, работ),
выполняемых подразделениями/сотрудниками предприятия.
|

|
|
2
|
Ссылочный объект
|
Объект, используемый для описания ссылок на другие диаграммы
модели, циклические переходы в рамках одной модели, различные комментарии к
функциям.
|

|
|
3
|
Логическое «И»
|
Логический оператор, определяющий связи между функциями в рамках
процесса. Позволяет описать ветвление процесса.
|

|
|
4
|
Логическое «ИЛИ»
|
Логический оператор, определяющий связи между функциями в рамках
процесса. Позволяет описать ветвление процесса.
|

|
|
5
|
Логическое исключающее «ИЛИ»
|
Логический оператор, определяющий связи функциями в рамках
процесса. Позволяет описать ветвление процесса.
|

|
Таблица 2
В моделях
могут использоваться стрелки трех видов, показанных в следующей таблице 3.
|
№
|
Тип стрелки
|
Графическое представление
|
|
1
|
Стрелка предшествования. Соединяет последовательно выполняемые
функции.
|

|
|
2
|
Стрелка отношения. Используется для привязки
объектов-комментариев к функциям.
|

|
|
3
|
Стрелка потока объектов. Показывает поток объектов от одной
функции к другой.
|

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

Рисунок 5.
На рисунке 6
показан бизнес-процесс, описанный при помощи нотации IDEF3. (Этот процесс
представлен в нотации ARIS eEPC на рисунке 4.

Рисунок 6.
В нотации
IDEF3, так же как и в нотации ARIS eEPC, используются символы логики,
отражающие ветвление процесса.
Сравнительный анализ
нотаций ARIS и IDEF
Сравнительный
анализ нотаций ARIS и IDEF приводится в следующей таблице.
|
№
|
Критерии сравнения
|
ARIS
|
IDEF0
|
IDEF3
|
|
1
|
Принцип построения диаграммы / логика процесса
|
Временная последовательность выполнения процедур
|
Принцип доминирования (см. стандарт IDEF0)
|
Временная последовательность выполнения процедур
|
|
2
|
Описание процедуры процесса
|
Объект на диаграмме
|
Объект на диаграмме
|
Объект на диаграмме
|
|
3
|
Входящий документ
|
Используется отдельный объект для описания («документ»)
|
Стрелка слева, стрелка сверху
|
Нет (может быть отражен в модели только привязкой
объекта-комментария)
|
|
4
|
Входящая информация
|
Используется отдельный объект для описания («кластер»,
«технический термин»)
|
Стрелка слева, стрелка сверху
|
Нет (может быть отражен в модели только привязкой
объекта-комментария)
|
|
5
|
Исходящий документ
|
Используется отдельный объект для описания («документ»)
|
Стрелка справа
|
Нет (может быть отражен в модели только привязкой
объекта-комментария)
|
|
6
|
Исходящая информация
|
Используется отдельный объект для описания («кластер»,
«технический термин»)
|
Стрелка справа
|
Нет (может быть отражен в модели только привязкой
объекта-комментария)
|
|
7
|
Исполнитель процедуры
|
Используется отдельный объект для описания («позиция»,
«организационная единица»)
|
Стрелка снизу
|
Нет (может быть отражен в модели только привязкой
объекта-комментария)
|
|
8
|
Используемое оборудование
|
Используется отдельный объект для описания
|
Стрелка снизу
|
Нет (может быть отражен в модели только привязкой
объекта-комментария)
|
|
9
|
Управление процедурой
|
Нет. Может быть отражено только символами логики и событий
(последовательность выполнения процедур) и/или указанием входящих документов
|
Стрелка сверху
|
Только временная последовательность выполнения процедур и логика
процесса
|
|
10
|
Контроль выполнения процедуры
|
Нет. Может быть отражен указанием входящих документов
|
Стрелка сверху
|
Нет.
|
|
11
|
Обратная связь по управлению/контролю
|
Нет. Может быть отражена только символами логики
(последовательность выполнения процедур)
|
Стрелка сверху
|
Нет.
|
Таблица 4
Одним из
важнейших аспектов описания моделей бизнес-процессов является отражение на
модели управляющих воздействий, обратных связей по контролю и управлению
процедурой. В нотации ARIS eEPC управление процедурой может быть отражено
только при помощи указания входящих документов, которые регламентируют
выполнение процедуры, и последовательности выполнения процедур во времени
(запускающие события). В отличие от ARIS, в нотации IDEF0 каждая процедура
должна иметь хотя бы одно управляющее воздействие (вход управления – стрелка
сверху). Если при создании модели в eEPC указывать только последовательность
выполнения процедур, не заботясь об отражении управляющих документов и информации,
полученные модели будут иметь низкую ценность с точки зрения анализа и
дальнейшего использования. К сожалению, именно эта ошибка наиболее
распространена на практике. Создается модель Work Flow (поток работы),
отражающая простую последовательность выполнения процедур и входящих/исходящих
документов, при этом управляющие (контрольные) воздействия на функции в модели
не отражаются. Реальные процессы управления могут остаться «за кадром» на
30-90% (см. пример на следующем рисунке).

Рисунок 7. Недостатки описания бизнес-процесса в ARIS eEPC.
На рисунке 7
Функция 4 является контрольной и служит для проверки результатов выполнения
работы, выполняемой функциями 2 и 3. Но данная модель не отвечает на вопросы:
- каким образом осуществляется управляющее воздействие на
функции 2 и 3, показан только тот факт, что по ходу процесса возможен
возврат и повторное выполнение функций 2 и 3; информация об этой обратной
связи может быть раскрыта только в виде описания в атрибутах объектов
модели;
- какие документы (например, нормативы), распоряжения,
внешние условия (например, влажность воздуха в помещении), регламентируют
выполнение функций.
Если
пытаться отразить все условия и ограничения, определяющие выполнение функций,
то потребуется описать большое количество событий и входящей информации
(например, устных распоряжений руководителей), и модель станет сложной и плохо
читаемой. (Эти недостатки присущи так же и нотации IDEF3). Указанных недостатков
нет у нотации IDEF0. В то же время, на моделях в IDEF0 не предусмотрено
использование символов логики выполнения процесса.
Таким
образом, нотация ARIS eEPC является расширением достаточно простой нотации
IDEF3. Для адекватного описания процесса управления в нотации eEPC необходимо
заранее договориться, как будут отражены в модели документы (информация),
регламентирующие выполнение процедур процесса.
Функциональные
возможности продуктов ARIS и BPwin
Функциональные
возможности инструментальных средств моделирования ARIS Toolset и BPwin можно
корректно сравнивать только по отношению к определенному кругу задач. В данном
исследовании рассматривается задача формирования моделей (описания)
бизнес-процессов предприятия. Каждая из рассматриваемых систем имеет свои
преимуществ и недостатки. В зависимости от решаемых задач эти преимущества
могут как усиливаться, так и наоборот. То же касается и недостатков: недостаток
системы в рамках одного проекта, может не быть недостатком в рамках другого.
Например, отсутствие четких соглашений по моделированию управляющих воздействий
в рамках eEPC ARIS может привести к созданию моделей, не отвечающих на
поставленные вопросы, в то время как нотация IDEF0 системы BPwin позволяет
решить эту задачу. С другой стороны, описание процедуры, выполняемой одним
сотрудником, может быть описано более адекватно при помощи eEPC ARIS, чем IDEF0
или IDEF3 BPwin. Сравнение функциональных возможностей систем приводится в
следующей таблице.
|
№
|
Возможности/Инструментальная среда
|
ARIS Toolset 5.0
|
BPwin 4.0
|
|
1
|
Поддерживаемый стандарт
|
- (частично – DFD, ERM, UML)
|
IDEF0, IDEF3, DFD
|
|
2
|
Система хранения данных модели
|
Объектная база данных
|
Модели хранятся в файлах
|
|
3
|
Ограничение на размер базы данных
|
Нет. Размер базы данных ограничивается вычислительными ресурсами
|
Нет. Размер базы данных ограничивается вычислительными ресурсами
|
|
4
|
Возможность групповой работы
|
Есть. Используется ARIS Server.
|
Есть. Используется ModelMart.
|
|
5
|
Ограничение на количество объектов на диаграмме.
|
Нет.
|
От 2 до 8.
|
|
6
|
Возможность декомпозиции
|
Неограниченная декомпозиция. Возможно декомпозиция на различные
типы моделей.
|
Неограниченная декомпозиция. Возможен однократный переход на
другую нотацию в процессе декомпозиции.
|
|
7
|
Формат представления моделей
|
Не регламентируется
|
Стандартный бланк IDEF с возможностью его отключения
|
|
8
|
Удобство работы по созданию моделей
|
Сложная панель управления, есть выравнивание объектов, есть
undo.
|
Простая панель управления, нет выравнивания объектов, нет undo.
|
|
9
|
UDP – свойства объектов, определяемые пользователем
|
Большое, но ограниченное количество свойств, количество типов
ограничено.
|
Количество UDP не ограничено. Количество типов ограничено.
|
|
10
|
Возможность анализа стоимости процессов
|
Есть. Возможность использовать ARIS ABC.
|
Упрощенный анализ стоимости по частоте использования в процессе.
Возможность экспорта в Easy ABC.
|
|
11
|
Генерация отчетов
|
Создание отчетов на основе стандартных и настраиваемых
пользователем макросов Visual Basic.
|
RPT Win, возможность визуальной настройки отчетов, включая
расчет по формулам с использованием UDP
|
|
12
|
Сложность разработки нестандартных отчетов
|
Сложно
|
Просто
|
Таблица 5
Сравнивая
две системы, следует сразу отметить, что для хранения моделей в ARIS
используется объектная СУБД, и под каждый проект создается новая база данных.
Для удобства пользователя модели (объекты моделей) могут храниться в различных
группах, организованных в зависимости от специфики проекта. Вполне естественно,
что в ARIS-е предусмотрены различные функции по администрированию базы данных:
управление доступом, консолидация и т.п. В BPwin данные модели хранятся в
файле, что существенно упрощает работу по созданию модели, но с другой стороны
ограничивает возможности по анализу объектов модели. В ModelMart так же
предусмотрено администрирование базы данных.
Часто одним
из недостатков 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-бальной шкале показаны в следующей таблице.
|
Задача/Инструментальная среда
|
ARIS Toolset 5.0
|
BPwin 4.0
|
|
Разовый проект по описанию бизнес-процессов, например:
1.
описание одного бизнес-процесса с точки зрения контроля и
управления;
2.
описание функциональных возможностей новой системы управления на
верхнем уровне.
|
3
3
|
5
5
|
|
Длительный (непрерывный) проект по описанию деятельности
компании с различных точек зрения (организационная структура, структура
документов, большой объем базы данных процессов и т.д.)
|
5
|
3
|
|
Разработка системы автоматизации:
1.
описание функциональных возможностей системы;
2.
создание логической модели данных;
3.
создание физической модели данных.
|
3
3
-
|
5
BPwin + ERwin + Paradigm Plus
|
Таблица 6
Позиционирование
систем можно провести по отношению к решению задачи моделирования
бизнес-процессов (см. рисунок 8).

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