Шрифт:
Таблица 3.1.1. Определения уровней деятельности в системе процессов организации
Рис. 3.1.1. Пример представления системы процессов организации в виде графической схемы
Система процессов может строиться сразу в виде иерархического справочника процессов. Другой возможный вариант – описание модели деятельности компании на верхнем уровне в некоторой нотации с последующим представлением в виде иерархического справочника. Если речь идет о построении системы процессов для действующей организации, то, с моей точки зрения, полезно разрабатывать систему процессов сразу в виде справочника, не формируя графическую модель верхнего уровня. Форма справочника более понятна большинству руководителей. Далеко не все топ-менеджеры могут воспринимать сложные графические модели структурного типа (например, в нотации IDEF0 [73] ).
73
IDEF0 (Function Modeling) – методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Прим. ред.
После того как система процессов в виде иерархического справочника построена, при необходимости могут быть созданы модели деятельности в виде графических схем. На уровнях 1–3 целесообразно использовать структурные типы моделей (например, IDEF0). С уровня 4 (для небольших компаний – с уровня 3), как правило, описание выполняют при помощи схем в формате Work Flow. Удобный способ их визуального представления – кросс-функциональные схемы, содержащие дорожки. На каждой дорожке указываются операции, выполняемые подразделениями/сотрудниками/бизнес-ролями. Пример: «начальник отдела продаж» – сотрудник, «инициатор договора» – бизнес-роль. Подробно методики описания графических схем в формате Work Flow рассмотрены в главе 4.
Пример. Аналогия с техническим устройством
Рассмотрим внутреннее устройство электронного прибора. В нем есть печатные платы с элементами, микросхемы, блок питания, жгуты проводов и т. п. Жгуты (шлейфы) состоят из нескольких проводков. Каждый проводок – проводник определенного, вполне конкретного электрического сигнала. Для работы устройства необходимо, чтобы конкретные провода были присоединены к конкретным элементам. В результате создается корректно работающая электрическая схема.
Аналогия с организацией следующая. Проводки – это потоки документов (информации) и материальных ресурсов, возникающие при выполнении процессов. Эти потоки являются конкретными – каждый документ выходит из одной операции процесса и входит в другую. Как можно объединить несколько потоков в один? В электрическом приборе это проводки, скрученные в жгуты (шлейфы). Они могут быть разного цвета и формы. Как именно отдельные проводки собраны в жгуты (шлейфы), определяет разработчик электронного прибора (инженер). Конструкция прибора может быть совершенно разная.
Так и в компании. При создании модели верхнего уровня объединение потоков и агрегирование операций процессов остается на совести бизнес-аналитика. Сделать это можно по-разному. Если при создании электронных приборов действуют хотя бы некоторые стандарты, то при создании системы процессов организации таких стандартов фактически нет [74] . Есть только нотации для создания графических схем и некоторое видение типовой структуры категорий процессов на верхнем уровне («Продажи», «Производство», «Закупка»…). Но что получится в результате моделирования, очень зависит от компетенции и опыта бизнес-аналитика.
Обратим внимание на тот факт, что реальная жизнь начинается на уровне операционных процессов там, где возникает реальный документооборот (информационные потоки). Модели верхнего уровня – это некоторая абстракция, «дизайн» системы, который может быть выполнен по-разному. Поэтому ценность модели верхнего уровня определяется возможностью ее использования для оптимизации бизнес-модели организации, назначения зон ответственности руководителей и т. д.
Если модель организации на верхнем и среднем уровнях выполнена некорректно, то ее невозможно использовать на практике. Далеко не в каждой организации найдется опытный бизнес-аналитик, способный построить модель верхнего уровня, действительно имеющую ценность для управления.
Для уже действующих организаций можно ограничиться иерархическим перечнем процессов, а описание процессов в виде графических схем выполнять только на операционном уровне – уровне реального документооборота и потоков информации. Важно, чтобы практика определяла требования к модели, а не формализованная нотация ограничивала реальную практику бизнеса.
Пример. Согласно требованиям стандарта IDEF0 на схеме не может быть более 8 объектов деятельности (подпроцессов). Но в реальности часто требуется показывать большее число подпроцессов. Что делать в случае, если на схеме IDEF0 показано 12 подпроцессов? Создавать 3 отдельные модели по 5 + 4 + 3 подпроцесса в каждой? Агрегировать 12 подпроцессов на 3 подпроцесса («основные», «вспомогательные», «управленческие») с последующей декомпозицией? Однозначного ответа нет.
74
Есть некоторые отраслевые стандарты на системы процессов (например, eTOM – enhanced Telecom Operations Map – многоуровневая модель бизнес-процессов телекоммуникационной компании; является базой для анализа и проектирования бизнес-процессов в отрасли связи) и типовые перечни процессов (например, модель APQC), но общепризнанного комплексного стандарта проектирования системы процессов организации пока не существует. При применении некоторых существующих общих методических подходов (например, матрицы Захмана) количество разных моделей организации соответствует числу аналитиков, участвовавших в работе.
Как правило, на уровне операционных процессов в системе процессов компании определяются и согласуются между собой входы/выходы процессов. Вопрос определения и согласования входов/выходов не такой простой, как кажется. Дело в том, что определение входов/выходов – весьма неоднозначная и ресурсоемкая задача. Если есть уверенность в том, что система процессов построена адекватно (а это зависит от методики и опыта бизнес-аналитиков), то входы/выходы могут быть корректно определены уже на следующем этапе – описания бизнес-процессов. Конечно, при этом в систему придется вносить некоторые изменения. Но система процессов – не застывшая, а живая, развивающаяся модель деятельности организации. Поэтому не стоит бояться вносить в нее изменения. Важно определить и регламентировать правила их внесения.
Для описания системы процессов организации можно использовать 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. Этот справочник интересен как пример создания сложной системы процессов современной организации. Недостаток справочника – его сложность и всеохватность, из-за которой его трудно применять для внедрения процессного подхода в конкретной компании.
75
Авторский перевод справочника версии 2010 года на русский язык представлен в приложении 1.
При формировании дерева процессов и описании его в виде таблицы (рис. 3.1.2) возникает вопрос – как правильно показывать входы/выходы для процессов? Для нижнего уровня (четвертого и, возможно, третьего) ответ очень прост: следует описывать конкретные документы (бумажные, электронные) и материальные потоки. Но что делать при описании входов/выходов для процессов верхнего уровня (первый-второй, иногда [76] третий)? Существует как минимум три основных варианта:
76
В зависимости от сложности модели и общего количества уровней процессного дерева.
1. Агрегировать информационные и материальные потоки и показывать их в обобщенном виде, соответствующем уровню процессов.
2. Не показывать входы/выходы на тех уровнях процессов, где нужно делать агрегирование (то есть там, где невозможно или слишком сложно показывать потоки реальных документов/материалов).
3. Дублировать описание входов/выходов в виде списка, повторяя все входы/выходы, определенные для процессов нижних уровней.
Первый вариант предполагает, что бизнес-аналитики, проектирующие систему процессов организации, достаточно квалифицированны, чтобы выполнять декомпозицию/агрегирование как процессов, так и потоков ресурсов (информационных и материальных). Если в этом есть сомнения, то лучше оставлять ячейки с описанием входов/выходов для процессов верхнего уровня пустыми (вариант 2), заполняя их только для детальных процессов конкретными наименованиями документов/материалов. Третий вариант – наименее удобный, так как ведет к дублированию большого количества информации в таблице и усложнению ее восприятия.
Заполнение таблицы процессов вида 3.1.2 в MS Excel сопряжено с существенными затратами рабочего времени. Ее лучше всего использовать на начальной стадии проекта внедрения процессного подхода, пока нет возможности применить более эффективные инструменты (например, среду моделирования процессов). Перенос системы процессов из таблицы в среду моделирования требует незначительных трудозатрат.
Пример. Справочник процессов в среде бизнес-моделирования
При выполнении проекта была разработана система процессов в файле MS Excel. Для последующего моделирования процессов использовалась среда Business Studio. При помощи разработки и использования так называемого пакета импорта процессное дерево было импортировано в базу Business Studio, что исключило необходимость повторного ручного ввода информации о структуре процессов.