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

• наложены на ключевые показатели эффективности (KPI) и стратегические цели;

• использованы для приоритизации проектов и планирования ресурсов;

• наложены на модели системной динамики, чтобы сформулировать альтернативные сценарии на будущее, дать высокоуровневые оценки или прогнозы.

Использование референтных процессных моделей

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

Примеры процессных фреймворков:

• простые многоуровневые или пирамидальные модели;

• референтная модель процессов APQC;

• цепочка создания ценностей Портера;

• специализированные отраслевые референтные модели для энергетики, нефтегазовой промышленности, телекоммуникаций, страхования.

Классификация и группировка процессов согласно фреймворкам

Как правило, стандартные референтные модели делят процессы на основные, вспомогательные и управляющие.

• Основные процессы в цепочке создания ценностей Портера – «входящая логистика», «операционная деятельность», «исходящая логистика», «маркетинг и продажи», «послепродажное обслуживание».

• Основные процессы в модели APQC – «разработка видения и стратегии» (1.0), «проектирование и разработка продукции и услуг» (2.0), «маркетинг и продажа продукции и услуг» (3.0), «поставка продукта и услуг» (4.0) и «управление обслуживанием клиентов» (5.0).

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

Референтные модели, процессные фреймворки и архитектуры рассматриваются также в разделах 3.8 и 9.1.4.

3.4.2. Модели бизнес-процессов

Взгляд со стороны владельца процесса

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

• бизнес-контекст;

• описание бизнес-процесса;

• границы бизнес-процесса, в рамках которых выполняется анализ и внедряются изменения.

Этот взгляд находит отражение в моделях сквозных[67] бизнес-процессов: основных, вспомогательных, управляющих.

Модели бизнес-процессов:

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

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

3.4.3. Модели потоков работ

Взгляд со стороны операционного менеджера

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

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

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

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

3.4.4. Шаги выполнения задачи

И это не предел – модель можно детализировать еще глубже. Основное правило – детализировать процесс до уровня, достаточного для:

• решения ваших задач и

• решения своих задач другими участниками на следующих фазах проекта.

Нижний уровень определяет задачи исполнителей и требования к данным

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

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

• провести совещание с разработчиками, чтобы выяснить, какая информация им понадобится в ходе разработки и тестирования ПО;