В настоящее время на российском рынке представлено достаточно большое количество CASE-систем, многие из которых позволяют создавать описания (модели) бизнес-процессов предприятий. Очевидно, что выбор системы в значительной мере определяет весь дальнейший ход проекта. Рациональный выбор системы возможен при понимании руководством предприятия и его специалистами нескольких аспектов:
- • целей проекта;
- • требований к информации, характеризующей бизнес-процессы и необходимой для анализа и принятия решений в рамках конкретного проекта;
- • возможностей CASE-систем по описанию процессов с учетом требований к разрабатываемой системе.
Анализ документов, предоставленных на тендер
Документы к тендеру проанализированы
Приглашение к тендеру сделано
Знания о структуре и поведении целевой группы
Все виды нотаций для моделирования бизнес-процессов за две минуты
Знания о состоянии бизнеса,
Знания о состоянии бизнеса, финансов клиентов и др.
Знания, необходимые при выполнении функций
Прояснение открытых вопросов с клиентом
Знания о стратегии и планах клиента
Открытые вопросы прояснены
Дополнительные документы о требованиях клиента
Рис. 3.31. Пример обработки знаний в модели еЕРС
Знания, которые поступают при выполнении функций
Знания о стратегии и планах клиента
Знания о контактах клиента
Знания, которые документируются при выполнении функций
Говорить о преимуществе той или иной системы/нотации бессмысленно, пока не определены тип и рамки проекта, основные задачи, которые данный проект должен решить.
Описание бизнес-процессов проводится с целью их дальнейшего анализа и реорганизации. Целью реорганизации может быть внедрение информационной системы, сокращение затрат на выпуск продукции, повышение качества обслуживания клиентов, создание должностных и рабочих инструкций при внедрении стандартов ISO-9000 и т. д. Для каждой такой цели существуют параметры, определяющие набор критических знаний по бизнес-процессу. От задачи к задаче требования к описанию бизнес-процессов могут меняться. В общем случае модель биз-нес-процесса должна давать ответы на следующие вопросы:
- • какие процедуры (функции, работы) необходимо выполнить для получения заданного конечного результата;
- • в какой последовательности выполняются эти процедуры;
- • какие механизмы контроля и управления существуют в рамках рассматриваемого бизнес-процесса;
- • кто выполняет процедуры процесса;
- • какие входящие документы/информацию использует каждая процедура процесса;
- • какие исходящие документы/информацию генерирует процедура процесса;
- • какие ресурсы необходимы для выполнения каждой процедуры процесса;
- • какая документация/условия регламентируют выполнение процедуры;
- • какие параметры характеризуют выполнение процедур и процесса в целом.
Описание бизнес-процесса формируется при помощи нотации и инструментальной среды, которые позволяют отразить все указанные выше аспекты. Только в этом случае модель бизнес-процесса окажется полезной для предприятия, так как ее можно будет подвергнуть анализу и реорганизации.
Сравнительный анализ возможностей нотаций ARIS и IDEF приводится в табл. 3.2.
Одним из важнейших аспектов описания моделей бизнес-про-цессов является отражение на модели управляющих воздействий, обратных связей по контролю и управлению процедурой. В нотации ARIS еЕРС управление процедурой может быть отражено только при помощи указания входящих документов, регламентирующих выполнение процедуры, и последовательности выполнения процедур во времени (запускающих событий).
В отличие от ARIS, в нотации IDEF0 каждая процедура должна иметь хотя бы одно управляющее воздействие (вход управления — стрелка сверху). Если при создании модели в еЕРС указывать только последовательность выполнения процедур, не заботясь об отражении управляющих воздействий (например, документов и информации), полученные модели будут иметь низкую ценность с точки зрения анализа и дальнейшего использования.
К сожалению, именно эта ошибка наиболее распространена на практике. Создается модель WorkFlow (поток работы), отражающая простую последовательность выполнения процедур и входящих/исходя-щих документов, при этом управляющие (контрольные) воздействия на функции в модели не отражаются. Реальные процессы управления могут остаться «за кадром» на 30-90 % (рис. 3.32).
На рис. 3.32 функция 4 является контрольной и служит для проверки результатов выполнения работы, исполняемой функциями 2 и 3. Но данная модель не отвечает на следующие вопросы:
- • каким образом осуществляется управляющее воздействие на функции 2 и 3, показан только тот факт, что по ходу процесса возможен возврат и повторное выполнение функций 2 и 3; информация об этой обратной связи может быть раскрыта только в виде описания в атрибутах объектов модели;
- • какие документы (например, нормативы), распоряжения, внешние условия (например, влажность воздуха в помещении) регламентируют выполнение функций.
Сравнительный анализ нотаций ARIS и IDEF
1. Принцип построения диаграммы / логика процесса
Временная последовательность выполнения процедур
Временная последовательность выполнения процедур
2. Описание процедуры процесса
Объект на диаграмме
Объект на диаграмме
Объект на диаграмме
3. Входящий документ
Используется отдельный объект для описания («документ»)
Стрелка слева, стрелка сверху
Нет (может быть отражен в модели только привязкой объекта-комментария)
4. Входящая информация
Используется отдельный объект для описания («кластер», «технический термин»)
Стрелка слева, стрелка сверху
Нет (может быть отражен в модели только привязкой объекта-комментария)
5. Исходящий документ
Используется отдельный объект для описания («документ»)
Нет (может быть отражен в модели только привязкой объекта-комментария)
6. Исходящая информация
Используется отдельный объект для описания («кластер», «технический термин»)
Нет (может быть отражен в модели только привязкой объекта-комментария)
Окончание табл. 3.2
7. Исполнитель процедуры
Используется отдельный объект для описания («позиция», «организационная единица»)
Нет (может быть отражен в модели только привязкой объекта-комментария)
8. Используемое оборудование
Используется отдельный объект для описания
Нет (может быть отражен в модели только привязкой объекта-комментария)
9. Управление процедурой
Нет (может быть отражено только символами логики и событий (последовательность выполнения процедур) и/или указанием входящих документов)
Только временная последовательность выполнения процедур и логика процесса
10. Контроль выполнения процедуры
Нет (может быть отражен указанием входящих документов)
11. Обратная связь по у правлен и ю/ко нтро л го
Нет (может быть отражена только символами логики (последовательность выполнения процедур))
Рис. 3.32. Недостатки описания бизнес-процесса в ARIS еЕРС
Если пытаться отразить все условия и ограничения, определяющие выполнение функций, то потребуется описание большого количества событий и входящей информации (например, устных распоряжений руководителей) и модель станет сложной и плохо читаемой. Эти недостатки присущи также и нотации IDEF3. Указанных недостатков нет у нотации IDEF0.
В то же время на моделях в IDEF0 не предусмотрено использование символов логики выполнения процесса. Таким образом, нотация ARIS еЕРС является расширением достаточно простой нотации IDEF3. Для адекватного описания процесса управления в нотации еЕРС необходимо заранее договориться, как будут отражены в модели документы (информация), регламентирующие выполнение процедур процесса.
Функциональные возможности инструментальных средств моделирования ARIS Toolset и AllFusion Process Modeler (ранее BP Win) можно корректно сравнивать только по отношению к определенному кругу задач.
В данном пособии рассматривается задача формирования моделей (описания) бизнес-процессов предприятия. Каждая из рассматриваемых систем имеет свои преимущества и недостатки. В зависимости от решаемых задач эти преимущества могут как усиливаться, так и наоборот. То же касается и недостатков: недостаток системы в рамках одного проекта может не быть недостатком в рамках другого.
Например, отсутствие четких соглашений по моделированию управляющих воздействий в рамках еЕРС ARIS может привести к созданию моделей, не отвечающих на поставленные вопросы, в то время как нотация IDEF0 системы BPWin позволяет решить эту задачу. С другой стороны, описание процедуры, выполняемой одним сотрудником, может быть сделано более адекватно при помощи еЕРС ARIS, чем IDEF0 или IDEF3 BPWin.
Сравнение функциональных возможностей систем приводится в табл. 3.3. Сравнивая две системы, следует сразу отметить, что для хранения моделей в ARIS используется объектная СУБД, и для каждого проекта создается новая база данных.
Сравнение функциональных возможностей
Возможности/ инструментальная среда
ARIS Toolset 5.0
1. Поддерживаемый стандарт
DFD (частично), ERM, UML
IDEFO, IDEF3, DFD
2. Система хранения данных модели
Объектная база данных
Модели хранятся в файлах
3. Ограничение на размер базы данных
Нет. Размер базы данных ограничивается вычислительными ресурсами
Нет. Размер базы данных ограничивается вычислительными ресурсами
4. Возможность групповой работы
5. Ограничение на количество объектов на диаграмме
6. Возможность декомпозиции
Неограниченная декомпозиция. Возможна декомпозиция на различные типы моделей
Неограниченная декомпозиция. Возможен однократный переход на другую нотацию в процессе декомпозиции
7. Формат представления моделей
Стандартный бланк IDEF с возможностью его отключения
8. Удобство работы по созданию моделей
Сложная панель управления, есть выравнивание объектов, есть откат назад
Простая панель управления, нет выравнивания объектов, нет отката назад
9. UDP-свойства объектов, определяемые пользователем
Большое, но ограниченное количество свойств, количество типов ограничено
Количество UDP не ограничено. Количество типов ограничено
Окончание табл. 3.3
Возможности/ инструментальная среда
ARIS Toolset 5.0
10. Возможность анализа стоимости процессов
Есть. Возможность использовать ARIS АВС
Упрощенный анализ стоимости по частоте использования в процессе. Возможность экспорта в Easy АВС
11. Генерация отчетов
Создание отчетов на основе стандартных и настраиваемых пользователем макросов Visual Basic
RPT Win, возможность визуальной настройки отчетов, включая расчет по формулам с использованием UDP
12. Сложность разработки нестандартных отчетов
Для удобства пользователя модели объекты моделей могут храниться в различных группах, организованных в зависимости от специфики проекта. Вполне естественно, что в ARIS предусмотрены различные функции по администрированию БД: управление доступом, консолидация и т. п. В BPWin данные модели хранятся в файле, что существенно упрощает работу по созданию модели, но, с другой стороны, ограничивает возможности по анализу объектов модели. В ModelMart также предусмотрено администрирование базы данных.
Часто одним из недостатков BPWin сторонники методологии ARIS называют ограничение по количеству объектов на диаграмме. Однако опыт реальных проектов показывает, что для проекта, результаты которого можно реально использовать (критерий — обозримость), количество объектов в БД ARIS или модели BPWin составляет 150-300. Это означает, что при 8 объектах на одной диаграмме общее количество диаграмм (листов) в модели составит 20-40.
Базы данных ARIS Toolset (как и BPWin), содержащие более 500 объектов, фактически невозможно использовать. Следует подчеркнуть, что модель создается для выделения и анализа проблем, т. е. требуется детальное описание наиболее сложных, проблемных областей деятельности, а не тотальное описание всех процессов. Как ни странно, у директоров компаний существует вера в то, что детальное описание процессов само по себе представляет ценность и может решить многие проблемы. Это далеко не так. Именно понимание того, что нужно описывать и какие аспекты функционирования реальной системы при этом отражать, определяет успех проекта по моделированию бизнес-процессов.
ARIS предоставляет существенно больше возможностей по работе с отдельными объектами модели, но именно вследствие чрезмерного количества настроек работа по созданию модели должна регламентироваться сложной, многоаспектной документацией — соглашениями по моделированию. Разработка этих соглашений является сложной, дорогостоящей задачей, требующей значительного времени (1-3 месяца) и наличия квалифицированных специалистов. Если проект с использованием ARIS начинается без детальной проработки таких соглашений, то вероятность создания моделей бизнес-процессов, не отвечающих на поставленные вопросы, составляет 80-90 %.
BPWin отличается от ARIS простотой в использовании и достаточно строгой регламентацией при создании диаграмм (наличие стандарта IDEF и рекомендаций по его применению, бланка IDEF для создания диаграммы, ограничений по количеству обязательно заполняемых полей и объектов на одной диаграмме и др.). ARIS, безусловно, является более «тяжелым» инструментом по сравнению с BPWin, но это в итоге оборачивается значительными трудностями и высокими затратами на его эксплуатацию.
Позиционирование систем BPWin и ARIS можно провести по функциональным возможностям и простоте использования в проекте (рис. 3.33).
Для ведения небольших по масштабам (малые и средние предприятия, 2-5 человек в группе консультантов) и длительности (2-3 месяца) проектов рационально использовать BPWin.
L Функциональные возможности
Простота использования в проекте ____________________________________________________________ь.
Рис. 3.33. Позиционирование систем BPWin и ARIS по функциональным возможностям и простоте использования в проекте
Для крупных и/или длительных проектов (напри-мер, внедрение систем непрерывного улучшения бизнес-процессов, ISO, TQM) больше подходит ARIS. В этом случае подготовительные работы по созданию регламентирующей документации могут занять 1-3 месяца, но это является необходимым элементом последующей успешной работы.
Компанией IDS Scheer в 2009 г. создан продукт ARIS Express, ориентированный на новичков в моделировании процессов и обычных пользователей, не достаточно глубоко разбирающихся в информационных технологиях, а также на преподавателей и студентов университетов. Программное обеспечение ARIS Express предлагается в качестве альтернативы таким инструментам для рисования, как MS Visio и MS PowerPoint. ARIS Express доступен для загрузки на сайте сообщества ARIS Community. В настоящее время продукт существует только с англоязычным интерфейсом.
Вопросы для самоконтроля
- 1. Кто автор концепции ARIS, и какие преимущества этой концепции он декларирует?
- 2. Укажите четыре отдельных типа, отражающие различные аспекты исследуемой системы, на которые делится модель ARIS.
- 3. С какой целью в ARIS вводится управляющая модель?
- 4. Как строятся модели архитектуры ARIS при описании бизнес-процесса?
- 5. Опишите общую архитектуру ARIS.
- 6. С какой целью вводится организационная модель ARIS?
- 7. Опишите организацию календаря смен в ARIS.
- 8. Опишите процессно-ориентированное функциональное дерево в ARIS.
- 9. Опишите Y-диаграмму в ARIS.
- 10. Приведите пример диаграммы целей в ARIS.
- 11. С какой целью в ARIS вводится функциональная модель?
- 12. Опишите расширенную модель «сущность-отношение» в ARIS.
- 13. Приведите пример описания объектов на уровне формулировки требований и спецификации проекта в информационной модели ARIS.
- 14. Приведите описание и пример диаграмм PCDs.
- 15. Приведите описание и пример диаграмм EPCs.
- 16. Какие диаграммы могут использоваться в ARIS при построении управляющей модели (за исключением PCDs и EPCs)? Дайте им краткую характеристику.
- 17. Приведите описание и пример диаграмм «Технические ресурсы».
- 18. Приведите описание и пример диаграмм материалов.
- 19. Приведите описание и пример диаграмм стоимостных драйверов.
- 20. Что собой представляет метод управления знаниями в методологии ARIS?
- 21. Приведите сравнительный анализ методологий ARIS и BPwin.
Источник: ozlib.com
Сравнительный анализ нотаций ARIS/IDEF и продуктов их поддерживающих (ARIS Toolset/BPWin)
Описание бизнес-процессов проводится с целью их дальнейшего анализа и реорганизации. Целью реорганизации может быть внедрение информационной системы, сокращение затрат на выпуск продукции, повышение качества обслуживания клиентов, создание должностных и рабочих инструкций при внедрении стандартов ISO-9000 и т.д. Для каждой такой задачи существует определенные параметры, определяющие набор критических знаний по бизнес-процессу. От задачи к задаче требования к описанию бизнес-процессов могут меняться. В общем случае, модель бизнес-процесса должна давать ответы на следующие вопросы:
какие процедуры (функции, работы) необходимо выполнить для получения заданного конечного результата;
в какой последовательности выполняются эти процедуры;
какие механизмы контроля и управления существуют в рамках рассматриваемого бизнес-процесса;
кто выполняет процедуры процесса;
какие входящие документы/информацию использует каждая процедура процесса;
какие исходящие документы/информацию генерирует процедура процесса;
какие ресурсы необходимы для выполнения каждой процедуры процесса;
какая документация/условия регламентирует выполнение процедуры;
какие параметры характеризуют выполнение процедур и процесса в целом.
Описание бизнес-процесса формируется при помощи нотации и инструментальной среды, позволяющих отразить все указанные выше аспекты. Только в этом случае модель бизнес-процесса окажется полезной для предприятия, т.к. ее можно будет подвергнуть анализу и реорганизации.
2. Описание нотации ARIS eEPC
Нотация 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 при создании модели бизнес-процесса.
Каждый объект в системе ARIS Toolset, которая поддерживает метод описания бизнес-процессов ARIS, имеет определенный набор атрибутов. Пользователю предлагается воспользоваться стандартными атрибутами для описания объектов или ограниченным количество т.н. пользовательских атрибутов.
Из рисунка 1 видно, что бизнес-процесс в нотации eEPC представляет собой последовательность процедур, расположенных в порядке их выполнения. Следует отметить, что реальная длительность выполнения процедур в eEPC визуально отражена быть не может. Это приводит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя будет возложено выполнение двух задач одновременно. Используемые при построении модели символы логики позволяют отразить ветвление и слияние бизнес-процесса. Для получения информации о реальной длительности процессов необходимо использовать другие инструменты описания, например графики Ганта в системе MS Project.
Таким образом, при помощи нотации eEPC ARIS можно описывать бизнес-процесс в виде потока последовательно выполняемых работ (процедур, функций). Пример моделей, сформированных с использованием ARIS eEPC, показаны на рисунках 3-4.
Рисунок 3.
Рисунок 4.
3. Описание нотации IDEF0, IDEF3
Нотация IDEF0 была разработана на основе методологии структурного анализа и проектирования SADT, утверждена в качестве стандарта США и успешно эксплуатируется во многих проектах, связанных с описанием деятельности предприятий. Нотация IDEF3 была разработана с целью более удобного описания рабочих процессов (Work Flow), для которых важно отразить логическую последовательность выполнения процедур. Нотации IDEF0 и IDEF3 используют следующие объекты.
В моделях могут использоваться стрелки трех видов, показанных в следующей таблице 3.
Семантика построения моделей IDEF0 и IDEF3 предполагает соблюдение четких правил. Детальную информацию о построении моделей в IDEF0,3 можно узнать в стандартах и книгах (см. литературу).
Бизнес-процесс, сформированный при помощи нотации IDEF0, показан на рисунке 5. (Этот процесс представлен в нотации ARIS eEPC на рисунке 3).
Рисунок 5.
На рисунке 6 показан бизнес-процесс, описанный при помощи нотации IDEF3. (Этот процесс представлен в нотации ARIS eEPC на рисунке 4.)
Рисунок 6.
В нотации IDEF3, так же как и в нотации ARIS eEPC, используются символы логики, отражающие ветвление процесса.
4. Сравнительный анализ нотаций ARIS и IDEF
Сравнительный анализ нотаций ARIS и IDEF приводится в следующей таблице.
Таблица 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 необходимо заранее договориться, как будут отражены в модели документы (информация), регламентирующие выполнение процедур процесса.
5. Функциональные возможности продуктов ARIS и BPWin
Функциональные возможности инструментальных средств моделирования ARIS Toolset и BPWin можно корректно сравнивать только по отношению к определенному кругу задач. В данном исследовании рассматривается задача формирования моделей (описания) бизнес-процессов предприятия. Каждая из рассматриваемых систем имеет свои преимуществ и недостатки.
В зависимости от решаемых задач эти преимущества могут как усиливаться, так и наоборот. То же касается и недостатков: недостаток системы в рамках одного проекта, может не быть недостатком в рамках другого. Например, отсутствие четких соглашений по моделированию управляющих воздействий в рамках eEPC ARIS может привести к созданию моделей, не отвечающих на поставленные вопросы, в то время как нотация IDEF0 системы BPWin позволяет решить эту задачу. С другой стороны, описание процедуры, выполняемой одним сотрудником, может быть описано более адекватно при помощи eEPC ARIS, чем IDEF0 или IDEF3 BPWin. Сравнение функциональных возможностей систем приводится в следующей таблице.
Сравнивая две системы, следует сразу отметить, что для хранения моделей в 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, но это в итоге оборачивается значительными трудностями и высокими затратами на его эксплуатацию.
6. Выводы. Рекомендации по применению систем в зависимости от типовых задач
Источник: logscm.ru