Типичные ошибки при старте проектов по НСИ и внедрению MDM

Типичные ошибки при старте проектов по НСИ и внедрению MDM
Изображение AI
Почему даже после внедрения MDM компании продолжают сталкиваться с дубликатами, устаревшими записями и ошибками в справочниках? Какие просчеты на старте проекта приводят к дополнительным расходам, затягивают внедрение и мешают использовать новые данные?

Мастер-данные — это не «все справочники»

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

И что важно! За такой услугой приходят компании, которые 10 лет назад уже справочники централизовали. Почему? Методика устарела, система требует замены, данные так или иначе стали неактуальными, а их вывод из оборота не прорабатывали.

Любой проект по НСИ начинается с проблематики, которая не позволяет бизнесу решать стратегические задачи. Мы работаем с производственными компаниями и для них, как правило, самый ценный справочник – справочник МТР (материально-технических ресурсов). Он самый сложный по структуре, логике и времени, стоимости для приведения в порядок. На примерах внедрения справочников МТР мы будем говорить о проблемах и общих проблемах любого бизнеса.

Следующий по ценности – справочник контрагентов. Он важный, даже порой критически важный (оплата не тому контрагенту может быть серьёзной ошибкой), но в разработке простой и понятный. Для его актуализации не нужны специальные экспертные знания.

И ещё есть много разных небольших справочников (до 1000 хранимых значений). Если подходить к вопросу централизации всех справочников внутри большой компании и переводу их в один сервис ведения/управления (MDM), то наберётся от 50 до 150 штук.

Первый вопрос, который себе бизнес должен задать: «А действительно ли все справочники должны вестись централизованно? Или допустимо, чтобы часть из них осталась локальными и жила в своих системах?». И только ответив на этот вопрос, стоит идти дальше.

Основной акцент стоит сделать на справочниках, которые потребляются несколькими участниками. Как уже писала выше, самый ценный и самый используемый – справочник МТР. Его актуализация и структурирование – серьёзная потенциальная экономия. Все хотят знать: какую именно экономию даёт нормализованный справочник МТР. Но тут важно не его наличие в компании, а то, как под него адаптированы процессы. Как он будет использоваться, так он и будет работать.

С чего начинать?

Итак, решение о необходимости работ по НСИ принято, двигаемся дальше. На этом этапе детали, как правило, никто не прорабатывает. В основном известно: какие справочники нормализовываем (обычно МТР и контрагенты в фокусе), какими силами (сами или подрядчик), где дальше будем вести (в какой системе), бюджет на проект.

По нашей практике, мы видим, что очень часто при реализации проектов упускают ряд важных моментов. Самая распространённая ошибка – нет лидера проекта внутри компании. Без такого ответственного лица, погружённого во внутренние процессы реализовать проект успешно практически невозможно. Внутри компании заказчика должен быть человек, который умеет продвигать проект по этапам, вовремя сигнализировать о проблемах и собирать обратную связь. В одном из проектов на нас как на исполнителя возложили ответственность за сбор обратной связи с участников от заказчика по предметным запросам (это специалисты, которые детально знают область, для которой проводится закупка материалов той или иной категории). Объяснения, что данную функцию может выполнять только погружённый в особенности направления сотрудник компании, обладающий достаточным авторитетом, восприняты не были. Как итог, после двух эскалаций на ЛПР, такое лицо всё же было определено. Однако время было уже потрачено, а это ни много, ни мало 3 недели (с учётом определения ответственных лиц и получения результата от них). График по проекту мог существенно сдвинуться – избежать проблем удалось, потому что это был только первый, пробный, этап и риски подобного развития событий были уже заложены. Тем не менее, всё равно пришлось оптимизировать сроки на последующих этапах.

Вторая самая распространённая ошибка – на внедрение бюджет есть, на поддержку заказчик его не предусмотрел. А справочники – это навсегда. Многие справочники можно актуализировать и условно «забыть», управляя ими с минимальными трудозатратами, кроме справочника МТР. Он живой и самый динамично наполняемый и изменяемый. И команда для поддержки справочника около 300 000 позиций – это не меньше 5-6 человек. Здесь мы неоднократно сталкивались с ситуациями, когда утверждается штат 1-2 человека, а остальные эксперты берутся из подрядной организации. Бюджет на подрядчиков утверждается на 1-2 года, с перспективами, что объёмы работы уменьшатся и свой штат дальше справится самостоятельно. Реальность оказывается несколько другой. И спустя 2 года компания приходит к пониманию: собственный штат нужно увеличить в 2-3 раза. Существует ошибочное предположение, что после наполнения справочника данными, объёмы потребности для нормализации уменьшатся. Рынок очень динамичен, номенклатура всё время меняется и объёмы на нормализацию с годами не сильно сокращаются, зато добавляются новые задачи – корректировки, вывод номенклатуры из использования и иные операции для поддержания справочника в порядке.

Третий часто упускаемый момент – это команда участников.

Хороший справочник без экспертов компании не сделать. Ни один, даже самый именитый исполнитель, не знает особенностей компании лучше её сотрудников. Это не значит, что нужно нести весь накопленный опыт в новые справочники, но могут быть очень важные моменты, которые нельзя упустить! В проектную команду должны быть включены: технические эксперты по отраслям (особенно по критически важным номенклатурам); бухгалтерия, так как на структуру классификатора устанавливается, например, учёт; маркетологи, при условии, что им важно анализировать рынок через призму справочника; ИТ, чтобы вовремя сигнализировать по техническим ограничениям всех систем-участников и потребителей данных.

На одном из проектов, который шёл 8 месяцев, практически весь объём согласовывался и утверждался командой НСИ заказчика. У внутренней команды была очень большая экспертиза, но тем не менее в двух категориях экспертов всё же пришлось привлекать – это запорно-регулируемая арматура (ЗРА) и химия. Важно учитывать: сферы, требующие не просто опыта, но и специализированных знаний, без подключения узкопрофильных экспертов не сделать.

Описанные упущения – это то, про что забывают 90% клиентов.

Ответственный за результат важнее выбранной технологии

Если про лидера проекта, который следит за ходом этапов забывают, то про ключевого эксперта НСИ обычно помнят. Он несёт на себе груз принятия решений по качеству и структуре данных. Важно в период проработки в спокойном темпе написать Регламент управления справочником. Об этом документе тоже часто не задумываются, а он является ключевым. Без него справочник может превратиться в хаос уже через полгода после внедрения.

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

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

Идеально, если и качество, и система (как она должна работать) будут сосредоточены в одних руках.

«Золотая запись», дубликаты и структура данных – фундамент проекта НСИ

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

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

Также нередко встречается желание заказчика увидеть моментальный результат, например, запустив в эксплуатацию 1-2 проработанных категории. Но это так не работает, потому что процесс переключения на новые справочники меняет весь процесс использования работы. Ранее созданные сценарии должны быть отключены, а новые запущены. Сделать это только для части контента очень сложно и предполагает лишние затраты. Зато хорошо работает постепенное подключение филиалов и ДО. Сегодня один, завтра – другой.

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

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

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

Перенос данных в MDM: на что обратить внимание

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

Первичная загрузка данных – продумать, как данные забрать и какие дополнительные справочники могут потребоваться к заведению. Для МТР это классификатор, справочник атрибутов, справочник значений\словарей, справочник позиций в формате обезличенных, товарных и кратких. Нужно решить, как эти данные будут храниться и друг от друга зависеть. Это, пожалуй, основное техническое ограничение. В одном из проектов данные, которые мы нормализовали, загружались в МДМ-систему, внедряемую другим исполнителем. Было настроено ограничение, при котором словари значений для атрибутов может наполнять только администратор (фактически это 1 человек в команде). Через несколько месяцев такое ограничение пришлось снять и дать возможность наполнять словари значениями и другим ролям, так как администратор физически не успевал вносить все необходимые новые значения. Почему так вышло? С одной стороны, закрытые словари – это некая гарантия качества. Но с другой – это дополнительная точка проверки и как следствие дополнительные трудозатраты и дополнительное время, которое может увеличить срок появления в справочнике нужных объектов. Перенести остатки со старых записей на новые. Старые важно заблокировать, чтобы исключить параллельную работу.

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

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

Приведу пример из проекта. Клиент приобрёл новый актив с работающим справочником, который ранее мы разрабатывали. При этом в остальной компании справочника нет. Он есть с точки зрения «записали- оприходовали-списали», но нет его как целостной прослеживаемой сущности. Раз был приобретен актив со справочником МТР и услуг, то возникла потребность транслировать справочник на остальные общества. Технически ведение реализовано на нашей стороне, а по интеграции передаются уже нормализованные позиции и все изменения по структуре и шаблонам. То есть процесс выстроен технически стандартно, но он все время ломается на пользователях справочника. А происходит это потому, что справочник внедрили, а старые лазейки для создания записей в 1С, минуя нормализацию, не закрыли. Существовала такая ситуация около полугода пока её не обнаружили. После того как такая возможность была закрыта, появились другие проблемы. Пользователи очень часто хотят заводить позиции «как есть», возникает такая потребность потому, что товар уже куплен и есть на него накладная, следовательно, дальше он должен быть учтён так, как его приобрели. И поставщик требует в документах именно это наименование. Это проблема процесса, который не был адаптирован под справочник. Компания ещё на пути к перестраиванию процессов. Успех очень сильно зависит от того, как сильно влияние лица, принимающего окончательные решения.

ИИ в MDM. Что реально работает, а что пока ручной труд

Справочники компании – это в 99% случаев закрытые данные со своей структурой и методологией. А значит, ИИ сможет работать только опираясь на тот опыт, который есть у самой компании.  Сейчас все говорят про ИИ, и все хотят максимально передать справочники на ведение ИИ-агентам. Мы пока не можем сказать, что смогли добиться 100% результата, который бы соответствовал нашим ожиданиям, и реализованных сценариев с высоким качеством на рынке тоже пока не видели. Неплохой результат мы получаем по автоматической классификации позиций. Но, увы, достоверность всё ещё не более 90%, то есть полностью уйти от ручного труда даже здесь пока не можем. Одна из причин – невысокое качество с контента, с которым мы работаем в проектах – он несистематизированный, нестандартизированный, разрозненный и не всегда актуальный, и полный. Если на входе данные недостаточные и противоречивые, то и результат от ИИ на выходе будет таким же.

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

Однако для первичной проработки справочников ИИ стал очень полезен. Понимая логику проекта НСИ, имея большой объём шаблонов и классификаторов, мы через ИИ создаём первичную структуру классификатора и проводим первичную классификацию по категориям. По нашим оценкам, достоверность при классификации пока получается на уровне 60%, но даже этот результат превращает несколько недель работы эксперта НСИ в 3-4 часа работы с ИИ-моделью.

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

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

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

Сколько времени нужно на проект по НСИ МТР?

Если уже проведён консалтинг, точно понятны объёмы и конечные точки, к которым стремимся прийти, то минимальный срок проекта – 3 месяца, даже если справочник небольшой (20-30 000 позиций). Есть этапы, которые должны быть пройдены: согласование классификатора и шаблонов с отраслевыми экспертами, первичные приёмки результатов нормализации и корректировка по итогам замечаний в том числе может отразиться и на методике. Так сказать, отладка и настройка.

Средний проект с номенклатурой 100-200 000 позиций – это не менее 6 месяцев. Важна ли отрасль в определении сроков? Нет. Важна зрелость внутри компании и понимание, какими процессы станут после внедрения новых централизованных справочников.

Опубликовано 16.10.2026

Похожие статьи