Определение системы процессов организации

В этой главе я использую термины «система процессов» и «архитектура процессов» в качестве синонимов.
Описание системы процессов организации означает создание модели, в которой в структурированном виде представлена информация обо всех процессах организации.
Построение системы процессов не означает комплексного описания процедур (алгоритмов) выполнения всех процессов на всех уровнях управления, то есть создания так называемой комплексной модели процессов. Речь здесь идет только о дереве процессов. Для компании среднего размера можно разработать систему процессов за два-три месяца, в то время как описание всех процессов на операционном уровне займет несколько лет (в зависимости от количества выделенных ресурсов), что нецелесообразно. Описывать нужно только те процессы, которые предполагается оптимизировать и регламентировать.
Система процессов может быть описана в файле MS Excel или в виде специального справочника в инструментальном средстве моделирования процессов^[72].

Пример. Система процессов торгово-производственной компании представлена в виде графической схемы на рис. 3.1.1. Эта компания занимается производством и реализацией промышленной продукции.

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

1. Процессная категория (1-й уровень).
1.1. Процессная группа (2-й уровень).
1.1.1. Процесс (3-й уровень).
1.1.1.1. Операционный процесс (4-й уровень).
1.1.1.1.1. Операция (5-й уровень).
1.1.1.1.1.1. Транзакция (6-й уровень).

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

_{Таблица 3.1.1. Определения уровней деятельности в системе процессов организации}

_{Рис. 3.1.1. Пример представления системы процессов организации в виде графической схемы}

Система процессов может строиться сразу в виде иерархического справочника процессов. Другой возможный вариант – описание модели деятельности компании на верхнем уровне в некоторой нотации с последующим представлением в виде иерархического справочника. Если речь идет о построении системы процессов для действующей организации, то, с моей точки зрения, полезно разрабатывать систему процессов сразу в виде справочника, не формируя графическую модель верхнего уровня. Форма справочника более понятна большинству руководителей. Далеко не все топ-менеджеры могут воспринимать сложные графические модели структурного типа (например, в нотации IDEF0^[73]).
После того как система процессов в виде иерархического справочника построена, при необходимости могут быть созданы модели деятельности в виде графических схем. На уровнях 1–3 целесообразно использовать структурные типы моделей (например, IDEF0). С уровня 4 (для небольших компаний – с уровня 3), как правило, описание выполняют при помощи схем в формате Work Flow. Удобный способ их визуального представления – кросс-функциональные схемы, содержащие дорожки. На каждой дорожке указываются операции, выполняемые подразделениями/сотрудниками/бизнес-ролями. Пример: «начальник отдела продаж» – сотрудник, «инициатор договора» – бизнес-роль. Подробно методики описания графических схем в формате Work Flow рассмотрены в главе 4.

Пример. Аналогия с техническим устройством
Рассмотрим внутреннее устройство электронного прибора. В нем есть печатные платы с элементами, микросхемы, блок питания, жгуты проводов и т. п. Жгуты (шлейфы) состоят из нескольких проводков. Каждый проводок – проводник определенного, вполне конкретного электрического сигнала. Для работы устройства необходимо, чтобы конкретные провода были присоединены к конкретным элементам. В результате создается корректно работающая электрическая схема.
Аналогия с организацией следующая. Проводки – это потоки документов (информации) и материальных ресурсов, возникающие при выполнении процессов. Эти потоки являются конкретными – каждый документ выходит из одной операции процесса и входит в другую. Как можно объединить несколько потоков в один? В электрическом приборе это проводки, скрученные в жгуты (шлейфы). Они могут быть разного цвета и формы. Как именно отдельные проводки собраны в жгуты (шлейфы), определяет разработчик электронного прибора (инженер). Конструкция прибора может быть совершенно разная.
Так и в компании. При создании модели верхнего уровня объединение потоков и агрегирование операций процессов остается на совести бизнес-аналитика. Сделать это можно по-разному. Если при создании электронных приборов действуют хотя бы некоторые стандарты, то при создании системы процессов организации таких стандартов фактически нет^[74]. Есть только нотации для создания графических схем и некоторое ви́ дение типовой структуры категорий процессов на верхнем уровне («Продажи», «Производство», «Закупка»…). Но что получится в результате моделирования, очень зависит от компетенции и опыта бизнес-аналитика.
Обратим внимание на тот факт, что реальная жизнь начинается на уровне операционных процессов там, где возникает реальный документооборот (информационные потоки). Модели верхнего уровня – это некоторая абстракция, «дизайн» системы, который может быть выполнен по-разному. Поэтому ценность модели верхнего уровня определяется возможностью ее использования для оптимизации бизнес-модели организации, назначения зон ответственности руководителей и т. д.
Если модель организации на верхнем и среднем уровнях выполнена некорректно, то ее невозможно использовать на практике. Далеко не в каждой организации найдется опытный бизнес-аналитик, способный построить модель верхнего уровня, действительно имеющую ценность для управления.
Для уже действующих организаций можно ограничиться иерархическим перечнем процессов, а описание процессов в виде графических схем выполнять только на операционном уровне – уровне реального документооборота и потоков информации. Важно, чтобы практика определяла требования к модели, а не формализованная нотация ограничивала реальную практику бизнеса.

Пример. Согласно требованиям стандарта IDEF0 на схеме не может быть более 8 объектов деятельности (подпроцессов). Но в реальности часто требуется показывать большее число подпроцессов. Что делать в случае, если на схеме IDEF0 показано 12 подпроцессов? Создавать 3 отдельные модели по 5 + 4 + 3 подпроцесса в каждой? Агрегировать 12 подпроцессов на 3 подпроцесса («основные», «вспомогательные», «управленческие») с последующей декомпозицией? Однозначного ответа нет.

Как правило, на уровне операционных процессов в системе процессов компании определяются и согласуются между собой входы/выходы процессов. Вопрос определения и согласования входов/выходов не такой простой, как кажется. Дело в том, что определение входов/выходов – весьма неоднозначная и ресурсоемкая задача. Если есть уверенность в том, что система процессов построена адекватно (а это зависит от методики и опыта бизнес-аналитиков), то входы/выходы могут быть корректно определены уже на следующем этапе – описания бизнес-процессов. Конечно, при этом в систему придется вносить некоторые изменения. Но система процессов – не застывшая, а живая, развивающаяся модель деятельности организации. Поэтому не стоит бояться вносить в нее изменения. Важно определить и регламентировать правила их внесения.
Для описания системы процессов организации можно использовать MS Excel (мне известны примеры крупных компаний, которые поддерживают репозиторий процессов в этой программе).
Форма представления системы процессов в MS Excel показана на рис. 3.1.2. Каждая процессная категория находится на отдельном листе файла.

_{Рис. 3.1.2. Представление системы процессов в виде таблицы MS Excel}

Пример. Модель процессов APQC
Обращаю внимание читателя на созданный американской компанией APQC (American Productivity and Quality Center) «Общий классификатор процессов для различных отраслей» (Cross Industry Process Classification Framework^[75]). Он постоянно корректируется, дополняется новыми процессами. Структура процессов в классификаторе APQC включает 12 категорий, каждая из которых описана на отдельном листе в файле MS Excel. Этот справочник интересен как пример создания сложной системы процессов современной организации. Недостаток справочника – его сложность и всеохватность, из-за которой его трудно применять для внедрения процессного подхода в конкретной компании.

При формировании дерева процессов и описании его в виде таблицы (рис. 3.1.2) возникает вопрос – как правильно показывать входы/выходы для процессов? Для нижнего уровня (четвертого и, возможно, третьего) ответ очень прост: следует описывать конкретные документы (бумажные, электронные) и материальные потоки. Но что делать при описании входов/выходов для процессов верхнего уровня (первый-второй, иногда^[76] третий)? Существует как минимум три основных варианта:
1. Агрегировать информационные и материальные потоки и показывать их в обобщенном виде, соответствующем уровню процессов.
2. Не показывать входы/выходы на тех уровнях процессов, где нужно делать агрегирование (то есть там, где невозможно или слишком сложно показывать потоки реальных документов/материалов).
3. Дублировать описание входов/выходов в виде списка, повторяя все входы/выходы, определенные для процессов нижних уровней.

Первый вариант предполагает, что бизнес-аналитики, проектирующие систему процессов организации, достаточно квалифицированны, чтобы выполнять декомпозицию/агрегирование как процессов, так и потоков ресурсов (информационных и материальных). Если в этом есть сомнения, то лучше оставлять ячейки с описанием входов/выходов для процессов верхнего уровня пустыми (вариант 2), заполняя их только для детальных процессов конкретными наименованиями документов/материалов. Третий вариант – наименее удобный, так как ведет к дублированию большого количества информации в таблице и усложнению ее восприятия.
Заполнение таблицы процессов вида 3.1.2 в MS Excel сопряжено с существенными затратами рабочего времени. Ее лучше всего использовать на начальной стадии проекта внедрения процессного подхода, пока нет возможности применить более эффективные инструменты (например, среду моделирования процессов). Перенос системы процессов из таблицы в среду моделирования требует незначительных трудозатрат.

Пример. Справочник процессов в среде бизнес-моделирования
При выполнении проекта была разработана система процессов в файле MS Excel. Для последующего моделирования процессов использовалась среда Business Studio. При помощи разработки и использования так называемого пакета импорта процессное дерево было импортировано в базу Business Studio, что исключило необходимость повторного ручного ввода информации о структуре процессов.

На первых стадиях внедрения процессного управления использование таблицы в MS Excel – самый простой и удобный вариант. Для небольших компаний дерево процессов в MS Excel вполне может использоваться постоянно, без переноса в какую-либо другую систему.

3.2. Цели разработки системы процессов организации

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

Пример. Один из крупнейших российских холдингов в конце 2011 года инициировал проект создания так называемого автоматизированного репозитория бизнес-процессов. Речь шла о создании архитектуры процессов для всех компаний холдинга с последующим постепенным описанием, регламентацией и частичной автоматизацией бизнес-процессов. Модели процессов, хранящиеся в репозитории, по сути, должны представлять собой базу знаний о деятельности организации. Их можно использовать для различных целей: анализа, регламентации, накопления данных по показателям процессов, привязки различной документации (нормативно-справочные документы, описания успешно реализованных проектов оптимизации, результаты аудитов и т. д.). Ряд моделей из репозитория могут использоваться для автоматизации.
Масштаб компании определяет сложность архитектуры бизнес-процессов, которая должна быть разработана, и ресурсы (персонал, программное обеспечение, серверы и т. п.), необходимые для решения этой задачи.

Пример. В одной из крупных частных компаний (производитель снеков) реализовали проект по созданию архитектуры бизнес-процессов. Частично был выполнен так называемый маппинг с APQC – сравнение между собой двух моделей процессов за счет наложения одной на другую. При разработке системы процессов преследовались следующие цели, согласованные руководством компании:
• создать уникальную процессную модель «ХХХ», которая бы за счет наличия четких связей с моделями APQC, CBM (Component Business Model), SAP, DocsVision, СМК (система менеджмента качества) и реестром нормативных документов компании обеспечивала возможность:
– осуществлять расширение бизнеса (как в России, так и в странах СНГ) за счет передачи знаний о процессах, используемых средствах автоматизации и соответствующих регламентирующих документах;
– системно осуществлять описание и регламентацию бизнес-процессов компании с использованием системы Business Studio 3.6;
– создавать систему управления знаниями о деятельности компании.
Одна из неформальных целей разработки системы процессов заключалась в снижении зависимости от конкретных личностей – их субъективного ви́ дения состава и границ процессов, которые нужно выполнять для поддержания стабильного состояния и развития бизнеса.

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

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

Построение системы процессов организации означает упорядочение ее деятельности в виде процессов. Древовидная структура процессов и согласованные границы позволяют четко определить зоны ответственности руководителей на всех уровнях управления, исключить зоны безответственности и зоны размытой ответственности (пересечения ответственности). Четкое определение зон ответственности руководителей позволяет организовать оперативное управление процессами, не дожидаясь их подробного описания и регламентации. Сказанное иллюстрирует рис. 3.2.1. В ситуации 1 процессы не выделены и не управляются. В ситуации 2 процессы выделены, границы процессов четко определены, руководители приступили к организации управления процессами на основе системы показателей. В ситуации 3 процессы регламентированы, оперативно управляются и совершенствуются на основе цикла PDCA.

_{Рис. 3.2.1. Упорядочение деятельности организации в виде процессов}

Управление процессами означает, что для каждого из них разработаны и используются показатели. Если не создать систему процессов, то не к чему будет привязывать эти показатели (не будет идентифицированных объектов управления)^[77]. Если система процессов будет построена некорректно (например, состав и границы выделенных процессов окажутся неадекватны реальной деятельности^[78]), то организация управления такими «процессами» – бессмысленное занятие. Поэтому корректно построенная система процессов – это основа для успешного внедрения процессного подхода.
В целом система процессов организации обеспечивает достижение следующих целей:
• упорядочение деятельности организации в виде процессов, анализ существующей организационной структуры и обоснование возможных и целесообразных направлений ее реорганизации;
• организация управления процессами, в том числе создание основы для разработки системы показателей для управления процессами;
• четкое определение зон ответственности руководителей, исключение зон безответственности, зон дублирования ответственности;
• четкое определение границ процессов по входам/выходам и событиям;
• повышение эффективности межфункционального взаимодействия подразделений за счет определения, описания и оптимизации сквозных процессов;
• создание основы для последующего системного описания и регламентации процессов;
• создание основы для успешного внедрения различных средств автоматизации деятельности;
• прочее.

3.3. Различные подходы к построению системы процессов организации

На мой взгляд, методика построения системы процессов – базовая среди всех методик процессного управления. Как разработать систему процессов, адекватно описывающую деятельность компании? В российской практике я сталкивался со следующими подходами:
• структурный подход;
• продуктовый подход;
• подход «блюдо спагетти»;
• CBM IBM (Component Business Model компании IBM);
• методика построения системы процессов на основе анализа модели цепочек создания ценности (ЦСЦ);
• смешанные подходы.
Рассмотрим каждый из указанных подходов подробнее.