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

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

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

Предпосылки к трансформации были рассмотрены выше в этой главе (см. раздел 7.1).

Ключ к трансформации – это цели (стандарты, показатели эффективности, KPI и требования) и подходы. Проектная команда и участники начинают с того, что добиваются единого понимания целей и требований, а также ожиданий руководителей, персонала и бизнес-партнеров, которых затрагивает трансформация. Это достигается с помощью рабочих совещаний. Следует уделить внимание тестированию, чтобы убедиться в правильном понимании всеми ключевых концепций, целей, требований, возможностей IТ и т. д.

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

• Сколько предположений, сделанных в ходе обсуждения проекта, было поддержано руководством?

• На сколько исследовательских команд будет разбита проектная команда?

• Будут ли интервью проводиться одним членом команды или парой – один беседует, второй записывает?

• Будут ли для участия в проекте выделены один или два бизнес-пользователя или команда предпочтет более широкое вовлечение, привлекая множество людей на короткое время?

• Будут ли бизнес-пользователи обучаться работе с BPMS или все моделирование будет выполняться проектной командой?

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

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

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

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

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

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

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

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

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

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

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

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

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