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

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

Рейтинг:

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


3.4.   методика формирования моделей бизнес-процессов верхнего уровня организации

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

Для чего нужны схемы процессов верхнего уровня? Нельзя ли сразу присту­пить к описанию детальных бизнес-процессов, например, используя нотацию IDEF3? Ответ на этот вопрос достаточно прост. В рамках комплексного подхо­да к описанию процессов организация рассматривается как сложная система.

Устройство такой системы проще понять, описывая ее процессы сверху, укруп-ненно. Попытки сразу перейти на детальный уровень описания на практике не приводили к успеху.

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

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

увязка результатов деятельности (выходов) и процессов, определение гра­ниц процессов;

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

•           подготовка фронта работ для детального описания процессов. Выполнив описание бизнес-процессов верхнего уровня, рабочая группа полу­чает комплексное представление о деятельности организации, которое является основой для дальнейшей детализации моделей процессов. Информацию на этом этапе работ следует заносить в таблицы (табл. 3.8—3.10). Отметим, что до начала работ с таблицами целесообразно составить простейшие эскизы процессов верх­негоуровня. Эти эскизы позволят быстрее и точнее сформировать таблицы.

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

В начале главы 3 была описана методология «ускоренного» моделирования бизнес-процессов организации, согласно которой первый шаг построения мо­делей - определение внешних входов и выходов организации (см. на рис.3.7).

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

Определив перечень входов и выходов, рабочая группа составляет предвари­тельный перечень бизнес-процессов верхнего уровня, причем основных про­цессов. Заметим, что в ходе этих процессов создается добавленная ценность, их выходами является продукция, поставляемая основным клиентам организации, - это первый критерий выделения основных процессов. Вторым критерием выделения основных процессов является взаимодействие с внешней средой орга­низации. Составив перечень основных бизнес-процессов, рабочая группа фор­мирует табл. 3.9—3.10.

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

* Предварительное формулирование процесса.

** Можно отнести эти выходы как к процессу «Сбыт», так и к процессу «Производство».

 

 

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

Может показаться, что распределение входов и выходов по процессам явля­ется несколько субъективным. К сожалению, такая ситуация действительно су­ществует. Единственный путь устранить эту субъективность — максимально при­ближать границы основных процессов к границам подразделений предприятия.

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

 

 

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

На каком основании присваивать названия функциям, входящим в процесс? іоскольку «новоиспеченный» бизнес-процесс как объект управления не регла­ментирован в документах организации, то источниками информации о нем мо-ут служить:

а)         мнения руководителей и специалистов подразделений, участвующих в про- цессе;

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

Инструкции плохо подходят для целей анализа, так как либо регламентиру­ют деятельность на слишком детальном уровне, либо, наоборот, очень общи и написаны под копирку. Таким образом, рабочая группа вынуждена интервьюи­ровать руководителей подразделений с целью получить ответ на вопрос: «Какие функции содержатся в бизнес-процессе верхнего уровня?». Какой ответ может дать руководитель подразделения на такой вопрос? Во-первых, для него не по­нятно, что представляет собой объект «бизнес-процесс верхнего уровня». Во-вторых, он привык оперировать категориями структурных подразделений и их границ. Для него будет сложно ответить на поставленный вопрос. Таким обра­зом, более правильным будет вопрос: «Какие функции выполняет ваше подраз­деление и какие основные выходы оно формирует?». Ответ на такой вопрос может быть дан достаточно легко.

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

Итак, рабочая группа разработала перечень функций, входящих в процесс. Теперь этот процесс нужно представить в виде графической схемы. Как это лучше сделать? Есть несколько правил формирования схем моделей бизнес-процессов верхнего уровня:

ограниченное количество функций на схеме (не более шести-восьми);

все функции должны быть одного уровня;

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

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

должна быть отражена информация по управлению процессом;

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

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

Какой из представленных на рис. 3.29 процессов на ваш взгляд является более корректным? Первый вариант процесса не устраивает нас по нескольким причинам. Во-первых, функция «Обработка заявки клиента» весьма детальна и не исчерпывает всех работ, связанных с деятельностью по формированию портфеля заказов. Во-вторых, объект «Приход денег» вовсе не является функ-

 

Рис 3 29 Пример неправильного описания процесса верхнего уровня

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

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

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

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

Представление типового процесса «Закупки» на верхнем уровне приведено на рис. 3.31. Процесс сформирован при помощи нотации ARIS Value-added Chain Diagram (ARIS VAD).

 

 

Портфель _ заказов FB

Заказы

 

 

 

План по закупкам FB

Проект плана производстваFB

Планирование закупок

 

Служба МТО

 

План по закупкам FB

 

Заключение сделок

 

 

 

ы.

Рис 3 30 Пример процесса верхнего уровня Процесс «Закупки» МТО — материально-техническое обеспечение, ТМЦ — товарно-материальные ценности

 

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

функции планирования закупок ТМЦ;

функции формирования заказов на ТМЦ;

функции получения, хранения и отпуска ТМЦ в производство;

функции оплаты ТМЦ и контроля дебиторской задолженности;

функции бухгалтерского учета операций по закупкам ТМЦ. Обратные связи показаны на схеме процесса (см. рис. 3.31) при помощи

входящих и исходящих объектов. Например, функция «Получать, хранить и отпускать ТМЦ» имеет выход под названием «Данные по состоянию склада и движению ТМЦ», который является входом функции «Планировать закупки ТМЦ» На приведенной схеме процесса можно найти и другие обратные связи.

Информационные и материальные потоки показаны на схеме процесса «За­купки» в укрупненном виде. При последующей декомпозиции процесса на бо­лее детальные эти потоки также будут рассмотрены более подробно.

Тот же самый процесс, но разработанный в нотации IDEF0, представлен на рис. 3.32. Этот процесс будет подробно рассмотрен в главе 4 при описании цикла PDCA. Таким образом, при формировании процесса верхнего уровня очень важно отобразить основные типы потоков и существующие обратные связи. Если схема процесса верхнего уровня сформирована корректно, то существенно облегчается задача последующей декомпозиции процессов.

Какую нотацию следует использовать для описания процессов верхнего уров­ня? На наш взгляд, вполне достаточно простейших средств рисования блок-схем, таких как MS Word или MS Visio. Если использовать более серьезные инструменты, то, безусловно, стандарт IDEF0 (см. главу 2).

 

Данные по состо­янию склада и дви­жению ТМЦ рз

Данные о несо­ответствии ТМЦ требованиям рВ

Документы на ТМЦ

 

Данные поставщиков ТМЦ FB

Данные по получению ТМЦ рв

 

ТМЦ

 

 

Потребность в ТМЦ

 

Платежные документы

Документация по претензиям

FB

Данные заявки на отпуск ТМЦ в производстворв

 

Плановые ПП и ПЭ процесса «Закупки» FB

 

План закупок

Документы для оплаты ТМЦ рв

Договоры и спецификации

 

Требования потребителя на ТМЦ FB

План закупок

Плановые ПП и ПЭ процесса «Закупки» рв

Договоры и спецификации

FB

Плановые ПП и ПЭ процесса «Закупки» рв

 

 

 

Регламент БП 1.1

ПП, ПЭиДУК процесса 1.1

Регламент БП 1.2

ПП, ПЭиДУК процесса 1.2

Регламент БП 1.3

 

Ж

 

Планировать закупки ТМЦ БП1.1

Получать, хранить

 

 

 

 

 

 

 

 

 

 

 

 

ТМЦ — товарно-материальные ценности;

Ппрод — показатель продукта;

ПЭ — показатель эффективности процесса;

БП — бизнес процесс;

ОПЗ — Отдел планирования закупок;

ТО УЗ - Технический отдел управления закупками;

 

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

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

 

Данные о несо­ответствии ТМЦ требованиям рв

 

Данные по состо­янию склада и дви­жению ТМЦ рв

Данные по получению ТМЦ рв

Документы на ТМЦ

 

 

 

Данные по получению ТМЦ F

Договоры и спецификации

FB

Платежные документы

 

FB

 

тмц,

отпускаемые со склада FB

Документы для оплаты ТМЦ рв

Платежные документы

Документы для оплаты ТМЦ рв

 

 

 

ТМЦ на складе

Плановые ПП и ПЭ процесса «Закупки» рв >   Оплата ТМЦ

Плановые ПП и ПЭ процесса «Закупки» рв

ПП, ПЭиДУК процесса 1.5

 

 

 

ПП, ПЭ и ДУК процесса 1.3

Регламент БП 1.4

ПП.ПЭиДУК процесса 1.4

Регламент БП 1.5

Данные бухучета

 

Ж

 

и отпускать ТМЦ БП1.3

Оплачивать ТМЦ, контр ДЗ и КЗ, БП 1.4

Выполнять бух. учет закупок ТМЦ

 

 

 

 

 

[Склад ТМЦ

 

Бухгалтерия

 

Верхний уровень. VAD ARIS:.

ОАП — Отдел анализа поставщиков;

03 — Отдел закупок;

ЛВК — Лаборатория входного контроля;

ДЗ — дебиторская задолженность;

К.З — кредиторская задолженность;

ДУК — данные удовлетворенности клиентов;

ФО — Финансовый отдел.

12-1870

USED AT

 

DATE

 

WORKING

READER

DATE

CONTEXT

 

 

 

REV

 

DRAFT

 

п ш

 

 

 

 

 

RECOMMENDED

 

 

 

 

NOTES   123456789 10

 

 

PUBLICATION

 

AO 

 

 

Подпись: Регламент БП 1 3
W
ТП наТМЦд/

Плановые ПП и ПЭ процесса «Закупки»             М         ,

Регламент БП «Закупки»

Л/Регламент БП 1 1    Ї регламент БП 1 2

ПП ПЭ и ДУК процесса 1 1

д/Заявка на отпуск ТМЦ в производство             V

Регламент БП 1 4 W

 

Регламент БП 1 5

W

 

 

 

 

 

 

 

 

 

 

 

 

План закупок

ПП, ПЭ и ДУК процесса 1 2

Договоры и^спецификации

Документация по претензиям

Документация для оплаты ТМЦ

ПП ПЭ и ДУК процесса 1 3

Формировать заказы на ТМЦ, БП 1 2

А22

ТМЦ на складе

этпуск ТМЦ в производстве і

ТМЦ, отпуск со склада

Оплачивать ТМЦ контроли­ровать ДЗ КЗ, БП 1 4

А24

Получать, хранить и отпускать ТМЦ, БП 1 3

А23

» Ж

Данные о несоответствии требованиям ТМЦ

Данные по получению ТМЦ

опз

лвк/

Данные по состоянию склада и движению ТМЦ

 

^СкладТМЦ /V

03'

 

ОАП

г

Управление закупок

Бухгалтерия

 

 

 

NODE

А2

TITLE

Бизнес-процесс «Закупки»

NUMBER

 

Рис 3 32 Бизнес-процесс «ЗАКУПКИ» Верхний уровень IDEF0.

вем проверкой адекватности. Существует методика проверки адекватности мо­делей бизнес-процессов, которая будет рассмотрена в следующем параграфе.

 


Оцените книгу: 1 2 3 4 5