«Процессный подхо I к управлению Моделирование бизнес-процессов Издательство Манн, Иванов и Фербер Москва, 2013 УДК 658.512 ЫЖ 65.291.216 Р41 Репин В. В., Елиферов В. Г. Р41 Процессный подход к управлению. Моделирование ...»

Может использоваться для описания корректирующих действий 3 «Документ«. Объект используется для описания входящих и ис­ 4 «Начало/завершение«. Объект отображает начало или заверше­ 5 «Решение«. Объект служит для указания альтернативных резуль­ татов выполнения функции. Обычно изображают два выхода из этого объекта: «да« и «нет«. Сам объект получает наименование, характеризующее результат выполнения предыдущей функции, например «документ согласован?« 6 Объект может служить для описания контрольных функций Глава 2. Выбор методологии описания биз}1ес-процессов Пример описания процесса при помощи блок-схем представлен на рис. 2.45. Блок-схемы удобно располагать на листе вертикаль­ но. При этом справа остается место для описания осуществляемых функций, результатов их выполнения, исполнителей, номеров вхо­ дящих и исходящих документов. Такая форма представления блоксхем подходит для документирования процессов и создания регла­ ментирующей документации: описания процессов, должностных и рабочих инструкций.

Рис. 2.45. Пример блок-схемы процесса Описание процессов при помощи блок-схем имеет одно су­ щественное преимущество: простота и доступность восприятия 132 Процессный подход к управлению. Моделирование бизнес-процессов руководителями и специалистами предприятия. Затраты на обуче­ ние исполнителей чтению блок-схем минимальны. Кроме того, для их формирования не требуются специализированные, дорогостоя­ щие программные продукты.

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

2.9. Нотация «Процедура» среды моделирования Business Studio Сейчас одним из распространенных инструментов бизнес-модели­ рования стала среда Business Studio (данная система уже использу­ ется более чем в 1000 компаний в России и странах СНГ). В этой си­ стеме реализованы четыре нотации: IDEF0, «Процесс», «Процедура», еЕРС. Рассмотрим подробнее нотацию «Процедура» (рис. 2.46), так как она наиболее проста и удобна для описания бизнес-процессов организации. Основные элементы этой нотации:

— операция («действие» в терминологии Business Studio);

— стрелка типа «Связь предшествования»;

— стрелка типа «Поток объектов»;

— междиаграммная ссылка (МДС);

— сноска (текстовый комментарий);

Блок «Решение» в Business Studio обладает всеми свойствами объ­ екта типа «Процесс», но при этом не может быть декомпозирован.

Основное назначение блока «Решение» — использование в качестве логического оператора «ИЛИ» (исключающего и неисключающего).

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

Рис. 2.46. Схема процесса в нотации «Процедура» среды моделирования Business Studio Для описания взаимодействия нескольких процессов удобно применять так называемые междиаграммные ссылки (МДС).

На рис. 2.47 показан пример модели процесса, выполненной в но­ тации «Процедура» среды моделирования Business Studio. Обратим внимание читателя, что тот же самый процесс описан в нотации IDEF3 (рис. 2.24) и ARIS еЕРС (рис. 2.38). Сравнивая указанные схе­ мы, можно сделать выводы о сложности моделирования и наглядно­ сти представления моделей процессов в различных нотациях.

134 Процессный подход к управлению. Моделирование бизнес-процессов Рис. 2.47. Пример модели в нотации «Процедура» среды моделирования Business Studio Глава 2. Выбор методологии описания бизнес-процессов В целом схема процесса в нотации «Процедура» при кажущейся про­ стоте весьма информативна и удобна для описания. Можно сфор­ мулировать следующие преимущества этой нотации (в случае ее ис­ пользования в Business Studio):

— представлен минимально необходимый набор графических элементов для описания процессов типа Work Flow (поток — быстрота создания графических схем для целей регламен­ — возможность повышения информативности схем процессов за счет гибкого использования событий и именованных стре­ лок (одновременно с возможностью привязки документов к стрелкам и последующей выгрузки информации в регла­ ментирующих документах);

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

— простота в обучении (нет необходимости привлекать дорого­ стоящих специалистов со стороны — обучение можно про­ водить силами сотрудников отдела организационного раз­ — схемы процессов являются кросс-функциональными, что удобно для описания сквозных процессов компании;

— можно выгружать и редактировать схемы в MS Visio (при не­ Программный продукт Business Studio, как и другие достаточно мощные продукты, позволяет формировать публикацию всей моде­ ли в формате HTML в виде связанных между собой диаграмм, текста и гиперссылок на документы и файлы для размещения на внутрен­ нем интранет-портале.

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

136 Процессный подход к управлению. Моделирование бизнес-процессов 2.10. Нотация BPMN BPMN — система условных обозначений (нотация) и модель для опи­ сания и подготовки к автоматизации бизнес-процессов. Разработана она компанией Business Process Management Initiative и поддерживает­ ся Object Management Group после слияния организаций в 2005 году.

Предыдущая версия BPMN — 1.2, последняя версия — 2.0 (2012 год).

Нотация BPMN появилась в 2004 году. Она ориентирована на опи­ сание так называемых исполняемых процессов, которые поддержи­ ваются системами автоматизации операционных процессов — ВРМ (Business Process Management).

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

Основные категории объектов (элементов), которые исполь­ зуются в BPMN, а также соответствующие условные обозначения показаны на рис. 2.48. Элементы потока являются ключевыми для формирования модели процесса. События (Event) используются для обозначения начала (Start) и завершения (End) процесса. Кроме того, могут быть промежуточные события (Intermediate). Как правило, событие имеет причину (так называемый триггер) или воздействие (результат) и изображается в BPMN в виде круга со свободным цен­ тром, предназначенным для отображения различных триггеров или результатов («Сообщение», «Таймер», «Ошибка», «Отмена», «Компен­ сация», «Правило», «Связь», «Множественный», «Завершение»). Для каждого триггера есть соответствующее условное обозначение.

«Действие» (Activity) — общий термин, обозначающий работу, выполняемую исполнителем. В BPMN определены следующие виды действий: «процесс» (Process), «подпроцесс» (Sub-Process) и «задача»

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

Глава 2. Выбор методологии описания бизнес-процессов Рис. 2.48. Объекты нотации BPMN «Шлюзы» (Gateway) используются для контроля расхождений и схождений потока задач. Их основное назначение состоит в описа­ нии логики выполнения процесса, которая может включать ветвле­ ние, раздвоение, слияние и соединение маршрутов. Маркеры внутри условных обозначений показывает тип шлюза как логического опе­ ратора. Определены следующие типы шлюзов:

— эксклюзивные «ИЛИ» (XOR) — исключающие условия раз­ вилки и объединения. Данные шлюзы могут основываться как на данных (Data-based), так и на событиях (Event-based).

Тип шлюзов, основанный на данных, может отображаться как при помощи маркера X, так и без него;

— «ИЛИ» (Or) — включающие условия и объединение;

— комплексные (Complex) — сложные условия и ситуации;

— «И» (And) — раздвоение и слияние.

Соединяющие элементы служат для соединения других элемен­ тов между собой.

138 Процессный подход к управлению. Моделирование бизнес-процессов «Поток операций» (Sequence Flow) служит для отображения по­ следовательности (порядка) выполнения задач во времени внутри «Поток сообщений» (Message Flow) служит для отображения об­ мена сообщениями (информацией) между двумя пулами (процесса­ ми), готовыми их отсылать и принимать.

«Ассоциация» (Association) служит для установления связей между информацией и элементами потока. При помощи ассоциации текстовые объекты, а также графические объекты, не относящиеся к элементам потока, могут соотноситься с его элементами.

В BPMN «пул» (Pool) представляет собой процесс. Кроме того, он может использоваться для отображения некоторой внешней по от­ ношению к процессу сущности или сервиса. Между пулами может осуществляться обмен информацией.

«Дорожка» (Lane) обеспечивает разделения внутреннего про­ странства пула как по вертикали, так и по горизонтали. Дорожка может служить для группировки задач, выполняемых одним под­ разделением, исполнителем и т. п. Использование дорожек призвано сделать схемы более наглядными и удобными для восприятия.

«Объект данных» (Data Object) относится к артефактам, посколь­ ку он не оказывает непосредственного влияния ни на поток задач, ни на поток сообщений. Однако он отображает информацию о том, ка­ кие действия необходимо выполнить и/или каков их результат. При по­ мощи объекта данных на схеме можно показать входы/выходы задачи.

«Группировка объектов» (Group) применяется для составления документации или анализа. Группа может быть использована как альтернатива дорожкам.

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

На рис. 2.49 показан пример модели процесса, разработанной с применением нотации BPMN. Отметим, что тот же самый процесс описан в нотации IDEF3 (рис. 2.24), ARIS еЕРС (рис. 2.38) и «Проце­ дура» среды моделирования Business Studio (рис. 2.47).

яоэээНосЫ-ээнепд нтшэпио птоиодошдп йодп{\ ттг \ uo Процессный подход к управлению. Моделирование бизнес-процессов 2.11. Сравнительный анализ нотаций.

Выбор нотации для описания процессов 2.11.1. Нотации IDEF0 и ARIS VAD Ниже в табл. 2.5 приводится сравнительный анализ нотаций моде­ лирования бизнес-процессов ARIS VAD и IDEF0. Обе эти нотации предназначены для описания процессов организации на верхнем Табл. 2.5. Сравнение нотаций IDEF0 и ARIS VAD 1 Принцип построения диаграммы Временная последовательность Принцип доминирования Входящая информация Используется отдельный объект Исходящая информация Используется отдельный объект Исполнитель процесса Используемое оборудование Iлава 2. Выбор методологии описания бизнес-процессов Управление процессом по управлению/контролю Обратная связь по входу Миграция потоков данных и ре­ Принципиально невозможна Предусмотрена. Миграция сурсов при декомпозиции Туннелирование потоков данных узлов (процессов) ление диаграммы процесса при мендаций по форматированию ЮЕЕО. Развитая система обо­ Сравнительный анализ нотаций показывает, что нотацию ARIS VAD можно рассматривать как инструмент простейшего схемати­ ческого изображения бизнес-процессов. Это средство для эскизного описания процессов верхнего уровня, не предназначенное для по­ строения связных комплексных моделей деятельности организации.

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

142 Процессный подход к управлению. Моделирование бизнес-процессов В методических материалах [6] по использованию нотации УАО можно найти рекомендации следующего характера. На первом эта­ пе работы формируются модели верхнего уровня в УАО. Затем они декомпозируются в нотации А1Ш еЕРС. Но допускается и создание нескольких уровней декомпозиции в нотации УАО, что исключи­ тельно неудобно, так как декомпозируемые модели никак не связаны с моделями верхнего уровня (кроме формальной принадлежности).

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

Рис. 2.50. Декомпозиция моделей процессов в АШБ Справедливости ради следует отметить, что при декомпозиции процессов из нотации ШЕРО в ШЕРЗ мы сталкиваемся с теми же Глава 2. Выбор методологии описания бизнес-процессов проблемами. Но здесь мы делаем акцент на том, что описание про­ цессов в УАЭ на верхнем уровне существенно менее удобно, чем в ШЕРО. Кроме того, работа в АШБ УАЭ значительно более трудоем­ ка. Так, количество операций по отображению процесса в УАЭ в два и более раз больше, чем при создании аналогичной модели в ШЕРО.

На рис. 2.51 и 2.52 дается пояснение данной оценки трудоемкости.

Рис. 2.51. Процесс в ШЕРО Рис. 2.52. Процесс рис. 2.51 в АШБ УАЭ UA Процессный подход к управлению. Моделирование бизнес-процессов Видно, что для отображения простейшего процесса из двух функ­ ций в IDEF0, включающего один поток материальных ресурсов и две обратные связи, потребовалось отображение пяти объектов (двух функций и трех стрелок). В нотации ARIS VAD для отображения рассматриваемого процесса потребовалось 12 объектов (два Valueadded Process chain, два Cluster, один Technical Term, семь стрелок).

Таким образом, трудоемкость описания процесса в нотации VAD су­ щественно выше, а это отражается на времени выполнения проекта и необходимых ресурсах.

Если поставлена задача описания деятельности организации на верхнем уровне, можно решить ее двумя способами, как показано Табл. 2.6. Способы описания бизнес-процессов верхнего уровня Данный подход предполагает быстрое, эскизное Использование методологии ЮЕГО - оптималь­ описание схем процессов верхнего уровня. Не тре­ ный вариант для описания бизнеса на верхнем буется создавать комплексную модель. При такой уровне, так как позволяет отобразить информа­ постановке задачи можно использовать простей­ ционные и материальные потоки, требования шие средства визуализации блок-схем процессов, к персоналу и инфраструктуре, управляющие воз­ Использование IDEF0 не рекомендуется, так как ствует определению процесса в ИСО 9000:2005.

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

2.11.2. Нотации IDEF3 и ARIS еЕРС В табл. 2.7 приводится сравнение нотаций IDEF3 ARIS и еЕРС. Нота­ ция ARIS еЕРС — более новая с точки зрения времени ее появления, но фактически это расширение IDEF3 за счет использования объ­ екта «Событие» (Event).

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

Глава 2. Выбор методологии описания бизнес-процессов Табл. 2.7. Сравнение нотаций IDEF3 и ARIS еЕРС Принцип построения диа­ 2 Описание процедуры Входящий документ Входящая информация 5 Исходящий документ Исходящая информация Исполнитель процедуры Используемое оборудо­ 9 Связь диаграмм при де­ Для привязки к другим диа­ Визуальное восприятие Интуитивно понятные, легко диаграмм процессов Стандартная форма пред­ ставления диаграммы мендаций по форматированию процесса при документи­ моделей еЕРС при документи­ Ограничения по количе­ Количество объектов не огра­ Рекомендовано не более шести.

При помощи этих символов отображаются ветвления и слияния потоков работ в рамках бизнес-процесса. Возможность отображе­ ния событий в АШБ еЕРС позволяет создавать более корректные и подробные описания процессов. При этом, однако, существенно 146 Процессный подход к управлению. Моделирование бизнес-процессов повышается сложность и трудоемкость описания. Дополнительные преимущества АМБ еЕРС заключаются в возможности визуально­ го отображения входящих/исходящих документов, информации, используемой инфраструктуры и т. п. при помощи специальных объектов. К сожалению, на практике наличие таких широких воз­ можностей по описанию процесса в АМБ еЕРС часто приводит к от­ рицательным результатам: модели становятся слишком сложными и громоздкими, неудобными для документирования. Данную про­ блему нельзя отнести к недостаткам программного продукта А1Ш:

аналогичные результаты получались и при использовании других инструментов, например Сазе1Ш5е. Причину этого следует искать в недостаточно проработанной методике (Соглашении по модели­ рованию), которая бы ограничивала применение всех возможностей инструментария практическими потребностями и назначением кон­ кретной модели. То есть перед началом проекта необходимо тщатель­ но оговорить, какими объектами в модели должны быть отражены совокупности реальных действий, событий и связей.

С формальной точки зрения нотация А1Ш еЕРС наиболее удобна для детального описания процессов. С ее помощью можно эффек­ тивно описывать процессы уровня рабочих мест с целью разработки должностных и рабочих инструкций.

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

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

В нотации А1Ш еЕРС и ШЕРЗ не заложены средства описания управляющих воздействий, обратных связей по управлению и ин­ формации. Поэтому при формировании моделей процессов можно Глава 2. Выбор методологии описания бизнес-процессов использовать несколько способов отображения управляющих воз­ действий. Более корректным было бы описывать процессы управле­ ния отдельно.

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

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

— на схеме отображаются реальные документы, файлы, ресурсы;

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

— схема процесса имеет компактный размер.

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

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

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

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

Рис. 2.53. Объемный бизнес-процесс На рисунке видно, что руководитель и его заместитель активно участвуют в процессе. Существует постоянный, цикличный поток Глава 2. Выбор методологии описания бизнес-процессов информации по ходу процесса от исполнителей вверх и управленче­ ских решений от руководителей вниз. Даже если в крайнем случае мы полностью делегируем все права на принятие управленческих ре­ шений по процессу исполнителям, у руководителя останется ключе­ вая функция — анализ эффективности бизнес-процесса и его улуч­ шение с ориентиром на стратегические цели компании (если таковые имеются). Улучшение процесса руководитель осуществляет за счет управления ресурсами: персоналом, финансами, материалами, обо­ рудованием, программным обеспечением, информацией.

Каким же образом увязать деятельность руководителей и испол­ нителей при построении моделей потоков работ (АКК еЕРС, ШЕРЗ)?

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

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

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

При этом «где-то в другом месте» мы должны описать работу руко­ водителя по проверке этого документа и принятию решения. Это означает, что мы должны создать модель, описывающую деятель­ ность руководителя.

Рис. 2.54. Различные варианты отображения участия руководителя в процессе Глава 2. Выбор методологии описания бизнес-процессов На рис. 2.54 приводится еще два способа встраивания руководи­ теля в бизнес-процесс. Первый из них предполагает прямое вклю­ чение в процесс «Функции управления», второй изображен в виде дополнительного события «Принято управленческое решение».

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

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

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

Подводя итог раздела, следует сказать, что формально нотация ЛЮБ еЕРС проработана удобнее и лучше, чем ШЕРЗ.

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

— четко сформулированные цели проекта;

— методологию (нотацию) моделирования;

— инструмент (среду) моделирования;

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

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

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

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

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

2.12. Список литературы 1. Mayer R. J., deWitte R S. Delivering Results: Evolving BPR from Art to Engineering. URL: www.idef.com 2. Марка Д. А., Макгоуэн К. Методология структурного анализа и проекти­ рования. — М. : МетаТехнология, 1993.

3. Маклаков С. В. BPWin и ERWin. CASE-средства разработки информаци­ онных систем. — М. : Диалог-МИФИ, 2000.

4. Ивлев В. А., Попова Т. В. Реорганизация деятельности предприятий:

от структурной к процессной организации. — М. : Иаучтехлигиздат, 2000.

5. Черемпых С. В., Семенов И. О., Ручкин В. С. Структурный анализ систем:

IDEE-технологи и. — М. : Финансы и статистика, 2001.

6. Шматалюк А. и др. Моделирование бизнеса. Методология ARIS. Практи­ ческое руководство. — М. : Серебряные нити, 2001.

7. Шеер А.-В. Бизнес-процессы: основные понятия, теории, методы. — М. :

Глава 2. Выбор методологии описания бизнес-процессов 8. Вендров Л. М. Проектирование программного обеспечения экономиче­ ских информационных систем. — М.: Финансы и статистика, 2000.

9. Рении В. В. Бизнес-процессы компании: построение, анализ, регламента­ ция. — М.: Стандарты и качество, 2007.

10. Руководство пользователя Business Studio (2012).

11. Руководство технического специалиста Business Studio (2012).

12. Создание пользовательских отчетов Business Studio. Методика (2012).

13. Маклаков С. В. Моделирование бизнес-процессов с АП Fusion Process Modeler. — М.: Диалог-МИФИ, 2008.

И. Silver В. BPMN Method and Style: Л Levels-based Methodology for В PM Process Modeling and Improvement Using BPMN 2.0. — Cody-Cassidy, 2009.

15. Оптнер С. Л. Системный анализ для решения проблем бизнеса и про­ мышленности. — М.: Кои цент, 2006.

Глава Описание и анализ бизнес-процессов 3.1. Постановка целей описания бизнес-процессов 3.1.1. Формулировка целей проекта Глава 3 посвящена методикам создания моделей бизнес-процессов организации. В настоящее время руководители многих предприятий инициируют проекты по моделированию процессов, преследую­ щие различные цели. Качественно эти цели можно разделить на две группы. Достижение первой группы целей должно, по мнению ру­ ководителей, обеспечить решение конкретных проблем организа­ ции и повысить эффективность ее деятельности. От проекта описа­ ния бизнес-процессов в этом случае ожидаются какие-то реальные, практически важные результаты. Вторая группа может быть охарак­ теризована как группа целей-лозунгов. В действительности никто в организации не ждет практического эффекта от проекта, однако он играет существенную политическую роль или служит обоснованием для распределения финансовых ресурсов. В главе 3 мы рассмотрим методики работ, обеспечивающие достижение первой группы целей, то есть каких-либо практических результатов.

Если говорить о первой группе целей, то можно выделить несколь­ ко различных направлений, по которым может развиваться проект описания бизнес-процессов. На практике в первую очередь руководи­ тели ставят задачу «разобраться, как идет работай где теряется эффек­ тивность (возникают финансовые потери)». При этом предполагается, что полученный комплект моделей бизнес-процессов будет использо­ ван в дальнейшем для автоматизации. Кроме того, из моделей хотят получить информацию о существующей системе документооборота Глава 3. Описание и анализ бизнес-процессов и внести в нее необходимые изменения и т. д. Можно выделить не­ сколько характерных особенностей формулировок постановки задаУ руководителей верхнего уровня на данном этапе:

— размытость формулировок и четких определений (например, — отсутствие четких критериев достижения целей проекта;

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

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

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

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

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

Рис. 3.1. Непонимание целей проекта Глава 3. Описание и анализ бизнес-процессов Для того чтобы избежать противоречий, целесообразно провести детализацию целей руководителей, с тем чтобы привести структуру целей верхнего уровня к понятным, конкретным и количественно измеримым целям нижнего уровня. После этого данная структура целей согласовывается с руководством, которое подтверждает, что именно это оно и имело в виду.

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

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

— наличие четких, проработанных целей проекта;

— наличие профессионального руководителя проекта;

— наличие утвержденной методологии ведения проекта, вклю­ чая методологию создания моделей процессов;

— рабочую команду, соответствующую поставленным задачам;

— эффективное использование инструментальных средств мо­ делирования бизнес-процессов;

— освещение работ среди сотрудников предприятия.

Следует отметить, что при описании бизнес-процессов можно и нужно пользоваться существующими инструментами проектного управления [1].

Роль руководителей верхнего и среднего уровня при внедрении процессного подхода к управлению является решающей.

Наличие опытного руководителя проекта — это обязательное условие. Такой специалист должен удовлетворять по крайней мере следующим квалификационным требованиям:

158 Процессный подход к управлению. Моделирование бизнес-процессов — опыт работы в организации (отрасли) не менее трех лет;

— знание методик и практический опыт проектного управления — знание и понимание принципов процессного управления и методов менеджмента качества;

— знание и понимание методологий моделирования бизнеспроцессов (в том числе знание нотаций);

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

Далее в главе 3 будут более подробно рассмотрены указанные основные критические факторы успеха проекта моделирования биз­ нес-процессов.

3.1.2.Методика структуризации целей проекта Методика структуризации целей проекта реорганизации бизнеспроцессов состоит из шагов, представленных на рис. 3.2.

Рис. 3.2. Методика структуризации целей проекта На этапе 1 руководитель формулирует в произвольной (лучше, конечно, в формализованной) форме цели проекта, сроки его вы­ полнения и возможный объем выделяемых на этот проект ресурсов.

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

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

Табл. 3.1. Таблица для структуризации целей проекта Цели, сформулированные Цели второго уровня Цели третьего Приоритет, простав­ Основная задача рабочей группы на этом этапе — добиться пре­ дельной конкретности целей. При декомпозиции следует стремиться ставить цели, достижение которых может быть выражено количе­ ственными показателями. Пример заполнения таблицы целей пред­ ставлен в табл. 3.2.

Очевидно, что детализированные цели, показанные в табл. 3.2, далеки от совершенства, но они существенно более информативны для рабочей группы, чем формулировка «Оптимизировать бизнеспроцесс сбыта готовой продукции».

На этапе 3 разработки целей проекта проводится согласование де­ тальной структуры целей с руководителем. Его задача на этом этапе состоит в установлении приоритетов по достижению детальных це­ лей. Может возникнуть ситуация, когда руководитель неудовлетворен предложенной структурой. В этом случае рабочая группа исправляет 160 Процессный подход к управлению. Моделирование бизнес-процессов указанные недостатки и представляет на рассмотрение вторую версию структуры целей и т. д. Если руководителя устраивает предложенная декомпозиция целей, то рабочая группа приступает к разработке тех­ нического задания (ТЗ) на выполнение работ по проекту Табл. 3.2. Пример заполнения таблицы целей Цели, сформулирован­ Цели второго Цели третьего уровня 1. Оптимизировать 1.1. Увеличить 1.1.1. Оптимизировать про­ бизнес-процесс сбыта объем продаж цесс сбыта через представи­ Разработка внутреннего ТЗ не является обязательным элементом проекта, однако его наличие существенно облегчает задачу по вы­ полнению проекта. В процессе подготовки ТЗ как у рабочей команды, так и у руководителей возникает общее понимание целей и возмож­ ных результатов проекта, а также параметров, по которым измеря­ ется степень достижения целей. Общая структура ТЗ на описание бизнес-процессов предприятия приводится ниже:

— требования к моделям бизнес-процессов и критериям их ана­ — требования к отчетной информации по этапам;

— требования к оперативной отчетности по проекту.

Структура ТЗ на описание бизнес-процессов зависит от приме­ няемого инструментального средства моделирования.

Глава 3. Описание и анализ бизнес-процессов После подготовки ТЗ рассматривается и утверждается руковод­ ством. Утвержденное ТЗ является обязательным к исполнению ра­ бочей группой. По ходу выполнения проекта могут возникать раз­ личные ситуации, приводящие к изменению понимания его целей и задач, а также степени их достижимости. Поэтому возможны кор­ ректировки ТЗ в процессе работы, но они не должны быть слишком сильными, дезориентирующими рабочую группу.

3.1.3.Методика определения целей проекта на основе существующих проблем Методика определения целей проекта на основе существующих про­ блем представлена на следующем рис. 3.3.

Рис. 3.3. Методика определения целей проекта На этапе 1 руководитель ставит задачу повысить эффективность бизнес-процесса сбыта. При этом четко очерчиваются границы рассма­ триваемого процесса. Работы будут проводиться именно с этим про­ цессом. На этапе 2 рабочая группа формирует эскиз (приблизительное описание) бизнес-процесса на верхнем уровне. Главная задача — ото­ бразить основные функции (процессы), входящие в процесс верхнего уровня. Далее как для процесса в целом, так и для составляющих его функций определяются существующие проблемы. Их выделение осно­ вывается на анализе результатов интервьюирования руководителей и сотрудников подразделений, выполняющих данный процесс. Стро­ го говоря, полученные данные носят характер симптомов, а не причин проблем. Тем не менее полученная спецификация проблем представля­ ется либо в виде перечня, либо в виде дерева, как показано на рис. 3.4.

162 Процессный подход к управлению. Моделирование бизнес-процессов Рис. 3.4. Дерево проблем процесса На третьем этапе рабочая группа пытается определить показа­ тели, которые характеризуют каждую выделенную проблему. Таких показателей может быть несколько. Иногда формулировка проблемы уже может содержать наименование показателя и указание на его не­ соответствующее значение.

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

— данные неудовлетворенности и требования клиентов процесса;

— данные финансово-экономического анализа.

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

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

Рис. 3.6. Целевые критерии оценки эффективности процесса 164 Процессный подход к управлению. Моделирование бизнес-процессов Фактически рассмотренный способ разработки целей состоит в том, чтобы определить параметры оценки существующего про­ цесса, измерить их для текущего состояния и определить перспек­ тивные значения, которые необходимо получить путем описания и реорганизации процесса. Как видно из рис. 3.6, данный подход об­ ладает двумя существенными недостатками, а именно:

1. Субъективность определения проблем и показателей оценки 2. Отсутствие какой-либо системы, используемой для стандар­ тизации показателей оценки процесса.

Далее в данной главе приводятся классификация и примеры по­ казателей процесса. В главе 4 также рассмотрены практические при­ меры определения показателей.

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

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

Глава 3. Описание и анализ бизнес-процессов — ориентация на быстрое (2-3 месяца) достижение результатов проекта описания процессов;

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

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

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

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

— низкое качество (фрагментарность описания, «потерянные»

функции и документы, отсутствие описания необходимых элементов процесса, отсутствие комментариев к процессам, анализа проблем и т. п.).

Такое состояние полученных моделей процессов можно попы­ таться объяснить несоответствием привлеченных для работы ресур­ сов (времени, людей) масштабам работ. Но простой расчет показывает, что для корректного, детального описания процессов деятельности организации среднего размера (3-5 тыс. человек) потребуется дватри года работы пяти-восьми аналитиков. Тем не менее руководители компаний, инициирующие проекты, часто не оценивают сложность такой работы. В некоторых случаях были попытки задействовать од­ новременно более 15 аналитиков для описания процессов. Но такой подход, к сожалению, не решает проблему. Дело в том, что получен­ ный огромный комплект моделей процессов никто не сможет опера­ тивно (за те же два-три месяца) проанализировать, выявить причины проблем, определить адекватные мероприятия по реорганизации.

Для чего же тогда можно использовать ускоренный метод? Наш опыт общения с руководителями служб крупных предприятий 166 Процессный подход к управлению. Моделирование бизнес-процессов и холдингов показывает, что руководство этих организаций часто ставит задачу локального описания некоторых выделенных бизнеспроцессов на первом этапе (1-3-й месяц), следующих — на втором (4-6-й месяц) и т. д. При таком подходе приходится выделять часть процессов действующей организации и заниматься их описанием.

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

Шаг 1. Определить внешних клиентов организации и входы/выходы для организации в целом.

На рис. 3.7 показана организация в целом, ее внешнее окружение, а также входы и выходы. Под внешним окружением подразумевают­ ся основные потребители готовой продукции, поставщики сырья, кредиторы, государственные органы и т. д. Входы и выходы пред­ ставляют собой основные информационные и материальные потоки, посредством которых организация взаимодействует со своим окру­ жением. При описании ее деятельности на этом этапе важно показать основных субъектов окружения и основные потоки так, чтобы модель Рис. 3.7. Метод 1. Шаг 1. Определение окружения организации и внешних входов/выходов Глава 3. Описание и анализ бизнес-процессов не стала слишком сложной, но в то же время была достаточно инфор­ мативной для дальнейшего выделения основных бизнес-процессов.

Шаг 2. Составить перечень основных бизнес-процессов органи­ зации, формирующих внешние выходы.

Выделение основных бизнес-процессов организации осущест­ вляется на основе информации о внешнем окружении и основных информационных и материальных потоках по принципу «клиент процесса -> потребляемый им продукт -> основной бизнес-процесс организации». Количество основных бизнес-процессов, которые мо­ гут быть выделены, желательно ограничивать (не более 7 ± 2). Кро­ ме основных, должны быть определены вспомогательные процессы.

Общее количество процессов верхнего уровня не должно превы­ шать 13-15.

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

Рис. 3.8. Метод 1. Шаг 2. Составление перечня основных бизнес-процессов организации Шаг 3. Определить внутренние входы/выходы каждого процесса и недостающие вспомогательные бизнес-процессы.

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

Рис. 3.9. Метод 1. ШагЗ. Определение внутренних входов/выходов процессов

ОРГАНИЗАЦИЯ

Итогом выполнения работ на этом шаге является спецификация основных и вспомогательных процессов и внешних/внутренних вхо­ дов/выходов, связанных с ними.

Шаг 4. Описать каждый бизнес-процесс в виде набора подпро­ Каждый процесс, выделенный при выполнении шагов 2-3, опи­ сывается в виде набора подпроцессов нижнего уровня (рис. 3.10).

Эта работа может выполняться как с использованием специальной среды моделирования, так и простейшими средствами MS Word или Excel. Как определять подпроцессы, входящие в процесс? Для этого пользуются существующей документацией (положения о подразде­ лениях, инструкции и т. д.) Как правило, такая документация явля­ ется актуальной лишь на 30-40% — реально выполняемые функции отличаются от бумажных. Рабочей группе приходится собирать ин­ формацию путем интервьюирования или анкетирования сотрудни­ ков и руководителей функциональных подразделений организации.

Глава 3. Описание и анализ бизнес-процессов Подробно методы сбора информации представлены далее в данной главе.

Рис. 3.10. Метод 1. Шаг 4. Описание бизнес-процесса в виде набора подпроцессов Шаг 5. Распределить полученные подпроцессы по подразделени­ ям организации.

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

Шаг 6. Детально описать каждый процесс при помощи выбранной методики (IDEFO, IDEF3, DFD, ARIS VAD, ARIS еЕРС, BPMN, S-BPM).

Имея формальные перечни процессов, входящих в них подпро­ цессов, входов и выходов, можно заняться формированием схем 170 Процессный подход к управлению. Моделирование бизнес-процессов процессов при помощи выбранной нотации (ARIS, стандартов IDEF, DFD, блок-схем и т. д.), как показано на рис. 3.12. Существу­ ет ряд практически важных, проверенных приемов создания каче­ ственных моделей бизнес-процессов. Для их успешного применения необходимо знать принципы создания моделей бизнес-процессов, изложенные в главе 2.

Рис. 3.11. Метод 1. Шаг 5. Распределение подпроцессов бизнес-процесса по подразделениям Рис. 3.12. Метод 1. Шаг 6. Детальное описание бизнес-процесса Глава 3. Описание и анализ бизнес-процессов Шаг 7. Составить регламенты и сформировать матрицы ответ­ ственности по каждому бизнес-процессу (рис. 3.13).

Рис. 3.13. Метод 1. Шаг 7. Составление регламентов по бизнес-процессу Разработанные при выполнении шага 6 модели бизнес-процессов документируются, то есть создается описывающий их комплект до­ кументов. К числу таких документов можно отнести:

— регламент выполнения процесса;

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

— должностные инструкции исполнителей;

— рабочие инструкции исполнителей.

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

То же самое касается должностных инструкций. Если процесс явля­ ется сквозным (проходит через несколько крупных подразделений), то сформированный для него «Регламент выполнения процесса»

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

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

— субъективность определения перечня процессов верхнего уровня и привязки к ним внешних входов/выходов;

— сложность и субъективность определения внутренних вхо­ дов/выходов для основных и вспомогательных процессов;

— субъективность определения вспомогательных процессов;

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

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

3.2.2. Методология полного описания бизнес-процессов (метод 2) Методология полного описания бизнес-процессов рассчитана на ор­ ганизации, поставившие своей целью реальное улучшение деятель­ ности в разумные сроки. Данная методология помогает в первую очередь навести элементарный порядок в управлении, а затем пере­ ходить к внедрению элементов процессного управления. «Полным»

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

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

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

Шаг 1. Определить внешних клиентов организации (окружения) и входы/выходы для организации в целом.

При выполнении шага 1 рассматривается организация в целом и ее окружение, так же как и в методе 1. Определяются внешние вхо­ ды и выходы (рис. 3.14). Результатом работ является спецификация входов/выходов и окружения организации. Важно отметить, что входы/выходы должны быть указаны в спецификации на верхнем уровне. Например, было бы неправильно включать в спецификацию такие позиции, как «накладная», «готовое изделие» и т. п. Нужно включать агрегированные позиции: «документы на отгрузку», «гото­ вые изделия».

Шаг 2. Привязать полученные входы/выходы к подразделениям организации.

Шаг 2 существенно отличается от метода 1, а именно выделяются не основные процессы, а структурные подразделения организации.

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

Далее все внешние входы и выходы связываются со структурны­ ми подразделениями, как показано на рис. 3.15. Эту работу можно выполнить также достаточно корректно. Могут возникать ситуации, когда те или иные входы/выходы связаны с несколькими функци­ ональными подразделениями; при этом возможны две ситуации:

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

Рис. 3.14. Метод 2. Шаг 1. Определение окружения организации и внешних входов/выходов Рис. 3.15. Метод 2. Шаг 2. Привязка полученных входов/выходов к подразделениям организации 176 Процессный подход к управлению. Моделирование бизнес-процессов Очевидно, что субъективность работ по привязке входов/выходов к подразделениям на этом этапе минимальная или вообще от­ сутствует.

Шаг 3. Определить внутренние входы/выходы для каждого под­ разделения организации.

Помимо внешних входов/выходов существуют и внутренние вхо­ ды/выходы, обусловленные информационными и материальными потоками между подразделениями организации (рис. 3.16). Эти вну­ тренние потоки также достаточно легко могут быть идентифициро­ ваны. При этом важно не допускать слишком детального описания потоков. Оно на данном этапе работ нецелесообразно. В то же время важно определить все типы внутренних потоков между подразделе­ Рис. 3.16. Метод 2. Шаг 3. Определение внутренних входов/выходов для каждого подразделения Шаг 4. Определить перечень функций, выполняемых в каждом подразделении.

На шаге 4 рассматривается деятельность каждого подразделения в отдельности. Более четко определяются границы подразделений.

Для каждого подразделения формируется перечень выпол­ няемых в нем функций (рис. 3.17). Именно на этом этапе начинает Глава 3. Описа1ше и анализ бизнес-процессов сказываться элемент субъективности. Как правило, реально выпол­ няемые в подразделениях функции отражены в формальных доку­ ментах лишь на 30-40%. Дело в том, что положения о подразделениях, инструкции и другие документы редко пересматриваются и не явля­ ются актуальными. Это обусловлено в первую очередь отношением руководства компании к регламентирующей документации и отсут­ ствием системы работы с ней. На наш взгляд, такое положение дел характерно именно для российских организаций. В Европе, Японии, США в крупных компаниях система управления документацией существует хотя бы в формальном виде. Почему мы сделали такой вывод? Дело в том, что подавляющее число предприятий развитых стран сертифицировано по стандартам ИСО 9001, одним из требо­ ваний которых является управление документацией. В настоящее время в России многие руководители осознают важность регламен­ тации работы при помощи документации процессов и инициируют соответствующие проекты.

Рис. 3.17. Метод 2. Шаг 4. Определение перечня функций, выполняемых в подразделении чей группой с использованием существующей документации, но основное средство сбора информации — интервьюирование 178 Процессы ы й п одход к у правлены ю. Мо делировапие бизнес-процес со в руководителей и сотрудников подразделений. Напомним, что мето­ дики интервьюирования являются также базовыми и для метода 1.

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

Шаг 5. Для каждого подразделения сгруппировать функции по про­ цессам, формирующим выходы. Привязать к этим процессам входы.

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

Другая часть функций может войти во вспомогательные процессы.

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

Как давать наименования бизнес-процессам, по которым распре­ делены функции подразделения? Делать это можно по-разному:

— на основе состава выполняемых работ и полученных резуль­ — на основе классификации процессов (см. выше);

— на основе наименования процессов схемы жизненного цикла лава 3. Описи} ше и анализ бизнес-процессов Рис. 3.18. Метод 2. Шаг 5. Группирование функций подразделения по процессам При использовании первого подхода (ему соответствует рис. 3.19) названия бизнес-процессов подразделения определяются на осно­ ве состава выполняемых работ и полученных результатов (пример:

процесс «Формирование плана отгрузки на квартал» или процесс «Бюджетирование деятельности подразделения»). На практике мно­ гие полученные цепочки процессов подразделения могут принадле­ жать одному более крупному процессу уровня организации в целом.

Так, например, несколько бизнес-процессов уровня отдела сбыта — это составляющие процесса «Сбыт» для организации в целом.

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

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

Нежелательно давать выделенным цепочкам процессов под­ разделения произвольные названия, так как это будет препят­ ствовать определению сквозных бизнес-процессов организации на следующем этапе. Нельзя также рассматривать процессы подразде­ ления как плоские, то есть состоящие только из работ, выполняемых 180 Процессный подход к управлению. Моделирование бизнес-процессов исполнителями на местах, без руководителей. Следует помнить, что любая цепочка процесса нуждается в планировании, учете, анали­ зе, управлении. Выделенные процессы подразделений должны быть объемными (показывать деятельность руководителей), а не просто отражать плоскую последовательность выполнения функций.

Рис. 3.19. Объединение процессов подразделений в процессы организации в целом Результатом работы на шаге 5 является четкое понимание деятельности подразделений за счет ее структуризации по биз­ нес-процессам. Обратите внимание, что субъективность выделения бизнес-процессов уровня подразделения на основе его выходов и вы­ полняемых функций минимальна.

Шаг 6. Используя входы/выходы между подразделениями, сгруп­ пировать бизнес-процессы подразделений в бизнес-процессы орга­ На шаге 6 осуществляется интеграция бизнес-процессов уров­ ня подразделений в сквозные бизнес-процессы уровня организации в целом. Существующие между подразделениями информационные и материальные потоки являются при этом указателями связи между Глава 3. Описание и анализ бизнес-процессов процессами подразделений. Отметим, что сквозных процессов верх­ него уровня (или групп процессов) в организации не должно быть много. Оптимальное количество — от 3 до 8. Это наиболее важные для бизнеса сквозные процессы.

Рис. 3.20. Жизненный цикл продукции Таким образом, все функции подразделений оказываются отне­ сенными к определенным бизнес-процессам.

Еще раз подчеркнем, что бизнес-процессы организации, представ­ ленные на рис. 3.21 в виде плоских процессов, на самом деле объемные.

Попытка отобразить их «объемность» показана на рис. 3.22.

Шаг 7. Сформировать матрицы ответственности по каждому под­ разделению. На основе этих матриц составить матрицы ответствен­ ности бизнес-процессов организации (см. рис. 3.23).

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

Рис. 3.21. Метод 2. Шаг 6. Формирование бизнес-процессов организации из бизнес-процессов подразделений Рис. 3.22. Объемные бизнес-процессы Один из «объемных» бизнес-процессов организации в целом Глава 3. Описание и анализ бизнес-процессов Рис. 3.23. Метод 2. Шаг 7. Формирование матриц ответственности по бизнес-процессам Матрица ответственности бизнес-процесса Итак, методология 2 (полная) позволяет детально описать де­ на основе информационных и материальных потоков и однозначно связывая функции подразделений с процессами. При использовании методологии 2 не должно быть «потерянных», то есть не вошедших ни в один бизнес-процесс функций. Таким образом, все функции организации оказываются привязанными к конкретным бизнеспроцессам. Бизнес-процессы формируются не субъективным об­ разом, а на основе реальных потоков информации и материальных ресурсов между подразделениями.

К недостаткам данного метода можно отнести:

— высокую трудоемкость применения метода для средних — значительную длительность описания (8-12 месяцев);

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

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

3.2.3.Сравнительный анализ подходов: преимущества и недостатки Обе рассмотренные выше методологии описания бизнес-процессов не лишены недостатков. В табл. 3.3 приводится сравнение данных методологий.

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

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

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

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

Табл. 3.3. Сравнение методологий описания процессов Критерий сравнения Степень субъективности 2 Полнота описания деятель­Фрагментарное описание ности организации 3 Длительность выполнения 4 Корректность полученных Степень участия руководи­ телей и сотрудников органи­ 6 Трудоемкость выполнения 7 Степень риска неудачи про­ екта (при наличии поддерж­ 8 Степень риска неудачи про­ екта (при отсутствии под­ держки руководства) Возможность использова­ ния результатов проекта (полученной информации Длительность выполнения проекта. Метод 1 предполагает, что работы по описанию процессов должны быть выполнены в течение двух-трех месяцев. Метод 2 изначально ориентирован на более де­ тальную, тщательную работу и, соответственно, большие сроки — 6-12 месяцев.

ускоренного метода описания являются низкое качество и недо­ факт обусловлен как особенностями самого метода, так и малыми 186 11ро цесси ы й п од ход к у правде} ш ю. Мо делироваиие бизиес-процес со в сроками выполнения проекта. Полный метод дает более достовер­ ную картину процессов. Следует отметить, что корректность по­ лучаемых моделей должна контролироваться и в том и в другом Степень участия персонала организации в проекте. При мето­ де 1 предполагается, что руководители и сотрудники предприятия в основном предоставляют информацию о процессах, а большую часть работы по формированию моделей выполняет рабочая груп­ па (возможно, состоящая из внешних консультантов). Она же за­ нимается проверкой корректности моделей процессов и анали­ зом проблем. Таким образом, основной акцент в проекте делается на деятельность рабочей группы. К сожалению, часто на практи­ ке ее состав формируется по остаточному принципу, то есть в нее включают сотрудников, наименее ценных для реальной работы под­ разделений. Такой подход неизбежно приводит к трудностям при выполнении проекта и низкому качеству полученного комплекта моделей бизнес-процессов. Наоборот, при использовании метода делается акцент на участие большого числа руководителей и сотруд­ ников предприятия в проекте. Например, описание деятельности подразделения, составление блок-схем процессов, формирование рабочих документов (положения о подразделении, инструкций) вы­ полняется непосредственно руководителями подразделений и их подчиненными. Рабочая группа руководит данным процессом, обучает персонал, разрабатывает методические материалы, про­ веряет и корректирует результаты работы и т. п. Подчеркнем, что в методе 2 отводится очень большое значение роли руководителей верхнего уровня в проекте.

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

Степень риска неудачи проекта. Если руководство не участву­ ет в проекте или участвует формально, то риск неудачного выпол­ нения проекта для метода 1 очень высок — 80-100%. Для метода Глава 3. Описание и анализ бизнес-процессов отсутствие внимания и заинтересованности руководства также яв­ ляется критическим фактором успеха. Но в этом случае полученные результаты могут быть использованы хоты бы формально в виде по­ ложений о подразделениях и т. д. При поддержке руководства и ис­ пользовании метода 1 можно добиться хороших результатов, но сте­ пень их практического использования все-таки будет невысокой.

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

Возможность использования результатов проекта. Поскольку метод 1 описывает бизнес-процессы организации фрагментарно, то и практическое использование результатов проекта возможно, как правило, лишь на 30-40%. Для практического использования ин­ формации, оставшейся в моделях, потребуется описать соседние, не описанные процессы, распределить оставшиеся функции подраз­ делений и т. д. Согласно методу 2, работа изначально ориентирова­ на на получение практически применимых результатов, например в виде процессной документации. Поэтому степень практического использования результатов проекта, выполненного по методу 2, су­ щественно выше.

В заключение раздела по сравнению методов отметим, что методология 2 является существенно более структурированной, чем методология 1. Результаты, полученные по методологии 2, бо­ лее прозрачны для руководителей организации и подразделений.

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

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

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

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

Основную работу на подготовительном этапе выполняет руково­ дитель проекта и рабочая группа при активном участии руководите­ лей предприятия.

Длительность подготовительного этапа может составлять от 2 не­ дель до 2 месяцев в зависимости от масштабов проекта и численно­ сти организации.

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

— диагностика проблем предприятия;

— определение перечня основных бизнес-процессов;

— определение и ранжирование целей проекта;

— выбор (разработка) и утверждение методики ведения проек­ та, включая методику моделирования бизнес-процессов;

— подготовка программного и аппаратного обеспечения;

— формирование рабочих групп;

— методическая подготовка: обучение руководителей и специа­ — информирование персонала о задачах проекта;

— детальное планирование работ.

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

Последовательность выполнения работ на подготовительном эта­ пе показана на рис. 3. 24.

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

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

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

Рис. 3.24. Последовательность работ, осуществляемых на подготовительном этапе проекта Руководитель проекта создает рабочую группу, отбирая сотруд­ ников подразделений по определенным требованиям.

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

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

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

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

1. Управление организацией:

1.1. Методы структурного и бесструктурного управления си­ 1.2. Система глубинных знаний доктора Э. Деминга.

1.3. Методы стратегического управления (в том числе BSC).

1.4. Методы разработки бизнес-плана компании.

1.5. Типы и характеристики организационных структур, ме­ тоды проектирования и оптимизации организационных 1.6. Методы построения бизнес-модели компании.

2. Процессный подход к управлению:

2.1. Принципы процессного подхода.

2.3. Метод определения границ процесса (ресурсы, события, Глава 3. Описание и анализ бизнес-процессов 2.4. Методы разработки показателей (метрик) для управления 2.5. Метод разработки системы (сети, архитектуры) бизнес-про­ 2.6. Методы и формы регламентации процессов (типовые фор­ мы нормативно-методических документов, организация 2.7. Принципы и методы оперативного управления процесса­ ми (в том числе определение контрольных точек, разработ­ ка процедур мониторинга процессов, выполнения коррек­ 2.9. Метод нормирования операций процессов и расчета тре­ 3. Моделирование бизнес-процессов:

3.1. Методы построения структурных моделей процессов.

3.2. Методы построения схем цепочек создания ценности.

3.3. Метод построения операционных моделей процессов 3.4. Метод построения моделей потоков данных.

3.5. Нотации IDEFO, IDEF3, IDEF1X, ARIS VAD, ARIS еЕРС, 3.6. Метод сбора и обработки первичной информации (в том 3.7. Метод управления проектом описания бизнес-процессов.

3.8. Метод разработки процессов to be на основе требований.

4. Регламентация бизнес-процессов:

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

4.4. Разработка положений о подразделении и должностных 5. Аналитические методы:

5.1. Метод проведения мозгового штурма.

5.2. Методы построения контрольных карт Шухарта.

5.3. Методы построения диаграммы Парето и Исикавы.

5.4. Методы выявления и анализа потерь при выполнении про­ 5.5. Методы построения графиков, анализа трендов, расчета 6. Управление проектами:

6.1. Методы управления проектами организационного развития.

6.2. Методы управления инвестиционными проектами.

6.3. Метод внедрения процессного подхода к управлению.

7. Менеджмент качества:

7.1. Требования стандартов ИСО 9000.

7.2. Методы и формы разработки документации СМК.

7.3. Метод построения и анализа функции потерь Тагути.

8. Информационные системы:

8.1. Системы для моделирования бизнес-процессов (BPWin, ARIS Toolset, CaseWise, Business Studio и т. д.).

8.2. ВРМ-системы.

8.3. ERP-системы (архитектура, принципы работы).

8.4. Системы электронного документооборота.

8.5. Разработка требований к информационной системе.

9. Финансы и экономика:

9.1. Микроэкономика (в том числе маржинальный анализ).

9.2. Метод построения и анализа финансово-экономических Глава 3. Описание и анализ бизнес-процессов 93. Метод анализа и контроля затрат по бизнес-процессам.

9.4. Методы оценки стоимости компании.

10. Аудит бизнес-процессов:

10.1. Метод организации системы аудита бизнес-процессов.

10.2. Метод проведения аудита бизнес-процесса и формирова­ 11. Взаимодействие с внешними консультантами:

11.1. Метод постановки задачи консультантам.

11.2. Метод контроля качества работ/услуг внешних консуль­ 11.3. Метод выполнения функции единого заказчика по про­ 12. Методы управления рисками:

12.1. Метод выявления и оценки рисков.

12.2. Метод разработки мероприятий по минимизации рисков.

13. Психология межличностного общения.

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

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

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

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

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

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

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

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

Попытки проводить совещания группы внутри подразделений при­ ведут к отвлечению других сотрудников и т. д.

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

Итогом подготовительного этапа является готовность организа­ ции к проекту, как показано в табл. 3.4.

Табл. 3.4. Критерии готовности организации к проекту описания бизнес-процессов Структурированная спецификация целей проекта, Детальное техническое задание, 20-50 страниц Методика ведения проекта, 80-150 страниц Календарный план работ, 5-10 страниц Инструментальная среда моделирования Инфраструктура (помещения, аппаратное обеспечение) Глава 3. Описание и анализ биз}1ес-процессов Критерий готовности 7 Документы, регламентирующие деятельность рабочей 8 Обучение рабочей группы 9 Обучение руководителей верхнего уровня 10 Обучение руководителей среднего уровня И Обучение руководителей и специалистов подразделений 12 Информирование персонала К проекту можно приступать, когда получены результаты табл. 3.4. Далее по ходу проекта не полностью выполненные работы будут закончены.

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

3.3.2. Требования по управлению проектом.

Роли сотрудников в проекте Требования куправлению проектом моделирования бизнес-процессов соответствуют стандартным требованиям проектного управления [1].

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

— мотивацию персонала организации, демонстрирование лич­ ной заинтересованности в проекте;

— участие в постановочных совещаниях рабочей группы;

— оперативный анализ разрабатываемых материалов;

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

— поэтапный контроль выполнения проекта;

— анализ и перераспределение функций подразделений, ответ­ ственности и полномочий руководителей, ресурсов на основе результатов проекта;

— обеспечение рабочей группы необходимыми ресурсами.

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

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

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

Структура управления проектом представлена на рис. 3.25.

Рис. 3.25. Структура управления проектом Глава 3. Описание и анализ бизнес-процессов Руководитель проекта подчиняется непосредственно руководите­ лю организации. Именно поэтому на схеме он вынесен на один уро­ вень с владельцем процесса — руководителем крупного структурного подразделения. В крупных организациях власть и возможности ру­ ководителя проекта несопоставимы с возможностями руководителя крупного подразделения. Поэтому в таких проектах целесообразно вводить роль куратора проекта — руководителя уровня заместителя директора или приближенного к нему советника. В этом случае вза­ имодействие руководителя проекта с руководителями структурных подразделений осуществляется при участии куратора, что в некото­ рой степени гарантирует возможность плодотворной коммуникации между руководителем проекта и начальником структурного подразде­ ления, а это способствует успешному выполнению работ по проекту.

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

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

В процессе выполнения проекта участники рабочей группы мо­ гут играть различные роли:

— заказчик — руководитель предприятия, владелец процесса;

— руководитель проекта — сотрудник, ответственный за пол­ ноту и корректность описания бизнеса при помощи моделей бизнес-процессов;

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

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

— рецензент — руководитель/специалист организации либо внешний привлеченный эксперт, являющийся специалистом в предметной области, отвечающий за анализ переданных ему на рассмотрение моделей бизнес-процессов;

— ответственный за формирование архива — участник рабочей группы, ответственный за сбор, обработку и хранение доку­ ментации по проекту (одна из основных функций — архиви­ рование подшивок моделей бизнес-процессов, используемых при рецензировании/проверке адекватности).

Далее при описании процессов формирования моделей процес­ сов будут подробно освещены указанные выше роли.

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

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