MDM: как навести порядок в НСИ и перестать чинить интеграции

В любой компании справочники НСИ сначала выглядят как “ну это же просто таблицы”. Контрагенты, номенклатура, адреса, подразделения, единицы измерения, статусы. Пока людей и систем мало - всё держится на внимательности пары сотрудников и привычке “если что, поправим руками”.

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

Эта статья - про MDM: что считать мастер-данными, какие справочники есть почти везде, почему хаос появляется даже в нормальных командах, и как начать наводить порядок без мегапроекта на два года. В конце будет план на 30/60/90 дней, чтобы можно было примерить.

1. почему справочники важнее, чем кажется

НСИ - это “словарь” компании. В нём живут те объекты, к которым потом привязывается всё остальное: контрагенты, номенклатура, адреса, подразделения, единицы измерения, статусы, типы документов. Пока этот словарь единый и аккуратный, процессы идут ровно: закупка понимает, у кого покупаем, склад понимает, что принимаем, бухгалтерия понимает, кому выставляем, аналитика понимает, что считать.

Проблемы начинаются, когда у компании становится больше одной системы. Обычно это выглядит так: есть учёт (часто 1С), есть CRM, есть складская система, есть сайт или маркетплейсы, есть BI. Каждая система по-своему хранит одни и те же сущности. И даже если “на бумаге” они одинаковые, в данных быстро появляются различия. Маленькие. Незаметные. Но именно они потом ломают интеграции и отчётность.

Важно поймать мысль в самом начале: интеграция переносит не данные, а смысл. Если смысл расходится, интеграция превращается в бесконечный ремонт.

как это выглядит в жизни (на пальцах)

Контрагенты.
В учёте контрагент - это юрлицо с реквизитами. В CRM “клиент” часто живёт как карточка компании плюс контактные лица. В логистике важнее адреса доставки и грузополучатель. В результате один реальный поставщик или покупатель распадается на несколько “почти одинаковых” карточек.

Типичный набор расхождений:

·         Разные варианты названия: “ООО Ромашка”, “Ромашка ООО”, “OOO Romashka”.

·         Разные или неполные реквизиты, у кого-то заполнен ИНН, у кого-то нет, у кого-то адрес в одну строку, у кого-то по полям.

·         Разные роли в одной карточке: где-то поставщик и покупатель - одна сущность, где-то это два разных типа.

Снаружи это выглядит как ерунда. Внутри это означает, что система не понимает, что “Ромашка ООО” и “ООО Ромашка” - одно и то же. Она честно создаёт дубль. А дальше дубль начинает жить своей жизнью: на одного оформляют договор, на другого выставляют счёт, на третьего заводят доставку.

Номенклатура.
Номенклатура - чемпион по бардаку, потому что там много “человеческого творчества”. Один и тот же товар могут завести как:

·         “Кабель 3х2.5”, “Кабель 3*2,5”, “Кабель ВВГнг 3x2.5”.

·         В разных единицах: метр, бухта, упаковка.

·         С разными характеристиками: где-то хранится сечение, где-то нет, где-то это часть названия, где-то отдельное поле.

Если у товара нет единого кода и единых правил описания, интеграция начинает “угадывать”. Сегодня угадала, завтра нет. Потом появляются ручные таблицы соответствий “вот этот товар в CRM равен вот этому товару в учёте”. Таблицы пухнут, люди путаются, новые сотрудники боятся их трогать.

Адреса и локации.
Адрес - классический источник тихого хаоса. Один сотрудник пишет “СПб, Невский 1”, другой - “Санкт-Петербург, Невский пр., д. 1”, третий - “г. Санкт-Петербург, Невский проспект 1”. Для человека это одно и то же. Для системы это три разных значения. Потом начинаются странные вещи: отчёты по регионам пляшут, доставки “не находятся”, в документах всплывают разные варианты.

Единицы измерения и статусы.
Это кажется мелочью, но это основа для автоматизации. Когда в одной системе “шт”, в другой “штука”, в третьей “pcs”, а в четвёртой “1”, интеграция не может корректно сопоставить. То же со статусами: где-то “Отгружено”, где-то “Передано в доставку”, где-то “Закрыто”. Если нет общей карты смыслов, автоматические процессы спотыкаются.

почему это превращается в вечный ремонт интеграций

Интеграция любит стабильные ключи. Ей нужен “якорь”, по которому она понимает, что это тот же объект:

·         Для контрагента - един��й идентификатор и понятные правила, откуда берутся реквизиты и как обновляются.

·         Для товара - единый код (артикул) и понятные правила по единицам и характеристикам.

·         Для адреса - стандарт и нормализация (хотя бы единый формат).

Если якоря нет, интеграция начинает жить на костылях:

·         “Если название совпало на 80 процентов - считаем, что это тот же контрагент”.

·         “Если в названии товара есть ‘3х2.5’ - маппим сюда”.

·         “Если статус такой-то - значит почти отгружено”.

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

как это бьёт по бизнесу

·         Люди тратят время на сверки и ручные исправления: “проверь, тот ли контрагент”, “найди правильный товар”, “сведи отчёт”.

·         Ошибки становятся регулярными: неверные реквизиты, неправильные адреса, пересортица, двойные оплаты, “задвоенные” отгрузки.

·         Руководители спорят о цифрах вместо решений: один отчёт показывает одно, второй другое, третий третье. И каждый прав “в своей системе”.

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

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

 

2. термины - мастер-данные, НСИ, справочник, транзакции

Сначала разделим данные в компании на три корзины. Это сильно упрощает жизнь, потому что дальше становится понятно, что именно мы “лечим” MDM-ом, а что трогать не надо.

транзакционные данные

Это события и факты “что произошло”. Заказ, счёт, платёж, отгрузка, звонок в колл-центр, заявка в поддержку, движение по складу.

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

мастер-данные

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

Пример. Если контрагент заведен криво, то “криво” будет в заказах, счетах, отгрузках, отчётах и интеграциях. Это и есть причина, почему мастер-данные так больно бьют по бизнесу, хотя “их всего-то справочник”.

НСИ и справочники

НСИ - нормативно-справочная информация. На практике в компаниях так называют “все справочники, которые должны быть одинаковыми для всех систем”. Это зонтик, под которым живут и мастер-данные, и классификаторы, и разные таблицы соответствий.

Справочник - это форма хранения. Там лежат записи, у которых есть поля. Проблема обычно не в том, что “справочник плохой”. Проблема в том, что в разных системах справочников несколько, и каждый считает себя главным.

классификаторы и справочники значений

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

идентификатор, ключ, код

Тут важно различать два понятия.

Идентификатор - это то, по чему система узнаёт объект. Внутренний ID в базе, GUID, код записи. Он должен быть стабильным.

Название - это то, что видит человек. Оно может меняться, у него бывают опечатки, разные форматы и “как привыкли в отделе”.

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

эталонная запись

Эталонная запись - это “версия, которой верим”. Для одной сущности в компании выбираются правила, какие поля считаем эталонными и кто имеет право их менять.

Например, у контрагента можно договориться так.

·         Реквизиты и юридические атрибуты ведём в учёте.

·         Контактных лиц ведём в CRM.

·         Адреса доставки ведём там, где реально работают с доставкой, но формат адреса нормализуем один раз и используем везде.

Важно, что эталон - это не “самая старая система” и не “у кого громче голос”. Это договорённость плюс контроль.

качество данных

Качество данных - это не “красиво заполнено”. Это когда данные пригодны для работы и автоматизации.

Обычно качество распадается на простые вещи.

·         Полнота. Заполнены ли ключевые поля.

·         Точность. Соответствует ли значение реальности.

·         Единообразие. Одинаково ли заполняем в разных местах.

·         Уникальность. Нет ли дублей.

·         Актуальность. Обновляются ли данные, когда должны.

нормализация и дедупликация

Нормализация - приведение к единому формату. Простейший пример - единый формат адреса, телефона, наименования организации, единиц измерения.

Дедупликация - поиск и склейка дублей. Важно слово “склейка”. Часто люди удаляют “лишнюю карточку”, а потом внезапно выясняется, что на неё завязаны документы. Поэтому правильнее мыслить так: дубли объединяются в эталон, а история сохраняется.

где тут MDM

MDM - это подход и набор практик, которые делают мастер-данные управляемыми.

·         Есть правила, как создаём и меняем записи.

·         Есть роли, кто отвечает за что.

·         Есть контроль качества.

·         Есть механизм, как “правд��” расходится по системам.

 

 

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

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

Ниже - набор справочников, который встречается почти всегда. Если навести порядок хотя бы здесь, интеграции резко “успокаиваются”, а отчёты начинают сходиться.

3.1 контрагенты (юрлица, ИП, физлица, филиалы)

Это основа для продаж, закупок, бухгалтерии и договоров.

Что обычно хранится:

·         Идентификаторы и реквизиты (ИНН, КПП, ОГРН, наименование, банковские реквизиты).

·         Роли (поставщик, покупатель, перевозчик, подрядчик).

·         Адреса (юридический, фактический, доставки), контакты, договорные признаки (платёжные условия, НДС, валюты).

Типовые проблемы:

·         Дубли из-за разного написания и отсутствия общего “якоря”.

·         “Смешение сущностей”: в одной карточке и юрлицо, и контактное лицо, и филиал, и грузополучатель.

·         Реквизиты меняются, но обновляются не везде, дальше начинается ручная сверка.

Практическая мысль для руководителя: контрагент почти вс��гда должен иметь единый жизненный цикл. Кто создаёт, кто подтверждает реквизиты, кто меняет адрес, кто закрывает карточку. Без этого вы будете бесконечно “подравнивать” интеграции.

3.2 номенклатура (товары, услуги, материалы, работы)

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

Что обычно хранится:

·         Код/артикул, наименование, единица измерения, группа/категория.

·         Характеристики (размер, цвет, материал, мощность - что угодно по отрасли).

·         Признаки учёта (серийность, партии, комплекты, ставки налогов, требования к маркировке - если актуально).

Типовые проблемы:

·         Один товар заведён несколькими способами: разное имя, разные единицы, разные характеристики.

·         Характеристики “живут” в названии, поэтому их невозможно нормально сравнивать и искать.

·         Справочники категорий и единиц измерения расходятся между системами, и расчёты начинают “плыть”.

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

3.3 адреса, локации, объекты (склады, филиалы, точки, места работ)

Это всё, что отвечает на вопрос “где”.

Что обычно хранится:

·         Адрес как текст и как структура (город, улица, дом и т.д.).

·         География (регион, зона доставки, маршруты), привязка к складам/точкам.

·         Для B2B часто появляется “объект работ”: стройка, площадка, магазин, офис клиента.

Типовые проблемы:

·         Адрес в свободной форме, из-за этого система не понимает совпадения.

·         Одна локация называется по-разному в учёте, логистике и CRM.

·         Невозможно нормально считать “по регионам” и “по зонам”, потому что адреса не приводились к одному виду.

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

3.4 оргструктура и сотрудники (подразделения, должности, роли)

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

Что обычно хранится:

·         Дерево подразделений, руководители, центры затрат, локации.

·         Роли в процессах (кто согласует, кто подписывает, кто отвечает за справочник).

·         Связки “сотрудник - подразделение - роль”.

Типовые проблемы:

·         В одной системе отдел называется так, в другой иначе, в третьей отдел вообще “подразделение 001”.

·         Согласования ломаются при реорганизации, потому что нет единой точки, где оргструктура считается актуальной.

·         Доступы и маршруты живут на исключениях.

3.5 классификаторы и “малые справочники” (единицы, статусы, типы, причины)

Это вроде мелочь, но именно она делает интеграции хрупкими.

Что обычно хранится:

·         Единицы измерения, валюты, ставки, типы документов.

·         Статусы процессов (заказа, поставки, возврата), причины отмен, причины списания.

·         Справочники соответствий между системами.

Типовые проблемы:

·         Разные значения означают одно и то же, но пишутся по-разному.

·         Статусы в системах несопоставимы по смыслу, и автоматизация превращается в “если то”.

·         Таблицы соответствий ведутся вручную, никто не знает, где последняя версия.

3.6 как выбрать “первый справочник” для наведения порядка

Если цель - быстро уменьшить количество поломок в интеграциях, стартуют обычно так:

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

·         Номенклатура - если много складских операций, себестоимости, пересортицы и “похожих товаров”.

·         Адреса/локации - если логистика, выезды, доставка, филиальная сеть.

Правило простое: берёте справочник, который чаще всего участвует в проблемных местах и чаще всего “всплывает” в ручных сверках.

 

 

4. откуда берётся хаос в нси

Хаос в справочниках появляется не потому, что “люди плохие”. Он появляется потому, что справочники - общая инфраструктура, а живут они обычно кусками: в каждой системе, в каждом отделе, в каждом файле “актуальная_версия_финал_2.xlsx”.

4.1 слишком много входов в справочник

Один и тот же объект создают из разных мест:

·         менеджер заводит контрагента в CRM, чтобы выставить КП;

·         бухгалтер заводит его в учёте, чтобы провести оплату;

·         снабжение заводит в закупках, чтобы оформить договор;

·         интеграция импортирует “поставщиков” из внешней системы;

·         кто-то вручную загружает прайс и получает сотни новых позиций номенклатуры.

Каждый вход живёт по своим правилам. Итог предсказуемый: дубли и расхождения.

4.2 нет единых правил заполнения

Обычно правила звучат так: “заполняйте аккуратно”. Это не правило. Правило - это когда понятно:

·         какие поля обязательны;

·         в каком формате их заполняем;

·         откуда берём “истину” по каждому полю;

·         что делать, если данных нет или они спорные.

Пока этого нет, сотрудники заполняют так, как удобно им и их системе. Через месяц это превращается в “контрагент есть, но найти его нельзя” или “товар вроде есть, но в закупке он другой”.

4.3 у справочника нет владельца

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

·         “Это ведёт бухгалтерия”

·         “Нет, это ведёт продажи”

·         “Это вообще ИТ должно чинить”

Без владельца справочник живёт по принципу “кто успел, тот и прав”, а качество становится побочным эффектом.

4.4 отделы оптимизируют под себя

Каждый отдел решает свою задачу быстро и локально:

·         продажам важно завести контрагента за минуту, иначе сорвётся контакт;

·         бухгалтерии важно, чтобы реквизиты были идеальные, иначе будет больно в учёте;

·         логистике важно, чтобы адрес был нормальным, иначе водитель не доедет.

Все правы. Но без общей модели и правил каждый делает “лучше для себя”, и справочник расходится на версии.

4.5 разные идентификаторы и “якоря”

Системы любят свои внутренние ID. Это нормально. Плохо, когда:

·         в одной системе ключ - ИНН, в другой - название, в третьей - внутренний код;

·         ИНН не заполняют на старте;

·         “название” пишут как угодно.

В этот момент интеграция перестаёт сопоставлять объекты надёжно. Она начинает угадывать или плодить дубли.

4.6 изменения не управляются

Создать запись обычно умеют все. А вот дальше начинается туман:

·         как правильно изменить реквизиты, чтобы это разошлось по системам;

·         как “закрыть” карточку контрагента, чтобы он не всплывал в новых документах;

·         как переименовать товар, не сломав историю;

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

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

4.7 справочники “лечат” интеграциями

Когда справочники расходятся, самый частый рефлекс - дописать преобразование в интеграции:

·         тут заменить “шт” на “штука”;

·         тут “склеить” по названию;

·         тут подставить значение по умолчанию;

·         тут сделать исключение для конкретного филиала.

Это даёт быстрый эффект, но накапливает технический и смысловой долг. Интеграции становятся хрупкими, а первопричина остаётся.

4.8 нет цены ошибки

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

·         внедряют ERP/BI;

·         подключают маркетплейсы/EDI;

·         запускают сквозные процессы;

·         начинают масштабироваться по филиалам.

Тогда выясняется, что вы строите автоматизацию на песке.

 

5. что такое MDM на практике: правила, роли, контроль качества, эталон

MDM в компании появляется в тот момент, когда вы перестаёте “поправлять справочники по факту” и вводите понятные правила. Чтобы любой сотрудник знал: как создать запись, как её изменить, кто это подтверждает, и как изменения разъедутся по системам.

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

5.1 эталон и “одна версия правды”

Эталон не означает, что все справочники физически лежат в одной базе. Эталон означает другое: по каждой сущности (контрагент, товар, адрес) есть ответ на вопрос “кому верим”.

Пример на контрагентах.

·         Реквизиты и юридические атрибуты. Есть место, где они считаются правильными.

·         Контакты. Есть место, где их ведут, и правило, как они попадают в остальные системы.

·         Адреса доставки. Есть правило формата и точка, где адрес нормализуется.

С номенклатурой та же история: должен быть ответ, что такое “код товара”, что входит в “наименование”, где хранятся характеристики, кто имеет право менять единицу измерения.

5.2 правила работы со справочником (жизненный цикл записи)

В MDM важно не “как хранить”, а “как жить”.

Минимальный жизненный цикл для любой записи:

·         Создание. Кто может создать, какие поля обязательны, какие значения запрещены.

·         Проверка. Кто подтверждает, что запись реальная, не дубль, не мусор.

·         Изменение. Как менять так, чтобы не сломать документы и историю.

·         Закрытие. Как выводим из использования, чтобы запись не всплывала в новых операциях, но сохранялась в истории.

Пока этого нет, люди делают то, что быстрее: создают новую карточку. Это и рождает 80 процентов дублей.

5.3 роли и ответственность (чтобы “справочник” стал процессом)

MDM редко проваливается из-за технологий. Он проваливается, когда некому принимать решения.

Минимальный набор ролей:

·         Владелец данных (обычно бизнес). Решает, какие правила считаются нормой, какие поля важны, какие исключения допустимы.

·         Ответственный за ведение (data steward). Следит за чистотой, разбирает спорные случаи, помогает пользователям, держит регламент.

·         ИТ. Делает так, чтобы правила реально работали в системах: проверки, интеграции, публикация изменений, аудит.

Важно: если владелец данных не назначен, все спорные вопросы уходят в чат “пусть ИТ решит”. ИТ начинает “решать смысл”, а не технологию. Это плохо заканчивается.

5.4 контроль качества, который можно проверить

В MDM качество не должно быть “на глаз”. Оно должно быть проверяемым.

Примеры проверок для контрагентов:

·         ИНН обязателен для юрлиц (если так решил бизнес).

·         КПП обязателен при определённом типе контрагента.

·         Не допускаются записи без страны, региона или хотя бы города, если от этого зависит логистика.

·         Поиск дублей по ключевым полям: ИНН, связка “название + адрес”, телефон, email (по ситуации).

Примеры проверок для номенклатуры:

·         Единица измерения только из утверждённого списка.

·         Код товара уникален.

·         Категория обязательна.

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

Главная мысль: качество должно проверяться автоматически там, где возможно. Иначе регламент превращается в “пожалуйста, заполняйте правильно”.

5.5 как MDM выглядит без покупки “большой системы”

MDM можно начать без отдельной MDM-платформы. На первом этапе вам нужно:

·         Описать правила и роли.

·         Выбрать один справочник и один процесс (например, создание контрагента).

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

·         Настроить распространение изменений хотя бы в 1-2 ключевые системы.

Это уже даёт эффект: дублей становится меньше, интеграции перестают “угадывать”, у людей появляется один понятный маршрут действий.

5.6 важный компромисс: скорость против качества

Бизнес обычно хочет два взаимоисключающих желания:

·         заводить карточки быстро;

·         чтобы карточки всегда были идеальными.

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

Если договорённости нет, компромисс всё равно возникнет. Просто неуправляемо: каждый отдел выберет “как ему удобно”, и справочник разъедется сно��а.

 

 

6. быстрый старт: какой справочник брать первым и как определить MVP-поля и правила

MDM почти всегда умирает в момент, когда команда пытается “навести порядок во всём сразу”. Поэтому старт должен быть маленьким, скучным и полезным. Один справочник. Один процесс. Один владелец. Пара метрик. Через 2-4 недели должно стать заметно легче жить.

6.1 как выбрать первый справочник

Выбирайте по одному из трёх признаков:

·         Самый частый источник ошибок. Там, где больше всего ручных сверок и “ой, не тот объект”.

·         Самый дорогой по последствиям. Там, где ошибка ведёт к деньгам, срокам, документам, поставкам.

·         Самый “центральный” для интеграций. Там, где больше всего систем потребляют один и тот же справочник.

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

6.2 ограничьте старт одним процессом

Справочник может участвовать в десятках процессов, но для пилота берём один:

·         Создание записи (как заводим новую карточку).

·         Изменение записи (как правим реквизиты, название, единицы, категорию).

·         Объединение дублей (как склеиваем и что происходит с историей).

Если взять все три сразу, вы закопаетесь в исключениях. Берите “создание” - это самый быстрый способ перестать размножать мусор.

6.3 MVP-поля: минимум, который даёт эффект

MVP - это набор полей, без которых объект нельзя считать пригодным для работы.

Примерный MVP для контрагентов (адаптируете под себя):

·         Тип контрагента (юрлицо/ИП/физлицо или ваш вариант).

·         Идентификатор(ы) по правилам компании (что вы считаете якорем).

·         Наименование в едином формате.

·         Страна, город (или более детальный адрес, если логистика критична).

·         Признак роли (поставщик/покупатель/подрядчик) - если это влияет на процессы.

Примерный MVP для номенклатуры:

·         Код/артикул (и правило, кто его выдаёт).

·         Наименование по шаблону (без “творчества”, где это важно).

·         Единица измерения из утверждённого списка.

·         Категория/группа (чтобы можно было считать и искать).

·         1-3 ключевые характеристики, которые реально используются (и хранятся в полях, а не в названии).

Смысл MVP простой: вы не пытаетесь сделать “идеальную карточку”. Вы делаете карточку, которая не ломает процессы.

6.4 MVP-правила: что запрещаем, что проверяем, что допускаем

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

Типы правил, которые реально работают:

·         Обязательные поля. Если пусто - запись не создаётся или создаётся как “черновик”.

·         Формат. Телефон и адрес заполняем по шаблону, единицы и статусы берём из списка.

·         Уникальность. Якорные поля не должны повторяться (или повтор допускается по понятной причине).

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

Важный момент: правила без механизма применения превращаются в плакат. Поэтому в пилоте вы сразу решаете, где правило живёт - в форме ввода, в регламенте, в согласовании, в “очереди на проверку”.

6.5 “быстро и идеально” не бывает: вводим черновики

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

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

·         Проверено. Прошёл контроль качества, получил “зелёный” статус, разошёлся по потребителям.

Так вы сохраняете скорость и одновременно перестаёте разносить мусор по всей компании.

6.6 как настроить роли, чтобы процесс не встал

Для пилота достаточно трёх ролей:

·         Владелец справочника (бизнес). Решает, какие поля важны и какие правила считаются нормой.

·         Ответственный за ведение. Разбирает спорные случаи и дубли, следит за очередью, обновляет правила.

·         ИТ. Делает так, чтобы процесс не был “на честном слове”: формы, проверки, распространение изменений.

Если владельца нет, решение “что считать правильным” превращается в бесконечные споры, а потом в исключения.

6.7 метрики пилота: 3 цифры, которые понимает руководитель

На старте достаточно трёх метрик:

·         Сколько дублей появляется в неделю (и как меняется цифра).

·         Сколько карточек создаётся с нарушениями (пустые поля, неверный формат).

·         Сколько времени занимает “довести карточку до нормы”.

Эти метрики напрямую влияют на внедрения и интеграции: качество данных часто становится критичным фактором успеха при внедрении ERP и сквозных процессов.

6.8 пример “правильного” старта на 2-4 недели

Неделя 1:

·         Выбираем справочник и процесс “создание”.

·         Фиксируем MVP-поля и 5-10 правил.

·         Назначаем роли.

Неделя 2:

·         Включаем проверки на вводе и простую проверку дублей.

·         Вводим “черновик -> проверено”.

Неделя 3-4:

·         Подключаем 1-2 системы-потребителя.

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

 

 

7. нормализация и дедупликация: почему «склеить дубли» опаснее, чем кажется

Нормализация - это приведение данных к одному виду. Дедупликация - поиск дублей и их объединение. Эти две задачи обычно идут парой: пока вы не договорились о формате, вы будете “находить” то дубли, то “почти дубли”, и спорить бесконечно. Тему нормализации НСИ обычно отдельно выделяют как обязательную, потому что без неё MDM быстро превращается в витрину поверх хаоса.

7.1 что такое нормализация на практике

Нормализация - это не “сделать красиво”. Это сделать так, чтобы одинаковое выглядело одинаково.

Типовые примеры:

·         Телефон: [phone] вместо десяти вариантов с пробелами, скобками и “доб. 123”.

·         Наименование контрагента: единый шаблон и правила сокращений, чтобы “ООО Ромашка” не превращалось в зоопарк.

·         Адрес: единая структура (город, улица, дом, корпус), а не поле “адрес одной строкой, как написали”.

·         Номенклатура: единицы измерения только из справочника, характеристики хранятся в полях, а не в названии.

·         Даты, почта, коды, статусы: единый формат, единые значения.

Результат нормализации измеряется просто: вы можете сделать поиск/сопоставление и получить предсказуемый результат.

7.2 «удалить дубль» почти всегда плохая идея

Когда люди слышат “дубли”, первый импульс - удалить “лишнее”. В учётных и операционных системах это часто ломает историю:

·         Документы ссылаются на старую карточку.

·         В интеграциях остались связи на “удалённый” объект.

·         В отчётах начинают появляться провалы, потому что часть данных осталась “сиротой”.

Поэтому рабочая модель другая:

·         Дубли объединяем в одну эталонную запись.

·         Старые записи помечаем как “объединено” или “не использовать”.

·         Сохраняем связи и историю, чтобы прошлые транзакции не развалились.

7.3 дедупликация - это всегда правила, а не “умный алгоритм”

Даже если вы используете автоматический матчинг, всё равно нужно ответить на вопросы:

·         По каким полям считаем, что это один и тот же объект.

·         Какие поля “побеждают”, если значения разные.

·         Что делать со спорными случаями.

·         Кто принимает решение, когда автоматике нельзя верить.

Для контрагентов обычно есть “жёсткие” признаки (типа уникальных идентификаторов по вашим правилам) и “мягкие” (похожее имя, похожий адрес, телефон, почта). Для номенклатуры часто наоборот: уникальные коды есть не всегда, и приходится строить дисциплину вокруг кода и категорий.

7.4 как объединять записи безопасно (простая схема)

Чтобы склейка не превращалась в минное поле, используйте понятный порядок:

1.       Выбираем “выжившую” запись (эталон), у неё будет основной идентификатор.

2.      К выжившей записи прикрепляем “псевдонимы” и старые ID (чтобы интеграции и история находили связь).

3.      Для каждого поля задаём правило выживания (survivorship), кто выигрывает: “берём из учёта”, “берём самое заполненное”, “берём последнее подтверждённое”, “берём вручную после проверки”.

4.      Старые записи переводим в статус “не использовать”, но не вырываем из истории.

5.       Фиксируем событие объединения: кто сделал, когда, почему, что объединяли.

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

7.5 нормализация как конвейер, а не разовая акция

Один раз “почистить” можно. Через месяц всё вернётся, если вход в справочник не контролируется.

Нормальный конвейер выглядит так:

·         На входе: проверки формата и обязательных полей.

·         При создании: подсказка о возможном дубле до сохранения.

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

·         В изменениях: правило, какие поля можно менять всем, а какие только через ответственного.

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

7.6 где чаще всего “рвётся” и почему

·         Адреса: слишком много вариантов ввода, много “человеческих” сокращений, плюс разные потребности у логистики и бухгалтерии.

·         Номенклатура: характеристики в названии, разные единицы, разные уровни детализации у закупок и продаж.

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

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

7.7 что делаем в пилоте, чтобы не утонуть

В пилоте дедупликация должна быть “разумно ограниченной”:

·         Выберите один тип дублей, который реально мешает (например, контрагенты-дубли при заведении).

·         Настройте простое правило: “покажи похожие записи перед созданием”.

·         Введите ручную очередь на склейку, чтобы не сломать историю автоматикой.

·         Нормализуйте хотя бы 2-3 поля, которые дают максимум эффекта (телефон, адрес, единицы).

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

8. как раздавать «истину» в системы-потребители и снова не получить 1001 справочник

Проблема “1001 справочник” появляется, когда вы навели порядок в одном месте, а дальше каждая система продолжила жить своей жизнью и править данные локально. На Хабре это часто описывают именно как ситуацию, где справочники размножаются и начинают спорить друг с другом.

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

Самый рабочий способ - договориться не “какая система главная”, а “кто отвечает за какую часть правды”.

Пример логики (как шаблон, не как закон):

·         Контрагенты. Реквизиты и юридические атрибуты ведём там, где их реально проверяют; контакты - там, где с ними работают; адреса - по правилам нормализации и с понятным владельцем.

·         Номенклатура. Код и единицы измерения - строго по правилам; характеристики - в полях; маркетинговые описания могут жить отдельно, если они не участвуют в учёте.

Это снимает вечный спор “где главный справочник” и заменяет его на понятный вопрос: “кто отвечает за поле X”.

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

Если в системе-потребителе можно править мастер-данные как попало, вы гарантированно вернётесь к дублям.

Обычно делают так:

·         В системах-потребителях мастер-данные доступны “только для чтения” или “для чтения + заявка на изменение”.

·         Изменения идут через один процесс: заявка -> проверка -> публикация -> распространение.

Это дисциплина, которая сначала раздражает, а потом экономит кучу времени на сверках.

8.3 три базовых способа раздачи мастер-данных

Не выбирайте “самый модный”. Выбирайте то, что переживёт вашу реальность: разные системы, разные команды, разные сроки.

1.       Пакетная синхронизация (по расписанию)
Подходит для начала и для “тяжёлых” систем. Минус - задержка, плюс - простота и предсказуемость.

2.      Событийная раздача (изменения улетают сразу)
Хорошо для процессов, где важно быстрое обновление. Минус - сложнее отлаживать, нужен порядок в версиях и повторной доставке.

3.      API по запросу (система спрашивает “дай актуальное”)
Удобно, когда потребителей мало или данные нужны точечно. Минус - если потребители начнут кешировать “как им удобно”, вы снова получите расхождения.

На практике часто получается гибрид: критичное раздаём быстро, остальное - пакетами.

8.4 “контракт данных”: что именно вы отдаёте и в каком виде

Самая частая причина проблем - вы отдаёте “как получилось”, а потребитель ждёт “как у него заведено”.

Нужен простой контракт:

·         Какие поля есть у сущности (минимальный набор).

·         Какие поля обязательны.

·         Какие значения допустимы (списки, форматы).

·         Как кодируются статусы и справочники значений.

·         Как выглядит “удаление” (обычно это не удаление, а “не использовать”).

Отдельно важно решить: вы отдаёте “сырой текст” или нормализованный формат. Если нормализация у вас есть, её лучше делать централизованно, иначе каждый потребитель начнёт нормализовать по-своему.

8.5 версии и обратная совместимость: чтобы обновления не ломали интеграции

MDM живёт, правила меняются, поля добавляются, значения уточняются. Это нормально.

Чтобы не превращать каждое изменение в аварию:

·         Добавляйте поля без удаления старых, пока потребители не переедут.

·         Меняйте справочники значений через “новое значение + период поддержки старого”.

·         Фиксируйте версии контракта и дату, когда старое перестанет поддерживаться.

Это скучная инженерия, но она спасает от “всё сломалось после обновления справочника”.

8.6 подключение нового потребителя: процедура вместо героизма

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

Сделайте короткую процедуру:

1.       Новый потребитель описывает, какие сущности и поля ему нужны.

2.      Сверяем с контрактом: что берём как есть, что добавляем, что запрещаем локально править.

3.      Поднимаем тестовую синхронизацию на ограниченном наборе данных.

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

5.       Запускаем в прод и включаем мониторинг расхождений.

Ключевой момент - подключение не должно менять правила “на лету”. Иначе вы сломаете дисциплину ради одной системы.

8.7 анти-паттерны, которые почти гарантированно вернут хаос

·         “Пусть потребитель хранит свою копию и правит, как хочет, а мы потом разберёмся”.

·         “Давайте маппить по названию, так быстрее”.

·         “У нас есть таблица соответствий в Excel, она и есть интеграция”.

·         “Удалим дубль, чтобы не мешал” (без правил истории и связей).

·         “У каждого отдела свой справочник, зато им удобно”.

Это быстрые решения, которые создают долг. Потом он возвращается в виде падений интеграций и вечных сверок.

 

9. KPI для руководителя: как измерять прогресс, а не “ощущения”

MDM легко превратить в бесконечный разговор “стало лучше”. Чтобы этого не было, нужны метрики, которые понятны бизнесу и которые можно обновлять регулярно. Если вы внедряете ERP или строите сквозные процессы, качество данных почти всегда всплывает как один из ключевых факторов успеха, поэтому KPI по НСИ лучше завести раньше, чем позже.

9.1 правило хорошей метрики

Хорошая метрика отвечает на три вопроса:

·         Что именно мы улучшаем.

·         Как мы это считаем.

·         Что будет считаться “нормой”, и кто отвечает за отклонения.

Если метрику нельзя посчитать без ручного опроса “ну как оно”, она будет жить ровно до первого аврала.

9.2 качество справочника (главный блок)

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

·         Дубли. Количество дублей на 1000 записей (или доля дублей в справочнике), отдельно по “критичным” типам (контрагенты, номенклатура).

·         Полнота. Доля записей, у которых заполнены MVP-поля (например, для контрагентов это идентификатор по вашим правилам, тип, минимальный адрес; для номенклатуры это код, единица, категория).

·         Валидность формата. Доля записей, прошедших проверку формата (телефон, email, единицы измерения, классификаторы, длины полей).

·         Единообразие. Доля записей, которые соответствуют шаблону именования (особенно для номенклатуры и подразделений).

·         “Мусор”. Количество записей, помеченных как “черновик” дольше X дней, и количество записей со статусом “не использовать”, которые всё равно всплывают в операциях.

Как это читать руководителю: если полнота и валидность растут, а дубли падают, вы реально перестаёте разносить хаос по системам.

9.3 скорость и предсказуемость изменений

Эти метрики отвечают на вопрос “MDM помогает бизнесу или стал бюрократией”.

·         Время заведения записи “до рабочего состояния”. Сколько времени проходит от запроса до статуса “проверено”.

·         Время изменения критичного поля. Например, реквизиты контрагента или единица измерения у товара.

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

·         Очередь на обработку. Сколько заявок висит у ответственного и сколько из них просрочены.

Как это читать: MDM должен ускорять работу на дистанции. Если “качество растёт”, но “время изменений” взлетело, бизнес начнёт обходить процесс.

9.4 эффект на процессы (самое убедительное для бизнеса)

Это метрики “про деньги и нервы”, которые проще всего защищать на руководящих встречах.

Выберите 2-3 процесса, где НСИ реально влияет, и меряйте:

·         Закупки. Доля возвратов/ошибок из-за неверных реквизитов или номенклатуры.

·         Склад и логистика. Количество ошибок отгрузки/приёмки из-за неверной номенклатуры или адреса, процент доставок “с уточнением адреса”.

·         Финансы и документы. Количество исправлений документов по причине данных контрагента, доля ручных правок в первичке.

·         Поддержка и операции. Сколько обращений в поддержку связано с “не нашли контрагента/товар/подразделение”.

Как это читать: когда падают ошибки в конкретном процессе, спор “зачем MDM” заканчивается сам.

9.5 здоровье интеграций (чтобы перестать “чинить”)

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

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

·         Количество исключений и “костылей”. Сколько ручных таблиц соответствий, сколько специальных правил в интеграциях (и как меняется число).

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

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

9.6 минимальный дашборд (чтобы начать без бюрократии)

Если начинать “по-взрослому”, но без лишних ритуалов, хватит одного листа на месяц:

·         3 метрики качества (дубли, полнота MVP, валидность формата).

·         2 метрики скорости (время до “проверено”, просроченные заявки).

·         1 метрика эффекта (ошибки в выбранном процессе или инциденты интеграций из-за НСИ).

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

 

 

10. типовые ошибки внедрения MDM/НСИ и как их обойти

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

10.1 старт “сразу со всего”

Когда команда пытается одновременно привести в порядок контрагентов, номенклатуру, адреса, оргструктуру и ещё десяток классификаторов, проект превращается в бесконечный фронт работ.

Как обойти:

·         Один справочник, один процесс, 10-20 правил, 1-2 системы-потребителя.

·         Чёткая граница “что в этом квартале не трогаем”.

10.2 “сначала купим систему, потом разберёмся”

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

Как обойти:

·         Сначала владелец данных и правила, потом выбор инструмента.

·         На пилоте можно обойтись без “большой MDM-платформы”, но нельзя обойтись без правил.

10.3 нет владельца справочника

Когда у справочника нет хозяина со стороны бизнеса, любое спорное поле превращается в переписку “пусть ИТ решит”. ИТ начинает принимать смысловые решения, а потом крайними остаются все.

Как обойти:

·         Назначить владельца домена данных (контрагенты, номенклатура и т.д.).

·         Зафиксировать: какие решения он принимает, а какие делегирует ответственному за ведение.

10.4 правила есть, исполнения нет

Регламент “заполняйте аккуратно” не работает. Работает только то, что проверяется при вводе и в потоке изменений.

Как обойти:

·         Встроить проверки в точку создания и изменения.

·         Ввести статусы “черновик - проверено”, чтобы мусор не разъезжался по системам.

10.5 борьба с дублями через удаление

Удалили дубль - сломали историю, ссылки, документы, отчёты. Потом появляются “странные” провалы, и команда начинает бояться чистки.

Как обойти:

·         Объединять, а не удалять: “выжившая” запись + статусы “не использовать” + сохранение истории объединений.

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

10.6 интеграции как “место правды”

Когда интеграция начинает исправлять данные на лету (замены, угадывание, ручные маппинги), она становится вторым справочником. В итоге вы снова получаете “1001 справочник”, только часть живёт в коде. Тему разрастания справочников в MDM часто описывают именно в таком ключе - “у каждого своя версия”.

Как обойти:

·         Исправления и нормализация - ближе к источнику истины, а не в каждом канале передачи.

·         Договориться о контракте данных и запрещать локальное редактирование критичных полей в потребителях.

10.7 MDM превращается в узкое горло

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

Как обойти:

·         Разделить изменения на “быстрые” и “контролируемые”.

·         Для быстрых - автоматические проверки, для контролируемых - очередь и понятный SLA.

10.8 нет метрик, поэтому нет управления

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

Как обойти:

·         Минимальный дашборд из 6 метрик (качество, скорость, эффект) и владелец каждой метрики.

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

 

 

11. план 30/60/90 дней для руководителя: как запустить MDM, чтобы он поехал

Ниже план, который работает, когда нет “большого проекта на два года”, зато есть реальная боль в справочниках и интеграциях.

первые 30 дней: договориться и остановить размножение хаоса

Цель месяца - перестать ухудшать ситуацию и зафиксировать базовые правила игры.

Что делаем:

·         Назначаем владельца домена (например, “контрагенты” или “номенклатура”) и ответственного за ведение.

·         Выбираем 1 справочник для старта и 1 процесс (обычно “создание записи”).

·         Описываем MVP: 10-20 обязательных полей и 5-10 правил качества, которые можно проверить.

·         Вводим простой порядок: где создаём запись, кто подтверждает, что делать при сомнениях.

·         Фиксируем “якорь” идентификации: по чему мы понимаем, что это один и тот же объект (и что считается дублем).

Артефакты на выходе:

·         Одна страница “как мы ведём справочник X”.

·         Список обязательных полей и правил.

·         Список точек входа: кто и откуда может создавать записи (чтобы потом закрывать лишние входы).

31-60 дни: сделать пилот, где правила реально исполняются

Цель второго месяца - чтобы правила перестали быть текстом и стали поведением системы и людей.

Что делаем:

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

·         Вводим статусы “черновик” и “проверено”, чтобы сырые записи не разъезжались по всем системам.

·         Настраиваем очередь на разбор дублей и спорных случаев (чётко: кто смотрит, за сколько, по каким правилам склеиваем).

·         Подключаем 1-2 системы-потребителя (самые важные), и запрещаем там локально править ключевые поля “как попало”.

Артефакты на выходе:

·         Рабочий пилотный процесс создания и изменения записей.

·         Понятный маршрут “к кому идти, если надо изменить поле X”.

·         Первые метрики: дубли, полнота MVP-полей, время “от заявки до проверено”.

Отдельно: если параллельно идёт внедрение ERP или крупной интеграции, этот этап окупается особенно быстро, потому что качество данных прямо влияет на стабильность и сроки таких проектов.

61-90 дни: масштабировать без потери контроля

Цель третьего месяца - сделать так, чтобы MDM не был “пилотом на энтузиазме”, а стал нормальной частью операционной работы.

Что делаем:

·         Расширяем охват: ещё 1-2 потребителя, ещё 1 процесс (например, “изменение записи” или “объединение дублей”).

·         Нормализация превращается в конвейер: что проверяем при вводе, что чистим регулярно, какие поля нормализуем централизованно.

·         Вводим “контракт данных” на уровне здравого смысла: какие поля обязательны, какие значения допустимы, как выглядит “не использовать”, как обрабатываем изменения.

·         Закрепляем ежемесячный ритм: разбор метрик, топ-5 причин брака, обновление правил, обучение новичков.

Артефакты на выходе:

·         Регулярный процесс ведения справочника, который выдерживает отпуск ответственного.

·         Дашборд из 6 метрик (качество, скорость, эффект), владелец каждой метрики и действие “что делаем, если стало хуже”.

·         Снижение “ремонта интеграций” как класса задач: меньше исключений, меньше ручных таблиц соответствий, меньше “угадываний”.

Я отношусь к MDM просто: это дисциплина, которая превращает справочники из “вечной боли” в нормальную инфраструктуру для роста. Чем раньше вы начнёте наводить порядок в НСИ, тем меньше будет ком проблем дальше - в интеграциях, отчётности, внедрениях и масштабировании.

Качество данных и справочников всплывает как критичный фактор особенно тогда, когда компания берётся за большие изменения вроде ERP и сквозных процессов: если НСИ не готова, проект почти неизбежно начинает буксовать на “мелочах”, которые внезапно становятся системными.

Владислав Прокопович