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

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

Конкретные результаты этапа понимания включают:

1. Перечень моделей сквозных процессов.

2. Перечень сквозных подпроцессов.

3. Модели действующих процессов с детализацией, достаточной для выполнения этапа инноваций.

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

5. Перечень основных проблем процессов, определенных бизнес-подразделениями.

6. Определение приоритетов для инноваций.

7. Выявление возможностей быстрых выигрышей.

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

9. Отчет по этапу.

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

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

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

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

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

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

Если сравнить два подхода, ясно видно, что, несмотря на аргумент увеличения вложений на ранней стадии, преимущества такого подхода существенно выше по сравнению с традиционным подходом (рис. 15.9 – Regatta® фирмы Sogeti Nederland).

В презентации «Привязка ИТ к эффективности предприятия: важна реализация», сделанной Джорджем Лори из Forrester Research 21 мая 2003 года в Амстельвине, Голландия, на церемонии представления книги Regatta® фирмой Sogeti Nederland говорилось: «Неважно, сколько вы тратите на ИТ, важно – какие технологии вы покупаете, но самое важное – как вы их внедряете». Этот вывод следует из осознания, что все больше и больше организаций покупает и внедряет стандартные готовые пакеты, так что конкурентное преимущество проистекает не из самого инструментария, а из того, как он сконфигурирован и реализован в организации.

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

Кейс: преждевременное внедрение

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

Внедрение проходило в навязанные сроки и действительно вызвало операционный хаос, но мы впоследствии узнали, что руководитель организации получил существенную премию за реализацию проекта «в срок»!

Вывод. Анализ заинтересованных сторон и понимание факторов, которые движут ими, очень важны для успешного итога проекта.

Следует использовать стандартную типовую форму бизнес-обоснования, принятую в организации. Помимо обычного содержания обоснования BPM (которое подробно описано в Приложении C), данное обоснование должно также включать:

• анализ приращения экономической ценности (EVA);

• внутреннюю подготовку предложений;

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

• рассмотрение «за» и «против» различных вариантов;

• использование критериев оценки сценариев и эффективности.

Группе проекта ни в коем случае не следует отстаивать сделанные рекомендации, а только давать их и объяснять возможные варианты объективно и непредвзято {5}.

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

Следует иметь в виду, что это лишь исходное обоснование, которое может обосновать либо весь проект BPM, либо дальнейшее финансирование разработки подробного обоснования полного проекта. Бизнес-обоснование необходимо обновить или доработать на этапе инноваций, чтобы оправдать продолжение проекта BPM (см. шаг 13 в главе 17).

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

Эта типовая структура проекта предназначена для широкомасштабной программы или проекта внедрения BPM. Ее нужно адаптировать к конкретным требованиям организации и проекта. Группа проекта редко начинает проект в таком составе на этапе стартовой площадки. Однако необходимо определить и спланировать будущую структуру группы проекта. Количество и состав направлений работы, показанные на рис. 15.10, будут зависеть от проекта и используемых элементов автоматизации. Мы представили только одно направление для элемента управления документами; очевидно, что будут и другие для реализации модуля – машины процессов (потока работ – workflow) и бизнес-правил. Данная структура, однако, оказалась особенно эффективной, так что ее излишняя модификация может привести к снижению результативности.

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

Мы настоятельно рекомендуем две ведущие должности в структуре проекта:

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

2. Привлечение такого опытного консультанта BPM настоятельно рекомендуется не только для курирования и обучения бизнес-менеджера проекта, если тому не хватает знаний BPM, но и для оказания помощи:

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

• в сохранении фокуса и направленности проекта и его самофинансировании и создании реальной ценности для бизнеса;

• в нахождении дополнительных возможностей бизнеса, которые могут реализовываться BPM;

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

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

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

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

Структура более мелких проектов BPM может потребовать объединения некоторых должностей, но лидерство чрезвычайно важно для любого проекта, особенно для проекта BPM, поэтому в данной области не должно быть никаких отступлений. Более подробно лидерство и ведущая роль рассмотрены в главе 26.

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

Этот комитет рассматривался на этапе архитектуры процессов.

Группа проекта разбивается на различные проектные подгруппы (часто их называют направлениями работ). Разумеется, количество подгрупп зависит от размера проекта и его сложности. В крупном проекте с автоматизацией можно предположить наличие небольшой подгруппы специалистов по процессам (возможно из Центра совершенствования бизнес-процессов), подгруппы ИТ, занимающейся вопросами интерфейса и другими работами по системной разработке, а также подгруппы, владеющей вопросами управления документами, которая оказывает консультационную помощь всем подгруппам, особенно выполняющим анализ и инновации процессов. В зависимости от размера проекта в каждую подгруппу входят следующие специалисты:

• глава подгруппы;

• глава пользователей;

• представители подгруппы пользователей;

• специалисты по процессам.

Кейс: необходимость в знающем бизнес-менеджере проекта с опытом BPM

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

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

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

Каждая из этих ролей кратко описана в данной главе, а более подробно – в Приложении С.

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

2. Глава пользователей. Это лицо – бизнес-ресурс, назначаемый бизнес-руководством. Оно наделено полномочиями принимать решения от имени бизнес-подразделений.

3. Представители пользователей в подгруппе. Технические специалисты или эксперты в областях знаний из бизнес-подразделений. Их выбирает глава пользователей.

4. Специалисты по процессам. Эта группа формируется в Центре совершенствования бизнес-процессов, обеспечивая квалифицированную помощь и профессионализм:

• при проектировании, разработке и реструктурировании (перестройке) процессов;

• в инструментарии разработки процессов, используемом в проекте;

• в раздельном учете затрат по типам деятельности;

• в имитационном моделировании процессов;

• в планировании ресурсов;

• во взаимодействии процессов.

Если в организации нет Центра совершенствования бизнес-процессов или профессионалов внутри, то опыт и знания в этой области может предоставить специализированная консалтинговая организация BPM.

Члены этой подгруппы в большинстве своем являются специалистами во взаимодействии систем. Они обладают опытом и знаниями и работают с другими подгруппами, чтобы интерфейсы процессов с различными системами работали успешно.

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

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

По нашему опыту должно быть проведено не более четырех практические совещаний «понимания» по 3–4 часа в неделю, а время между ними следует посвятить отработке моделей, рассмотрению и анализу результатов исследований в бизнес-подразделениях (включая анализ корневых причин), сбору и завершению анализа метрик. Более подробно это рассматривается в главе 16.

Количество смоделированных на каждом практическом совещании процессов зависит от объема и сложности процессов.

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

На данном этапе должны быть определены и спланированы потенциальные выигрыши. Обратитесь к шагу 2 главы 21, где это описано в контексте реализации ценности в проекте.

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

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

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

Таблица 15.3. Риски этапа стартовой площадки и стратегии их снижения

Глава 16
Этап понимания

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

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

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

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

Бизнес может рассчитывать на несколько результатов и выходных данных этого этапа, в том числе:

1. Модели действующих сегодня процессов.

2. Адекватные метрики, достаточные для установления точек отсчета при измерении усовершенствований процессов в будущем, расстановки приоритетов и выбора процессов для этапа инноваций.

3. Измерение и документальное фиксирование текущих или фактических уровней эффективности.

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

5. Выявление быстрых выигрышей, которые могут быть реализованы в течение трех-шести месяцев.

6. Отчет этапа.

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

• «понимайте», что фактически происходит, и убедитесь, что документированное отражает реальную, а не воображаемую (как должно было бы быть) ситуацию;

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

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

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

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

Кейс: чрезвычайно важно участие в практических совещаниях нужных людей

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

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

Ниже приводится несколько аргументов «за» и «против» моделирования на этапе понимания.

Аргументы в пользу моделирования процессов:

1. Достижение общего понимания и общего языка проблемы.

2. Выявление изъянов сложившейся ситуации.

3. Поддержка одобрения «разморозки» проекта.

4. Возможность оценить завершенность инноваций процессов.

5. Созданные модели могут использоваться для документации процесса, если нет острой необходимости изменения процессов.

6. Персонал привыкает к процессному мышлению и моделированию процессов.

7. Определение точки отсчета для взаимодействия процессов с организацией, ИТ и персоналом.

Аргументы против моделирования процессов:

1. Сегодняшняя моделируемая ситуация устаревает, едва только спроектированы новые процессы и внедрены перестроенные процессы.

2. Всегда существует опасность «узкофокусного» проектирования процессов, что налагает ограничения на осмысление инноваций процессов.

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

4. Существует опасность перегрузиться информацией и погрязнуть в деталях.

Шаги, выполняемые на этапе понимания, показаны на рис. 16.2.