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

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

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

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

Из таблицы 1 видно, что на уровне 3 «Процессы» может быть два уровня диаграмм. Так же это возможно на уровне 4 «Операционные процессы». Обратите внимание – начиная с уровня 4, для формирования графических схем используется нотация BPMN.

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

Эти требования, по сути, говорят о том, что все бизнес-процессы в архитектуре должны быть корректно увязаны между собой по входам/выходам потоками информации и материальных объектов, а также синхронизованы по условиям начала и завершения. Говоря «все», я не подразумеваю связи каждого процесса со всеми остальными. Речь идет только о тех процессах, которые реально взаимодействуют между собой.

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

Замечу, что в Business Studio технически можно определить руководителей, ответственных за выполнение процессов, без определения входов/выходов процессов. Для этого достаточно иметь реестр процессов в виде справочника. Назначение ответственных осуществляется путем определения связи между субъектом (должность, роль) и процессом (через интерфейс системы). Однако с точки зрения практики, такое назначение будет довольно абстрактным до тех пор, по четко не будут определены границы соответствующих процессов.

Для определения границ нужно четко определить, какие документы (информация) и материальные ресурсы пересекают эти границы. Нужно определить спецификации, показатели оценки, методы и средства измерения. Но надо четко понимать, что детальное определение границ всех процессов по входам/выходам может повлечь за собой большой объем работы по идентификации и занесению в среду моделирования соответствующей информации о процессах (например, по ходу так называемой «паспортизации процессов»).

При создании архитектуры процессов компании нужно четко понимать возможности и знать ограничения, связанные как с используемой нотацией, таки и функционалом Business Studio.