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

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

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

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

Важно задать показатели для мониторинга продвижения. Вот некоторые примеры:

• количество заданных вопросов в первые недели (неделю);

• количество ошибок в первые недели (неделю);

• процент персонала, работающего с новыми процессами;

• уровень сверхурочной работы, необходимой для выполнения работы.

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

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

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

• то, как воплощен проект, окажет влияние на то, как будет проходить реализация выигрышей (ценности) проекта;

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

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

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

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

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

Ради чего проект затевался вообще? Это написано в бизнес-обосновании. Там должны быть указаны выгоды и ценность для бизнеса, которые ожидается получить по окончании проекта.

Ценность не падает сверху, как манна небесная. Выигрыши нужно планировать, они должны быть кому-то нужны, на их материализацию нужно работать. Реализация бизнес-ценности редко случается сразу после воплощения проекта (рис. 21.1), задержка может иногда длиться от трех до шести месяцев (рис. 21.2).

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

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

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

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

В своей лекции в Университете Лидса в 2002 г. Дейвид Винни (David Vinney, специалист в области инжиниринга информационных систем) указал:

Последние исследования, проведенные школой бизнеса Университета Крэнфильда, показали, что 78 % проектов с изменениями на основе ИТ (в крупных британских компаниях) не принесли выгоды бизнесу. 47 % опрошенных считали, что оценка бизнес-выгод была слабой или плохой, а 79 % сказали, что не все имевшиеся выигрыши были обнаружены при оценке, а 45 % считали, что выгоды проектов в их организациях были явно завышены, чтобы получить финансирование.

На сайте правительства Соединенного Королевства ( www.ogc.gov.uk, по состоянию на 8 июня 2005 года), утверждалось, что:

… многие проекты не обеспечивают выигрышей, на которые рассчитывали, когда утверждали исходное финансирование. По оценкам специалистов, 30–40 % систем поддержки бизнес-изменений вообще не дают никаких выигрышей.

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

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

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