Свод знаний по управлению бизнес-процессами: BPM CBOK 3.0

Диаграмма ниже (рис. 5.3) является примером процессной иерархии. Различные организации могут использовать больше или меньше уровней и называть их иначе. Суть в том, что о качестве моделей и в целом информации о процессе можно говорить только в том случае, если она организована в систему.

Примечание: число уровней и их названия определяются стандартами моделирования конкретной компании. Принципиально то, что процесс должен быть детализирован вплоть до уровня, позволяющего понять, какие действия выполняются и как они координируются друг с другом. Таким образом, уровни на рис. 5.3 – это лишь пример того, как компания может стандартизовать уровни детализации процессных моделей.

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

Верхний уровень – это модель сквозного процесса. Она может содержать подпроцессы, а также отображать информационные системы и проблемы верхнего уровня.

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

Третий уровень – это поток работ внутри подразделения, показывающий выполняющиеся действия. Модели этого уровня могут также показывать связь между действиями, выполняемыми в этом же подразделении в рамках других функций и подпроцессов.

Четвертый уровень детализации – сценарии, он позволяет понять, какими событиями, таймерами или данными вызываются выполняемые в подразделении работы. Сворачивая задачи в действия, а те, в свою очередь, в потоки работ и подпроцессы, можно легко проследить, как работа складывается в процесс, и ее роль в создании конечной продукции процесса.

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

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

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

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

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

Подробнее о том, как разрабатываются модели процессов, см. в главе 3 «Моделирование процессов».

5.3.4. Выявление процесса и потока работ