Опыт внедрения Хранилища данных в Банке "Павелецкий"

Опытом автоматизациии управленческой отчетности на основе хранлища данных "Контур" делится Ярослав Медокс - начальник Управления банковских технологий ОАО Банк "Павелецкий".

В банке "Павелецкий" серьезно относятся к информационным технологиям, в частности автоматизации учета и анализа. В 2003 г. перед нами встала задача анализа динамики изменения базы пассивов банка с целью получения оперативной информации о его финансовом состоянии и прогнозирования путей дальнейшего развития банка. Понятно, что такие задачи не входят в функции стандартных АБС.

Банк не один год использует "RS-Bank 5.0" компании R-Style Softlab. Мы стараемся максимально использовать функционал, заложенный в те модули, которыми пользуемся, и не увеличивать их количество. Для систематизации процесса развития "RS-Bank" и других прикладных систем в организационной структуре банка создано Управление банковских технологий, в функции которого входит постановка задач для разработчиков, а также разработка или настройка системы. За эти годы специалистами банка создано много собственных приложений, как на встроенном языке программирования RSL, так и на языках высокого уровня. Причем по количеству и качеству собственных разработок на языке RSL банк "Павелецкий" находится в первых рядах среди клиентов компании R-Style Softlab.

Постановка задачи

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

Для того чтобы определить путь решения поставленной задачи мы сделали классический шаг: подготовили техническое задание (ТЗ), которое разрабатывалось Управлением банковских технологий совместно с Управлением бюджетного планирования и контроля (аналитической службой банка). Были сформулированы требования к системе. Кроме этого, была формализована методика, используемая для анализа в Управлении бюджетного планирования и контроля. В соответствии с ТЗ система должна обеспечивать:

1. Хранение информации о пассивах (сроки, агенты, процентные ставки и т.д.), включая информацию, которая не может быть извлечена из "RS-Bank".
2. Ежедневное обновление информации на основе данных, импортируемых из "RS-Bank".
3. Формирование отчетов о привлеченных средствах банка с возможностью их группировки по:

• инструментам привлечения;
• срокам;
• процентным ставкам;
• группам клиентов;
• привлекающим подразделениям;
• по нескольким вышеназванным признакам.

4.      Расчет средневзвешенных ставок привлечения по:

• инструментам привлечения;
• срокам;
• процентным ставкам;
• группам клиентов;
• привлекающим подразделениям;
• по нескольким вышеназванным признакам.

5.      Формирование календаря выплат, ежедневного и за период времени, по возврату   основной суммы; процентов; основной суммы и процентов.

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

Рис.1. Структура системы <Анализ пассивов>.

Назначение различных блоков на схеме такое:

• блок авторизации - отвечает за предоставление доступа к системе различным группам пользователей;
• блок работы с группами пользователей - отвечает за ввод информации о новых пользователях системы;
• блок работы с характеристиками пассива - предназначен для работы с учетными записями характеристик пассивов;
• шлюз - предназначен для извлечения информации о пассивах из "RS-Bank" и загрузки этой информации в базу данных <Пассивы>;
• база данных <Пассивы> - содержит ежедневную информацию об остатках на счетах, отражаемых в балансе банка;
• блок консолидации данных - отвечает за объединение и обработку данных, предоставляемых блоком работы с характеристиками пассивов и базой данных <Пассивы>, и позволяет формировать отчеты.

Критерии выбора платформы автоматизации

Изначально проектируемая система рассматривалась не как некое расширение функциональных возможностей АБС "RS-Bank", а как самостоятельное приложение, надстройка. В процессе работы над ТЗ мы проанализировали возможности "RS-Bank", сложившиеся технологические цепочки и пришли к выводу о нецелесообразности расширения функциональных возможностей "RS-Bank" собственными силами в рамках, которые позволяет встроенный язык RSL. Теперь следовало выяснить, будем ли мы сами разрабатывать систему на языке высокого уровня или искать подходящее решение на рынке. На основе имеющейся статистики мы оценили трудоемкость и возможные сроки разработки качественной системы. Полученный результат прямо наводил на мысль о необходимости поиска и приобретения готовой. Помимо формализованных требований к системе, мы учли и следующие факторы:

1. Современные тенденции развития банковского ПО. Нарастающую популярность технологий OLAP и DataWarehouse.
2. Необходимость решения в ближайшем будущем задач построения системы бюджетирования, выпуска отчетности в соответствии с МСФО, консолидации учетных данных филиалов и т.д.
3. Наличие в банке разных работающих учетных систем - кроме АБС "RS-Bank", в банке действовали иные системы, автоматизирующие такие направления бизнеса, как учет сделок в ценными бумагами, учет сделок межбанковского кредитования и др.
4. Наличие <критической> массы собственных приложений.

В результате принято следующее решение:

1. Ориентируясь на технологию Хранилищ данных (Data Warehouse), выбрать тиражную систему, соответствующую стратегии банка в области программного обеспечения.
2. Выбрать поставщика, способного в перспективе решить перечисленные выше задачи, в первую очередь построить систему бюджетирования.

Банк провел закрытый тендер, основанием для которого послужили материалы разработанного ранее ТЗ. К сожалению, из рассмотренных четырех предложений ни одно не решало задачу <Анализ пассивов> в точном соответствии с требованиями ТЗ. Но наиболее близкое и наиболее подходящее решение было предложено компанией Intersoft Lab. Специалисты компании смогли четко классифицировать наши задачи, с помощью Хранилища данных <Контур Корпорация> обозначить пути их решения, в том числе и задачи, связанные с дополнительной разработкой, привести примеры решения аналогичных задач, разграничить функции учетных систем и Хранилища данных, а также показать перспективы развития Хранилища в банке. Причем при проведении тендера и в процессе переговоров Intersoft Lab выступал слаженно вместе со своим партнером - консалтинговой фирмой <ТрастКонто>. Отметим особенности платформы <Контур>, которые показались нам наиболее существенными и повлияли на выбор:

1. Загрузка информации в Хранилище осуществляется через XML. При этом описание тэгов система генерирует автоматически, что позволяет, например, совершенно стандартными средствами в автоматическом режиме загружать в Хранилище сущности, созданные нами же в рамках Хранилища.
2. Развитые средства распределения и сбора информации. Кроме описанного выше XML, Хранилище <умеет> генерировать шаблоны документов в формате Excel, что позволяет организовать ввод информации на рабочих местах без доступа к Хранилищу.     
3. Не совсем традиционный подход к построению Хранилища данных: система позволяет изменять загруженную извне информацию.
4. Наличие готового конвертера данных для "RS-Bank 5.0".

Мы умышленно не приводим весь набор характеристик системы, так как считаем, что главное - это соответствие выдвинутым требованиям по функциональности и перспективам развития. С этой точки зрения, например, выбор СУБД имеет второстепенное значение, тем более, что серьезных систем на непромышленных СУБД не существует. Более того, IT-подразделение любого банка может сформулировать технические требования к системе без консультаций с заказчиками и вообще чьей-либо помощи. Если вернуться к СУБД, то <Контур Корпорация> построена на MS SQL, что совпадает с корпоративной политикой банка в области собственных разработок. Другими словами, отдельных администраторов банку не потребуется.

Известно, что крупные IT-проекты в банке (и не только в банке) невозможны без явной поддержки руководства. Нам в этом плане повезло. Непосредственный заказчик системы, член Правления, куратор аналитической службы, был изначально заинтересован в долгосрочном сотрудничестве с поставщиком. В дальнейшем он выступал ведущим экспертом при уточнении вопросов, связанных с внедрением приложения <Анализ пассивов>, и курировал проект. Наши планы встретили понимание и одобрение у других членов Правления.

Несколько слов о заключении договора. От того, насколько хорошо проработан договор, насколько детализированы действия и ответственность сторон, существенно зависит взаимопонимание и конструктивность работы. В качестве материалов для подготовки договора компания Intersoft Lab располагала информацией о среде, в которой будет внедряться Хранилище данных, о перспективах сотрудничества в случае успешного запуска приложения <Анализ пассивов>, а также ТЗ на это приложение. Мы сознательно заложили некоторую избыточность в комплект поставки системы в расчете на дальнейшее сотрудничество: например, тиражное приложение <Управление филиалами> в составе <Контур Корпорации> не требовалось для решения текущей задачи, но в дальнейшем потребуется для построения системы бюджетирования. На текущем этапе <Управление филиалами> будет использовано только для настройки и хранения организационно-штатной структуры банка, что необходимо в соответствии с требованиями к разрезам отчетности приложения <Анализ пассивов>.

Компания Intersoft Lab, оценив трудоемкость разработки нашего приложения, предложила соответствующие перечень работ и этапы их выполнения, которые и были включены в договор. Может показаться странным, что, ориентируясь на тиражное решение, мы сознательно пошли на разработку некоего приложения. Но надо понимать, что, во-первых, приложения без Хранилища данных (а оно должно быть тиражным) не существует, а во-вторых, то, что не существует единой и стандартной для всех банков методики управленческого учета. А одним из элементов управленческого учета и является проектируемое приложение <Анализ пассивов>.

Внедрение Хранилища данных

Итак, договор заключен, работы начались. Мы не стали официально создавать рабочую группу по внедрению системы. Тем не менее процесс внедрения мы определили как проект, и большую часть вопросов, связанных с внедрением Хранилища, сосредоточили в Управлении банковских технологий. Из состава Управления был выделены: руководитель проекта, которого освободили от прочих работ; программист, чьи обязанности включали вопросы организации загрузки данных. Конфигурирование отдельного сервера для системы были поручено Управлению автоматизации банка. Оперативные вопросы, связанные с работами по ТЗ, решались руководителем проекта в постоянном контакте с начальником Отдела анализа и контроля пассивных операций. Экспертами выступали куратор Управления бюджетного планирования и контроля от Правления и начальник Управления банковских технологий. Условием слаженной работы было четкое понимание всеми сторонами высокого приоритета данной задачи. Со стороны компании Intersoft Lab выделили куратора, с которым мы решали все вопросы. Кроме этого, над нашим приложением <Анализ пассивов> работал аналитик компании и разработчики. По ходу работ мы свободно контактировали и с куратором, и с аналитиком, и с руководством компании. Более того, мы договорились о предоставлении банку внутренних отчетов компании о ходе работ по нашему проекту, что явилось неформальным условием заключения договора. Отчеты позволили контролировать отношение компании к нашим проблемам и исключить возможность завышения оценок достигнутых результатов.

Планирование и проведение работ по запуску Хранилища данных включали следующие этапы:

1. Установка базовых компонентов системы на сервере, включая подготовку сервера.
2. Настройка выгрузки из "RS-Bank" и загрузки в Хранилище <Контур Корпорация> первичных данных. Запуск на постоянной основе загрузки данных.
3. Разработка, тестирование, устранение замечаний к приложению <Анализ пассивов>.
4. Запуск всей системы в промышленную эксплуатацию

Поскольку компания располагала достаточным опытом по внедрению <Контур Корпорации> в банках, использующих АБС "RS-Bank 5.0", больших проблем не предвиделось.

Здесь следует вкратце описать процесс переноса данных. Сначала из "RS-Bank" выгружается транспортный файл в XML-формате, причем это делается RSL-макросом, входящем в поставку <Контура>. Первые проверки делаются уже на этом этапе, затем, в случае отсутствия ошибок, транспортный файл загружается в Хранилище, где производится повторный контроль. Мы столкнулись с логическими ошибками в базе данных уже на этапе выгрузки. Так, нашлись счета, у которых формальный признак <дата закрытия счета> был раньше даты последней проводки, а также счета, не привязанные ни к одному клиенту в справочнике клиентов, и т.д. На устранение этих ошибок понадобилось время. Кроме этого, макрос нуждается в некоторой кастомизации для каждого банка, что не стало для нас неожиданностью. Более того, благодаря наличию квалифицированных кадров мы смогли доработать макрос и запустить выгрузку-загрузку первичных данных практически самостоятельно.

С самого начала мы вели протокол ошибок и сбойных ситуаций, где фиксировали возникающие проблемы, дату возникновения, причину (описание), статус. Это позволило нам исключить личностный фактор и неоднозначность толкования наших запросов в процессе общения с компанией. Наши протоколы принимались и рассматривались руководством Intersoft Lab, а затем совместно мы намечали порядок решения наших проблем. Следует заметить, что особенно важно ведение такого журнала в процессе разработки и внедрения заказного решения, каким, по сути, является <Анализ пассивов>. Так, например, мы локализовали проблемы, связанные с недоработками в ТЗ и отнесли их на платные доработки после окончания внедрения. Соответственно, более к этой теме возвращаться не пришлось.

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

Самой большой проблемой для нас стал не очень удачный интерфейс приложения <Анализ пассивов>. Поскольку само приложение разработано на встроенном в систему языке Python, разработчикам пришлось долго искать решение, которое бы устроило банк. Было предложено несколько вариантов решения, из которых мы выбрали лучшее. Так, ввод данных о пассивах осуществляется в HTML-форме, что является, по сути, компромиссным решением. В ближайшее время (первая половина 2004 г.) компания Intersoft Lab выпустит новые версии своих основных продуктов, в которые входит дизайнер интерфейсов. Мы надеемся, что это позволит сделать работу с приложением <Анализ пассивов> более удобной. Описанная проблема относится только к приложению <Анализ пассивов> и не относится к основному интерфейсу <Контур Корпорации>.

Результаты проекта и перспективы

Как известно, существует две основные линейки продуктов компании Intersoft Lab: это собственно платформа Хранилищ данных <Контур Корпорация> и аналитическая платформа, в состав которой входит генератор OLAP-отчетов <Контур Стандарт>. Соответственно назначению этих систем наше приложение <Анализ пассивов> разделено на две части: <Контур Корпорация> обеспечивает учет пассивов, а <Контур Стандарт> позволяет получать отчеты, предусмотренные ТЗ. С одной стороны, такое решение позволяет разделить учет и отчетность, с другой - позволяет создавать новые отчеты, не предусмотренные в ТЗ. Кроме того, OLAP-представление имеющихся отчетов обеспечивает гибкость, например, при формировании различных срезов данных.

Прошедшие несколько месяцев эксплуатации Хранилища данных и приложения <Анализ пассивов> позволили сделать некоторые выводы:

1. Удалось собрать воедино всю информацию о пассивах банка. Теперь не требуется ежедневно консолидировать информацию из разных источников.
2. Радикально ускорилась подготовка отчетов и улучшилось их качество. Снижено влияние человеческого фактора. Появилась возможность прогнозирования.
3. Появились контрольные функции, причем как заявленные в ТЗ, так и новые. Примером новой контрольной функции является комплексная проверка логической целостности импортируемых данных.

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

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

Если говорить о стратегических результатах внедрения, то мы убедились, что нам по силам сопровождение и развитие корпоративного Хранилища данных. Но: Нельзя стоять на месте, поэтому те перспективы, которые мы обрисовывали при заключении первого договора, теперь обретают реальные очертания. Сейчас в банке полным ходом идут работы по внедрению технологии бюджетирования на базе <Контур Корпорации>, запланировано приобретение и внедрение приложения <Внешняя отчетность по МСФО>, запланирован постепенный перенос выпуска обязательной регламентированной отчетности в Хранилище данных и т.д. Полученный опыт позволяет минимизировать количество ошибок и задержек во внедрении новых приложений на базе Хранилища данных. Мы знаем возможности наших учетных систем, возможности Хранилища, поэтому вместе с компаниями Intersoft Lab и <ТрастКонто> удается быстро находить оптимальные пути решения тактических задач. Примером такой локальной задачи, выходящий за рамки приложения <Анализ пассивов>, стало, например, принятие технологии локализации доходов и расходов по площадкам банка и по подразделениям центрального офиса.

Как добиться успеха при внедрении Хранилища данных: советы коллегам

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

1. Должна быть реальная, осознанная необходимость в сложном аналитическом инструменте. Соответственно, в банке должна быть аналитическая служба, способная использовать сложный инструмент и ставить задачи по его развитию. При этом следует обязательно учитывать возможные и реальные перспективы развития системы: в аналитике нельзя ориентироваться на <узко заточенный> инструмент.
2. Необходима явная и активная поддержка проекта руководством банка.
3. Необходимо описать требования к системе максимально точно и подробно. В результате вы сформулируете техническое задание или функциональную спецификацию, которые могут быть использованы для проведения тендера. Особенную важность данный пункт приобретает в связи с уникальностью аналитических методик в каждом банке.
4. Необходимо детально проработать договор на поставку и/или разработку приложения. Особенно внимательно следует подойти к определению этапов разработки и внедрения специализированного (заказного) приложения, если таковое необходимо.
5. В процессе внедрения необходимо обеспечить документирование всех тактических решений, дополнений к ТЗ, а также протоколировать все сбойные и проблемные ситуации. Кроме перечисленного, необходимо обеспечить прозрачное взаимодействие с поставщиком и заказчиком для своевременной локализации проблем. Для организаций с поставленным процессом развития IT-инфраструктуры этот пункт является самым простым.
6. Должны подводиться итоги окончания работ по каждому этапу. Возможно, не имеет смысла продолжать работу, если ожидаемые на этапе результаты не могут быть достигнуты разумными средствами.

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

Автор: Я.В.Медокс

Источник: Банки и технологии, 2004, № 2