Джон Джестон - Управление бизнес-процессами. Практическое руководство по успешной реализации проектов
Конкретные результаты этапа понимания включают:
1. Перечень моделей сквозных процессов.
2. Перечень сквозных подпроцессов.
3. Модели действующих процессов с детализацией, достаточной для выполнения этапа инноваций.
4. Соответствующие метрики, дающие возможность задать точку отсчета для будущих сравнительных измерений процессов.
5. Перечень основных проблем процессов, определенных бизнес-подразделениями.
6. Определение приоритетов для инноваций.
7. Выявление возможностей быстрых выигрышей.
8. Проверка и передача на реализацию возможностей быстрых выигрышей, если это целесообразно на данном этапе.
9. Отчет по этапу.
Шаг 6. Разработка плана реализации
Важность собственно реализации невозможно переоценить. Распространен вопрос «что выиграет проект, если потратить больше денег и времени на реализацию». Ответ прост, но иногда трудно посчитать выигрыш сразу же. Четкая реализация обеспечит оптимальность предложенного решения для организации, использование этого решения наилучшим образом и в возможно кратчайшие сроки. Если реализация не проходит гладко, может возникнуть одна или несколько следующих ситуаций:
• выбранное решение не оптимально для организации – это может быть вызвано неверным, неполным или несогласованным сбором требований, но все же большей частью вызывается недостаточно плотным участием заинтересованных сторон и пользователей процесса;
• организация использует решение не лучшим образом, поскольку пользователи недостаточно проинформированы, не обучены и не мотивированы;
• решение невозможно реализовать сразу же; необходимы изменения, что затягивает сроки получения реальных преимуществ, и они не столь велики, как должны были быть.
Для традиционного подхода к реализации характерны скромные усилия и вложения в начальный момент. К моменту внедрения решения приходится вносить изменения в последнюю минуту, что ведет к существенным непредвиденным дополнительным вложениям и более низким устойчивым результатам (рис. 15.7).
Если начать подготовку реализации на этапе стартовой площадки проекта, это поначалу приведет к увеличению вложений, однако реализованное решение будет готово запуститься с одного оборота, что быстрее даст лучшие устойчивые результаты (рис. 15.8 – Regatta® фирмы Sogeti Nederland).
Если сравнить два подхода, ясно видно, что, несмотря на аргумент увеличения вложений на ранней стадии, преимущества такого подхода существенно выше по сравнению с традиционным подходом (рис. 15.9 – Regatta® фирмы Sogeti Nederland).
В презентации «Привязка ИТ к эффективности предприятия: важна реализация», сделанной Джорджем Лори из Forrester Research 21 мая 2003 года в Амстельвине, Голландия, на церемонии представления книги Regatta® фирмой Sogeti Nederland говорилось: «Неважно, сколько вы тратите на ИТ, важно – какие технологии вы покупаете, но самое важное – как вы их внедряете». Этот вывод следует из осознания, что все больше и больше организаций покупает и внедряет стандартные готовые пакеты, так что конкурентное преимущество проистекает не из самого инструментария, а из того, как он сконфигурирован и реализован в организации.
На этапе реализации рассматриваются различные варианты, которые следует изучить на данном шаге, цель которого – обдумывание вариантов внедрения и выбор наиболее подходящего для проекта. Это задает направление для других этапов и шагов общей методической схемы по мере продвижения проекта.
Кейс: преждевременное внедрение
Мы участвовали в проекте, где руководитель организации настаивал на его реализации к строго определенной дате, хотя менеджер проекта, директор ИТ и директор операций дружно настаивали, что эта дата должна быть отсрочена на три месяца и что реализация в такие сроки вызовет неразбериху в операционных областях бизнеса организации.
Внедрение проходило в навязанные сроки и действительно вызвало операционный хаос, но мы впоследствии узнали, что руководитель организации получил существенную премию за реализацию проекта «в срок»!
Вывод. Анализ заинтересованных сторон и понимание факторов, которые движут ими, очень важны для успешного итога проекта.
Шаг 7. Разработка/утверждение бизнес-обоснования
Следует использовать стандартную типовую форму бизнес-обоснования, принятую в организации. Помимо обычного содержания обоснования BPM (которое подробно описано в Приложении C), данное обоснование должно также включать:
• анализ приращения экономической ценности (EVA);
• внутреннюю подготовку предложений;
• документирование всех операционных затрат, не поддающихся количественному измерению, выгоды и приращений экономической ценности, а также анализ рисков каждого из них;
• рассмотрение «за» и «против» различных вариантов;
• использование критериев оценки сценариев и эффективности.
Группе проекта ни в коем случае не следует отстаивать сделанные рекомендации, а только давать их и объяснять возможные варианты объективно и непредвзято {5}.
В разработку обоснования входит и определение лица (лиц), которое будет отвечать за процесс (процессы) после перехода проекта из «проектного» в рабочее состояние. Это нужно для обеспечения участия данных лиц в проекте и принятии решений по проекту, чтобы у них был некий уровень принадлежности к результатам проекта и ответственности за них.
Следует иметь в виду, что это лишь исходное обоснование, которое может обосновать либо весь проект BPM, либо дальнейшее финансирование разработки подробного обоснования полного проекта. Бизнес-обоснование необходимо обновить или доработать на этапе инноваций, чтобы оправдать продолжение проекта BPM (см. шаг 13 в главе 17).
Шаг 8. Определение и формирование структуры группы проекта
После принятия решения о последовательности изучения процессов на этапе понимания исходная группа проекта и бизнес-подразделения могут приступать к формированию структуры проекта BPM и группы проекта. Структура проекта BPM может несколько отличаться от типичного проекта ИТ или бизнес-проекта. Структура на рис. 15.10 предполагает, что одновременно с реализацией проекта BPM внедряется интегрированная система управления документами. Функциональные обязанности рассматриваются более подробно в Приложении С.
Эта типовая структура проекта предназначена для широкомасштабной программы или проекта внедрения BPM. Ее нужно адаптировать к конкретным требованиям организации и проекта. Группа проекта редко начинает проект в таком составе на этапе стартовой площадки. Однако необходимо определить и спланировать будущую структуру группы проекта. Количество и состав направлений работы, показанные на рис. 15.10, будут зависеть от проекта и используемых элементов автоматизации. Мы представили только одно направление для элемента управления документами; очевидно, что будут и другие для реализации модуля – машины процессов (потока работ – workflow) и бизнес-правил. Данная структура, однако, оказалась особенно эффективной, так что ее излишняя модификация может привести к снижению результативности.
