Банковское хранилище данных: разрабатывать или покупать?

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

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

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

Согласно исследованиям Gartner, 76% бюджета любого BI-проекта тратится на внедрение хранилища данных. Во многих статьях, посвященных рискам, возникающим в ходе проектов по внедрению хранилищ, утверждается, что успех проекта зависит от множества присущих этой технологии факторов. В соответствии с данными отчёта Gartner, опубликованного в 2009 г., более 50% проектов внедрения хранилищ будут иметь ограниченное применение или закончатся провалом.

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

• Самостоятельно разработанное решение будет учитывать потребности бизнеса и благодаря этому станет источником конкурентных преимуществ.
• Его будет легко адаптировать в течение долгого времени в соответствии с изменениями потребностей бизнеса.
• Оно не предполагает зависимости от внешнего поставщика.

Для каждого пункта в пользу выбора собственного решения есть соответствующий аргумент за выбор коммерческого решения:

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

Кроме того:

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

• Максимальная отдача за краткий срок – с помощью правильной технологии и адаптеров для исходных систем внедрение хранилищ данных может быть осуществлено всего за 3 месяца.
• Хороший поставщик обладает значительным опытом проектирования и знает, что будет работать, а что нет.
• «Вливание помощи» - большинство IT-отделов старается выполнить существующие обязательства по проектам. Новые разработки программного обеспечения могут конкурировать с текущей работой. Начало проекта с опытным поставщиком позволит обеспечить вливание ресурсов, чтобы работа выполнялась даже в условиях максимальной загруженности банковского ИТ-персонала.
• Коммерческое решение позволяет избежать множества рисков, связанных с индивидуальной разработкой и обеспечить быстрое внедрение.
• Снижение совокупной стоимости владения – даже при том, что начальная стоимость любого коммерческого пакета может показаться высокой, совокупная стоимость владения продуктом в течение трёх-пяти лет может быть намного ниже.

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

В общем, этапы построения хранилища данных выглядят следующим образом:

1. Определение модели данных
2. Определение интерфейсов
3. Извлечение данных из бизнес-систем
4. Преобразование данных
5. Импорт данных в хранилище
6. Хранение данных
7. Формирование аналитических выборок данных
8. Разработка бизнес-логики
9. Представление данных
10. Распространение данных

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

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

Использование наилучшего решения также предоставит доступ к инновационным подходам, которые обычно выходят за рамки внутреннего проекта, в том числе к виртуализации данных, при котором данные содержатся в хранилище в собственном формате. Это, как правило, сокращает до 95% этап трансформации во время ETL-процесса (Extract, Transform, Load, извлечение, преобразование и загрузка данных) и обеспечивает полную прозрачность для аудита любых генерируемых отчётов вплоть до источника данных.

1. Graz Sweden AB. Следует строить или покупать? (Should you build or buy?), 2014 г.
2. Data Transformed. Построение хранилища данных? Прыжок с обрыва! (Building a Data Warehouse? Jump Off a Cliff!), 2014 г.
3. Курт Зара (Kurt Zahra). Причины, почему так много проектов построения хранилищ данных заканчиваются провалом (Reasons Why So Many Data Warehouse Projects are a Failure), 16 апреля 2013 г.
4. Майк Дойл (Mike Doyle). Разработка или покупка корпоративного хранилища данных в здравоохранении: что лучше для вас? (Build vs. Buy a Healthcare Enterprise Data Warehouse: Which is Best for You?), 2014 г.
5. Mosaic Data Science. Почему проекты по внедрению корпоративных хранилищ данных заканчиваются неудачей и что с этим делать (Why Enterprise Data Warehouse Projects Fail, and What to do About it), январь 2014 г.

Автор: По материалам зарубежных сайтов