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

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

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

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

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

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

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

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

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

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

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

1.6. Требования к архитектуре бизнес-процессов как к объекту управления

Архитектура бизнес-процессов компании сама по себе является сложной системой, т.е. объектом, требующим управления.

В рамках архитектуры приходится использовать модели разного типа. Как правило, на 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 технически можно определить руководителей, ответственных за выполнение процессов, без определения входов/выходов процессов. Для этого достаточно иметь реестр процессов в виде справочника. Назначение ответственных осуществляется путем определения связи между субъектом (должность, роль) и процессом (через интерфейс системы). Однако с точки зрения практики, такое назначение будет довольно абстрактным до тех пор, по четко не будут определены границы соответствующих процессов.

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

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

2. Методика построения архитектуры процессов: общий обзор

2.1. Пошаговая методика построения архитектуры бизнес-процессов компании

Общая методика построения архитектуры бизнес-процессов компании в Business Studio включает в себя следующие этапы:

1. Разработка модели организационной структуры компании.

2. Формирование реестров функциональных бизнес-процессов подразделений и основных справочников.

3. Создание контекстной модели бизнеса в нотации IDEF0 (уровень «0»).

4. Разработка моделей (или реестров) категорий бизнес-процессов в нотации IDEF0 (уровень «1»).

5. Разработка моделей (или реестров) процессных групп в нотации IDEF0 (уровень «2»).

6. Разработка моделей (или реестров) процессов в нотации IDEF0 (уровень «3»).

7. Разработка моделей операционных процессов в нотации BPMN (уровни «4» и «5»).

8. Перегруппировка объектов в справочниках объектов деятельности (если будет принято такое решение).

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

Этап 1. Для каждого бизнес-процесса в архитектуре должны быть определены исполнители и ответственные. Ими могут являться подразделения, должности или роли. Поэтому на первом этапе целесообразно создать модель организационной структуры компании в Business Studio.

Этап 2. Необходимо выполнить анализ деятельности подразделений и определить реестр бизнес-процессов (на 2-3-х уровнях представления) для каждого функционального подразделения. Реестры заносят в Business Studio в виде иерархического справочника. Заполняются справочники документов, информации, материальных ресурсов, информационных систем, баз данных, терминов. Группировка объектов в справочниках осуществляется на основе структуры функциональных подразделений. Таким образом, получаем реестры функциональных процессов подразделений.

Этап 3. Разрабатывается контекстная модель бизнеса (диаграмма А-0, уровень «0») (или отдельного сквозного процесса[3 - В зависимости от выбранного метода. Об этом будет сказано ниже.]). Для этого определяются и группируются поставщики и потребители компании, а также другие субъекты, которые с ней взаимодействуют. Определяются входы/выходы для бизнеса компании в целом.

Этап 4. Выполняется анализ деятельности компании. Выбирается принцип группировки категорий процессов. Разрабатывается диаграмма А0 (уровень 1).

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

Этап 6. Разрабатываются модели процессов для каждой процессной группы. Процессы формируются из реестров функциональных процессов подразделений.

Этап 7. Разрабатываются модели операционных процессов для каждого процесса. Операционные процессы могут создаваться непосредственно в процессной модели или формироваться из реестров функциональных процессов подразделений.

Этап 8. Выполняется перегруппировка объектов в справочниках (кроме справочника «Процессы») для перехода от функциональной к выбранному типу процессной модели. Новая группировка осуществляется в соответствии со структурой категорий и групп процессов компании.

На каждом этапе работы возникает ряд практических нюансов и проблемы, которые будут рассмотрены ниже.

2.2. Инструмент Business Studio

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