3.6.2. Методика формирования схем процессов с использованием выбранной нотации

В данном разделе мы рассмотрим вопросы формирования графических схем моделей бизнес-процессов. Следует отметить, что специфика применяемой инструментальной среды моделирования накладывает свои требования на вы­полнение этой работы. Приемы описания процессов в нотациях, например IDEFO, IDEF3, системы BPWin и с использованием других инструментов, от­личаются от приводимых в данном параграфе только технически. Основные правила работы по формированию моделей детальных процессов действуют независимо от нотации

Рассмотрим методику создания моделей детальных процессов на примере работы с системой ARIS Toolset. При использовании указанной системы целе­сообразно выполнить следующие работы:

1. Создать ряд вспомогательных моделей:

а) модель организационной структуры компании в нотации Organizational Diagram;

б) модель функций, выполняемых в подразделениях, в нотации Function Tree;

в) модели входящих и исходящих документов и материальных потоков в формате Technical Term Diagram;

г) другие вспомогательные модели (создаются в соответствии с требовани­ ями «Методики описания бизнес-процессов» (далее — Методики);

2. Декомпозировать функции модели процессов верхнего уровня, создавая модели в нотациях Value-added chain и еЕРС:

3. Выполнить анализ корректности построенных детачьных моделей процес­ сов, включая проверку полноты и увязки детальных моделей между собой;

2. Проверить адекватность детальных моделей процессов;

5. При необходимости, внести изменения в модели детальных процессов. На рис. 3.37 показан принцип использования вспомогательных моделей в ARIS.

Г л а в а 3 Описание и анализ бизнес-процессов 191

Возможны два подхода к созданию моделей процессов. В первом случае ана­литик берет данные непосредственно из анкет и других документов и сразу строит графическую схему процесса. Во втором случае аналитик сначала фор­мирует вспомогательные модели, а затем — модели процессов, используя дан­ные вспомогательных моделей. Во втором случае объем работ существенно воз­растает, но качество создаваемых моделей значительно повышается. При не­посредственном переносе информации из форм в графическую схему модели возможны ошибки, связанные с некорректным наименованием функций, ис­полнителей, документов и т.д. Есть и вторая проблема, состоящая в том, что при создании новых объектов (функций, исполнителей и т.п.) непосредственно в модели полученная информация является разрозненной, хаотичной. Другим аналитикам потребуется искать в базе процессов заранее определенные кем-то объекты. Часто вместо этого аналитики определяют новые объекты с отличаю­щимися от уже существующих объектов именами (см. рис. 3.38).

Через несколько недель работы база данных оказывается заполненной объек­тами с различными названиями, отображающими один реальный объект пред­метной области. Потребуется значительное время, чтобы очистить базу дан­ных от лишних объектов, используя один объект. Чтобы избежать указанных трудностей очень важно использовать заранее сформированные вспомогатель­ные модели.

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

192 В.В. Репин, В.Г. Елиферов. Процессный подход к управлению

Важнейшей проблемой создания детальных моделей процессов является про­блема управления параллельной работой нескольких групп аналитиков, описы­вающих различные функции одного процесса верхнего уровня. Такая ситуация возникает при декомпозиции сложных бизнес-процессов организации. Руково­дитель проекта должен оперативно контролировать содержание создаваемых моделей и проверять соответствие уровня декомпозиции в моделях аналитиков. На практике может возникать ситуация, показанная на рис. 3.39.

Рассмотрим пример, приведенный на рис. 3.39. Рабочая группа декомпози­рует процесс верхнего уровня, состоящий их трех функций. Аналитик 1 г-н Н.Е. Радивый создал модель нижнего уровня, состоящую из двух функций уровня подразделения (на рис. 3.39 не показаны). На его взгляд, информации, содер­жащейся в названиях функций его модели, вполне достаточно для понимания реального процесса. Аналитик 2 г-н О. Тщательный расписал функции процес­са очень подробно (детальное описание работ на каждом рабочем месте), вклю­чив в него 16 функций и, фактически, перешел на более низкий уровень деком­позиции, чем это требовалось в проекте. Наконец, Аналитик 3 г-н А. Декват-ный расписал процесс в соответствии с требованиями Методики и заданием руководителя проекта (уровень функций, выполняемых на рабочих местах). При попытке «склеить» из трех кусков процесса одну общую картину руководитель проекта испытывает большие трудности, так как уровни детальных моделей не совпадают. Чтобы этого не происходило, руководитель проекта должен опера­тивно контролировать работу аналитиков с точки зрения уровня описания и увязки моделей детальных процессов между собой.