Почему в системе появляются дубликаты и несовпадения

Дубликаты данных редко появляются потому, что кто-то просто дважды нажал кнопку «Создать».

В корпоративной инфраструктуре одна и та же сущность может проходить через несколько систем, подразделений и процессов. Клиент создаётся в CRM, затем появляется в 1С, его данные используются на сайте, в сервисе доставки и в аналитической системе. Товар приходит из ERP, дополнительно загружается на маркетплейс, редактируется в каталоге и участвует в складских операциях.

Каждая система хранит эту сущность по своим правилам.

В результате одна компания превращается в несколько записей, один товар получает несколько идентификаторов, а один бизнес-статус начинает называться по-разному.

Упрощённо проблема выглядит так:

Откуда вообще берутся дубликаты

Первопричина обычно не в самих данных.

Она в том, что разные системы по-разному понимают одну и ту же сущность.

Представим компанию:

Если система сопоставляет записи только по названию, она может решить, что это четыре разных организации.

• › Если сопоставлять только по телефону, проблемы появятся у компаний с несколькими номерами.
• › Если только по email — один адрес может использоваться несколькими сотрудниками или подразделениями.

Дубликат — это не всегда полная копия

Это принципиально важный момент.

Две записи могут выглядеть совершенно по-разному и при этом описывать одного человека или организацию.

Технически строки различаются.

Но вероятность того, что это один человек, очень высокая.

И наоборот, две записи могут выглядеть почти одинаково, но относиться к разным объектам:

Название одинаковое.

Юридические лица разные.

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

Она заключается в определении:

Дубликат — это не всегда полная копия

Это принципиально важный момент.

Две записи могут выглядеть совершенно по-разному и при этом описывать одного человека или организацию.

Технически строки различаются.

Но вероятность того, что это один человек, очень высокая.

И наоборот, две записи могут выглядеть почти одинаково, но относиться к разным объектам:

Название одинаковое.

Юридические лица разные.

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

Она заключается в определении:

Самая важная вещь — идентификаторы

В зрелой системе у каждой сущности должен существовать устойчивый идентификатор.

Но одного внутреннего идентификатора новой системы недостаточно, если объект приходит из других систем.

Тогда возникает соответствие:

Такая таблица соответствий позволяет понимать, что несколько технических идентификаторов относятся к одному бизнес-объекту.

Нормализация и сопоставление — разные задачи

Их часто объединяют, хотя это два разных процесса.

То есть:

Для разных сущностей нужны разные правила

Нельзя создать одно универсальное правило дедупликации для всей компании.

Товар особенно легко превратить в несколько объектов

Допустим, в ERP есть:

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

Нужно определить, является ли это:

• › одним товаром с вариантами;
• › двумя отдельными SKU;
• › одной моделью и двумя комплектациями;
• › разными складскими позициями.

Статусы тоже создают несовпадения

Представим, что CRM использует:

На первый взгляд достаточно написать таблицу соответствий:

Но возникает более сложный вопрос. Что означает won?

Это:

• › заказ создан;
• › заказ подтверждён;
• › деньги получены;
• › отгрузка выполнена?

У разных систем могут быть разные жизненные циклы.

Единый справочник не означает, что все системы должны использовать одинаковые значения

Это важный архитектурный нюанс.

Не всегда нужно заставлять все существующие системы работать с одним набором статусов.

Можно построить слой соответствия:

При этом внутренняя терминология каждой системы сохраняется.

Главное — чтобы интеграционный слой понимал соответствия и не терял смысл.

А кто вообще должен исправлять данные?

Это уже вопрос ответственности.

Допустим, система обнаружила:

Кто должен решить, какую запись оставить?

Поэтому для ключевых данных полезно определить владельцев:

Источник истины должен быть один

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

Например:

Правильнее установить:

А не организовывать бесконечный обмен:

Двусторонняя синхронизация требует особой осторожности

Представим:

CRM изменила клиента.

Изменение ушло в ERP.

ERP сохранила его и отправила обратно.

Или более неприятную ситуацию — одна система постоянно перезаписывает другую.

Поэтому при проектировании обмена нужно понимать:

• › кто инициировал изменение;
• › кто является владельцем поля;
• › какое значение новее;
• › можно ли его изменять с другой стороны;
• › как определяется конфликт;
• › что происходит при одновременном редактировании.

Что делать с конфликтующими изменениями

Представим:

Последняя запись не обязательно правильная.

Принцип «побеждает последнее изменение» работает далеко не всегда.

Для разных атрибутов могут действовать разные правила.

Автоматическое объединение тоже имеет границы

Можно построить систему, которая автоматически ищет вероятные дубликаты.

Например:

Но не все случаи стоит объединять автоматически.

Удобно использовать несколько уровней уверенности:

Конкретные пороги зависят от типа данных и цены ошибки.

Почему «нечёткий поиск» не решает проблему

Fuzzy matching действительно полезен.

Он помогает обнаруживать:

Но он отвечает только на вопрос:

А бизнес-задача звучит иначе:

Похожесть — лишь один из признаков.

Надёжное сопоставление может выглядеть так:

Дубликаты появляются и из-за неправильной интеграции

Иногда проблема вообще не в пользователях.

Например, CRM отправляет заказ:

Система создаёт заказ.

Ответ не успевает вернуться из-за сетевого сбоя.

CRM считает запрос неуспешным и отправляет его снова.

Поэтому для интеграций важна идемпотентность операций.

Например, передаётся внешний идентификатор:

При повторном запросе система видит:

Удаление тоже может создавать несоответствия

Представим, клиент удалён в CRM.

Что должно произойти в остальных системах?

Поэтому корпоративные системы часто используют не физическое удаление, а состояние:

При этом объект остаётся в истории, но перестаёт участвовать в новых операциях.

История изменений важнее текущего состояния

Допустим, сегодня клиент относится к категории:

Но три месяца назад он был:

Если хранить только текущее состояние, исторический отчёт может показать, что клиент всегда был VIP.

Поэтому для значимых атрибутов иногда требуется хранить историю:

Тогда можно ответить не только:

но и:

Как строится качественный процесс очистки

Очистка данных обычно проходит не одной операцией.

Условно процесс можно представить так:

Профилирование особенно важно.

Нельзя просто удалить дубликаты

Представим две записи:

Поэтому объединение должно быть не:

A + B → удалить B

а:

Архивировать исходную запись

Такой процесс называют merge.

Хорошая система должна предотвращать дубликаты, а не только искать их

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

Гораздо эффективнее поставить проверки на входе.

Например, при создании юридического лица:

Так дубликат не появляется в системе изначально.

Качество данных — это непрерывный процесс

Даже после первоначальной очистки проблема не исчезает.

• › Появляются новые пользователи.
• › Подключаются новые системы.
• › Меняются форматы API.
• › Добавляются филиалы.
• › Изменяются справочники.
• › Появляются новые бизнес-процессы.

Поэтому качество данных можно представить как цикл:

Метрики качества позволяют увидеть проблему до пользователя

Для крупных систем полезно контролировать качество не субъективно, а количественно.

Например:

Можно установить допустимые пороги:

Конкретные значения зависят от бизнеса.

Что должно происходить при обнаружении ошибки

Не каждая проблема должна автоматически исправляться.

Иногда система может решить проблему сама:

Иногда требуется правило:

А иногда нужен человек:

Поэтому полезно разделять автоматические и ручные решения:

Где должна находиться логика качества

Если каждое приложение самостоятельно проверяет клиентов, товары и статусы, со временем правила начнут расходиться.

Лучше выделять общие механизмы:

Типичная схема, когда компания объединяет много систем.

Дубликаты — это симптом архитектурной проблемы

Если в компании постоянно возникают:

• › повторные клиенты;
• › разные карточки одного товара;
• › конфликтующие статусы;
• › разные адреса;
• › несогласованные справочники;
• › расхождения между CRM и ERP;

Возможно, проблема находится глубже:

В таком случае очередная очистка базы даст только временный эффект.

Как выглядит зрелая модель управления данными

В зрелой architecture для каждой ключевой сущности можно ответить на несколько вопросов:

Единые данные — это не одинаковые базы

Иногда под «единой системой данных» ошибочно понимают необходимость физически хранить всё в одной базе.

Это не обязательно так.

• › CRM может оставаться CRM.
• › ERP — ERP.
• › WMS — WMS.
• › Сайт — сайтом.

Важно другое:

Что в итоге делает данные действительно качественными

Одной очисткой базы проблему не решить.

Качественные данные появляются тогда, когда компания одновременно контролирует несколько уровней:

Каждый слой закрывает свою часть проблемы.

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

Дубликаты и несовпадения редко являются отдельной технической неисправностью.

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

Поэтому зрелый подход начинается не с вопроса:

А с другого:

Если ответ найден, можно устранить первопричину.

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

Тогда архитектура постепенно меняется:

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