О качестве данных для людей, далеких от ИТ

О качестве данных для людей, далеких от ИТ

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

В интересное время мы живем! Нас окружает информация, и ее стало слишком много. Свою информацию мы доверяем компьютерам и сетям, над которыми колдуют айтишники и наслаждаемся чувством контроля: вот он весь мир, на кончиках пальцев! Каждый шаг под контролем! Все клиенты не в головах менеджеров, которые иногда уходят, а в моих системах, которые остаются! Ура!

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

Представьте себе, например, производство колбасы. Это технологический процесс, который выполняется и все. На входе – мясо, специи, всякая полезная и не очень химия, на выходе – колбаса. Вкусная. А если мясо будет с душком, специи – не те, соль – с камнями, то и результат на выходе получится малосъедобный. Но виноват ли в этом процесс, технологи которого умеют единственно что строго и точно его исполнять?

С данными происходит все то же самое. За каждой цифрой, записью, за каждой строкой отчета, в конце невероятно длинной цепочки стоят люди. Которые ошибаются. Компьютеры не ошибаются никогда, и доверяя их безошибочности мы нередко забываем про то, что их безошибочность – это формальная правильность колбасного техпроцесса. И получаем несъедобные отчеты, информацию «с душком», а то и тяжкое отравление бизнеса.

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

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

Клиенты

Нет ничего важнее клиента – это вам любой управленец скажет! Стало быть, и информация о клиенте – самый ценный актив. А что такое «информация о клиенте»? А это его имя или наименование, адреса, телефоны, имена контактов и снова адреса и телефоны.

Ошибки в клиентских данных почти неизбежны, ибо их вводят люди, причем люди как правило не самые квалифицированные и высокооплачиваемые. Вы уверены, что вот та девушка из колл-центра с хорошим голосом и зарплатой в 20 тыс. рублей, задавленная системой контроля эффективности операторов, правильно введет какой-нибудь «Севзапгазнефтепромприбор»? Или Христофора Карловича Урамбердыева? Да ладно, спотыкаются даже на «ООО Рамашка» и Павле Питровиче Сидрове!

Облигиация или Аблигация?

А адреса? На практике мы видели минимум 18 способов написать «Москва»! По доброй половине адресов из среднестатистической клиентской базы никак нельзя приехать или выслать почту, они ведут в никуда и требуют уточнения, их нельзя написать на конверте. Конечно, потом, когда это в конкретном случае мешает, появляется новый человек, и для человека очевидно, что «ул. Нвая» — это улица Новая, «Ивнов» — это Иванов, а номер 132-23-44 наверняка имеет код 495, ибо компания московская и если бы был 499, то так бы и написали. Может быть.

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

Но и это еще не вся история. В бизнесах, массово обслуживающих клиентов, со временем, клиент оказывается учтен множество раз. Раз завели с опечаткой в наименовании, второй – вместо ООО написали «Общество с ограниченной ответственностью». Третий раз – по именованию без оргформы вообще. Так вот, для компьютера это будут три разных клиента. С людьми еще хуже, там однофамильцы и прочее, там вообще любому оператору проще заново завести, чем пытаться найти в базе. И чем больше масштаб процесса – тем больше размер ошибки. Это мы еще даже не рассматриваем сложные жизненные случаи типа «женщина вышла замуж и сменила фамилию». Для 99% бизнесов она стала другим человеком.

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

Итого, в отчетах у Вас три миллиона клиентов, а по факту –  как бы не два. В отчетах в среднем три покупки на клиента в год, а по факту – пять с лишним. И так далее. Вам никогда никакие компании, банки, например, не звонили по три раза к ряду с одним и тем же «персональным предложением»? Вот, это именно оно!

Последствия низкого качества клиентских данных – неадекватная отчетность на верхнем уровне, косяки с доставками и коммуникациями с клиентом на нижнем. А для компьютеров – все нормально. Три миллиона клиентов, без сомнения!

Самое сложное в этой ситуации то, что к этому все привыкли. «Раз в компьютере — значит верно».

А теперь задайте себе простые вопросы: сколько на самом деле у Вас клиентов? Какова вероятность, что клиенту дозвонятся по номеру телефона? Что письмо дойдет? Уверены? А почему? Компьютер так показывает?

Товары и услуги

Товары – наверное, вторая по важности сущность для бизнеса. Нет смысла в клиенте, если нечего ему продать, так?

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

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

А на вводе данных, обработке заказов и прочей оперативке у нас опять сидят обычные люди, под прессом KPI среди которых нет пункта «долго и внимательно искать в базе из сотен тысяч наименований на предмет нет ли там чего-то похожего». Да еще и в предмете эти люди как правило не разбираются вовсе. И заколачивает девушка-оператор-логист какой-нибудь кабель 3х2,5 по пятнадцатому разу.

И заметим снова: с точки зрения компьютера – это совершенно разные позиции!

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

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

А теперь зададим себе вопрос: сколько у меня дублей в каталоге товаров? Какова реальная номенклатура, а что – результат многократного ввода? Когда логист принимает решение по закупке – какова вероятность того, что он просто не нашел этот же товар по складу? Не такой простой вопрос как кажется!

Базы инвентаризации, обслуживаемой техники и так далее

Еще одна важная зона, если ваша компания – сервисная. Особенно если она делает сервис за деньги. Источник тут все тот же – человек, ибо все эти базы в отправной своей точке формируются людьми, и все их ошибки дальше живут своей жизнью, искажая картину. А даже если Вы получаете эти базы от клиента — то кто сказал, что они должного качества? Их тоже люди делали.

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

И что с этим делать?

Итак, если Вы дочитали до этого места, не закрыв окно с возгласом «какая фигня!» – значит, как минимум, узнали в описанном свои проблемы. Поговорив о проблемах было бы неправильно не поговорить о решениях, чем мы и займемся.

Итак, первое: предупрежден, значит вооружен! Мы надеемся, что теперь у Вас есть понимание того, что компьютеры не ошибаются, но честно транслируют ошибки людей. А значит, мы уже на полпути к решению. Из этого следует, что «управление качеством данных» — никакая не блажь, а одна из многих дисциплин на стыке информационных технологий, бизнес-процессов и управления персоналом. И этим надо серьезно заниматься.

Второе, как и все в этом мире, проблема не нова, а напротив, она куда старше компьютеров, ибо относится к управлению и учету, а не к ИТ. Да, да, и до компьютеров в бланки учета писали не то, а потом их бездумно обобщали!

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

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

Собирательно, такого рода решения относятся к классу систем «управление качеством данных» (data quality), и в широком смысле включают в себя два главных процесса: валидацию и дедубликацию.

Валидация

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

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

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

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

Когда мы имеем дело с данными, у которых внутренне присущей им логики нет, ситуация становится сложнее. Тут в ход идут эталонные базы данных, справочники, алгоритмы поиска и соотнесения. Например, базы адресов, имен, наименований организаций, и специальные алгоритмы сопоставления, потому что «тупое сравнение по буквам» — не работает. Помните же, ошибки опечатки? Задача это сложная, хитрая и многогранная, во всяком случае за те 13 лет что мы ею занимаемся – нам она еще не надоела. Здесь обычно используются специальные средства и сервисы валидации, в том числе и те, что делаем мы. К сожалению, эта тема слишком объемна, чтобы полностью делать ее разработку только для себя и она вышла достаточно эффективной. Изобретение велосипедов — не лучшая стратегия.

Вкратце, эти сервисы «пробивают по базе» предоставленные данные, исправляют ошибки, опечатки, дополняют недостающую информацию где возможно.

Например, оператор ввел «Мсква, Ленинск про. 17 кв 23», мы это передаем сервису валидации, сервис его разбирает, проверяет по базе адресов и возвращает: «119071, г Москва, пр-кт Ленинский, дом 17, квартира 23», и отметку – «ОК». Значит адрес хороший, можно сохранять. Совсем ведь другое дело, и индекс появился, и уверенность, это хоть на конверт, хоть курьеру! А если сервис отвечает, что адрес не найден – это повод его «вернуть на доработку» оператору. Посмотреть как это работает можно здесь.

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

Наименования так же стоит валидировать. Их можно сверять по базе ЕГРЮЛ, например, что само по себе уже убережет от многих ошибок. Кроме того, при валидации они приводятся к единообразному виду, чтобы уж если название в кавычках – то все названия в кавычках, если уж ООО, то везде ООО, а не где как оператору было не лень. Кстати, это упрощает поиск и уменьшает накопление «дублей».

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

Между прочим, все перечисленное — очень доступное удовольствие. Сложившаяся цена на валидацию данных сервисами – от 10 копеек за одну проверку и вниз, плюс всякие лимиты на бесплатную обработку, бонусы и бесплатные виды услуг. Разве не стоит этих копеек уверенность в том, что данные качественные? И только если Вы обрабатываете записи миллионами в день или по религиозным соображениям не готовы к работе с внешними сервисами – то в этом случае сервер валидации данных нужно ставить на своей территории.

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

Иногда для повышения качества любят применять «структурированный ввод выбором из списка». Скачивают базу адресов – КЛАДР, и делают поля ввода в соответствии с ней. То есть надо сперва выбрать регион, потом населенный пункт, потом улицу, потом дом, а потом и квартиру, и все это из выпадающих полей длинною в два экрана, и тут уж никак не ошибешься, ибо выбрать можно только то, что в этой базе есть. Это типичный пример того, как качество данных достигается ценой непропорциональных трудозатрат. Если в одну строку оператор вводит адрес секунд за пять, валидация сервисом и полный разбор занимают где-то 0,2 секунды, и превращает 95% этого ввода в надежные адреса, а 5% оператору приходится дорабатывать, то с этим нагромождением полей и списков – ввод одного адреса может занять и поболее минуты. И уж совсем ужасно, если Вы заставляете этим заниматься своих клиентов. Это тупиковый путь, жертвовать удобством и скоростью ввода в угоду качеству не следует, тем более, что и к качеству тут вопросы есть, на двадцатом вводе операторы устают и тупо промахиваются в списках.

Ну и заканчивая с темой валидации еще раз напомним: не надейтесь заставить людей «делать правильно» приказами, инструкциями, правилами или регламентами. Вы можете обещать им все казни египетские за ошибки или отпуск на Бали за их отсутствие – это ничего не изменит. Ошибаются и будут ошибаться.
Филлипыч!

Дедубликация

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

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

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

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

Второе, именно по этой причине ИТ-индустрия давно выделила эти виды данных в группу «мастер-данные», то есть ключевые данные на каркасе которых строится вся деятельность предприятия, требующие особого подхода. Чтобы понять подробнее – стоит почитать нашу образовательную статью. А раз они требуют особого подхода, то появился и новый класс систем – системы управления мастер-данными. Например, наш IQ MDM.

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

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

  1. «Заставить», подход организационный: прежде чем завести новое – убедись в том, что это не повтор! Как мы говорили, это самый неэффективный путь, но зато он и не стоит ничего.
  2. «Чистка кармы». Разовая или периодическая очистка данных. Это приблизительно как пригласить профессионалов на генеральную уборку. Люди приходят, берут Ваши данные, шаманят над ними, а затем возвращают их, очищенными, вадилированными, собранными в кучу, обогащенными и с разметкой: вот это и это – слить, это один и тот же клиент. То есть делают всю интеллектуальную работу, используя инструменты, слишком громоздкие и дорогие, чтобы их покупать. Ваши айтишники обновляют данные в системе результатом «переработки» и вы сбрасываете с себя груз накопленных проблем. Но начинаете копить их снова. Правда, за счет приведения к единому виду и чистки накопление новых ошибок идет уже куда медленнее, особенно если эффективно использовать валидацию.
  3. «Сделать по уму». Самый долгий и дорогой, но в то же время самый эффективный способ. Подразумевает полноценное внедрение технологий и средств управления мастер-данными и интеграцию их со всеми другими приложениями. В этом случае все мастер-данные хранятся в единой базе, а «проверка на похожие» производится прямо при попытке создания новых клиентов, товаров и так далее. Поскольку эти системы обладают развитыми алгоритмами анализа подобия и сравнения, хитрыми правилами всякими что считать одним и тем же, а что нет, то в этом случае большая часть проблем с «дублями» решается. Правда, унаследованные данные все равно придется сперва «прочистить», см. п. 2 выше.

Естественно, что надо по одежке протягивать ножки. При небольшом количестве клиентов, умных айтишниках и правильной мотивации нередко хватает п. 1 и 2 для того, чтобы ущерб от потери качества данных был разумным. Но если данных по-настоящему много, миллионы записей, они «размазаны» по разным системам, то тут особого выбора и нет. Или мириться с потерями или внедрять MDM. Впрочем, при таких масштабах бизнеса стоимость MDM систем уже не является проблемой, экономия от ее внедрения будет намного больше.

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

И в заключение

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

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

Здоровья Вам и вашим данным! Берегите честь — смолоду, платье – снову, а данные – прямо с момента ввода!

%d0%b4%d0%b0%d0%bd%d0%bd%d1%8b%d0%b5-%d0%ba%d1%83%d1%80%d0%b8%d0%bb%d1%8c%d1%89%d0%b8%d0%ba%d0%b0

Share