Название: Моделирование бизнес-процессов - Репин В.В

Жанр: Экономика

Рейтинг:

Просмотров: 1586

3.6. методики детального описания бизнес-процессов

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

Для того чтобы успешно выполнить декомпозицию процессов, желательно использовать следующие методики:

методика сбора информации в подразделениях;

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

методика проверки корректности моделей процессов (проверка на соот­ветствие нотации);

•           методика проверки адекватности моделей процессов. Подробно указанные методики будут рассмотрены далее.

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

Цель методики - описание этапов выполнения работ по сбору информации в подразделениях и ее последующая обработка с целью использования при фор­мировании моделей бизнес-процессов.

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

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

положения о подразделениях;

должностные и рабочие инструкции;

документы методологического характера;

государственные и отраслевые стандарты, технические условия;

прочие документы.

Все эти документы могут быть использованы при подготовке к проведению интервью в подразделениях. Аналитики должны заранее ознакомиться с ними и подготовить перечень вопросов.

В табл. 3.13 представлен состав работ, которые выполняются при сборе ин­формации.

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

Если у сотрудников подразделений по три-пять раз запрашивают информа­цию, то это вызывает негативную реакцию и сопротивление. В чем дело? Когда аналитик проводит интервью, его интересует получение структурированной информации, т.е. информации, которая необходима в данный момент для мо­делирования процессов. Сотрудники, как правило, подробно рассказывают обо всех деталях процесса. Поэтому им кажется, что они изложили аналитику всю нужную информацию. Аналитик, в свою очередь, считает, что получил лишь часть интересующей его информации и будет настаивать на проведении следу­ющих интервью и т.д. После второго-третьего раза сотрудник не готов повто­рять то, что, на его взгляд, уже было неоднократно сказано. Приведенная ситу­ация проиллюстрирована на рис. 3.35.

Чтобы избежать подобной ситуации, аналитик должен обратить внимание на следующие особенности работы по организации сбора информации:

необходимо четко представлять цели сбора информации;

необходимо заранее формулировать ограниченный перечень вопросов (пять-шесть);

Рис 3 35. Взаимодействие аналитика и сотрудника подразделения

при проведении интервью необходимо добиваться кратких ответов и на­правлять их в нужном аналитику направлении;

предупредить сотрудника, что будет несколько интервью для получения информации в полном объеме.

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

Исходя из целей сбора информации, рабочая группа разрабатывает форму анкеты, которая будет использована при проведении интервью. Отметим, что данная анкета не предназначена для заполнения сотрудником подразделения. Форма анкеты представлена на с. 187.

При подготовке к проведению интервью руководитель проекта должен про­инструктировать аналитиков по методам сбора и обработки информации. Далее будут приведены некоторые правила проведения интервью.

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

Остановимся подробнее на трех различных методиках проведения интервью, представленных в табл. 3.14.

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

ях. Нужное количество анкет передают в подразделения. За отведенное время (два-три дня) сотрудники подразделений заполняют анкеты. Члены рабочей группы контролируют сроки заполнения и собирают анкеты. Затем рабочая группа при­ступает к их обработке. Как показывает практический опыт, булыиая часть анкет оказывается заполненной некорректно: на некоторые вопросы нет ответов, отсут­ствует описание многих функций, степень описания функций сильно отличается, нет данных о входящих и исходящих документах и т.д. Фактически, использовать полученные анкеты сложно. Большая часть содержащейся в анкетах информации в дальнейшем не используется в проекте. В чем причина низкого качества запол­нения анкет? В первую очередь, нежелание сотрудников аккуратно и в полной мере их заполнять. Заполнение анкет является для них дополнительной и неопла­чиваемой работой. Кроме того, сотрудники не понимают целей этой работы и не обучены методике работы с анкетами.

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

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

Форма анкеты для сбора информации в подразделении

«УТВЕРЖДАЮ»» Руководитель проекта

Форма № Ф-И01 Док. №. Аналитик     

200 г.

Наименование бизнес-процесса.

Подразделение     

Ф.И.О.сотрудника  

Дата  

.Время проведения интервью: с.

.Должность,

            по       

Перечень вопросов:

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

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

Какую из трех методик сбора информации выбрать? По нашему мнению, наиболее эффективна вторая методика. Основа этой методики - проведение квалифицированных интервью с сотрудниками подразделений с последующей обработкой информации. Следует отметить, однако, что данная методика предъяв­ляет значительные требования к квалификации и опыту аналитиков, которые проводят интервьюирование.

После того как выполнено интервьюирование сотрудников подразделений, целесообразно провести встречную проверку полученных данных. Она выпол­няется достаточно просто: необходимо сопоставить данные, полученные в од­ном подразделении (рабочем месте), с данными, полученными в другом подраз­делении (рабочем месте). Например, сотрудник А.К. Куратный предоставил информацию, что результатом его работы является Документ 1, который он передает в соседний отдел сотруднице Н.Е. Точной. Но эта сотрудница не на­звала в своем интервью какого-либо документа, получаемого от А.К. Куратного. Таким образом, можно уточнить полученную информацию еще на стадии ее обработки, т.е. до создания моделей бизнес-процессов.

В заключение остановимся на важнейших правилах проведения интервью с сотрудниками подразделений.

Общие правила проведения интервью:

малая длительность (от 1 до 2 ч);

не перед обеденным перерывом и не поздно вечером (перед концом рабочего дня);

четко представлять цель интервью;

объяснить свою роль сотруднику подразделения перед началом ин­тервью;

включать в интервью ограниченное количество вопросов;

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

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

Что нужно сказать сотруднику подразделения в начале интервью:

почему проводится это интервью;

от кого получено разрешение его проводить;

кто еще будет проинтервьюирован;

по какому принципу и кто выбирал интервьюируемых;

как будет использована полученная информация;

будет ли интервью анонимным;

будет ли интервью отражено в отчете;

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

как интервьюируемый может помочь процессу в целом;

почему важно получить детальную и точную информацию в процессе интервью.

Некоторые полезные советы по проведению интервью:

не отвлекаться на пространные комментарии по проблемам, связанным с обсуждаемым предметом;

не пытаться завязать дружеские отношения;

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

давать интервьюируемому время подумать;

отделять «мнения о...» от фактов;

не иронизировать;

концентрироваться на наиболее сложных аспектах предметной области;

не пытаться показывать свои знания, быть скромным (эксперт не вы, а интервьюируемый);

не увеличивать длительность проведения интервью.

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

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

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

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

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

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

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

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

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

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

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

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

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

Данные об отделах, должностях

Данные о функциях      Данные о ресурсах

Модель бизнес-процесса 1

Модель организационной структуры

Рис. 3.37. Использование вспомогательных моделей в ARIS.

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

Реальный объект (функция, исполнитель и т.п.)

Аналитик 1

Аналитик 2

Аналитик 3

Модель 1

Модель 2

Модель 3

Название объекта, вариант Б

Рис. 3.38. Некорректное определение объектов моделей.

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

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

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

Глубина описания

Рис. 3.39. Параллельная декомпозиция процессов.

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

Можно выделить несколько характерных типов несоответствий создаваемых детальных процессов между собой по следующим характеристикам:

уровню детальности описания;

входам/выходам и событиям при переходе с уровня на уровень;

входам/выходам и событиям на одном уровне;

выполняемым функциям и исполнителям на одном уровне. Рассмотрим эти типы несоответствий, начиная со второго (первый тип был

рассмотрен выше). На рис. 3.40 отображены возможные несоответствия, возни­кающие в процессе декомпозиции при переходе с уровня на уровень.

13-1870

Во-первых, на модели процесса верхнего уровня Функция 1 может завершать­ся двумя альтернативными событиями 4 и 5, но на декомпозирующей модели одно из завершающих событий (событие 10) не соответствует модели верхнего уровня. Во-вторых, нестыковка по входам и выходам. На процессе верхнего уров­ня входящим является Документ 1, а исходящим — Документ 2. На схеме процес­са нижнего уровня эти документы не указаны, зато есть входящий Документ 3 и исходящий Документ 4. Третий вид нестыковок, показанный на рис. 3.40, связан с использованием символов логики: исключающего (на схеме процесса верхнего уровня) и не исключающего (на схеме детального процесса) логического «ИЛИ»

Несоответствия по входам/выходам и событиям на схемах моделей одного уровня аналогичны несоответствиям, проиллюстрированным на рис. 3.40.

На рис. 3.41 показаны несоответствия, связанные с моделированием функ­ций. Процесс верхнего уровня, состоящий из двух функций, декомпозируется на два детальных процесса. Аналитик 1, выполняющий декомпозицию Функ­ции А, указывает в модели Функцию X, которую, по его мнению, выполняет Цех 1. В то же время, Аналитик 2, описывающий Функцию Б, считает, что Функция X должна быть отнесена к его процессу и что выполняет ее Цех 2. Таким образом, возникает нестыковка на одном уровне детализации.

Кроме указанной нестыковки, на рис. 3.41 можно найти еще две. Первая нестыковка — выполнение Функции А2 Цехом 2, в то время как на верхнем уровне показан один исполнитель Функции А Вторая нестыковка — на верх­нем уровне Ресурс 1 является входящим для Функций 1 и 2, но на нижнем уровне, при декомпозиции Функции Б, он не показан.

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

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

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

Когда становится ясно, что пересечений детальных процессов избежать не удается, необходимо пересмотреть процесс верхнего уровня. Таким образом, работа по созданию моделей является итерационной: создание моделей верхне­го уровня --> создание детальных моделей --> анализ схем детальных моделей -->

Ресурс 1

Ресурс 2

Продукт 1

FB

э| Продукт 2

FB

Начало процесс_а-/ >ч Функция А

Событие А )-Ц

Функция Б

Конец .процесса

Начало процесса.

Событие А

Функция А1

Event

Функция Б2

Конец процесса

Цех 2

Продукт 2

Рис. 3.41. Несоответствия по функциям на одном уровне,

пересмотр моделей верхнего уровня -> корректировка детальных моделей и т.д. Возможность итерационного пересмотра моделей необходимо учитывать при планировании проекта.

Говоря об описании детальных процессов следует упомянуть о времени, не­обходимом для такой работы. Практический опыт показывает, что для описа­ния детального процесса, состоящего из 8—12 функций, квалифицированному аналитику требуется 1,5—2 рабочих дня. Это минимальное время. На практике реальное время работы следует увеличить на коэффициент 3. Дело в том, что при работе в подразделениях постоянно происходит сдвиг сроков за счет:

переноса времени интервью и его сокращения;

превышения времени проверки адекватности моделей сотрудниками;

технических проблем при работе с инструментальной средой.

На диаграммах (рис. 3.43—3.46) приводятся примеры планового и фактичес­кого участия сотрудников в проекте.

Руководители верхнего уровня — непременные участники в проекте. Более того, степень их участия в проекте должна быть значительна: до 10—15\% рабо­чего времени или 4—6 ч в неделю. К сожалению, на практике руководители уделяют проекту слишком мало времени, что является одной из важнейших причин неудач проектов моделирования и реорганизации бизнес-процессов.

Руководители среднего уровня (начальники управлений и подразделений орга­низации) должны уделять проекту не менее 8—10 ч в неделю или 1,5—2 ч в день. Они участвуют в следующих работах по проекту:

проведение интервью;

анализ и проверка адекватности моделей процессов;

совещания по обсуждению проблем процессов и поиску путей их устра­нения;

□ Участие в проекте          □ Участие в проекте

П Основная работа            ■ Основная работа

Рис. 3.43. Плановое и фактическое участие в проекте руководителей верхнего уровня.

Руководители среднего уровня,            Руководители среднего уровня,

план факт

□ Участие в проекте          □ Участие в проекте

О Основная работа            ■ Основная работа

Рис. 3.44. Плановое и фактическое участие в проекте руководителей подразделений.

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

Специалисты подразделений предприятия должны работать в проекте не менее 10—12 ч в неделю. Они дают информацию аналитикам, проводят проверку адекватности процессов, составляют должностные и рабочие инструкции, one-

Рис. 3.45. Плановое и фактическое участие в проекте специалистов.

рационные карты, участвуют в работе по анализу процессов и разработке мер по их улучшению.

На практике как руководители, так и сотрудники подразделений уделяют работе в проекте времени в 2—2,5 раза меньше расчетного. Во многом это свя­зано с отношением руководителей к проекту. Если статус проекта невысок, ру­ководство верхнего уровня не уделяет ему достаточно внимания, руководите­ли подразделений начинают относиться к работам по проекту как к второсте­пенным задачам, имеющим самый низкий приоритет при распределении их ра­бочего времени.

Участие сотрудников рабочей группы в проекте, как правило, оставляет же­лать лучшего. Обычно предполагается, что они будут тратить 95—100\% рабочего времени на проект. На практике 30\% и более их времени уходит на текущие работы в своем подразделении. Руководителю проекта приходится приклады­вать значительные усилия для обеспечения 100\%-ной занятости сотрудников рабочей группы в проекте.

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

Количество рабочих мест в Отделе сбыта — 15.

Среднее количество функций, выполняемых на одном рабочем месте — 8.

Рис. 3.46. Плановое и фактическое участие в проекте участников рабочей группы.

3.         Среднее время описания типового процесса из 10 функций одним анали- тиком — 2 дня.

4.         Коэффициент поправки на «затягивание» длительности проекта — 3. Далее г-н О. Даренный выполнил следующий расчет:

Общее количество функций, выполняемых в Отделе сбыта — 15x8= 120.

Время описания такого количества функций одним аналитиком — (120 : 10) х 2 дня = 24 рабочих дня.

Время описания процессов с учетом наличия трех аналитиков в рабочей группе - 24 : 3 = 8.

Итоговое время описания процессов с учетом поправочного коэффици­ента — 8 х 3 = 24 рабочих дня или 5 недель.

Таким образом, руководителю проекта г-ну О. Даренному необходимо от­стаивать перед руководителем организации свою позицию по времени выпол­нения проекта, составляющем не менее 5 недель.

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

3.6.3. Методика проверки корректности моделей процессов (проверка на соответствие нотации)

Модели бизнес-процессов, подготовленные рабочей группой, могут содер­жать несоответствия, которые необходимо устранить до момента передачи этих моделей на проверку адекватности в подразделения. Их можно условно разде­лить на два типа:

1. Несоответствия выбранной нотации; ! 2. Несоответствия требованиям утвержденной «Методики описания бизнес-процессов».

Строго говоря, можно было бы отнести все ошибки в моделях процессов к разряду несоответствий Методики. На наш взгляд, целесообразно все-таки вы­делить указанные два типа.

В первую очередь, модели процессов должны быть подвергнуты тщательно­му анализу на соответствие выбранной нотации. Это означает, что необходимо проверить соблюдение правил моделирования объектов и связей между ними, регламентируемых в нотации. На рис. 3.47 показан пример модели, построен­ной в ARIS еЕРС, не соответствующей данной нотации.

На рис. 3.47 показано несколько видов несоответствий:

одно событие «запускает» выполнение двух функций без использования логического символа ветвления процесса;

в одну функцию входят две стрелки;

в начале процесс ветвится при помощи символа логического «И», а в конце стоит символ исключающего логического «ИЛИ».

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

Еще одним примером несоответствий является некорректное наименование объектов моделей. Каждый аналитик должен соблюдать правила наименования

объектов. При этом очень важно пользоваться глоссарием проекта. На рис. 3.48 приводится пример некорректного наименования объектов.

Вариант 1

Получить .документ Ау

Вариант 2

' Документ AN

Вариант 3

/ Поступил документ А/

Обработать документ А

"ІФинансовьік отдел

/Документ А Чобработан/

Док. А об-н

/Документ А ^обработан/

Рис. 3.48. Некорректное наименование объектов.

Вариант 1 содержит несколько несоответствий: 1) нельзя давать событию название функции («Получить документ А»); 2) если в Методике принято име­новать объекты типа «Подразделение» при помощи сокращений, то название объекта «Финансовый отдел» является несоответствием.

Вариант 2 — событие названо «Документ А», что недопустимо. Приводятся произвольно сокращенные названия функции, второго события и подразделе­ния, что является несоответствием.

Вариант 3 — несоответствий нет.

Таким образом, все модели должны быть проверены на соблюдение правил наименования объектов как принятых в нотации, так и сформулированных в Методике.

Следующей группой несоответствий являются несоответствия требованиям Методики к оформлению моделей. На рис. 3.49 представлены два варианта мо­делей. Первая модель выполнена с нарушением требований, вторая полностью соответствует им.

Очень часто на практике аналитики не придают значения требованиям к оформлению моделей. В результате получаются модели нестандартного вида, которые не только плохо выглядят (Вариант 1), но и значительно затрудняют возможности визуального анализа. Напротив, модели, подготовленные с учетом требований к оформлению (Вариант 2), легко читаются и могут быть использо­ваны для документирования и анализа. При построении модели (Вариант 2) Учтены следующие требования:

Построение модели «сверху вниз»;

Соблюдение стандартных размеров объектов модели;

Выравнивание объектов модели по вертикали и горизонтали.

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

После того как модели бизнес-процессов проверены на корректность, они должны быть переданы в подразделения для проверки адекватности.

Методика проверки адекватности моделей процессов

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

большой объем работы, много итерационных согласований;

необходимость проведения совещаний по увязке процессов на границах

подразделений (рабочих мест).

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

Документирование моделей процессов

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

Введение.

Глоссарий терминов.

Схемы моделей организационной структуры.

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

Схемы вспомогательных моделей.

Описание вспомогательных моделей.

Схемы моделей бизнес-процессов.

Текстовое описание моделей бизнес-процессов.

Приложение. Перечень документов.

10.       Приложение. Результаты интервьюирования сотрудников. Целесообразно представлять схемы моделей процессов в виде листов форма- та А4 (в исключительных случаях — A3), содержащих не более 8—12 объектов. При большем количестве объектов схема модели становится трудно читаемой.

Не рекомендуется создавать так называемые «склейки», когда схема процесса представлена в виде соединенных между собой нескольких листов.

Более подробно о документировании процессов при внедрении процессного подхода к управлению будет написано в главе 4.

3.6.6. Типовые ошибки выполнения работ

Типовые ошибки выполнения работ на этапе создания детальных моделей бизнес-процессов можно сформулировать следующим образом:

ошибки в сроках планирования работ по сбору и