7.5. Трансформация бизнеса: достижение оптимума

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

С приемкой модели верхнего уровня начинается основная работа по трансформации.

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

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

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

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

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

По мере того как компоненты проектируются, тестируются и утверждаются, служба IТ получает требования верхнего уровня, а также детальные спецификации программных интерфейсов, модулей Java, веб-сервисов, структуры баз данных и прочие. Имитационное моделирование привязывается по срокам к готовности изменений в IТ-инфраструктуре, необходимых интерфейсов и т. п. Эта готовность определяет также расписание «окончательного» имитационного моделирования и общий график трансформации.

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