Big data простым языком

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

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

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

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

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

Основные методы управления качеством данных

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

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

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

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

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

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

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

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

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

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

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

Точка дислокации этой группы может быть разной. В организациях, где директор по данным (CDO) не является ключевым сотрудником компании и находится где-нибудь на уровне Board-2[131], такая команда может находиться как внутри финансового блока, так и внутри IT-блока.

Эффективнее будет расположить инженеров ближе к команде IT-блока, так как эти ребята должны непосредственно изучать IT-системы, углубляться в процессы и предлагать решения.

В случае, когда организация слишком продвинутая и зрелая, CDO обычно выступает уже на уровне Board – входит в Правление или стоит максимум на одну ступень ниже, но по-прежнему остается ключевым сотрудником.

Теперь вопрос. Где взять таких людей для позиции инженера по качеству данных на рынке? Если начать поиски на HeadHunter или на других подобных порталах, то достаточно быстро станет ясно, что количество релевантных кандидатов для обеих позиций оставляет желать лучшего.

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