Построение системы процессов в среде Business Studio
В.В. Репин, к.т.н., доцент
Исполнительный директор ООО "BPM Консалтинг Групп", зав. кафедрой Управления бизнес-процессами НОУ ВПО "ИЭФ "Синергия", основатель портала http://www.finexpert.ru/
20.09.2010 г.
В статье обсуждаются вопросы построения системы бизнес-процессов организации и ее использования в среде моделирования процессов. Представлен пример системы процессов торговой компании, созданной в среде моделирования Business Studio.
Предполагается, что подход автора статьи вызовет интересную и полезную в практическом отношении дискуссию специалистов по бизнес-моделированию.
Методика построения системы процессов компании
В данном разделе представлен авторский взгляд на построение в компании системы (архитектуры) процессов.
Подход к построению системы процессов организации можно сравнить с собиранием пазла. Для того, что собрать картинку из большого количества разрозненных элементов нужно:
- визуально представить себе готовую картинку в целом (обычно она приводится на коробке к пазлу);
- терпеливо отбирать и складывать нужные элементы между собой.
Очевидно, что в случае потери общей картинки задача сборки элементов пазла существенно усложняется.
Переводя эту аналогию на язык бизнес-моделирования можно сказать, что:
- общая картинка пазла – это системное понимание процессов бизнеса на верхнем уровне, и
- отдельные детальные элементы – это деятельность на среднем и нижнем уровне, выполняемая структурными подразделениями организации.
Один из возможных алгоритмов построения системы процессов организации представлен на рис 1.
Рис. 1. Алгоритм построения системы процессов организации.
На первом шаге осуществляется разработка модели процессов организации на верхнем уровне. Цель создания модели – понимание того, как устроен бизнес организации. Рекомендуется создавать эту модель, используя принципы определения и построения схем цепочек создания ценности (ЦСЦ). Формируемая модель является структурной. Ее назначение – системно показать процессы компании на верхнем уровне и основные, наиболее важные связи между ними. Для создания структурной модели можно использовать любую, понятную и удобную бизнес-аналитикам нотацию (в т.ч. IDEF0 и т.п.). Главное, чтобы эта нотация соответствовала поставленной задаче. Для создания структурной модели можно использовать MS Visio, как наиболее доступный инструмент. На крайний случай, можно нарисовать модель на бумаге.
На шаге 2 осуществляется анализ деятельности структурных подразделений, выявление и структурирование процессов, которые в них выполняются. В случае, если позволяют человеческие ресурсы, шаги 1 и 2 можно выполнять одновременно. Заметим, что информация о процессах подразделений представляется в табличной форме (в MS Excel).
После получения видения процессов организации в целом (структурная модель процессов на верхнем уровне) и информации по процессам структурных подразделений на шаге 3 формируется первая версия системы процессов организации. Она представляет собой таблицу в MS Excel, включающую несколько столбцов:
- номер процесса;
- наименование процесса;
- ответственный за выполнение процесса руководитель;
- участники;
- входы;
- инициирующие события;
- выходы;
- завершающие события.
Заметим, что схемы ЦСЦ являются промежуточным, рабочим материалом, необходимым для понимания бизнеса в целом и создания основы, «скелета» системы процессов. Но результат работы (система процессов) представляется в табличной форме.
На шаге 4 выполняется согласование границ процессов по входам/выходам и инициирующим/завершающим событиям. Это довольно длительный и затратный с точки зрения вовлечения человеческих ресурсов этап, но он позволяет сделать систему более адекватной. Как правило, при согласовании входов/выходов структура процессов несколько изменяется. Обратим внимание, что для процессов 1 и 2 уровня нужно согласовывать только границы ответственности руководителей на уровне решаемых задач, достигаемых целей и т.п. «Стыковка» на уровне реальных рабочих документов выполняется на 3 и 4 уровнях.
По итогам выполнения этого шага формируется вторая версия системы процессов организации. Уточняются должности руководителей, ответственных за выполнение процессов, и состав участников на уровне подразделений и должностей сотрудников.
На шаге 5 осуществляется согласование системы процессов. Результатом является третья, согласованная версия системы процессов. Она является рабочей и используется на следующих этапах проекта внедрения процессного подхода.
Обычно для разработки адекватной бизнесу системы процессов требуется не менее 3-4 итераций. Для компании среднего размера (численность 1000-1500 человек, 100-150 сотрудников руководящего состава) такая работа занимает около 2 месяцев.
Важно, чтобы работу по формированию системы процессов организации выполняли квалифицированные бизнес-аналитики или внешние консультанты. Возможен вариант организации совместной команды. Нежелательно поручать такую важную задачу, как построение системы процессов организации, малоопытным и недостаточно компетентным сотрудникам.
Использование отраслевых решений и материалов других компаний
На практике при построении системы процессов могут использоваться:
- информация по структуре процессов других компаний, работающих в той же отрасли;
- опыт экспертов по выделению и описанию процессов в аналогичных компаниях;
- отраслевые референтные модели разного типа, подходящие для контекста решаемой задачи (например, отраслевая модель APQC).
Если в команде проекта есть эксперты, владеющие указанной выше информацией, то построение системы процессов организации можно выполнять, не разрабатывая схемы цепочек создания ценности (т.е. не формируя структурную графическую модель верхнего уровня). Дело в том, что у таких экспертов уже есть видение того, как работает бизнес, и понимание, как можно структурировать процессы для компаний данной отрасли.
В этом случае берется материал, наработанный в другой компании. Далее он корректируется и уточняется с использованием информации о процессах структурных подразделений рассматриваемой организации.
Необходимость графической модели процессов на верхнем уровне
Отдельно стоит обсудить, насколько полезны графические модели процессов для построения системы процессов. Например, с точки зрения автора, ошибкой является попытка построения многоуровневой системы процессов организации в одной модели IDEF0 (или другой нотации). Если соблюдать формальные правила, то в такой модели может получиться 7-8 уровней декомпозиции. Но реальную ценность для последующего описания и регламентации имеет всего 1-2 нижних уровня, где выполнятся конкретные операции процессов и осуществляется реальный документооборот! Именно на этих уровнях процессы могут быть описаны в формате Work Flow (поток работ), и при помощи этих описаний сформированы регламенты работы сотрудников («регламент процесса», «инструкция по выполнению процесса» и т.п.).
Можно сказать, что структурная модель верхнего уровня нужна:
- бизнес-аналитикам для понимания деятельности организации и создания адекватной системы процессов (в первую очередь, для корректного перехода к процессам уровня Work Flow – «регламентируемым» или «автоматически исполняемым» в BPMS процессам);
- руководителям, которым такая модель нужна для анализа и совершенствования архитектуры бизнеса.
Заметим, что руководители компаний, которые умеют и хотят работать со структурной графической моделью процессов верхнего уровня, на практике встречаются исключительно редко.
Пример построения системы процессов торговой компании
В одной из торговых компаний был инициирован проект построения системы бизнес-процессов. Поскольку в отдел организационного развития (название изменено) входили квалифицированные и опытные бизнес-аналитики, было решено не разрабатывать цепочки создания ценности, а воспользоваться существующими наработками (специалистов компании и автора статьи). На рис. 2, например, представлена схема ЦСЦ для торговой компании в максимально агрегированном виде.
Рис. 2. ЦСЦ торговой компании.
Данная схема не полностью соответствовала реальности рассматриваемой компании. Ее использовали только в качестве основы для дальнейшего обсуждения структуры процессов на верхнем уровне. Кроме схемы, была использована система процессов другой торговой компании. Также был учтен опыт работы бизнес-аналитиков в других компаниях аналогичного профиля.
В результате обсуждения появилась первая версия системы процессов компании. Ее фрагмент представлен на рис. 3.
Рис. 3. Первая версия системы процессов торговой компании.
На рисунке видно, что уровень «подпроцессов» и «операций» не заполнен. Определены только «группы процессов» и «процессы».
После получения первой версии системы, бизнес-аналитики провели серию совещаний с руководителями подразделений, в ходе которых уточнялась структура процессов и определялись подпроцессы. В некоторых случаях, удалось сразу дойти до уровня операций.
В результате анализа процессов структурных подразделений компании, была разработана вторая версия системы процессов. Затем были уточнены ответственные и участники процессов.
В результате ряда обсуждений, корректировок и согласований была получена четвертая версия системы бизнес-процессов, часть которой показана на рис. 4.
Рис. 4. Четвертая версия системы процессов торговой компании.
Было принято решения описывать на отдельных листах MS Excel процессы:
- центрального офиса (индекс – ЦО);
- распределительного центра (индекс – РЦ);
- типового универсама (индекс – УН).
Засчет такого решения удалось сократить количество процессных групп на каждом листе MS Excel и уйти от создания в системе «псевдо-процессов». Например, если бы деятельность типового универсама описали в общей системе процессов, то возникла бы процессная группа под названием «Процесс универсама». Фактически, это означало бы, что появлялся лишний, практически ненужный уровень декомпозиции. Кроме того, такое представление системы процессов удобно для согласования – можно согласовывать документ по частям. Заметим, что некоторые специалисты предпочитают создавать систему процессов на одном листе.
Создание системы процессов в Business Studio
После того, как система процессов была создана и согласована в виде файла MS Excel, было принято решение перенести ее в среду моделирования Business Studio. Данные были предварительно обработаны и загружены в Business Studio. Это легко можно сделать путем пакетного импорта из файла MS Excel. Результат (дерево процессов) представлен на рис. 5.
Рис. 5. Система процессов торговой компании в Business Studio.
Были созданы три папки: «Процессы ЦО», «Процессы РЦ» и «Процессы УН». Внутри этих папок процессы имеют 4-уровневую структуру. Четвертый уровень – это уровень операций, выполняемых конкретными сотрудниками подразделений.
На рис. 6. показан пример описания одного из операционных процессов в нотации «Процедура» Business Studio.
Заметим, что в данном проекте стыковка процессов по входам/выходам в файле MS Excel не осуществлялась. Это решено было делать при последовательном описании и согласовании схем процессов 3 или 4 уровня в Business Studio.
Рис. 6. Описание процессов в нотации «Процедура».
Для того, чтобы можно было моделировать процессы, используя существующие названия подразделений и должностей, в среде Business Studio была описана схема организационной структуры компании. Поскольку она была довольно сложной, пришлось создавать модель на нескольких уровнях (см. рис. 7 и 8).
Рис. 7. Описание организационной структуры компании в Business Studio.
Рис. 8. Описание организационной структуры подразделения компании в Business Studio.
После описания ряда пилотных процессов, был разработан отчет, выводящий информацию о процессах в нужном компании виде – «Инструкции по выполнению процесса». Данный документ предназначался для регламентации деятельности конкретных сотрудников компании на операционном уровне.
Заключение
Еще раз обратим внимание на систему процессов в среде моделирования Business Studio, представленную на рис. 5. Важно, что описание процессов в такой системе можно начинать с третьего или, лучше, с четвертого уровня – там, где есть реальный документооборот. Это означает, что процессы первого и второго уровня вообще можно не описывать! В этом случае исключаются значительные затраты времени на моделирование и согласование «неисполняемых» (в BPMS) и «нерегламентируемых» (слишком общие для этой цели) «процессов» 1 и 2 уровня.
Возможно, такой подход вызовет критику со стороны некоторых системных аналитиков. Но, с точки зрения автора статьи, создание «системных» графических моделей верхнего уровня, непонятных и ненужных руководителям и сотрудникам организации, не является лучшей альтернативой с практической точки зрения.
Поставить оценку статье, задать вопрос авторам
