Джон Джестон - Управление бизнес-процессами. Практическое руководство по успешной реализации проектов
Вывод. Выбор опытного бизнес-менеджера для проекта BPM – это одно из наиболее важных решений, связанных с проектом. Потратьте необходимое время и деньги, чтобы назначить правильного человека на эту должность, и он отплатит вам сторицей на протяжении всего срока жизни проекта.
Каждая из этих ролей кратко описана в данной главе, а более подробно – в Приложении С.
1. Глава подгруппы. Возглавляет подгруппу и ведет направление работ, обеспечивая организацию практических совещаний, разработку плана проекта (вместе с менеджером проекта), соблюдение плана – графика работ, выполнение бюджета и т. п.
2. Глава пользователей. Это лицо – бизнес-ресурс, назначаемый бизнес-руководством. Оно наделено полномочиями принимать решения от имени бизнес-подразделений.
3. Представители пользователей в подгруппе. Технические специалисты или эксперты в областях знаний из бизнес-подразделений. Их выбирает глава пользователей.
4. Специалисты по процессам. Эта группа формируется в Центре совершенствования бизнес-процессов, обеспечивая квалифицированную помощь и профессионализм:
• при проектировании, разработке и реструктурировании (перестройке) процессов;
• в инструментарии разработки процессов, используемом в проекте;
• в раздельном учете затрат по типам деятельности;
• в имитационном моделировании процессов;
• в планировании ресурсов;
• во взаимодействии процессов.
Если в организации нет Центра совершенствования бизнес-процессов или профессионалов внутри, то опыт и знания в этой области может предоставить специализированная консалтинговая организация BPM.
Подгруппа разработки ИТ
Члены этой подгруппы в большинстве своем являются специалистами во взаимодействии систем. Они обладают опытом и знаниями и работают с другими подгруппами, чтобы интерфейсы процессов с различными системами работали успешно.
Подгруппа управления документами
В данную подгруппу входят специалисты по управлению документами и бизнес-персонал, который разбирается в документообороте и использовании документов в своих бизнес-областях. Эта подгруппа вносит вклад в работу других подгрупп, обеспечивая гладкую интеграцию документов и изображений в каждый процесс.
Шаг 9. Разработка исходного плана проекта
Исходный план проекта подробно охватывает этап понимания с включением шагов этапа инноваций, но на данной фазе без увязки по срокам этого этапа.
По нашему опыту должно быть проведено не более четырех практические совещаний «понимания» по 3–4 часа в неделю, а время между ними следует посвятить отработке моделей, рассмотрению и анализу результатов исследований в бизнес-подразделениях (включая анализ корневых причин), сбору и завершению анализа метрик. Более подробно это рассматривается в главе 16.
Количество смоделированных на каждом практическом совещании процессов зависит от объема и сложности процессов.
Нельзя забывать о включении в план проекта действий на случай непредвиденных обстоятельств и следует иметь в виду, что составление отчета по окончании этого этапа всегда отнимает больше времени, чем вы думаете, так что отведите на отчет достаточно времени – тут нельзя торопиться. На самом деле отчет заполняется по ходу проекта. В Приложении С приведены типовые формы отчета и плана проекта.
Реализация ценности
На данном этапе должны быть определены и спланированы потенциальные выигрыши. Обратитесь к шагу 2 главы 21, где это описано в контексте реализации ценности в проекте.
Конкретные итоги этапа стартовой площадки
Информация, выработанная на этапе стартовой площадки, будет использована на входе различных этапов, как показано на рис. 15.11.
Очевидно, что она будет применяться на входе этапа понимания, где разрабатывается план проекта, процессы ранжируются посредством матрицы выбора процессов, решаются вопросы исходных метрик и бизнес-обоснования, а также определяется документация проекта. Бóльшая часть этой информации, например задачи процессов, также перетечет на этап инноваций.
Риски этапа стартовой площадки
На данном этапе формируется платформа, с которой будут запускаться проекты. Как и в любом проекте, если платформа неправильно установлена, будет трудно вернуть проект на верный путь. Необходимо учесть несколько рисков и реализовать стратегию борьбы с ними, чтобы устранить (или хотя бы снизить) их. Некоторые из рисков указаны в табл. 15.3.
Таблица 15.3. Риски этапа стартовой площадки и стратегии их снижения
Глава 16
Этап понимания
Назначение
Цель этапа понимания (рис. 16.1) – достижение членами группы проекта и бизнес-подразделением достаточного понимания действующих бизнес-процессов, что позволит приступить к этапу инноваций. Это предусматривает сбор соответствующих метрик, который позволит лучше понять, определить приоритеты инноваций/перестройки и установить сравнительные реперные точки отсчета для текущего состояния. Такие точки дают возможность проводить сравнение с будущими сценариями инноваций процессов, которые будут определены на следующем этапе (инноваций) и позволят завершить шаги имитационного моделирования и раздельного учета затрат по типам деятельности.
Группа проекта должна также понимать бизнес-цель данного этапа. Созданные модели процессов могут применяться не только как входные данные для этапа инноваций, но и как модели для обучения и документирования на этапах инноваций и внедрения.
Этап понимания должен также подтвердить правильность ви́дения реально действующих процессов внутри организации и определить приоритеты совершенствований в рамках проекта. Это поможет выявить требуемые изменения в процессах, если они вообще необходимы.
Решающим моментом здесь является стремление группы проекта и бизнеса понять процессы, а не только задокументировать их вплоть до мельчайших подробностей. Если процесс четко понят и задокументирован, можно нажать на тормоз: этого достаточно. Если с бизнесом достигнуто согласие о возможности применения моделей процессов для документирования и обучения, нужно оговорить уровень детализации в моделях процессов.
Результаты
Бизнес может рассчитывать на несколько результатов и выходных данных этого этапа, в том числе:
