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