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

Уровень 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) в рамках единой архитектуры бизнес-процессов организации.

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

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