«Банковские технологии»: Начнем с опыта компании по построению хранилищ. Где работают системы отчетности, построенные компанией «Неофлекс»?

Василий Кузьмин: Мы занимаемся хранилищными проектами с момента основания компании «Неофлекс», т. е. пять с половиной лет. Причем первый наш проект — в СДМ-Банке — это был как раз проект по созданию системы для подготовки управленческой отчетности. Сегодня на наших хранилищах формируют отчетность целый ряд иностранных и российских банков. В их числе Русфинанс Банк (группа Societe Generale), банк БНП Париба Восток, Бинбанк, СДМ-Банк, Ханты-Мансийский банк и др. В хранилищных проектах мы используем наш собственный продукт — систему для формирования банковской отчетности Neoflex Reporting. У нас есть клиенты, которые с помощью этой системы готовят один вид отчетности, скажем, обязательную. Есть также банки, где с помощью нашей системы формируется несколько видов отчетности, например, управленческая, обязательная и МСФО. Отдельно хотелось бы сказать о создании с помощью Neoflex Reporting системы для подготовки обязательной отчетности. Создать такую систему — объективно сложная задача, поскольку речь идет о системе, в которой данные соответствуют данным исходных систем с точностью до копейки. В значительной степени это удается делать благодаря входящей в Neoflex Reporting подсистеме контроля качества. «Б. Т.»: Что представляет собой Neoflex Reporting ? В. К.: Система состоит из трех больших частей. Это, во-первых, наша собственная модель данных, которая описывает бизнес универсального российского банка, вторая часть — подсистема контроля качества данных, и третья — набор модулей для формирования разных видов отчетности: обязательной, МСФО, управленческой, налоговой и др. В течение нескольких лет развития продукта мы одновременно с расширением состава поставляемых отчетов расширяли и углубляли функциональность подсистемы контроля качества данных. За это время мы опробовали десятки подходов к решению многих проблем, и сегодня все наши находки аккумулированы в Neoflex Reporting в виде шаблонов, архитектурных принципов, работающих компонентов.

«Б. Т.»:   Расскажите подробнее об отчетности, которая подготавливается в системе. В. К.: Мы имеем сегодня в системе несколько модулей отчетности. Первый модуль — это обязательная отчетность. Сразу скажу, что мы не только реализовали эти отчеты и передаем их банку при внедрении, мы и сопровождаем последующие изменения законодательства для обязательной отчетности. Это важный момент, так как требования Центробанка и других регулирующих органов имеют свойство меняться. Второй модуль — это международная отчетность. Это отчетность МСФО, но не только. Многие из наших клиентов — это иностранные банки, которым нужно готовить отчетность для головной организации в специфичных форматах, например GAAP. Поэтому с самого начала перед нами стояла задача разработки настраиваемого универсального модуля, позволяющего выполнять трансформацию данных из российского учета в западный. Корректировки российской отчетности формируются либо автоматически, либо вручную. Это целый механизм надстройки над хранилищем, с которым работают пользователи. Третий вид отчетности — это управленческая отчетность: управленческий баланс, отчет о прибылях и убытках, отчет о движении денежных средств, показатели эффективности, рассчитываемые с учетом аллокации накладных доходов и расходов и трансфертного ценообразования, натуральные показатели. Практически все, что банкам нужно на поле управленческого учета, реализовано в нашей системе. Далее налоговая отчетность, которую часто относят к регуляторной отчетности, но все же она стоит особняком, так как требует сложных преобразований данных для последующего расчета налоговых регистров. Основная причина, почему мы реализуем разные виды отчетностей на единой системе, на одном хранилище данных — это экономия банка на создании систем отчетности и их сопровождении. Данные единожды собираются в хранилище, выполняются всевозможные проверки качества, и на базе единого корпоративного хранилища детальных данных формируются разные виды отчетности.

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

«Б. Т.»: Как вы понимаете качество данных в хранилище, за счет чего оно обеспечивается? В. К.: Когда говорят о системах контроля качества данных, подразумевают, как правило, техническое качество данных: ссылочную целостность, обязательность полей, правильность заполнения атрибутов у отдельных записей. Иногда термин «качество данных» понимают как синоним «качества клиентских данных» — правильно ли введены фамилия, имя, отчество клиента, правильна ли адресная информация, соответствует ли она КЛАДРу, нет ли дублирующей информации и т. п. Но это только технический контроль — первый уровень обеспечения качества информации. Для его реализации существует много инструментов класса Data Quality от разных вендоров. Следующий уровень — это контроль качества детальных данных, поступивших из учетных систем, исходя из их внутренней логики. На этом уровне проверяются взаимосвязи между отдельными сущностями в разрезе детальных данных: сделок, счетов, проводок и т. п. Например, если есть кредит, то с ним должны быть связаны счета определенных типов, и эти счета должны соответствовать сроку кредита, типу заемщика и другим условиям. Подобными проверками — прежде всего соответствия сделочной и бухгалтерской информации — мы пронизываем весь массив данных банка. Это позволяет нам получать полную картину качества данных и управлять качеством конечных отчетов. Вживую это выглядит следующим образом — после загрузки данных автоматически выполняются десятки проверок, в результате которых выдается отчет в виде журнала, где фиксируются все обнаруженные проблемы детальных данных. Наконец, есть третий уровень контроля качества данных — это проверки, которые выполняются с уже рассчитанными показателями конечных отчетов. Прежде всего, это внутриформенный и межформенный контроль, а также сверка показателей из разных видов отчетности. Например, итоговые значения многих отчетов ЦБ должны сходиться с графами оборотно-сальдовой ведомости. Есть и более сложные зависимости. Кроме того, в банках есть задача сверки итоговых и промежуточных значений, полученных для разных видов отчетности: обязательной, управленческой, налоговой и международной. Даже если эта отчетность получается из одного источника, это еще не гарантия того, что между ее разными видами не будет расхождений — например, расхождений между управленческим балансом и бухгалтерским. Третий уровень проверок нам эту гарантию дает.

«Б. Т.»: Что побудило вас выделить разные виды отчетов в отдельные модули? В. К.: Для нас очень важно, чтобы заказчик быстро получил результат. Последовательное внедрение отдельных модулей — обязательная отчетность, управленческая и т. д. — позволяет быстро получать работающие наборы отчетов. Таким образом, с помощью модулей мы обеспечиваем банку возможность сдавать, скажем, обязательную отчетность безотносительно готовности данных для других видов отчетности. Когда мы говорим о модулях Neoflex Reporting , мы имеем в виду не просто наборы отчетов, сгруппированных по функциональному признаку. Модульность реализована нами на уровне архитектуры. Мы делим по модулям также витрины данных. Даже модель данных имеет блоки, ориентированные на подготовку конкретных типов отчетов. При внедрении системы механизм загрузки данных обязательно проектируется с учетом разбивки системы на модули.

«Б. Т.»: Какие факторы влияют на обеспечение качества данных? В. К.: Таких факторов несколько. Первый фактор — модульность. Это одно из трех измерений, которое необходимо учитывать при выстраивании системы проверок — для разных видов отчетности важны свои проверки качества данных, периодичность выполнения групп проверок должна соответствовать режиму работы пользователей с конечными отчетами. Второе измерение — это многофилиальность, т. е. работа с данными большого числа филиалов банка, разнесенных по часовым поясам. Здесь есть сложности, связанные с тем, что одни и те же проверки нужно выполнять и по данным филиалов, и по данным всего банка. Степень готовности данных по разным филиалам для помещения в хранилище может быть разной, и график выполнения проверок должен учитывать время закрытия операционного дня в конкретном филиале, внесение исправлений в исходные данные, получение отчетов в разрезе филиалов и т. п. Наконец, третье измерение — сегментирование загрузки по системам-источникам. Здесь нужно обеспечить согласованность асинхронных потоков данных, извлекаемых из отдельных учетных систем, учесть индивидуальные особенности данных, поступающих из конкретной системы, подстроить работу проверок и расчетов под график поступления данных из каждого источника. Все это делает проектирование механизма загрузки и подсистемы контроля качества весьма нетривиальной задачей. Чтобы видеть все риски, связанные с обеспечением хранилища качественными данными, и знать, что этим рискам можно противопоставить, нужно выполнить не один и не два проекта по реализации отчетности в банке, нужно как следует прочувствовать, как все это работает.

«Б. Т.»: Что значит многофилиальность для хранилищного проекта? В. К.: Мы сейчас делаем проект в банке, который имеет 35 филиалов по всей стране. Хранилище в таком банке должно обеспечивать независимую загрузку данных филиалов, формирование любых необходимых отчетов в разрезе филиалов, поддерживать разграничение прав доступа к данным филиалов. При этом филиалы могут находиться в разных часовых поясах и управлять своими данными независимо от данных головного отделения. В чем сложность? Один филиал уже закрылся и уже хочет формировать отчеты, а другие филиалы, в том числе головной, еще работают, и данные в них еще не готовы для передачи в хранилище. Но пусть все данные уже загружены. Казалось бы, получило хранилище данные, они там похоронены — и все. К сожалению, в жизни не так: когда приходят данные, отрабатывает система контроля качества, она сообщает о том, что там-то ошиблись при вводе, там-то в системе данные неправильно были захвачены. По результатам проверок качества специалисты филиалов вносят в свои системы исправления (причем нужно понимать, что данные могут быть исправлены как на следующий день, так и в течение месяца), а параллельно с этим идут догрузки данных из других филиалов. И так круглые сутки. В таких случаях мы применяем инновационную технологию сегментирования загрузки данных. Речь идет о параллельной передаче данных из разных филиалов и разных учетных систем. В результате по тем данным, которые поступили из закрывшихся филиалов, например находящихся на востоке России, уже можно получать отчеты, хотя из части филиалов данных еще нет. При этом процессы загрузки данных, контроля качества, сборки витрин и получения отчетов полностью развязаны и осуществляются строго в разрезе филиалов. В то же время они организованы таким образом, что поддерживается возможность строить сводный баланс банка и консолидированную отчетность, которая включает все данные организации.

«Б. Т.»: Каким вы видите дальнейшее развитие вашего продукта? В. К.: Сейчас Neoflex Reporting развивается сразу в нескольких направлениях. Одно из наиболее интересных — это интеграция наших модулей отчетности с хранилищами данных, построенными другими поставщиками. Дело в том, что во многих банках хранилище уже есть. У него может быть своя модель детальных данных и платформа, и наша задача состоит в том, чтобы настроить получение из этого хранилища отчетности того или иного вида. В этом случае мы устанавливаем поверх существующего хранилища, в качестве бизнес-приложения, нашу подсистему контроля качества данных и нужный модуль отчетности, например, отчетность ЦБ. Еще одно направление развития, — это реализация на нашей платформе различных аналитических задач, связанных с планированием, бюджетированием, контролем расходов, сегментированием клиентской базы и т. п. «Б. Т.»: Спасибо за беседу.

Банковские технологии, №8, 2010

Источник: Банковские Технологии


Поделиться

Вернуться к списку публикаций