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

Джестон Джон

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

Шаг 8. Обновление матрицы способностей персонала

На шаге 6 этапа понимания подчеркивалась необходимость заполнения матрицы способностей персонала. Эту матрицу (см. рис. 16.4) нужно пересмотреть или сформировать для будущих новых процессов (процесса). Затем собранные сведения будут использованы

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

Шаг 9. Планирование персонала

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

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

Шаг 10. Обсуждение предлагаемых решений на совещаниях

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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