|
В настоящее время на российском рынке представлено достаточно большое количество CASE-систем, многие из которых позволяют, так или иначе, создавать описания (модели) бизнес-процессов предприятий. Очевидно, что выбор системы в значительной мере определяет весь дальнейший ход проекта.
Владимир Репин
1. Введение.
Типовые задачи описания бизнес-процессов.
Требования к описанию бизнес-процессов
предприятий
Основная задача
данного аналитического исследования
состоит в том, чтобы ответить на ряд
вопросов, возникающих у руководителей и
специалистов в начале проекта по
моделированию и реорганизации бизнес-процессов
предприятия. Наиболее часто в этом
случае задают следующие вопросы (по
степени важности для спрашивающих):
-
какое программное
обеспечение использовать в проекте («ARIS
лучше BPWin?», «ERWin лучше ARIS?» и т.п.);
-
как моделировать
процессы с использованием продукта «Х»?;
-
как проводить анализ
и выявлять проблемы при помощи
продукта «Х»?;
-
какую методологию
использовать для описания процессов?
В настоящее время на
российском рынке представлено
достаточно большое количество CASE-систем,
многие из которых позволяют, так или
иначе, создавать описания (модели)
бизнес-процессов предприятий. Очевидно,
что выбор системы в значительной мере
определяет весь дальнейший ход проекта.
Рациональный выбор системы возможен при
понимании руководством компании, и ее
специалистами нескольких аспектов:
-
целей проекта;
-
требований к
информации, характеризующей бизнес-процессы
и необходимой для анализа и принятия
решений в рамках конкретного проекта;
-
возможностей CASE-систем
по описанию процессов с учетом
требований п.2.
Говорить о
преимуществе той или иной системы/нотации
бессмысленно, пока не определены тип и
рамки проекта, основные задачи, которые
данные проект должен решить. В настоящем
исследовании сделана попытка провести
сравнение наиболее популярных нотаций,
используемых для описания бизнес-процессов,
и двух систем, поддерживающих эти
нотации. Предполагается, что данное
исследование послужит основанием для
дискуссии, посвященной проблемам
эффективного применения CASE-систем для
описания и анализа бизнес-процессов
предприятий.
Описание бизнес-процессов
проводится с целью их дальнейшего
анализа и реорганизации. Целью
реорганизации может быть внедрение
информационной системы, сокращение
затрат на выпуск продукции, повышение
качества обслуживания клиентов,
создание должностных и рабочих
инструкций при внедрении стандартов
ISO-9000 и т.д. Для каждой такой задачи
существует определенные параметры,
определяющие набор критических знаний
по бизнес-процессу. От задачи к задаче
требования к описанию бизнес-процессов
могут меняться. В общем случае, модель
бизнес-процесса должна давать ответы на
следующие вопросы:
-
какие процедуры (функции,
работы) необходимо выполнить для
получения заданного конечного
результата;
-
в какой
последовательности выполняются эти
процедуры;
-
какие механизмы
контроля и управления существуют в
рамках рассматриваемого бизнес-процесса;
-
кто выполняет
процедуры процесса;
-
какие входящие
документы/информацию использует
каждая процедура процесса;
-
какие исходящие
документы/информацию генерирует
процедура процесса;
-
какие ресурсы
необходимы для выполнения каждой
процедуры процесса;
-
какая документация/условия
регламентирует выполнение процедуры;
-
какие параметры
характеризуют выполнение процедур и
процесса в целом.
Описание бизнес-процесса
формируется при помощи нотации и
инструментальной среды, позволяющих
отразить все указанные выше аспекты.
Только в этом случае модель бизнес-процесса
окажется полезной для предприятия, т.к.
ее можно будет подвергнуть анализу и
реорганизации.
Нотация 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 была
разработана на основе методологии
структурного анализа и проектирования
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 |
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 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. |
Есть. Используется
Model Mart. |
| 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 данные модели
хранятся в файле, что существенно
упрощает работу по созданию модели, но с
другой стороны ограничивает
возможности по анализу объектов модели.
В Model Mart так же предусмотрено
администрирование базы данных.
Часто одним из
недостатков 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 месяца, но это является
необходимым элементом последующей
успешной работы.
1. Инфопортал www.finexpert.ru
2. Интернет-сайт www.idef.com
3. С.В. Маклаков. BPWin и ERWin.
CASE-средства разработки информационных
систем. Москва: Диалог-МИФИ, 2000.256 с
4. Марка Д.А., МакГоуэн К.
Методология структурного анализа и
проектирования. Москва, 1993 г.
5. «Методы ARIS». Файл pdf,
более 1000 стр. Поставляется вместе с демо-версией
системы ARIS Toolset.
6. Август-Вильгельм Шеер,
Бизнес-процессы: основные понятия,
теории, методы, Москва.: Просветитель, 1999 |