Как не пустить в хранилище данных некачественные данные

Технологии
243801
0
Сергей Цевин, директор центра развития бизнес-приложений департамента аналитических систем, R-Style Softlab
Знаете ли вы, что, вопреки распространенному в банковской среде мнению, само по себе внедрение хранилища данных не в состоянии сделать данные банка качественными? Зато оно совершенно точно поможет вам выявить ошибки в данных, поступающих из учетных систем. Как? С помощью встроенной системы контроля качества данных.


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

Ошибки в данных, и откуда они берутся


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

1. Ошибки, связанные с человеческим фактором.
2. Недочеты автоматизации и архитектурные ошибки.
3. Ошибки в бизнес-процессах.

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

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

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

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

Хотите найти ошибки в данных? Установите хранилище данных!


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

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

Знакомьтесь — «RSDH: СККД»!


Пришла пора представить нашу систему контроля качества данных — технологический модуль «RSDH: СККД». Он реализован на платформе RS-DataHouse, поставляется вместе с ней и обладает следующими характеристиками:
  • имеет набор дистрибутивных проверок качества данных;
  • позволяет добавлять или менять проверки качества данных;
  • имеет общий для платформы интерфейс;
  • полностью интегрирован с модулем рассылки сообщений по электронной почте (модуль рассылки так же является частью платформы RS-DataHouse).
К необходимости создания этого инструмента мы пришли не сразу. Изначально был выбран путь, которым следует большинство разработчиков, — просто реализовывали на каждом из проектов необходимые проверки. Но затем пришло понимание, что, во-первых, проверки чаще всего бывают почти одинаковыми (с минимальными различиями), а во-вторых, нам приходится каждый раз делать одну и ту же работу. Появилось желание упростить себе жизнь, а заодно и снизить затраты как на внедрение, так и на сопровождение наших решений.

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

Как избавиться от ошибок?


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

Универсального рецепта, как сделать данные в учетных системах качественными, нет и быть не может. Тем не менее, мы подготовили некоторые общие рекомендации и советы и готовы ими поделиться. Итак, чтобы проблем с качеством данных не возникало, нужно:
  • настроить процедуры проверки данных в учетных системах. Исправление ошибок что называется «на месте», будет выполняться более оперативно, чем после их обнаружения в хранилище;
  • доработать учетные системы для предотвращения появления ошибок, вызванных невнимательностью пользователей;
  • устранить в интеграционных процессах те места, где возможно редактирование данных, передаваемых между учетными системами, которое приводит к ошибкам в хранилище данных;
  • оптимизировать бизнес-процессы, которые служат источником ошибок (зачастую появление ошибок здесь может быть обусловлено принципом «так исторически сложилось» или неэффективным взаимодействием между подразделениями);
  • если систем-источников данных для хранилища несколько, то имеет смысл в группе сопровождения выделить одного или нескольких специалистов, задачами которых будет именно анализ выявленных в хранилище ошибок и взаимодействие с бизнес-подразделениями с целью их устранения;
  • доработать технологические карты/инструкции по работе с учетными системами;
  • порой может оказаться эффективным ввод KPI для руководителей бизнес-подразделений на количество ошибок, зафиксированное в хранилище.
Иногда с какими-то ошибками приходится мириться, принимая их как данность. Но это ни в коем случае не должно относиться к данным, которые влияют на отчеты, критичные к точности показателей (например, на отчетность для регулятора). Иначе вся польза от внедрения хранилища данных будет обесценена.

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

Комментарии



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