Джон Джестон - Управление бизнес-процессами. Практическое руководство по успешной реализации проектов

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

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

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

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

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

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

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

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

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

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

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

На рис. 20.2 представлены шаги, применимые к этапу реализации, которые рассматриваются ниже.

Хорошая реализация нуждается в хорошей коммуникации, включая двусторонние коммуникации. Активное участие пользователей даст отличные предложения и может также вызвать некоторые «интересные» (критические) замечания и неадекватные намеки. Но когда пользователи осведомлены, почему их предложения или замечания не учитываются в общих целях проекта, это дает более глубокое понимание того, чего мог бы достичь проект. Лучше работать с обратной связью, чем игнорировать ее, вызывая потерю интереса и апатию. Также важно понять, что некоторые обмены информацией могут фактически усилить, а не ослабить сопротивление изменениям – так что всегда следите за методами общения и действиями.

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

• группа проекта и организация гораздо лучше будут понимать предлагаемые изменения;

• стратегия должна принять во внимание текущую ситуацию, а она могла измениться (и, скорее всего, изменилась) с момента начального определения стратегии реализации/внедрения.

В табл. 20.1 даются примеры типов стратегии, которые следует рассмотреть.

Таблица 20.1.Типы стратегии реализации

Сценарии реализации могут быть смоделированы, как показано на рис. 20.3.

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

На этом шаге, если применимо, подготавливаются тестовые конфигурации для бизнеса. Требование тестирования решений фактическими бизнес-пользователями отнесено на шаг 5 (выполнение бизнес-тестов и опытных работ). У них будет возможность испытать готовое решение с точки зрения «обычной практики». К данной стадии проекта решение будет протестировано лишь на соответствие письменным спецификациям бизнес-требований, тогда как новое решение также необходимо проверить на интеграцию с повседневной «текучкой» дел бизнес-пользователей и неявными предположениями и ожиданиями.

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

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

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

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

Ясно, что используемые обучающие материалы должны быть согласованы, и обучение нельзя начинать слишком рано. Лучше всего проводить обучение непосредственно перед тем, как понадобятся определенные навыки (если научиться новым навыкам слишком рано и не использовать их, они быстро забываются). Вот предложения касательно обучения: