Все данные под одной крышей

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

Об особенностях управления данными в финансовой группе и самых интересных и важных деталях этого проекта рассказывает Евгений Павлов, начальник Департамента развития и сопровождения программного обеспечения Пробизнесбанка, головного банка ФГ Лайф.

Какова специфика Финансовой Группы Лайф в плане хранения данных и управления ими?

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

При консолидации данных подобная система действительно важна. Нередко для крупных финансовых организаций именно разнородность ПО является серьезным препятствием. В таких организациях применение промышленной модели (КХД), аналогичной той, которую мы выбрали, сопряжено с большими сложностями, поскольку. сложить в однородную структуру данные из разрозненных структур, порой, противоречащих друг другу, очень сложно. Чаще всего в таких случаях приходится управленческую и другую отчетность делать в в каждой из организаций отдельно, а затем консолидировать уже готовые отчеты, так как прописать единую методику формирование отчетности, имея “зоопарк” систем, гораздо сложней, ведь нужно учесть особенности каждой из них.

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

Подобная модель централизованной инфраструктуры была запланирована изначально или создавалась постепенно?

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

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

Кто был основным инициатором и спонсором проекта?

Проект выполнялся в рамках инвестиционного бюджета Финансовой Группы Лайф, основным заказчиком являлся президент Сергей Леонтьев. По уровню финансирования проект был одним из самых крупных в нашей финансовой группе. Вторым заказчиком был финансовый директор, которому требовалось перевести управленческую отчетность на новый уровень – требовалось сократить время выдачи отчетности и повысить ее качество.

По какой схеме формировалась отчетность до внедрения единого корпоративного хранилища? На какие этапы можно разделить проект?

До внедрения промышленного решения корпоративного хранилища данных у нас было собственное разработанное хранилище, которое позволяло построить управленческую, часть рисковой отчетности и ряд аналитических отчетов, но все они были разрозненны, и готовили ее разные подразделения. Поэтому, хотя на входе мы имели единые учетные системы, но разные методики и «руки», которые это реализовывали, в результате на выходе отчеты могли не сходиться, что было неприемлемо. Мы приняли решение о создании единой системы отчетности, составленной на основе общих начальных данных. На первом этапе занялись управленческой отчетностью, поскольку она была самая проработанная, следующим шагом стала отчетность по РСБУ и рисковая отчетность. В этом году мы как раз занимаемся переводом рисковой отчетности, что значительно расширит объем детальных данных в нашем хранилище. Также переводится часть регламентированной отчетности, которая у нас сдается из АБС (автоматизированной банковской системы) и из программы «Инэк». Раньше у нас использовалась следующая схема: главная книга, промежуточная база, затем «Инэк». Теперь мы намерены отказаться от промежуточной базы, а все недостающие данные для «Инэк» получать в корпоративном хранилище. Иными словами, мы не будем из главной книги загружать данные в несколько систем, убрав тем самым повторяющиеся звенья. Такая же схема применена и для других видов отчетности.

Помимо единого детального слоя в рамках проекта мы создали ряд основополагающих «витрин» — по кредитам, по депозитам, по комиссионным продуктам, данные из которых мы используем в различных видах отчетности. Благодаря этому мы можем гарантировать, что, к примеру, остаток по кредиту в управленческой и рисковой отчетности посчитан одинаково.

Какие проблемы возникали в ходе проекта и как они были решены?

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

Другая проблема – это сроки. Cроки реализации были очень сжатыми – Внедрить КХД за один год – это ”подвиг” . У проекта были амбициозные KPI, и мыдолжны были их выполнить, контроль выполнения KPI велся на уровне президента ФГ Лайф.

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

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

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

Все ли пожелания удалось удовлетворить в ходе проекта?

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

Ваша финансовая группа в рамках проекта первой в России внедрила Oracle Financial Services Analytical Applications (OFSAA). Каково быть первопроходцами?

Мы первые в России и одни из первых в мире. Официально наш проект начат в апреле 2011 года, а сам продукт OFSAA появился в декабре 2010 года. На этапе первоначальных тендеров и знакомства с имеющимися на рынке решениями наш партнер компания «РДТЕХ» предлогала вместо промышленной модели детального слоя свою внутреннюю разработку. Мы пересмотрели множество продуктов, в первую очередь, мы обращали внимание на те, которые изначально были разработаны для России. Но именно с появлением OFSAA вопрос решился окончательно, поскольку эта система перекрывала больше запросов, чем мы планировали выполнить. Другие приложения, как правило, были предназначены для конкретного вида отчетности — либо набор «блоков», либо набор подотчетов, ориентированных на российскую действительность, и стандарты. Если говорить о моей позиции я выбирал именно хранилище, а не решение для реализации управленческой отчетности, хотя именно ее мы сделали в первую очередь. Наше подразделение занималось и управленческой, и аналитической отчетностью, поэтому мне было интересно решение, позволяющее закрыть множество областей. Сейчас, внедрив КХД для управленческой отчетности, мы добавляем рисковую отчетность, уже зная, как устроен детальный слой, немного модернизируем в соответствии со спецификой и получаем результат.

У продукта OFSAA отсутствовали структуры, в которые можно было бы поместить российский бухучет (проводки). Эту кастомизацию наш партнер осуществил довольно быстро, и она оказалась не такая сложная, хотя изначально были опасения, что потребуется большие усилия. Каково быть первопроходцами? С одной стороны, плохо, а с другой — хорошо, поскольку в ходе проекта мы получили поддержку от корпорации Oracle. Вендор очень заинтересован в таких проектах, поэтому он всячески помогал нашему подрядчику.

В целом, опыт можно назвать успешным, и уже в текущем году мы реализуем проект по внедрению MDM (Master Data Management), в ходе которого мы опять же первыми в России будем внедрять продукт Oracle Data Quality в связке с Siebel UCM.

И последний вопрос. Какие бизнес-процессы в наибольшей степени оптимизированы в результате создания единого корпоративного хранилища данных?

У нас не было общего для всей финансовой группы инструмента бизнес-аналитики. Были отдельные, разрозненные BI-решения, а теперь мы получили дополнительные BI-средства, где отображены информационные панели для руководителей различного ранга. Раньше мы рассылали Excel-файлы и использовали самописную программу, которая «лазила» в хранилище данных и оттуда извлекала информацию. Но все равно подобные отчеты были довольно просты и не позволяли многое проанализировать. Для нас это важно так как во всех подразделениях финансовой группы введена система внутреннего хозрасчета, и все они, в том числе и сервисные, ведут свой внутренний P&L (отчет о прибыли и убытках). Соответственно, бизнес-аналитика для всех очень важна. А чем удобнее инструмент, тем легче с ним работать.

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