Привет, меня зовут Павел Кардаш, я IT-архитектор в «Магните» и занимаюсь управлением мастер-данными. Ранее я уже рассказывал о лучших практиках при работе с мастер-данными. В этой статье хочу поделиться, чем грамотно построенные процессы управления мастер-данными могут помочь продажам.
Что такое мастер-данные
Ответ хорошо изложен в статьях:
https://habr.com/ru/companies/navicon/articles/260927/
https://habr.com/ru/articles/324148/
https://habr.com/ru/articles/720738/
Если в магазине есть что-то особенное, это всегда дополнительный мотив для клиента купить именно там. Только наличия товара на складе или полке недостаточно: покупатель всё реже ищет товар «глазами».
Информация о товаре должна быть доступна для поиска, но в лучшем случае особые характеристики указываются в текстовом описании. Даже если для интересующего свойства сделали отдельное поле, то его заполняют левой задней пяткой без гарантий достоверности.
Давайте разберемся, почему так происходит и что с этим возможно предпринять.
Боль покупателя
Как ни удивительно, я тоже покупатель и лично не раз сталкивался с проблемами поиска особенного товара на различных площадках.
Например, всё большую популярность набирают оранжевые вина. Это вино из белых сортов винограда, но приготовленное по технологиям красного и от этого приобретающее золотистый оттенок и новые нотки вкуса. Но найти такую категорию или фильтр получилось только на ресурсах компаний, плотно специализирующихся на алкоголе.
Другой пример: при поиске смесителя в ванную мне был важен тип переключения между изливом и душем. Этот функционал бывает реализован дезертиром, переключателем, встроенным в кран или поворотом излива. Но поискать смеситель по типу переключения не получилось: даже в специализированном интернет-магазине если фильтр и есть, то качеством заполнения свойств товара никто не занимается. В результате куплен тот товар, по которому нашлась информация в сети: обзор блогера или подробное описание у производителя.
Почему «собака бывает кусачей», или как происходит, что свойства заполняются некорректно
Когда специалистам по мастер-данным приходит запрос на добавление нового свойства, срабатывает реализация процесса по умолчанию: руки сразу тянутся добавить атрибут. Реже встречается практика, когда добавляемые атрибуты структурированы, но всё так же неотделимо связаны с карточкой товара.
Добавлением товара обычно занимаются закупщики, но ассортимент канала продаж и сами продажи часто уже вне их ответственности. Разграничить ответственность владельцев информации на атрибутном уровне и обеспечить консистентное состояние свойств товара при приемлемых сроках заведения новой карточки — задача нетривиальная. В результате ответственность за весь состав навешивается на закупщиков, которые часто не замотивированы разбираться в тонкостях потребительских свойств и бороться за качество заполнения: у них и без этого хватает задач.
Ещё потребительские свойства совсем не нужны, например, бухгалтерам и логистам. Приходится либо загружать лишнюю информацию в профильные системы, либо на интеграционном слое срезать лишнее. Если при этом интеграция сделана без учёта возможных расширений атрибутов, то при добавлении новых свойств «вздрагивают» связанные системы.
Как там у Чернышевского, или что с этим делать
Хорошее решение такой проблематики: выделение доменов мастер-данных, создание для разных доменов своих связанных сущностей с недублирующимися атрибутами.
Например, выделение набора потребительских свойств в отдельный связанный с товаром объект позволяет:
Организовать связанные, но не блокирующие друг друга процессы заведения и изменения свойств, принадлежащих разным доменам.
Сформировать не конфликтующие наборы правил качества данных. Разнести по времени заполнение блокирующих характеристик на этапе закупки и на этапе включения в ассортимент. Ускорить процесс ввода новых позиций.
Разделить ответственность подразделений за набор базовых (ключевых) характеристик и пользовательских свойств. Улучшить качество информации за счёт заполнения заинтересованными в результате сотрудниками.
Если специфика компании требует (читай: если в компании не в курсе значения термина «омниканальность») — развести свойства товара для отдельных каналов продаж.
При необходимости даже развести ведение карточки товара и потребительских свойств в разные системы. Не могу и не стану никому рекомендовать такую реализацию, но ситуации бывают разные.
И что же с логистами?
Раз упомянул логистов, стоит сказать, что у товара должно быть ровно одно логистическое свойство: связь с видами упаковки, в которой он транспортируется. Вес, габариты, количество единиц в коробке, условия перевозки (температура, хрупкость, вертикальная ориентация, возможность штабелирования) — это всё свойства упаковки. Логистика возит упаковку, не товар!
А бухгалтеры?
Вообще придумана такая мощная вещь, как «Правила продажи»: сущность, связанная с товаром, рынком, объектом продажи. Правила могут иметь срок действия и дату начала. Их можно классифицировать, чтобы разделить правила бухгалтерского учёта продаж, правила взаимодействия с ГИС при продажах, временны́е и вре́менные ограничения продаж, правила выкладки товара в офлайн-магазине.
Но это уже не мастер-данные, а настройки бизнес-процессов. Главное обеспечить для них связанность с мастер-данными и ни в коем случае не копировать них значения из карточки товара.
Итог
Управление мастер данными редко имеет прямое прослеживаемое влияние на бизнес, достаточное для финансового обоснования эффективности переустройства модели данных или даже обновления средств автоматизации. Выстроить цепочку от модели мастер-данных до результатов продаж сложно и, если в компании нет выделенного бюджета «на модернизацию ИТ», то выявленные проблемы ложатся в ящик отложенным долгом. Цена ошибки проектирования модели растёт. Вместе с ней всегда растёт стоимость устранения, так как данные обрастают потребителями. Чтобы не попасть в этот замкнутый круг, есть принцип:
Хорошее архитектурное решение не отрезает путь к новым возможностям, возникающим при росте бизнеса.
А если ресурса на качественную проработку архитектуры мастер-данных не выделили, то «всё придумано до нас» – есть референсные модели данных, где учтены множество потребностей. Я всегда призываю сверяться с ними перед любыми изменениями. Например, для розничной торговли мне нравится очень хорошо проработанная модель от Association for Retail Technology Standards.
