Консалтинг и автоматизация в области управления
эффективностью банковского бизнеса

Публикации

Банковские технологии

Камень преткновения тендерных состязаний

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

Выбор поставщика BPM-системы (аббревиатура от Business Performance Management – система управления эффективностью бизнеса, в основе которой хранилище данных) через проведение тендерного соревнования – уже достаточно устоявшееся явление. На мой взгляд, это объективный рыночный способ отбора оптимального предложения для определения лучшего поставщика, лучшего решения. Однако несмотря на широкое применение конкурсов такого рода и многолетнюю их практику, проведении тендера на построение BPM-системы нередко заканчивается ничем.

Почему же так происходит?

 

Тендер и «пилот»

Как правило, тендер на поставку BPM-системы включает следующие типовые этапы:

1. Первичный отбор поставщиков.

2. Запрос предложений, включающий подготовку ответов на вопросы анкет (другими словами Request for Proposal, RFP).

3. Презентации продуктов и услуг.

4. Демонстрация работы программного решения на площадках клиентов вендора (известное также как Reference Visit).

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

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

 

Поиски философского камня?

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

Что можно реализовать в рамках «пилота»? Как показывает наш многолетний опыт, в эти сроки реально развернуть хранилище данных, собрать и загрузить данные бухучета, настроить выпуск форм обязательной отчетности либо основных управленческих отчетов по этим данным, автоматизировать планирование и контроль бюджета хозяйственных расходов.

Однако нередко в качестве ожиданий от пилотного проекта озвучиваются задачи, реализация которых выходит за его рамки. Заказчик может захотеть в первую очередь автоматизировать подготовку отчетности по МСФО или, скажем, расчет расшифровок для обязательных нормативов. У подобных задач есть одно общее – для формирования соответствующих отчетных форм требуется сбор и выверка целого ряда портфелей сделок. Например, для расчета нормативов, как и для других сложных сводных форм, таких как 0409117, 0409118, 0409125, 0409128, 0409129, необходим весь массив данных первичного учета, включая бухгалтерский учет, сведения о контрагентах и клиентах, информация по договорам (сделкам).

Думаю, ни для кого не секрет, что качество исходных данных – это ахиллесова пята банковской отчетности. Практически всегда у сделочных данных отсутствует часть аналитических признаков, нужных для подготовки отчетов. В АБС, как правило, не предусмотрен расчет группы риска для клиента или сделки. Кроме того, ведение части атрибутики по сделкам (например, срока погашения по депозитным договорам) может осуществляться в Microsoft Excel. Также часто бывает, что информация о некоторых финансовых инструментах, объем операций по которым минимален (например, об аккредитивах), может храниться исключительно в электронных таблицах. Список проблем с исходными данными можно легко продолжить[1], но хочется подчеркнуть главное: добиться надлежащего качества данных можно только за счет серьезной и кропотливой работы. В хранилище данных «Контур» реализованы функция контроля достаточности и корректности данных, что дает возможность нам совместно с заказчиком создать технологию обеспечения качества данных. Краеугольным камнем этой технологии является реестр качества данных. В нем фиксируются результаты контроля данных, а также предложены рекомендации по повышению качества данных.

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

 

Время собирать камни, или Что может быть целью пилотного проекта?

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

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

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

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

 

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



[1]Подробнее об этом см.: Чаусов В., Кудинов А. Семь нот качества данных // Банковские технологии. –  2010. – № 12. – С. 59–61