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

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

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

● обсудите с разработчиками программного обеспечения, какая информация понадобится:

○ для проектирования ПО или для разработки приложений в среде минимального кодирования (low-code, no-code);

○ для тестирования ПО;

● используйте прямые и обратные матрицы прослеживаемости, чтобы:

○ задокументировать функциональные требования;

○ гарантировать, что программное обеспечение разработано и протестировано в соответствии с потребностями участников процесса.

4.7.9. Шаги задач

Того, кто фактически выполняет работу, обычно интересуют его задачи и шаги, из которых они состоят. Шаги задачи определяют, как выполняется работа.

Взгляд со стороны работника

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

● триггер;

● шаги;

● показатели эффективности;

● принципы, которым нужно следовать;

● материалы и инструменты (включая программное обеспечение);

● ожидаемые результаты;

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

● к кому следует обращаться за консультацией:

○ в ходе выполнения задачи;

○ после выполнения задачи.

Пример шагов задачи в сфере услуг

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

Пример шагов задачи в промышленности

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

4.8. Фреймворки и референтные модели

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

4.8.1. Моделирование с использованием фреймворков

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

Комплексные процессные фреймворки

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

● архитектурный фреймворк федеральных ведомств США (FEAF – Federal Enterprise Architecture Framework);

● архитектурный фреймворк Министерства обороны Великобритании (MODAF – Ministry of Defense Architecture Framework);

● архитектурный фреймворк Министерства обороны США (DoDAF – Department of Defense Architecture Framework);

● архитектурный фреймворк (TOGAF – The Open Group Architectural Framework).

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

Последний из перечисленных фреймворков, TOGAF, поддерживаемый The Open Group, является универсальной версией фреймворка DoDAF, и Министерство обороны использует его наряду с DoDAF. Большинство этих внешне различных фреймворков являются либо вариацией фреймворка, предложенного Джоном Захманом (John Zachman) в 1987 г., либо разработаны под влиянием его идей.