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

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

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

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

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

Если начать подготовку реализации на этапе стартовой площадки проекта, это поначалу приведет к увеличению вложений, однако реализованное решение будет готово запуститься с одного оборота, что быстрее даст лучшие устойчивые результаты (рис. 15.8 – Regatta® фирмы Sogeti Nederland).

Если сравнить два подхода, ясно видно, что, несмотря на аргумент увеличения вложений на ранней стадии, преимущества такого подхода существенно выше по сравнению с традиционным подходом (рис. 15.9 – Regatta® фирмы Sogeti Nederland).

В презентации «Привязка ИТ к эффективности предприятия: важна реализация», сделанной Джорджем Лори из Forrester Research 21 мая 2003 года в Амстельвине, Голландия, на церемонии представления книги Regatta® фирмой Sogeti Nederland говорилось: «Неважно, сколько вы тратите на ИТ, важно – какие технологии вы покупаете, но самое важное – как вы их внедряете». Этот вывод следует из осознания, что все больше и больше организаций покупает и внедряет стандартные готовые пакеты, так что конкурентное преимущество проистекает не из самого инструментария, а из того, как он сконфигурирован и реализован в организации.

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

Кейс: преждевременное внедрение

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

Внедрение проходило в навязанные сроки и действительно вызвало операционный хаос, но мы впоследствии узнали, что руководитель организации получил существенную премию за реализацию проекта «в срок»!

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

Следует использовать стандартную типовую форму бизнес-обоснования, принятую в организации. Помимо обычного содержания обоснования BPM (которое подробно описано в Приложении C), данное обоснование должно также включать:

• анализ приращения экономической ценности (EVA);

• внутреннюю подготовку предложений;

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

• рассмотрение «за» и «против» различных вариантов;

• использование критериев оценки сценариев и эффективности.

Группе проекта ни в коем случае не следует отстаивать сделанные рекомендации, а только давать их и объяснять возможные варианты объективно и непредвзято {5}.

В разработку обоснования входит и определение лица (лиц), которое будет отвечать за процесс (процессы) после перехода проекта из «проектного» в рабочее состояние. Это нужно для обеспечения участия данных лиц в проекте и принятии решений по проекту, чтобы у них был некий уровень принадлежности к результатам проекта и ответственности за них.

Следует иметь в виду, что это лишь исходное обоснование, которое может обосновать либо весь проект BPM, либо дальнейшее финансирование разработки подробного обоснования полного проекта. Бизнес-обоснование необходимо обновить или доработать на этапе инноваций, чтобы оправдать продолжение проекта BPM (см. шаг 13 в главе 17).

После принятия решения о последовательности изучения процессов на этапе понимания исходная группа проекта и бизнес-подразделения могут приступать к формированию структуры проекта BPM и группы проекта. Структура проекта BPM может несколько отличаться от типичного проекта ИТ или бизнес-проекта. Структура на рис. 15.10 предполагает, что одновременно с реализацией проекта BPM внедряется интегрированная система управления документами. Функциональные обязанности рассматриваются более подробно в Приложении С.

Эта типовая структура проекта предназначена для широкомасштабной программы или проекта внедрения BPM. Ее нужно адаптировать к конкретным требованиям организации и проекта. Группа проекта редко начинает проект в таком составе на этапе стартовой площадки. Однако необходимо определить и спланировать будущую структуру группы проекта. Количество и состав направлений работы, показанные на рис. 15.10, будут зависеть от проекта и используемых элементов автоматизации. Мы представили только одно направление для элемента управления документами; очевидно, что будут и другие для реализации модуля – машины процессов (потока работ – workflow) и бизнес-правил. Данная структура, однако, оказалась особенно эффективной, так что ее излишняя модификация может привести к снижению результативности.

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