В 2015 году ФНС грозился, что штраф за незаполненное поле «ИНН» с каждой такой записи составит двести рублей, а с 2016 года вырастет до пятисот. Представьте, что я банк. И если у меня сто тысяч клиентов, по которым я списал задолженность, или по которым начисляют зарплату с моих банковских карт, то, умножив сто тысяч на двести рублей, я получу ежегодный штраф в размере двадцати миллионов рублей.

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

Сколько таких «важных» полей существует внутри IT-систем большой организации? Отвечу досрочно – десятки тысяч как минимум. Десятки тысяч таких полей, десятки тысяч гигантских табличек, которые нужно проверять и контролировать.

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

Наверняка, заполняя какую-нибудь формочку на сайте, вы сталкивались с его просьбой указать «индекс». А потом вы нервно начинали гуглить индекс указанного адреса.

Но фишка в том, что «индекс» как поле можно и не запоминать, это атавизм. Из утвержденных публичных справочников типа ФИАС или КЛАДР[125], в правильном существующем адресе уже есть индекс, и его можно взять оттуда.

Это ведь просто прекрасно – не заполнять поле «индекс». Так почему же его до сих пор заполняют и спрашивают?

Оказалось, что в базе ФИАС[126] (государственный источник) поле «индекс» заполнено не совсем корректными почтовыми индексами. Нужно искать еще и другие правильные источники, например, базу данных «Почты России», но даже в этой базе нет всех тех индексов, которые есть в ФИАС.

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

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

Как быть? Как исправить ошибки, которые уже случились? Я ведь не могу пойти на «Горбушку» и купить компакт-диск с данными[127].

Для обогащения данных клиентов и заполнения поля «ИНН», мы пробовали различные методы. Звонили и спрашивали, просили прийти в офис и заполнить анкету, делали даже такую доработку в мобильном приложении или интернет-банке[128].

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

Кстати, если вдруг вы торгуете ценными бумагами, мало ли меня читают такие умные люди, то, наверное, обратили внимание, что в личном кабинете брокера, через который вы торгуете, появилось обязательное требование заполнить поле «ИНН». Совпадение? Не думаю.

Качеством и проблемами в данных должны управлять специальные люди в организации.

Да ладно вам, согласитесь, что это уже очевидно. Будет странно, если я начну распинаться и объяснять слишком очевидные вещи.

Лучше я объясню, где и как организовать работу таких людей.

Для начала нужно все разбить на две части.

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

Задача дата-стюардов проста и понятна – разобраться оперативно в каше под названием данные так, чтобы ни один клиент не пострадал, или чтобы вовремя выпустилась отчетность. Ну, кажется, понятно объяснил. Если нет, то, скорее всего, во время чтения этой книги вы слышали какие-то посторонние звуки или встретили другие препятствия, – настоятельно рекомендую избавиться от них. Главное, не говорите потом, мол, Алексей, ты пишешь «непонятно». Даже не думайте. Я ведь очень стараюсь.

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

Я обнаружил, что самая эффективная реализация функции дата-стюардов находится в бизнес-подразделении[129]. Дам вам десять баллов, если сможете засунуть их в департамент разбора жалоб клиентов, где они на месте смогут разбираться в проблемах с качеством клиентских данных.

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

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

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