Управление бизнес-процессами. Практическое руководство по успешной реализации проектов
Шрифт:
Мы побеседовали с пользователями, и они сообщили, что с ними не посоветовались о предлагаемых изменениях, которые строились на неверных предположениях, и на практике не сработали бы. Когда мы поинтересовались у спонсора проекта, на какой стадии проекта советовались с пользователями и сообщали им об изменениях, оказалось, что это было осуществлено лишь после создания перестроенных процессов с помощью внешнего аналитика и своих менеджеров.
Вывод. Пользователи должны привлекаться в проект на самых ранних стадиях, как, впрочем, и все заинтересованные стороны.
Результаты
Если
• обученный и мотивированный персонал;
• усовершенствованные или новые процессы, которые работают удовлетворительно, согласно требованиям и нуждам определенных заинтересованных сторон и бизнес-обоснованию.
Кейс: тест у кофейного автомата
Об участии заинтересованных сторон и пользователей часто говорят, но редко его добиваются. Нам кажется, что можно легко проверить (простым и ненаучным способом), привлечены ли пользователи.
Подойдите к кофейному автомату в любой фирме и спросите у сотрудников о предлагаемых улучшениях процессов. Если ответы будут вроде: «Понятия не имею, чем они там занимаются», «Они провели увлекательные беседы, но я ничего не слышал в подробностях» или «Нам они все равно ничего не говорят», знайте, что налицо явные признаки невовлеченности пользователей и недостаточного общения.
Нам приходилось сталкиваться с проектами, участники которых не пытались защитить проект, когда о нем отзывались негативно. Часто это является проявлением неуверенности и отсутствия гордости за проект, что может быть следствием невовлеченности сотрудников.
Вывод. Неважно, насколько велики выгоды, которые вы намерены извлечь из проекта, – если вы не доносите эти выгоды до заинтересованных сторон и пользователей, их будет трудно достичь или реализовать.
Осуществление
Часто проекты не удаются, поскольку реализация сводится лишь к одному из завершающих шагов проекта и сосредотачивается на одностороннем потоке информации, сообщающем пользователям и другим заинтересованным сторонам о выгодах нового решения для организации. Более того, бо льшая часть работы нацелена на обеспечение способности пользователей применять новое решение (например, обучении), а не на то, чтобы они хотели пользоваться им (например, мотивирование персонала).
Лучший способ обеспечить плавную реализацию – рассматривать вопросы реализации еще при инициировании проекта. Только в этом случае этап реализации будет ориентирован на обновление информации и выполнение задач, а не на придумывание в последнюю минуту приемов, способных ублажить пользователей.
На рис. 20.2 представлены шаги, применимые к этапу реализации, которые рассматриваются ниже.
Шаг 1. Обмен информацией
Хорошая реализация нуждается в хорошей коммуникации, включая двусторонние коммуникации.
Шаг 2. Обновление стратегии реализации
Стратегия реализации/внедрения должна быть определена еще в начале проекта. На этапе реализации важно пересмотреть исходную стратегию реализации, поскольку:
• группа проекта и организация гораздо лучше будут понимать предлагаемые изменения;
• стратегия должна принять во внимание текущую ситуацию, а она могла измениться (и, скорее всего, изменилась) с момента начального определения стратегии реализации/внедрения.
В табл. 20.1 даются примеры типов стратегии, которые следует рассмотреть.
Таблица 20.1. Типы стратегии реализации
Сценарии реализации могут быть смоделированы, как показано на рис. 20.3.
На шаге стратегии реализации еще раз рассматриваются различные типы пользователей и заинтересованных сторон, а их ожидания и участие в проекте выверяются.
Шаг 3. Подготовка к тестам приемки пользователями
На этом шаге, если применимо, подготавливаются тестовые конфигурации для бизнеса. Требование тестирования решений фактическими бизнес-пользователями отнесено на шаг 5 (выполнение бизнес-тестов и опытных работ). У них будет возможность испытать готовое решение с точки зрения «обычной практики». К данной стадии проекта решение будет протестировано лишь на соответствие письменным спецификациям бизнес-требований, тогда как новое решение также необходимо проверить на интеграцию с повседневной «текучкой» дел бизнес-пользователей и неявными предположениями и ожиданиями.
В идеале, подготовка к бизнес-тестированию должна была начаться во время проектирования новых процессов (процесса). Это могло произойти либо на этапе инноваций, либо на этапе разработки, в зависимости от конкретных обстоятельств. Если тестовые конфигурации были разработаны на столь ранней стадии, то у организации имеется возможность сравнить ожидаемые итоги тестирования с техническими и бизнес-спецификациями и схемами, чтобы убедиться в отсутствии пробелов в требованиях. Такой прекрасный пример проверки позволяет избежать дорогостоящих ошибок.