Что происходит, когда название товара в отделе продаж не совпадает с названием на складе, а в интернет-магазине до сих пор висит прошлогодняя фотография? Кто-то заказывает не тот товар. Покупатель запрашивает данные, которые никто не может найти, и сотрудники начинают проверять таблицы, старые письма, PDF-файлы поставщиков и пять разных систем, чтобы ответить на простой вопрос. Добро пожаловать в очередную порцию знаний от M365FM IoT MDMO Peters, и сегодня мы рассматриваем Dynamics 365 для управления информацией о продуктах, или сокращенно PIM. К концу вы поймете, как она поддерживает единую общую запись о продукте, как продукты могут принимать разные формы, и как эта информация доходит до тех подразделений бизнеса, которым она нужна. Одна запись о продукте для всей компании. Со стороны продукт может показаться простым. Только название, цена и, возможно, картинка. Но за кулисами этот же продукт затрагивает почти каждую часть компании. Вот как это происходит. Отделу закупок нужны данные о поставщиках и единице измерения, о складским командам, информация для приема, хранения и комплектации товаров. Отделу продаж нужны понятные названия. Финансовому отделу нужна правильная настройка, а интернет-магазину – точные фотографии и описания. Каждая команда смотрит на один и тот же продукт под своим углом. Без единого общего места для этой информации люди часто создают свои собственные копии. Команда по продукту ведет таблицу. Отдел продаж вводит более короткое название в свою систему. Склад использует номер позиции с другим описанием. Отдел маркетинга сохраняет изображение в общую папку, а служба поддержки клиентов роется в старых письмах. Такой подход сначала создает небольшие расхождения, а затем эти расхождения распространяются дальше. Представьте компанию, которая продает термобутылки. Поставщик меняет объем с 500 мл на 750 мл. Отдел закупок получает новые данные, но в интернет-магазине все еще указан старый объем. Отдел продаж отправляет клиентам неверную спецификацию, а складские работники видят этикетку товара, которая не соответствует заказу. Никто не хотел создавать проблему. Просто каждая команда работала со своей копией. Dynamics 365 для управления информацией о продуктах предоставляет компании единое центральное определение продукта. Думайте об этом как об общем картотечном шкафе для информации о товарах. Вместо того, чтобы каждый отдел вел свою папку, запись о продукте становится местом, где хранятся согласованные данные. Люди используют это определение в рабочих процессах. Они перепечатывают одну и ту же информацию снова и снова. Номер продукта занимает центральное место в этой записи. Он помогает компании идентифицировать продукт единообразно, даже если разные команды используют разные слова, говоря о немецком. Наряду с этим номером вы сохраняете название и описание, а также указываете, является ли это физическим товаром, который можно хранить, или услугой, которую предоставляет компания. Запись также включает единицы измерения, которые используются при покупке, продаже, хранении или учете продукта. Коробка, штука, килограмм, литр или палета могут означать совершенно разные вещи в повседневной работе. Когда эти единицы ясны, у отделов закупок и склада появляется гораздо лучшая отправная точка. Информация о продукте может также содержать изображения, вложения, категории, атрибуты и переводы названий и описаний. Таким образом, запись может содержать больше, чем просто этикетку. Она может хранить документ поставщика с описанием продукта, фотографию для его идентификации, переведенные описания для команд или клиентов, работающих на другом языке, а также такие детали, как материал, бренд или инструкции по обращению. Общее определение предшествует локальному использованию. Компания определяет продукт один раз, а затем позволяет различным подразделениям бизнеса использовать его по мере необходимости. Общая запись объединяет общие факты, в то время как каждое подразделение позже применяет свои собственные бизнес-настройки. Вам не нужно создавать продукт с нуля каждый раз, когда он требуется другой команде. Это гораздо более эффективный способ работы, но название и описание все равно не могут полностью раскрыть историю продукта. Одна пара джинсов может превратиться во множество позиций, как только учитываются цвет и размер. Основные записи продуктов и варианты – это семейное древо. Так когда же один продукт становится множеством продуктов? Подумайте о паре джинсов. Вы, вероятно, воспринимаете джинсы как один продукт, но на складе нельзя просто взять любую пару. Когда в заказе указаны черные джинсы большого размера. И отдел продаж не может обещать синие джинсы очень маленького размера, если такой комбинации на самом деле не существует. Именно здесь Dynamics 365 предлагает простую идею. Она отделяет базовый продукт от основного продукта. Простой продукт – это одна фиксированная позиция. Представьте обычную пачку бумаги для принтера, которая продается в одном размере, цвете и формате. Для нее создается отдельная запись продукта, поскольку нет выбора, который менял бы суть товара. Основной продукт работает иначе. Это родительская запись для целого семейства продуктов. В ней хранятся общие сведения и правила выбора, которые создают отдельные позиции. Вот как это работает. Основная запись джинсов содержит название, базовое описание и общую информацию для каждой пары в этой линейке. Затем отдельные варианты идентифицируют конкретные джинсы, которые кто-то покупает, хранит, производит или отгружает. Вариант – это конкретный товар, готовый к продаже. Для джинсов синий цвет и средний размер могут быть одним вариантом. Черный цвет и большой размер – другим. Они принадлежат к одному семейству продуктов, но не являются взаимозаменяемыми. Одни могут лежать на складской полке, в то время как другие могут закончиться. Одни могут иметь другую этикетку. У одних может быть свой собственный штрих-код. Структура «Родитель-потомок» – это ключевая идея. Мастер-продукт определяет семейство. Варианты продукта – это отдельные его представители. Вместо того, чтобы постоянно вводить одну и ту же базовую информацию, вы берете мастер-продукт и создаете реальные комбинации, необходимые вашему бизнесу. Позвольте привести конкретный пример. Представьте, что линейка джинсов представлена в синим, черном и коричневом цветах. Она также выпускается в размерах очень маленький, маленький, средний, большой, очень большой и двойной очень большой. Если бы каждый цвет был доступен в каждом размере, вы получили бы 18 комбинаций. Но компании редко продают все возможные комбинации. Возможно, синие джинсы бывают только от очень маленького до среднего размера. Черные – от среднего до очень большого. Коричневые начинаются с большого размера. Dynamics 365 может рассматривать каждую разрешенную комбинацию как отдельный вариант. Когда кто-то добавляет джинсы в заказ, он выбирает параметры, которые определяют конкретный товар. Цвет и размер сообщают системе, какой именно вариант нужен клиенту. Никаких гаданий о том, какая пара должна быть в коробке. Эти параметры называются измерениями продукта. Dynamics 365. Управление цепочками поставок включает пять из них. А именно – цвет, размер, стиль, конфигурация и версия. Компания выбирает измерения, подходящие для семейства продуктов, а затем группирует их для данного мастер-продукта. Давайте быстро пробежимся по ним. Цвет – это просто. Синий, черный, коричневый, красный. Размер также знаком каждому. Маленький, средний, большой или номер размера обуви. Стиль помогает различать продукты с одним названием, но разным внешним видом. Рубашка может быть стандартного кроя или приталенной. Стул может иметь стандартную раму или другую отделку. Конфигурация описывает выбранную сборку или настройки. Например, для станка может потребоваться определенный двигатель, напряжение или набор запчастей. Измерение, конфигурация – фиксирует этот выбор. Версия очлеживает изменения продукта с течением времени. Это наиболее важно для производителей. Представьте деталь, которая сохраняет свое назначение, но меняется после утвержденного инженерного обновления. Версия позволяет компании отличать первую версию от второй по мере продвижения по цепочке поставок. Конечно, не каждому мастер-продукту нужны все пять измерений. Для футболки могут потребоваться только цвет и размер. Для единицы оборудования могут понадобиться конфигурация и версия. Группа измерений действует как свод правил для семейства продукта. Она указывает Dynamics 365, какие параметры применять при создании и идентификации вариантов. Это решение определяет продукт с самого начала. Возможно, вы спросите о весе, высоте, длине, ширине или объеме. Эти данные описывают физические характеристики продукта, но не создают варианты. У пары джинсов может быть указан вес или размер упаковки, но это не превращает их в другой товар, в отличие от цвета или размера. Физические размеры описывают сам товар. Параметры продукта определяют конкретный вариант исполнения. Разделение этих двух понятий помогает избежать путаницы в будущем. Если складу нужно знать, сколько места занимает коробка, помогают физические размеры. Если в заказе нужны черные джинсы большого размера, определите нужный вариант. Есть одно важное решение, которое влияет на все последующее. Как компания будет создавать и контролировать эти варианты продуктов? И именно это мы сейчас обсудим. Настройка продуктов без создания хаоса. Выбор параметров сообщает Dynamics 365, как определять вариант. Но компании все равно нужно решить, как создавать эти варианты. Этот выбор зависит от самого продукта. Управление цепочками поставок поддерживает три основных подхода. Предопределенные варианты – конфигурация на основе параметров и конфигурация на основе ограничений. Названия звучат технически, поэтому позвольте объяснить их простыми словами. Предопределенные варианты подходят для продуктов с ограниченным набором комбинаций. Представьте того ретейлера, продающего линейку джинсов, которую мы обсуждали. Компания заранее знает, какие цвета и размеры она будет закупать, хранить и продавать. Синие доступны в размерах экстра малый, малый и средний. Черные – в среднем, большом и экстра большом. Коричневые – в большом, экстра большом и дважды экстра большом. Эти девять вариантов можно создать заранее как отдельные позиции. Бизнесу не нужны все возможные комбинации цветов и размеров. Он создает только те комбинации, которые существуют. Это сохраняет каталог в порядке и не дает заказать коричневые джинсы размера экстра малой, если их никто не производит. Предопределенные варианты хорошо работают, когда ассортимент предсказуем. Производитель одежды – дистрибьютор с фиксированными размерами упаковок, магазин стандартной мебели. Все они могут подготовить товары, с которыми планируют работать. Каждый вариант существует как известный элемент до поступления заказа, поэтому отделы закупок, склады и продаж работают с понятным ассортиментом. Следующий подход – конфигурация на основе параметров. Он часто встречается в производстве. Представьте компанию, которая создает промышленные насосы. В одном семействе насосов используются многие общие детали, но клиент может выбрать определенную конфигурацию. Этот выбор влияет на то, какие компоненты войдут в готовый насос. Dynamics 365 может использовать параметр конфигурации для управления этим. Продукт использует одну общую спецификацию материалов. Ее часто называют BOM – ведомость материалов. Спецификация материалов – это просто список запчастей для сборки изделия. Внутри этого списка некоторые детали применяются только тогда, когда клиент выбирает конкретную конфигурацию. Например, для насоса под одно напряжение может потребоваться один двигатель. Для другого напряжения нужен другой двигатель. Вместо того, чтобы ввести отдельный список запчастей для каждого возможного насоса, компания использует один общий список. В нем отмечается, какие позиции относятся к какой конфигурации. Когда выбранная конфигурация попадает в планирование или производство, Dynamics 365 использует только те комплектующие, которые соответствуют этому выбору. Это позволяет избежать дублирования настроек. Это также дает производителям более понятный способ управления семейством продуктов, которые имеют общую конструкцию, но различаются в заданных пределах. Размеры идентифицируют выбранный продукт. Спецификация материалов определяет, какие детали входят в эту сборку. Далее идет конфигурация на основе ограничений. Этот подход подходит для продуктов, где клиенты могут выбирать из множества опций. Но не каждая опция сочетается с любой другой. Представьте изготовленное на заказ оборудование, лабораторный прибор или изделие, собранное из множества деталей. Клиент может выбрать тип питания, корпус, двигатель, защитные опции и панель управления. Некоторые комбинации работают, а некоторые просто невозможны. Определенный корпус может не подойти для более крупного двигателя. Для одного напряжения может потребоваться конкретная панель управления. Защитный кожух может подходить только для одного размера оборудования. Без правил менеджер по продажам может выбрать комбинацию, которую завод не сможет собрать. ограничений закладывает эти правила в модель конфигурации продукта. Модель описывает возможные варианты выбора и правила, ограничивающие их. Когда пользователь настраивает продукт, система направляет его к допустимым опциям. Она предотвращает выбор параметров, которые конфликтуют друг с другом. Это останавливает невыполнимый заказ еще до того, как он поступит в производство. Я хочу остановиться здесь, так как это важное решение на раннем этапе проектирования. Компания должна выбрать технологию конфигурации, соответствующую ее бизнес-процессам, до начала разработки семейства продуктов. Dynamics 365 не позволяет в дальнейшем конвертировать продукт из одной модели конфигурации в другую. Поэтому ретейлеру с фиксированным ассортиментом не следует настраивать сложную модель пользовательской конфигурации только потому, что она звучит гибко. А производителю оборудования под заказ не стоит загонять все возможные сборки в длинный список предопределенных вариантов, если выбор зависит от правил. Начните с анализа реальных процессов покупки, продажи и производства. Задайте простой вопрос, знаем ли мы все комбинации продуктов до момента поступления заказа? Или клиент сам формирует выбор продукта из набора разрешенных опций? Ответ укажет бизнесу на правильный подход. Как только компания понимает, каким может быть продукт, ей нужно описать его четко и систематизировать эту информацию. Категории, атрибуты и контроль информации о продукте. Название продукта говорит о том, как он называется, но этого недостаточно для покупки, хранения, продажи или объяснения клиенту. Вот здесь на помощь приходят категории. Представьте категории, как отделы в хорошо организованном магазине. Компания может группировать продукты по их типу. Одежда в одном ряду, инструменты в другом, канцелярские товары, в третьем. Или их могут группировать по типу выполняемой работы. В любом случае цель одна и та же. Упростить поиск товаров и управление ими. Возьмем аккумуляторную дрель. Отделу продаж нужно найти ее в разделе электроинструментов. Отдел продукции может отнести ее к категории оборудования на аккумуляторах. И вот в чем дело. Один товар может находиться в нескольких категориях одновременно, если они отвечают разным бизнес-задачам. Смысл не в том, чтобы запихнуть каждый товар в одну идеальную папку. Категории дают бизнесу структурированный способ организации информации, поиска товаров и работы с группами связанных позиций. Они также помогают применять нужную информацию к товарам, которые относятся к одной группе. Категории делают многое, но они не могут содержать в себе все детали. Вот здесь на помощь приходят атрибуты. Для бутылки для воды атрибутами могут быть материал, объем, тип крышки, термоизоляция, бренд и инструкции по уходу. Для деталей механизма это могут быть габариты, требования к питанию, температурный диапазон или технический стандарт. Атрибуты превращают общее название в полезную информацию о продукте. Ту информацию, которая действительно нужна вам для работы. Категории могут содержать атрибуты, актуальные для товаров внутри них. Для одежды нужны ткань, крой и инструкции по стирке. Для электрооборудования нужны напряжение, условия гарантии и информация о совместимости. Это значит, что никому не нужно придумывать произвольные поля для каждой карточки товара. Они просто используют детали, подходящие для данной группы товаров. Изображения и вложения добавляют еще один уровень. Фотография помогает работнику склада, продавцу или клиенту увидеть товар, о котором идет речь. Вложение может содержать сопроводительные материалы, такие как документ от поставщика, спецификация или другие бумаги. Иногда одного лишь названия недостаточно. Переводы важны, когда компания работает с разными языками. Название и описание товаров можно перевести, чтобы люди на разных рынках получали понятную им информацию. Сам товар остается прежним, но описание может быть адаптировано под аудиторию. Компании также нужен контроль над тем, кто может изменять эту информацию. Не каждый сотрудник должен иметь возможность редактировать записи о товарах, переименовывать их или менять детали, от которых зависят другие команды. Dynamics 365 позволяет применять правила доступа к данным о товарах на уровне категории или для отдельного товара. Например, команда, отвечающая за промышленное оборудование, работает с этой категорией, а другая группа занимается потребительскими товарами. Ограниченный в обороте товар может требовать более строгого контроля, чем обычные констовары. Бизнес сам решает, кто может работать с каждой областью данных о своих продуктах. Это защищает информацию, на которую полагаются люди. Теперь в записи могут быть указаны правильные сведения, документы, категории и элементы управления. Но все еще требуется одобрение, прежде чем подразделения компаний, которые закупают, продают, хранят или производят товар, смогут его использовать. Выпуск продуктов для юридических лиц. Готовое определение продукта теперь автоматически готово к использованию всеми. О, еще нет. Компания часто работает через несколько юридических лиц, которые являются отдельными компаниями внутри более крупного бизнеса. Одно подразделение может закупать и хранить продукт в Германии. Другое продает тот же продукт в Соединенных Штатах. Третье производит его. Все они могут начать с одного и того же общего определения продукта. В Dynamics 365 это общее определение становится выпущенным продуктом, когда компания одобряет его для использования конкретным юридическим лицом. Рассматривайте выпуск как предоставление этому подразделению разрешения на использование продукта в его повседневной работе. Продукт не меняет своей идентичности. Его общее название, описание, категория, размеры и другие общие данные остаются связанными с центральным определением, но каждое юридическое лицо может добавить настройки, необходимые перед заказом, продажей, хранением или производством этого продукта. Одна компания может покупать продукт у поставщика, другая может только продавать его. Производственной компании нужны настройки производства, в то время как дистрибьюторской компании нужны настройки склада и запасов. Детали продаж различаются в зависимости от организации. Местные бизнес-правила также различаются. Выпуск позволяет каждому юридическому лицу подготовить продукт для своей работы без создания полностью отдельного определения продукта. Представьте компанию, которая продает одну и ту же бутылку воды в нескольких странах. Команда по продукту создает одно центральное определение продукта. Затем компания выпускает его для юридического лица в Великобритании. И это лицо добавляет настройки, необходимые для закупки и хранения бутылки. Позже тот же продукт выпускается для канадского юридического лица, где сотрудники завершают настройки для местных продаж и запасов. Обе компании используют один и тот же продукт. Им не нужно начинать все сначала с названия, описания и деталей семейства продуктов. Они дополняют только ту информацию, которая относится к их собственной организации. Такое разделение позволяет хранить общие данные и локальные рабочие процессы в нужном месте. Общее определение продукта отвечает на вопрос, что это за продукт, а выпущенный продукт отвечает на вопрос, как эта конкретная компания будет его использовать. Это небольшая разница в формулировке, но она предотвращает множество дублирующей работы, когда бизнес работает с несколькими юридическими лицами. Dynamics 365 может выпускать продукты для одного юридического лица или для нескольких одновременно. Это помогает, когда компания внедряет стандартный ассортимент продукции во многих бизнес-единицах. Тем не менее, выпуск теперь имитирует финальный шаг «нажал и забыл». Каждому юридическому лицу могут потребоваться дополнительные сведения, прежде чем его команды смогут работать с продуктом. Рабочая область «Обслуживание выпущенных продуктов» помогает контролировать этот процесс. Она показывает недавно выпущенные продукты и проверяет, завершена ли необходимая настройка для данного юридического лица. Если кому-то еще нужно добавить атрибуты продукта, категории, параметры заказа или переводы, рабочая область позволяет найти эту задачу и открыть нужные страницы продуктов. Она также помогает командам выявлять незавершенные задачи по изменению продуктов. Это важно, поскольку продукт может выглядеть готовым в центральном представлении, в то время как локальные настройки остаются незавершенными. Рабочая область предоставляет юридическому лицу практический список продуктов, требующих внимания, вместо того, чтобы заставлять людей просматривать длинные списки. Таким образом, выпуск не копирует продукт в отдельный мир. Он связывает одно утвержденное определение продукта с юридическим лицом, а затем дает этому лицу возможность применить свои собственные операционные детали. Как только это происходит, информация о продукте может использоваться в работе с заказами, запасами и потребностями клиентов. Итак, как PIM связывает работу вокруг продукта? Так как же управление информацией о продукте на самом деле связывает работу вокруг продукта? Вот самое простое определение. PIM не управляет каждым бизнес-процессом самостоятельно. Вместо этого он предоставляет информацию о продукте, необходимую для этих процессов. Представьте это как главный картотечный шкаф для данных о продуктах. Закупщику нужно найти правильный товар в заказе на закупку. Складской команде нужен правильный товар при получении или комплектации запасов. Отделу продаж нужны сведения о продукте для коммерческого предложения. И другим приложениям Dynamics 365 также могут потребоваться данные о продукте. PIM дает всем этим командам общую отправную точку, единый источник достоверной информации. Теперь, откуда берутся эти данные о продукте? Определения продуктов могут создаваться непосредственно в Dynamics 365 Supply Chain Management. Это хорошо работает, когда компания управляет информацией о продукте там с самого начала. Но многие предприятия уже используют другую систему для разработки продуктов или учета товаров. Например, данные о продукте могут поступать из системы управления жизненным циклом продукта, часто называемой PLM. Система PLM помогает командам управлять продуктом на этапе его проектирования и разработки. Существует также система управления данными о продуктах или PDM, которая обрабатывает данные о продуктах и сопутствующую документацию. Некоторые компании даже используют отдельную систему PIM, прежде чем информация о продукте попадает в управление цепочками поставок. Вот хорошая новость. Dynamics 365 может импортировать определения продуктов из этих систем. Это означает, что вам не нужно повторно вводить одни и те же сведения о продукте, только из-за того, что продукт переходит из стадии проектирования в стадию работы цепочки поставок. Supply Chain Management может стать местом, где хранятся основные данные о продуктах и для других экземпляров системы. Это важно для крупных компаний, использующих несколько экземпляров системы. Один экземпляр управляет центральными определениями продуктов, а затем экспортирует и импортирует эти данные в другие. Microsoft предоставляет сущности данных для такого обмена структурированные способы перемещения определенных данных между системами. Но это еще не все. Microsoft Dataverse расширяет этот путь распространения. Dataverse — это общая облачная служба данных Microsoft, используемая многими бизнес-приложениями. Управление цепочками поставок может экспортировать определения продуктов в Dataverse, а другие бизнес-приложения, такие как Dynamics 365 Sales, могут использовать эти данные о продуктах. Однако это не означает, что каждое приложение теперь выполняет одну и ту же работу. PIM организует и поддерживает информацию о продуктах. Dynamics 365 Sales отвечает за процессы продаж. Другие приложения выполняют свои задачи — обслуживание клиентов, коммерцию, финансы, производство или операционную деятельность. Они могут использовать соответствующие данные о продуктах, но каждое приложение сохраняет свое назначение. Давайте рассмотрим практический процесс. Команда по продукту создает или импортирует новые определения продукта. Бизнес выпускает его для тех юридических лиц, которым оно необходимо. Эти подразделения завершают свою локальную настройку. Отдел закупок может работать с утвержденной позицией. Сотрудники склада могут принимать и обрабатывать ее. Отдел продаж может использовать верный продукт, вместо того, чтобы создавать свою собственную версию. Результат проявляется в повседневных рабочих моментах. Покупатель заказывает нужный товар. Клиент видит верные сведения, а работник склада может сопоставить заказ с наличием товара перед собой. При изменении информации о продукте у команд есть четкий путь использования актуальных утвержденных данных, вместо поиска старых копий. Это сокращает количество ошибок при заказе, устаревшей информации и возвратов из-за неверных данных о продукте. Управление информацией о продуктах — это компонент, который обеспечивает упорядоченность определений, в то время как остальная часть платформы заставляет эту информацию работать. Вывод. Единая общая история продукта в Dynamics. Dynamics 365 Product Information Management превращает идею продукта в одну контролируемую запись, которую юридические лица и бизнес-команды могут использовать в своей работе. Это была ваша порция знаний на сегодня. Подписывайтесь на вашей любимой платформе подкастов и поделитесь этим с тем, кто изучает Dynamics 365. Затем переходите к следующему эпизоду, чтобы увидеть, как все строительные блоки соединяются воедино.