Здравствуйте, меня зовут Даниил и я занимаюсь развитием аналитических систем в банке «Ренессанс Кредит». В этой статье я расскажу о том, как мы создавали систему контроля качества данных для хранилища обязательной отчетности. Такой контроль необходим, чтобы утвердительно ответить на простой, но чрезвычайно важный вопрос бизнеса: «Могу ли я доверять этому источнику информации?». Возможно, какие-нибудь из описанных приемов помогут и вам в решении разных задач.
В качестве вступления — немного о нашей инфраструктуре и об аналитических системах в нашей работе.
В инфраструктуре Ренессанса аналитические системы служат источником информации для collection-систем и систем противодействия мошенничеству. Наше Data Warehouse (DWH) – это не просто корпоративное хранилище в классическом понимании этого термина, необходимое для аналитики и отчетности. Это система, способная трансформировать и отдавать данные в другие бизнес-системы для поддержания бизнес-процессов, не связанных с аналитикой.
Если говорить о нашем технологическом стеке, то в основном мы используем Enterprise-решения. Наши хранилища (оперативное, аналитическое и обязательной отчетности) работают на БД Oracle, ETL процессы реализованы при помощи ПО Informatica Powercenter, а в качестве Business Intelligence инструмента мы используем продукт Cognos от IBM. Для репликации данных в оперативное хранилище мы также применяем продукт от Oracle – это GoldenGate. Потребности пользовательской аналитики закрываются продуктами от SAS – Miner и Enterprise Guide.
При этом мы находимся в постоянном поиске бесплатных или условно-бесплатных альтернатив решениям больших вендоров и для задач, не чувствительных к SLA, стараемся точечно пилотировать такие решения.
Краеугольная характеристика данных при работе с ними — это не количество, а качество. Если данным невозможно довериться, то технологические инвестиции и развитие экспертизы не принесут никакого результата. Проблема здесь в том, что на основе некачественных данных могут приниматься неправильные управленческие решения, что приводит к печальным последствиям для бизнеса. Именно это будет учитывать твой потенциальный внутренний заказчик в первую очередь. Он будет задавать себе один вопрос: «Могу ли я доверять этому источнику информации?».
Итак, давайте разберемся, как устроено хранилище обязательной отчетности. Оно состоит из трех слоев (к слову, достаточно типичных):
Проект внедрения системы обязательной отчетности стартовал в банке в 2013 году с одной задачи расчета обязательных резервов на портфели однородных ссуд. После успешной и относительно быстрой реализации этой задачи стало понятно, что у системы есть будущее и её использование можно масштабировать на процессы сдачи отчетных форм ЦБ и для отчетности другим регуляторам (например, ФНС).
Совместная команда IT и бизнеса сфокусировалась на наращивании функциональности системы, неосознанно принося в жертву вопросы качества данных. Результатом такого поверхностного отношения стало недоверие к данным, регулярные перепроверки бухгалтерией тех цифр, которые выдает система, «пожарные» корректировки данных уже на уровне отчетных форм, исправление данных прямо на уровне базы (так называемые дата фиксы). Всё это происходило буквально «на флажке» отчетной даты.
Само собой, таким положением дел бизнес был крайне недоволен, ведь каждый отчетный период сопровождался нервотрепкой, а над головой, как Дамоклов меч, нависала угроза санкций со стороны ЦБ за несвоевременно сданную или сданную с ошибками форму. Ситуацию надо было исправлять, причем на этот раз системно.
После нескольких тяжелых встреч мы пришли к тому, что для решения задачи нам нужно сфокусироваться и ответить на три важных вопроса:
Для решения первой задачи мы посмотрели международный опыт и выяснили, что лучшие практики рекомендуют делать это не на стороне IT-подразделения, а на стороне бизнес-владельца сервиса. Мы последовали этим рекомендациям и начали реализовывать подход, где IT-служба отвечает за своевременную актуализацию данных, а бизнес-подразделение — за процессы контроля качества.
С этой идеей мы пошли в бухгалтерию, но, как несложно догадаться, встретили непонимание и несогласие по поводу создания этой функции на их стороне.
Тогда мы попытались найти такого владельца в подразделении, которое отвечает за данные в месте их «рождения», а именно в автоматизированных банковских системах (АБС). Построение данного контроля на стороне отчетной системы автоматически помогало коллегам повысить управляемость данными на самом источнике, и поэтому нам удалось быстро договориться. По сути мы не добавили им лишней работы, а трансформировали их текущий процесс, частично автоматизировав те проверки, которые и так делались вручную.
Разобравшись с первым вопросом, мы приступили к решению второго и третьего.
Здесь важно было договориться, что вообще считать контролем и как эти контроли классифицировать. Контроль мы решили определить как критерий, который позволяет однозначно идентифицировать ошибочные записи. Он сформулирован в бизнес-терминах — тех же, которые применяются в слое детальных данных. Например, контроль может быть сформулирован как «количество договоров с датой выдачи больше текущей». На данный момент мы придумали 34 контроля такого рода и поделили их на три группы:
Технологически это реализовано относительно просто. В ETL поток (workflow) встроена сессия, которая после расчета основной порции бизнес-данных запускает алгоритмы контроля качества. Они отрабатывают базы данных хранилища и «складывают» информацию в табличку.
Для пользователей мы разработали интерфейс в нашем корпоративном Business Intelligence инструменте, который позволяет запрашивать информацию о контроле качества данных с уровня БД, показывать её в различных уровнях детализации и за различные отчетные периоды.
На стороне владельца был выстроен процесс ежедневной обработки данного отчета. Сотрудник открывает отчет, получает набор расхождений и проводит первичную диагностику, чтобы выделить из всего набора ошибок те, которые относятся к первой группе. Ошибки бизнес-процесса (первая группа) в основной своей массе могут быть исправлены на стороне владельца без обращения в смежные подразделения. Например, исправление некорректной проводки. Такая первичная диагностика позволяет сократить количество шагов, которое должен пройти потенциальный инцидент, прежде чем он будет исправлен.
Если ошибку не удалось классифицировать как ошибку первой группы, то он передается в IT-службу, где по стандартной воронке Helpdesk переводится на исполнительную группу, отвечающую за работу системы обязательной отчетности. Данная группа действует по классической схеме, проводя анализ ошибки от потребителя к источнику данных. В данном случае специалисты сначала пытаются разобраться с алгоритмами, которые формируют ядро системы обязательной отчетности (на котором и выстроены наши бизнес-проверки), а затем двигаются «вглубь» к источнику бизнес-данных (АБС).
А как же быть, если весь поток ошибок в данных не может быть обработан командой одномоментно? Мы договорились о подходе к приоритизации. Обязательная отчетность по каждой форме должна быть сдана на первый день месяца. Поэтому приоритет инцидента меняется в зависимости от близости дня сдачи той или иной формы отчетности. Все инциденты на данные, заведенные за 5 дней до последнего дня месяца имеют по умолчанию приоритет Critical, так как ошибки в данных за 5 дней до отчетной даты требуют немедленного анализа и устранения. Впоследствии при анализе инцидента и по согласованию с ответственным со стороны подразделения Operations приоритет может быть понижен. В остальные дни месяца инциденты заводятся с приоритетом Medium.
При создании системы контроля качества данных нас поддерживал один из вице-президентов банка. Процессы устранения ошибок в данных затрагивают сразу несколько совершенно разных подразделений банка, так что участие человека со стороны Leadership Team нам очень помогло.
Теперь с помощью наших контролей подразделение Operations анализирует данные обязательной отчетности, и по итогам мы получаем от него ежедневную рассылку. В ней перечислены актуальные проблемы в данных и всплески ошибок, которые требуют немедленного реагирования. Все проверки мы классифицируем на уровне бизнес-сущностей в которых содержатся ошибки: договор, счет, клиент, остаток.
Благодаря такому подходу бухгалтерия всегда может оценить качество данных обязательной отчетности, за сдачу которых она ответственна. Подразделение Operations стало активнее участвовать в решении инцидентов, так как лучше понимает свою ответственность за качество данных. Изменились внутренние установки задействованных сотрудников. Мысли «Ну я же завел инцидент, пусть IT его решает» сменились другими: «У нас есть столько-то ошибок, приоритет их исправлений такой-то, ожидаем их исправление к такому-то числу». Все почувствовали себя «в одной лодке».
Перемены радикально отразились на общем количестве ошибок. Оно снизилось на несколько порядков. На текущий момент общее количество ошибок в контролях качества не превышает 30 тысяч записей, причем все они не являются критичными для процесса сдачи отчетности (например, отсутствие ОКАТО у клиента является ошибкой данных, но на отчетность ЦБ влияния не оказывает). На момент старта у нас было около 20 контролей с суммарным количеством ошибок в районе шести миллионов записей.
С нового года мы хотим научиться на ежедневной основе создавать резервы, которые у нас считает система обязательной отчетности. Это значит, что вместо валидных данных по состоянию на первое число каждого месяца нам будут необходимы такие данные каждый день. Конечно же, это отразится и на процессах контроля качества данных.
Также у нас есть планы по выстраиванию системы межформенного контроля. Сейчас мы сверяем большинство форм с формой 101, но хотим делать еще и более сложные сверки (например, в части разбивки по ОКАТО сверять новую форму 120 с формой 302).
Буду рад ответить на ваши вопросы в комментариях. Если тема интересна, могу описать, как мы выстраиваем аналогичные процессы в нашем втором хранилище, для аналитической отчетности.
В качестве вступления — немного о нашей инфраструктуре и об аналитических системах в нашей работе.
В инфраструктуре Ренессанса аналитические системы служат источником информации для collection-систем и систем противодействия мошенничеству. Наше Data Warehouse (DWH) – это не просто корпоративное хранилище в классическом понимании этого термина, необходимое для аналитики и отчетности. Это система, способная трансформировать и отдавать данные в другие бизнес-системы для поддержания бизнес-процессов, не связанных с аналитикой.
Если говорить о нашем технологическом стеке, то в основном мы используем Enterprise-решения. Наши хранилища (оперативное, аналитическое и обязательной отчетности) работают на БД Oracle, ETL процессы реализованы при помощи ПО Informatica Powercenter, а в качестве Business Intelligence инструмента мы используем продукт Cognos от IBM. Для репликации данных в оперативное хранилище мы также применяем продукт от Oracle – это GoldenGate. Потребности пользовательской аналитики закрываются продуктами от SAS – Miner и Enterprise Guide.
При этом мы находимся в постоянном поиске бесплатных или условно-бесплатных альтернатив решениям больших вендоров и для задач, не чувствительных к SLA, стараемся точечно пилотировать такие решения.
Что было сначала
Краеугольная характеристика данных при работе с ними — это не количество, а качество. Если данным невозможно довериться, то технологические инвестиции и развитие экспертизы не принесут никакого результата. Проблема здесь в том, что на основе некачественных данных могут приниматься неправильные управленческие решения, что приводит к печальным последствиям для бизнеса. Именно это будет учитывать твой потенциальный внутренний заказчик в первую очередь. Он будет задавать себе один вопрос: «Могу ли я доверять этому источнику информации?».
Итак, давайте разберемся, как устроено хранилище обязательной отчетности. Оно состоит из трех слоев (к слову, достаточно типичных):
- Слой сырых данных — это наборы данных, загруженных из систем-источников (АБС, GL, клиентский MDM) без какой-либо трансформации.
- Слой детальных данных — здесь информация из систем-источников трансформируется в нашу бизнес-модель (счет, клиент, договор и т.д.).
- Слой витрин — здесь информация со слоя детальных данных трансформируется в отдельные витрины, каждая под свою форму обязательной отчетности.
Проект внедрения системы обязательной отчетности стартовал в банке в 2013 году с одной задачи расчета обязательных резервов на портфели однородных ссуд. После успешной и относительно быстрой реализации этой задачи стало понятно, что у системы есть будущее и её использование можно масштабировать на процессы сдачи отчетных форм ЦБ и для отчетности другим регуляторам (например, ФНС).
Совместная команда IT и бизнеса сфокусировалась на наращивании функциональности системы, неосознанно принося в жертву вопросы качества данных. Результатом такого поверхностного отношения стало недоверие к данным, регулярные перепроверки бухгалтерией тех цифр, которые выдает система, «пожарные» корректировки данных уже на уровне отчетных форм, исправление данных прямо на уровне базы (так называемые дата фиксы). Всё это происходило буквально «на флажке» отчетной даты.
Само собой, таким положением дел бизнес был крайне недоволен, ведь каждый отчетный период сопровождался нервотрепкой, а над головой, как Дамоклов меч, нависала угроза санкций со стороны ЦБ за несвоевременно сданную или сданную с ошибками форму. Ситуацию надо было исправлять, причем на этот раз системно.
Что сделали
После нескольких тяжелых встреч мы пришли к тому, что для решения задачи нам нужно сфокусироваться и ответить на три важных вопроса:
- Кто должен отвечать за качество данных?
- С помощью какого инструмента это должно происходить?
- Как должен работать процесс обнаружения и исправления найденных ошибок?
Для решения первой задачи мы посмотрели международный опыт и выяснили, что лучшие практики рекомендуют делать это не на стороне IT-подразделения, а на стороне бизнес-владельца сервиса. Мы последовали этим рекомендациям и начали реализовывать подход, где IT-служба отвечает за своевременную актуализацию данных, а бизнес-подразделение — за процессы контроля качества.
С этой идеей мы пошли в бухгалтерию, но, как несложно догадаться, встретили непонимание и несогласие по поводу создания этой функции на их стороне.
Тогда мы попытались найти такого владельца в подразделении, которое отвечает за данные в месте их «рождения», а именно в автоматизированных банковских системах (АБС). Построение данного контроля на стороне отчетной системы автоматически помогало коллегам повысить управляемость данными на самом источнике, и поэтому нам удалось быстро договориться. По сути мы не добавили им лишней работы, а трансформировали их текущий процесс, частично автоматизировав те проверки, которые и так делались вручную.
Разобравшись с первым вопросом, мы приступили к решению второго и третьего.
Здесь важно было договориться, что вообще считать контролем и как эти контроли классифицировать. Контроль мы решили определить как критерий, который позволяет однозначно идентифицировать ошибочные записи. Он сформулирован в бизнес-терминах — тех же, которые применяются в слое детальных данных. Например, контроль может быть сформулирован как «количество договоров с датой выдачи больше текущей». На данный момент мы придумали 34 контроля такого рода и поделили их на три группы:
- Ошибки бизнес-процесса. Например, сотрудник сделал какую-то ручную некорректную операцию вразрез с установленным процессом, и эта корректировка привела к расхождениям.
- Ошибки выгрузки-загрузки. Например, на уровне данных в системе-источнике было все хорошо, но в результате трансформации и загрузки данных произошел сбой.
- Ошибки системы обязательной отчетности. Например, все выгрузилось и загрузилось хорошо, но в отчетной форме есть логическая ошибка и она требует исправления.
Технологически это реализовано относительно просто. В ETL поток (workflow) встроена сессия, которая после расчета основной порции бизнес-данных запускает алгоритмы контроля качества. Они отрабатывают базы данных хранилища и «складывают» информацию в табличку.
Для пользователей мы разработали интерфейс в нашем корпоративном Business Intelligence инструменте, который позволяет запрашивать информацию о контроле качества данных с уровня БД, показывать её в различных уровнях детализации и за различные отчетные периоды.
На стороне владельца был выстроен процесс ежедневной обработки данного отчета. Сотрудник открывает отчет, получает набор расхождений и проводит первичную диагностику, чтобы выделить из всего набора ошибок те, которые относятся к первой группе. Ошибки бизнес-процесса (первая группа) в основной своей массе могут быть исправлены на стороне владельца без обращения в смежные подразделения. Например, исправление некорректной проводки. Такая первичная диагностика позволяет сократить количество шагов, которое должен пройти потенциальный инцидент, прежде чем он будет исправлен.
Если ошибку не удалось классифицировать как ошибку первой группы, то он передается в IT-службу, где по стандартной воронке Helpdesk переводится на исполнительную группу, отвечающую за работу системы обязательной отчетности. Данная группа действует по классической схеме, проводя анализ ошибки от потребителя к источнику данных. В данном случае специалисты сначала пытаются разобраться с алгоритмами, которые формируют ядро системы обязательной отчетности (на котором и выстроены наши бизнес-проверки), а затем двигаются «вглубь» к источнику бизнес-данных (АБС).
А как же быть, если весь поток ошибок в данных не может быть обработан командой одномоментно? Мы договорились о подходе к приоритизации. Обязательная отчетность по каждой форме должна быть сдана на первый день месяца. Поэтому приоритет инцидента меняется в зависимости от близости дня сдачи той или иной формы отчетности. Все инциденты на данные, заведенные за 5 дней до последнего дня месяца имеют по умолчанию приоритет Critical, так как ошибки в данных за 5 дней до отчетной даты требуют немедленного анализа и устранения. Впоследствии при анализе инцидента и по согласованию с ответственным со стороны подразделения Operations приоритет может быть понижен. В остальные дни месяца инциденты заводятся с приоритетом Medium.
При создании системы контроля качества данных нас поддерживал один из вице-президентов банка. Процессы устранения ошибок в данных затрагивают сразу несколько совершенно разных подразделений банка, так что участие человека со стороны Leadership Team нам очень помогло.
Что получили
Теперь с помощью наших контролей подразделение Operations анализирует данные обязательной отчетности, и по итогам мы получаем от него ежедневную рассылку. В ней перечислены актуальные проблемы в данных и всплески ошибок, которые требуют немедленного реагирования. Все проверки мы классифицируем на уровне бизнес-сущностей в которых содержатся ошибки: договор, счет, клиент, остаток.
Благодаря такому подходу бухгалтерия всегда может оценить качество данных обязательной отчетности, за сдачу которых она ответственна. Подразделение Operations стало активнее участвовать в решении инцидентов, так как лучше понимает свою ответственность за качество данных. Изменились внутренние установки задействованных сотрудников. Мысли «Ну я же завел инцидент, пусть IT его решает» сменились другими: «У нас есть столько-то ошибок, приоритет их исправлений такой-то, ожидаем их исправление к такому-то числу». Все почувствовали себя «в одной лодке».
Перемены радикально отразились на общем количестве ошибок. Оно снизилось на несколько порядков. На текущий момент общее количество ошибок в контролях качества не превышает 30 тысяч записей, причем все они не являются критичными для процесса сдачи отчетности (например, отсутствие ОКАТО у клиента является ошибкой данных, но на отчетность ЦБ влияния не оказывает). На момент старта у нас было около 20 контролей с суммарным количеством ошибок в районе шести миллионов записей.
Что планируем
С нового года мы хотим научиться на ежедневной основе создавать резервы, которые у нас считает система обязательной отчетности. Это значит, что вместо валидных данных по состоянию на первое число каждого месяца нам будут необходимы такие данные каждый день. Конечно же, это отразится и на процессах контроля качества данных.
Также у нас есть планы по выстраиванию системы межформенного контроля. Сейчас мы сверяем большинство форм с формой 101, но хотим делать еще и более сложные сверки (например, в части разбивки по ОКАТО сверять новую форму 120 с формой 302).
Буду рад ответить на ваши вопросы в комментариях. Если тема интересна, могу описать, как мы выстраиваем аналогичные процессы в нашем втором хранилище, для аналитической отчетности.
Комментарии (7)
VolCh
24.01.2018 09:37А в целом предпринимались шаги по уменьшению количества ошибок на этапе их создания? Ну, то есть не искать постфактум где пользователь, что-то не то ввёл вручную, а исправлять интерфейсы, чтобы у него не было возможности ввести что-то не то?
И почему принято решение получать отчёт об ошибках по запросу, а не формировать автоматически, например, по расписанию?
DaniIlMak Автор
24.01.2018 10:39Работа с любым новым контролем у нас проводится в два логических этапа:
- Фиксирование количества расхождений. Мы, получив определенное (обычно немного пугающее) количество ошибок после первого запуска контроля, начинаем внимательно следить за их динамикой. То есть, если вчера было 10 000 ошибок а сегодня 10 100, то мы отдельно выделим эти 100 записей и будем разбираться, какой бизнес-процесс порождает "кривые" данные и, соответственно, делать необходимые корректировки данного процесса.
- Разбор и исправление уже зафиксированного количества расхождений. Здесь мы активно анализируем данные в хранилище и делаем точечные исправления именно на уровне данных, а не процессов.
Как я и писал в статье, отчет здесь является исключительно средством визуализации того, что в плоскую и простую по структуре таблицу сложили встроенные в ETL контроли. Так как это достаточно "легкий" отчет, который не создает хоть сколь-нибудь значимой нагрузки на базу, и может быть запущен на любую (доступную в хранилище) дату в прошлом, то ставить данный отчет на регламент просто нет необходимости.
WTYPMAH
24.01.2018 09:52В моей практике только на данные под расчет резерва настроено около 80 контролей минимум :)
DaniIlMak Автор
24.01.2018 10:54Честно говоря, 80 контролей кажутся избыточными. Для корректного расчета резервов необходимо, чтобы:
- В системе отчетности были корректные остатки по счетам — решается сверкой с GL
- Не было счетов без связи с договором — решается одной логической проверкой на уровне данных
- Корректные атрибуты договора, на основе которых происходит отнесение к определенному портфелю (продукт, количество дней просрочки и т.д.) — тут контролей может быть больше, но не могу представить, что их нужно больше 5-10.
Кроме того, критерием достаточного или не достаточного количества проверок служит объем необходимых ручных корректировок при резервировании. На текущий момент мы такие корректировки не делаем.
sshmakov
Как-то круто использовать GoldenGate для отчетности. Нет, конечно, здорово, репликация сырых данных без задержек мастер-базы, в онлайне, все такое «если диктор нам не врет», но, ё-моё, какое же оно дорогое.
Разве? Может быть все-таки в определенный день месяца? Например, упомянутая в статье 302-я по 4212-У сдается в 10-й рабочий день месяца, следующего за отчетным.
DaniIlMak Автор
Спасибо за найденную опечатку. Конечно же имеется в виду «на первый день месяца». Поправил в статье.
GoldenGate нам действительно закрыл множество вопросов, связанных именно с операционной отчетностью и снижением нагрузки всякими выгрузками бэковых систем.
vialz
Отчетность отчетности рознь, как вы понимаете. Если отрываться от форм отчетности ЦБ (где ETL-средств как правило хватает) и говорить о различных видах мониторинга операций, то там без CDC никуда. Ну и BI часто предъявляет такой SLA, что также CDC является здравым решением.