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

архитектуры приходится использовать модели разного типа. Как правило, на 1—4 уровне используются диаграммы процессов структурного типа, например, сформированные в нотации IDEF0. На нижележащих уровнях используются диаграммы класса Work Flow, например, разработанные в нотации BPMN (eEPC).

      На структурных диаграммах в нотации IDEF0 стрелки используются для моделирования потоков информационных и материальных объектов. На диаграммах в нотации BPMN базовый тип связи – это стрелка типа Sequence flow (поток управления). Стрелки такого типа показывают хронологический порядок, в котором выполняются операции процесса. Кроме того, на схемах в нотации BPMN можно дополнительно показывать потоки информации.

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

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

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

      Таблица 1. Уровни бизнес-процессов.

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

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

      Таблица 2. Требования к архитектуре

      бизнес-процессов.

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

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

      Замечу, что в Business Studio технически