WEBVTT

00:00:00.000 --> 00:00:03.860
Что происходит, когда название товара в отделе продаж не совпадает с названием на складе,

00:00:03.940 --> 00:00:06.480
а в интернет-магазине до сих пор висит прошлогодняя фотография?

00:00:06.620 --> 00:00:08.100
Кто-то заказывает не тот товар.

00:00:08.260 --> 00:00:11.100
Покупатель запрашивает данные, которые никто не может найти,

00:00:11.340 --> 00:00:14.120
и сотрудники начинают проверять таблицы, старые письма,

00:00:14.400 --> 00:00:18.320
PDF-файлы поставщиков и пять разных систем, чтобы ответить на простой вопрос.

00:00:18.520 --> 00:00:23.500
Добро пожаловать в очередную порцию знаний от M365FM IoT MDMO Peters,

00:00:23.680 --> 00:00:28.320
и сегодня мы рассматриваем Dynamics 365 для управления информацией о продуктах,

00:00:28.320 --> 00:00:29.660
или сокращенно PIM.

00:00:29.660 --> 00:00:33.640
К концу вы поймете, как она поддерживает единую общую запись о продукте,

00:00:33.760 --> 00:00:35.680
как продукты могут принимать разные формы,

00:00:35.780 --> 00:00:39.260
и как эта информация доходит до тех подразделений бизнеса, которым она нужна.

00:00:39.380 --> 00:00:41.480
Одна запись о продукте для всей компании.

00:00:42.020 --> 00:00:44.200
Со стороны продукт может показаться простым.

00:00:44.360 --> 00:00:47.080
Только название, цена и, возможно, картинка.

00:00:47.240 --> 00:00:50.660
Но за кулисами этот же продукт затрагивает почти каждую часть компании.

00:00:50.920 --> 00:00:51.920
Вот как это происходит.

00:00:52.120 --> 00:00:54.760
Отделу закупок нужны данные о поставщиках и единице измерения,

00:00:54.920 --> 00:00:58.080
о складским командам, информация для приема, хранения и комплектации товаров.

00:00:58.080 --> 00:00:59.960
Отделу продаж нужны понятные названия.

00:01:00.140 --> 00:01:01.820
Финансовому отделу нужна правильная настройка,

00:01:01.980 --> 00:01:04.040
а интернет-магазину – точные фотографии и описания.

00:01:04.180 --> 00:01:06.680
Каждая команда смотрит на один и тот же продукт под своим углом.

00:01:06.860 --> 00:01:10.380
Без единого общего места для этой информации люди часто создают свои собственные копии.

00:01:10.560 --> 00:01:12.120
Команда по продукту ведет таблицу.

00:01:12.300 --> 00:01:14.860
Отдел продаж вводит более короткое название в свою систему.

00:01:15.060 --> 00:01:17.040
Склад использует номер позиции с другим описанием.

00:01:17.320 --> 00:01:19.460
Отдел маркетинга сохраняет изображение в общую папку,

00:01:19.660 --> 00:01:21.740
а служба поддержки клиентов роется в старых письмах.

00:01:21.860 --> 00:01:23.820
Такой подход сначала создает небольшие расхождения,

00:01:23.820 --> 00:01:25.920
а затем эти расхождения распространяются дальше.

00:01:26.060 --> 00:01:28.620
Представьте компанию, которая продает термобутылки.

00:01:28.740 --> 00:01:31.940
Поставщик меняет объем с 500 мл на 750 мл.

00:01:32.220 --> 00:01:33.900
Отдел закупок получает новые данные,

00:01:34.140 --> 00:01:36.440
но в интернет-магазине все еще указан старый объем.

00:01:36.600 --> 00:01:39.160
Отдел продаж отправляет клиентам неверную спецификацию,

00:01:39.360 --> 00:01:42.720
а складские работники видят этикетку товара, которая не соответствует заказу.

00:01:42.860 --> 00:01:44.400
Никто не хотел создавать проблему.

00:01:44.540 --> 00:01:46.720
Просто каждая команда работала со своей копией.

00:01:46.920 --> 00:01:49.700
Dynamics 365 для управления информацией о продуктах

00:01:49.700 --> 00:01:52.320
предоставляет компании единое центральное определение продукта.

00:01:52.320 --> 00:01:55.420
Думайте об этом как об общем картотечном шкафе для информации о товарах.

00:01:55.560 --> 00:01:57.400
Вместо того, чтобы каждый отдел вел свою папку,

00:01:57.620 --> 00:02:00.480
запись о продукте становится местом, где хранятся согласованные данные.

00:02:00.680 --> 00:02:02.960
Люди используют это определение в рабочих процессах.

00:02:03.200 --> 00:02:05.860
Они перепечатывают одну и ту же информацию снова и снова.

00:02:06.120 --> 00:02:08.680
Номер продукта занимает центральное место в этой записи.

00:02:08.840 --> 00:02:11.420
Он помогает компании идентифицировать продукт единообразно,

00:02:11.540 --> 00:02:14.460
даже если разные команды используют разные слова, говоря о немецком.

00:02:14.660 --> 00:02:17.000
Наряду с этим номером вы сохраняете название и описание,

00:02:17.140 --> 00:02:19.500
а также указываете, является ли это физическим товаром,

00:02:19.500 --> 00:02:22.220
который можно хранить, или услугой, которую предоставляет компания.

00:02:22.440 --> 00:02:23.980
Запись также включает единицы измерения,

00:02:24.120 --> 00:02:27.020
которые используются при покупке, продаже, хранении или учете продукта.

00:02:27.120 --> 00:02:31.340
Коробка, штука, килограмм, литр или палета могут означать совершенно разные вещи в повседневной работе.

00:02:31.440 --> 00:02:35.480
Когда эти единицы ясны, у отделов закупок и склада появляется гораздо лучшая отправная точка.

00:02:35.640 --> 00:02:39.360
Информация о продукте может также содержать изображения, вложения, категории,

00:02:39.500 --> 00:02:41.360
атрибуты и переводы названий и описаний.

00:02:41.520 --> 00:02:44.420
Таким образом, запись может содержать больше, чем просто этикетку.

00:02:44.560 --> 00:02:47.080
Она может хранить документ поставщика с описанием продукта,

00:02:47.080 --> 00:02:50.740
фотографию для его идентификации, переведенные описания для команд или клиентов,

00:02:50.940 --> 00:02:55.420
работающих на другом языке, а также такие детали, как материал, бренд или инструкции по обращению.

00:02:55.640 --> 00:02:57.980
Общее определение предшествует локальному использованию.

00:02:58.220 --> 00:03:01.500
Компания определяет продукт один раз, а затем позволяет различным подразделениям бизнеса

00:03:01.500 --> 00:03:02.800
использовать его по мере необходимости.

00:03:02.960 --> 00:03:05.880
Общая запись объединяет общие факты, в то время как каждое подразделение

00:03:05.880 --> 00:03:07.860
позже применяет свои собственные бизнес-настройки.

00:03:08.020 --> 00:03:11.940
Вам не нужно создавать продукт с нуля каждый раз, когда он требуется другой команде.

00:03:12.100 --> 00:03:15.840
Это гораздо более эффективный способ работы, но название и описание

00:03:15.840 --> 00:03:18.560
все равно не могут полностью раскрыть историю продукта.

00:03:18.680 --> 00:03:21.560
Одна пара джинсов может превратиться во множество позиций,

00:03:21.740 --> 00:03:23.540
как только учитываются цвет и размер.

00:03:23.740 --> 00:03:27.000
Основные записи продуктов и варианты – это семейное древо.

00:03:27.180 --> 00:03:30.020
Так когда же один продукт становится множеством продуктов?

00:03:30.140 --> 00:03:31.520
Подумайте о паре джинсов.

00:03:31.520 --> 00:03:33.920
Вы, вероятно, воспринимаете джинсы как один продукт,

00:03:34.000 --> 00:03:35.580
но на складе нельзя просто взять любую пару.

00:03:35.580 --> 00:03:37.980
Когда в заказе указаны черные джинсы большого размера.

00:03:38.020 --> 00:03:40.540
И отдел продаж не может обещать синие джинсы очень маленького размера,

00:03:40.600 --> 00:03:42.360
если такой комбинации на самом деле не существует.

00:03:42.460 --> 00:03:45.400
Именно здесь Dynamics 365 предлагает простую идею.

00:03:45.520 --> 00:03:47.800
Она отделяет базовый продукт от основного продукта.

00:03:47.920 --> 00:03:50.200
Простой продукт – это одна фиксированная позиция.

00:03:50.360 --> 00:03:52.360
Представьте обычную пачку бумаги для принтера,

00:03:52.500 --> 00:03:54.900
которая продается в одном размере, цвете и формате.

00:03:55.100 --> 00:03:57.820
Для нее создается отдельная запись продукта, поскольку нет выбора,

00:03:57.940 --> 00:03:59.000
который менял бы суть товара.

00:03:59.160 --> 00:04:00.680
Основной продукт работает иначе.

00:04:00.800 --> 00:04:03.280
Это родительская запись для целого семейства продуктов.

00:04:03.280 --> 00:04:05.500
В ней хранятся общие сведения и правила выбора,

00:04:05.660 --> 00:04:07.180
которые создают отдельные позиции.

00:04:07.360 --> 00:04:08.240
Вот как это работает.

00:04:08.460 --> 00:04:10.260
Основная запись джинсов содержит название,

00:04:10.540 --> 00:04:13.500
базовое описание и общую информацию для каждой пары в этой линейке.

00:04:13.680 --> 00:04:15.920
Затем отдельные варианты идентифицируют конкретные джинсы,

00:04:16.080 --> 00:04:18.520
которые кто-то покупает, хранит, производит или отгружает.

00:04:18.680 --> 00:04:20.680
Вариант – это конкретный товар, готовый к продаже.

00:04:20.840 --> 00:04:23.140
Для джинсов синий цвет и средний размер могут быть одним вариантом.

00:04:23.260 --> 00:04:24.880
Черный цвет и большой размер – другим.

00:04:24.980 --> 00:04:26.540
Они принадлежат к одному семейству продуктов,

00:04:26.640 --> 00:04:27.840
но не являются взаимозаменяемыми.

00:04:27.980 --> 00:04:29.220
Одни могут лежать на складской полке,

00:04:29.400 --> 00:04:30.660
в то время как другие могут закончиться.

00:04:30.660 --> 00:04:32.200
Одни могут иметь другую этикетку.

00:04:32.280 --> 00:04:33.900
У одних может быть свой собственный штрих-код.

00:04:34.000 --> 00:04:35.920
Структура «Родитель-потомок» – это ключевая идея.

00:04:36.060 --> 00:04:37.540
Мастер-продукт определяет семейство.

00:04:37.740 --> 00:04:39.780
Варианты продукта – это отдельные его представители.

00:04:39.960 --> 00:04:42.360
Вместо того, чтобы постоянно вводить одну и ту же базовую информацию,

00:04:42.460 --> 00:04:44.500
вы берете мастер-продукт и создаете реальные комбинации,

00:04:44.640 --> 00:04:45.700
необходимые вашему бизнесу.

00:04:45.780 --> 00:04:47.280
Позвольте привести конкретный пример.

00:04:47.440 --> 00:04:49.240
Представьте, что линейка джинсов представлена в синим,

00:04:49.400 --> 00:04:50.380
черном и коричневом цветах.

00:04:50.520 --> 00:04:52.160
Она также выпускается в размерах очень маленький,

00:04:52.160 --> 00:04:54.560
маленький, средний, большой, очень большой и двойной очень большой.

00:04:54.700 --> 00:04:56.560
Если бы каждый цвет был доступен в каждом размере,

00:04:56.640 --> 00:04:57.940
вы получили бы 18 комбинаций.

00:04:58.060 --> 00:05:00.160
Но компании редко продают все возможные комбинации.

00:05:00.340 --> 00:05:02.820
Возможно, синие джинсы бывают только от очень маленького до среднего размера.

00:05:02.900 --> 00:05:04.500
Черные – от среднего до очень большого.

00:05:04.660 --> 00:05:06.260
Коричневые начинаются с большого размера.

00:05:06.380 --> 00:05:09.720
Dynamics 365 может рассматривать каждую разрешенную комбинацию как отдельный вариант.

00:05:09.900 --> 00:05:11.220
Когда кто-то добавляет джинсы в заказ,

00:05:11.360 --> 00:05:13.580
он выбирает параметры, которые определяют конкретный товар.

00:05:13.720 --> 00:05:16.560
Цвет и размер сообщают системе, какой именно вариант нужен клиенту.

00:05:16.680 --> 00:05:18.940
Никаких гаданий о том, какая пара должна быть в коробке.

00:05:18.940 --> 00:05:21.260
Эти параметры называются измерениями продукта.

00:05:21.400 --> 00:05:22.700
Dynamics 365.

00:05:23.060 --> 00:05:25.500
Управление цепочками поставок включает пять из них.

00:05:25.620 --> 00:05:28.680
А именно – цвет, размер, стиль, конфигурация и версия.

00:05:28.860 --> 00:05:31.320
Компания выбирает измерения, подходящие для семейства продуктов,

00:05:31.500 --> 00:05:33.280
а затем группирует их для данного мастер-продукта.

00:05:33.420 --> 00:05:34.760
Давайте быстро пробежимся по ним.

00:05:34.900 --> 00:05:35.800
Цвет – это просто.

00:05:36.020 --> 00:05:37.920
Синий, черный, коричневый, красный.

00:05:38.060 --> 00:05:39.420
Размер также знаком каждому.

00:05:39.620 --> 00:05:42.340
Маленький, средний, большой или номер размера обуви.

00:05:42.500 --> 00:05:45.560
Стиль помогает различать продукты с одним названием, но разным внешним видом.

00:05:45.720 --> 00:05:47.900
Рубашка может быть стандартного кроя или приталенной.

00:05:47.900 --> 00:05:50.460
Стул может иметь стандартную раму или другую отделку.

00:05:50.600 --> 00:05:53.100
Конфигурация описывает выбранную сборку или настройки.

00:05:53.220 --> 00:05:56.980
Например, для станка может потребоваться определенный двигатель, напряжение или набор запчастей.

00:05:57.140 --> 00:05:59.520
Измерение, конфигурация – фиксирует этот выбор.

00:05:59.680 --> 00:06:02.060
Версия очлеживает изменения продукта с течением времени.

00:06:02.240 --> 00:06:03.960
Это наиболее важно для производителей.

00:06:04.120 --> 00:06:06.200
Представьте деталь, которая сохраняет свое назначение,

00:06:06.400 --> 00:06:08.380
но меняется после утвержденного инженерного обновления.

00:06:08.600 --> 00:06:12.640
Версия позволяет компании отличать первую версию от второй по мере продвижения по цепочке поставок.

00:06:12.760 --> 00:06:15.420
Конечно, не каждому мастер-продукту нужны все пять измерений.

00:06:15.420 --> 00:06:17.820
Для футболки могут потребоваться только цвет и размер.

00:06:17.960 --> 00:06:20.760
Для единицы оборудования могут понадобиться конфигурация и версия.

00:06:20.960 --> 00:06:23.700
Группа измерений действует как свод правил для семейства продукта.

00:06:23.860 --> 00:06:28.500
Она указывает Dynamics 365, какие параметры применять при создании и идентификации вариантов.

00:06:28.620 --> 00:06:30.740
Это решение определяет продукт с самого начала.

00:06:31.000 --> 00:06:34.700
Возможно, вы спросите о весе, высоте, длине, ширине или объеме.

00:06:34.820 --> 00:06:38.540
Эти данные описывают физические характеристики продукта, но не создают варианты.

00:06:38.660 --> 00:06:41.180
У пары джинсов может быть указан вес или размер упаковки,

00:06:41.300 --> 00:06:44.360
но это не превращает их в другой товар, в отличие от цвета или размера.

00:06:44.360 --> 00:06:46.400
Физические размеры описывают сам товар.

00:06:46.520 --> 00:06:49.100
Параметры продукта определяют конкретный вариант исполнения.

00:06:49.280 --> 00:06:52.120
Разделение этих двух понятий помогает избежать путаницы в будущем.

00:06:52.280 --> 00:06:56.560
Если складу нужно знать, сколько места занимает коробка, помогают физические размеры.

00:06:56.720 --> 00:07:00.340
Если в заказе нужны черные джинсы большого размера, определите нужный вариант.

00:07:00.560 --> 00:07:03.400
Есть одно важное решение, которое влияет на все последующее.

00:07:03.540 --> 00:07:06.700
Как компания будет создавать и контролировать эти варианты продуктов?

00:07:06.800 --> 00:07:08.380
И именно это мы сейчас обсудим.

00:07:08.580 --> 00:07:10.800
Настройка продуктов без создания хаоса.

00:07:10.800 --> 00:07:14.720
Выбор параметров сообщает Dynamics 365, как определять вариант.

00:07:14.880 --> 00:07:17.840
Но компании все равно нужно решить, как создавать эти варианты.

00:07:17.960 --> 00:07:19.760
Этот выбор зависит от самого продукта.

00:07:19.920 --> 00:07:23.100
Управление цепочками поставок поддерживает три основных подхода.

00:07:23.300 --> 00:07:28.160
Предопределенные варианты – конфигурация на основе параметров и конфигурация на основе ограничений.

00:07:28.340 --> 00:07:31.640
Названия звучат технически, поэтому позвольте объяснить их простыми словами.

00:07:31.800 --> 00:07:35.160
Предопределенные варианты подходят для продуктов с ограниченным набором комбинаций.

00:07:35.300 --> 00:07:38.280
Представьте того ретейлера, продающего линейку джинсов, которую мы обсуждали.

00:07:38.280 --> 00:07:41.520
Компания заранее знает, какие цвета и размеры она будет закупать, хранить и продавать.

00:07:41.700 --> 00:07:44.020
Синие доступны в размерах экстра малый, малый и средний.

00:07:44.160 --> 00:07:46.260
Черные – в среднем, большом и экстра большом.

00:07:46.380 --> 00:07:49.280
Коричневые – в большом, экстра большом и дважды экстра большом.

00:07:49.400 --> 00:07:52.240
Эти девять вариантов можно создать заранее как отдельные позиции.

00:07:52.460 --> 00:07:55.380
Бизнесу не нужны все возможные комбинации цветов и размеров.

00:07:55.460 --> 00:07:57.860
Он создает только те комбинации, которые существуют.

00:07:58.000 --> 00:08:03.240
Это сохраняет каталог в порядке и не дает заказать коричневые джинсы размера экстра малой, если их никто не производит.

00:08:03.400 --> 00:08:06.360
Предопределенные варианты хорошо работают, когда ассортимент предсказуем.

00:08:06.360 --> 00:08:11.100
Производитель одежды – дистрибьютор с фиксированными размерами упаковок, магазин стандартной мебели.

00:08:11.260 --> 00:08:14.020
Все они могут подготовить товары, с которыми планируют работать.

00:08:14.180 --> 00:08:20.600
Каждый вариант существует как известный элемент до поступления заказа, поэтому отделы закупок, склады и продаж работают с понятным ассортиментом.

00:08:20.760 --> 00:08:23.240
Следующий подход – конфигурация на основе параметров.

00:08:23.400 --> 00:08:24.960
Он часто встречается в производстве.

00:08:25.120 --> 00:08:27.640
Представьте компанию, которая создает промышленные насосы.

00:08:27.760 --> 00:08:32.260
В одном семействе насосов используются многие общие детали, но клиент может выбрать определенную конфигурацию.

00:08:32.260 --> 00:08:35.520
Этот выбор влияет на то, какие компоненты войдут в готовый насос.

00:08:35.680 --> 00:08:39.480
Dynamics 365 может использовать параметр конфигурации для управления этим.

00:08:39.600 --> 00:08:42.100
Продукт использует одну общую спецификацию материалов.

00:08:42.260 --> 00:08:44.460
Ее часто называют BOM – ведомость материалов.

00:08:44.560 --> 00:08:47.580
Спецификация материалов – это просто список запчастей для сборки изделия.

00:08:47.760 --> 00:08:52.380
Внутри этого списка некоторые детали применяются только тогда, когда клиент выбирает конкретную конфигурацию.

00:08:52.540 --> 00:08:55.800
Например, для насоса под одно напряжение может потребоваться один двигатель.

00:08:55.980 --> 00:08:57.920
Для другого напряжения нужен другой двигатель.

00:08:57.920 --> 00:09:02.720
Вместо того, чтобы ввести отдельный список запчастей для каждого возможного насоса, компания использует один общий список.

00:09:02.840 --> 00:09:05.560
В нем отмечается, какие позиции относятся к какой конфигурации.

00:09:05.720 --> 00:09:11.660
Когда выбранная конфигурация попадает в планирование или производство, Dynamics 365 использует только те комплектующие, которые соответствуют этому выбору.

00:09:11.740 --> 00:09:13.720
Это позволяет избежать дублирования настроек.

00:09:13.840 --> 00:09:20.040
Это также дает производителям более понятный способ управления семейством продуктов, которые имеют общую конструкцию, но различаются в заданных пределах.

00:09:20.180 --> 00:09:22.140
Размеры идентифицируют выбранный продукт.

00:09:22.400 --> 00:09:25.560
Спецификация материалов определяет, какие детали входят в эту сборку.

00:09:25.560 --> 00:09:27.800
Далее идет конфигурация на основе ограничений.

00:09:27.920 --> 00:09:31.320
Этот подход подходит для продуктов, где клиенты могут выбирать из множества опций.

00:09:31.480 --> 00:09:33.480
Но не каждая опция сочетается с любой другой.

00:09:33.640 --> 00:09:37.980
Представьте изготовленное на заказ оборудование, лабораторный прибор или изделие, собранное из множества деталей.

00:09:38.100 --> 00:09:42.240
Клиент может выбрать тип питания, корпус, двигатель, защитные опции и панель управления.

00:09:42.460 --> 00:09:45.120
Некоторые комбинации работают, а некоторые просто невозможны.

00:09:45.280 --> 00:09:47.780
Определенный корпус может не подойти для более крупного двигателя.

00:09:47.960 --> 00:09:50.440
Для одного напряжения может потребоваться конкретная панель управления.

00:09:50.640 --> 00:09:53.140
Защитный кожух может подходить только для одного размера оборудования.

00:09:53.140 --> 00:09:56.900
Без правил менеджер по продажам может выбрать комбинацию, которую завод не сможет собрать.

00:09:57.920 --> 00:10:01.980
ограничений закладывает эти правила в модель конфигурации продукта. Модель описывает возможные

00:10:01.980 --> 00:10:05.520
варианты выбора и правила, ограничивающие их. Когда пользователь настраивает продукт,

00:10:05.660 --> 00:10:08.820
система направляет его к допустимым опциям. Она предотвращает выбор параметров,

00:10:08.980 --> 00:10:11.960
которые конфликтуют друг с другом. Это останавливает невыполнимый заказ еще до того,

00:10:12.080 --> 00:10:15.640
как он поступит в производство. Я хочу остановиться здесь, так как это важное решение на раннем

00:10:15.640 --> 00:10:19.460
этапе проектирования. Компания должна выбрать технологию конфигурации, соответствующую ее

00:10:19.460 --> 00:10:24.220
бизнес-процессам, до начала разработки семейства продуктов. Dynamics 365 не позволяет в дальнейшем

00:10:24.220 --> 00:10:28.020
конвертировать продукт из одной модели конфигурации в другую. Поэтому ретейлеру с фиксированным

00:10:28.020 --> 00:10:31.760
ассортиментом не следует настраивать сложную модель пользовательской конфигурации только потому,

00:10:31.960 --> 00:10:36.440
что она звучит гибко. А производителю оборудования под заказ не стоит загонять все возможные сборки

00:10:36.440 --> 00:10:41.020
в длинный список предопределенных вариантов, если выбор зависит от правил. Начните с анализа реальных

00:10:41.020 --> 00:10:46.260
процессов покупки, продажи и производства. Задайте простой вопрос, знаем ли мы все комбинации продуктов

00:10:46.260 --> 00:10:51.000
до момента поступления заказа? Или клиент сам формирует выбор продукта из набора разрешенных опций?

00:10:51.000 --> 00:10:56.120
Ответ укажет бизнесу на правильный подход. Как только компания понимает, каким может быть продукт,

00:10:56.320 --> 00:11:01.500
ей нужно описать его четко и систематизировать эту информацию. Категории, атрибуты и контроль

00:11:01.500 --> 00:11:06.580
информации о продукте. Название продукта говорит о том, как он называется, но этого недостаточно

00:11:06.580 --> 00:11:11.780
для покупки, хранения, продажи или объяснения клиенту. Вот здесь на помощь приходят категории.

00:11:11.920 --> 00:11:16.280
Представьте категории, как отделы в хорошо организованном магазине. Компания может группировать

00:11:16.280 --> 00:11:20.980
продукты по их типу. Одежда в одном ряду, инструменты в другом, канцелярские товары,

00:11:20.980 --> 00:11:26.100
в третьем. Или их могут группировать по типу выполняемой работы. В любом случае цель одна и та же.

00:11:26.260 --> 00:11:30.520
Упростить поиск товаров и управление ими. Возьмем аккумуляторную дрель. Отделу продаж нужно

00:11:30.520 --> 00:11:34.340
найти ее в разделе электроинструментов. Отдел продукции может отнести ее к категории

00:11:34.340 --> 00:11:38.720
оборудования на аккумуляторах. И вот в чем дело. Один товар может находиться в нескольких

00:11:38.720 --> 00:11:44.180
категориях одновременно, если они отвечают разным бизнес-задачам. Смысл не в том, чтобы запихнуть

00:11:44.180 --> 00:11:49.160
каждый товар в одну идеальную папку. Категории дают бизнесу структурированный способ организации

00:11:49.160 --> 00:11:53.740
информации, поиска товаров и работы с группами связанных позиций. Они также помогают применять

00:11:53.740 --> 00:11:57.620
нужную информацию к товарам, которые относятся к одной группе. Категории делают многое,

00:11:57.780 --> 00:12:02.080
но они не могут содержать в себе все детали. Вот здесь на помощь приходят атрибуты. Для бутылки

00:12:02.080 --> 00:12:06.820
для воды атрибутами могут быть материал, объем, тип крышки, термоизоляция, бренд и инструкции

00:12:06.820 --> 00:12:11.820
по уходу. Для деталей механизма это могут быть габариты, требования к питанию, температурный диапазон

00:12:11.820 --> 00:12:16.460
или технический стандарт. Атрибуты превращают общее название в полезную информацию о продукте.

00:12:16.460 --> 00:12:21.260
Ту информацию, которая действительно нужна вам для работы. Категории могут содержать атрибуты,

00:12:21.480 --> 00:12:26.200
актуальные для товаров внутри них. Для одежды нужны ткань, крой и инструкции по стирке.

00:12:26.380 --> 00:12:30.760
Для электрооборудования нужны напряжение, условия гарантии и информация о совместимости. Это

00:12:30.760 --> 00:12:34.560
значит, что никому не нужно придумывать произвольные поля для каждой карточки товара. Они просто

00:12:34.560 --> 00:12:39.240
используют детали, подходящие для данной группы товаров. Изображения и вложения добавляют еще один уровень.

00:12:39.380 --> 00:12:43.680
Фотография помогает работнику склада, продавцу или клиенту увидеть товар, о котором идет речь.

00:12:43.680 --> 00:12:47.420
Вложение может содержать сопроводительные материалы, такие как документ от поставщика,

00:12:47.620 --> 00:12:52.280
спецификация или другие бумаги. Иногда одного лишь названия недостаточно. Переводы важны,

00:12:52.480 --> 00:12:56.460
когда компания работает с разными языками. Название и описание товаров можно перевести,

00:12:56.720 --> 00:13:00.440
чтобы люди на разных рынках получали понятную им информацию. Сам товар остается прежним,

00:13:00.620 --> 00:13:04.180
но описание может быть адаптировано под аудиторию. Компании также нужен контроль над тем,

00:13:04.360 --> 00:13:08.140
кто может изменять эту информацию. Не каждый сотрудник должен иметь возможность редактировать

00:13:08.140 --> 00:13:12.040
записи о товарах, переименовывать их или менять детали, от которых зависят другие команды.

00:13:12.040 --> 00:13:17.040
Dynamics 365 позволяет применять правила доступа к данным о товарах на уровне категории или для

00:13:17.040 --> 00:13:21.140
отдельного товара. Например, команда, отвечающая за промышленное оборудование, работает с этой

00:13:21.140 --> 00:13:25.300
категорией, а другая группа занимается потребительскими товарами. Ограниченный в обороте товар может

00:13:25.300 --> 00:13:29.680
требовать более строгого контроля, чем обычные констовары. Бизнес сам решает, кто может работать

00:13:29.680 --> 00:13:33.980
с каждой областью данных о своих продуктах. Это защищает информацию, на которую полагаются люди.

00:13:34.100 --> 00:13:37.820
Теперь в записи могут быть указаны правильные сведения, документы, категории и элементы управления.

00:13:37.820 --> 00:13:41.120
Но все еще требуется одобрение, прежде чем подразделения компаний, которые закупают,

00:13:41.120 --> 00:13:43.660
продают, хранят или производят товар, смогут его использовать.

00:13:43.840 --> 00:13:49.140
Выпуск продуктов для юридических лиц. Готовое определение продукта теперь автоматически готово

00:13:49.140 --> 00:13:54.000
к использованию всеми. О, еще нет. Компания часто работает через несколько юридических лиц,

00:13:54.160 --> 00:13:58.380
которые являются отдельными компаниями внутри более крупного бизнеса. Одно подразделение может

00:13:58.380 --> 00:14:02.440
закупать и хранить продукт в Германии. Другое продает тот же продукт в Соединенных Штатах.

00:14:02.580 --> 00:14:06.700
Третье производит его. Все они могут начать с одного и того же общего определения продукта.

00:14:06.700 --> 00:14:11.480
В Dynamics 365 это общее определение становится выпущенным продуктом, когда компания одобряет

00:14:11.480 --> 00:14:15.300
его для использования конкретным юридическим лицом. Рассматривайте выпуск как предоставление

00:14:15.300 --> 00:14:18.700
этому подразделению разрешения на использование продукта в его повседневной работе.

00:14:18.800 --> 00:14:22.840
Продукт не меняет своей идентичности. Его общее название, описание, категория,

00:14:22.980 --> 00:14:25.900
размеры и другие общие данные остаются связанными с центральным определением,

00:14:26.020 --> 00:14:29.200
но каждое юридическое лицо может добавить настройки, необходимые перед заказом,

00:14:29.320 --> 00:14:33.880
продажей, хранением или производством этого продукта. Одна компания может покупать продукт у поставщика,

00:14:33.880 --> 00:14:37.640
другая может только продавать его. Производственной компании нужны настройки производства,

00:14:37.820 --> 00:14:41.400
в то время как дистрибьюторской компании нужны настройки склада и запасов. Детали продаж

00:14:41.400 --> 00:14:45.240
различаются в зависимости от организации. Местные бизнес-правила также различаются.

00:14:45.460 --> 00:14:48.860
Выпуск позволяет каждому юридическому лицу подготовить продукт для своей работы без

00:14:48.860 --> 00:14:53.140
создания полностью отдельного определения продукта. Представьте компанию, которая продает одну и ту же

00:14:53.140 --> 00:14:57.020
бутылку воды в нескольких странах. Команда по продукту создает одно центральное определение

00:14:57.020 --> 00:15:01.900
продукта. Затем компания выпускает его для юридического лица в Великобритании. И это лицо добавляет

00:15:01.900 --> 00:15:06.500
настройки, необходимые для закупки и хранения бутылки. Позже тот же продукт выпускается для

00:15:06.500 --> 00:15:10.880
канадского юридического лица, где сотрудники завершают настройки для местных продаж и запасов.

00:15:11.000 --> 00:15:15.120
Обе компании используют один и тот же продукт. Им не нужно начинать все сначала с названия,

00:15:15.360 --> 00:15:19.660
описания и деталей семейства продуктов. Они дополняют только ту информацию, которая относится к их

00:15:19.660 --> 00:15:23.840
собственной организации. Такое разделение позволяет хранить общие данные и локальные рабочие процессы

00:15:23.840 --> 00:15:28.720
в нужном месте. Общее определение продукта отвечает на вопрос, что это за продукт, а выпущенный продукт

00:15:28.720 --> 00:15:32.680
отвечает на вопрос, как эта конкретная компания будет его использовать. Это небольшая разница

00:15:32.680 --> 00:15:36.540
в формулировке, но она предотвращает множество дублирующей работы, когда бизнес работает с

00:15:36.540 --> 00:15:41.380
несколькими юридическими лицами. Dynamics 365 может выпускать продукты для одного юридического лица

00:15:41.380 --> 00:15:45.520
или для нескольких одновременно. Это помогает, когда компания внедряет стандартный ассортимент

00:15:45.520 --> 00:15:50.980
продукции во многих бизнес-единицах. Тем не менее, выпуск теперь имитирует финальный шаг «нажал и забыл».

00:15:50.980 --> 00:15:54.800
Каждому юридическому лицу могут потребоваться дополнительные сведения, прежде чем его команды смогут

00:15:54.800 --> 00:15:59.040
работать с продуктом. Рабочая область «Обслуживание выпущенных продуктов» помогает контролировать

00:15:59.040 --> 00:16:03.300
этот процесс. Она показывает недавно выпущенные продукты и проверяет, завершена ли необходимая

00:16:03.300 --> 00:16:07.580
настройка для данного юридического лица. Если кому-то еще нужно добавить атрибуты продукта,

00:16:07.700 --> 00:16:12.360
категории, параметры заказа или переводы, рабочая область позволяет найти эту задачу и открыть

00:16:12.360 --> 00:16:16.920
нужные страницы продуктов. Она также помогает командам выявлять незавершенные задачи по изменению

00:16:16.920 --> 00:16:20.340
продуктов. Это важно, поскольку продукт может выглядеть готовым в центральном представлении,

00:16:20.540 --> 00:16:23.920
в то время как локальные настройки остаются незавершенными. Рабочая область предоставляет

00:16:23.920 --> 00:16:27.180
юридическому лицу практический список продуктов, требующих внимания, вместо того,

00:16:27.300 --> 00:16:31.360
чтобы заставлять людей просматривать длинные списки. Таким образом, выпуск не копирует продукт

00:16:31.360 --> 00:16:35.240
в отдельный мир. Он связывает одно утвержденное определение продукта с юридическим лицом,

00:16:35.260 --> 00:16:38.420
а затем дает этому лицу возможность применить свои собственные операционные детали.

00:16:38.560 --> 00:16:42.360
Как только это происходит, информация о продукте может использоваться в работе с заказами,

00:16:42.580 --> 00:16:46.900
запасами и потребностями клиентов. Итак, как PIM связывает работу вокруг продукта?

00:16:47.000 --> 00:16:50.680
Так как же управление информацией о продукте на самом деле связывает работу вокруг продукта?

00:16:50.680 --> 00:16:55.360
Вот самое простое определение. PIM не управляет каждым бизнес-процессом самостоятельно. Вместо

00:16:55.360 --> 00:16:58.920
этого он предоставляет информацию о продукте, необходимую для этих процессов. Представьте

00:16:58.920 --> 00:17:03.220
это как главный картотечный шкаф для данных о продуктах. Закупщику нужно найти правильный товар

00:17:03.220 --> 00:17:07.340
в заказе на закупку. Складской команде нужен правильный товар при получении или комплектации

00:17:07.340 --> 00:17:11.740
запасов. Отделу продаж нужны сведения о продукте для коммерческого предложения. И другим приложениям

00:17:11.740 --> 00:17:16.800
Dynamics 365 также могут потребоваться данные о продукте. PIM дает всем этим командам общую отправную точку,

00:17:16.800 --> 00:17:20.640
единый источник достоверной информации. Теперь, откуда берутся эти данные о продукте?

00:17:20.800 --> 00:17:24.880
Определения продуктов могут создаваться непосредственно в Dynamics 365 Supply Chain Management.

00:17:25.100 --> 00:17:28.900
Это хорошо работает, когда компания управляет информацией о продукте там с самого начала. Но

00:17:28.900 --> 00:17:32.540
многие предприятия уже используют другую систему для разработки продуктов или учета товаров.

00:17:32.680 --> 00:17:35.820
Например, данные о продукте могут поступать из системы управления жизненным циклом продукта,

00:17:35.980 --> 00:17:40.120
часто называемой PLM. Система PLM помогает командам управлять продуктом на этапе его проектирования

00:17:40.120 --> 00:17:43.720
и разработки. Существует также система управления данными о продуктах или PDM, которая обрабатывает

00:17:43.720 --> 00:17:46.920
данные о продуктах и сопутствующую документацию. Некоторые компании даже используют отдельную

00:17:46.920 --> 00:17:50.040
систему PIM, прежде чем информация о продукте попадает в управление цепочками поставок.

00:17:50.160 --> 00:17:54.580
Вот хорошая новость. Dynamics 365 может импортировать определения продуктов из этих систем.

00:17:54.740 --> 00:17:57.160
Это означает, что вам не нужно повторно вводить одни и те же сведения о продукте,

00:17:57.220 --> 00:18:00.060
только из-за того, что продукт переходит из стадии проектирования в стадию работы цепочки поставок.

00:18:00.160 --> 00:18:03.960
Supply Chain Management может стать местом, где хранятся основные данные о продуктах и для других

00:18:03.960 --> 00:18:07.920
экземпляров системы. Это важно для крупных компаний, использующих несколько экземпляров системы.

00:18:07.920 --> 00:18:11.940
Один экземпляр управляет центральными определениями продуктов, а затем экспортирует и импортирует

00:18:11.940 --> 00:18:16.020
эти данные в другие. Microsoft предоставляет сущности данных для такого обмена структурированные

00:18:16.020 --> 00:18:20.400
способы перемещения определенных данных между системами. Но это еще не все. Microsoft Dataverse

00:18:20.400 --> 00:18:24.580
расширяет этот путь распространения. Dataverse — это общая облачная служба данных Microsoft,

00:18:24.820 --> 00:18:28.340
используемая многими бизнес-приложениями. Управление цепочками поставок может экспортировать

00:18:28.340 --> 00:18:32.060
определения продуктов в Dataverse, а другие бизнес-приложения, такие как Dynamics 365 Sales,

00:18:32.260 --> 00:18:35.540
могут использовать эти данные о продуктах. Однако это не означает, что каждое приложение теперь

00:18:35.540 --> 00:18:39.380
выполняет одну и ту же работу. PIM организует и поддерживает информацию о продуктах.

00:18:39.500 --> 00:18:44.080
Dynamics 365 Sales отвечает за процессы продаж. Другие приложения выполняют свои задачи — обслуживание

00:18:44.080 --> 00:18:47.500
клиентов, коммерцию, финансы, производство или операционную деятельность. Они могут использовать

00:18:47.500 --> 00:18:50.320
соответствующие данные о продуктах, но каждое приложение сохраняет свое назначение.

00:18:50.480 --> 00:18:53.820
Давайте рассмотрим практический процесс. Команда по продукту создает или импортирует

00:18:53.820 --> 00:18:57.580
новые определения продукта. Бизнес выпускает его для тех юридических лиц, которым оно необходимо.

00:18:57.780 --> 00:19:01.460
Эти подразделения завершают свою локальную настройку. Отдел закупок может работать с утвержденной

00:19:01.460 --> 00:19:05.100
позицией. Сотрудники склада могут принимать и обрабатывать ее. Отдел продаж может использовать

00:19:05.100 --> 00:19:08.440
верный продукт, вместо того, чтобы создавать свою собственную версию. Результат проявляется

00:19:08.440 --> 00:19:12.300
в повседневных рабочих моментах. Покупатель заказывает нужный товар. Клиент видит верные

00:19:12.300 --> 00:19:15.600
сведения, а работник склада может сопоставить заказ с наличием товара перед собой.

00:19:15.740 --> 00:19:19.660
При изменении информации о продукте у команд есть четкий путь использования актуальных утвержденных

00:19:19.660 --> 00:19:24.680
данных, вместо поиска старых копий. Это сокращает количество ошибок при заказе, устаревшей информации

00:19:24.680 --> 00:19:29.160
и возвратов из-за неверных данных о продукте. Управление информацией о продуктах — это компонент,

00:19:29.160 --> 00:19:32.900
который обеспечивает упорядоченность определений, в то время как остальная часть платформы

00:19:32.900 --> 00:19:37.140
заставляет эту информацию работать. Вывод. Единая общая история продукта в Dynamics.

00:19:37.300 --> 00:19:41.680
Dynamics 365 Product Information Management превращает идею продукта в одну контролируемую запись,

00:19:41.860 --> 00:19:44.640
которую юридические лица и бизнес-команды могут использовать в своей работе.

00:19:44.760 --> 00:19:48.040
Это была ваша порция знаний на сегодня. Подписывайтесь на вашей любимой платформе

00:19:48.040 --> 00:19:52.780
подкастов и поделитесь этим с тем, кто изучает Dynamics 365. Затем переходите к следующему эпизоду,

00:19:52.980 --> 00:19:55.560
чтобы увидеть, как все строительные блоки соединяются воедино.