Единая карточка товара требует правил изменения и ответственности. Объясняем, что такое мастер-данные и как договориться о согласованных значениях.
Один товар может выглядеть по-разному в отделах
Представим условную компанию, продающую упаковку. Отдел закупок хранит товар как «коробка малая», склад — как «упаковка 20», а сайт показывает покупателю другое название. Разные названия могут быть оправданы задачами. Проблема начинается, если вес, размеры и признак снятия с продажи меняются независимо, а сотрудники не знают, каким сведениям доверять.
Мастер-данные описывают основные объекты бизнеса: например, клиентов, товары, поставщиков и места хранения. В объяснении IBM такие сведения отделены от событий вроде продаж и счетов. Для нашего случая карточка коробки описывает товар, а каждая его отгрузка — отдельное событие. Согласованное описание нужно разным операциям, которые ссылаются на этот товар.
Управление продолжается после первого объединения
Управление мастер-данными часто сокращают до MDM. В материале Oracle оно включает объединение, очистку, дополнение и согласование данных с приложениями. Это более широкая работа, чем однократное копирование нескольких таблиц. Если завтра размер упаковки изменится, нужно знать, кто подтверждает изменение и какие системы должны его получить.
Для условной компании предложим начать с одного типа объектов и небольшого набора важных полей. Например, у товара согласуем размеры, единицу измерения, допустимый статус и ответственного за описание. Необязательно сразу переносить все сведения компании в одну программу. Сначала полезно определить, какие данные должны быть согласованы и где они используются.
Общая запись нуждается в правилах выбора значений
Допустим, склад сообщил новый вес, а закупки сохранили прежний. Самая свежая запись не обязательно правильная: в одном случае речь может идти о товаре, в другом — о товаре вместе с транспортной упаковкой. Для нашего процесса сначала уточним смысл поля и единицы измерения. Затем назовём источник, которому доверяем именно по этому признаку.
Предложим сохранять основание исправления: кто подтвердил значение, когда оно применяется и как проверить результат. Если между отделами нет согласованного решения, общая карточка должна показывать необходимость разбора. Назначение ответственного за данные помогает определить, кто вправе принять решение. Техническое обновление поля лишь выполняет уже согласованное правило.
Разные представления могут оставаться разными
Для сайта нужно короткое название товара, для склада — удобное обозначение места и упаковки. В нашем примере не будем требовать один текст для всех задач. Важно сохранить связь этих представлений с общим объектом и договориться о тех характеристиках, которые обязаны совпадать. Тогда местная удобная подпись не подменяет согласованный размер или статус товара.
У общей записи также есть история. Если коробка изменилась, стоит решить, считается ли это новым товаром или новой версией описания прежнего. Старую отгрузку нельзя без обсуждения интерпретировать как поставку уже изменённой упаковки. Для учебного разбора достаточно назвать момент изменения и потребителей данных, которым потребуется объяснить его последствия.
Мастер-данные поддерживают отчёты, но не определяют любой показатель
Если товары правильно описаны и связаны, отчёт получает устойчивую опору для группировки. Однако правило выручки, учёт возвратов и момент признания продажи требуют собственных определений. Общая карточка товара не отвечает на все эти вопросы. О согласовании расчётов отдельно рассказывает материал про семантический слой, где поддерживают смысл показателей.
В условной проверке выберем один товар и проследим его описание в закупках, на складе и в отчёте. Назовём поля, которые должны совпадать, и допустимые различия. После одного согласованного изменения повторим проверку. Такой путь показывает, пользуются ли системы общим решением, вместо предположения, что опубликованный справочник уже автоматически обновил все приложения.
Первый результат — понятный порядок изменений
Для начала полезно собрать небольшую карточку процесса: какой объект описываем, какие поля согласуем, кто принимает решения, откуда приходят изменения и как узнают о них остальные. Эта работа не обещает мгновенно устранить все ошибки. Зато делает обсуждение конкретным: спор о размере упаковки получает владельца, источник подтверждения и понятную точку завершения.
Продолжить изучение устройства систем можно на программе «Архитектор данных». С общей ролью специалиста знакомит статья о работе архитектора данных. Для собственного учебного примера выберите один справочник и проверьте, кто сможет объяснить каждое изменение его важных полей.
