Назначение

We use cookies. Read the Privacy and Cookie Policy

Назначение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Данный текст является ознакомительным фрагментом.