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

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

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

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

5.3.2. Организация информации о процессе

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

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

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

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

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

5.3.3. Уровни модели

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

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

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

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

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

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

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

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

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

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

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

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