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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• возможность использовать модели процессов для разработки требований к автоматизации и настройке систем класса BPMS, СЭД и др.;

• возможность использования базы знаний для совершенствования бизнес-процессов;

• возможность обучать новых сотрудников.

Процессный офис (Отдел организационного развития):

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