Можно ли нам внедрять регуляторное хранилище? У нас очень плохие данные

Недавно потенциальный заказчик спросил меня: «Можно ли нам внедрять регуляторное хранилище? У нас очень плохие данные.»

«Поздравляю. Вы гораздо ближе к результату, чем многие ваши коллеги» – ответила я.

И вот почему.

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

Чаще всего банки оценивают качество первичных данных как «высокое», намного реже – как «хорошее». А «ниже среднего» и подобные формулировки встречаются очень редко.

Но на деле все ровно наоборот. Проблемы с качеством данных есть всегда. У большинства банков проблем много. При внедрении регуляторного хранилища выполняется огромная работа по их выявлению и исправлению. В общем случае исправить обнаруженные проблемы можно:

1. В системе-источнике. Это предпочтительный вариант. Для его реализации может потребоваться доработка учетных модулей (чтобы обеспечить хранение и ввод недостающих данных) или дополнение регламента работы с ПО (чтобы, например, операционист обязательно вводил необходимые данные) и др. В результате сотрудники исполнителя просто перестают создавать бОльшую часть проблем с данными.
2. В рамках ETL-процесса. Здесь часто решают проблемы некорректных дат, допустим, когда дата открытия счета в АБС больше даты первой операции по нему, или восстанавливают недостающие данные, например вычисляют отсутствующие обороты по счетам, и проч.

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

Устранить ошибки в данных, особенно на стороне систем-источников, – большая техническая и организационная работа. И она обязательно выполняется при создании регуляторного хранилища. То, как заказчик распорядится её результатами, во многом определит будущее качества данных в банке:

• Если сделает один раз и забудет сразу после завершения проекта – качество данных и в источниках, и в хранилище постепенно снова придет в упадок. Потому что не существует исчерпывающего списка проблем в данных. В ходе проекта можно устранить все обнаруженные недостатки и ошибки. Но со временем неизбежно будут появляться новые.
• Если использует как отправную точку для создания технологии контроля качества данных в банке – существенно улучшит первичные данные, повысит доверие к хранилищу и качество отчетов для разных подразделений.

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

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