Оглавление
Введение. Типовые задачи описания бизнес-процессов
Описание нотаций AR
Нотация ARIS eEPC
Нотация ARIS Organizational Chart
Нотация ARIS Information Flow
Нотации, поддерживаемые BPwin 4.0
Описание нотаций IDEF0 и IDEF3
Описание нотации DFD
Организационные диаграммы (Organizational Chart) в BPwin 4.0
Сравнительный анализ нотаций ARIS и IDEF
Функциональные возможности продуктов ARIS и BPwin
Выводы. Рекомендации по применению систем в зависимости от типовых задач
Литература
Анализ деятельности предприятий и реорганизация бизнес-процессов - чрезвычайно сложная задача, требующая методической и инструментальной поддержки. В последнее время среди бизнес-аналитиков все большую популярность приобретают CASE-средства BPwin (Computer Associates) и ARIS Toolset (ARIS). В настоящей статье дается краткий сравнительный анализ этих средств и рекомендации по их использованию.
Введение. Типовые задачи описания бизнес-процессов
На ранних этапах проектов, целью которых является реорганизация бизнес-процессов и внедрение информационных систем, у руководителей и специалистов наиболее часто возникают следующие вопросы:
- каких результатов с точки зрения улучшения деятельности организации можно добиться, используя технологииописания и реорганизации бизнес-процессов;
- какое программное обеспечение использовать в проекте («ARIS лучше BPwin?», «ERwin лучше ARIS?» и т.п.);
- как моделировать процессы с использованием продукта «Х»;
- как проводить анализ и выявлять проблемы при помощи продукта «Х»;
- какую методологию использовать для описания процессов;
- что делать дальше с полученными моделями бизнес-процессов.
В настоящее время на российском рынке представлено достаточно большое количество CASE-систем, многие из которых позволяют так или иначе создавать описания (модели) бизнес-процессов предприятий. В то же время существуют системы, ориентированные в первую очередь на создание моделей процессов и неудобные или вообще не предназначенные для создания моделей данных и настройки СУБД. Очевидно, что выбор системы определяется целями проекта и в значительной мере влияет на весь его дальнейший ход. Рациональный выбор системы возможен при понимании руководством компании и ее специалистами нескольких аспектов:
- целей проекта;
- требований к информации, характеризующей бизнес-процессы и необходимой для анализа и принятия решений врамках конкретного проекта;
- возможностей CASE-систем по описанию процессов с учетом требований п. 2;
- особенностей разрабатываемой/внедряемой информационной системы.
Говорить о преимуществе той или иной системы/нотации бессмысленно, пока не определены тип и рамки проекта, а также основные задачи, которые данный проект должен решить. В нашей статье сделана попытка провести сравнение наиболее популярных нотаций (систем обозначений, принятых при моделировании), используемых для описания бизнес-процессов, и двух систем, поддерживающих эти нотации. Предполагается, что этот материал послужит основанием для дискуссии, посвященной проблемам эффективного применения CASE-систем для описания и анализа бизнес-процессов предприятий.
Описание бизнес-процессов проводится с целью их дальнейшего анализа и реорганизации. Целью реорганизации может быть внедрение информационной системы, сокращение затрат на выпуск продукции, повышение качества обслуживания клиентов, создание должностных и рабочих инструкций при внедрении стандартов ISO 9000 и т.д. Для каждой такой задачи существуют определенные параметры, определяющие набор критических знаний по бизнес-процессу. От задачи к задаче требования к описанию бизнес-процессов могут меняться. В общем случае модель бизнес-процесса должна давать ответы на следующие вопросы:
- какие процедуры (функции, работы) необходимо выполнить для получения заданного конечного результата;
- в какой последовательности выполняются эти процедуры;
- какие механизмы контроля и управления существуют в рамках рассматриваемого бизнес-процесса;
- роли и ответственности - кто выполняет процедуры процесса;
- какие входящие документы/информацию использует каждая процедура процесса;
- какие исходящие документы/информацию генерирует процедура процесса;
- какие ресурсы необходимы для выполнения каждой процедуры процесса;
- какие документация/условия регламентируют выполнение процедуры;
- какие параметры характеризуют выполнение процедур и процесса в целом;
- существует ли последовательность процессов, минимизирующая затраты (в том числе стоимость, время и т.д.);
- насколько процесс поддерживается/будет поддерживаться информационной системой.
Описание бизнес-процесса формируется при помощи нотации и инструментальной среды, позволяющих отразить все указанные выше аспекты. Только в этом случае модель бизнес-процесса окажется полезной для предприятия, так как ее можно будет подвергнуть анализу и реорганизации.
Нотация 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
Нотация Organizational Chart является одной из основных нотаций ARIS и предназначена для построения схем организационной структуры предприятия. Как правило, эта модель строится в начале проекта по моделированию бизнес-процессов. В модели отражаются существующие подразделения предприятия в виде иерархической структуры, как показано на рис. 5.
Рис. 5. Модель организационной структуры предприятия
Модель строится из объектов «Organizational unit», «Position», «Internal person» и др. Заложенные в нотацию виды связей позволяют отразить различные виды отношений между объектами организационной структуры. В представленном на рис. 5 примере «Предприятие» управляется «Директором», при этом используется тип связи «is Organization Manager for». Иерархия подразделений строится при помощи связей типа «is composed of». Кроме того, могут быть указаны должности - «Position» и фамилии реальных сотрудников, их занимающих: «Internal person», а также тип связи «occupies».
Кроме моделей иерархии подразделений, могут быть построены модели иерархии подчиненности в проектных командах, группах и т.д. Все отраженные в моделях объекты могут быть использованы в дальнейшем при построении моделей бизнес-процессов. При построении сложных иерархических структур может быть использована декомпозиция, например структура подразделения может быть отражена на более детальной схеме.
Нотация Information Flow является аналогом нотации DFD (см. ниже) и используется при построении схем потоков данных или документов между функциями бизнес-процессов предприятия, как показано на рис. 6.
Рис. 6. Фрагмент диаграммы ARIS Information Flow
Простота нотации ограничивает области ее полезного применения. Основными объектами нотации являются «Function» (используется также при построении моделей бизнес-процессов) и «Information Flow» - информационный поток (рис. 7).
Рис. 7. Нотация ARIS Information Flow
При построении моделей бизнес-процессов сначала может быть построена модель eEPC, а затем, с использованием определенных в процессе функций, - модель информационных потоков.
Нотации, поддерживаемые BPwin 4.0
Описание нотаций IDEF0 и IDEF3
Нотация IDEF0 была разработана на основе методологии структурного анализа и проектирования SADT, утверждена в качестве стандарта США и успешно эксплуатируется во многих проектах, связанных с описанием деятельности предприятий. IDEF0 получила чрезвычайно широкое распространение и является, в частности, стандартом в таких международных организациях, как НАТО и МВФ. Нотация IDEF3 была разработана с целью более удобного описания рабочих процессов (Workflow), для которых важно отразить логическую последовательность выполнения процедур. Объекты нотаций IDEF0 и IDEF3 показаны в табл. 2 и 3.
Таблица 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 и IDEF3 предполагает соблюдение четких правил. Полное описание стандартов IDEF можно найти на сайте http://www.idef.com/.
Пример описания бизнес-процесса в нотации IDEF0 показан на рис. 8 (соответствует процессу, показанному на рис. 3).
Рис. 8. Пример описания бизнес-процесса в нотации IDEF0
Одной из особенностей описания процессов в нотации IDEF0 является четкое выявление достоинств и недостатков бизнес-процессов. Работы на диаграмме IDEF0 располагаются в порядке доминирования - с левого верхнего угла диаграммы в правый нижний. В левом верхнем углу размещается либо самая важная работа, либо работа, выполняемая первой. Стрелки связывают работы, при этом различается пять типов связей. Стрелка, направленная с выхода вышестоящей работы на вход или управление нижестоящей, является прямой связью; стрелка, направленная с выхода нижестоящей работы на вход или управление вышестоящей, является обратной связью. Отсутствие обратных связей, работы без выхода или управления, дублирующиеся работы указывают на несовершенство бизнес-процессов.
На рис. 9 показан пример описания бизнес-процесса в нотации IDEF3 (соответствует процессу, показанному на рис. 4).
Рис. 9. Пример описания бизнес-процесса в нотации IDEF3
В нотации IDEF3, так же как и в нотации ARIS eEPC, используются символы логики, отражающие ветвление процесса. Диаграмма в нотации IDEF3 позволяет представить процесс целиком, причем отслеживается последовательность выполнения операций и логика выполнения процесса.
Нотация 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
Сравнительный анализ нотаций ARIS и IDEF приводится в табл. 5.
Таблица 5. Объекты нотаций ARIS, IDEF0 и IDEF3
|
№ |
Критерии сравнения |
ARIS |
IDEF0 |
IDEF3 |
|---|---|---|---|---|
| 1 | Принцип построения диаграммы/логика процесса | Временная последовательность выполнения процедур | Принцип доминирования (см. стандарт IDEF0) | Временная последовательность выполнения процедур |
| 2 | Описание процедуры процесса | Объект на диаграмме | Объект на диаграмме | Объект на диаграмме |
| 3 | Входящий документ | Используется отдельный объект для описания («документ») | Стрелка входа, стрелка управления | Используется отдельный объект для описания (Объект ссылки типа Object или стрелка Object flow) |
| 4 | Входящая информация | Используется отдельный объект для описания («кластер», «технический термин») | Стрелка входа, стрелка управления | Используется отдельный объект для описания (Объект ссылки типа Object или стрелка Object flow) |
| 5 | Исходящий документ | Используется отдельный объект для описания («документ») | Стрелка выхода | Используется отдельный объект для описания (Объект ссылки типа Object или стрелка Object flow) |
| 6 | Исходящая информация | Используется отдельный объект для описания («кластер», «технический термин») | Стрелка выхода | Используется отдельный объект для описания (Объект ссылки типа Object или стрелка Object flow) |
| 7 | Исполнитель процедуры | Используется отдельный объект для описания («позиция», «организационная единица») | Стрелка механизма | Нет (может быть отражен в модели только привязкой объекта ссылки) |
| 8 | Используемое оборудование | Используется отдельный объект для описания | Стрелка механизма | Нет (может быть отражен в модели только привязкой объекта ссылки) |
| 9 | Управление процедурой | Нет. Может быть отражено только символами логики и событий (последовательность выполнения процедур) и/или указанием входящих документов | Стрелка управления | Только временная последовательность выполнения процедур и логика процесса |
| 10 | Контроль выполнения процедуры | Нет. Может быть отражен указанием входящих документов | Стрелка управления | Нет (может быть отражен в модели только привязкой объекта ссылки). |
| 11 | Обратная связь по управлению/контролю | Нет. Может быть отражена только символами логики (последовательность выполнения процедур) | Стрелка управления | Нет |
| 12 | Обратная связь по входу | Нет. Может быть отражена только символами логики (последовательность выполнения процедур) | Стрелка входа | Нет |
Одним из важнейших аспектов описания моделей бизнес-процессов является отражение на модели управляющих воздействий, обратных связей по контролю и управлению процедурой. В нотации ARIS eEPC управление процедурой может быть отражено только при помощи указания входящих документов, которые регламентируют выполнение процедуры, и последовательности выполнения процедур во времени (запускающие события). В отличие от ARIS, в нотации IDEF0 каждая процедура должна иметь хотя бы одно управляющее воздействие (вход управления - стрелка сверху). Если при создании модели в eEPC указывать только последовательность выполнения процедур, не заботясь об отражении управляющих воздействий (например, документов и информации), полученные модели будут иметь низкую ценность с точки зрения анализа и дальнейшего использования. К сожалению, именно эта ошибка наиболее распространена на практике. Создается модель Workflow (поток работы), отражающая простую последовательность выполнения процедур и входящих/исходящих документов, при этом управляющие (контрольные) воздействия на функции в модели не отражаются.
На рис. 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 | Реализован экспорт отчетов в MS Office, текстовый файл, RTF, HTML |
| 14 | Связь с моделью данных | Возможность построения ERD-диаграмм, для экспорта необходимо дополнительное программное обеспечение | Реализована связь с моделью данных ERwin. Каждой стрелке может быть поставлен в соответствие набор сущностей и атрибутов |
| 15 | Описание доступа к данным | Нет | Для каждой работы могут быть описаны права на использование данных. Объект модели данных может быть создан непосредственно в среде BPwin |
| 16 | Описание сопутствующей документации | Есть, поддержка OLE | С помощью UDP типа command с каждой стрелкой связывается любой документ, который может быть загружен с помощью Windows - приложения. Запуск приложения проводится непосредственно из среды BPwin |
Сравнивая две системы, следует сразу отметить, что для хранения моделей в 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.
Таблица 7. Оценка применимости ARIS Toolset 5.0 и BPwin 4.0 для задач моделирования бизнес-процессов
|
Задача/Инструментальная среда |
ARIS Toolset 5.0 |
BPWin 4.0 |
|---|---|---|
Разовый проект по описанию бизнес-процессов, например:
|
3 | 5 |
| Длительный (непрерывный) проект по описанию деятельности компании с различных точек зрения (организационная структура, структура документов, большой объем базы данных процессов и т.д.) | 5 | 4 |
Разработка системы автоматизации:
|
3 3 - - |
5 BPwin + ERwin + Paradigm Plus |
Позиционирование систем можно провести по отношению к решению задачи моделирования бизнес-процессов (рис. 13).
Рис. 13. Оценка эффективности ARIS Toolset и BPwin
Таким образом, для ведения небольших по масштабам (малые и средние предприятия, 2-5 человек в группе консультантов) и длительности (2-3 месяца) проектов рационально использовать BPwin. Для крупных и/или длительных проектов (например, таких как внедрение системы непрерывного улучшения бизнес-процессов, ISO, TQM) больше подходит ARIS. Следует отметить, в что системе ARIS Toolset неудобно создавать информационные модели, а проектирование и настройка баз данных не предусмотрена. В этом случае подготовительные работы по созданию регламентирующей документации могут занять 1-3 месяца, но это является необходимым элементом последующей успешной работы.
- Интернет-сайт www.finexpert.ru
- Интернет-сайт www.interface.ru
- Интернет-сайт www.idef.com
- С.В.Маклаков. BPwin и ERwin. CASE-средства разработки информационных систем. Москва: Диалог-МИФИ, 2000, 256с.
- Д.А. Марка, К. МакГоуэн Методология структурного анализа и проектирования. Москва, 1993.
- «Методы ARIS». Файл pdf, более 1000 стр. Поставляется вместе с демо-версией системы ARIS Toolset.
- Август-Вильгельм Шеер. Бизнес-процессы: основные понятия, теории, методы. Москва: Просветитель, 1999.