2.5.3. Окончательный перечень показателей, вошедших в «Справку о ходе процесса «Управление финансами»»

Показатели продукта:

1. Отклонение налоговых выплат от плановых (в %).

1. Отклонение по прибыли по данным аудиторских прове­ рок (в %).

2. Отклонение по результатам налоговых проверок:

• по доначислению прибыли (в %);

• по доначислению налогов (в %).

4.Отклонения от прогноза исполнения бюджета (в %). Показатели процесса:

5. Закрытие месяца по учетной программе на дней, сле­ дующих за отчетным месяцем.

6. Исполнение бюджета подразделения.

7. Исполнительская дисциплина. Показатели удовлетворенности потребителей:

166

8. Время прохождения документов в подразделении (заяв­ ки на оплату, договора).

9. Процент ошибок (неточностей) при переводах денежных средств.

10. Время простоев по информационному обеспечению — (в часах).

Комментарии консультантов:

Данный список показателей не является окончательным (не­смотря на название раздела). Пересмотр системы показателей должен производиться регулярно вместе с пересмотром системы управления и регламентирования процесса. По мере развития сис­темы управления организации в финансовой службе можно будет выделить три подпроцесса со своими раздельными системами по­казателей, по которым начальники отделов будут отчитывать­ся перед финансовым директором.

2.6. ЛИТЕРАТУРА К ГЛАВЕ 2

1. МС ИСО 9000:2000 Системы менеджмента качества. Основ­ ные положения и словарь.

2. МС ИСО 9001:2000 Системы менеджмента качества. Требо­ вания.

3. МС ИСО 9004:2000 Системы менеджмента качества. Руко­ водящие указания по улучшению деятельности.

4. Веснин В.Р. Основы менеджмента. — М.: Т.Д. «Элит 2000», 2001.

5. Хьюго Брайан Флинт. Взгляд американца на системы управ­ ления предприятиями в России // Стандарты и качество. 2000.

№2.

6. Деминг В. Едвард. Выход из кризиса. — Тверь: Альба, 1994.

7. Друкер Питер Ф. Задачи менеджмента в XXI веке: Пер. с англ. — М.: Издательский дом «Вильямс», 2002.

8. Друкер Питер Ф. Практика менеджмента: Пер. с англ. — М.: Издательский дом «Вильямс», 2001.

9. Пшенников В.В. Продвижение ТРМ: перед новым рубе­ жом // Методы менеджмента качества. 2003. № 12.

10. Искандарян Р.А. Модельные группа в ТРМ // Методы ме­неджмента качества. 2003. № 9.

Глава 3

МЕТОДИКИ РЕГЛАМЕНТАЦИИ БИЗНЕС-ПРОЦЕССОВ

3.1. Обзор методик моделирования

БИЗНЕС-ПРОЦЕССОВ И РЕКОМЕНДАЦИИ

ПО ИХ ПРИМЕНЕНИЮ

3.1.1. Для чего используются методики моделирования бизнес-процессов

Основная задача данного раздела состоит в том, чтобы кратко осветить существующие методики создания графических схем бизнес-процессов и дать рекомендации по их применению. Более подробную информацию об отдельных методиках можно най­ти, например, в [1], [2], [3],[4].

В данной книге термины «процесс» и «бизнес-процесс» ис­пользуются как синонимы для обозначения выделенного сегмента деятельности, управляемого на основе процессного подхода. В данной главе чаще будет использоваться термин «бизнес-про­цесс», так как в методиках моделирования, чаще применяется именно этот термин.

При описании бизнес-процессов с помощью графических схем у руководителей и сотрудников организации возникает ряд вопросов:

1. какую методику выбрать для описания и документирова­ ния бизнес-процессов организации;

2. какое программное обеспечение использовать для описания;

3. как моделировать процессы с использованием выбранного программного продукта;

168

4) как проводить анализ и выявлять проблемы при помощи полученных описаний бизнес-процессов.

В настоящее время на российском рынке представлено дос­таточно большое количество методик (нотаций¹) описания про­цессов и поддерживающих эти методики программных продук­тов. Многие из них предназначены для создания комплексных описаний (моделей²) бизнес-процессов организации. Очевидно, что выбор методики и программного продукта в значительной мере определяет весь дальнейший ход проекта. Рациональный выбор возможен при условии понимания руководителями компании и ее специалистами нескольких важных аспектов:

• целей проекта (что, для чего, каким образом предполагает­ ся менять в организации);

• требований к информации, характеризующей бизнес-процес­ сы и необходимой для анализа и принятия решений в рам­ ках конкретного проекта;

• возможностей методики и соответствующих программных продуктов по описанию (моделированию) процессов с уче­ том требований п. 2;

• возможностей программных продуктов по документирова­ нию процессов.

Говорить о преимуществе той или иной методики бессмыс­ленно, пока не определены тип и рамки проекта, основные за­дачи, которые данный проект должен решить. Ниже приводит­ся сравнение наиболее популярных методик (нотаций), исполь­зуемых для описания бизнес-процессов, и двух наиболее популярных в настоящее время систем, поддерживающих эти нотации.

Как правило, описание бизнес-процессов проводится с це­лью: а) документирования, т.е. описания процессов в виде рег­ламентирующих деятельность документов; б) анализа и реорга­низации процессов. Целью реорганизации может быть повыше­ние результативности и эффективности процессов, внедрение информационной системы, подготовка к сертификации по стан­дартам ISO серии 9000 версии 2000 г. и пр. Для каждой такой задачи существует определенный набор знаний по бизнес-про­цессу, которые должны быть отражены в модели процесса. От

¹ В главе 3 термины «методика» и «нотация» описания процесса ис­ пользуются в качестве синонимов.

² В главе 3 термины «описание» процесса и «модель» процесса исполь­ зуются в качестве синонимов.

169

задачи к задаче требования к описанию бизнес-процессов мо­гут меняться. В общем случае модель бизнес-процесса должна давать ответы на следующие вопросы:

1. какие функции (работы, операции) необходимо выполнить для получения заданного конечного результата;

2. кто выполняет функции процесса;

3. как происходит взаимодействие исполнителей при выпол­ нении этих функций, в какой последовательности;

4. какие механизмы управления существуют в рамках рассмат­ риваемого бизнес-процесса;

5. какие входящие документы/информацию использует каж­ дая функция процесса;

6. какие исходящие документы/информацию генерирует каждая функция процесса;

7. какие ресурсы необходимы для выполнения каждой фун­ кции процесса;

8. какая документация регламентирует выполнение каждой функции;

9. какие параметры характеризуют выполнение каждой фун­ кции в отдельности и процесса в целом.

Описание бизнес-процесса формируется при помощи методик (нотаций) и программных продуктов, позволяющих отразить все указанные выше аспекты. Только в этом случае модель бизнес-процесса окажется полезной для организации.

3.1.2. Описание нотации ARIS еЕРС

Нотация ARIS еЕРС расшифровывается следующим обра­зом — extended Event Driven Process Chain — расширенная нотация описания цепочки процесса, управляемого события­ми. Нотация разработана специалистами компании IDS Scheer AG (Германия), в частности профессором Шеером (см. [4]). Нотация ARIS еЕРС относится к классу нотаций work flow¹), которые предназначены для описания деятельности в динамике. Модели потоков работ (ARIS еЕРС, IDEF3 и др.) позволяют отобразить последовательность выполнения отдельных функ­ций процесса. В следующей таблице приводятся основные ис­пользуемые в рамках нотации ARIS еЕРС объекты.

Помимо указанных в таблице основных объектов, при по­строении диаграммы ARIS еЕРС могут быть использованы мно-

¹ Work flow — поток работ. 170

Таблица 3.1

Основные объекты, используемые в рамках нотации ARIS еЕРС

№	Наимено­вание	Описание	Графическое пред­ставление
1	Функция	Объект «Функция» служит для описания функций(процедур, работ), выполняемых подразде­лениями/сотрудниками органи­зации
2	Событие	Объект «Событие» служит для описания реальных состояний системы, влияющих и управ­ляющих выполнением функций
3	Организа­ционная единица	Объект, отражающий различные организационные звенья (на­пример, управление или отдел)
4	Документ	Объект, отражающий реальные носители информации, напри­мер бумажный документ
5	Приклад­ная систе­ма	Объект отражает реальную при­кладную систему, используемую в при выполнении функции
6	Кластер информа­ции	Объект характеризует данные, как набор сущностей и связей между ними. Используется для создания моделей данных
7	Стрелка связи ме­жду объек­тами	Объект описывает тип отноше­ний между другими объектами, например — активацию выпол­нения функции некоторым собы­тием
8	Логическое «И»	Логический оператор, опреде­ляющий связи между событиями и функциями в рамках процесса. Позволяет описать ветвление процесса
9	Логическое «ИЛИ»	Логический оператор, опреде­ляющий связи между событиями и функциями в рамках процесса. Позволяет описать ветвление процесса
10	Логическое исклю­чающее «ИЛИ»	Логический оператор, опреде­ляющий связи между событиями и функциями в рамках процесса. Позволяет описать ветвление процесса

гие другие объекты. Применение большого числа различных объектов, связанных различными типами связей, значительно увеличивает размер модели и делает ее плохо читаемой. Для понимания смысла нотации ARIS еЕРС достаточно рассмотреть основные используемые типы объектов и связей. На рисунке 3.1 представлена простейшая модель ARIS еЕРС, описывающая фрагмент некоторого бизнес-процесса.

Рис. 3.1. Фрагмент модели процесса в нотации ARIS еЕРС

На рисунке 3.1 видно, что связи между объектами имеют определенный смысл и отражают последовательность выполне­ния функций в рамках процесса. Стрелка, соединяющая собы­тие 1 и функцию 1, «активирует», или инициирует, выполнение функции 1. Функция 1 «создает» событие 2, за которым следу­ет символ логического «и», «запускающий» выполнение функ­ций 2 и 3. Нотация ARIS еЕРС построена на определенных се­мантических правилах описания:

1. каждая функция должна быть инициирована событием и должна завершаться событием;

2. в каждую функцию не может входить более одной стрел­ ки, «запускающей» выполнение функции, и выходить не более одной стрелки, описывающей завершение выполнения функции.

Кроме этих правил существуют и другие важные правила формирования моделей в методике ARIS. Эти правила можно изучить при помощи методического материала «Методы ARIS», который устанавливается на компьютер одновременно с демо-версией продукта.

На рисунке 3.2 показано применение различных объектов ARIS при создании модели бизнес-процесса.

Каждый объект в системе ARIS Toolset, которая поддерживает метод описания бизнес-процессов ARIS, имеет определенный набор атрибутов. При этом предлагается воспользоваться стан­дартными атрибутами для описания объектов, или ограничен­ным количеством так называемых пользовательских атрибутов.

Из рисунка 3.1 видно, что бизнес-процесс в нотации еЕРС представляет собой последовательность функций, расположенных

172

в порядке их выполнения. Реальная длительность выполнения процедур в еЕРС визуально отражена быть не может. Это при­водит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя будет возложено выполнение двух задач одновременно. Используемые при построении модели символы логики позволяют отразить ветвление и слияние биз­нес-процесса. Для получения информации о реальной длитель­ности процессов необходимо использовать другие инструмен­ты описания, например графики Гантта в системе MS Project.

Рис. 3.2. Фрагмент модели процесса в нотации ARIS еЕРС

Таким образом, при помощи нотации ARIS еЕРС можно описывать бизнес-процесс в виде потока последовательно вы­полняемых работ (процедур, функций). Примеры моделей, сформированных с использованием ARIS еЕРС, показаны на рисунках 3.3, 3.4.

3.1.3. Описание нотации IDEFO, IDEF3

Нотация IDEF0 была разработана на основе методологии структурного анализа и проектирования SADT, утверждена в качестве стандарта США и успешно эксплуатируется во многих проектах, связанных с описанием деятельности предприятий. Нотация IDEF3 была разработана с целью более удобного опи­сания потоков работ (work flow), для которых важно отразить логическую последовательность выполнения процедур во вре­мени. Нотации IDEF0 и IDEF3 используют следующие объек­ты (см. табл. 3.2).

173

Таблица 3.2 Объекты, используемые в нотациях IDEF0 и IDEF3

В моделях могут использоваться стрелки трех видов (см. табл. 3.3).

Таблица 3.3

176

Семантика построения моделей IDEF0 и IDEF3 предпола­гает соблюдение четких правил. Детальную информацию о по­строении моделей в IDEF0 и IDEF3 можно узнать в стандартах и книгах (см. [2],[3]).

Бизнес-процесс, сформированный при помощи нотации IDEF0, показан на рисунке 3.5 (этот же процесс представлен в нотации ARIS еЕРС на рис. 3.3).

Рис. 3.5. Модель бизнес-процесса в нотации IDEF0

Важно отметить, что модели бизнес-процессов в нотации IDEF0 являются статичными, т.е. они не отображают динами-

177

ку выполнения процесса. На схеме IDEF0 можно показать фун­кции, из которых состоит процесс, и взаимодействие между этими функциями. Поэтому нотацию IDEF0 целесообразно использовать при описании организации на верхнем уровне, когда не стоит задача детально описывать логику выполнения процессов.

Схема в IDEF0 позволяет наглядно структурировать процессы организации и графически отобразить взаимодействие между этими процессами.

Особенно важно, что в нотации IDEF0 при помощи специ­альных стрелок можно показывать управленческие воздействия, что дает возможность описывать систему управления процессами и организацией.

Примеры формирования моделей в нотации IDEF0 можно найти в [1] и на сайте www.finexpert.ru.

На рисунке 3.6 показан бизнес-процесс, описанный при помощи нотации IDEF3 (этот же процесс представлен в нота­ции ARIS еЕРС на рис. 3.4.).

Рис. 3.6. Модель бизнес-процесса в нотации IDEF3

В нотации IDEF3 так же, как и в нотации ARIS еЕРС, ис­пользуются символы логики, отражающие ветвление процесса.

178

ЗЛА. Сравнительный анализ нотаций ARIS и IDEF

Для лучшего понимания нотаций ниже приводится их срав­нительный анализ.

Таблица 3.4

№	Критерии	ARIS еЕРС	IDEF0	IDEF3
	сравнения
1	Принцип по-	Временная последова-	Принцип	Временная последова-
	строения диа-	тельность выполнения	доминиров	тельность выполнения
	граммы / логи-	процедур	ания (см.	процедур
	ка процесса		стандарт
			IDEF0)
2	Описание	Объект на диаграмме	Объект на	Объект на диаграмме
	процедуры		диаграмме
	процесса
3	Входящий	Используется отдельный	Стрелка	Нет (может быть отра-
	документ	объект для описания	слева,	жен в модели только
		(«документ»)	стрелка	привязкой объекта-
			сверху	комментария)
4	Входящая	Используется отдельный	Стрелка	Нет (может быть отра-
	информация	объект для описания	слева,	жен в модели только
		(«кластер», «техниче-	стрелка	привязкой объекта-
		ский термин»)	сверху	комментария)
5	Исходящий	Используется отдельный	Стрелка	Нет (может быть отра-
	документ	объект для описания	справа	жен в модели только
		(«документ»)		привязкой объекта-
				комментария)
6	Исходящая	Используется отдельный	Стрелка	Нет (может быть отра-
	информация	объект для описания	справа	жен в модели только
		(«кластер», «техниче-		привязкой объекта-
		ский термин»)		комментария)
7	Исполнитель	Используется отдельный	Стрелка	Нет (может быть отра-
	процедуры	объект для описания	снизу	жен в модели только
		(«позиция»,«организа-		привязкой объекта-
		ционная единица»)		комментария)
8	Используемое	Используется отдельный	Стрелка	Нет (может быть отра-
	оборудование	объект для описания	снизу	жен в модели только
				привязкой объекта-
				комментария)
9	Управление	Нет. Может быть отра-	Стрелка	Только временная по-
	процедурой	жено только символами	сверху	следовательность вы-
		логики и событий (по-		полнения процедур и
		следовательность вы-		логика процесса
		полнения процедур)
		и/или указанием входя-
		щих документов
10	Контроль вы-	Нет. Может быть отра-	Стрелка	Нет
	полнения про-	жен указанием входящих	сверху
	цедуры	документов
11	Обратная	Нет. Может быть отра-	Стрелка	Нет
	связь по	жена только символами	сверху
	управле-	логики (последователь-
	нию/контролю	ность выполнения про-
		цедур)

179

Один из важнейших аспектов описания моделей бизнес-процессов — отражение на модели управляющих воздействий, обратных связей по контролю и управлению процессом. В но­тации ARIS еЕРС управление может быть отражено только при помощи указания входящих документов, которые регламенти­руют выполнение процедуры, и последовательности выполнения процедур во времени (запускающие события). В отличие от ARIS еЕРС, в нотации IDEF0 каждая процедура должна иметь хотя бы одно управляющее воздействие (вход управления — стрелка сверху). Если при создании модели в ARIS еЕРС ука­зывать только последовательность выполнения процедур, не заботясь об отражении управляющих воздействий (например, документов и управленческой информации), полученные мо­дели будут иметь низкую ценность с точки зрения анализа и дальнейшего использования руководителями. К сожалению, именно эта ошибка наиболее распространена на практике. Создается модель work flow (поток работы), отражающая про­стую последовательность выполнения функций и входящих/ис­ходящих документов, при этом управляющие (контрольные) воздействия на функции в модели не отражаются. Реальные про­цессы управления могут остаться «за кадром» на 30—90% (см. пример на рис. 3.7).

Рис. 3.7. Недостатки описания бизнес-процесса в ARIS еЕРС

На рисунке 3.7 функция 4 является контрольной и служит для проверки результатов выполнения функций 2 и 3. Но дан­ная модель не отвечает на вопросы:

1) каким образом осуществляется управляющее воздействие на функции 2 и 3, показан только тот факт, что по ходу про­цесса возможен возврат и повторное выполнение функций 2 и 3; информация об этой обратной связи может быть раскрыта только в виде описания в атрибутах объектов модели;

180

2) какие документы (например, нормативы), распоряжения, внешние условия регламентируют выполнение функций.

Если пытаться отразить все условия и ограничения, опреде­ляющие выполнение функций, то потребуется описать большое количество событий и входящей информации (например, уст­ных распоряжений руководителей). Модель станет сложной и плохо читаемой. Эти недостатки присущи и нотации IDEF3. Указанных недостатков нет у нотации IDEF0. В то же время, на моделях в IDEF0 не предусмотрено использование символов логики выполнения процесса, поэтому нотация IDEF0 не мо­жет быть использована для описании динамики выполнения процесса.

Таким образом, нотация ARIS еЕРС является расширени­ем достаточно простой нотации IDEF3. Для адекватного опи­сания процесса управления в нотации ARIS еЕРС необходи­мо заранее договориться, как будут отражены в модели доку­менты (информация), регламентирующие выполнение функций процесса.

3.1.5. Функциональные возможности программных продуктов ARIS и BPWin

Функциональные возможности программных продуктов (инструментальных средств) моделирования ARIS Toolset и BPWin можно корректно сравнивать только по отношению к определенному кругу задач. Мы рассматриваем только зада­чу формирования моделей (описания) бизнес-процессов орга­низации. Каждая из рассматриваемых систем имеет свои пре­имуществ и недостатки. В зависимости от решаемых задач эти преимущества могут как усиливаться, так и наоборот. То же касается и недостатков: недостаток системы в рамках одного проекта может не быть недостатком в рамках другого. Напри­мер, отсутствие четких соглашений по моделированию управ­ляющих воздействий в рамках ARIS еЕРС может привести к созданию моделей, не отвечающих на поставленные вопро­сы, в то время как нотация IDEF0 (и система BPWin соответ­ственно) позволяет решить эту задачу. С другой стороны, описание работы, выполняемой одним сотрудником, может быть описано более адекватно при помощи ARIS еЕРС, чем IDEF0 или IDEF3 BPWin.

Сравнение функциональных возможностей систем приводит­ся в таблице 3.6.

181

Таблица 3.6

№	Возможности/	ARIS Toolset 5.0	BPWin 4.0
	Инструментальная сре-
	да
1	Поддерживаемый стан-	- (частично — DFD,	IDEF0, IDEF3, DFD
	дарт	ERM, UML)
2	Система хранения дан-	Объектная база дан-	Модели хранятся в
	ных модели	ных	файлах
3	Ограничение на размер	Нет. Размер базы	Нет. Размер базы
	базы данных	данных ограничива-	данных ограничива-
		ется вычислительны-	ется вычислитель-
		ми ресурсами	ными ресурсами
4	Возможность групповой	Есть. Используется	Есть. Используется
	работы	ARIS Server	Model Mart.
5	Ограничение на количе-	Нет	От 2 до 8
	ство объектов на диа-
	грамме.
6	Возможность декомпози-	Неограниченная де-	Неограниченная де-
	ции	композиция. Возмож-	композиция. Возмо-
		на декомпозиция на	жен однократный
		различные типы мо-	переход на другую
		делей	нотацию в процессе
			декомпозиции
7	Формат представления	Не регламентируется	Стандартный бланк
	моделей		IDEF с возможно-
			стью его отключения
8	Удобство работы по соз-	Сложная панель	Простая панель
	данию моделей	управления, есть	управления, нет
		выравнивание объек-	выравнивания объ-
		тов, есть undo	ектов, нет undo
9	U DP — свойства объек-	Большое, но ограни-	Количество UDP не
	тов, определяемые поль-	ченное количество	ограничено. Количе-
	зователем	свойств, количество	ство типов ограни-
		типов ограничено	чено
10	Возможность анализа	Есть. Возможность	Упрощенный анализ
	стоимости процессов	использовать ARIS	стоимости по часто-
		ABC	те использования в
			процессе. Возмож-
			ность экспорта в
			Easy ABC
11	Генерация отчетов	Создание отчетов на	RPT Win, возмож-
		основе стандартных и	ность визуальной
		настраиваемых поль-	настройки отчетов,
		зователем макросов	включая расчет по
		Visual Basic	формулам с исполь-
			зованием UDP
12	Сложность разработки	Сложно	Просто
	нестандартных отчетов

Сравнивая две системы, следует отметить, что для хранения моделей в ARIS используется база данных. Для удобства пользо-

182

вателя модели (объекты моделей) могут быть сгруппированы по различным принципам в зависимости от специфики проекта. В программном продукте ARIS Toolset предусмотрены различные функции по администрированию базы данных: управление до­ступом, консолидация и т.п. В BPWin данные модели хранятся в файле, что существенно упрощает работу по созданию моде­ли, но, с другой стороны, ограничивает возможности по анализу объектов модели. В Model Mart также предусмотрено админи­стрирование базы данных.

Часто одним из недостатков BPWin сторонники ARIS на­зывают ограничение по количеству объектов на диаграмме¹. Однако опыт реальных проектов показывает, что для проекта, результаты которого можно реально использовать, одним из критериев использования является обозримость модели. Коли­чество объектов в базе данных ARIS или модели BPWin состав­ляет 150—300. Это означает, что при восьми объектах на од­ной диаграмме, общее число диаграмм (листов) в модели со­ставит 20—40. Следует подчеркнуть, что модель создается: а) для документирования процесса; б) для выделения и анализа про­блем. Чрезмерно детальное описание всех процессов органи­зации не требуется. Как ни странно, среди директоров компаний иногда встречается вера в то, что детальное описание процес­сов само по себе представляет ценность и может решить мно­гие проблемы. Это далеко не так. Именно понимание того, что нужно описывать и какие аспекты функционирования реаль­ной системы управления при этом необходимо отображать в модели, определяет успех проекта по моделированию бизнес-процессов.

ARIS предоставляет существенно больше возможностей по работе с отдельными объектами модели, но именно вследствие чрезмерного количества настроек работа по созданию модели должна регламентироваться сложной, многоаспектной докумен­тацией — так называемыми Соглашениями по моделированию. Разработка этих Соглашений сама по себе является сложной, дорогой и требующей значительного времени (1—3 месяца) и квалифицированных специалистов задачей. Если проект с ис­пользованием ARIS начинается без детальной проработки таких

¹ Строго говоря, ограничение на количество объектов на диаграмме является требованием стандарта IDEF0; при создании моделей IDEF0 с помощью BPWin технически возможно указывать практически нео­граниченное количество объектов на одной диаграмме.

183

соглашений, то вероятность создания моделей бизнес-процес­сов, не отвечающих на поставленные вопросы, составляет 80— 90%. В свою очередь, BPWin отличается простотой в использо­вании и достаточной строгой регламентацией при создании диаграмм: стандарт IDEF и рекомендации по его применению, бланк IDEF для создания диаграммы, ограниченное количество обязательно заполняемых полей, ограничение количества объек­тов на одной диаграмме и т.д. ARIS, безусловно, является бо­лее «тяжелым» инструментом, по сравнению с BPWin, но это в итоге оборачивается значительными трудностями и высокими затратами на его эксплуатацию.

3.1.6. Рекомендации по применению методик и программных продуктов в зависимости от типовых задач

Различные ситуации применения инструментальных средств моделирования бизнес-процессов и их экспертная оценка по­казаны по 5-балльной шкале (табл. 3.7)'.

Таблица 3.7

Задача/Инструментальная среда	ARIS	BPWin 4.0
	Toolset 6.0
Разовый проект по описанию бизнес-
процессов, например:
1) описание одного бизнес-процесса с	4	5
точки зрения контроля и управления;
2) описание функциональных возможно-	3	5
стей новой системы управления на верх-
нем уровне
Длительный (непрерывный) проект по	5	3
описанию деятельности компании с раз-
личных точек зрения (организационная
структура, структура документов, боль-
шой объем базы данных процессов и т.д.)
Разработка системы автоматизации:
1) описание функциональных возможно-	4	3
стей системы;
2) создание логической модели данных;	3	5
3) создание физической модели данных	-	BPWin + ERWin +
		Paradigm Plus

Позиционирование систем можно провести по отношению к решению задачи моделирования бизнес-процессов (см. рис. 3.8).

¹ Приводимые оценки программных продуктов являются экспертными. 184

Рис. 3.8. Качественное сравнение программных продуктов ARIS

Toolset и BPWin

Таким образом, для ведения небольших по масштабам (ма­лые и средние предприятия, 2—5 человека в группе консультан­тов) и длительности (2—3 месяца) проектов рациональнее ис­пользовать BPWin. Для крупных и/или длительных проектов в больших организациях больше подходит ARIS Toolset. В этом случае подготовительные работы по созданию регламентирую­щей документации могут занять 1—3 месяца, но это является необходимым элементом последующей успешной работы. В зак­лючении отметим, что стоимость использования ARIS Toolset как основного средства описания процессов организации явля­ется весьма значительной.

При принятии решения о выборе любого программного про­дукта для описания бизнес-процессов, руководителям компаний следует оценивать не только цену поставки продукта, но и зат­раты на: 1) установку; 2) обучение персонала; 3) поддержание продукта в работоспособном состоянии; 4) наполнение полез­ной информации; 5) поддержание моделей в актуальном состо­янии; 6) разработку отчетов, позволяющих использовать инфор­мацию, заложенную в систему. С учетом этих факторов многие компании принимают решение не использовать сложные и до­рогостоящие программные продукты, а документировать биз­нес-процессы доступными средствами (например, при помощи программных продуктов MS Word или Visio).

185

3.2. «ПЛОСКИЕ» И «ОБЪЕМНЫЕ» МОДЕЛИ ПРОЦЕССОВ