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

Группа проекта должна сузить варианты процессов до небольшого числа, и цель следующей серии практических совещаний – объединение всех заинтересованных сторон, чтобы определить, отвечают ли предлагаемые варианты всем их запросам. Среди заинтересованных сторон должны быть представлены:

• бизнес-подразделения;

• внешние заинтересованные стороны (каналы распределения, поставщики, возможно, инвесторы);

• персонал обеспечения действующего законодательства;

• информационные технологии;

• контроль операционных рисков;

• внутренний аудит;

• (возможно) внешний аудит, в зависимости от процессов.

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

Не все заинтересованные стороны, вероятно, следует объединять в одном совещании из-за возможно противоречивых требований.

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

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

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

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

Шаг 11. Доказательство и проверка практической реализуемости предлагаемых решений

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

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

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

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

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

Шаг 12. Анализ разрыва процессов

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

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

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

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

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

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

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

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

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