Проблемы качества данных и варианты их решения. Часть II. Обнаружение, регистрация, исправление и контроль

Технологии
2180
0
Сергей Сетрин, директор проектов департамента аналитических систем, R-Style Softlab

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



Обнаружение проблем

Говоря об обнаружении проблем качества данных (далее — КД), следует использовать простое правило: чем ближе к изначальному источнику данных имеется возможность их обнаружить или исправить, а еще лучше — и вовсе предотвратить появление, тем лучше.

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

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

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

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

По моему убеждению, реалии на сегодняшний день таковы, что оптимальным вариантом для каждого банка является разработка на базе ХД системы поиска и учета ошибок с уклоном именно в ту область (или области), которая является для банка приоритетной.

Это могут быть как первичные данные с широким охватом в нескольких особо важных учетных системах (например, АБС и карточная система), так и специализированный набор показателей для нужд управленческой, МСФО и прочей отчетности. Зачастую проблемы КД как раз и выявляются при составлении и проверке указанных видов отчетностей, а сам процесс поддержания КД во многих банках начинает строиться как необходимый дополнительный атрибут ко всему трансформированной и агрегированной информации.

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

Регистрация

Если ХД используется для регистрации обнаруженных ошибок, и процесс этот имеет достаточно серьезный подход, то система КД в банке превращается, по сути, в собственную систему отчетности в разрезе источников, сущностей, областей проверок, которые еще и разделены по типам. Стандартов тут нет, и степень сложности и вариативности выстроенной структуры зависит только от архитектуры решения и количества «мастеров», приложивших руку к его созданию.

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

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

Наиболее продвинутые банки используют BI (Business Intelligence) для построения общедоступной отчетности по КД — для удобства всех заинтересованных пользователей.

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

Исправление ошибок

Касаемо исправления ошибок КД есть два пути — правильный, но долгий и неправильный, но быстрый.

Правильный путь выглядит так:

1. Обнаружение ошибки в ХД.
2. Формирование пула записей для исправления в разрезе структурных подразделений, филиалов или лиц, ответственных за данную информацию.
3. Отправка данного пула записей на исправление или оповещение о нем (зависит от выстроенного процесса) ответственных лиц.
4. Согласование сроков исправления данных в учетных системах или следование установленным внутренними инструкциями срокам.
5. Контроль исправлений в ХД.

Плюсами этого подхода являются: постоянное поддержание достаточной чистоты данных в учетных системах, повышение дисциплины пользователей, отсутствие риска получить порцию неверных данных при очередной загрузке в ХД.

Неправильный, но порой единственно возможный путь заключается в исправлении данных уже непосредственно в ХД, причем зачастую минуя слой DDS (Detailed Data Store / Stage) и затрагивая, например, базовые или прикладные витрины.

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

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

Контроль

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

Итоги

Процесс управления качеством данных проходит практически через все системы банка, но не в том порядке, как ETL, а в обратном — начиная от хранилища данных и заканчивая той или иной системой-источником.

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

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


Все статьи

Комментарии



Подписка на рассылку
Сортировать
Теги:
Все теги
Выберите интересующий Вас продукт компании
Любой продукт
Сортировать по году:
2015 2016 2017 2018 2019 2020