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

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

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

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

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

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

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

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

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

4.7.2. Состав информации о процессе

Разработанные в ходе реализации процессной инициативы модели процессов следует использовать для создания модели бизнеса предприятия – это избавит от необходимости инициировать отдельный проект по созданию такой модели.

Чтобы способствовать эволюционным усилиям по созданию модели предприятия, модели процессов должны содержать следующую информацию:

● для процессов – подпроцессы и их взаимодействие;

● для подпроцессов – бизнес-функции/сценарии и подразделения, которые их выполняют;

● для потоков работ в рамках бизнес-подразделения – выполняемые действия (могут декомпозироваться на более низкие уровни, чтобы показать задачи, из которых они состоят);

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

● возможности для оптимизации и ожидаемый эффект, в привязке к части бизнеса, к которой они относятся;

● метрики (численность сотрудников, объем выполняемой работы, частота ошибок), привязанные к точке операции, в которой они измеряются;

● ИТ-приложения и где они используются в организации;

● основная функциональность каждого ИТ-приложения;

● данные – где хранятся, как редактируются и как используются;

● правила – писаные и неписаные;

● процедуры принятия решений с вероятностями каждого возможного исхода;

● нормативы качества/продолжительности/производительности и т. п.;

● политики и требования внутреннего аудита;

● требования к измерению эффективности.

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

4.7.3. Интеграция процессных моделей