Сравнительный анализ нотаций
                Основная задача данного аналитического исследования состоит в том, чтобы ответить на ряд вопросов, возникающих у руководителей и специалистов в начале проекта по моделированию и реорганизации бизнес-процессов предприятия.
Оглавление
- 
			Введение. Типовые задачи описания бизнес-процессов.
Требования к описанию бизнес-процессов предприятий. - Описание нотации ARIS eEPC.
 - Описание нотации IDEF0, IDEF3.
 - Сравнительный анализ нотаций ARIS и IDEF.
 - Функциональные возможности продуктов ARIS и BPwin.
 - Выводы. Рекомендации по применению систем в зависимости от типовых задач.
 
Введение. Типовые задачи описания бизнес-процессов. Требования к описанию бизнес-процессов предприятий.
Основная задача данного аналитического исследования состоит в том, чтобы ответить на ряд вопросов, возникающих у руководителей и специалистов в начале проекта по моделированию и реорганизации бизнес-процессов предприятия. Наиболее часто в этом случае задают следующие вопросы (по степени важности для спрашивающих):
- какое программное обеспечение использовать в проекте («ARIS лучше BPwin?», «ERwin лучше ARIS?» и т.п.);
 - как моделировать процессы с использованием продукта «Х»?;
 - как проводить анализ и выявлять проблемы при помощи продукта «Х»?;
 - какую методологию использовать для описания процессов?
 
В настоящее время на российском рынке представлено достаточно большое количество CASE-систем, многие из которых позволяют, так или иначе, создавать описания (модели) бизнес-процессов предприятий. Очевидно, что выбор системы в значительной мере определяет весь дальнейший ход проекта. Рациональный выбор системы возможен при понимании руководством компании, и ее специалистами нескольких аспектов:
- целей проекта;
 - требований к информации, характеризующей бизнес-процессы и необходимой для анализа и принятия решений в рамках конкретного проекта;
 - возможностей CASE-систем по описанию процессов с учетом требований п.2.
 
Говорить о преимуществе той или иной системы/нотации бессмысленно, пока не определены тип и рамки проекта, основные задачи, которые данные проект должен решить. В настоящем исследовании сделана попытка провести сравнение наиболее популярных нотаций, используемых для описания бизнес-процессов, и двух систем, поддерживающих эти нотации. Предполагается, что данное исследование послужит основанием для дискуссии, посвященной проблемам эффективного применения CASE-систем для описания и анализа бизнес-процессов предприятий.
Описание бизнес-процессов проводится с целью их дальнейшего анализа и реорганизации. Целью реорганизации может быть внедрение информационной системы, сокращение затрат на выпуск продукции, повышение качества обслуживания клиентов, создание должностных и рабочих инструкций при внедрении стандартов ISO-9000 и т.д. Для каждой такой задачи существует определенные параметры, определяющие набор критических знаний по бизнес-процессу. От задачи к задаче требования к описанию бизнес-процессов могут меняться. В общем случае, модель бизнес-процесса должна давать ответы на следующие вопросы:
- какие процедуры (функции, работы) необходимо выполнить для получения заданного конечного результата;
 - в какой последовательности выполняются эти процедуры;
 - какие механизмы контроля и управления существуют в рамках рассматриваемого бизнес-процесса;
 - кто выполняет процедуры процесса;
 - какие входящие документы/информацию использует каждая процедура процесса;
 - какие исходящие документы/информацию генерирует процедура процесса;
 - какие ресурсы необходимы для выполнения каждой процедуры процесса;
 - какая документация/условия регламентирует выполнение процедуры;
 - какие параметры характеризуют выполнение процедур и процесса в целом.
 
Описание бизнес-процесса формируется при помощи нотации и инструментальной среды, позволяющих отразить все указанные выше аспекты. Только в этом случае модель бизнес-процесса окажется полезной для предприятия, т.к. ее можно будет подвергнуть анализу и реорганизации.
Описание нотации ARIS eEPC
Нотация ARIS eEPC расшифровывается следующим образом - Extended Event Driven Process Chain – расширенная нотация описания цепочки процесса, управляемого событиями. Нотация разработана специалистами компании IDS Scheer AG (Германия), в частности профессором Шеером. В следующей таблице приводятся основные используемые в рамках нотации объекты.
| 
						 №  | 
					
						 Наименование  | 
					
						 Описание  | 
					
						 Графическое представление  | 
				
| 
						 1  | 
					
						 Функция  | 
					
						 Объект «Функция» служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия.  | 
					
						 
							  | 
				
| 
						 2  | 
					
						 Событие  | 
					
						 Объект «Событие» служит для описания реальных состояний системы, влияющих и управляющих выполнением функций  | 
					
						 
							  | 
				
| 
						 3  | 
					
						 Организационная единица  | 
					
						 Объект, отражающий различные организационные звенья предприятия (например, управление или отдел)  | 
					
						 
							  | 
				
| 
						 4  | 
					
						 Документ  | 
					
						 Объект, отражающий реальные носители информации, например бумажный документ  | 
					
						 
							  | 
				
| 
						 5  | 
					
						 Прикладная система  | 
					
						 Объект отражает реальную прикладную систему, используемую в рамках технологии выполнения функции  | 
					
						 
							  | 
				
| 
						 6  | 
					
						 Кластер информации  | 
					
						 Объект характеризует данные, как набор сущностей и связей между ними. Используется для создания моделей данных  | 
					
						 
							  | 
				
| 
						 7  | 
					
						 Стрелка связи между объектами  | 
					
						 Объект описывает тип отношений между другими объектами, например – активацию выполнения функции некоторым событием  | 
					
						 
							  | 
				
| 
						 8  | 
					
						 Логическое «И»  | 
					
						 Логический оператор, определяющий связи между событиями и функциями в рамках процесса. Позволяет описать ветвление процесса  | 
					
						 
							  | 
				
| 
						 9  | 
					
						 Логическое «ИЛИ»  | 
					
						 Логический оператор, определяющий связи между событиями и функциями в рамках процесса. Позволяет описать ветвление процесса  | 
					
						 
							  | 
				
| 
						 10  | 
					
						 Логическое исключающее «ИЛИ»  | 
					
						 Логический оператор, определяющий связи между событиями и функциями в рамках процесса. Позволяет описать ветвление процесса  | 
					
						 
							  | 
				
Таблица 1
Помимо указанных в Таблице 1 основных объектов, при построении диаграммы eEPC могут быть использованы многие другие объекты. Применение большого числа различных объектов, связанных различными типами связей значительно увеличивает размер модели и делает ее плохо читаемой. Для понимания смысла нотации eEPC достаточно рассмотреть основные используемые типы объектов и связей. На следующем рисунке представлена простейшая модель eEPC, описывающая фрагмент бизнес-процесса предприятия.
		
		Рисунок 1.
На рисунке 1 видно, что связи между объектами имеют определенный смысл и отражают последовательность выполнения функций в рамках процесса. Стрелка, соединяющая Событие 1 и Функцию 1 «активирует» или инициирует выполнение Функции 1. Функция 1 «создает» Событие 2, за которым следует символ логического «И», «запускающий» выполнение Функций 2 и 3. Нотация eEPC построена на определенных семантических правилах описания:
- каждая функция должна быть инициирована событием и должна завершаться событием;
 - в каждую функцию не может входить более одной стрелки, «запускающей» выполнение функции, и выходить не более одной стрелки, описывающей завершение выполнения функции.
 
Кроме этих правил, существуют и другие важные правила формирования моделей в ARIS. Эти правила можно изучить при помощи методического материала «Методы ARIS», который устанавливается на компьютер одновременно с демо-версией продукта.
На рисунке 2 показано применение различных объектов ARIS при создании модели бизнес-процесса.
		
		Рисунок 2.
Каждый объект в системе ARIS Toolset, которая поддерживает метод описания бизнес-процессов ARIS, имеет определенный набор атрибутов. Пользователю предлагается воспользоваться стандартными атрибутами для описания объектов или ограниченным количество т.н. пользовательских атрибутов.
Из рисунка 1 видно, что бизнес-процесс в нотации eEPC представляет собой последовательность процедур, расположенных в порядке их выполнения. Следует отметить, что реальная длительность выполнения процедур в eEPC визуально отражена быть не может. Это приводит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя будет возложено выполнение двух задач одновременно. Используемые при построении модели символы логики позволяют отразить ветвление и слияние бизнес-процесса. Для получения информации о реальной длительности процессов необходимо использовать другие инструменты описания, например графики Ганта в системе MS Project.
Таким образом, при помощи нотации eEPC ARIS можно описывать бизнес-процесс в виде потока последовательно выполняемых работ (процедур, функций). Пример моделей, сформированных с использованием ARIS eEPC, показаны на рисунках 3-4.
		
		Рисунок 3.
		
		Рисунок 4.
Описание нотации IDEF0, IDEF3
Нотация IDEF0 была разработана на основе методологии структурного анализа и проектирования SADT, утверждена в качестве стандарта США и успешно эксплуатируется во многих проектах, связанных с описанием деятельности предприятий. Нотация IDEF3 была разработана с целью более удобного описания рабочих процессов (Work Flow), для которых важно отразить логическую последовательность выполнения процедур. Нотации IDEF0 и IDEF3 используют следующие объекты.
| 
						 №  | 
					
						 Наименование  | 
					
						 Описание  | 
					
						 Графическое представление  | 
				
| 
						 Нотация IDEF0  | 
				|||
| 
						 1  | 
					
						 Модуль поведения (UOB)  | 
					
						 Объект служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия.  | 
					
						 
							  | 
				
| 
						 2  | 
					
						 Стрелка слева  | 
					
						 Стрелка описывает входящие документы, информацию, материальные ресурсы, необходимые для выполнения функции.  | 
					
						 
							  | 
				
| 
						 3  | 
					
						 Стрелка справа  | 
					
						 Стрелка описывает исходящие документы, информацию, материальные ресурсы, являющиеся результатом выполнения функции.  | 
					
						 
							  | 
				
| 
						 4  | 
					
						 Стрелка сверху  | 
					
						 Стрелка описывает управляющее воздействия, например распоряжение, нормативный документ и т.д. В нотации IDEF0 каждая процедура должна обязательно иметь не менее одной стрелки сверху, отражающей управляющее воздействие.  | 
					
						 
							  | 
				
| 
						 5  | 
					
						 Стрелка снизу  | 
					
						 Стрелка снизу описывает т.н. механизмы, т.е. ресурсы, необходимые для выполнения процедуры, но не изменяющие в процессе ее выполнения свое состояние. Примеры: сотрудник, станок и т.д.  | 
					
						 
							  | 
				
| 
						 Нотация IDEF3  | 
				|||
| 
						 1  | 
					
						 Модель работы (UOW)  | 
					
						 Объект служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия.  | 
					
						 
							  | 
				
| 
						 2  | 
					
						 Ссылочный объект  | 
					
						 Объект, используемый для описания ссылок на другие диаграммы модели, циклические переходы в рамках одной модели, различные комментарии к функциям.  | 
					
						 
							  | 
				
| 
						 3  | 
					
						 Логическое «И»  | 
					
						 Логический оператор, определяющий связи между функциями в рамках процесса. Позволяет описать ветвление процесса.  | 
					
						 
							  | 
				
| 
						 4  | 
					
						 Логическое «ИЛИ»  | 
					
						 Логический оператор, определяющий связи между функциями в рамках процесса. Позволяет описать ветвление процесса.  | 
					
						 
							  | 
				
| 
						 5  | 
					
						 Логическое исключающее «ИЛИ»  | 
					
						 Логический оператор, определяющий связи функциями в рамках процесса. Позволяет описать ветвление процесса.  | 
					
						 
							  | 
				
Таблица 2
В моделях могут использоваться стрелки трех видов, показанных в следующей таблице 3.
| 
						 №  | 
					
						 Тип стрелки  | 
					
						 Графическое представление  | 
				
| 
						 1  | 
					
						 Стрелка предшествования. Соединяет последовательно выполняемые функции.  | 
					
						 
							  | 
				
| 
						 2  | 
					
						 Стрелка отношения. Используется для привязки объектов-комментариев к функциям.  | 
					
						 
							  | 
				
| 
						 3  | 
					
						 Стрелка потока объектов. Показывает поток объектов от одной функции к другой.  | 
					
						 
							  | 
				
Таблица 3
Семантика построения моделей IDEF0 и IDEF3 предполагает соблюдение четких правил. Детальную информацию о построении моделей в IDEF0,3 можно узнать в стандартах и книгах (см. литературу).
Бизнес-процесс, сформированный при помощи нотации IDEF0, показан на рисунке 5. (Этот процесс представлен в нотации ARIS eEPC на рисунке 3).
		
		Рисунок 5.
На рисунке 6 показан бизнес-процесс, описанный при помощи нотации IDEF3. (Этот процесс представлен в нотации ARIS eEPC на рисунке 4.
		
		Рисунок 6.
В нотации IDEF3, так же как и в нотации ARIS eEPC, используются символы логики, отражающие ветвление процесса.
Сравнительный анализ нотаций ARIS и IDEF
Сравнительный анализ нотаций ARIS и IDEF приводится в следующей таблице.
| 
						 №  | 
					
						 Критерии сравнения  | 
					
						 ARIS  | 
					
						 IDEF0  | 
					
						 IDEF3  | 
				
| 
						 1  | 
					
						 Принцип построения диаграммы / логика процесса  | 
					
						 Временная последовательность выполнения процедур  | 
					
						 Принцип доминирования (см. стандарт IDEF0)  | 
					
						 Временная последовательность выполнения процедур  | 
				
| 
						 2  | 
					
						 Описание процедуры процесса  | 
					
						 Объект на диаграмме  | 
					
						 Объект на диаграмме  | 
					
						 Объект на диаграмме  | 
				
| 
						 3  | 
					
						 Входящий документ  | 
					
						 Используется отдельный объект для описания («документ»)  | 
					
						 Стрелка слева, стрелка сверху  | 
					
						 Нет (может быть отражен в модели только привязкой объекта-комментария)  | 
				
| 
						 4  | 
					
						 Входящая информация  | 
					
						 Используется отдельный объект для описания («кластер», «технический термин»)  | 
					
						 Стрелка слева, стрелка сверху  | 
					
						 Нет (может быть отражен в модели только привязкой объекта-комментария)  | 
				
| 
						 5  | 
					
						 Исходящий документ  | 
					
						 Используется отдельный объект для описания («документ»)  | 
					
						 Стрелка справа  | 
					
						 Нет (может быть отражен в модели только привязкой объекта-комментария)  | 
				
| 
						 6  | 
					
						 Исходящая информация  | 
					
						 Используется отдельный объект для описания («кластер», «технический термин»)  | 
					
						 Стрелка справа  | 
					
						 Нет (может быть отражен в модели только привязкой объекта-комментария)  | 
				
| 
						 7  | 
					
						 Исполнитель процедуры  | 
					
						 Используется отдельный объект для описания («позиция», «организационная единица»)  | 
					
						 Стрелка снизу  | 
					
						 Нет (может быть отражен в модели только привязкой объекта-комментария)  | 
				
| 
						 8  | 
					
						 Используемое оборудование  | 
					
						 Используется отдельный объект для описания  | 
					
						 Стрелка снизу  | 
					
						 Нет (может быть отражен в модели только привязкой объекта-комментария)  | 
				
| 
						 9  | 
					
						 Управление процедурой  | 
					
						 Нет. Может быть отражено только символами логики и событий (последовательность выполнения процедур) и/или указанием входящих документов  | 
					
						 Стрелка сверху  | 
					
						 Только временная последовательность выполнения процедур и логика процесса  | 
				
| 
						 10  | 
					
						 Контроль выполнения процедуры  | 
					
						 Нет. Может быть отражен указанием входящих документов  | 
					
						 Стрелка сверху  | 
					
						 Нет.  | 
				
| 
						 11  | 
					
						 Обратная связь по управлению/контролю  | 
					
						 Нет. Может быть отражена только символами логики (последовательность выполнения процедур)  | 
					
						 Стрелка сверху  | 
					
						 Нет.  | 
				
Таблица 4
Одним из важнейших аспектов описания моделей бизнес-процессов является отражение на модели управляющих воздействий, обратных связей по контролю и управлению процедурой. В нотации ARIS eEPC управление процедурой может быть отражено только при помощи указания входящих документов, которые регламентируют выполнение процедуры, и последовательности выполнения процедур во времени (запускающие события). В отличие от ARIS, в нотации IDEF0 каждая процедура должна иметь хотя бы одно управляющее воздействие (вход управления – стрелка сверху). Если при создании модели в eEPC указывать только последовательность выполнения процедур, не заботясь об отражении управляющих документов и информации, полученные модели будут иметь низкую ценность с точки зрения анализа и дальнейшего использования. К сожалению, именно эта ошибка наиболее распространена на практике. Создается модель Work Flow (поток работы), отражающая простую последовательность выполнения процедур и входящих/исходящих документов, при этом управляющие (контрольные) воздействия на функции в модели не отражаются. Реальные процессы управления могут остаться «за кадром» на 30-90% (см. пример на следующем рисунке).
		
		Рисунок 7. Недостатки описания бизнес-процесса в ARIS eEPC.
На рисунке 7 Функция 4 является контрольной и служит для проверки результатов выполнения работы, выполняемой функциями 2 и 3. Но данная модель не отвечает на вопросы:
- каким образом осуществляется управляющее воздействие на функции 2 и 3, показан только тот факт, что по ходу процесса возможен возврат и повторное выполнение функций 2 и 3; информация об этой обратной связи может быть раскрыта только в виде описания в атрибутах объектов модели;
 - какие документы (например, нормативы), распоряжения, внешние условия (например, влажность воздуха в помещении), регламентируют выполнение функций.
 
Если пытаться отразить все условия и ограничения, определяющие выполнение функций, то потребуется описать большое количество событий и входящей информации (например, устных распоряжений руководителей), и модель станет сложной и плохо читаемой. (Эти недостатки присущи так же и нотации IDEF3). Указанных недостатков нет у нотации IDEF0. В то же время, на моделях в IDEF0 не предусмотрено использование символов логики выполнения процесса.
Таким образом, нотация ARIS eEPC является расширением достаточно простой нотации IDEF3. Для адекватного описания процесса управления в нотации eEPC необходимо заранее договориться, как будут отражены в модели документы (информация), регламентирующие выполнение процедур процесса.
Функциональные возможности продуктов ARIS и BPwin
Функциональные возможности инструментальных средств моделирования ARIS Toolset и BPwin можно корректно сравнивать только по отношению к определенному кругу задач. В данном исследовании рассматривается задача формирования моделей (описания) бизнес-процессов предприятия. Каждая из рассматриваемых систем имеет свои преимуществ и недостатки. В зависимости от решаемых задач эти преимущества могут как усиливаться, так и наоборот. То же касается и недостатков: недостаток системы в рамках одного проекта, может не быть недостатком в рамках другого. Например, отсутствие четких соглашений по моделированию управляющих воздействий в рамках eEPC ARIS может привести к созданию моделей, не отвечающих на поставленные вопросы, в то время как нотация IDEF0 системы BPwin позволяет решить эту задачу. С другой стороны, описание процедуры, выполняемой одним сотрудником, может быть описано более адекватно при помощи eEPC ARIS, чем IDEF0 или IDEF3 BPwin. Сравнение функциональных возможностей систем приводится в следующей таблице.
| 
						 №  | 
					
						 Возможности/Инструментальная среда  | 
					
						 ARIS Toolset 5.0  | 
					
						 BPwin 4.0  | 
				
| 
						 1  | 
					
						 Поддерживаемый стандарт  | 
					
						 - (частично – DFD, ERM, UML)  | 
					
						 IDEF0, IDEF3, DFD  | 
				
| 
						 2  | 
					
						 Система хранения данных модели  | 
					
						 Объектная база данных  | 
					
						 Модели хранятся в файлах  | 
				
| 
						 3  | 
					
						 Ограничение на размер базы данных  | 
					
						 Нет. Размер базы данных ограничивается вычислительными ресурсами  | 
					
						 Нет. Размер базы данных ограничивается вычислительными ресурсами  | 
				
| 
						 4  | 
					
						 Возможность групповой работы  | 
					
						 Есть. Используется ARIS Server.  | 
					
						 Есть. Используется ModelMart.  | 
				
| 
						 5  | 
					
						 Ограничение на количество объектов на диаграмме.  | 
					
						 Нет.  | 
					
						 От 2 до 8.  | 
				
| 
						 6  | 
					
						 Возможность декомпозиции  | 
					
						 Неограниченная декомпозиция. Возможно декомпозиция на различные типы моделей.  | 
					
						 Неограниченная декомпозиция. Возможен однократный переход на другую нотацию в процессе декомпозиции.  | 
				
| 
						 7  | 
					
						 Формат представления моделей  | 
					
						 Не регламентируется  | 
					
						 Стандартный бланк IDEF с возможностью его отключения  | 
				
| 
						 8  | 
					
						 Удобство работы по созданию моделей  | 
					
						 Сложная панель управления, есть выравнивание объектов, есть undo.  | 
					
						 Простая панель управления, нет выравнивания объектов, нет undo.  | 
				
| 
						 9  | 
					
						 UDP – свойства объектов, определяемые пользователем  | 
					
						 Большое, но ограниченное количество свойств, количество типов ограничено.  | 
					
						 Количество UDP не ограничено. Количество типов ограничено.  | 
				
| 
						 10  | 
					
						 Возможность анализа стоимости процессов  | 
					
						 Есть. Возможность использовать ARIS ABC.  | 
					
						 Упрощенный анализ стоимости по частоте использования в процессе. Возможность экспорта в Easy ABC.  | 
				
| 
						 11  | 
					
						 Генерация отчетов  | 
					
						 Создание отчетов на основе стандартных и настраиваемых пользователем макросов Visual Basic.  | 
					
						 RPT Win, возможность визуальной настройки отчетов, включая расчет по формулам с использованием UDP  | 
				
| 
						 12  | 
					
						 Сложность разработки нестандартных отчетов  | 
					
						 Сложно  | 
					
						 Просто  | 
				
Таблица 5
Сравнивая две системы, следует сразу отметить, что для хранения моделей в ARIS используется объектная СУБД, и под каждый проект создается новая база данных. Для удобства пользователя модели (объекты моделей) могут храниться в различных группах, организованных в зависимости от специфики проекта. Вполне естественно, что в ARIS-е предусмотрены различные функции по администрированию базы данных: управление доступом, консолидация и т.п. В BPwin данные модели хранятся в файле, что существенно упрощает работу по созданию модели, но с другой стороны ограничивает возможности по анализу объектов модели. В ModelMart так же предусмотрено администрирование базы данных.
Часто одним из недостатков BPwin сторонники ARIS-а называют ограничение по количеству объектов на диаграмме. Однако опыт реальных проектов показывает, что для проекта, результаты которого можно реально использовать (критерий – обозримость), количество объектов в базе данных ARIS или модели BPwin составляет 150-300. Это означает, что при 8 объектах на одной диаграмме, общее количество диаграмм (листов) в модели составит 20-40. Базы данных ARIS Toolset (как и BPwin), содержащие более 500 объектов, фактически невозможно использовать. Следует подчеркнуть, что модель создается для выделения и анализа проблем, т.е. требуется детальное описание наиболее сложных, проблемных областей деятельности, а не тотальное описание всех процессов. Как ни странно, среди директоров компаний существует вера в то, что детальное описание процессов само по себе представляет ценность и может решить многие проблемы. Это далеко не так. Именно понимание того, что нужно описывать и какие аспекты функционирования реальной системы при этом отражать, определяет успех проекта по моделированию бизнес-процессов.
ARIS предоставляет существенно больше возможностей по работе с отдельными объектами модели, но именно вследствие чрезмерного количества настроек работа по созданию модели должна регламентироваться сложной, многоаспектной документацией – т.н. «Соглашениями по моделированию». Разработка этих «Соглашений» само по себя является сложной, дорогой и требующей значительного времени (1-3 месяца) и квалифицированных специалистов задачей. Если проект с использованием ARIS начинается без детальной проработки таких соглашений, то вероятность создания моделей бизнес-процессов, не отвечающих на поставленные вопросы, составляет 80-90%. В свою очередь, BPwin отличается простотой в использовании, и достаточной строгой регламентацией при создании диаграмм (стандарт IDEF и рекомендации по его применению, бланк IDEF для создания диаграммы, ограниченное количество обязательно заполняемых полей, ограничение количества объектов на одной диаграмме и т.д.). ARIS, безусловно, является более «тяжелым» инструментом, по сравнению с BPwin, но это в итоге оборачивается значительными трудностями и высокими затратами на его эксплуатацию.
Выводы. Рекомендации по применению систем в зависимости от типовых задач
Различные ситуации применения инструментальных средств моделирования бизнес-процессов и их экспертная оценка по 5-бальной шкале показаны в следующей таблице.
| 
						 Задача/Инструментальная среда  | 
					
						 ARIS Toolset 5.0  | 
					
						 BPwin 4.0  | 
				
| 
						 Разовый проект по описанию бизнес-процессов, например: 1. описание одного бизнес-процесса с точки зрения контроля и управления; 2. описание функциональных возможностей новой системы управления на верхнем уровне.  | 
					
						
						 
							3  | 
					
						
						 
							5  | 
				
| 
						 Длительный (непрерывный) проект по описанию деятельности компании с различных точек зрения (организационная структура, структура документов, большой объем базы данных процессов и т.д.)  | 
					
						 5  | 
					
						 3  | 
				
| 
						 Разработка системы автоматизации: 1. описание функциональных возможностей системы; 2. создание логической модели данных; 3. создание физической модели данных.  | 
					
						
						 
							3  | 
					
						
						 
							5  | 
				
Таблица 6
Позиционирование систем можно провести по отношению к решению задачи моделирования бизнес-процессов (см. рисунок 8).
		
		Рисунок 8.
Таким образом, для ведения небольших по масштабам (малые и средние предприятия, 2-5 человека в группе консультантов) и длительности (2-3 месяца) проектов рационально использовать BPwin. Для крупных и/или длительных проектов (например, внедрение системы непрерывного улучшения бизнес-процессов, ISO, TQM) больше подходит ARIS. В этом случае подготовительные работы по созданию регламентирующей документации могут занять 1-3 месяца, но это является необходимым элементом последующей успешной работы.
Источник: Finexpert.ru
Похожие статьи
                ваш личный спасательный круг
                в цифровизации бизнеса 
                с полезными советами и новостями
                от экспертов
            
Присоединяйтесь, будем на связи!
















        
        
        
Комментарии 1