• Главная
•  > 
• Статьи
•  > 
• Факторы успеха проектов развития в коммерческом банке

Факторы успеха проектов развития в коммерческом банке

Роман Исаев

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

Перечень факторов успеха проектов развития в банке

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

• Использование единых общепринятых стандартов, методик и технологий по управлению проектами. Детальное планирование проекта.
  Следует различать методику / стандарт управления проектами (например [3] или [4]) и методики реализации конкретных проектов (например, методика разработки системы сбалансированных показателей BSC/KPI банка – см. [2])
• Использование успешных отраслевых методик реализации проектов. Данные методики предписывают и поясняют, как выполнять этапы и задачи проекта. Например, как описывать бизнес-процессы банка, как определять и назначать показатели KPI, как разрабатывать Руководство по качеству и т.п.
• Использование типовых решений для получения результатов проекта (например, Комплексная типовая бизнес-модель коммерческого банка [1]). Это позволит заранее представлять себе результаты проекта и сократить время на их получение. Чтобы не выполнять с нуля разработки и задачи, рекомендуется брать за основу типовые решения и документы, а затем дорабатывать их под специфику банка и задачи проекта.
• Использование профессиональных программных продуктов класса «Управление проектами», которые позволяют автоматизировать все процессы управления проектами, таким образом повысить эффективность данной деятельности.
• Использование программных продуктов других классов для решения специализированных задач проекта (например, для описания и регламентации бизнес-процессов рекомендуется использовать программный продукт бизнес-моделирования «Business Studio»).
• Тщательная и комплексная оценка зрелости банка для реализации проекта. Не все банки изначально готовы к реализации проектов развития. При низком уровне зрелости банка следует выполнить необходимые мероприятия, чтобы подготовить банк, его сотрудников и инфраструктуру для начала проекта. Если этого сделать невозможно, то проект рекомендуется не запускать, иначе с большой вероятностью он будет неудачным.
• Уделение большого внимания и проработка организационной составляющей проекта. Это: официальное создание рабочих групп, тщательный подбор специалистов в рабочие группы, правильное распределение ролей в проекте и рабочих группах, активное обучение и вовлечение в проект персонала банка, чёткое закрепление задач проекта среди рабочих групп и сотрудников банка, лидерство руководства. Высшее руководство банка должно на своём примере показывать заинтересованность в проекте, уделять максимум времени и ресурсов для проекта.
• Официальный статус проекта, строгие установки по времени и промежуточным результатам проекта. Чтобы проект воспринимался в банке на должном уровне и все понимали его значимость, необходимо издание, утверждение и публикация официальных документов по проекту: приказ о начале проекта, приказы по рабочим группам, приказы по выделению ресурсов, План проекта, бюджет проекта. Все этапы проекта должны иметь фиксированные сроки выполнения и промежуточные результаты, по которым можно контролировать проект и оперативно предпринимать корректирующие действия.
• Управление рисками. До начала проекта следует определить все возможные риски и разработать перечень предупреждающих и корректирующих мероприятий.
• Системный подход к управлению проектом и его выполнению. Несмотря на то, что данный пункт стоит последним в перечне, ему следует уделять особое внимание.
Системный подход в данном случае означает: удовлетворение интересов и требований всех заинтересованных сторон в проекте (высшее руководство банка, персонал, клиенты, регулирующие органы и др.), взаимосвязь проекта с различными системами управления и областями деятельности банка, соблюдение перечисленных в данной работе факторов при планировании и в течение всего проекта.
Например, руководство банка установило такие показатели и сроки для проекта, что специалистам рабочих групп приходится работать по 10 часов в день. И если всё это не подкреплено соответствующей финансовой мотивацией, не выделены полностью все необходимые ресурсы, то интересы и возможности сотрудников войдут в конфликт с работой на проекте. А следствия могут быть самые разные: отказ сотрудников от участия в проекте, намеренное невыполнение задач проекта и переложение ответственности на других, формальная презентация результатов проекта, которые не соответствуют реальности и сильно преувеличены.

Проект или текущая деятельность

Следует различать проект и текущую деятельность банка, которая реализуется в виде бизнес-процессов. Текущая деятельность не требует применения специальных проектных методик и технологий, рабочих групп и дополнительных ресурсов.
На практике часто встречаются ситуации, когда задачи, ради которых запускается полномасштабный проект, гораздо дешевле, проще и эффективней выполнять в рамках текущей деятельности, пусть с намного большими сроками и чуть меньшими результатами.
Поэтому банку перед инициированием соответствующих задач необходимо принять правильное и взвешенное решение, в каком формате их выполнять: в виде полномасштабного проекта, либо в виде текущей деятельности на основе действующей оргструктуры и имеющихся ресурсов.
И иногда принимаются неправильные решения. Запускается проект с привлечением больших финансовых, человеческих и других ресурсов, а достаточно просто принять в штат ключевых структурных подразделений 1-2-х новых высококвалифицированных специалистов и закрепить за ними постоянные обязанности.
Некоторые банки, к сожалению, даже не подозревают о том, что та деятельность, которую они называют «проектами», на самом деле является обычной текущей деятельностью. И отсюда возникают все проблемы. Результаты хотелось бы получить, как в настоящем проекте – в полном объёме и в короткие сроки, а проекта на самом деле нет – нет официальных рабочих групп, нет детального и строгого планирования, нет достаточных ресурсов, нет активного вовлечения персонала и лидерства руководства и так далее.
Текущая деятельность подразумевает закрепление необходимых задач в функциональных подразделениях банка (например, в должностных инструкциях или положениях о подразделениях) и их решение в зависимости от приоритета и по мере загруженности персонала своими основными работами. Как говорится, если сегодня что-то не успели по объективным причинам, можно сделать завтра.
Управление данными задачами может быть возложено на подразделение (или представителя руководства банка), которые являются потребителями результатов.
Например, если рассмотреть задачу построения системы менеджмента качества (СМК) банка не в формате проекта, а в формате текущей деятельности, то можно получить следующую картину.
Работы по описанию / актуализации бизнес-процессов, необходимых для СМК, может взять на себя отдел бизнес-процессов и методологии и заниматься ими наряду с разработкой других бизнес-процессов и нормативных документов. При этом данные работы по СМК могут занять как 1 год, так и более.
Разработку / актуализацию и контроль показателей и требований к качеству бизнес-процессов может взять на себя подразделение банковских продуктов и продаж, а также главный технолог банка.
Ещё раз подчеркнём, что для всего этого не требуется создание новых структурных подразделений в банке и рабочих групп, не требуется разработка строго календарного плана и привлечение дополнительных ресурсов. Не нужно прорабатывать риски, не нужно заботиться о вовлечении персонала, т.к. необходимые задачи уже входят в постоянные текущие обязанности сотрудников банка.

Две стороны одного проекта

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

1. Методическая
Подразумевает следующие функции.
• Полную методическую подготовку проекта. Подготовка / разработка методик, нормативных документов и форм документов, используемых в проекте, а также типовых отраслевых примеров [1]. Например, соглашение по бизнес-моделированию, анкеты для описания бизнес-процессов, методика описания бизнес-процессов, типовые регламенты банковских бизнес-процессов и т.п.
• Обучение участников проекта методикам и научно-практическим материалам, на базе которых выполняется проект. Например, обучение стандартам ISO 9000 и методике построения системы менеджмента качества.
• Разработка Плана проекта и распределение задач по участникам проекта. Определение перечня необходимой информации и ресурсов для проекта.
• Консультирование участников проекта по всем методическим вопросам той предметной области, которой посвящён проект. Например, вопросы по менеджменту качества.
• Проведение интервью сотрудников. Сбор, обработка и агрегация информации от сотрудников по тем задачам, которые они не имеют возможности решить самостоятельно. Разработка на основе собранной информации необходимых документов, программ и т.п.
• Рецензирование результатов решения задач, подготовленных участниками проекта самостоятельно. Совместная доработка. Например, доработка моделей бизнес-процессов, которые подготовили владельцы процессов.
• Самостоятельное решение отдельных задач согласно плану проекта, которые не требуют привлечения участников проекта.
Сформулируем требования к методологу проекта.
• Глубокие знания и большой опыт реализации проектов по соответствующих областям менеджмента, методикам управления.
• Профессиональное владение специализированными программными продуктами, которые необходимы для проекта. Например, MS Office Project, Business Studio, MS Visio и др.
• Общие компетенции в банковской сфере.
• Личные качества: коммуникативность, системное мышление.
2. Организационная
Подразумевает следующие функции.
• Решение всех организационных вопросов в проекте. Т.е. организация совещаний и встреч, убеждение сотрудников банка, чтобы они выделяли время для проекта, внутренний PR проекта, обеспечение проекта ресурсами.
• Предоставление банковской информации для проекта по запросу методолога.
• Участие в решении задач по проекту.
Сформулируем требования к организатору проекта.
• Длительный срок работы в банке (желательно более 5 лет)
• Знание специфики и всех основных направлений деятельности банка (блока, если банк крупный).
• Хорошие контакты с ключевыми сотрудниками банка / блока и представителями руководства.
• Наличие необходимых полномочий для проекта и высокий авторитет среди ключевых сотрудников банка.
• Общие компетенции в областях менеджмента и современных методиках управления, используемых в проекте.
• Лидерские и организаторские качества.
• Личная заинтересованность в проекте и его результатах.
• Готовность выделять максимум времени для проекта.
Если вы претендуете на роль Организатора проекта или назначены банком на эту роль, то можно легко определить успешность выполнения данной роли, а значит и всего проекта. Для этого необходимо оценить каждый из вышеперечисленных пунктов, поставить плюс или минус (соответствие требованиям пункта или нет). Количество минусов допускается не более 1

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

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

Зрелость банка для реализации проектов развития

Изучая опыт работы на банковских проектах коллег-специалистов и их результаты, а также некоторые проекты с личным участием, автор выявил следующие интересные ситуации. Проекты хорошо планируются, используются необходимые ресурсы и программные продукты, есть достаточно квалифицированных специалистов и рабочих групп, даже есть Организаторы, двигающие проект вперёд. Но почему-то проект «буксует», выполняется очень медленно, в некоторых случаях не доходит до завершения, а если и завершается, то не с тем результатом, который планировался. Причин может быть достаточно много, и преодолеть их все не представляется возможным. Значит, для решения проблемы необходимо посмотреть на неё сверху, системно.
Оказывается, большинство этих причин сводятся к одной – зрелость банка для реализации определённого проекта развития. Зрелость банка и уровень его развития – несколько разные понятия (в рамках настоящей работы), хотя и пересекающиеся. Уровень развития – это накопленная совокупность прошлых достижений банка. Зрелость – это готовность и способность банка к будущим достижениям. Проекты развития также можно классифицировать по требуемым уровням зрелости банка. Например, проект требует от банка уровня зрелости 5, а у банка на текущий момент уровень зрелости 2. И что бы ни делалось для успеха проекта, он всё равно не будет на 100% успешным.

Определить зрелость банка для реализации проекта достаточно просто. Для этого необходимо оценить каждую категорию из Табл. 1, поставить по ней плюс или минус. Затем сложить количество плюсов и получить уровень зрелости. Всего в таблице 8 категорий зрелости, соответственно высший уровень зрелости банк будет иметь при удовлетворении всех категорий. Для каждой категории зрелости приведены описание, способ оценки (как и на основе чего оценить требования категории), способ удовлетворения (как удовлетворить требования категории). Перевод банка на более высокий уровень зрелости – сложная и небыстрая задача. Для этого необходимо реализовать перечень мероприятий, часть из которых описана в столбце «Способ удовлетворения» Табл. 1. Категория «Уровень развития» является специфической и зависит от конкретного проекта. Это обусловлено тем, что разные виды проектов требуют разного «фундамента» (наработок) в банке. [2]
Например, для проекта оптимизации бизнес-процессов требуется, чтобы в банке уже были модели бизнес-процессов. Для разработки системы сбалансированных показателе BSC/KPI требуется, чтобы у банка была формализованная миссия, политика, стратегии, цели.

Таким образом, принимая во внимание уровень зрелости банка, принципиально меняется схема организации проекта. Раньше консультанты (или новые штатные специалисты) приходили в банк и, проведя диагностику требуемого участка деятельности, начинали работу согласно подготовленному плану и классическим методикам. Теперь, уже зная представленные выше материалы и выводы, сначала внимательно определяется уровень зрелости банка для реализации проекта. И только потом решается, стоит начинать проект или нет. Если уровень зрелости банка не позволяет начинать проект, то разрабатываются и реализуются мероприятия по переводу банка на более высокий уровень зрелости, либо проект отменяется. После реализации мероприятий оцениваются их результаты, и снова принимается решение о запуске проекта.
Приведём примеры ситуаций в реальных банках по каждой категории зрелости. Данные примеры показывают, что даже, когда одна категория зрелости не удовлетворялась, проект терпел неудачу.

1. Стратегия
В банке 1 разрабатывалась стратегия на следующие 3 года и перечень мероприятий / проектов по развитию. Часть проектов были чётко прописаны в документе «Стратегия развития», а несколько проектов по каким-то причинам в этот документ не попали, либо упоминались в нём косвенно. При этом все проекты были одинаково актуальными и востребованными в банке. В результате были запущены все проекты. Но один проект «Построение системы менеджмента качества по стандартам ISO 9000» потерпел неудачу, т.к. сотрудники банка не воспринимали его всерьёз, а руководство банка не смогло продвинуть этот проект, потому что он не был чётко закреплён в принятой Стратегии развития.
2. Акционеры и топ-менеджмент
В банке 2 группа топ-менеджеров решила инициировать проект по описанию бизнес-процессов. Решение было совершенно правильное, актуальное, соответствовало этапу развития банка. Проект начался, был выбран и приобретен специализированный программный продукт «Business Studio» для описания бизнес-процессов, приглашены высококвалифицированные специалисты, разработан План проекта на 1,5 года, изданы необходимые приказы по рабочим группам. Т.е. на лицо удовлетворение 3-8 категорий зрелости. Однако реализация проекта не была согласована с акционерами банка. У акционеров, как оказалось, было другое видение развития банка, согласно которому детальное описание бизнес-процессов не требовалось. В результате проект был закрыт, когда акционеры приступили к активному претворению своего видения в жизнь. Тем не менее, были подготовлены описания (модели и регламенты) примерно 30% бизнес-процессов банка, которые продолжали использоваться сотрудниками в работе и после завершения проекта.
3. Персонал
В банке 3 при реализации проекта «Разработка системы сбалансированных показателей BSC/KPI» возникла классическая ситуация. Акционеры и топ-менеджмент банка прилагали все усилия к реализации проекта и обеспечению его необходимым ресурсами, но персонал банка не был готов к этому и стал трудно преодолимым препятствием для проекта. Сотрудники боялись, что им назначат много новых показателей и функций. При попытках организации и проведения совещаний и интервью, сотрудники отказывались выделять время, мотивируя это большой занятостью, либо сообщали неполную / противоречивую информацию.
4. Размер банка и количество сотрудников
По данной категории вместо примеров приведём выводы. Небольшому банку с численностью сотрудников до 200 человек нецелесообразно реализовывать масштабный проект по детальному описанию бизнес-процессов, т.к. в таких банках, как правило, все друг друга хорошо знают, и излишняя регламентация может привести к конфликтам. Практически каждый специалист такого банка может выполнять широкий круг задач (направлений) – по сути, является незаменимым, и дополнительные инструкции ему не нужны. Описание отдельных бизнес-процессов, конечно, проводить стоит, но результаты масштабного проекта для небольшого банка вряд ли себя окупят.
5. Организатор проекта и рабочая группа
См. раздел «Организация проектных (рабочих) групп и распределение ролей в проекте». Ресурсы Банк 4 решил реализовать проект по описанию бизнес-процессов с минимальными расходами, проигнорировав рекомендации консультантов по приобретению специализированного программного продукта и приём в штат дополнительных специалистов. В результате объём работ был намного больше возможностей специалистов, а бизнес-процессы описывались с помощью самых подручных средств (по большей части в MS Word, MS Visio). Когда количество моделей и регламентов бизнес-процессов превысило 100, ими стало сложно управлять, актуализировать и просто использовать в работе. А рабочая группа попросту не уложилась в сроки проекта при том, что работать приходилось 10 часов в день.
6. Уровень развития
Банк 5 решил внедрить систему электронного документооборота. Были объективные предпосылки для внедрения, но не было необходимых условий и наработок. Сетевая и компьютерная инфраструктура не отвечала реальным потребностям, не была масштабируема, иногда работала со сбоями. Формы банковских документов и маршруты их прохождения не были систематизированы и качественно формализованы. В результате внедрение системы электронного документооборота заняло в несколько раз больше времени и потребовало колоссальных усилий и средств.
7. Жизненный цикл
Предлагаем самостоятельно подобрать банковские примеры для данной категории из личного опыта, либо опыта знакомых-специалистов.

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

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

1. Комплексная типовая бизнес-модель коммерческого банка, Типовая система менеджмента качества банка. http://www.businessstudio.ru/buy/modelshop/nm_bank2.
2. Исаев Р.А. Банковский менеджмент и бизнес-инжиниринг. – М.: ИНФРА-М, 2011. – 400 с. Ил.
3. Исаев Р.А. Организация и управление проектами развития в коммерческом банке. – Журнал «Управление в кредитной организации», № 2 / 2010.
4. Руководство к своду знаний по управлению проектами (PMBOK) 4-е издание. – PMI, 2008.

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