Юлия Амириди, заместитель генерального директора по развитию бизнеса компании Intersoft LabЮлия Амириди, заместитель генерального директора по развитию бизнеса компании Intersoft Lab

Проведенный Intersoft Lab в июне текущего года опрос представителей финансовых служб банков выявил три ключевые причины, которые препятствуют внедрению систем расчета финансового результата на базе банковского хранилища данных (ХД). Первая из них – высокие финансовые вложения (63,6% ответов), вторая причина – длительные сроки реализации (36%), третья – методическая неготовность заказчика к проекту (33,3%). Второй и третий барьеры вполне преодолимы: для этого потребуется тщательно выбрать внедренческую команду, обеспечить административную поддержку проекта внутри банка и ликвидировать «методический разрыв», в том числе с помощью внешних консультантов. Правда, это потребует дополнительной финансовой нагрузки на банк, которая и без того является лидирующей преградой.

Отбросим стоимость «железа» и системного софта, а также проекты заказной разработки ХД, которые зачастую не поддаются системной оценке, сделаем поправку на то, что о стоимости контрактов других поставщиков ПО мне известно только понаслышке и далеко не все, и посмотрим, какова же пугающая цена вопроса, от чего она зависит, и как ее минимизировать?

Задачу построения системы управленческой отчетности по финансовому результату банка разобьем на 2 части, чтобы оценивать их отдельно. К первой части отнесем все, что позволит создать базис системы – ХД. Это – поставка необходимых лицензий для построения ХД и стоимость услуг по его разворачиванию, интеграции с АБС банка для сбора данных бухгалтерского учета и договоров, а также устранению ошибок в первичных данных, вызванных человеческим фактором, некорректной работой АБС, несогласованностью информации между учетными модулями. Во вторую часть включим стоимость лицензий на прикладное ПО и услуги по автоматизации расчета финансового результата и его представления в виде управленческой отчетности: обеспечение качества данных в части их обогащения недостающими аналитическими признаками, настройку механизмов расчета отчетных показателей, расчета трансфертной стоимости ресурсов и перераспределения накладных расходов, формирования витрин данных отчетных показателей, настройку форм отчетности для конечных пользователей. Такое разделение продиктовано, с одной стороны, тем, что не все поставщики и интеграторы умеют решать обе части задачи, особенно ограничено предложение и экспертиза в отношении автоматизации вычисления трансфертных доходов/расходов и аллокаций косвенных расходов, с другой стороны, архитектура решения у конкретного банка может по различным причинам объединять базовое и прикладное ПО разных производителей.

Вот некоторые оценки стоимости уже состоявшихся проектов построения ХД: Топ-25 российских банков – от 100 млн. до 250 млн. рублей, Топ-50 – от 40 млн. рублей, Топ-100 – от 25 млн. рублей, Топ-200 – 5 млн. рублей. А это оценки внедрения прикладной функциональности: Топ-25 – от 40 млн. до 150 млн. рублей, Топ-100 – от 25 млн. рублей, Топ-200 – от 15 млн. рублей. Итого: минимальная известная стоимость проекта автоматизации расчета финансового результата – 20 млн. рублей, максимальная – 400 млн. рублей.

Существенный коридор цен на проекты для банков Топ-20 – от 100 млн. до 250 млн. рублей для ХД и от 40 млн. до 150 млн. рублей для автоматизации основных управленческих задач – объясняется разными предпочтениями заказчиков относительно составляющих комплексного решения. По законам маркетинга, действующим и на рынке информационных технологий, сила ИТ-бренда во многом определяет стоимость лицензий и задает уровень ставок специалистов на услуги внедрения. Согласно рамочным стандартам построения систем для автоматизации управления эффективностью и с учетом применяемых на практике подходов, экземпляр управленческой системы для конкретного банка может быть реализован как в виде пакетного решения от одной компании-разработчика, так и виде набора интегрированных на проекте компонентов от разных производителей. Таким образом, чем больше доля иностранного ПО в проекте, тем дороже лицензии и стоимость проектных работ. Например, цена лицензий на приложения для расчета себестоимости бизнес-процессов зарубежного и отечественного производства может отличаться более чем в 10 раз. У некоторых западных поставщиков лицензионная политика предполагает определение стоимости лицензий на программные компоненты для расчета «трансфертов» или аллокаций в зависимости от величины активов банка, начиная с определенного минимального уровня, вместо фиксированного прайса, который чаще всего применяют российские вендоры. Часовая ставка консультанта по иностранному ПО, как правило, выше, чем у внедренцев аналогичных по назначению российских разработок, более чем в 1,5 раза и т.д.

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

20-кратную «разбежку» в максимальной и минимальной финансовой оценке анализируемых проектов для банков, разместившихся на разных позициях в Топ-200, обосновывают следующие объективные факторы:

  1. Высокие требования к стандартам построения ИТ-систем (относительно соблюдения шаблонов оформления проектной документации, требований информационной безопасности и проч.) и ведения ИТ-проектов в банках, возглавляющих рейтинг. Их исполнение существенно влияет на состав и объем работ, количество и подтвержденную квалификацию привлекаемого на проект персонала исполнителя и, в конечном счете, на совокупную стоимость услуг.
  2. Разный подход к решению задачи обеспечения качества данных в ХД. На «качество данных» уходит около 30% трудоемкости в проекте автоматизации расчета финансового результата банка. Подходы к реализации существенно различаются по цене. Ряд банков берет решение задачи полностью на себя: либо гарантирует надлежащее качество данных, либо обеспечивает его на стороне АБС собственными силами. Противоположный подход – банк полностью делегирует решение задачи исполнителю проекта. Компания Intersoft Lab рекомендует промежуточный вариант: создание в банке службы качества данных, которая постепенно в ходе реализации проекта перенимает у подрядчика технологию обеспечения качества данных в ХД. То есть Intersoft Lab создает технологию, а банк ее исполняет и развивает.  
  3. Разная степень сложности методики расчета финансового результата. Например, расчет трансфертных цен и доходов/расходов можно производить по пулам счетов или для каждой сделки. От выбранного методического подхода будут зависеть не только трудозатраты на настройку соответствующего приложения, но и, главное, состав работ по построению ХД – с учетом, что сбор и выверка данных по договорам может потребовать до 60% общей трудоемкости по проекту.
  4. Разный уровень потребностей банков в детализации управленческой отчетности по финансовому результату: до лицевых счетов или до сделок, по продуктам/клиентам или по продуктовым/клиентским группам/сегментам и т.п. Обогащение данных аналитическими признаками – указание кода клиента, продукта и проч., – это, пожалуй, самая сложная в инженерном плане задача построения управленческой системы. Предположим, необходимо рассчитать финансовый результат в разрезе ЦФО, а в АБС банка счета не размечены ни кодами ЦФО, ни кодами подразделений ОШС. Приходится изобретать алгоритмы и способы автоматизировать проставление этого признака для всех счетов. Каждый следующий уровень детализации отчетности требует новых, зачастую индивидуальных проектных решений, что влечет дополнительные трудозатраты.
  5. Разный масштаб участия сотрудников банка в проектных работах. В зависимости от «тиражности» выбранного ПО и качества применяемой методики внедрения существенный пласт проектных работ, касающихся интеграции ХД с АБС и выполнения прикладных настроек, может быть делегирован сотрудникам банка. Это – проверенный инструмент экономии бюджета проекта.

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

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