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

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

Чтобы удостовериться в реализуемости и практичности вариантов перестройки, необходим дополнительный анализ, отвечающий на два вопроса:

1. Может ли новый процесс поддерживаться с точки зрения ИТ?

2. Будет ли бизнес функционировать эффективно и продуктивно в результате нового процесса?

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

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

Чрезвычайно полезно провести анализ разрыва процессов на этапе понимания и инноваций. Дождавшись, пока будет выбран вариант процесса на шаге 10 и 11, можно избежать разработки нескольких версий этого документа. Цель данного шага – сравнение новых и старых процессов для бизнес-подразделения, подразделения ИТ и разработчиков учебных материалов. Анализ разрыва процессов должен охватывать следующие моменты:

• краткий обзор действующих процессов;

• краткий обзор новых перестроенных процессов;

• основные изменения между двумя этими состояниями;

• проблемы процессов;

• соответствующие метрики;

• замечания по воздействию бизнеса и процессов;

• новые (бизнес) возможности;

• требуемые изменения (например, в ИТ).

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

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

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

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

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

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

Цель отчета – описать состояние проекта, полученные результаты и рекомендации этапа инноваций; отчет должен сопровождаться профессиональной презентацией. Это возможность для группы и спонсора проекта убедить руководителей высокого уровня в разумности рекомендаций, чтобы продолжить финансирование (если оно еще не утверждено).

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

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

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

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

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