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

• Кто будет заниматься стандартами и надзором за их соблюдением в ходе трансформации?

• Откуда команда будет брать бизнес-правила: из инструкций, служебных записок, интервью, семинаров, информационных систем?

• Что остается за рамками обсуждений и возможных действий – использование аутсорсинга? Новые веб-приложения? Ликвидация подразделений?

• Будет ли команда идти от процессов или от оргструктуры?

• Будет ли команда использовать для тестирования схем имитационное моделирование или совместное пошаговое прохождение процесса?

• Будет ли сформирован центр компетенции в области BPM или бизнес-архитектуры для обеспечения стандартизации и регулирования?

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

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

В дальнейшем трансформация должна следовать обычному проектному подходу с учетом специфики. Цель – за счет единообразия снизить затраты и риски. Обычно проект открывается задачей проектирования высокоуровневой модели бизнес-операций «как есть» [137] As is . – Прим. пер. . Эта модель концентрируется на процессе (процессах), которые подвергнутся трансформации, и показывает деятельность всех вовлеченных бизнес-подразделений. Это ключевая составляющая трансформации.

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

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

После этого проектная команда должна разработать схему верхнего уровня «как будет» [138] To be . – Прим. пер. . При этом все подвергается сомнению и поощряются инновационные и нешаблонные идеи. Поиск решения не должен быть ограничен ничем, кроме юридических, финансовых и других рамок, заданных высшим руководством.

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

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