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

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

Шлюз 3. Способность организации к изменениям

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

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

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

Этот шлюз часто закрыт из-за:

• излишней уверенности: у организаций часто разыгрывается неутолимая жажда иметь «все и сразу», но свой мир они могут менять лишь с ограниченной скоростью. Менеджеры проектов BPM должны определить разрыв между желанием перемен и объективной реальностью;

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

Этот шлюз часто открывается:

• оценкой и пониманием BPM-зрелости организации;

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

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

Шлюз 4. Принятие BPM организацией

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

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

Этот шлюз часто закрыт, потому что:

• руководители слишком увязли в решении текущих проблем;

• руководители не осознают значимости процессов для эффективности функционирования организации.

Этот шлюз часто открывается:

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

• растущей готовностью к BPM и расширением практики успешных реализаций BPM в других организациях;

• одним руководителем, успешно реализующим сценарий «пилотный проект» или проект «вне поля зрения», чего часто бывает достаточно при демонстрации выгод BPM для организации.

Шлюз 5. Техническое исследование

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

Такое соображение кажется очевидным, но в неоправданно большом количестве проектов оно не предпринимается на ранней стадии.

Этот шлюз часто закрыт, потому что:

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

Этот шлюз часто открывается:

• техническим анализом на начальной стадии проекта;

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

Кейс: инфраструктурный барьер

Мы руководили проектом внедрения автоматизированного BPM у клиента, где инфраструктура распадалась по мере невообразимого роста организации. Это ставило интересные проблемы в связи с действующей инфраструктурой.

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