Роман Исаев: Управление проектами в банке

Управление проектами: основные понятия и стандарты

Проект – уникальная деятельность, предполагающая координированное выполнение взаимосвязанных действий для достижения определенных целей в условиях временных и ресурсных ограничений. [3]

Управление проектами – это приложение знаний, навыков, инструментов и методов к работам проекта для удовлетворения требований, предъявляемых к проекту. [4]

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

Отдел управления проектами (или проектный офис, Project Management Office) – это подразделение банка, осуществляющее функции по централизованному управлению проектами.

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

Проектная группа (рабочая группа) – группа, составленная из сотрудников банка, компетенции и деятельность которых необходима для решения задач проекта; подчиняется напрямую руководителю проекта.

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

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

1. Организационная структура и человеческие ресурсы.

Включает: проектный офис, рабочие группы по проектам, комитет по развитию, «владельцы» бизнес-процессов, высшее руководство банка.

2. Процедуры, регламенты и методики по управлению проектами, проектная документация.

3. Программные продукты и технические средства по управлению проектами.

Классификация проектов, проекты развития

Перечислим некоторые критерии для классификации проектов.

§ По масштабу

§ По длительности

§ По предметной области

§ По используемым технологиям проектного управления

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

В рамках данной работы нас интересуют проекты развития.

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

Это не относится к отдельным локальным задачам / программам развития, которые регулярно реализуются в банке.

Выделим следующие типы проектов развития в соответствии с областями менеджмента.

§ Проекты по стратегическому управлению. Например, построение системы сбалансированных показателей (BSC/KPI).

§ Проекты по управлению бизнес-процессами. Например, описание, регламентация и оптимизация бизнес-процессов.

§ Проекты по управлению персоналом и оргструктурой. Например, оптимизация организационной структуры и расчет оптимальной численности персонала.

§ Проекты по управлению качеством. Например, построение системы менеджмента качества по стандартам серии ISO 9000.

§ Комплексные проекты. Выполнение взаимосвязанных проектов по нескольким областям менеджмента.

К данному перечню можно также отнести проекты по внедрению / совершенствованию информационных систем (ИС) банка.

Более подробная информация об особенностях перечисленных выше проектов и методиках их выполнения представлена в [2].

Стандарты управления проектами

Систематизацией и распространением успешного опыта в виде стандартов и руководств занимается ряд учреждений, одним из которых является институт проектного управления – PMI (Project Management Institute). Данным институтом разрабатывается Руководство к своду знаний по управлению проектами (Project Management Body of Knowledge) – сокращенно Руководство PMBOK [4].

В Руководстве PMBOK выделено и подробно описано 5 групп процессов управления проектами:

§ инициация

§ планирование

§ исполнение

§ мониторинг и контроль

§ завершения

и 9 областей знаний по управлению проектами:

§ управление интеграцией проекта

§ управление содержанием проекта

§ управление сроками проекта

§ управление стоимостью проекта

§ управление качеством проекта

§ управление человеческими ресурсами проекта

§ управление коммуникациями проекта

§ управление рисками проекта

§ управление закупками проекта.

Знание и применение положений Руководства PMBOK значительно увеличивает эффективность управления проектами.

Методика управления проектами

На основе анализа наиболее востребованных на практике положений Руководства PMBOK и опыта по реализации проектов развития в банках автором разработана методика управления проектами – см. Рис. 1.

Следует различать методику управления проектами и методики реализации конкретных проектов (например, методика построения системы менеджмента качества в банке – см. [2]).

Рассмотрим более подробно этапы методики.

Рис. 1. Методика управления проектами

1. Инициация проекта

1.1. Подача и генерация инициатив

Инициирование проекта может происходить двумя путями.

§ На основе внутренних потребностей банка и инициатив сотрудников.

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

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

§ На основе изменения и требований внешней среды банка.

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

Результат этапа: правильно оформленная инициатива.

Стандартная форма документа «Инициатива» включает в себя следующие поля.

§ ФИО и должность сотрудника (инициатора)

§ Название (тема) инициативы

§ Структурные подразделения и бизнес-процессы, которые затрагивает инициатива

§ Подробное описание инициативы и способов ее реализации (цели, идеи и предложения)

§ Результат инициативы (желательно с указанием сроков и количественных оценок)

1.2. Презентация и рассмотрение инициатив

Все инициативы попадают на рассмотрение в Комитет по развитию или другой комитет / подразделение (в зависимости от конкретного банка), который занимается их рассмотрением.

В процессе рассмотрения инициатив выполняются следующие задачи.

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

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

§ Актуальность инициативы, ее соответствие стратегии и стратегическим целям банка.

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

§ Оценка рисков по реализации инициативы.

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

1.3. Официальное открытие проекта

На данном этапе выполняются следующие задачи.

§ Разработка задания на проект. Данное задание включает в себя уточненную (дополненную) информацию из документа «Инициатива», информацию, подготовленную на этапе «Презентация и рассмотрение инициатив», требования к проекту. На основе задания на проект далее будет разрабатываться План проекта.

§ Издание приказа об официальном открытии проекта, назначение Руководителя проекта, Лидера / инициатора проекта, Спонсора / заказчика проекта – см. Рис. 2.

Результат этапа: задание на проект, приказ об открытии проекта.

2. Планирование проекта

Важно понимать, что время и усилия, затраченные на планирование проекта, многократно окупят себя на этапе его реализации. Для некоторых банковских проектов длительность этапа «Планирование проекта» иногда даже совпадает с длительностью этапа «Исполнение и контроль проекта».

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

2.1. Подготовка нормативных документов по проекту

Каждый проект развития относится к определенной предметной области, поэтому для выполнения проекта необходимо использовать соответствующие методики и стандарты принятые в этой области. От выбора методики зависит план проекта, объем привлекаемых человеческих и финансовых ресурсов, результат проекта в целом. Например, для успешного выполнения проекта построения системы менеджмента качества в коммерческом банке рекомендуется использовать методику и стандарты ISO 9000. Основные методики по проектам развития и примеры их реализации доступны в [2].

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

В качестве одного из основных исходных материалов для выполнения проектов развития автор рекомендует Комплексную типовую бизнес-модель коммерческого банка [1], в которой собраны модели и нормативные документы по основным областям деятельности и системам управления банка: стратегия и BSC/KPI, бизнес-процессы и методология, организационная структура и персонал, система менеджмента качества и др. Данная комплексная типовая бизнес-модель подготовлена на основе систематизации опыта и результатов проектов большого количества банков разного масштаба и профиля деятельности.

Результат этапа: нормативные документы по проекту.

2.2. Разработка общего плана проекта

Общий план проекта представляет собой перечень всех этапов проекта (или иерархическую структуру работ – ИСР) и их взаимосвязей. По каждому этапу проекта необходимо указать приблизительную длительность, которая затем будет уточнена при разработке календарного плана.

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

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

Когда готов Общий план проекта, можно приступить к определению человеческих, финансовых и других ресурсов по всем этапам.

2.3. Организация проектных (рабочих) групп и распределение ролей в проекте

Одним из главных ресурсов проекта являются сотрудники банка и их время.

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

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

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

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

Далее необходимо выполнить следующие мероприятия.

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

2. Закрепить рабочие группы и их участников за этапами проекта, назначить ответственных за этапы проекта (по аналогии, как для бизнес-процесса назначается «владелец»). Классическое правило: у каждого этапа проекта должен быть только один ответственный.

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

4. Начать последовательную работу с рабочими группами.

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

§ Распределить задачи по сотрудникам рабочей группы.

§ Консультировать сотрудников по выполнению задач, часть задач выполнять совместно, рецензировать и обрабатывать результаты.

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

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

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

С примерами типовых показателей и моделей для большинства бизнес-процессов банка можно ознакомиться в [1].

Очень важно правильно распределить и официально закрепить роли среди участников проекта.

Рассмотрим перечень ролей и их функций в рамках типового банковского проекта – см. Табл. 1 и Рис. 2. Отметим, что в реальности следующие роли могут совмещаться одним субъектом (сотрудником).

§ Лидер / инициатор проекта и спонсор / заказчик проекта.

§ Руководитель проекта, организатор (куратор) проекта, главный методолог проекта.

Рис. 2. Организационная структура проекта

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

Принцип № 2: Лидерство руководителей. Руководители обеспечивают единство цели и направления деятельности организации. Им следует создавать и поддерживать внутреннюю среду, в которой работники могут быть полностью вовлечены в деятельность по достижению целей организации.

Принцип № 3: Вовлечение работников. Работники всех уровней составляют основу организации и их полное вовлечение дает возможность организации с выгодой использовать их способности.

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

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

Чем крупнее и сложнее проект, тем больше рабочих групп требуется создавать и соответственно больше их иерархия. Т.е. это может быть одна главная рабочая группа, либо одна главная рабочая группа и несколько подчиненных ей специализированных рабочих групп (по областям, бизнес-процессам, этапам проекта и т.п.). Таким образом в организационной структуре проекта получается несколько уровней – см. Рис. 2.

Рекомендуется также ознакомиться с общими темами, методами и примерами по управлению организационной структурой и персоналом банка, которые представлены в [2].

Приведем пример организации рабочих групп и распределения ролей в проекте по описанию бизнес-процессов в среднем банке (численность сотрудников около 400 человек).

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

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

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

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

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

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

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

Банк приглашает консалтинговую компанию или принимает в штат необходимых специалистов для реализации проекта развития. Специалисты начинают работу согласно всем современным методикам управления. Они разрабатывают необходимые документы, программы и т.п.

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

Рабочие группы не создаются, нет явного Лидера / Организатора со стороны банка, либо он не справляется со своей ролью в проекте.

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

Результат этапа: приказы о создании и составе рабочих групп.

2.4. Назначение ресурсов и бюджета проекта

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

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

При большом количестве и сложной структуре ресурсов проекта удобно строить Дерево (иерархический список) ресурсов.

Распределение ресурсов по этапам проекта удобно выполнять с помощью Таблицы итогового плана проекта – см. Табл. 4, либо специальной матрицы распределения ресурсов по этапам проекта – см. Рис. 3.

Важно определить доступность и загрузку ресурсов на каждом этапе проекта. Могут возникать ситуации, когда объем использования ресурса превышает его физический лимит, либо ресурс недоступен из-за объективных факторов. Тогда необходимо так называемое «выравнивание ресурсов». [3]

Например, в программном продукте могут одновременно работать 5 человек, а на определенном этапе проекта требуется вовлечение в работу 8 человек. Таким образом, часть задач необходимо перенести на другие промежутки времени (этапы), когда загрузка программного продукта составляет менее 5 человек.

Пример итогового бюджета проекта представлен в Табл. 2.

Результат этапа: бюджет проекта.

Табл. 2. Бюджет проекта (фрагмент)

Рис. 3. Матрица распределения ресурсов по этапам (работам) проекта

2.5. Разработка плана по рискам

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

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

Фрагмент плана по рискам представлен в Табл. 3.

Табл. 3. План по рискам (фрагмент)

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

Как правило, ни один проект по развитию в банке не проходит идеально и без рисков, поэтому данному этапу следует уделить особое внимание.

Результат этапа: план по рискам.

2.6. Разработка календарного плана

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

Например, если в рабочей группе будет 12 человек, то это одна длительность этапа, если в рабочей группе 5 человек, это намного большая длительность. Если для выполнения задач проекта будет приобретен специализированный программный продукт – это одна длительность проекта, а если нет – то на выполнение проекта уйдет больше времени, т.к. программный продукт позволяет автоматизировать часть задач, экономя при этом время специалистов.

Пример календарного плана в составе Итогового плана проекта представлена на Рис. 4.

Результат этапа: календарный план.

2.7. Разработка и утверждение Итогового (главного) плана проекта

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

Рассмотрим пример Итогового плана проекта построения системы менеджмента качества (СМК) в коммерческом банке. Текстовый формат данного плана имеет следующий вид.

1. Оценочный аудит СМК банка.

Начало – завершение: 18.01.2010 – 22.01.2010. Длительность 5 дней.

Исполнитель: служба качества.

Вход: нормативные документы банка, интервью сотрудников банка.

Выход: отчет по оценочном аудиту СМК банка.

2. Создание и обучение рабочей группы по СМК.

Начало – завершение: 25.01.2010 – 27.01.2010. Длительность 3 дня.

Исполнитель: служба качества.

Вход: учебные материалы по СМК.

Выход: обученная рабочая группа.

3. Описание и разработка стандартов основных бизнес-процессов банка

Начало – завершение: 28.01.2010 – 31.03.2010. Длительность 45 дней.

Исполнитель: служба качества, «владельцы» и исполнители бизнес-процессов, рабочая группа

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

Выход: стандарты основных бизнес-процессов банка.

4. Разработка обязательных процедур СМК

Начало – завершение: 01.04.2010 – 16.04.2010. Длительность 12 дней.

Исполнитель: служба качества, рабочая группа

Вход: типовые описания обязательных процедур СМК, интервью сотрудников банка.

Выход: модели и регламенты процедур СМК

5. Разработка Политики в области качества и Руководства по качеству

Начало – завершение: 19.04.2010 – 04.05.2010. Длительность 12 дней.

Исполнитель: служба качества, Правление банка

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

Выход: политика в области качества, руководство по качеству.

6. Разработка / доработка необходимой документации для СМК

Начало – завершение: 19.04.2010 – 04.05.2010. Длительность 12 дней.

Исполнитель: служба качества, рабочая группа

Вход: образцы документации СМК, нормативные документы банка, интервью сотрудников банка.

Выход: документация СМК.

7. Проведение внутреннего аудита СМК в банке

Начало – завершение: 05.05.2010 – 11.05.2010. Длительность 5 дней.

Исполнитель: служба качества.

Вход: документация СМК, интервью сотрудников банка.

Выход: отчет по внутреннему аудиту.

8. Проведение обучения по СМК всех сотрудников банка – участников СМК

Начало – завершение: 12.05.2010 – 14.05.2010. Длительность 3 дня.

Исполнитель: служба качества.

Вход: документация СМК, учебные материалы.

Выход: обученные сотрудники банка.

Комбинированный и табличный форматы Плана проекта показаны на Рис. 4 и в Табл. 4.

Рис. 4. Пример Плана проекта в комбинированном формате (диаграмма Гантта, Gantt Chart)

Табл. 4. Шаблон Итогового плана проекта в табличном формате

Очередность столбцов в данном шаблоне Итогового плана проекта (Табл. 4) полностью отражает последовательность их заполнения. Т.е. сначала на основе выбранной методики и установленного задания на проект заполняется перечень и характеристики этапов проекта (столбцы 1-5 в Табл. 4), затем заполняется перечень необходимых ресурсов проекта (столбцы 6-7). Затем на основе характеристик этапов и ограничений в ресурсах заполняются сроки проекта (столбцы 8-10).

Выполнение этапов отслеживается в столбце 11 «процент выполнения».

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

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

Если проект предполагает большое вовлечение сотрудников, то помимо Плана проекта для каждого этапа должен быть План встреч с необходимыми сотрудниками банка. И если проект идет активно, то каждый день проводится около 2-3-х часов встреч и интервью с рабочими группами и сотрудниками банка.

Рис. 5. Иерархия и взаимосвязь планов проекта

Результат этапа: итоговый (главный) план проекта.

3. Исполнение и контроль проекта

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

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

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

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

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

1. Неправильность плана, нереальность сроков, отсутствие необходимых ресурсов. В этом случае необходима тщательная корректировка плана и всех его составляющих (см. «Этап 2. Планирование проекта»).

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

4. Завершение проекта

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

4.1. Подготовка и презентация Итогового отчета по проекту

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

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

4.2. Анализ Итогового отчета по проекту

Заказчик проекта и представители высшего руководства банка на основе проведенной презентации и анализа Итогового отчета принимают решение по проекту. Возможны 2 варианта.

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

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

4.3. Официальное закрытие проекта

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

На данном этапе также выполняется распределение мотивационного фонда проекта среди его участников, что оформляется отдельным приказом. При распределении мотивационного фонда Руководитель проекта оценивает вклад каждого участника в результаты проекта, определяет коэффициенты их трудового участия и рассчитывает величину вознаграждения.

4.4. Архивация всех материалов проекта

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

Автоматизация управления проектами

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

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

Перечислим наиболее известные и распространенные программные продукты класса «Управление проектами»: Microsoft Office Project 2007, Primavera Project Planner Professional, Spider Project Professional, Deltek Enterprise Project Management Solutions. Более подробная информация доступна на веб-сайтах разработчиков соответствующих продуктов.

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

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

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

Также на рынке есть такие решения: Бизнес-инженер, ARIS, AllFusion Process Modeler, MS Visio.

Более подробная информация доступна в [2].

Заключение

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

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

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

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

Источники информации

[1] Комплексная типовая бизнес-модель коммерческого банка.

[2] Исаев Р.А. Бизнес-инжиниринг и управление в коммерческом банке. – М.: ГОЛОС-ПРЕСС, 2009. – 318 с. Ил.

[3] Ковалев С., Ковалев В. Секреты успешных предприятий: бизнес-процессы и организационная структура – М.: ГОЛОС-ПРЕСС, 2009. – 520 с. Ил.

[4] Руководство к своду знаний по управлению проектами (PMBOK) 4-е издание. – PMI, 2008.