• Главная
•  > 
• Статьи
•  > 
• Организация и управление проектами развития в коммерческом банке

Организация и управление проектами развития в коммерческом банке

Роман Исаев

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

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

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

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

Управление проектами – это приложение знаний, навыков, инструментов и методов к работам проекта для удовлетворения требований, предъявляемых к проекту. [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.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. Отметим, что в реальности следующие роли могут совмещаться одним субъектом (сотрудником).

• Лидер / инициатор проекта и спонсор / заказчик проекта.
• Руководитель проекта, организатор (куратор) проекта, главный методолог проекта.

Табл. 1. Распределение ролей и функций в проекте

№	Роли	Выполняемые функции и обязанности в проекте
1.	Спонсор / заказчик проекта	генерирует главную идею и задание на проект согласует и принимает результаты проекта участвует в обсуждении промежуточных результатов и задач (при необходимости) выделяет ресурсы (прежде всего, финансовые)
2.	Лидер / инициатор проекта	инициирует проект, готовит его предварительное обоснование и предложения по реализации, согласует их с заказчиком проекта обеспечивает продвижение проекта на всех уровнях в банке и его успешное выполнение отвечает за мотивацию персонала банка в проекте, демонстрирует личную заинтересованность в проекте контролирует деятельность и результаты работы рабочих групп организует выделение и распределение ресурсов в проекте принимает ключевые решения по проекту
3.	Руководитель проекта	выполнение всех функций по управлению проектом определение структуры и состава рабочих групп в проекте определение требований к участникам рабочих групп выполнение всех распоряжений лидера / инициатора проекта
4.	Организатор (куратор) проекта	отвечает за вовлечение сотрудников банка в проект, взаимодействие с руководителями структурных подразделений банка, проведение встреч и совещаний, решение всех организационных вопросов
5.	Главный методолог проекта	отвечает за методическую часть проекта, подготовку всех материалов проекта организация и проведение обучения участников проекта – рабочих групп
6.	Главная рабочая группа / методологи	централизованное распределение и координация всех задач по проекту выполнение задач, где не требуется помощь экспертов выполнение всех распоряжений Руководителя проекта
7.	Рабочие группы по областям / эксперты	выполнение специализированных задач по своей предметной области / бизнес-процессу и предоставление результатов Руководителю проекта / главной рабочей группе Консультирование Руководителя проекта и главной рабочей группы по вопросам своей компетенции
8.	Руководитель подразделения / «владелец» процесса – Начальник рабочей группы	предоставление Руководителю проекта всей необходимой информации по своим сотрудникам определение совестно с Руководителем проекта требований к каждому назначенному члену рабочей группы согласование времени участия и загрузки своих сотрудников в проекте обеспечение сотрудникам – участникам рабочей группы возможности отрыва от текущей деятельности обеспечение эффективного участия своих подчиненных в проекте

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

№	Ресурс	Общая стоимость, руб.
1	Услуги консалтинговой компании	500 000
2	Оплата работы в проекте сотрудников банка	1 200 000
3	Командировочные расходы	100 000
4	Приобретение необходимой методической литературы	10 000
5	Приобретение программного обеспечения	250 000
6	Приобретение аппаратного обеспечения	200 000
7	Текущие расходы на МБП	50 000
	ИТОГ:	2 310 000

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

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

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

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

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

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

№	Риск	Важность	Вероятность	Предупреждающие действия	Корректирующие действия
1	Сотрудники банка не уделяют время для проекта / не выполняют задачи	Высокая	0,4	Создание мотивационного фонда для сотрудников, вовлекаемых в проект. Официальное закрепление за сотрудниками задач и сроков их реализации в проекте. Лидерство высшего руководства. Обучение сотрудников.	Перераспределение функций среди сотрудников. Реализация определён-ных санкций в отношении сотрудников. Лидерство высшего руководства.
2	Задержка сроков выполнения проекта	Средняя	0,2	Тщательное планирование проекта. Выявление и предупреждение рисков, влияющих на сроки. Необходимо заложить вре-менные резервы для каждого этапа проекта.	Модификация плана проекта. Привлечение дополни-тельных ресурсов.

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

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

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

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. Шаблон Итогового плана проекта в табличном формате

№	Этап	Вход	Выход	Описание этапа	Исполнители / Ответственный	Ресурсы, бюджет	Начало	Завершение	Длительность	% вы-полнения
1	2	3	4	5	6	7	8	9	10	11
...	...	...	...	...	...	...	...	...	...	...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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].

Заключение

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

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

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

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

журнал "Управление в кредитной организации" № 2/2010

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

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

[2] Исаев Р.А. Банковский менеджмент и бизнес-инжиниринг. – М.: ИНФРА-М, 2011. – 400 с. Ил.

[3] Методические рекомендации по организации функционирования системы менеджмента качества в коммерческом банке.

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

Вы можете задать автору интересующие Вас вопросы по телефону +7 (495) 796-11-35 или по электронной почте avtor@src-master.ru.

 Семинары автора с открытой датой:

• Операционные риски и операционная надёжность организаций: процессы, технологии, ИТ-архитектура
• Практика работы в системе Business Studio: моделирование и оптимизация бизнес-процессов и бизнес-архитектур
• Управление ИТ-архитектурой организации: проектирование, анализ, оптимизация и трансформация