Управление данными

Один клиент, пять названий: зачем компаниям MDM

Никита Корнеев·11 мин чтения

MDMData Modeling

В 1С клиент записан как ООО Ромашка, в CRM - как Ромашка ООО, в SellOut-системе - как Romashka, а во внешнем источнике находится по условному ИНН 7712…. В аналитической витрине он уже может выглядеть как Клиент 000142.

Это не обязательно ошибка. Разные системы решают разные задачи, используют собственные правила ввода и присваивают объектам локальные идентификаторы. Проблема появляется в момент, когда данные нужно объединить: сложить продажи, связать активность менеджеров с оплатами, построить отчёт по клиенту или передать изменения из одной системы в другую.

Тогда возникает практический вопрос: все эти записи относятся к одному клиенту или перед нами несколько разных объектов?

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

Система	Локальная запись	Что может стоять за записью
1С	`ООО Ромашка`, код контрагента `18452`	учётная запись контрагента
CRM	`Ромашка ООО`, customer ID `C-9081`	коммерческий клиент
SellOut	`Romashka`, partner ID `P-271`	партнёр, сеть или торговая точка
Внешний источник	ИНН `7712…`, адрес, официальное название	внешний идентификатор и реквизиты
DWH	master ID `M-000142`	единая аналитическая сущность

Даже если все записи связаны с одной организацией, это ещё не доказывает, что они описывают одинаковую бизнес-сущность. В 1С может быть юридическое лицо или контрагент по договору, в CRM - коммерческий аккаунт, в SellOut - партнёр либо конкретная торговая точка. DWH может объединять эти объекты в одну аналитическую модель, но для этого связь нужно определить явно.

Для задач сопоставления записей из разных источников используется термин entity resolution - определение того, какие записи описывают одну и ту же реальную сущность. На практике также говорят matching или сопоставление сущностей. Описание этой задачи как объединения данных из разных источников приведено, например, в документации AWS Entity Resolution.

Почему чистки названий недостаточно

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

После такой обработки записи могут превратиться, например, в:

ООО РОМАШКА;
РОМАШКА ООО;
ROMASHKA.

Но даже одинаковая строка не гарантирует, что речь идёт об одной организации. И наоборот, разные строки могут описывать одну сущность.

Различия возникают по нескольким причинам:

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

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

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

Название - это один из признаков, а не универсальный идентификатор.

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

До сопоставления строк нужно договориться о сущностях. Слово «клиент» в разных процессах может обозначать разные объекты:

юридическое лицо;
контрагента в ERP;
плательщика;
покупателя;
коммерческий аккаунт в CRM;
торговую сеть;
торговую точку;
филиал или обособленное подразделение;
группу компаний;
внутреннюю запись конкретной системы.

Предположим, в CRM есть аккаунт «Ромашка», а в SellOut - три магазина этой сети. В учётной системе при этом может существовать одно юридическое лицо, которое оплачивает товары. С точки зрения финансового учёта это один контрагент, с точки зрения продаж - сеть, а с точки зрения SellOut - несколько точек.

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

Поэтому до выбора правила сопоставления нужно ответить на вопрос: какую сущность должна представлять единая запись в конкретной аналитической или операционной задаче?

Внутренний ID и устойчивый идентификатор - не одно и то же

18452 в 1С, C-9081 в CRM, P-271 в SellOut и M-000142 в DWH могут быть уникальными идентификаторами внутри своих систем. Но это не делает их универсальными.

Внутренний ID обычно нужен конкретному приложению:

1С использует собственный код контрагента;
CRM - собственный customer ID;
SellOut - код партнёра или торговой точки;
DWH - ключ аналитической сущности.

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

Master ID	Система	Исходный ID	Локальное представление
`M-000142`	1С	`18452`	`ООО Ромашка`
`M-000142`	CRM	`C-9081`	`Ромашка ООО`
`M-000142`	SellOut	`P-271`	`Romashka`

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

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

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

Поэтому устойчивый идентификатор нужно рассматривать в контексте сущности, к которой он относится.

Matching - не магическая кнопка

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

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

Найти точное совпадение по доступному устойчивому идентификатору.
Проверить, что идентификатор относится к нужной сущности и не был ошибочно перенесён.
Если надёжного идентификатора нет, сравнить нормализованные название, адрес, телефон и другие признаки.
Определить степень уверенности в совпадении.
Автоматически объединять только случаи, которые соответствуют заранее заданным правилам.
Передавать пограничные случаи на ручную проверку.
Сохранять решение, дату, основание и ответственного.

В зависимости от данных могут использоваться разные подходы:

точное совпадение по одному или нескольким полям;
набор детерминированных правил;
нечёткое сравнение строк;
вероятностная оценка по совокупности признаков;
ручная верификация спорных случаев.

Пример логики для условной записи «Ромашка»:

название после нормализации похоже на запись в CRM;
адрес совпадает частично;
телефон отличается;
ИНН найден только во внешнем источнике;
в SellOut запись может относиться не к юридическому лицу, а к торговой точке.

Результатом не обязательно должно быть бинарное «совпало» или «не совпало». Полезно разделять хотя бы такие статусы:

подтверждённое совпадение;
вероятное совпадение;
вероятный дубль;
конфликт;
недостаточно данных;
отклонённое совпадение.

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

Golden record: согласованное представление клиента

После сопоставления нужно решить, как будет выглядеть объединённое представление сущности. Для этого используется понятие golden record - согласованная запись, сформированная на основе нескольких источников и правил разрешения конфликтов.

Условный golden record клиента может содержать:

единый master ID;
официальное название;
коммерческое название;
ИНН или другой внешний идентификатор, если он доступен;
адреса;
статус;
контактные данные;
связи с записями в 1С, CRM, SellOut и DWH;
дату обновления;
происхождение каждого атрибута.

Ключевой момент: golden record не обязательно является буквальной копией одной строки из одной системы. Для разных атрибутов эталонное значение может поступать из разных источников.

Например:

юридическое название берётся из юридически проверенного источника;
коммерческое название - из CRM;
связь с торговой точкой - из SellOut;
сегмент клиента - из маркетинговой системы;
master ID - из процесса управления master data.

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

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

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

Master data связывает системы, но не отменяет их различия

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

В рассматриваемом примере одни и те же данные о клиенте участвуют в разных процессах:

CRM хранит коммерческие отношения и работу менеджеров;
1С хранит контрагента, документы и расчёты;
SellOut отражает продажи через партнёра или торговые точки;
внешние данные дополняют и проверяют атрибуты организации;
DWH объединяет эти контексты для аналитики.

Master data позволяет связать объекты между собой, но не делает их одинаковыми. Юридическое лицо, торговая точка и коммерческий аккаунт могут оставаться разными сущностями с разными связями.

Здесь проходит граница между MDM и обычной задачей построения витрины. DWH может создать единый клиентский ключ и объединить данные для отчёта. Но наличие такого ключа само по себе ещё не означает, что в компании есть управление master data.

MDM включает не только модель данных, но и правила:

как создаётся новая запись;
как обнаруживаются и обрабатываются дубли;
какие атрибуты считаются обязательными;
как разрешаются конфликты;
кто подтверждает изменения;
как решения распространяются в источники;
как хранится история;
как измеряется качество данных.

Общее представление о MDM как об управлении ключевыми сущностями бизнеса и согласованными данными в разных системах приведено в материалах IBM о Master Data Management. Контекст управления качеством, согласованием и ответственностью за master data также рассматривается в материалах SAP о Master Data Governance.

Кто решает, какое значение правильное

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

Для разных атрибутов владельцами могут быть разные функции. Например:

Атрибут	Возможный предпочитаемый источник	Кто принимает решение
Юридическое название	официальный реестр или юридически проверенный источник	юридическая функция или владелец справочника
Коммерческое название	CRM или коммерческий процесс	продажи или владелец CRM
Внутренний ID 1С	1С	владелец ERP
Сегмент клиента	CRM или маркетинговая система	маркетинг или продажи
Связь с торговой точкой	SellOut или операционная система	владелец канала
Master ID	MDM- или DWH-процесс	владелец модели master data

Это пример, а не универсальная схема. В конкретной компании источники и роли могут быть другими.

Помимо data ownership - ответственности за решения о данных и правилах их использования - нужна операционная работа по поддержанию качества. Её часто называют data stewardship. Она включает обработку спорных совпадений, контроль исключений, координацию исправлений и проверку соблюдения правил.

Нужно заранее ответить на практические вопросы:

кто создаёт новую запись;
кто подтверждает юридические реквизиты;
кто отвечает за коммерческое название;
кто исправляет ошибочное сопоставление;
что происходит при конфликте между CRM и 1С;
кто одобряет объединение двух записей;
как исправление попадает в остальные системы;
кто отвечает за связь юридического лица с торговой точкой;
как фиксируется решение и его основание.

Фраза «источник истины - CRM» обычно слишком груба. CRM может быть хорошим источником коммерческого названия и сегмента, но не обязательно юридического адреса. ERP может быть владельцем внутреннего кода контрагента, но не коммерческого бренда. Для каждого атрибута нужны отдельное правило и ответственный.

Что MDM меняет в архитектуре и процессах

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

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

Для условной «Ромашки» это может означать, что M-000142 связан с кодом 18452 в 1С, C-9081 в CRM и P-271 в SellOut. При этом связь с SellOut может быть уточнена: это не сама организация, а одна из её торговых точек или партнёрский объект.

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

какой атрибут изменился;
кто имеет право его менять;
нужно ли обновить golden record;
в какие системы передать изменение;
как сохранить прежнее значение для исторической отчётности.

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

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

MDM нужен не ради ещё одного справочника

У одной организации действительно может быть несколько названий и идентификаторов:

ООО Ромашка в 1С;
Ромашка ООО в CRM;
Romashka в SellOut;
условный ИНН во внешнем источнике;
Клиент 000142 в аналитической системе.

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

MDM нужен, чтобы согласованно ответить на несколько вопросов:

что именно в компании считается клиентом;
как соотносятся юридическое лицо, контрагент, сеть, торговая точка и CRM-аккаунт;
какие идентификаторы используются для связи;
как работает matching;
какие случаи объединяются автоматически, а какие проверяются вручную;
что считается golden record;
откуда берётся каждое значение;
кто владеет атрибутом;
как изменения и решения возвращаются в исходные системы.

Результат - не обязательно одна одинаковая строка во всех приложениях. Это управляемая договорённость о сущностях, идентификаторах, связях, правилах, ответственности и происхождении данных. Именно она позволяет корректно объединять продажи, активность и реквизиты, не выдавая удобное совпадение названий за доказанную идентичность клиента.