Хорошо известно, что проблемы построения хранилища и получение гибкой и адекватной бизнесу отчетности неразделимы. Уделяя первостепенное внимание отчетности, банк вынужден столь же внимательно относиться и к выбору продуктов и технологий в области построения хранилищ данных.
Выпуск отчетности, особенно официальной, составляемой по требованиям и правилам Центрального банка России, — задача особого значения для ИТ-подразделений. Для банков важность такой отчетности еще выше: ее несвоевременная подача подвергает риску само существование кредитной организации. Любое серьезное изменение требований регуляторов к формам или содержанию отчетности влечет за собой авральную занятость множества банковских ИТ‑специалистов. Чаще всего подготовка отчетов, их согласование и проверка — процесс чрезвычайно трудоемкий, отнимающий много сил и времени, поэтому проектов автоматизации формирования банковской отчетности немало. Опыт «Газэнергопромбанка» в этой области дает интересную информацию к размышлению.
В «Газэнергопромбанке» решили строить единое универсальное хранилище, и первой из задач, которые оно помогает решать, стала подготовка официальной отчетности для ЦБ. Ограничиться этим в банке не собираются, и со временем планируется также подготовка управленческой отчетности.
Решение о создании хранилища было принято в конце 2007 года. Такой подход не был чем‑то новым: уже несколько лет эксплуатировалось хранилище самописное, но оно было построено на Pervasive SQL и имело ряд существенных ограничений по производительности и объемам обрабатываемых данных. Дальше поддерживать морально устаревшую систему совершенно не хотелось. Хранилище в этом случае — единая база данных в головном офисе, куда собираются все данные из филиалов. Собранные данные обрабатывались, из них формировалась обязательная отчетность и некоторые формы управленческой отчетности. Однако при использовании самописного хранилища требовалось очень много времени для согласований, контроля и работы программистов. При этом достичь требуемой руководством оперативности было нереально. «Старая база достигла своего предела», — говорит Андрей Бурым, директор департамента информационных технологий банка.
В банке имелся опыт эксплуатации хранилища, и он очень помог в новом проекте: регламенты подготовки и сдачи отчетности уже были отлажены. Именно их и взяли за основу, что сильно упростило создание нового хранилища данных, считает Бурым.
Принципиально важно было использовать тиражное, промышленное решение. Это не случайность, а реализация планомерного подхода. «Мы за шесть лет не взяли ни одного нового программиста, — говорит Бурым. — У нас банк корпоративный, никаких особенно стремительных изменений у нас не происходит, и поэтому наша политика — развитие ИТ‑систем на базе готовых продуктов».
«Мы посмотрели продукты R-Style, «Диасофт», — говорит он, — рассматривали один из западных продуктов, но решили, что нам еще рано его использовать, тем более что на тот момент он еще мало внедрялся в российских банках. Вместе с тем у «Контура» более 60 внедрений в российских банках, десятки историй успеха, и мы остановились на этом продукте. В качестве подрядчика выбрали самих разработчиков». Возможно, это в значительной степени и определило успех проекта, подчеркивает Бурым и добавляет: «Кроме того, мы сделали референс-визит в «Транскредитбанк», где используется такая же система, и мнение коллег оттуда стало решающим при выборе системы. Их пример нас убедил в том, что «Контур» сможет работать в большом банке и нам не придется сразу же искать замену».
В «Газэнергопромбанке» только три основные учетные системы — АБС «Кворум», розничная система «3Card-R» и модуль учета ценных бумаг «Аскина». Две из них используют базы Oracle, одна — MS SQL‑сервер, объемы данных в них не слишком велики, поэтому ИТ-директор не видит смысла в использовании интеграционных шин для их связывания на данном этапе. Для хранилища была по этим же причинам выбрана версия «Контур» на Oracle.
Как только начинается диспут сторонников собственных разработок и адептов промышленных решений, обязательно упоминается тезис о зависимости: меняя самописное решение на тиражное, вы из кабалы программистов собственных попадаете в кабалу программистов разработчика. Андрею Бурыму не кажется актуальной такая проблема. До сей поры разработчики «Контура» за требованиями ЦБ успевали, а это в данном случае главное.
На первом этапе начали делать формы отчетности ЦБ, поскольку именно с этой отчетностью связаны основные риски. Так как схемы сдачи отчетности были уже отлажены, для филиалов со сменой продукта практически ничего не изменилось, они продолжили работать по известному им регламенту. «На подготовку ушло около трех месяцев, и через этот срок мы были готовы к выпуску первых форм, — рассказывает Бурым. — Мы также хотели упростить работу конечных пользователей с хранилищем, и это действительно получилось, так как «Контур» — современное и удобное решение для работы с базой данных по готовым формам, причем реализованы через Web-интерфейс, и требования к аппаратной части там минимальные».
Конвертацию данных из самописной системы в промышленную не проводили, просто с 1 января 2008 года стали загружать данные в новое хранилище. Три квартала в банке вели параллельный выпуск отчетных форм, сверяя результаты. Департамент финансов и другие бизнес-подразделения активно участвовали в проекте, поскольку были прямо заинтересованы в результатах, обсуждали каждое ТЗ, вспоминает Бурым. Он утверждает: когда есть ясное понимание конечной цели, когда не звучат призывы «все менять, потому что надо все поменять», к проекту и относятся по‑другому. Андрей Бурым рассказывает: «Как только мы определились с данными и их отображением, проект пошел по графику, и 1 августа 2009 года мы сдали отчетность ЦБ из новой системы». Пока реализованы около 30 форм отчетности. Когда будут готовы все 60 форм отчетности ЦБ, а эту работу планируется закончить к середине следующего года, в банке намерены заняться развитием управленческой аналитики, а также бюджетированием с использованием функций и возможностей «Контура».
Для создания витрин данных совместно с хранилищем применяется Oracle BI. По словам Бурыма, этот продукт полностью оправдал ожидания. Наладить взаимодействие двух продуктов оказалось легко. Обучать конечных пользователей практически не потребовалось. «По нажатию трех клавиш пользователь получает необходимую ему выборку, например балансовый отчет, в котором он может, переходя по ссылкам, углубиться в данные вплоть до отдельной проводки, — поясняет Бурым. — Мы намеренно разделили работу аналитиков с хранилищем и доступ к нему конечных пользователей. Собственно аналитиков немного: около 10 в головном офисе и по одному в каждом филиале, всего около 50 человек. Их со временем станет больше, но не намного».
«С появлением этого хранилища мы можем быть уверены, что у нас есть проверенные данные, собранные в одном месте, и они надлежащим образом защищены, — говорит он. — Мы грузим данные в единое хранилище по всем филиалам и головному офису за один день не более 60 минут. Это 120 тыс. клиентов, 220 тыс. лицевых счетов, 70 тыс. бухгалтерских документов, в сумме это более 1 млн записей. Поэтому аппаратная часть нас пока устраивает, и пока не начнем собирать данные по сделкам, менять ее не стоит. Чтобы обеспечить работу хранилища, мы взяли наполовину заполненный блейд-центр IBM, добавили одно лезвие и полку с дисками. На такой аппаратной базе хранилище и функционирует (подробнее об применении блейд-центра см. стр. 75). Со временем будет видно, действительно ли нам нужно получать данные быстрей, чем за один час. Если да, то будет иметь смысл апгрейд сервера», — поясняет Бурым.
Последовательно или параллельно?
Евгений Ерофеев,
директор департамента BPM-систем компании GMCSПоследовательность построения аналитической отчетности выбирается в зависимости от многих параметров и условий. В числе таких факторов — требования внешней среды (то есть организаций, устанавливающих сроки предоставления отчетности, регламенты и т.д.). Следует выбрать последовательный подход, если четко поставлена задача получить отчетность к какому‑то конкретному периоду. Например, для банка — в соответствии со сроками, установленными ЦБ РФ. Если строгой привязки к срокам нет, то можно разрабатывать отчеты параллельно, и тут многое будет зависеть от имеющихся у заказчика ресурсов, а также от компетенции исполнителя.
Вносит свои коррективы и отраслевой фактор. Для ряда предприятий простои в работе исчисляются в денежном выражении. Поскольку хранилище данных составляет фундамент BI‑системы компании, невозможность получить информацию, требуемую для принятия управленческих решений, самым прямым образом влияет на эффективность деятельности. Поэтому можно рекомендовать при создании отчетности ранжировать типы отчетов по степени важности получения той или иной информации: критичные для деятельности компании отчеты формировать в первую очередь, а менее важные временно отложить.
В целом, если рассматривать проблему шире, при построении хранилища данных также может применяться как последовательный, так и параллельный подход. В первом случае за основу, как правило, берется департамент или подразделение компании с устоявшимися бизнес-процессами, где используется набор отчетов, понятный и для внутренних, и для внешних пользователей. Важную роль играет готовность самого заказчика к проекту. Когда заказчик готов, построение отчетности может осуществляться параллельно путем делегирования полномочий исполнителям. В противном случае заказчик берет на себя обязательство проработать на примере определенной области бизнес-правила, регламенты, логику формирования отчетов и передает их в виде технических требований подрядчику. Такая проработка иногда занимает довольно много времени, но позволяет исключить непонимание между заказчиком и исполнителем.
