Нотация ARIS EPC, используемая для моделирования бизнес-процессов в инструментарии ARIS, представляет собой последовательность событий и функций, отражающих логику выполнения взаимосвязанных действий, направленных на достижение определенного результата.
Модель ARIS EPC предназначена для описания алгоритма выполнения бизнес-процесса в виде последовательности функций, управляемых событиями. В модели ARIS EPC главное внимание уделяется последовательности выполнения функций, а для описания условий в модели бизнес-процесса используются события и правила, которые могут описывать сложные алгоритмы выполнения бизнес-процесса.
Функции в модели ARIS EPC запускаются событиями, например, «Счет поступил на согласование», и событиями оканчиваются, например, «Счет согласован» или «Счет не согласован». Если в результате исполнения функции имеется только один вариант дальнейшего выполнения бизнес-процесса, т.е. в результате формируется только одно событие, после которого идет следующая функция, событие между этими функциями может не рисоваться.
Модель бизнес-процесса нотации ARIS EPC обязательно начинается и заканчивается одним, или несколькими событиями или интерфейсами в другие модели бизнес-процессов. Для отражения интерфейсов используются специальные объекты «Интерфейс процесса» — тип объекта «Функция».
При создании модели ARIS EPC могут возникнуть ситуации, когда один и тот же документ является исходящим для одной функции и входящим для следующей. В этих случаях для улучшения эргономики модели допустимо использования одного представления документа с одной входящей связью (от функции, в которой он создается или корректируется) и одной исходящей связью (к функции, которой он используется).
Модель EPC не может быть несвязной, т.е. расположение на модели, одного объекта, не связанного с остальными, является ошибкой.
Расположение документов относительно функций как правило следующее, слева сверху – входящие, слева снизу – исходящие документы, исполнителей, как правило располагают справа от функции.
На модели ARIS EPC указывается следующая информация:
Имя события (Event) должно содержать существительное и описание изменения состояния в виде отглагольной формы. Пример: «Сделка исполнена».
Для наименования функции (Function) необходимо использовать ее реальное название. Имя должно состоять из двух частей – отглагольного существительного, описывающего выполняемую функцию, и существительного, показывающего объект, над которым он выполняется. Наименование функции состоит из краткого наименования объекта, начинающегося с заглавной буквы, например, «Поиск контактов клиента».
Наименование бизнес-роли (Person Type) должно соответствовать сути возлагаемых на исполнителя обязанностей. Как правило, наименование содержит фразу «Ответственный за …». Наименования должностей (Position) пишутся в соответствии со штатным расписанием.
Объект соответствует документу (Information Carrier) (в бумажном и/ или электронном виде). Для наименования документов (независимо от используемого символа) необходимо использовать их реальное название.
Для наименования информационных систем (Application system type) следует использовать их устоявшиеся названия.
Интерфейс (Process interface) показывает ссылку на смежный процесс. Имя интерфейса процесса соответствует названию модели, которая описывает смежную часть бизнес-процесса. Интерфейс может использоваться для ссылок на модели бизнес-процесса, не входящие в описываемый бизнес-процесс.
Общая структура методологии 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
Основная задача данного аналитического исследования состоит в том, чтобы ответить на ряд вопросов, возникающих у руководителей и специалистов в начале проекта по моделированию и реорганизации бизнес-процессов предприятия. Наиболее часто в этом случае задают следующие вопросы (по степени важности для спрашивающих):
В настоящее время на российском рынке представлено достаточно большое количество CASE-систем, многие из которых позволяют, так или иначе, создавать описания (модели) бизнес-процессов предприятий. Очевидно, что выбор системы в значительной мере определяет весь дальнейший ход проекта. Рациональный выбор системы возможен при понимании руководством компании, и ее специалистами нескольких аспектов:
Говорить о преимуществе той или иной системы/нотации бессмысленно, пока не определены тип и рамки проекта, основные задачи, которые данные проект должен решить. В настоящем исследовании сделана попытка провести сравнение наиболее популярных нотаций, используемых для описания бизнес-процессов, и двух систем, поддерживающих эти нотации. Предполагается, что данное исследование послужит основанием для дискуссии, посвященной проблемам эффективного применения CASE-систем для описания и анализа бизнес-процессов предприятий.
Описание бизнес-процессов проводится с целью их дальнейшего анализа и реорганизации. Целью реорганизации может быть внедрение информационной системы, сокращение затрат на выпуск продукции, повышение качества обслуживания клиентов, создание должностных и рабочих инструкций при внедрении стандартов ISO-9000 и т.д. Для каждой такой задачи существует определенные параметры, определяющие набор критических знаний по бизнес-процессу. От задачи к задаче требования к описанию бизнес-процессов могут меняться. В общем случае, модель бизнес-процесса должна давать ответы на следующие вопросы:
Описание бизнес-процесса формируется при помощи нотации и инструментальной среды, позволяющих отразить все указанные выше аспекты. Только в этом случае модель бизнес-процесса окажется полезной для предприятия, т.к. ее можно будет подвергнуть анализу и реорганизации.
Нотация ARIS eEPC расшифровывается следующим образом – extended Event Driven Process Chain – расширенная нотация описания цепочки процесса, управляемого событиями. Нотация разработана специалистами компании IDS Scheer AG (Германия), в частности профессором Шеером. В следующей таблице приводятся основные используемые в рамках нотации объекты.
Таблица 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
Нотация IDEF3
Таблица 2.
В моделях могут использоваться стрелки трех видов, показанных в следующей таблице 3.
Таблица 3.
Семантика построения моделей IDEF0 и IDEF3 предполагает соблюдение четких правил. Детальную информацию о построении моделей в IDEF0,3 можно узнать в стандартах и книгах (см. литературу).
Бизнес-процесс, сформированный при помощи нотации IDEF0, показан на рисунке 5. (Этот процесс представлен в нотации ARIS eEPC на рисунке 3).
Рисунок 5.
На рисунке 6 показан бизнес-процесс, описанный при помощи нотации IDEF3. (Этот процесс представлен в нотации ARIS eEPC на рисунке 4.)
Рисунок 6.
В нотации IDEF3, так же как и в нотации ARIS eEPC, используются символы логики, отражающие ветвление процесса.
Сравнительный анализ нотаций ARIS и IDEF приводится в следующей таблице.
Таблица 4.
Одним из важнейших аспектов описания моделей бизнес-процессов является отражение на модели управляющих воздействий, обратных связей по контролю и управлению процедурой. В нотации ARIS eEPC управление процедурой может быть отражено только при помощи указания входящих документов, которые регламентируют выполнение процедуры, и последовательности выполнения процедур во времени (запускающие события). В отличие от ARIS, в нотации IDEF0 каждая процедура должна иметь хотя бы одно управляющее воздействие (вход управления – стрелка сверху). Если при создании модели в eEPC указывать только последовательность выполнения процедур, не заботясь об отражении управляющих документов и информации, полученные модели будут иметь низкую ценность с точки зрения анализа и дальнейшего использования. К сожалению, именно эта ошибка наиболее распространена на практике. Создается модель Work Flow (поток работы), отражающая простую последовательность выполнения процедур и входящих/исходящих документов, при этом управляющие (контрольные) воздействия на функции в модели не отражаются. Реальные процессы управления могут остаться “за кадром” на 30-90% (см. пример на следующем рисунке).
Рисунок 7. Недостатки описания бизнес-процесса в ARIS eEPC.
На рисунке 7 Функция 4 является контрольной и служит для проверки результатов выполнения работы, выполняемой функциями 2 и 3. Но данная модель не отвечает на вопросы:
Если пытаться отразить все условия и ограничения, определяющие выполнение функций, то потребуется описать большое количество событий и входящей информации (например, устных распоряжений руководителей), и модель станет сложной и плохо читаемой. (Эти недостатки присущи так же и нотации IDEF3). Указанных недостатков нет у нотации IDEF0. В то же время, на моделях в IDEF0 не предусмотрено использование символов логики выполнения процесса.
Таким образом, нотация ARIS eEPC является расширением достаточно простой нотации IDEF3. Для адекватного описания процесса управления в нотации eEPC необходимо заранее договориться, как будут отражены в модели документы (информация), регламентирующие выполнение процедур процесса.
Функциональные возможности инструментальных средств моделирования ARIS Toolset и BPWin можно корректно сравнивать только по отношению к определенному кругу задач. В данном исследовании рассматривается задача формирования моделей (описания) бизнес-процессов предприятия. Каждая из рассматриваемых систем имеет свои преимуществ и недостатки. В зависимости от решаемых задач эти преимущества могут как усиливаться, так и наоборот. То же касается и недостатков: недостаток системы в рамках одного проекта, может не быть недостатком в рамках другого. Например, отсутствие четких соглашений по моделированию управляющих воздействий в рамках eEPC ARIS может привести к созданию моделей, не отвечающих на поставленные вопросы, в то время как нотация IDEF0 системы BPWin позволяет решить эту задачу. С другой стороны, описание процедуры, выполняемой одним сотрудником, может быть описано более адекватно при помощи eEPC ARIS, чем IDEF0 или IDEF3 BPWin. Сравнение функциональных возможностей систем приводится в следующей таблице.
Таблица 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-бальной шкале показаны в следующей таблице.
Таблица 6.
Позиционирование систем можно провести по отношению к решению задачи моделирования бизнес-процессов (см. рисунок 8).
Рисунок 8.
Таким образом, для ведения небольших по масштабам (малые и средние предприятия, 2-5 человека в группе консультантов) и длительности (2-3 месяца) проектов рационально использовать BPWin. Для крупных и/или длительных проектов (например, внедрение системы непрерывного улучшения бизнес-процессов, ISO, TQM) больше подходит ARIS. В этом случае подготовительные работы по созданию регламентирующей документации могут занять 1-3 месяца, но это является необходимым элементом последующей успешной работы.
Введение. Типовые задачи описания бизнес-процессов
а ранних этапах проектов, целью которых является реорганизация бизнес-процессов и внедрение информационных систем, у руководителей и специалистов наиболее часто возникают следующие вопросы:
В настоящее время на российском рынке представлено достаточно большое количество CASE-систем, многие из которых позволяют так или иначе создавать описания (модели) бизнес-процессов предприятий. В то же время существуют системы, ориентированные в первую очередь на создание моделей процессов и неудобные или вообще не предназначенные для создания моделей данных и настройки СУБД. Очевидно, что выбор системы определяется целями проекта и в значительной мере влияет на весь его дальнейший ход. Рациональный выбор системы возможен при понимании руководством компании и ее специалистами нескольких аспектов:
Говорить о преимуществе той или иной системы/нотации бессмысленно, пока не определены тип и рамки проекта, а также основные задачи, которые данный проект должен решить. В нашей статье сделана попытка провести сравнение наиболее популярных нотаций (систем обозначений, принятых при моделировании), используемых для описания бизнес-процессов, и двух систем, поддерживающих эти нотации. Предполагается, что этот материал послужит основанием для дискуссии, посвященной проблемам эффективного применения CASE-систем для описания и анализа бизнес-процессов предприятий.
Описание бизнес-процессов проводится с целью их дальнейшего анализа и реорганизации. Целью реорганизации может быть внедрение информационной системы, сокращение затрат на выпуск продукции, повышение качества обслуживания клиентов, создание должностных и рабочих инструкций при внедрении стандартов ISO 9000 и т.д. Для каждой такой задачи существуют определенные параметры, определяющие набор критических знаний по бизнес-процессу. От задачи к задаче требования к описанию бизнес-процессов могут меняться. В общем случае модель бизнес-процесса должна давать ответы на следующие вопросы:
Описание бизнес-процесса формируется при помощи нотации и инструментальной среды, позволяющих отразить все указанные выше аспекты. Только в этом случае модель бизнес-процесса окажется полезной для предприятия, так как ее можно будет подвергнуть анализу и реорганизации.
Нотация Organizational Chart является одной из основных нотаций ARIS и предназначена для построения схем организационной структуры предприятия. Как правило, эта модель строится в начале проекта по моделированию бизнес-процессов. В модели отражаются существующие подразделения предприятия в виде иерархической структуры, как показано на рис. 5 .
Модель строится из объектов «Organizational unit», «Position», «Internal person» и др. Заложенные в нотацию виды связей позволяют отразить различные виды отношений между объектами организационной структуры. В представленном на рис. 5 примере «Предприятие» управляется «Директором», при этом используется тип связи «is Organization Manager for». Иерархия подразделений строится при помощи связей типа «is composed of». Кроме того, могут быть указаны должности - «Position» и фамилии реальных сотрудников, их занимающих: «Internal person», а также тип связи «occupies».
Кроме моделей иерархии подразделений, могут быть построены модели иерархии подчиненности в проектных командах, группах и т.д. Все отраженные в моделях объекты могут быть использованы в дальнейшем при построении моделей бизнес-процессов. При построении сложных иерархических структур может быть использована декомпозиция, например структура подразделения может быть отражена на более детальной схеме.
Нотация 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 показаны в табл. 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 месяца, но это является необходимым элементом последующей успешной работы.
КомпьютерПресс 1"2002
