загрузка...

Сравнительный анализ нотаций. Выбор нотации для описания процессов

  Нотации IDEF0 и ARIS VAD
Ниже в табл. 2.5 приводится сравнительный анализ нотаций моделирования бизнес-процессов ARIS VAD и IDEF0. Обе эти нотации предназначены для описания процессов организации на верхнем уровне.
Табл. 2.5. Сравнение нотаций iDEFO и ARiSVAD


Критерий сравнения

НОТАЦИЯ



ARIS Value-added Process Chain

ВЕТО

1

Принцип построения диаграммы

Временная последовательность выполнения процедур. Используется тип связи is predecessor of

Принцип доминирования (см. стандарт IDEF0). Функции связаны потоками данных и материальных ресурсов

2

Описание процедуры процесса

Объект на диаграмме

Объект на диаграмме

3

Использование сторон объекта «процесса» для отображения различных видов входов

Не регламентировано. Стороны объекта Value-added Process Chain не имеют специального назначения

Регламентировано. Каждая сторона объекта Activity (функция, процесс) имеет специальный смысл: входы, выходы, управление, механизмы

4

Входящий документ

Не используется специальный объект для отображения документов. Может использоваться объект Technical Term

Стрелка входа, стрелка управления

5

Входящая информация

Используется отдельный объект Cluster. Может быть использован объектТесЬШса! Term

Стрелка входа, стрелка управления

6

Исходящий документ

Не используется специальный объектдля отображения документов. Может использоваться объект Technical Term

Стрелка выхода

7

Исходящая информация

Используется отдельный объект Cluster. Может быть применен o6beKTTechnical Term

Стрелка выхода

8

Исполнитель процесса

Используются отдельные объекты для описания: Position, Organizational Unit

Стрелка механизма

9

Используемое оборудование

Используется отдельный объект для описания Product, Product/Service. Может быть использован объектТес!1пюа1 Term

Стрелка механизма



Критерий сравнения

Котар ’


/>ARIS Value-added Process Chain
©ЕГО

10

Управление процессом

Нет средств для отображения управления процессом. Воз можно косвенное отображение управления при помощи входящих документов, информации

Стрелка управления (стрелка сверху)

11

Обратная связь по управлению/контролю

Не может быть отображена. Есть возможность однократно показать обратную связь типа is predecessors of

Стрелка управления.
(Есть требования по отображению обратных связей по управлению.)

12

Обратная связь по входу

Не может быть отображена. Есть возможность однократно показать обратную связь типа
is predecessors of

Стрелка входа. (Есть требования по отображению обратных связей по информации.)

13

Миграция потоков данных и ре сурсов при декомпозиции

Принципиально невозможна

Предусмотрена. Миграция стрелок вниз и вверх

14

Туннелирование потоков данных и ресурсов при декомпозиции

Принципиально невозможна

Предусмотрено. Туннелирование стрелок вверх и вниз

15

Автоматическая нумерация узлов(процессов)

Не предусмотрена

Предусмотрена

16

Стандартная форма - представление диаграммы процесса при документировании

Не регламентирована. Нет рекомендаций по форматированию моделей VAD при документиро вании

Регламентирована. Рамка IDEF0. Развитая система обозначений на диаграмме

17

Ограничения по количеству объектов на диаграмме процесса

Количество объектов не ограничено

Рекомендовано не более шести. Общее количество не ограничено


Сравнительный анализ нотаций показывает, что нотацию ARIS VAD можно рассматривать как инструмент простейшего схематического изображения бизнес-процессов. Это средство для эскизного описания процессов верхнего уровня, не предназначенное для построения связных комплексных моделей деятельности организации. Более того, принцип построения моделей в ARIS VAD — последовательность процедур во времени — больше подходит для создания моделей класса Work Flow (например, IDEF3). Метод ARIS VAD лишен таких практически необходимых инструментов, как отображение входов управления процессом, возможность описания обратных связей, миграция связей (входов/выходов процесса) при декомпозиции.

В методических материалах [6] по использованию нотации VAD можно найти рекомендации следующего характера. На первом этапе работы формируются модели верхнего уровня в VAD. Затем они декомпозируются в нотации ARIS еЕРС. Но допускается и создание нескольких уровней декомпозиции в нотации VAD, что исключительно неудобно, так как декомпозируемые модели никак не связаны с моделями верхнего уровня (кроме формальной принадлежности). При дальнейшей декомпозиции процессов в нотации еЕРС приходится вручную заботиться о связности создаваемых моделей, так как на верхнем уровне составляющие процессов в VAD были слабо увязаны между собой через потоки информации и ресурсов, носили иллюстративный характер, как показано на рис. 2.50.
Рис. 2.50. Декомпозиция моделей процессов в ARIS



Справедливости ради следует отметить, что при декомпозиции процессов из нотации IDEF0 в IDEF3 мы сталкиваемся с теми же
проблемами. Но здесь мы делаем акцент на том, что описание процессов в VAD на верхнем уровне существенно менее удобно, чем в IDEF0. Кроме того, работа в ARIS VAD значительно более трудоемка. Так, количество операций по отображению процесса в VAD в два и более раз больше, чем при создании аналогичной модели в IDEF0. На рис. 2.51 и 2.52 дается пояснение данной оценки трудоемкости.
Рис. 2.51. Процесс в IDEF0



Рис. 2.52. Процесс рис. 2.51 в ARIS VAD






Видно, что для отображения простейшего процесса из двух функций в IDEF0, включающего один поток материальных ресурсов и две обратные связи, потребовалось отображение пяти объектов (двух функций и трех стрелок). В нотации ARIS VAD для отображения рассматриваемого процесса потребовалось 12 объектов (два Value- added Process chain, два Cluster, один Technical Term, семь стрелок). Таким образом, трудоемкость описания процесса в нотации VAD существенно выше, а это отражается на времени выполнения проекта и необходимых ресурсах.
Если поставлена задача описания деятельности организации на верхнем уровне, можно решить ее двумя способами, как показано в табл. 2.6.
Табл. 2.6. Способы описания бизнес-процессов верхнего уровня

Способ блок-схем

Комплексный подход

Данный подход предполагает быстрое, эскизное описание схем процессов верхнего уровня. Не требуется создавать комплексную модель. При такой постановке задачи можно использовать простейшие средства визуализации блок-схем процессов, например MS Word или Visio.
Использование IDEF0 не рекомендуется, так как получаемые схемы процессов слишком сложные. Использование ARIS VAD возможно, но не дает существенных преимуществ

Использование методологии IDEF0 — оптимальный вариант для описания бизнеса на верхнем уровне, так как позволяет отобразить информационные и материальные потоки, требования к персоналу и инфраструктуре, управляющие воздействия и обратные связи. Методология соответствует определению процесса в ИСО 9000:2005. Использование ARIS VAD не обеспечивает получения комплексных связных моделей верхнего уровня, поэтому не рекомендуется для создания моделей такого типа


Подчеркнем, что выбор нотации для описания процессов верхнего уровня в первую очередь определяется задачами проекта. Нотации IDEF3 и ARIS еЕРС
В табл. 2.7 приводится сравнение нотаций IDEF3 ARIS и еЕРС. Нотация ARIS еЕРС — более новая с точки зрения времени ее появления, но фактически это расширение IDEF3 за счет использования объекта «Событие» (Event).
Нотации ARIS еЕРС и IDEF3 принципиально не отличаются друг от друга, так как базируются на одних и тех же принципах моделирования потоков работ (Work Flow), предполагающих использование символов логики (перекрестков в IDEF3).

Табл. 2.7. Сравнение нотаций IDEF3 и ARIS еЕРС


Критерий сравнения

Нотация

ARiSeE С

IDEF3                             *

1

Принцип построения диаграммы

Временная последовательность выполнения процедур

Временная последовательность выполнения процедур

2

Описание процедуры процесса

Объект на диаграмме

Объект на диаграмме

3

Входящий документ

Используется отдельный объект для описания типа Document. Могут использоваться и другие объекты

Используется отдельный объект для описания(объект ссылки типа Object или стрелка Object Bow)

4

Входящая информация

Используется отдельный объект для описания типа Cluster, Technical Term

Используется отдельный объектдля описания (объект ссылки типа Object или стрелка Object Bow)

5

Исходящий документ

Используется отдельный объект для описания типа Document. Могут использоваться и другие объекты

Используется отдельный объект для описания (объект ссылки типа Object или стрелка Object Bow)

6

Исходящая информация

Используется отдельный объект для описания типа Ouster, Technical Term

Используется отдельный объект для описания (объект ссылки типа Object или стрелка Object Flow)

7

Исполнитель процедуры

Используется отдельный объект для описания типа Position, Organizational Unit и т. д.

Нет. (Может быть отражен в модели только привязкой объекта ссылки.)

8

Используемое оборудование

Используется отдельный объект для описания

Нет. (Может быть отражен в модели только привязкой объекта ссылки.)

9

Связь диаграмм при де композиции

Для привязки к другим диаграммам используется объект Process Interface

Для привязки к другим диаграммам используется объект ссылки

10

Визуальное восприятие диаграмм процессов

Интуитивно понятные, легко читаемые диаграммы

Сложно воспринимаются

11

Стандартная форма представления диаграммы процесса при документировании

Не регламентирована.
Нет рекомендаций по форматированию моделей еЕРС при документировании

Регламентирована. Рамка IDEF0. Развитая система обозначений на диаграмме

12

Ограничения по количеству объектов на диаграмме процесса

Количество объектов не ограничено

Рекомендовано не более шести. Общее количество не ограничено


При помощи этих символов отображаются ветвления и слияния потоков работ в рамках бизнес-процесса. Возможность отображения событий в ARIS еЕРС позволяет создавать более корректные и подробные описания процессов. При этом, однако, существенно

повышается сложность и трудоемкость описания. Дополнительные преимущества ARIS еЕРС заключаются в возможности визуального отображения входящих/исходящих документов, информации, используемой инфраструктуры и т. п. при помощи специальных объектов. К сожалению, на практике наличие таких широких возможностей по описанию процесса в ARIS еЕРС часто приводит к отрицательным результатам: модели становятся слишком сложными и громоздкими, неудобными для документирования. Данную проблему нельзя отнести к недостаткам программного продукта ARIS: аналогичные результаты получались и при использовании других инструментов, например Casewise. Причину этого следует искать в недостаточно проработанной методике (Соглашении по моделированию), которая бы ограничивала применение всех возможностей инструментария практическими потребностями и назначением конкретной модели. То есть перед началом проекта необходимо тщательно оговорить, какими объектами в модели должны быть отражены совокупности реальных действий, событий и связей.
С формальной точки зрения нотация ARIS еЕРС наиболее удобна для детального описания процессов. С ее помощью можно эффективно описывать процессы уровня рабочих мест с целью разработки должностных и рабочих инструкций.
Особенно следует подчеркнуть, что обе нотации не предназначены для описания процессов верхнего уровня.
Распространенная ошибка моделирования в ARIS еЕРС и IDEF3 — создание плоских моделей потоков работ, проходящих только через рабочие места исполнителей нижнего звена. При этом не рассматриваются руководители, без которых деятельность компании невозможна. Подчеркнем, что этот факт не указывает на недостаток конкретной нотации, а свидетельствует о некорректности существующих методических подходов к описанию процессов организации с использованием данных нотаций. К сожалению, в российской практике эта ошибка широко распространена.
В нотации ARIS еЕРС и IDEF3 не заложены средства описания управляющих воздействий, обратных связей по управлению и информации. Поэтому при формировании моделей процессов можно

использовать несколько способов отображения управляющих воздействий. Более корректным было бы описывать процессы управления отдельно.
Предположим, что мы хотим использовать схему бизнес-процесса для регламентации (например, в документе «Регламент выполнения бизнес-процесса»). Эта схема должна удовлетворять следующим требованиям: все отображенные на схеме операции бизнес-процесса существуют реально и закрепляются за конкретными исполнителями; на схеме отображаются реальные документы, файлы, ресурсы; схема процесса проста и понятна для визуального восприятия; схема процесса имеет компактный размер.
Эти требования означают, что строить модель бизнес-процесса имеет смысл при описании операций уровня рабочего места исполнителя, в крайнем случае — для операций небольшого (три-четыре человека) подразделения. На более крупном уровне модели потоков работ могут дать общую информацию о процессе, но использовать их для регламентации затруднительно вследствие размывания ответственности между исполнителями процесса.
Если мы описываем бизнес-процесс на детальном уровне, то на выходе этой работы получаем схемы, содержащие поток операций и их исполнителей. Именно при формировании таких моделей и возникает важнейшая, на наш взгляд, проблема: из рассмотрения полностью исключаются руководители. Возникает следующая ситуация. Группа аналитиков (или внутренних экспертов) приходит в подразделение, получает разрешение руководителя, начинает работать с исполнителями бизнес-процесса, переходя от одного рабочего места к другому в соответствии с ходом движения процесса. Формируется его модель, включающая операции всех рядовых исполнителей, но лишенная даже намека на руководителей, владельцев бизнес-про- цесса. Кроме того, такие модели чаще всего описывают нормальный ход бизнес-процесса. Возможные отклонения очень часто остаются вне рассмотрения. Также часто опускают такие важные моменты, как действия при получении не соответствующих требованиям входов

(например, документ из соседнего подразделения пришел без согласования и утверждения) и выходов (брак, недоработка, отрицательное решение по проблеме), регистрация параметров процесса (измерения), контроль. Нужен ли такой результат работы руководителю? Ответ очевиден. Полученные схемы бизнес-процесса плоские, неполные, не могут эффективно использоваться для внедрения системы процессного управления. Тем не менее многие компании, особенно крупные, выполняют отдельные проекты по созданию внутренних стандартов моделирования плоских бизнес-процессов, создания баз знаний компании по бизнес-процессам и т. п. В итоге полученные «горы» четко структурированной, но однобокой, неполной информации оказываются бесполезными для целей реального управления.
alt="" /> На рис. 2.53 показан объемный бизнес-процесс. Он состоит из нескольких моделей потоков работ, сформированных для каждого уровня: исполнителей, заместителя руководителя, руководителя (владельца) бизнес-процесса.

информации по ходу процесса от исполнителей вверх и управленческих решений от руководителей вниз. Даже если в крайнем случае мы полностью делегируем все права на принятие управленческих решений по процессу исполнителям, у руководителя останется ключевая функция — анализ эффективности бизнес-процесса и его улучшение с ориентиром на стратегические цели компании (если таковые имеются). Улучшение процесса руководитель осуществляет за счет управления ресурсами: персоналом, финансами, материалами, оборудованием, программным обеспечением, информацией.
Каким же образом увязать деятельность руководителей и исполнителей при построении моделей потоков работ (ARIS еЕРС, IDEF3)? Очевидно, что сделать это можно несколькими способами. Первый и самый простой состоит в следующем: отдельно описываются потоки работ, выполняемых как руководителями, так и исполнителями. Такой простейший подход имеет несколько недостатков, основной из которых состоит в том, что взаимодействие руководителя и исполнителя становится в модели не явным, а опосредованным при помощи обратных связей по информации. Другой способ состоит в том, что при описании работ исполнителей можно указать прямые ссылки на процессы, выполняемые руководителями, или отобразить их вмешательство в работу (см. рис. 2.54).
На рис. 2.54 вверху показана простейшая цепочка бизнес-процесса, состоящая из двух операций. Представим себе, что они выполняются исполнителем и требуют управления со стороны руководителя. Как мы можем отобразить этот факт на модели? Согласно первому предложенному выше способу, мы указываем на модели процесса обратную связь по информации. В данном примере нотация ARIS еЕРС позволяет показать входящий и исходящий документ А, содержащий некоторые сведения. Документ А попадает от исполнителя руководителю после выполнения функции 2 и затем может быть возвращен на доработку при выполнении функции 1. При этом «где-то в другом месте» мы должны описать работу руководителя по проверке этого документа и принятию решения. Это означает, что мы должны создать модель, описывающую деятельность руководителя.

Рис. 2.54. Различные варианты отображения участия руководителя в процессе
Необходимо отобразить две обратных связи: по информации и по управлению.

alt="" />


Шаг 2. Вариант 1. Обратная связь по управлению отображается в виде логики процесса
-для описания обратной связи по управлению/ приходится вводить в процесс саму функцию управления и обратную связь Г Л Событие «X»

alt="" />


На рис. 2.54 приводится еще два способа встраивания руководителя в бизнес-процесс. Первый из них предполагает прямое включение в процесс «Функции управления», второй изображен в виде дополнительного события «Принято управленческое решение».
Какой способ для отображения участия руководителя в бизнес- процессе выбрать? Это определяет сама организация. Можно со ста вить схему бизнес-процесса уровня исполнителей, а деятельность руководителя расписать в виде подробной таблицы с указанием операций, входящих и исходящих документов, принимаемых решений. Можно сформировать схемы процесса для работы самого руководителя или попытаться отобразить его участие на одной плоской схеме, увеличивая количество возможных ветвлений и слияний процесса. Мы считаем, что нужно выбирать тот способ, который наилучшим образом подходит для последующей регламентации и управления бизнес-процессом. Моделируя, главное — не забывать про руководителя, поскольку именно он отвечает за управление и улучшение процесса и в конечном счете модели бизнес-процессов создаются именно для него.
Подводя итог раздела, следует сказать, что формально нотация ARIS еЕРС проработана удобнее и лучше, чем IDEF3.
В заключение главы хотим обратить внимание читателя на тот факт, что успешная и эффективная деятельность по описанию процессов организации не определяется только выбором методологии моделирования (нот ации). Необходимо учитывать следующие факторы: четко сформулированные цели проекта; методологию (нотацию) моделирования; инструмент (среду) моделирования; методику использования нотации и инструмента для описания и регламентации бизнес-процессов; наличие специалистов, компетентных в области бизнес-моделирования.
Дело в том, что нотация редко используется отдельно от специализированного инструмента — среды моделирования бизнес-
процессов. С одной стороны, она накладывает определенные ограничения при описании процессов. С другой — дает, как правило, новые возможности, которые позволяют более полно описывать процессы и выгружать их из среды моделирования в виде готовых к утверждению регламентирующих документов или HTML-публикаций на интранет-портале организации.
Но и выбор адекватной задачам нотации и среды моделирования еще не гарантирует успеха проекта. Необходимо четко понимать: Как и в какой последовательности будут описываться процессы компании? Кто это будет делать? Как будет организована координация между участниками проекта, моделирующими разные процессы?
Ответить на этот вопрос могут только достаточно квалифицированные, опытные бизнес-аналитики, которые способны разработать методику использования нотации и инструмента в проекте внедрения процессного подхода. 
<< | >>
Источник: Репин В. В., Елиферов В. Г.. Процессный подход к управлению. Моделирование бизнес-процессов. 2013

Еще по теме Сравнительный анализ нотаций. Выбор нотации для описания процессов:

  1. Моделирование процессов в нотации DFD
  2. ГЛАВА 1               Структурный анализ на основе DFD-нотации
  3. Документирование бизнес-процессов в нотации BPMN
  4. Нотация BPMN
  5. Нотация «Процедура» среды моделирования Business Studio
  6. Глава 2 Выбор методологии описания бизнес-процессов
  7. Выбор методологии описания бизнес-процессов организации
  8. § 1. Особое производство в гражданском и арбитражном процессе: сравнительный анализ
  9. Глава 3 Описание и анализ бизнес-процессов
  10. Выбор и описание принципов и критериев сегментации
  11. Применение метода анализа иерархий для ранжирования бизнес-процессов
  12. Основные методологии описания процессов
  13. Описание процессов при помощи блок-схем
  14. Методологии описания бизнес-процессов
  15. Глава 4 СРАВНИТЕЛЬНЫЙ АНАЛИЗ МИРОВЫХ ЦИВИЛИЗАЦИЙ
  16. ГЛАВА 34. СРАВНИТЕЛЬНЫЙ АНАЛИЗ ВАРИАНТОВ ФИНАНСИРОВАНИЯ
- Cвязи с общественностью - PR - Бренд-маркетинг - Деловая коммуникация - Деловое общение и этикет - Делопроизводство - Интернет - маркетинг - Информационные технологии - Консалтинг - Контроллинг - Корпоративное управление - Культура организации - Лидерство - Литература по маркетингу - Логистика - Маркетинг в бизнесе - Маркетинг в отраслях - Маркетинг на предприятии - Маркетинговые коммуникации - Международный маркетинг - Менеджмент - Менеджмент организации - Менеджмент руководителей - Моделирование бизнес-процессов - Мотивация - Организационное поведение - Основы маркетинга - Реклама - Сбалансированная система показателей - Сетевой маркетинг - Стратегический менеджмент - Тайм-менеджмент - Телекоммуникации - Теория организации - Товароведение и экспертиза товаров - Управление бизнес-процессами - Управление знаниями - Управление инновационными проектами - Управление качеством товара - Управление персоналом - Управление продажами - Управление проектами - Управленческие решения -