Хранилище данных: вопросы и ответы

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

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

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

Предпосылки создания

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

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

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

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

Возможные заблуждения и рекомендации по их разрешению

1. Хранилище данных — это OLAP.

OLAP является аналитическим инструментом и одним, но далеко не единственным средством анализа данных в хранилище. Важно отметить, что средства OLAP могут быть использованы и вне хранилища. OLAP-анализ данных, находящихся в своих источниках, может быть произведен без их извлечения и загрузки в хранилище. Однако эффективность многомерного анализа при наличии хранилища данных резко возрастает.

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

2. Построение хранилища данных — задача только информационных технологий.

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

3. Загрузка данных — это просто.

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

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

4. Сначала загрузим все в хранилище, а уж затем определим цели.

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

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

5. Хранилище данных — это готовая программа.

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

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

6. Хранилище данных можно построить за пару недель.

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

7. Централизованное хранение метаданных решит все проблемы.

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

Основные элементы хранилищ данных

Рассмотрим некоторые компоненты хранилища данных на примере решения Datagy, созданного компанией Diasoft.

В целом такие компоненты подразделяются на два вида: структурообразующие и структурные. Первые представлены на схеме вертикальными прямоугольниками, а вторые — горизонтальными.

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

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

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

Хранилище данных может быть реализовано как на реляционной, так и на многомерной СУБД. Но, как показывает практика, хранилища серьезного объема реализованы в основном на реляционных СУБД. Центральным компонентом хранилища является отраслевая модель данных, и ее тщательная проработка во многом определяет успешность проекта в целом.

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

Существует несколько подходов к анализу данных в хранилище. Основными считаются:

интерактивный анализ данных (Online Analytical Processing, OLAP) — компьютерное приложение, поддерживающее многомерное представление и визуализацию данных с целью их анализа и подготовки отчетов;

периодически выпускаемая отчетность (Reporting) — отчеты в стандартных формах;
нерегламентированная отчетность (Ad-Hoc Reporting) — возможность получать быстрый доступ к реляционной базе данных для ответов на запросы, формируемые менеджерами “на лету”;

интеллектуальный анализ данных (Data Mining) — процесс анализа больших наборов данных, применяемый для обнаружения связей между различными их элементами и поиска скрытых закономерностей.

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

Метаданные можно разделить на два класса: технические и бизнес-метаданные; последние представляют собой описание данных на языке бизнес-пользователей. Иными словами, бизнес-метаданные — это слой абстракции, который позволяет бизнес-пользователям работать с системой, концентрируя свое внимание исключительно на предмете анализа, а не на технических деталях системы. Качество и полнота бизнес-метаданных во многом определяют степень успешности проекта по созданию хранилища данных.

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

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

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

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

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

Анализ доходов актуален для любого банка, причем более всего востребован анализ в разрезе клиентов. Очень важно также иметь представление о распределении доходов по продуктам и услугам, каналам предоставления услуг и подразделениям банка. Анализ доходов в разрезе клиентов и продуктов позволяет формировать “уникальные” предложения для каждого “уникального” клиента с целью максимизации прибыли в долгосрочной перспективе. Он способствует формированию ценовой политики банка, выделению сегментов, продуктов и услуг, которые стратегически важны для него.
Управление активами и пассивами. С помощью хранилища данных можно проводить эффективный анализ активов и пассивов и управлять не только ими, но и мгновенной ликвидностью банка на основе инструментального и портфельного подходов. Эти задачи решаются при минимальных затратах на подготовку специальных данных и с учетом лишь ограниченного объема информации, собираемой из источников в филиалах. Программный комплекс обеспечивает загрузку из информационных источников семи типов и позволяет формировать несколько десятков отчетов.