Хранилище данных — отложить до лучших времен?

28 мая 2009 16:00

Опыт компании SAS показывает, что делать этого не стоит. Результат сегодня можно получить быстро, если придерживаться некоторых простых правил. Каких? Ответ — в статье Юлия Гольдберга, директор по работе с финансовым сектором компании SAS Россия/СНГ.

Сегодня большинство организаций сильно урезали бюджеты развития, и IT-бюджет пострадал одним из первых. Новых проектов открывается гораздо меньше, чем прежде. Масштабные внедрения уровня организации и раньше можно было по пальцам пересчитать, а сейчас почти все они пущены под нож. Очевидно, что пока не время вкладывать большие средства в проекты, отдача по которым начнется через два-три года, а то и позже. Что в этой связи можно сказать о проектах по созданию хранилищ данных (ХД), которые большинству банкиров представляются супердолгими и дорогими?

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

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

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

Выбор оптимального набора бизнес-приложений

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

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

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

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

Если начинать использование ХД с этих приложений, то сроки внедрения могут быть действительно антикризисными. Так, в одном из крупнейших розничных банков страны аналитический CRM был запущен «поверх» хранилища менее чем через полгода после старта проекта, и уже через год только за счет решения одной этой задачи все инвестиции в ХД окупились. Для аналитического CRM критично качество данных по клиентам (отсутствие дублирования, правильность заполнения адресов и телефонов, корректность параметров клиентов), но при концентрации усилий на этой задаче и наличии специализированного инструмента класса SAS Customer Data Quality ее можно решить очень быстро. Гораздо быстрее, чем выверить финансовую информацию.

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

Архитектура хранилища данных и стоимость внедрения

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

 

 

Рис. Компонентная архитектура хранилища данных %images[2]%

Процессы интеграции с источниками данных. Готовых процессов ни у кого нет и быть не может, поскольку любые стандартные системы обязательно отличаются от банка к банку за счет тонкой настройки и доработок, выполненных в ходе внедрения и эксплуатации. Кроме того, разнятся и структуры данных самого ХД, они также проходят настройку и адаптацию при внедрении. Несмотря на это, есть возможность существенно сэкономить на интеграции. Если ETL-блок ХД умеет работать с базами данных систем-источников не просто на уровне таблиц, а с использованием метаданных, то реализация и отладка ETL-процессов становится гораздо проще. Например, SAS Data Integration Server имеет «умные» коннекторы к метаданным целого ряда систем таких производителей, как Oracle, SAP, 1С и др.

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

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

Модель данных банковского хранилища SAS BIS DDS ориентирована на решение широкого спектра задач, таких как управление рисками, CRM-аналитика, CPM (Corporate Performance Management, управление эффективностью) и пр. Она уже неоднократно применялась при создании ХД в таких кредитных организациях, как МДМ-Банк, ВТБ24, банк «Возрождение». Компания SAS передает заказчику не только модель, с которой можно работать с использованием распространенных case-инструментов, но и проработанную методологию адаптации и развития этой модели в ходе выполнения проекта у заказчика и в процессе эксплуатации ХД.

Дополнительно стоит отметить, что модель данных в ХД — это не только структура первичной информации. Это также витрины, ориентированные на использование в конкретных бизнес-приложениях. SAS в составе своей платформы ХД и аналитических приложений поставляет не только сами витрины и процедуры их формирования. В дистрибутивный комплект входит и набор специальных инструментов, создающих удобную для архитектора/технолога среду для управления формированием и наполнением витрин без привлечения программистов.

Интегрированные технологические компоненты платформы хранилища данных. В составе платформы ХД обычно выделяют три базовых компонента: ETL (загрузка и трансформация данных), Storage (СУБД) и BI (отчетность и анализ). К ETL часто относят еще и компоненты DQ (Data Quality, очистка данных), а SAS, например, выделяет в своей платформе еще отдельный блок продвинутой аналитики (Analytic Intelligence), инструменты которого используются в банках для построения риск-моделей, сегментации клиентов, прогнозирования вероятности приобретения продуктов или, наоборот, полного отказа от услуг банка.

В любом случае, при построении ХД использование нескольких компонентов платформы неизбежно. Очевидно, что в случае, если эти компоненты разнородны и каждый из них использует свои метаданные, внутри системы возникает несколько сложных узлов интеграции (ETL-DQ, ETL-Storage, Storage-BI и т. п.). Эти узлы требуют значительных трудозатрат на проведение интеграции при внедрении и в процессе эксплуатации ХД приводят к существенным дополнительным расходам.

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

***

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

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



© 2020 БАНКОВСКИЕ ТЕХНОЛОГИИ
Первое издание на российском рынке, посвященное информационным технологиям для банков.
Москва, Проспект Мира, д.3, корп. 1
+7 (495) 120-81-42
info@int-bank.ru

Свидетельство СМИ ФС77-39103 от 11 марта 2010 года.
По вопросам сайта просим обращаться к администрации сайта: info@int-bank.ru.
При использовании материалов необходимо давать ссылку на www.banktech.ru.