Этап разработки дает значимый вклад в другие этапы общей схемы (рис. 19.7), вот лишь несколько примеров:

• решение может налагать требования на людей, которые будут работать с системой;

• этап разработки дает информацию для обучения на этапе реализации-внедрения;

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

• этап разработки должен обеспечить устойчивое функционирование;

• разработка ПО может повлиять на изменения в архитектуре процессов (особенно соответствующей информации и технологий).

На данном этапе присутствуют некоторые риски, так что нужно предусмотреть и реализовать стратегии их исключения (или хотя бы снижения). Некоторые риски перечислены в табл. 18.2 (см. выше).

В табл. 19.1 указаны риски и стратегии снижения, которые должны быть рассмотрены на этапе разработки.

Таблица 19.1. Риски и стратегии их снижения на этапе разработки

На этапе реализации (рис. 20.1) все спроектированные и разработанные усовершенствования процессов осуществляются в реальности. Здесь также сходятся вместе многие действия по управлению изменениями персонала. Хотя это одна из последних частей всей общей схемы и цикла проекта, ее следует рассмотреть в самом начале каждого проекта, с этапом стартовой площадки, поскольку именно в начале проекта нужно принять решение относительно его внедрения в бизнес (подробности см. в главе 15). Решение о реализации окажет влияние на такие грани проекта, как проектирование или перестройка процессов, выполнение разработки и тестирования и т. п. К этому решению постоянно возвращаются по ходу проекта, понимая, что метод реализации может измениться.

Кейс: запоздалая реализация в малом масштабе

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

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

Вывод. Пользователи должны привлекаться в проект на самых ранних стадиях, как, впрочем, и все заинтересованные стороны.

Если этап реализации завершен успешно, то организация может надеяться получить:

• обученный и мотивированный персонал;

• усовершенствованные или новые процессы, которые работают удовлетворительно, согласно требованиям и нуждам определенных заинтересованных сторон и бизнес-обоснованию.

Кейс: тест у кофейного автомата

Об участии заинтересованных сторон и пользователей часто говорят, но редко его добиваются. Нам кажется, что можно легко проверить (простым и ненаучным способом), привлечены ли пользователи.

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

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

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

Часто проекты не удаются, поскольку реализация сводится лишь к одному из завершающих шагов проекта и сосредотачивается на одностороннем потоке информации, сообщающем пользователям и другим заинтересованным сторонам о выгодах нового решения для организации. Более того, бо льшая часть работы нацелена на обеспечение способности пользователей применять новое решение (например, обучении), а не на то, чтобы они хотели пользоваться им (например, мотивирование персонала).