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

 

 

Обычно сначала возникающие требования пытаются удовлетво­рить «малой кровью», отвечая, напри­мер, нанеобходимость построения все более сложных аналитических отчетов покредитному портфелю последова­тельно следующими действиями: опти­мизацией отчета вкредитном модуле АБС, наращиванием аппаратных мощ­ностей, выделением сервера отчетно­сти, накоторый производится реплика­ция данных транзакционной системы, и, наконец, венцом этой ветви эволю­ции – созданием специализированной базы данных, куда скриптами из тысяч строк кода загружаются ипреобразо­вываются данные. Все эти действия естественны ипозволяют решить теку­щие задачи, не затормозить развитие банка, вовремя отреагировать нано­вые требования регуляторов. Однако со временем обнаруживается, что, на­пример, специалисты поуправлению рисками работают содной версией кредитного портфеля, при подготовке управленческой отчетности использует­ся другая, адо подразделения, отвеча­ющего за разработку новых продуктов, необходимые данные внужных разре­зах вообще не доходят из-за того, что заявки наразработку новых отчетов уже несколько месяцев «висят» воче­редь надоработку учетной системы. При этом ибизнес-подразделения иIT крайне загружены текущей работой, одни ите же данные многократно вы­гружаются иобрабатываются для раз­личных подразделений, пользователи, страдающие отхронической нехватки данных, поддерживают собственные электронные таблицы огромных объе­мов итолько им ведомых форматов.

 

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

 

В целом же естественным развитием является создание такой системы как хранилище данных (в широком понима­нии термина) ивнедрение набора ана­литических приложений для работы с данными. При этом необходимо рас­смотреть возможность использования промышленного подля задач хранения (СУБД) ипреобразования (ETL) данных в качестве технологической основы ре­шения. Для аналитических приложений особое внимание нужно уделить воз­можности предоставления максималь­ного доступа к функциональности бизнес-пользователям, что содной сто­роны снизит вбудущем нагрузку наIT, а с другой – обеспечит оперативное развитие систем самим бизнесом. Естественно, если приложение подразу­мевает необходимость программиро­вания, возможность работы сней бизнес-пользователей всерьез рассма­тривать нельзя.

 

 

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

Недостаток у такого подхода всего один – он не работает.

 

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

 

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

 

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

 

Этот подход не ограничивает возмож­ные варианты архитектуры хранилища. Не противоречит он иподходу сисполь­зованием промышленной модели хра­нилища данных банка, такой как вре­шении IBM BDW. Напротив, поэтапное задействование единой, гарантирован­но согласованной модели данных вхра­нилище позволяет, держа вголове не­обходимость внедрения единого храни­лища данных банка, решать напервых этапах наиболее «горячие», важные для бизнеса задачи, тщательно тестируя ал­горитмы загрузки данных вхранилище поданным каждого отдельного этапа.

В случае же, когда не используется промышленная модель хранилища, от­лично зарекомендовал себя подход по­строения хранилища данных сисполь­зованием схемы «звезда», при которой хранилище данных представляет собой совокупность таблиц фактических дан­ных (например, задолженность, возна­граждения покредитам, депозитам) и согласованных измерений (та­ких как подразделения, клиенты). Именно согласованные измере­ния будут обеспечивать согласован­ность хранилища данных вцелом ивоз­можность получения данных из различ­ных областей. Например, соединяя фактические данные покредитам иде­позитам через общее измерение кли­ентов, пользователь получит сводные данные подепозитам икредитам кли­ента водном отчете.

 

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

 

 

С какой же области лучше начать вне­дрение хранилища вбанке сразвитым розничным направлением? Вопрос, с одной стороны, достаточно индивиду­ален, так как нужно понять самые про­блемные моменты втекущий мо-мент времени исостояние систем-источников, сдругой же –возможно дать несколько общих рекомендаций, основываясь наопыте проектов нашей компании вРоссии иСНГ.

Как правило, самой востребованной исамой проблемной, сточки зрения обработки порозничному направле­нию, является информация покредит­ной деятельности банка. Информацию покредитному портфелю, «разверну­тую» повремени, использует большое количество подразделений банка для задач внутренней ивнешней отчетно­сти, анализа, управления рисками. Обычно уже есть решения почастич­ной автоматизации анализа иобработ­ки кредитного портфеля, однако пере­неся решение нановую внедряемую платформу, учтя при этом самые акту­альные требования, можно решить сра­зу несколько задач:

 

• дать бизнес-пользователям единую версию правды иединый меха­низм доступа к данным снеобходимы­ми показателями ианалитиками;

• вовлечь большое количество бизнес-пользователей виспользование новой системы, заинтересовать, дать понимание возможностей системы, по­будить, таким образом, более активно участвовать вразвитии хранилища дан­ных ианалитической системы;

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

 

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

Далее, естественно, одной из первых автоматизировать область депозитов, для которой также характерны доста­точно большие объемы обрабатывае­мых данных исложность преобразова­ний.

 

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

 

Отмечу, что изложенные подходы не­однократно проходили проверку прак­тикой напроектах Columbus IT вбан­ках России иСНГ. Вовлечение, разви­тие команды специалистов со стороны банков, максимальная передача экс­пертизы входе совместной работы по­зволила не только решить текущие за­дачи банков, но иподготовить врезуль­тате команду, способную самостоятель­но развивать инаращивать построен­ное решение.

 

 

Важно, чтобы выбранная платформа иподходы не стали уже напервых шагах узким местом враз­витии аналитической системы банка. Исходя из опыта Columbus IT, можно порекомендовать обратить внимание наследующие основные компоненты решения вчасти хранилища данных и бизнес-анализа:

 

• СУБД – рекомендуется рас­смотреть промышленные базы данных, такие как решения от IBM, Oracle, Teradata;

• средства извлечения, преоб­разования, загрузки данных (ETL) – ре­шения Informatica, IBM;

• средства бизнес-анализа (BI) – решения IBM, SAP, Oracle.

 

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

 

 

В тексте статьи слово «полное» поот­ношению к степени внедрения храни­лища данных употреблялось только в кавычках. Аналитическая система,

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

 

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

 

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

 

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