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

На верхнем уровне иерархии отображаются сквозные процессы. Затем они разбиваются (декомпозируются) вплоть до отдельных действий, где и выполняется процессная работа.

В ходе декомпозиции процесс разбивается на подпроцессы и затем на функции. Функции привязываются к подразделениям. Действия, выполняемые в рамках подразделения, вместе с действиями, относящимися к другим подпроцессам, образуют поток работ. Результатом будет представление способа выполнения работы в бизнес-подразделениях.

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

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

На следующем рисунке показан пример иерархии процессов, начиная с уровня предприятия и заканчивая уровнями бизнес-процессов и потоков работ:

На рис. 4.13 показан пример иерархии процессов; организации могут использовать большее или меньшее количество уровней и называть их иначе.

Важно иметь в виду следующее:

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

● О качестве моделей и в целом информации о процессах можно говорить, только если она организована в систему.

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

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

Качественный стандарт моделирования должен в том или ином виде содержать по крайней мере следующие уровни:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Стратегическому взгляду на модели процессов со стороны высшего руководства;

2. Бизнес-взгляду на модели сквозных процессов;

3. Операционному взгляду на модели реально выполняемых потоков работ;

4. Самому низкому уровню задач и шагов, необходимых для выполнения работы.

С формированием BPM как управленческой дисциплины появилась необходимость в моделях, интегрирующих различные взгляды. В рамках концепции BPM стратегия организации реализуется через эффективные процессы. Эффективность процессов связывает модель предприятия и модель процессов с моделями потоков работ (или операций), которые описывают, что должно быть сделано для создания продукции или услуги для внешнего потребителя. Модели потоков работ, в свою очередь, состоят из задач и составляющих их шагов, описывающих, как должна выполняться работа. Выполнение задач поддерживается прикладными информационными системами. Эти взаимосвязи показаны на рис. 4.12.

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

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

Назначение бизнес-архитектуры:

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

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

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

○ возможности имеющегося готового программного обеспечения или

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

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

● Бизнес-архитекторы рассматривают стратегию и ее влияние на организацию:

○ процессные архитекторы моделируют текущие и будущие бизнес-операции;

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

○ корпоративные архитекторы обеспечивают поддержку изменений бизнес-архитектуры на уровне информационных систем и ИТ-инфраструктуры.

Разработка бизнес-архитектуры и бизнес-способностей предприятия подробно рассматривается в разделе 9.2.

Модели уровня предприятия представляют собой высокоуровневый взгляд на бизнес-процессы.

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

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

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

Модели бизнес-процессов предприятия используются не только в качестве средства классификации. Процессы могут быть:

● увязаны с ключевыми показателями эффективности и стратегическими целями;

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

● привязаны к динамическим моделям:

○ для разработки стратегий исходя из возможных сценариев будущего;

○ для высокоуровневых оценок и прогнозирования.

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

В некоторых проектах моделирования процессов предприятия в качестве первоначальной версии берется одна или несколько референтных моделей. Такая черновая модель поступает на рассмотрение руководства для одобрения или корректировки.

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

Примеры фреймворков и референтных моделей рассматриваются в разделе 4.8.

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

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

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

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

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

За модель бизнес-процесса отвечает владелец процесса. Модель процесса описывает потоки бизнес-операций и то, как бизнес-операции обеспечивают достижение стратегических целей организации.

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

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

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

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

Этот взгляд находит отражение в моделях бизнес-процессов.

Модели бизнес-процессов, отражающие взгляд бизнеса, включают в себя:

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

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

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

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

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

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

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

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

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

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

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

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

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

● триггер;

● шаги;

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

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

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

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

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

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

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

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

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

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