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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Взгляд со стороны предприятия

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

Модели уровня предприятия

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

Компоненты модели процессов уровня предприятия

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

Другие применения модели процессов уровня предприятия

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

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

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

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

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

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

Бизнес-архитектура и метрики уровня предприятия

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

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

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

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

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

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

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

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

Что в себя включает модель потока работ

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

Свертка действий

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

Дальнейшая декомпозиция модели потока работ

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

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

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

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

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

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

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

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

Что в себя включает модель бизнес-процесса

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

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

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

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

Что в себя включает уровень задач

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

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

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

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

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

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

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

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

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

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

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

● триггер;

● шаги;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

● архитектурный фреймворк федеральных ведомств США (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 г., либо разработаны под влиянием его идей.

Управление фреймворком и контроль соответствия

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

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

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

Наиболее известные референтные модели:

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

● SCOR (Supply Chain Operations Reference) – референтная модель управления цепями поставок;

● APQC PCF (Process Classification Framework) – референтная модель APQC (American Productivity & Quality Center).

Базовая классификация процессов

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

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

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

SCOR

Модель SCOR (Supply Chain Operations Reference) – это ведущая референтная модель управления цепями поставок, объединяющая в интегрированную структуру бизнес-процессы, показатели эффективности, практики, навыки и компетенции персонала. Модель SCOR продвигает Ассоциация управления цепями поставок (ASCM – Association of Supply Chain Management).

Организации, которые хотят разобраться с внутренними операционными процессами, а особенно с поставками, могут использовать эту референтную модель для анализа процессов, сравнения с конкурентами и оценки проведенной оптимизации. Структура процессов SCOR показана на рис. 4.15 и 4.16.

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

Помимо SCOR, ASCM предлагает и другие референтные модели: модель операционных процессов жизненного цикла (PLCOR), модель операционных процессов взаимодействия с клиентами (CCOR), модель операционных процессов разработки новых товаров (DCOR), модель стратегических процессов управления цепями поставок (M4SC) (рис. 4.17).

За дополнительной информацией обращайтесь на сайт ASCM: www.ascm.org.

APQC PCF

APQC (American Productivity and Quality Center) разработала референтные модели процессов PCF (Process Classification Framework) в качестве единого языка общения организаций, помогающего создавать полные и не избыточные описания процессов. APQC предлагает как универсальную модель, так и специализированные для различных отраслей. Организации используют эти фреймворки для бенчмаркинга, управления контентом и других важных составляющих управления эффективностью.

Как показано на следующем рисунке, в модели APQC PCF к основным (операционным) процессам относятся разработка видения и стратегии (1.0), проектирование и разработка продукции и услуг (2.0), маркетинг и продажа продукции и услуг (3.0), поставка продукции и предоставление услуг (4.0) и управление обслуживанием клиентов (5.0):

За дополнительной информацией обращайтесь на сайт APQC: www.apqc.org.

4.9. Процессный репозиторий

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

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

Помимо создания графических изображений бизнес-процессов, репозиторий предназначен для:

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

● создания централизованного хранилища информации о процессах;

● обеспечения совместной работы в многопользовательском режиме;

● подготовки отчетов о содержимом по запросам пользователей;

● проверки соблюдения стандартов моделирования;

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