WEBVTT

00:00:00.000 --> 00:00:06.320
Що стається, коли назва товару у відділі продажів не збігається з назвою на складі, а інтернет-магазин досі показує торішнє фото?

00:00:06.480 --> 00:00:08.040
Хтось замовляє не той товар.

00:00:08.160 --> 00:00:18.200
Покупець запитує деталі, яких ніхто не може знайти, і персонал починає перевіряти таблиці, старі листи, PDF-файли постачальників та п'ять різних систем лише заради відповіді на просте питання.

00:00:18.380 --> 00:00:29.640
Вітаємо у черговому випуску корисних порад від M365FMIO TMDMO PITAS, і сьогодні ми розглядаємо управління інформацією про продукти в Dynamics 365 або скорочено PIM.

00:00:29.640 --> 00:00:39.040
Наприкінці ви зрозумієте, як він підтримує один спільний запис про продукт, як продукти можуть мати різні форми і як ця інформація доходить до підрозділів компанії, яким вона потрібна.

00:00:39.160 --> 00:00:41.700
Один запис про продукт для всієї компанії.

00:00:42.080 --> 00:00:46.840
З боку продукт може здатися простим. Лише назва, ціна і, можливо, зображення.

00:00:47.040 --> 00:00:50.640
За лаштунками той самий продукт стосується майже кожного підрозділу компанії.

00:00:50.800 --> 00:00:52.040
Ось як це відбувається.

00:00:52.040 --> 00:00:58.080
Відділу закупівель потрібні дані постачальників та одиниці виміру, тоді як складським командам інформація для приймання, зберігання та відбору товарів.

00:00:58.200 --> 00:01:00.000
Відділу продажів потрібні чіткі назви.

00:01:00.120 --> 00:01:03.920
Фінансовому відділу потрібне правильне налаштування, а інтернет-магазину – точні фото та описи.

00:01:04.060 --> 00:01:06.720
Кожна команда дивиться на один і той самий продукт під іншим кутом.

00:01:06.900 --> 00:01:10.100
Без спільного місця для такої інформації люди часто створюють власні копії.

00:01:10.280 --> 00:01:12.280
Команда з роботи з продуктами веде таблицю.

00:01:12.280 --> 00:01:14.860
Відділ продажів вводить коротшу назву у своїй системі.

00:01:14.980 --> 00:01:21.740
Склад використовує номер товару з іншим описом, а маркетинг зберігає зображення у спільній папці, тоді як служба підтримки клієнтів шукає дані у старих листах.

00:01:21.880 --> 00:01:25.820
Такий підхід спочатку створює невеликі розбіжності, а потім ці розбіжності поширюються далі.

00:01:25.980 --> 00:01:28.580
Уявіть компанію, що продає термопляшки для води.

00:01:28.580 --> 00:01:36.480
Постачальник змінює об'єм з 500 мл на 750 мл, відділ закупівель отримує нові дані, але інтернет-магазин досі вказує старий об'єм.

00:01:36.600 --> 00:01:42.380
Відділ продажів надсилає клієнтам невірний опис, а працівники складу бачать етикетку продукту, яка не відповідає замовленню.

00:01:42.540 --> 00:01:44.380
Ніхто не мав наміру створювати проблему.

00:01:44.560 --> 00:01:46.840
Кожна команда просто працювала з різною копією.

00:01:47.000 --> 00:01:52.360
Управління інформацією про продукти в Dynamics 365 надає компанії одне централізоване визначення продукту.

00:01:52.500 --> 00:01:55.320
Уявіть це як спільну картотеку для інформації про продукти.

00:01:58.580 --> 00:02:00.380
Це є місцем, де зберігаються узгоджені дані.

00:02:00.500 --> 00:02:06.020
Люди використовують це визначення у робочих процесах, замість того, щоб вводити одну і ту саму інформацію знову і знову.

00:02:06.160 --> 00:02:08.560
Номер продукту знаходиться в центрі цього запису.

00:02:08.740 --> 00:02:14.620
Він допомагає компанії послідовно ідентифікувати продукт, навіть якщо різні команди використовують різні слова, говорячи про нього.

00:02:14.820 --> 00:02:22.000
Разом із цим номером ви зберігаєте назву та опис і вказуєте, чи є це фізичним товаром для зберігання, чи послугою, яку надає компанія.

00:02:22.000 --> 00:02:26.960
Запис також містить одиниці виміру, які використовуються під час купівлі, продажу, зберігання або обліку товару.

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

00:02:31.320 --> 00:02:35.580
Коли ці одиниці зрозумілі, відділи закупівель і складського обліку мають набагато кращу вихідну базу.

00:02:35.780 --> 00:02:41.480
Інформація про продукт також може містити зображення, вкладення, категорії, атрибути та переклади назв і описів.

00:02:41.620 --> 00:02:44.160
Отже, запис може містити більше, ніж просто назву.

00:02:44.160 --> 00:02:55.260
У ньому можна зберігати документацію постачальника, фото для ідентифікації товару, перекладені описи для команд чи клієнтів, які працюють іншою мовою, а також деталі, як от матеріал, бренд або інструкції з використання.

00:02:55.440 --> 00:02:58.200
Спільне визначення має пріоритет над локальним використанням.

00:02:58.320 --> 00:03:02.740
Компанія визначає продукт один раз, а потім дозволяє різним підрозділам використовувати його за потреби.

00:03:02.860 --> 00:03:07.580
Спільний запис об'єднує загальні факти, тоді як кожна сфера застосовує власній бізнес-налаштування пізніше.

00:03:07.580 --> 00:03:12.160
Вам не потрібно створювати продукт з нуля кожного разу, коли він знадобиться іншому відділу.

00:03:12.480 --> 00:03:18.240
Це набагато зручніший спосіб роботи, проте назва й опис не завжди повністю розкривають суть продукту.

00:03:18.440 --> 00:03:23.680
Одна пара джинсів може перетворитися на багато товарних одиниць, як тільки з'являються колір і розмір.

00:03:23.820 --> 00:03:26.560
Основні продукти та варіанти – родовід продукції.

00:03:27.020 --> 00:03:31.620
Тож, коли один продукт перетворюється на багато продуктів, подумайте про пару джинсів.

00:03:31.620 --> 00:03:41.960
Ви, ймовірно, вважаєте джинси одним продуктом, але склад не може взяти будь-яку пару, якщо в замовленні вказано чорний колір і розмір LA відділ продажів не може обіцяти сині джинси розміру XS, якщо такої комбінації насправді не існує.

00:03:42.080 --> 00:03:44.980
Ось тут Dynamics 365 пропонує просту ідею.

00:03:45.100 --> 00:03:48.020
Система розмежовує базовий продукт і основний продукт – Product Master.

00:03:48.160 --> 00:03:50.160
Простий продукт – це один фіксований товар.

00:03:50.300 --> 00:03:54.860
Уявіть звичайну пачку паперу для принтера, що продається в одному розмірі, одному кольорі та одному форматі.

00:03:54.860 --> 00:03:58.880
Вона має власний запис продукту, оскільки немає варіантів, які б змінювали характеристики товару.

00:03:59.000 --> 00:04:00.720
Основний продукт працює інакше.

00:04:00.900 --> 00:04:03.280
Це головний запис для цілого сімейства продуктів.

00:04:03.460 --> 00:04:07.100
Він містить спільні дані та правила вибору, які створюють окремі товарні одиниці.

00:04:07.260 --> 00:04:08.320
Ось як це працює.

00:04:08.480 --> 00:04:13.400
Основний запис джинсів містить назву, базовий опис та загальну інформацію для кожної пари в цій лінійці.

00:04:13.560 --> 00:04:18.520
Потім окремі варіанти ідентифікують конкретні джинси, які хтось купує, зберігає, виготовляє або відправляє.

00:04:18.520 --> 00:04:20.520
Варіант – це конкретний товар для продажу.

00:04:20.700 --> 00:04:24.800
Для джинсів синій колір і розмір M можуть бути одним варіантом, чорний колір і розмір L – іншим.

00:04:24.940 --> 00:04:27.720
Вони належать до одного сімейства продуктів, але вони невзаємозамінні.

00:04:27.860 --> 00:04:30.580
Один товар може лежати на полиці складу, тоді як інший вже закінчився.

00:04:30.700 --> 00:04:32.180
Один може мати іншу етикетку.

00:04:32.320 --> 00:04:33.760
Один може мати власний штрих-код.

00:04:33.900 --> 00:04:35.920
Структура батьківської, дочерній є ключовою ідеєю.

00:04:36.040 --> 00:04:37.580
Мастер-товар визначає сімейство.

00:04:37.800 --> 00:04:39.580
Варіанти товару – це окремі його члени.

00:04:39.580 --> 00:04:42.120
Замість того, щоб щоразу вводити однакову базову інформацію,

00:04:42.200 --> 00:04:45.580
ви починаєте з майстер-товару і створюєте реальні комбінації, потрібні вашому бізнесу.

00:04:45.700 --> 00:04:47.360
Дозвольте навести конкретний приклад.

00:04:47.520 --> 00:04:50.660
Уявіть, що лінійка джинсів доступна в синьому, чорному та коричневому кольорах.

00:04:50.840 --> 00:04:54.300
Вона також має розміри XS, S, M, L, XL та XXL.

00:04:54.420 --> 00:04:58.040
Якби кожен колір був доступний у кожному розмірі, ви мали б 18 комбінацій.

00:04:58.160 --> 00:05:00.580
Але бізнес рідко продає всі можливі комбінації.

00:05:00.580 --> 00:05:04.380
Можливо, сині джинси доступні лише від XS до M чорні, від M до XL.

00:05:04.520 --> 00:05:09.500
Коричневі починаються з розміру L-Dynamics 365 може розглядати кожну дозволену комбінацію як окремий варіант.

00:05:09.660 --> 00:05:13.500
Коли хтось додає джинси до замовлення, він обирає параметри, що ідентифікують конкретний товар.

00:05:13.620 --> 00:05:16.500
Колір і розмір вказують системі, який саме варіант потрібен клієнту.

00:05:16.660 --> 00:05:18.860
Жодних здогадок про те, яку пару класти в коробку.

00:05:19.020 --> 00:05:21.120
Ці параметри називаються вимірами продукту.

00:05:21.280 --> 00:05:22.780
Dynamics 365.

00:05:22.780 --> 00:05:25.600
Управління ланцюгом постачень включає 5 із них.

00:05:25.740 --> 00:05:28.560
Це колір, розмір, стиль, конфігурація та версія.

00:05:28.700 --> 00:05:33.080
Компанія обирає виміри, що підходять для сімейства товарів, а потім групує їх для цього мастер-товару.

00:05:33.240 --> 00:05:34.740
Давайте швидко пройдемося по них.

00:05:34.880 --> 00:05:35.800
Колір – це просто.

00:05:36.060 --> 00:05:37.880
Синій, чорний, коричневий, червоний.

00:05:38.060 --> 00:05:39.460
Розмір також всім знайомий.

00:05:39.620 --> 00:05:42.100
Малий, середній, великий або номер розміру взуття.

00:05:42.100 --> 00:05:45.560
Стиль допомагає розрізняти товари, які мають однакову назву, але виглядають по-різному.

00:05:45.560 --> 00:05:47.780
Сорочка може бути вільного або приталеного крою.

00:05:47.940 --> 00:05:50.460
Стілець може мати стандартний каркас або інше оздоблення.

00:05:50.640 --> 00:05:53.180
Конфігурація описує обрану збірку або налаштування.

00:05:53.360 --> 00:05:57.020
Наприклад, машині може знадобитися специфічний двигун, напруга або набір деталей.

00:05:57.220 --> 00:05:59.540
Вимір конфігурації ідентифікує цей вибір.

00:05:59.700 --> 00:06:01.920
Версія відстежує зміни продукту з часом.

00:06:02.100 --> 00:06:03.840
Це найбільш важливо для виробників.

00:06:03.840 --> 00:06:08.360
Уявіть деталь, яка виконує ту саму функцію, але змінюється після затвердженого інженерного оновлення.

00:06:08.360 --> 00:06:12.640
Версія дозволяє компанії відрізняти першу версію від другої під час руху ланцюгом постачень.

00:06:12.760 --> 00:06:15.460
Отже, не кожен мастер товар потребує всіх п'яти вимірів.

00:06:15.580 --> 00:06:17.900
Футболці можуть знадобитися лише колір і розмір.

00:06:18.020 --> 00:06:20.640
Обладнанню може знадобитися конфігурація та версія.

00:06:20.840 --> 00:06:23.440
Група вимірів діє як набір правил для сімейства товарів.

00:06:23.440 --> 00:06:28.440
Вона вказує Dynamics 365, які параметри застосовувати під час створення та ідентифікації варіантів.

00:06:28.540 --> 00:06:30.840
Це рішення визначає продукт від самого початку.

00:06:30.840 --> 00:06:34.760
Можливо, ви запитаєте про вагу, висоту, довжину, ширину або об'єм.

00:06:34.880 --> 00:06:38.280
Ці деталі описують фізичний продукт, але вони не створюють варіанти.

00:06:38.480 --> 00:06:41.140
Пара джинсів може мати зазначену вагу чи розмір упаковки,

00:06:41.280 --> 00:06:44.380
що не перетворює її на інший товар, як це роблять колір чи розмір.

00:06:44.520 --> 00:06:46.380
Фізичні розміри описують товар.

00:06:46.380 --> 00:06:48.940
Розміри продукту ідентифікують конкретний варіант.

00:06:49.100 --> 00:06:51.860
Розмежування цих двох понять запобігає плутанині в майбутньому.

00:06:51.860 --> 00:06:54.780
Якщо на складі потрібно знати, скільки місця займає коробка.

00:06:54.900 --> 00:06:56.660
Фізичні розміри стануть у пригоді.

00:06:56.800 --> 00:07:00.500
Якщо в замовленні потрібні чорні джинси розміру LATCH, знайдіть правильний варіант.

00:07:00.660 --> 00:07:03.220
Є один початковий вибір, який впливає на все подальше.

00:07:03.380 --> 00:07:06.520
Як компанія створюватиме та контролюватиме ці варіанти продукту.

00:07:06.520 --> 00:07:08.300
І саме це ми розглянемо далі.

00:07:08.440 --> 00:07:10.820
Налаштування продуктів без створення хаосу.

00:07:10.960 --> 00:07:14.700
Вибір розмірів підказує Dynamics 365, як ідентифікувати варіант.

00:07:14.700 --> 00:07:17.860
Але компанія все одно повинна вирішити, як створювати ці варіанти.

00:07:18.060 --> 00:07:19.660
Цей вибір залежить від продукту.

00:07:19.820 --> 00:07:23.040
Управління ланцюгами постачання підтримує три основні підходи.

00:07:23.140 --> 00:07:28.180
Попередньо визначені варіанти – конфігурація на основі розмірів та конфігурація на основі обмежень.

00:07:28.180 --> 00:07:31.420
Назви звучать технічно, тому дозвольте пояснити їх простими словами.

00:07:31.540 --> 00:07:35.200
Попередньо визначені варіанти підходять для товарів із відомим обмеженим набором комбінацій.

00:07:35.200 --> 00:07:38.280
Уявіть ретейлера, який продає асортимент джинсів, про який ми щойно говорили.

00:07:38.400 --> 00:07:41.540
Компанія вже знає, які кольори та розміри вона закупуватиме, зберігатиме та продаватиме.

00:07:41.680 --> 00:07:43.780
Сині бувають розмірів Extra Small, Small та Medium.

00:07:43.980 --> 00:07:46.220
Чорні бувають розмірів Medium, Large та Extra Large.

00:07:46.340 --> 00:07:49.200
Коричневі бувають розмірів Large, Extra Large та Double Extra Large.

00:07:49.200 --> 00:07:52.260
Ці дев'ять варіантів можна створити заздалегідь як окремі варіанти.

00:07:52.440 --> 00:07:55.300
Бізнесу не потрібна кожна можлива комбінація кольору та розміру.

00:07:55.300 --> 00:07:57.820
Він створює лише ті комбінації, які існують.

00:07:57.880 --> 00:08:03.000
Це підтримує каталог у порядку і не дає комусь замовити коричневі джинси розміру Extra Small, коли ніхто їх не виготовляє.

00:08:03.120 --> 00:08:06.380
Попередньо визначені варіанти добре працюють, коли асортимент залишається передбачуваним.

00:08:06.520 --> 00:08:11.100
Швейна компанія – дистриб'ютор із фіксованими розмірами упаковок, бізнес, що продає стандартні кольори меблів.

00:08:11.100 --> 00:08:13.960
Усі вони можуть підготувати товари, з якими очікують працювати.

00:08:13.960 --> 00:08:20.660
Кожен варіант існує як відомий товар до надходження замовлення, тому відділи закупівель, складські команди та персонал з продажу можуть працювати з чітким вибором продуктів.

00:08:20.760 --> 00:08:23.160
Наступний підхід – конфігурація на основі розмірів.

00:08:23.320 --> 00:08:25.040
Він часто зустрічається у виробництві.

00:08:25.160 --> 00:08:27.580
Уявіть компанію, яка виготовляє промислові насоси.

00:08:27.580 --> 00:08:31.580
Одне сімейство насосів може використовувати багато однакових деталей, але клієнт може обрати певну конфігурацію.

00:08:32.240 --> 00:08:35.560
Цей вибір впливає на те, які компоненти входять до складу готового насоса.

00:08:35.560 --> 00:08:39.380
Dynamics 365 може використовувати розмір конфігурації, щоб контролювати це.

00:08:39.540 --> 00:08:42.100
Продукт використовує одну спільну специфікацію матеріалів.

00:08:42.300 --> 00:08:44.360
Її часто називають BOM – Bill of Materials.

00:08:44.580 --> 00:08:47.600
Специфікація матеріалів – це просто перелік деталей для створення чогось.

00:08:47.600 --> 00:08:52.200
У межах цього списку деякі деталі застосовуються лише тоді, коли клієнт обирає конкретну конфігурацію.

00:08:52.340 --> 00:08:55.820
Наприклад, насос, розрахований на одну напругу, може потребувати одного двигуна.

00:08:56.000 --> 00:08:57.920
Для іншої напруги потрібен інший двигун.

00:08:57.920 --> 00:09:02.660
Замість того, щоб підтримувати окремий перелік деталей для кожного можливого насоса, компанія веде один спільний список.

00:09:02.760 --> 00:09:05.500
У ньому позначено, які позиції належать до якої конфігурації.

00:09:05.500 --> 00:09:11.500
Коли обрана конфігурація потрапляє до планування чи виробництва, Dynamics 365 використовує лише ті позиції, що відповідають цьому вибору.

00:09:11.600 --> 00:09:13.780
Це значно економить час на дублюванні налаштувань.

00:09:13.920 --> 00:09:19.940
Це також надає виробникам чіткіший спосіб керування родиною продуктів, які мають спільну основу, але відрізняються контрольованими параметрами.

00:09:19.940 --> 00:09:22.220
Розміри ідентифікують обраний продукт.

00:09:22.480 --> 00:09:25.420
Специфікація визначає, які деталі входять у цю збірку.

00:09:25.640 --> 00:09:27.720
Далі йде конфігурація на основі обмежень.

00:09:27.720 --> 00:09:33.420
Цей підхід підходить для продуктів, де клієнти можуть обирати з багатьох варіантів, але не кожен варіант сумісний з іншим.

00:09:33.580 --> 00:09:37.920
Уявіть спеціалізовану машину, лабораторне обладнання або продукт, зібраний із багатьох частин.

00:09:38.060 --> 00:09:42.380
Клієнт може обрати тип живлення, корпус, двигун, опцію безпеки та панель керування.

00:09:42.600 --> 00:09:45.060
Деякі комбінації працюють, деякі просто ні.

00:09:45.060 --> 00:09:47.620
Певний корпус може не підійти для більшого двигуна.

00:09:47.760 --> 00:09:50.300
Одна напруга може вимагати спеціальної панелі керування.

00:09:50.500 --> 00:09:53.120
Захисна кришка може працювати лише з одним розміром машини.

00:09:53.120 --> 00:09:56.900
Без правил менеджер з продажу міг би обрати комбінацію, яку завод не може виготовити.

00:09:57.200 --> 00:10:00.800
Конфігурація на основі обмежень вносить ці правила в модель конфігурації продукту.

00:10:00.960 --> 00:10:03.820
Модель описує можливі вибори та правила, що їх обмежують.

00:10:03.900 --> 00:10:07.340
Коли хтось конфігурує продукт, система спрямовує його до допустимих варіантів.

00:10:07.340 --> 00:10:09.960
Вона запобігає вибору опцій, що конфліктують між собою.

00:10:10.120 --> 00:10:12.980
Це зупиняє неможливе замовлення ще до того, як воно потрапить у виробництво.

00:10:13.140 --> 00:10:16.360
Я хочу зупинитися тут, оскільки це важливе рішення на ранньому етапі проєктування.

00:10:16.360 --> 00:10:21.860
Компанія повинна обрати технологію конфігурації, яка відповідає її бізнес-процесу, перш ніж створювати родину продуктів.

00:10:22.000 --> 00:10:26.480
Dynamics 365 не конвертує продукт з однієї моделі конфігурації в іншу пізніше.

00:10:26.480 --> 00:10:32.760
Тому ретейлер, що продає фіксований асортимент, не повинен налаштовувати складну модель користувацького продукту лише тому, що це звучить гнучко.

00:10:32.900 --> 00:10:39.720
А виробник обладнання під замовлення не повинен втискати кожен можливий варіант у довгий список визначених раніше моделей, якщо вибір залежить від правил.

00:10:39.880 --> 00:10:42.860
Почніть із реального процесу купівлі, продажу та виробництва.

00:10:43.020 --> 00:10:44.540
Запитайте себе просте питання.

00:10:44.700 --> 00:10:47.540
Чи знаємо ми всі комбінації продукту до надходження замовлення?

00:10:47.660 --> 00:10:50.920
Чи клієнт сам створює вибір продукту через набір дозволених опцій?

00:10:50.920 --> 00:10:53.360
Відповідь вказує бізнесу на правильний підхід.

00:10:53.500 --> 00:10:59.380
Коли компанія знає, яким може бути продукт, їй потрібен спосіб чітко описати його та впорядкувати цю інформацію.

00:10:59.600 --> 00:11:02.800
Категорії, атрибути та контроль інформації про продукт.

00:11:02.900 --> 00:11:09.500
Назва продукту говорить вам, як він називається, але цього недостатньо, щоб купити, зберігати, продати або пояснити його клієнту.

00:11:09.680 --> 00:11:11.660
Ось тут на допомогу приходять категорії.

00:11:11.840 --> 00:11:14.940
Сприймайте категорії як відділи у добре організованому магазині.

00:11:15.060 --> 00:11:17.520
Компанія може групувати продукти за тим, чим вони є.

00:11:17.520 --> 00:11:21.160
О, одяг в одному ряду, інструменти в іншому, офісне приладдя – у третьому.

00:11:21.340 --> 00:11:24.240
Або ж їх можуть групувати за типом роботи, яку потрібно виконати людям.

00:11:24.440 --> 00:11:26.000
У будь-якому разі мета однакова.

00:11:26.180 --> 00:11:28.140
Зробити продукти легшими для пошуку та керування.

00:11:28.340 --> 00:11:29.600
Візьмемо акумуляторний дріль.

00:11:29.740 --> 00:11:32.120
Відділу продажів потрібно знайти його серед електроінструментів.

00:11:32.240 --> 00:11:35.560
Команда продукту може віднести його до категорії обладнання на акумуляторах.

00:11:35.680 --> 00:11:39.940
І тут ося справа в тому, що один продукт може перебувати в кількох категоріях одночасно,

00:11:39.940 --> 00:11:42.260
якщо вони відповідають різним бізнес-потребам.

00:11:42.420 --> 00:11:46.060
Сенс не в тому, щоб намагатися запхнути кожен товар в одну ідеальну папку.

00:11:46.240 --> 00:11:49.960
Категорії надають бізнесу структурований спосіб організації інформації про продукти,

00:11:50.060 --> 00:11:52.440
пошуку товарів та роботи з групами пов'язаних позицій.

00:11:52.580 --> 00:11:55.200
Вони також допомагають людям застосовувати правильну інформацію до товарів,

00:11:55.280 --> 00:11:56.400
що належать до однієї групи.

00:11:56.520 --> 00:11:59.480
Категорії роблять багато, але вони не можуть містити кожну деталь.

00:11:59.600 --> 00:12:01.300
Ось тут і з'являються атрибути.

00:12:01.300 --> 00:12:07.380
Для пляшки для води атрибутами можуть бути матеріал, місткість, тип кришки, ізоляція, бренд та інструкції з догляду.

00:12:07.540 --> 00:12:12.840
Для деталі машини це можуть бути розміри, вимоги доживлення, температурний діапазон або технічний стандарт.

00:12:12.980 --> 00:12:16.480
Атрибути перетворюють загальну назву на корисну інформацію про продукт.

00:12:16.560 --> 00:12:19.180
Саме на ту, що вам справді потрібна для виконання роботи.

00:12:19.300 --> 00:12:22.980
Категорії можуть містити атрибути, які мають сенс для продуктів всередині них.

00:12:23.180 --> 00:12:26.280
Для одягу потрібні дані про тканину, розмір і вказівки щодо прання.

00:12:26.280 --> 00:12:30.460
Для електронного обладнання потрібна напруга, деталі гарантії та інформація про сумісність.

00:12:30.560 --> 00:12:33.980
Це означає, що нікому не потрібно вигадувати випадкові поля для кожного запису продукту.

00:12:34.160 --> 00:12:36.860
Вони просто використовують деталі, що підходять для цієї групи товарів.

00:12:36.980 --> 00:12:39.260
Зображення та вкладені файли додають ще один рівень.

00:12:39.400 --> 00:12:43.700
Фото допомагає працівнику складу, продавцю або клієнту побачити товар, про який йде мова.

00:12:43.880 --> 00:12:49.040
Вкладення може містити допоміжні матеріали, як от документ від постачальника, специфікацію чи інші папери.

00:12:49.240 --> 00:12:51.260
Іноді самої лише назви недостатньо.

00:12:51.260 --> 00:12:54.320
Переклади важливі, коли компанія працює з різними мовами.

00:12:54.520 --> 00:12:59.040
Назви та описи продуктів можна перекладати, щоб люди на різних ринках отримували зрозуміло їм інформацію.

00:12:59.200 --> 00:13:02.420
Продукт залишається тим самим, але слова навколо нього адаптуються до аудиторії.

00:13:02.580 --> 00:13:05.720
Компанії також потрібен контроль над тим, хто може змінювати цю інформацію.

00:13:05.720 --> 00:13:11.940
Не кожен працівник повинен мати можливість редагувати кожен запис продукту, перейменовувати товар або змінювати деталі, від яких залежать інші команди.

00:13:11.940 --> 00:13:17.780
Dynamics 365 дозволяє застосовувати правила доступу до даних про продукти на рівні категорії або для окремого товару.

00:13:17.900 --> 00:13:23.720
Наприклад, команда «Відповідальна за промислове обладнання» працює з цією категорією, тоді як інша група займається споживчими товарами.

00:13:23.860 --> 00:13:27.880
Продукт з обмеженим доступом може потребувати суворішого контролю, ніж звичайне офісне приладдя.

00:13:27.880 --> 00:13:31.400
Бізнес сам вирішує, хто може працювати з кожною ділянкою даних про продукти.

00:13:31.540 --> 00:13:33.960
Це захищає інформацію, на яку покладаються люди.

00:13:33.960 --> 00:13:37.660
Запис тепер може містити правильні деталі, документи, категорії та засоби контролю.

00:13:37.800 --> 00:13:39.020
Але він усе ще потребує схвалення.

00:13:39.160 --> 00:13:43.580
Перш ніж підрозділи компанії, які купують, продають, зберігають або виробляють його, зможуть фактично ним користуватися.

00:13:43.720 --> 00:13:45.780
Випуск продуктів для юридичних осіб.

00:13:45.980 --> 00:13:50.260
Завершене визначення продукту тепер готове до використання всіма автоматично.

00:13:50.260 --> 00:13:51.280
О, ще ні.

00:13:51.580 --> 00:13:56.960
Компанія часто працює через кілька юридичних осіб, які є окремими компаніями всередині більшого бізнесу.

00:13:56.960 --> 00:14:00.020
Одна юридична особа може купувати та зберігати продукт у Німеччині.

00:14:00.140 --> 00:14:02.400
Інша продає той самий продукт у Сполучених Штатах.

00:14:02.540 --> 00:14:03.640
Третя його виробляє.

00:14:03.800 --> 00:14:06.760
Усі вони можуть розпочинати роботу з одного спільного визначення продукту.

00:14:06.880 --> 00:14:10.320
У Dynamics 365 це спільне визначення стає випущеним продуктом,

00:14:10.320 --> 00:14:13.600
коли компанія схвалює його для використання конкретною юридичною особою.

00:14:13.760 --> 00:14:18.480
Вважайте випуск наданням цьому бізнес-підрозділу дозволу на використання продукту у своїй повсякденній роботі.

00:14:18.620 --> 00:14:20.760
Продукт не змінює свою ідентичність.

00:14:20.760 --> 00:14:25.780
Його загальна назва, опис, категорія, розміри та інші спільні деталі залишаються пов'язаними з центральним визначенням,

00:14:25.860 --> 00:14:31.340
але кожна юридична особа може додати налаштування, необхідні перед замовленням, продажем, зберіганням або виробництвом цього продукту.

00:14:31.340 --> 00:14:35.540
Одна компанія може купувати продукт у постачальника, інша може лише продавати його.

00:14:35.720 --> 00:14:40.420
Виробничій компанії потрібні налаштування виробництва, тоді як дистриб'юторські, налаштування складу та запасів.

00:14:40.600 --> 00:14:43.160
Деталі продажу відрізняються залежно від юридичної особи.

00:14:43.160 --> 00:14:45.280
Місцеві бізнес-правила також відрізняються.

00:14:45.480 --> 00:14:50.980
Випуск дозволяє кожній юридичній особі підготувати продукт для своєї роботи без створення повністю окремого визначення продукту.

00:14:50.980 --> 00:14:54.320
Уявіть компанію, яка продає ту саму пляшку води в кількох країнах.

00:14:54.380 --> 00:14:57.360
Команда з розробки продукту створює одне центральне визначення продукту.

00:14:57.500 --> 00:15:00.740
Потім компанія випускає його для юридичної особи у Великій Британії.

00:15:00.900 --> 00:15:04.800
І ця юридична особа додає налаштування, необхідні для купівлі та зберігання пляшки.

00:15:04.800 --> 00:15:10.800
Пізніше той самий продукт випускається для канадської юридичної особи, де працівники завершують налаштування для місцевих продажів та запасів.

00:15:10.920 --> 00:15:13.280
Обидві компанії використовують той самий продукт.

00:15:13.360 --> 00:15:17.040
Їм не потрібно починати спочатку з назвою, описом та даними про сімейство продуктів.

00:15:17.220 --> 00:15:20.640
Вони заповнюють лише ту інформацію, яка стосується їхньої власної юридичної особи.

00:15:20.740 --> 00:15:24.140
Такий поділ зберігає спільні факти та локальну бізнес-роботу на своїх місцях.

00:15:24.140 --> 00:15:29.500
Спільне визначення продукту відповідає на запитання, що це за продукт, а випущений продукт відповідає на інше.

00:15:29.640 --> 00:15:31.960
Як саме ця конкретна компанія буде його використовувати?

00:15:32.160 --> 00:15:37.660
Це невелика різниця у формулюванні, але вона запобігає великій кількості дублювання роботи, коли бізнес працює через кілька юридичних осіб.

00:15:37.840 --> 00:15:42.520
Dynamics 365 може випускати продукти для однієї юридичної особи або кількох одночасно.

00:15:42.660 --> 00:15:47.180
Це допомагає, коли компанія запроваджує стандартний асортимент продукції для багатьох бізнес-підрозділів.

00:15:47.180 --> 00:15:51.000
Все ж таки, випуск продукту тепер не є завершальним етапом, натиснув і забув.

00:15:51.140 --> 00:15:55.800
Кожна юридична особа може потребувати додаткових даних, перш ніж її команди зможуть безпечно працювати з продуктом.

00:15:55.960 --> 00:15:59.480
Робоча область обслуговування випущених продуктів допомагає стежити за цим процесом.

00:15:59.680 --> 00:16:05.000
Вона показує нещодавно випущені продукти та перевіряє, чи завершено необхідне налаштування для цієї юридичної особи.

00:16:05.140 --> 00:16:09.320
Якщо потрібно додати атрибути продукту, категорії, налаштування замовлень або переклади,

00:16:09.320 --> 00:16:13.520
робоча область надає місце для пошуку цих завдань і відкриття відповідних сторінок продукту.

00:16:13.680 --> 00:16:17.320
Вона також допомагає командам виявляти незавершені справи щодо зміни продукту.

00:16:17.480 --> 00:16:22.620
Це важливо, оскільки продукт може виглядати готовим у центральному поданні, тоді як локальні налаштування залишаються неповними.

00:16:22.740 --> 00:16:26.600
Робоча область надає юридичній особі практичний список продуктів, що потребують уваги,

00:16:26.660 --> 00:16:29.200
замість того, щоб змушувати людей переглядати довгі списки.

00:16:29.360 --> 00:16:31.880
Тож випускник копіює продукт в окремий світ.

00:16:31.880 --> 00:16:38.340
Він пов'язує одне затверджене визначення продукту з юридичною особою, надаючи їй можливість застосувати власні операційні деталі.

00:16:38.480 --> 00:16:44.100
Після цього інформація про продукт може бути використана в роботі із замовленнями, запасами та потребами клієнтів.

00:16:44.240 --> 00:16:50.700
Отже, як PIM поєднує роботу навколо продукту, то як управління інформацією про продукт насправді поєднує роботу навколо продукту.

00:16:50.860 --> 00:16:52.300
Ось найпростіше визначення.

00:16:52.460 --> 00:16:54.980
PIM не виконує кожен бізнес-процес самостійно.

00:16:55.120 --> 00:16:58.300
Натомість він надає інформацію про продукт, необхідну для цих процесів.

00:17:01.880 --> 00:17:04.200
Він повинен знайти правильний товар у замовленні на закупівлю.

00:17:04.340 --> 00:17:07.540
Складська команда потребує правильний товар під час приймання або відбору запасів.

00:17:07.700 --> 00:17:10.940
Відділ продажів потребує деталі продукту, які мають бути у комерційній пропозиції.

00:17:11.140 --> 00:17:14.540
Іншим програмам Dynamics 365 також можуть знадобитися дані про продукти.

00:17:14.640 --> 00:17:18.400
PIM дає всім цим командам одну спільну відправну точку, єдине джерело істини.

00:17:18.520 --> 00:17:20.540
Тепер, звідки надходять ці дані про продукт?

00:17:20.660 --> 00:17:24.720
Визначення продуктів можуть створюватися всередині Dynamics 365 Supply Chain Management.

00:17:24.720 --> 00:17:28.620
Це добре працює, коли компанія керує інформацією про продукт там із самого початку.

00:17:28.760 --> 00:17:32.460
Але багато компаній вже використовують іншу систему для розробки продукту або обліку продукції.

00:17:32.640 --> 00:17:36.820
Наприклад, дані про продукт можуть надходити із системи управління життєвим циклом продукту, яку часто називають PLM.

00:17:37.000 --> 00:17:40.740
Система PLM допомагає командам керувати продуктом під час його проєктування та розробки.

00:17:40.940 --> 00:17:45.140
Існує також управління даними про продукт або PDM, яке обробляє дані про продукт та супутні документи.

00:17:45.140 --> 00:17:49.880
Деякі компанії навіть використовують окрему систему PIM до того, як інформація про продукт потрапляє до Supply Chain Management.

00:17:50.100 --> 00:17:51.020
Ось хороші новини.

00:17:51.200 --> 00:17:54.600
Dynamics 365 може імпортувати визначення продуктів із цих систем.

00:17:54.780 --> 00:17:59.980
Це означає, що вам не потрібно вводити ті самі деталі продукту знову тільки тому, що продукт переходить від проєктування до ланцюга поставок.

00:18:00.060 --> 00:18:04.700
Supply Chain Management може стати місцем, де зберігаються майстер дані про продукти і для інших екземплярів системи.

00:18:04.800 --> 00:18:07.960
Це важливо для великих компаній, що мають більше, ніж один екземпляр системи.

00:18:07.960 --> 00:18:12.660
Один екземпляр керує центральними визначеннями продуктів, а потім експортує та імпортує ці дані в інші.

00:18:12.800 --> 00:18:18.160
Microsoft надає об'єкти даних для такого обміну, структуровані способи переміщення визначених даних між системами.

00:18:18.280 --> 00:18:19.220
Але це ще не все.

00:18:19.440 --> 00:18:22.040
Microsoft Dataverse розширює цей шлях розповсюдження.

00:18:22.220 --> 00:18:26.380
Dataverse – це спільна хмарна служба даних Microsoft, яку використовують багато бізнес-додатків.

00:18:26.520 --> 00:18:29.400
Управління ланцюгами постачання може експортувати визначення продуктів у Dataverse,

00:18:29.400 --> 00:18:33.560
а інші бізнес-додатки, як от Dynamics 365 Sales, можуть використовувати ці дані про продукти.

00:18:33.680 --> 00:18:36.500
Це не означає, що тепер кожен додаток виконує ту саму роботу.

00:18:36.660 --> 00:18:39.180
PM організовує та підтримує інформацію про продукт.

00:18:39.320 --> 00:18:42.080
Dynamics 365 Sales займається процесами продажу.

00:18:42.260 --> 00:18:46.700
Інші додатки відповідають за власне обслуговування клієнтів, комерцію, фінанси, виробництво або операційні завдання.

00:18:46.860 --> 00:18:50.380
Вони можуть використовувати відповідні дані про продукти, але кожен додаток зберігає своє призначення.

00:18:50.540 --> 00:18:51.920
Розгляньмо практичний процес.

00:18:51.920 --> 00:18:54.860
Команда з продуктів створює або імпортує нове визначення продукту.

00:18:55.000 --> 00:18:57.480
Бізнес надає його юридичним особам, яким це потрібно.

00:18:57.600 --> 00:18:59.660
Ці підрозділи завершують своє локальне налаштування.

00:18:59.860 --> 00:19:01.800
Відділ закупівель може працювати із затвердженим товаром.

00:19:01.920 --> 00:19:03.960
Працівники складу можуть отримувати та опрацьовувати його.

00:19:04.120 --> 00:19:07.520
Відділ продажів може посилатися на правильний продукт, замість того, щоб створювати власну версію.

00:19:07.660 --> 00:19:09.640
Результат проявляється у звичайних моментах.

00:19:09.740 --> 00:19:11.360
Покупець замовляє потрібний товар.

00:19:11.360 --> 00:19:15.520
Клієнт бачить правильні деталі, а складський працівник може зіставити замовлення з товаром перед собою.

00:19:15.660 --> 00:19:21.280
Коли інформація про продукт змінюється, команди мають чіткіший шлях використання поточних затверджених даних замість пошуку старих копій.

00:19:21.420 --> 00:19:26.780
Це зменшує кількість помилок при замовленні, застарілої інформації та повернень через неправильні дані про продукт.

00:19:26.900 --> 00:19:34.280
Управління інформацією про продукт – це частина, яка тримає визначення продукту впорядкованим, поки решта підключеної платформи використовує цю інформацію в роботі.

00:19:34.280 --> 00:19:37.240
Висновок «Одна спільна історія продукту в Dynamics»

00:19:37.240 --> 00:19:44.560
365 Product Information Management перетворює ідею продукту на один контрольований запис, який юридичні особи та бізнес-команди можуть використовувати у своїй роботі.

00:19:44.680 --> 00:19:46.480
Це ваш самородок знань на сьогодні.

00:19:46.600 --> 00:19:50.680
Підписуйтесь на улюбленій подкаст-платформі та поділіться цим із тими, хто вивчає Dynamics 365.

00:19:50.680 --> 00:19:55.500
А потім переходьте до наступного епізоду, щоб побачити, як усі ці блоки поєднуються між собою.