Раз вы добрались до этой главы, тяга к новым знаниям дарована вам природой или же воспитана в суровых сибирских условиях.
Тема качества данных лично меня коснулась не сразу. Работая в команде вышколенных аудиторов – выпускников лучших ВУЗов страны, мы привыкли опираться на свое мнение: делать выводы на основании данных, документировать и предоставлять описание своих ключевых суждений, которые ложились в основу аудиторского заключения.
Вот ты приходишь в банк, и тебе дают на руки выгрузку из проводок оборотно-сальдовой ведомости – это такая большая табличка с остатками и оборотами, где находится все на свете. И обычно аудиторы сбивают сначала оборот и остаток по оборотно-сальдовой ведомости с тем, что есть на счетах в отчетности, которую банки публикуют и отправляют в Центральный банк Российской Федерации.
Итак, вот мне сгружают тонну данных – это примерно несколько миллионов записей. В то время Excel еще не умел работать с такими количествами, это уже после он смог анализировать четыре миллиона записей. Приходилось разбирать этот большой объем данных на части.
Каждому аудитору доверяли какую-то конкретную секцию. Если смотреть на финансовую отчетность, то секция – это один ее раздел. Надеюсь, вам удавалось хоть раз на нее взглянуть. Если нет, взгляните для примера на публикуемую отчетность по МСФО любой российской компании или банка, например ВТБ, она, кстати, отличается от остальных тем, что ее составляют в миллиардах рублей. ВТБ был одним из первых банков, которые перешли на выпуск отчетности в миллиардах рублей. Сегодня не так много компаний могут этим похвастаться.
Что это значит в практическом плане? В первую очередь это, конечно же, размер потенциальной ошибки. Раньше у аудиторов была проблема с одной частой ошибкой при подготовке отчетности – с округлением.
Вот представьте, что вы округляете цифры для отчетности так, чтобы это соответствовало принятому размеру внутри самой отчетности – миллиарды, миллионы, тысячи и так далее. Раньше, когда появлялась та самая «единица», которая возникала из-за округления значений строк, аудиторы обычно пристраивали ее в какую-то из строчек так, чтобы общая сумма сходилась. Потому что иначе при сложении сумма расходилась с той суммой, которая была посчитана на более маленьких значениях.
Да и какая разница, в какой строчке баланса будет больше на одну единицу, а в какой меньше. А если дело касается миллиардов? У вас из-за округления появится плавающий миллиард…
Насколько сильно это повлияет на качество конечных данных? Насколько сильно это повлияет на принимаемые решения?
В таком случае аудитор всегда обязан определить ту разницу, которая может и не может одновременно влиять на принимаемые решения на основании выводов из финансовой отчетности. Вы спросите меня как?
Очень просто, есть такое понятие как «материальность» или по-нашему – существенность. Это означает размер потенциального искажения информации, которая может ввести пользователя в заблуждение, из-за которого он сделает неверные выводы, а то и неверные действия на основании некорректных данных.
Насколько материален миллиард? Вот вы смотрите на отчетность, возможно, вы ничего в этом не понимаете, но вам важно, что тут «плавает» миллиард между строк?
А теперь давайте спустимся на уровень ниже, так как это все вершина пирамиды. На самом нижнем уровне данные собираются из разных источников и могут искажаться гораздо существеннее чем на один миллиард рублей.
Но стоп…
Вы меня спросите, как такое возможно, если отчетность не сходится всего на один миллиард рублей? Следите за руками. Когда аудитор делает проверку, он должен гарантировать, что цифры не искажены во всех материальных аспектах. Материальность можно определить по-разному. Например, взять один процент от размера полученной прибыли до налогов или полпроцента от размера активов, которыми владеет организация и так далее. В общем, подходов много. Но суть в том, что, определяя этот самый размер «существенной» чувствительности к принимаемым решениям, организация отсекает ниже этого уровня все суммы, которые отныне считаются неважными. Таким образом аудитор проверяет отчетность во всех материальных аспектах и гарантирует при этом достаточный уровень уверенности в положительном исходе. Если спросить меня, что такое «достаточный» уровень, и чем он отличается от «абсолютного», то я отвечу – всем. Это не одно и то же.
Иными словами, аудитор не может проверить все цифры и все данные в организации. Все, стоп. Зачем я это описываю?
На самом деле, я так попытался пояснить, что такое искажения данных и подготовить вас к сложной части. Но теперь давайте прыгнем в эту темную пучину и попробуем разобраться. Хочу, чтобы вы понимали, что любая ошибка в данных – это финансовый эффект, независимо от того, сделана она на верхнем уровне подготовки самой отчетности, или же эта проблема была в первичных данных.
Итак, двигаемся дальше.
У меня есть брат. Мы близнецы. И, наверное, как стало понятно, мы однофамильцы. Так случилось, что мы имели счет в одном и том же банке. Не буду говорить в каком, этому бренду и так досталось, но особо пытливые поймут.
В один прекрасный день в этом самом банке меня внезапно «склеили» с другим клиентом так, что, открыв приложение этого мобильного банка, я увидел остатки на счетах другого человека, и у меня даже была возможность управлять этими счетами. Хорошо, что это были средства моего брата.
Но погодите-ка. Причем тут он? Вот и мне это интересно. Но система в банках внезапно заменила все мои данные на его. Даже при звонке в контакт-центр с моего телефона у них отражался другой человек, совсем не Алексей. Опустим, сколько проблем пришлось решить, чтобы я снова мог видеть свои счета и пользоваться банковскими сервисами.
Такая проблема бывает не только у меня, и она никак не связана с тем, есть ли у вас брат-близнец. Она даже может быть не связана с конкретным банком. Оказывается, это ошибка в данных, которая вызывает коллизии во внутренних IT-сервисах, делая недоступным для конечного потребителя стандартный набор функций, на которые он рассчитывал.
Тема качества клиентских данных всегда особо актуальна. Однажды у меня была проблема с одним из клиентов, который по одной из систем имел категорию «хороший клиент», а по другой – был «террористом». «Террорист» означает, что система нашла совпадение с одним человеком из списков, которые публиковал Центральный банк. Не все участники этого списка обязательно террористы в буквальном смысле, они вполне могли просто нарушить какой-то закон и попасть туда. Какое-то время назад, как мне рассказывали, в такие списки попадали люди, нарушившие законы, запрещающие участие в пикете или демонстрации.
Что банк должен делать в случае, если один из его клиентов попал в такой список? Правильный ответ: в соответствии с действующим законом он должен приостановить банковское обслуживание и закрыть банковский счет. Кстати, именно эту отговорку часто используют банки, если им нужно закрыть счет и особо не навлекать на себя сложности и тяжелые разбирательства.
А что же должен был делать я? Закрывать счет или нет?
Как бы вы поступили?
Разбирая проблемы в клиентских данных, можно отметить известный случай 2015 года, когда Федеральная налоговая служба ввела для всех налоговых агентов новое обязательное поле к заполнению при подаче справки 2-НДФЛ. Этим полем стало поле «ИНН», которое каждый налоговый агент обязан был заполнять во избежание штрафа.
Причем тут банк? Все просто. Вот я взял кредит в банке и больше не могу по нему платить. Что делает банк? Помимо того, что он насылает на меня своих демонов-коллекторов и бегает с требованиями погасить задолженность, после определенного периода он вынужден будет эту задолженность списать.
Но самое интересно будет дальше. С точки зрения буквы закона и учета, списание задолженности означает, что эти кредитные деньги я признаю себе как доход, а значит, я должен с них заплатить налог. Но если денег у меня нет, то, естественно, налог платить должен банк.
Маленький дурдом получается. Мало того, что банк терпит фиаско с клиентом, так он еще и вынужден заплатить 13 % с этой сделки в бюджет. C’est la vie. Не будем разбираться в справедливости сего факта, попробуем разобраться в следующем. Вот банк должен уплатить налог, а значит, подать еще и справку 2-НДФЛ в ФНС, а в этой справке теперь стоит обязательное поле «ИНН».
Но вот незадача, при выдаче кредита, банк не узнал эту информацию у клиента, потому что она не являлась обязательной. Существует много различных случаев получения такого дохода.
Доход по депозиту тоже можно признать таким же доходом, по которому обязаны подать справку 2-НДФЛ, если ставка, по которому он начисляется, в определенное количество раз больше, чем ставка рефинансирования, то в этом случае банк должен отчитаться также в ФНС. Получается, что если вы видите высокую ставку по депозиту и думаете туда положить денежку, то знайте – это сверхдоход, по нему нужно удержать налог. Удерживание налога – это обязанность налогового агента, то есть банка. Но разве кто-нибудь спрашивает у вас поле «ИНН» в момент, когда на каком-нибудь банковском сайте вы размещаете свою заявку на депозит?
Конечно, нет. Такое поле по-прежнему не является обязательным при открытии договора депозита или вклада в том или ином банке.
В 2015 году ФНС грозился, что штраф за незаполненное поле «ИНН» с каждой такой записи составит двести рублей, а с 2016 года вырастет до пятисот. Представьте, что я банк. И если у меня сто тысяч клиентов, по которым я списал задолженность, или по которым начисляют зарплату с моих банковских карт, то, умножив сто тысяч на двести рублей, я получу ежегодный штраф в размере двадцати миллионов рублей.
Оценка грубая, но, тем не менее, думаю, смысл стал понятен. С какого-то момента плохое качество данных организации, с которым она работает, начало создать проблемы и новые штрафы для самой организации. Иными словами, плохие данные стали «токсичным» активом, приносящим организации новые убытки в будущем.
Сколько таких «важных» полей существует внутри IT-систем большой организации? Отвечу досрочно – десятки тысяч как минимум. Десятки тысяч таких полей, десятки тысяч гигантских табличек, которые нужно проверять и контролировать.
Ошибки могут быть разными. Иногда важно, чтобы указанные данные существовали в реальности, как в случае с полем «адрес», чтобы банк смог доставить корреспонденцию своем клиенту. Многие вбивают в это поле все, что вздумается, но хорошо, что есть такие отличные сервисы как DaData, которые не позволяют вбить несуществующий адрес. Об этом впереди.
Наверняка, заполняя какую-нибудь формочку на сайте, вы сталкивались с его просьбой указать «индекс». А потом вы нервно начинали гуглить индекс указанного адреса.
Но фишка в том, что «индекс» как поле можно и не запоминать, это атавизм. Из утвержденных публичных справочников типа ФИАС или КЛАДР, в правильном существующем адресе уже есть индекс, и его можно взять оттуда.
Это ведь просто прекрасно – не заполнять поле «индекс». Так почему же его до сих пор заполняют и спрашивают?
Оказалось, что в базе ФИАС (государственный источник) поле «индекс» заполнено не совсем корректными почтовыми индексами. Нужно искать еще и другие правильные источники, например, базу данных «Почты России», но даже в этой базе нет всех тех индексов, которые есть в ФИАС.
Чтобы в этом всем копаться, нужно все это любить и получать удовольствие от разгребания подобных проблем. Большинство людей, ежедневно сталкивающихся с теми или иными цифровыми сервисами, не знают о том, какой объем работы проводится для упорядочивания данных перед тем, как показать их клиенту.
Ошибки, опечатки и погрешности влияют на многие факторы в организации. Однажды, объединяя клиентов одного банка с другим, в процессе консолидации мы внезапно выявили, что несколько тысяч мужчин внезапно изменили пол и стали женщинами. Конечно, у нас демократичная страна, но сей инцидент произошел в суровых сибирских районах, поэтому я по-прежнему склонен думать о наличии очередной ошибки в данных.
Как быть? Как исправить ошибки, которые уже случились? Я ведь не могу пойти на «Горбушку» и купить компакт-диск с данными.
Для обогащения данных клиентов и заполнения поля «ИНН», мы пробовали различные методы. Звонили и спрашивали, просили прийти в офис и заполнить анкету, делали даже такую доработку в мобильном приложении или интернет-банке.
Эффект на общем потоке составил какой-то мизерный процент, то есть люди не шли и не давали свои данные. Пришлось менять банковские процессы и делать поле «ИНН» обязательным для всех продуктов. Такая вот головная боль из-за одного поля, а таких полей, повторюсь, очень много.
Кстати, если вдруг вы торгуете ценными бумагами, мало ли меня читают такие умные люди, то, наверное, обратили внимание, что в личном кабинете брокера, через который вы торгуете, появилось обязательное требование заполнить поле «ИНН». Совпадение? Не думаю.
Основные методы управления качеством данных
Качеством и проблемами в данных должны управлять специальные люди в организации.
Да ладно вам, согласитесь, что это уже очевидно. Будет странно, если я начну распинаться и объяснять слишком очевидные вещи.
Лучше я объясню, где и как организовать работу таких людей.
Для начала нужно все разбить на две части.
Первая часть – это так называемая служба поддержки пользователей, которая приходит на помощь, если что-то случилось с их данными. По-умному эта команда называется дата-стюарды. Да, именно так и называются – дата-стюарды. Русского перевода нет. Пусть будет это новое английское слово в нашем лексиконе. Привыкайте, дальше будет веселее.
Задача дата-стюардов проста и понятна – разобраться оперативно в каше под названием данные так, чтобы ни один клиент не пострадал, или чтобы вовремя выпустилась отчетность. Ну, кажется, понятно объяснил. Если нет, то, скорее всего, во время чтения этой книги вы слышали какие-то посторонние звуки или встретили другие препятствия, – настоятельно рекомендую избавиться от них. Главное, не говорите потом, мол, Алексей, ты пишешь «непонятно». Даже не думайте. Я ведь очень стараюсь.
Дата-стюарды работают по понятной и прозрачной методике: на них сыплется поток плохих данных, в котором им нужно быстро ориентироваться. В идеале они должны выполнять простые операции, поэтому для их эффективной работы нужно составить простую и прозрачную методику, где будет указано, что они должны делать в конкретном случае. Все. Баста.
Я обнаружил, что самая эффективная реализация функции дата-стюардов находится в бизнес-подразделении. Дам вам десять баллов, если сможете засунуть их в департамент разбора жалоб клиентов, где они на месте смогут разбираться в проблемах с качеством клиентских данных.
Да, именно «там», где пишут жалобы через сайтик, контакт-центр или от руки (на бумажечке), должны сидеть дата-стюарды, которые работают с клиентскими данными.
К сожалению, все проблемы дата-стюарды решить не могут, иначе бы они рассыпались на много маленьких некрасивых кусочков.
На сцену выходит вторая боевая группа, которую я называю дата-инженеры. Как, надеюсь, понятно из слова «инженер», эти ребята должны что-то строить и проектировать. И все действительно так: они проектируют единую архитектуру управления качеством данных (проверки, средства контроля и, конечно, дизайн самих IT-систем и цифровых интерфейсов). Если сравнивать обе команды, то инженеров должно быть меньше, потому что это более высококвалифицированные единицы.
Точка дислокации этой группы может быть разной. В организациях, где директор по данным (CDO) не является ключевым сотрудником компании и находится где-нибудь на уровне Board-2, такая команда может находиться как внутри финансового блока, так и внутри IT-блока.
Эффективнее будет расположить инженеров ближе к команде IT-блока, так как эти ребята должны непосредственно изучать IT-системы, углубляться в процессы и предлагать решения.
В случае, когда организация слишком продвинутая и зрелая, CDO обычно выступает уже на уровне Board – входит в Правление или стоит максимум на одну ступень ниже, но по-прежнему остается ключевым сотрудником.
Теперь вопрос. Где взять таких людей для позиции инженера по качеству данных на рынке? Если начать поиски на HeadHunter или на других подобных порталах, то достаточно быстро станет ясно, что количество релевантных кандидатов для обеих позиций оставляет желать лучшего.
Я выкручивался тем, что брал людей из других подразделений, создавая таким образом возможности для горизонтального роста. Происходило это как внутри компании, так и с привлечением соискателей из вне.
Инженеров я искал и брал как из службы IT-поддержки, так и из смежных департаментов, где есть бизнес-экспертиза. В службах IT-поддержки я руководствовался тем, что люди при разборе тех или иных инцидентов и проблем в IT-сервисах, вынуждены погружаться в то, как работают сами IT-решения.
Бизнес-экспертиза необходима, потому что инженер должен понимать, как влияет на бизнес выявленная ошибка в данных.
В качестве инструмента сведения и демонстрации общего эффекта проблем с качеством данных, я выбрал подход так называемого документа «аппетит к риску».
«Аппетит к риску» – это специальный документ, отражающий размер потенциальных рисков, которые несет в текущий момент организация, он политика относительно текущей позиции и ее фиксирования.
История документа лежит в Базельских требованиях. Это требования, которые были приняты международным сообществом (Базельским комитетом) как достаточные требования для управления банковским капиталом, чтобы иметь возможность управлять риском банковского банкротства (дефолта), а точнее, иметь возможность его предсказывать.
Так вот, «аппетит к риску» – это внутренний документ, который готовит организация для того, чтобы в момент измерить, достаточно ли у нее капитала для покрытия возможных убытков, которые могут возникнуть, если что-то пойдет не так. Сюда в том числе относятся действия и самой организации, когда она решается на более рискованные стратегии или запуск сложных продуктов. Надеюсь, кратко, но понятно. Этот документ обычно режет глаз, он должен показывать то, что у организации больше нет возможностей для маневров, и служить отрезвляющим душем для менеджеров.
После участия в проектах управления Базельскими требованиями внедрения сложных механизмов расчета достаточности капитала, мне показалось интересным применить логику построения этого документа к оценке рисков, которые содержат в себе некачественные данные.
И если раньше, когда я приходил в Правление организации, мне было сложно объяснить важность управления качеством данных, то, создав такой документ, где мы наглядно отразили размер потенциальных убытков от плохих данных (те же штрафы за поле «ИНН»), я смог сфокусировать внимание менеджмента на самом важном. На бабках.
Только такой язык сегодня понятен внутри бизнеса. Если ты явно покажешь, что качество данных создает убыток для организации, с высокой степенью вероятности, ты получишь новый ресурс для решения этой проблемы или митигации этого риска.
Есть много подходов и визуализаций отражения и создания классического документа «аппетит к риску». Все они применимы к созданию аналогичного документа в отношении качества данных.
В классическом варианте такой документ выделяет виды капитала (регуляторный, экономический) и виды рисков, но что же он должен показывать в отношении данных?
Как измерять качество данных?
Не буду претендовать на уникальность и вернусь к работе аудиторов. Уж очень она яркий отпечаток оставила в моей памяти. Мое вечное желание все вокруг связывать и комбинировать в поисках прорывных решений не дает мне об этом просто так забыть.
Как проверить что конкретная цифра в весьма конкретной отчетности верна?
Оказалось, очень просто: аудитор в своей работе использует так называемые «assertions» или «допущения», которые разбиты на определенные группы, коих опять конечное количество. Есть такой стандарт по международному аудиту номер 315, которым обязаны руководствоваться международные компании по аудиту. Так вот он говорит, что этих самых «assertions» в части финансовой отчетности всего 13 штук и они все поделены на три определенные группы.
Первая группа таких допущений относится к транзакциям и формируемой прибыли:
1. Наличие (Occurrence) – транзакция или событие действительно имело место и реальности произошло.
2. Полнота (Completeness) – транзакции, которые произошли, были отражены полностью.
3. Точность (Accuracy) – все данные касательно транзакций отражены без искажений.
4. Срез (Cutoff) – транзакции произошли в правильном отчетном периоде.
5. Классификация (Classification) – транзакции были отражены на правильном счете и правильной строчке.
Вторая группа уже касается остатков и самого баланса, и выглядит она следующим образом:
1. Существование (Existence) – актив, обязательство или указанный капитал действительно существуют.
2. Права и обязанности (Rights and Obligations) – то, что отражено в отчетности, и организация непосредственно это контролирует.
3. Полнота (Completeness) – все, что реально существует, все это отражено полностью во всех соответствующих строчках отчетности (активы, обязательства, капитал).
4. Оценка и распределение (Valutation and allocation) – все, что реально было, отражено корректно с точки зрения оценки этих объектов. К примеру, ценные бумаги, которыми владеет организация, должны быть отражены по самой последней рыночной котировке и так далее.
Третья группа уже касается непосредственно раскрытий и пояснений финансовой отчетности:
1. Существование (Occurrence) – все, что было раскрыто и пояснено в отчетности, оно действительно случилось. Если в отчетности написано, что сгорел завод, значит, он действительно сгорел.
2. Полнота (Completeness) – все, что в реальности было, тоже раскрыто. Если еще сгорел амбар помимо завода, и это важно, то это нужно раскрыть.
3. Классификация и понимание (Classification and understanability) – вся финансовая информация должна быть представлена таким образом, чтобы было все просто и понятно. Никаких сложных раскрытий и сложных описаний.
4. Точность и оценка (Accuracy and valuation) – все посчитано честно и аккуратно.
Надеюсь, сознание после этих трех групп еще не потухло, идем дальше. Когда работает аудитор, он оценивает материальные искажения в каждом из этих тринадцати измерений. Материальность отклонения также определяют по разным правилам. Так управляется риск контроля качества информации в финансовой отчетности.
Мне показался данный подход достаточно зрелым, поэтому я взял его за основу и попробовал упростить для того, чтобы сделать единую методологию.
Прежде стоит отметить, что раньше аудиторам помогали специальные напарники, которые аудировали, как работают IT-системы, хранящие первичную информацию для отчетности.
Эти люди при проверке IT-систем изучали, как работает контроль в отношении данных. Должны были быть ответы на такие простые вопросы: «Откуда данные?», «Кто может их изменить?», «Как проверяется корректность значений?», «Какие программные средства использует организация для исправления проблем?» и так далее.
Они используют опросы, изучают логи подключений к системам и на выходе, по результатам своей работы, они могут сказать, в каких из измерений, скорее всего, будет проблема.
Эти самые «assertions» можно смело назвать «измерениями», то есть некоторым разделением того, как я воспринимаю объект в реальном мире.
Главное, что они должны говорить пользователю – любое число или любые данные – само по себе объект многомерный.
Вот я держу книгу. В стандартной проекции у нее три оси – ширина от края разворота до середины, длина от одного края страницы до другого края страницы и толщина, то есть количество страниц. Книгу мы воспринимаем как физический объект в трех измерениях.
Так вот, информация сама по себе имеет много измерений, больше трех. И не факт, что их именно тринадцать. Чтобы управлять качеством этой информации, нужно управлять представлением этой информации в этих измерениях. Это сложный контекст, отчасти поэтому в качество данных мало инвестируют и мало этим занимаются, хотя, на мой персональный взгляд, ценность этого очевидна.
Чтобы стало проще, можно упростить количество тех самых измерений, в которых мы управляем качеством данных. Для простоты оставим только «полноту» и «точность» – то есть все, что произошло вокруг, отражено в информации и отражено корректно. Только два измерения.
Теперь вернемся к пресловутому и коварному отчету «аппетит к риску» – здесь мы должны посчитать размер потенциального искажения для двух измерений.
Как пострадает организация, если поймет, что не отражены только 95 % тех событий, которые произошли, или что сами 15 % событий отражены неточно? Возьмем то же поле «ИНН». Допустим, что поле заполнено только в 95 % случаев, а в заполненных оно некорректно в 15 % случаев. Пусть мы говорим о количестве записей 10 тысяч единиц известных нам, тогда потенциальный размер штрафа будет равен:
15 %*95 %*10 000 + (10000/95 % – 10000) = 1425 + 526 = 1951 записи могут быть некорректны.
Опустим как получили оценку 95 % или 15 %, для простоты считаем это экспертной позицией участников процесса работы с данными.
1951 умножаем на размер штрафа в пятьсот рублей, получаем 975 500 рублей – это потенциальный убыток от проблем с качеством данных одного поля «ИНН» для организации.
Как понять, какие измерения качества выбрать?
Мне нравится одно очень интересно исследование, которое провели исследователи из MIT. Оно называется «Beyond Accuracy». Для него исследователи выделили несколько групп пользователей.
В первой группе пользователей, которых они опросили, были студенты MBA.
Во второй группе пользователей, среди которых был опрос, находились уже выпускники MBA, которые проработали в компаниях достаточное количество лет.
Опросы так же отличались друг от друга. Опрос для первой группы включал в себя список возможных измерений контроля качества данных, из которого студенты должны были выбрать предпочтительный.
Напомню, что в исследованиях всегда используют один из трех различных подходов получения научного познания:
• Эмпирический – познание получаем через ощущения.
• Теоретический – осмысление опыта с точки зрения логики.
• Интуитивный – когда мы полагаемся на свой «внутренний» голос при исследовании того или иного события.
В первой группе исследователи применили теоретический подход получения нового знания – а именно списка параметров, «измерений», по которым можно контролировать качество данных.
Во второй группе исследователи применили уже интуитивный подход, чтобы понять, какие из этих параметров на самом деле наиболее важны в принятии решений и их влиянии на бизнес. В этом случае продолжительный опыт бывших выпускников MBA в компаниях являлся тем самым «внутренним фильтром», который помог определить наиболее ценные измерения из большого списка.
Исследователи сформировали список из 32 параметров контроля качества данных (32 параметра – это достаточно внушительно), и попросили сформулировать, как бы выпускники контролировали качество данных.
По итогам опроса получилось 179 уникальных параметров, которые сформулировали участники процесса, то есть в пять с половиной раз больше, чем исследователи изначально заложили в свою модель.
Модель исследователей строилась на четырех основных группах, которые объединяли эти самые параметры:
• Доступность – данные должны быть доступны для пользователя.
• Интерпретируемость – данные должны быть способны к интерпретации. К слову, не пытайтесь использовать мандаринский диалект, если вдруг пишите комментарии в проводках и так далее.
• Релевантность – данные должны быть релевантны для конечного пользователя, если они участвуют в процессе принятия решения.
• Точность – данные должны быть точны для пользователя, то есть быть точными и из достоверных источников.
Во второй группе исследователи отбросили часть новых параметров и показали только 118 параметров контролирования качества данных. Опрос строился на ответах 1500 выпускников MBA, которые уже имели внушительный опыт работы.
Опустим тот факт, что опрос строился через почту, и тогда не было еще нормального работающего Интернета, обратимся лучше к его результатам.
99 из указанных параметров из основного списка оказались абсолютно не важны, когда люди с большим опытом и багажом знаний попытались интуитивно ответить на тот же самый вопрос о том, как контролировать качество данных.
Два параметра пользователи выделили как самые важные – «точность» (accuracy) и «правильность» (correct). Все самые важные параметры исследователи сгруппировали вместе в кластеры, которых получилось ровно четыре.
Рисунок SEQ Рисунок \* ARABIC 1 Структура концептуального фреймворка DQ, на основании исследования MIT Beyond Accuracy. 1993
Внутреннее качество данных – включает не только точность, но и два новых измерения – репутацию и правдоподобие. Одна лишь «точность», как оказалось, не дает пользователям уверенности в корректности данных. Им нужно доверять источникам данных.
Качество данных контекста – как оказалось, качество данных по контексту профессиональная литература по работе с данными не распознает, то есть, таких знаний просто не было. Люди не имели представления, как управлять качеством того контекста, который они получают. Единственные доступные материалы были о качестве визуального контекста – графике. Мы это подробно разобрали в главе про «Data Storytelling». Пример реализации контекстных проверок был, как ни странно, в армии Соединенных Штатов Америки во время операции «Буря в Пустыне», где такие проверки были установлены на воздушных судах. Они анализировали для каждой задачи, выполняемой воздушным судном, широкий список параметров, используемый в планировании авиаударов.
Представление качества данных – в первую очередь эта группа касается проблем с форматом данных и с тем, чтобы данные можно было понять и интерпретировать. К примеру, данные по отчетности ВТБ отражаются в российских рублях, в свою очередь, в данных группы Альфа-Банка в публикуемой отчетности вместо рублей уже используются доллары как основная валюта.
Доступность данных – один из самых неоднозначных параметров, потому что управление информационной безопасностью в большинстве проектов и организацией, в которых мне довелось побыть, выведено за периметр как IT-департамента, так и Финансового департамента. Управление информационной безопасностью – это отдельно выделенный лидер внутри организации, поэтому решения в области ИБ в большинстве случаев не участвуют в управлении качества данных.
В итоге, исследователи MIT вывели 15 ключевых измерений того, как можно управлять качеством данных, и сформировали из них следующий фреймворк.
Это было более двадцати лет назад, но на мой скромный экспертный взгляд такой подход по-прежнему актуален, хотя мало где еще используется. Его мы можем смело использовать при подготовке отчета «аппетит к риску», чтобы выбить из менеджмента ресурсы на все свои «хотелки» в области данных.
Инструменты управления качеством данных
Вот представим, что вам дали задачу наладить контроль качества данных в организации. Ваши действия? Кроме того, что выпить валерьянки – это и так понятно.
Я бы постарался разделить весь этот необъятный пирог из данных внутри организации на какие-то разумные блоки или куски.
Интуитивно понятным мне видится выделить хотя бы три блока информации, которыми можно попробовать управлять каждым по-своему. Ими будут – клиенты, справочники и продукты.
Такие блоки для простоты предлагаю называть «доменами», только не будем путать их с теми доменами, которые есть в Интернете. В текущем контексте «домен» – это группа однородной информации, которой нужно управлять. Большую часть информационного пирога можно разделить на три крупных блока, чтобы с этим начать работать по закону Парето.
Почему так?
На моей практике оказалось, что решения или инструменты (программные средства), которые обещают стать универсальным средством, по факту проигрывают в этом соревновании. Либо они становятся малоэффективными, то есть не позволяют выявить проблемы в данных, либо они становятся неимоверно дорогими, до такой степени, что стоимость их использования совершенно не сопоставима с получаемой ценностью.
Поэтому я для себя решил, что одного универсального средства ото всех бед не существует. Кстати, такие универсальные инструменты называются MDM-платформами. Какое-то время они считались единственным средством против всех болезней и рекомендовались к внедрению в любой организации для любой проблемы. В реальности каждое такое внедрение превращалось в некий эпик фейл, то есть в мероприятие, обреченное на провал. Поиск Святого Грааля в решениях с данными натолкнул на мысль о «вырожденности» решений, которые могут управлять различными доменами. «Вырожденность» подразумевает, что свойства и функции каждого из инструментов для различных доменов сильно отличаются друг от друга. Инструмент по управлению качеством данных для домена «Клиенты» не подходит для управления качеством в домене «Справочники» – и наоборот.
Теперь шаг в сторону и маленький ликбез по тому, как можно управлять качеством данных этого большого информационного пирога.
С одной стороны, можно не трогать источники данных и работать с конечным информационным продуктом, что обычно получается на выходе. К примеру, как это делают аудиторы, когда работают и проверяют финансовую отчетность и данные, на основании которых она строится.
С другой стороны, можно исправлять данные там, где они появляются, то есть, в самих системах. Или исправлять до того момента, пока они не появятся. Например, ограничить ввод данных и задать определенные рамки для информации.
Разница между этими принципиальными подходами заключается только в стоимости усилий. Оказалось, что стоимость усилий контроля в конце цикла какого-то длинного процесса кратно выше, чем стоимость контроля на начальных этапах. Происходит это из-за того, что анализ проблем осуществляется в конце, и требуется много дополнительного времени для раскопок причин, которые обычно могут рассказать, что пошло не так.
Если, скажем, стоимость проверки в конце при формировании финансовой отчетности стоит тысячу рублей, то стоимость контроля на первых этапах будет стоить не больше десяти рублей. Поэтому при плохой работе внутренних контролей внешний аудит обычно стоит много денег, потому что аудиторам приходится раскапывать много информации, – почему все плохо в цифрах.
Работать с качеством данных и контролировать их на первых этапах можно несколькими путями. Можно задать тот самый коридор допустимых значений, которые, к примеру, не позволяют ввести несуществующий адрес.
Во втором случае все работает наоборот. Решения допускают ввод любого значения, чтобы потом некоторое внутреннее решение по тому или иному домену само разобрало данные с использованием различной сложной логики и предложило правильный вариант. Если я ввел несуществующий адрес, система сможет найти самый ближайший аналог или экземпляр похожего адреса, который существует в реальности, а дата-стюард уже согласует финальное значение.
Да, именно так, решения сами по себе без дата-стюардов не работают, то есть нельзя автоматизировать всеми возможными средствами вокруг все возможные ошибки.
Самыми эффективными считаются гибридные подходы. Они объединяют первые подходы с заранее невозможным вводом несуществующих и невозможных данных и с определенным допущением свободны со стороны пользователя ввести все, что он считает правильным. Пример с почтовыми индексами это наглядно отражает. В базах данных они по-прежнему некорректные, поэтому пользователя просят дополнительно в свободной форме ввести его.
Первый подход называется «децентрализованным» контролем качества данных, а второй, когда задаются значения, называется «централизованным».
Домен «Клиенты» – вся информация, которая касается наших клиентов: их ФИО, дата рождения, контактные данные, сегменты, в которые определил их маркетинг, выводы, которые сделал комплаенс, и так далее. Все это будет внутри домена «Клиенты».
Для управления качеством данных в этом домене используется специальное решение CDI, задача которого посредством специальной сложной логики уметь сопоставлять различный образцы карточек клиентов, выделять похожих и указывать на это дата-стюарду.
Как было в случае «склейки» меня и моего брата в банковских сервисах, такое решение должно было выявить ошибку и показать дата-стюарду, что две карточки клиентов с одинаковой фамилией, одинаковым отчеством и одинаковой датой рождения склеились, но на самом деле это разные клиенты, так как у них разные имена и паспортные данные.
Правила в CDI задает и проверяет никто иной как инженер данных. Надеюсь, теперь стало понятно почему эти ребята тоже крайне важны.
Как работает CDI?
Он превращает информацию каждого экземпляра карточки клиента в сложный код посредством определенной логики и сравнивает их между собой. Например, внутри банка может такое быть, что Благирев Алексей Павлович был заведен девять раз в различных системах, и данные, естественно, неоднородно заполнены между всеми этими системами.
Где-то нет даты рождения, где-то нет полных паспортных данных, где-то нет адреса и много чего другого.
CDI объединяет все эти образцы вместе и создает свой собственный уникальный образец, который уже включает в себя все заполненные параметры из различных источников. Этот конечный образец называется «золотая запись», его можно уже передавать в системы и использовать.
CDI позволяет организовать полноценный промежуточный слой работы с клиентскими данными, а на него уже можно «надеть» или подключить все основные клиентские сервисы через CRM.
Но встает вопрос – как быть уверенным, что система взяла нужный образец и вытащила нужную дату рождения для этого образца? Здесь как раз снова появляются инженеры данных, которые определяют допустимые критерии (веса) по тем или иным источникам данных, полям и так далее. В определении весов участвует как интуиция, так и статистика. Сколько существует однофамильцев, которые родились со мной в один день? Инженеры знают ответ. Ну или должны знать.
Домен «Справочники» – тут нужно разобраться, какие из доступных классификаторов внутри организации являются ключевыми, то есть такими, которыми пользуются все департаменты. Эти классификаторы можно назвать глобальными. Классификатор – это список допустимых значений – названия офисов, список продуктов, список сегментов и так далее.
В качестве технического решения используется специальное средство RDM или по-русски «НСИ», которое не просто хранит правильный список значений и его распространяет, но и имеет встроенный механизм управления изменениями этих значений. Этот механизм допускает ввод новых значений только от владельцев данных.
Да именно так, появляются владельцы данных, которые отвечают за корректность того или иного справочника.
Владельцы могут назначаться на конкретный параметр в справочнике, а сам справочник может быть представлен не просто списком, а довольно сложной иерархией (отделения складываются в филиалы, филиалы складываются в организацию).
Рассмотрим пример со справочником банковских офисов. У него должен быть определен владелец, который отвечает за качество значений всех офисов. Должна быть процедура заведения нового значения в справочник.
Например, нам нужно поставить в банковский офис пандус, чтобы люди с ограниченными возможностями или дама с ребенком в коляске могли зайти в офис. Но так, чтобы дама сразу знала какой из офисов оборудован пандусом, а какой нет. Для этого руководителя офиса можно сделать владельцем данных одного параметра в справочнике банковских офисов – «Есть пандус».
Руководитель банковского офиса, который непосредственно находится на месте будет отмечать галочку «Да»/Нет», если в офисе есть пандус, а система уже выведет эту информацию на сайт или в мобильное приложение, чтобы конечный пользователь смог выбрать ближайший к нему офис и без проблем заехать в него.
Домен «Продукт» – самый сложный на мой взгляд домен, его цель – управлять жизненным циклом продукта внутри организации. От момента его создания, до момента его снятия с производства или с продаж. В розничном бизнесе и банках такие IT-платформы, которые управляют качеством данных по продукту называются PIM. В первую очередь, это управление каталогом продуктов и характеристиками каждого из продуктов, сбор статистики и определение базовой себестоимости услуг и сервисов внутри каждого конкретного продукта. На производствах такие платформы более комплексные, так как там необходимо уже интегрировать много различных источников (3D схемы из CAD решений и другие), они называются PLM. Они содержат информацию об изделии: 3D схему, технологическую карту о том, как изделие изготовлено, технологический паспорт и инструкцию по ремонту, то есть как изделие необходимо обслуживать.
На практике очень мало результативных внедрений таких технологий, потому что они затрагивают множество процессов в организации и являются критерием зрелости компании в работе с данными.
Начинать с домена «Продукт» я не рекомендую, потому что домены «Клиент» и «Справочники» являются гигиеническим минимумом в организации. Если компания решилась всерьез заняться качеством данных, переход к «Продукту» будет наиболее эффективен, когда организация освоит не только сами инструменты RDM или CDI, но и запустит соответствующие службы из дата-стюардов и дата-инженеров.