Публикации

Intersoft Lab в СМИ - истории успеха клиентов, интервью и мнения экспертов компании, обзоры рынка CPM

Кто в банке должен отвечать за качество отчетных данных?

Эксклюзивно для портала ИТ-директоров Global CIO Юлия Амириди, заместитель генерального директора Intersoft Lab, рассказала, как решить проблему качества данных для подготовки банковской отчетности, и привела в качестве примера опыт Банка «Санкт-Петербург».

С цифровых небес на землю

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

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

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

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

Исследование другой консалтинговой компании (Ernest & Young) говорит о том, что качество данных является серьезной проблемой для получения качественной аналитики, особенно в банковском секторе (так считают 37% опрошенных представителей банков, в других отраслях - 31%).

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

В этой связи невольно возникают два традиционных вопроса: кто виноват и что делать? Их и хотелось бы обсудить в данной статье.

Кто виноват?

Чтобы избежать соблазна найти «крайнего» и постараться объективно ответить на поставленный вопрос, стоит заранее договориться о том, что понимается под качеством данных и что является источником проблем с КД.

Вначале очертим рамки решаемой задачи - в соответствии с стандартами серии ISO/TS 8000, ГОСТ Р 56214–2014/ISO/TS 8000-1:2011, понятие качества данных затрагивает только те данные, которые участвуют в принятии какого-либо управленческого решения. Поэтому применительно к подготовке банковской отчетности, мы будем говорить о КД как о характеристике доступности, полноты, безошибочности и согласованности данных, на основе которых строятся отчеты.

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

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

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

Что делать?

В мировой практике ответ на данный вопрос хорошо известен: рекомендуется сформировать отдельную должность Chief Data Officer - «директора по данным», нанять такого менеджера и с его помощью наводить порядок с данными.

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

Поэтому неудивительно, что нередко эта задача оказывается «ничьей». Ответственность за нее прогнозируемо пытаются возложить на ИТ. ИТ-служба в свою очередь пытается перенести ее на бизнес-подразделения, справедливо полагая, что конечные пользователи в значительной части случаев сами являются источником проблем с данными. Возникает замкнутый круг.

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

Например, в составе хранилища «Контур» компании Intersoft Lab поставляются готовые модули контроля и обогащения данных, а также оценки КД. Первый из них дает возможность проверять готовность данных из учетных систем к прикладной обработке и выпуску отчетов; модуль контроля данных содержит несколько сотен видов проверок безошибочности, корректности и целостности данных, а модуль обогащения автоматически дополняет исходные данные необходимой аналитикой.  Модуль оценки КД позволяет анализировать динамику состояния данных, оценивать затраты на обеспечение КД в человекочасах и в денежном выражении.

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

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

Одним словом, неважно как станут именовать ответственных за КД -  Chief Data Officer на западный манер или более привычно для нашего слуха - Служба качества данных, очевидно, что работа у этих сотрудников и подразделений никогда не иссякнет. Эти уникальные специалисты, соединяющие одновременно компетенции менеджеров, технологов и ИТ-инженеров, постепенно должны стать неотъемлемой составляющей цифрового банка. 

 

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

Автор: Юлия Амириди, заместитель генерального директора по развитию бизнеса компании Intersoft Lab

Источник: Global CIO, рубрика "Дискуссии"