---

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

Цели и результаты проекта

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

Целесообразность построения хранилища объяснялась ограниченными функциональными возможностями существовавших информационных систем банка для решения аналитических задач. Для этого использовались два различных источника информации, целевым назначением которых являлся сбор и накопление данных из транзакционных систем головного офиса и филиалов. При этом данные, содержащиеся в источниках, дублировались на 80%, были рассредоточены, не согласованы, не структурированы, зачастую избыточны и не всегда достоверны, что не позволяло использовать их для поддержки принятия управленческих решений.

По итогам пилотного проекта ВТБ остановился на варианте корпорации Oracle и компании РДТЕХ, предложивших в качестве программной платформы для создания корпоративного хранилища данных комплекс приложений Oracle Financial Services Applications, адаптированный под специфику банковского бизнеса. Oracle Financial Services Applications представляет собой типовую аналитическую модель банковской деятельности и набор бизнес-приложений, работающих с этой моделью и позволяющих автоматизировать процессы бюджетирования, управления финансовыми рисками, подготовки управленческой отчетности и обязательной отчетности для Банка России. Основной этап создания корпоративного информационного хранилища длился полтора года, причем было решено не использовать результаты пилотного проекта. Разработка началась с нуля, так как было бы намного трудозатратнее доводить имевшееся упрощенное решение с ограниченной функциональностью до промышленного уровня.

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



Сбор первичной информации ведется из автоматизированных банковских систем 55 филиалов ВТБ. Эти системы не до конца унифицированы, и каждый филиал обладает собственной, отличающейся от других, системой настроек АБС. Кроме того, данные в хранилище поступают из 20 систем Головного офиса ВТБ и включают информацию из различных мидл- и бэк-офисов, а также необходимые для подготовки аналитической отчетности сведения из фронтальных систем.

На базе хранилища работают бизнес-приложения, обеспечивающие расчет трансфертных результатов и резервов, анализ балансовых рисков и операционной деятельности Банка, подготовку отчетности для Банка России, анализ кредитного портфеля, открытой процентной позиции, а также доходов и расходов в разрезе продуктов, клиентов и точек продаж.

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

Особенности ведения проекта

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

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

Во-вторых, в ВТБ фактически отсутствовал единый заказчик Корпоративного хранилища данных. Несмотря на то, что управление и мониторинг проекта осуществляется Финансовым департаментом банка, хранилище строится в интересах многих подразделений. Команде, внедрявшей Корпоративное хранилище данных, пришлось провести большую работу по согласованию требований и приоритетов разных заказчиков: помимо Финансового департамента, отвечающего за управленческую отчетность, в ВТБ ими выступили также Центральная бухгалтерия с подготовкой обязательной отчетности для Банка России и Департамент рисков. В результате ушло много времени на то, чтобы унифицировать понимание подразделениями своих и чужих бизнес-процессов.

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

Причины возникновения проблемы качества данных

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

Так, операционист банка вводит данные во фронт-офисную систему, откуда они попадают в локальную АБС по определенному трафику передачи данных. Затем информация в онлайновом или офлайновом режиме передается в Головной офис ВТБ, где преобразуется и загружается в хранилище, которое, в свою очередь, построено в соответствии с бизнес-правилами и типовой структурой Oracle Financial Services Applications. На базе хранилища формируется витрина данных и используется в работе прикладного бизнес-модуля. Так как не бывает программного обеспечения без единого недочета, ошибки на таком протяженном тракте передачи данных выявляются обязательно, особенно много их оказывается в момент внедрения системы. Каждую из ошибок в отдельности исправить не составляет труда, однако выяснить, на каком этапе тракта она произошла, крайне проблематично, причем сам процесс исправления ошибок также трудоемок из-за необходимости привлечения поставщиков систем-источников и изменения бизнес-процессов.

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

Помимо технических и организационных проблем мы столкнулись и с самими "грязными" данными. К ним относятся неполные, некорректные и неунифицированные данные. Если последние в основном касаются разнородной информации о клиенте, представленной в системе, и унифицируются за счет использования разнообразных средств автоматизации (например, решения Oracle Siebel Universal Customer Master), в ВТБ основную сложность представляли первые две проблемы качества данных.

До начала проекта не вся необходимая для бизнес-аналитики информация велась в системах-источниках ВТБ, поэтому мы были готовы к тому, что первоначальное качество данных в хранилище получится не очень высоким. Кроме того, было невозможно перестроить фронт-офисные системы таким образом, чтобы они контролировали качество информации в момент ввода, так как не у всех данных есть модель совершения операций, а бизнес-процессы продажи банковских продуктов подразумевают возможность дополнения информации на более позднем этапе. В результате это приводило к тому, что многие данные были не внесены или введены неправильно, что напрямую влияло на качество формирования отчетности. Например, неполные данные по участникам банковской группы могли искажать форму отчетности 0409134, по группам связанных клиентов - 0409157, по сделкам межбанковского кредита - 0409501, по НОСТРО - 0409501, переоценке по средневзвешенной цене - форму 0409134. В свою очередь, некорректные данные по наличию оборотов за границами жизни счета приводили к ошибкам в форме 0409102, а неунифицированные данные по субъектам и клиентским записям затрудняли формирование формы 0409157.

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

Традиционный путь решения проблемы качества данных

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

Со временем мы пришли к пониманию, что проблема качества данных может быть вызвана несовершенством самих эталонов. Так как при подготовке эталона бизнес-подразделения ВТБ использовали информацию, полученную по телефону, электронной почте и из файлов в формате Microsoft Excel, возможность проникновения ошибок в сам эталон умножалась на неточности в системах-источниках 55 филиалов и более, чем в 20 системах Головного офиса ВТБ. В результате было принято решение пересмотреть методологию управления качеством данных и технически закрыть проверками все этапы тракта доставки информации.

Практика применения новой методологии

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

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

Результаты управления качеством данных в хранилище

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

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

Источник: https://banktech.ru/