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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подробнее о том, как разрабатываются модели процессов, см. в главе 3 «Моделирование процессов».

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

Многие задаются вопросом: почему я должен беспокоиться о модели «как есть»? Я изменяю компанию, почему просто не сосредоточиться на будущем состоянии? Ответ прост: потому что, прежде чем менять процесс, необходимо его понять. Вы не сможете просто создать концептуальную будущую модель бизнеса и рассчитывать на ее реализацию, не обеспечив возможность перехода от текущего состояния к будущему.