Разработка архитектуры бизнес-процессов компании в Business Studio

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

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

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

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

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

1.4. Иерархическое представление бизнес-процессов

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

Модель не должна быть слишком сложной. Эта сложность может стать препятствием для анализа, обоснования и внедрения изменений.

Обратимся к рис. 3. – на нем показана пирамида. Наверху пирамиды – один синий четырехугольник («Контекстная диаграмма бизнеса»). Он символизирует компанию в целом, как сложную систему. Она состоит из подсистем – так называемых категорий бизнес-процессов. Каждая из категорий декомпозирована на группы процессов (на рисунке, для простоты, показана декомпозиция только одной категории).

Группа процессов, в свою очередь, декомпозирована на процессы, один из которых разделен на операционные процессы.

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

Рис. 3. Иерархия бизнес-процессов в компании.

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

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

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

Бизнес-процессы различных уровней иерархии нужно как-то называть. Можно, например, использовать способ, представленный организацией APQC (American Productivity & Quality Center)[2 - Американский центр производительности и качества.] в так называемой модели Cross Industry Process Classification Framework (PCF). В рамках этой модели определены следующие уровни процессной архитектуры:

Уровень 1 – Категория – представляет наиболее высокий уровень процессов в организации.

Уровень 2 – Процессная группа – указывает на следующий уровень процессов и представляет собой группу процессов.

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

Уровень 4 – Операция – показывает ключевые события, возникающие при выполнении процесса.

Уровень 5 – Задача – представляет собой следующий уровень иерархической декомпозиции после операций. Задачи являются более раздробленными и в значительной степени зависят от отрасли.

Видно, что в APQC, по сути, нет четких определений уровней. Есть лишь некоторое их описание.

Взяв названия уровней из APQC, в ряде проектов я использовал следующие определения:

Категория бизнес-процессов – совокупность групп бизнес-процессов, объединенных по критериям общности поставленных целей и единства методов создания ценности для потребителей.

Группа бизнес-процессов – совокупность процессов, объединенных по критериям общности поставленных целей и единства методов создания ценности для потребителей.

Процесс – совокупность взаимосвязанных операционных процессов, выполняемая одним или несколькими субъектами (подразделение, должность, роль).

Операционный процесс – ограниченная совокупность операций, выполняемая одним и более субъектами (должность, роль).

Операция процесса – ограниченная совокупность транзакций, выполняемая одним субъектом (должность, роль) или модулем информационной системы/программного продукта.

Транзакция – часть операции, которая может быть выполнена только целиком, либо вообще не выполнена.

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

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

1. на определенных уровнях сверху (1—3, иногда 1—4) для описания процессов могут использоваться модели только структурного типа (например, нотация IDEF0);

2. с некоторого уровня (4 или ниже) для описания процессов используется принципиально другой тип моделей – Work Flow (например, нотации eEPC или BPMN);

3. необходимо корректно увязывать между собой структурные модели (IDEF0) и модели типа Work Flow (eEPC и BPMN) в рамках единой архитектуры бизнес-процессов организации.

Выше я использовал термин «структурная модель». Приведу общее определение из Википедии: «Структура – определённая взаимосвязь, взаиморасположение составных частей, строение, устройство чего-либо». В философии «Структура – совокупность связей между частями объекта». Поэтому нужно сделать следующее определение:

Структурная модель бизнес-процесса – модель, включающая в себя части процесса и связи между этими частями, представляющие собой однонаправленные потоки объектов (информация, документы, материальные ресурсы).

Модель Work Flow бизнес-процесса – модель, включающая в себя части процесса и связи между этими частями, показывающие последовательность выполнения частей процесса во времени.

1.5. Цели создания архитектуры бизнес-процессов

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

Топ-менеджмент и собственники компании:

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

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

• возможность анализа и обоснования изменений в организационной структуре и бизнес-процессах;

• возможность управлять бизнес-процессами, в т.ч. за счет определения целей и показателей;

• создание единой процессной платформы для всех проектов и инициатив по изменению деятельности компании, в первую очередь, по автоматизации системы синхронизованных между собой бизнес-процессов (в BPM-приложениях, СЭД);

• наличие актуальной регламентной базы по бизнес-процессам;

• накопление знаний по выполнению и совершенствованию бизнес-процессов.

Руководители и специалисты:

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

• возможность управлять бизнес-процессами, в т.ч. за счет определения целей и показателей;