Що стається, коли назва товару у відділі продажів не збігається з назвою на складі, а інтернет-магазин досі показує торішнє фото? Хтось замовляє не той товар. Покупець запитує деталі, яких ніхто не може знайти, і персонал починає перевіряти таблиці, старі листи, PDF-файли постачальників та п'ять різних систем лише заради відповіді на просте питання. Вітаємо у черговому випуску корисних порад від M365FMIO TMDMO PITAS, і сьогодні ми розглядаємо управління інформацією про продукти в Dynamics 365 або скорочено PIM. Наприкінці ви зрозумієте, як він підтримує один спільний запис про продукт, як продукти можуть мати різні форми і як ця інформація доходить до підрозділів компанії, яким вона потрібна. Один запис про продукт для всієї компанії. З боку продукт може здатися простим. Лише назва, ціна і, можливо, зображення. За лаштунками той самий продукт стосується майже кожного підрозділу компанії.

Ось як це відбувається. Відділу закупівель потрібні дані постачальників та одиниці виміру, тоді як складським командам інформація для приймання, зберігання та відбору товарів. Відділу продажів потрібні чіткі назви. Фінансовому відділу потрібне правильне налаштування, а інтернет-магазину – точні фото та описи. Кожна команда дивиться на один і той самий продукт під іншим кутом. Без спільного місця для такої інформації люди часто створюють власні копії. Команда з роботи з продуктами веде таблицю. Відділ продажів вводить коротшу назву у своїй системі. Склад використовує номер товару з іншим описом, а маркетинг зберігає зображення у спільній папці, тоді як служба підтримки клієнтів шукає дані у старих листах. Такий підхід спочатку створює невеликі розбіжності, а потім ці розбіжності поширюються далі. Уявіть компанію, що продає термопляшки для води. Постачальник змінює об'єм з 500 мл на 750 мл, відділ закупівель отримує нові дані, але інтернет-магазин досі вказує старий об'єм.

Відділ продажів надсилає клієнтам невірний опис, а працівники складу бачать етикетку продукту, яка не відповідає замовленню. Ніхто не мав наміру створювати проблему. Кожна команда просто працювала з різною копією. Управління інформацією про продукти в Dynamics 365 надає компанії одне централізоване визначення продукту. Уявіть це як спільну картотеку для інформації про продукти.

Це є місцем, де зберігаються узгоджені дані. Люди використовують це визначення у робочих процесах, замість того, щоб вводити одну і ту саму інформацію знову і знову. Номер продукту знаходиться в центрі цього запису. Він допомагає компанії послідовно ідентифікувати продукт, навіть якщо різні команди використовують різні слова, говорячи про нього. Разом із цим номером ви зберігаєте назву та опис і вказуєте, чи є це фізичним товаром для зберігання, чи послугою, яку надає компанія. Запис також містить одиниці виміру, які використовуються під час купівлі, продажу, зберігання або обліку товару. Коробка, штука, кілограм, літр або палита можуть означати зовсім різні речі в щоденній роботі. Коли ці одиниці зрозумілі, відділи закупівель і складського обліку мають набагато кращу вихідну базу. Інформація про продукт також може містити зображення, вкладення, категорії, атрибути та переклади назв і описів.

Отже, запис може містити більше, ніж просто назву. У ньому можна зберігати документацію постачальника, фото для ідентифікації товару, перекладені описи для команд чи клієнтів, які працюють іншою мовою, а також деталі, як от матеріал, бренд або інструкції з використання. Спільне визначення має пріоритет над локальним використанням. Компанія визначає продукт один раз, а потім дозволяє різним підрозділам використовувати його за потреби. Спільний запис об'єднує загальні факти, тоді як кожна сфера застосовує власній бізнес-налаштування пізніше. Вам не потрібно створювати продукт з нуля кожного разу, коли він знадобиться іншому відділу. Це набагато зручніший спосіб роботи, проте назва й опис не завжди повністю розкривають суть продукту. Одна пара джинсів може перетворитися на багато товарних одиниць, як тільки з'являються колір і розмір. Основні продукти та варіанти – родовід продукції. Тож, коли один продукт перетворюється на багато продуктів, подумайте про пару джинсів.

Ви, ймовірно, вважаєте джинси одним продуктом, але склад не може взяти будь-яку пару, якщо в замовленні вказано чорний колір і розмір LA відділ продажів не може обіцяти сині джинси розміру XS, якщо такої комбінації насправді не існує. Ось тут Dynamics 365 пропонує просту ідею. Система розмежовує базовий продукт і основний продукт – Product Master. Простий продукт – це один фіксований товар. Уявіть звичайну пачку паперу для принтера, що продається в одному розмірі, одному кольорі та одному форматі. Вона має власний запис продукту, оскільки немає варіантів, які б змінювали характеристики товару. Основний продукт працює інакше. Це головний запис для цілого сімейства продуктів. Він містить спільні дані та правила вибору, які створюють окремі товарні одиниці. Ось як це працює. Основний запис джинсів містить назву, базовий опис та загальну інформацію для кожної пари в цій лінійці. Потім окремі варіанти ідентифікують конкретні джинси, які хтось купує, зберігає, виготовляє або відправляє.

Варіант – це конкретний товар для продажу. Для джинсів синій колір і розмір M можуть бути одним варіантом, чорний колір і розмір L – іншим. Вони належать до одного сімейства продуктів, але вони невзаємозамінні. Один товар може лежати на полиці складу, тоді як інший вже закінчився. Один може мати іншу етикетку. Один може мати власний штрих-код. Структура батьківської, дочерній є ключовою ідеєю. Мастер-товар визначає сімейство. Варіанти товару – це окремі його члени. Замість того, щоб щоразу вводити однакову базову інформацію, ви починаєте з майстер-товару і створюєте реальні комбінації, потрібні вашому бізнесу. Дозвольте навести конкретний приклад. Уявіть, що лінійка джинсів доступна в синьому, чорному та коричневому кольорах. Вона також має розміри XS, S, M, L, XL та XXL. Якби кожен колір був доступний у кожному розмірі, ви мали б 18 комбінацій. Але бізнес рідко продає всі можливі комбінації.

Можливо, сині джинси доступні лише від XS до M чорні, від M до XL. Коричневі починаються з розміру L-Dynamics 365 може розглядати кожну дозволену комбінацію як окремий варіант. Коли хтось додає джинси до замовлення, він обирає параметри, що ідентифікують конкретний товар. Колір і розмір вказують системі, який саме варіант потрібен клієнту. Жодних здогадок про те, яку пару класти в коробку. Ці параметри називаються вимірами продукту. Dynamics 365. Управління ланцюгом постачень включає 5 із них. Це колір, розмір, стиль, конфігурація та версія. Компанія обирає виміри, що підходять для сімейства товарів, а потім групує їх для цього мастер-товару. Давайте швидко пройдемося по них. Колір – це просто. Синій, чорний, коричневий, червоний. Розмір також всім знайомий. Малий, середній, великий або номер розміру взуття. Стиль допомагає розрізняти товари, які мають однакову назву, але виглядають по-різному.

Сорочка може бути вільного або приталеного крою. Стілець може мати стандартний каркас або інше оздоблення. Конфігурація описує обрану збірку або налаштування. Наприклад, машині може знадобитися специфічний двигун, напруга або набір деталей. Вимір конфігурації ідентифікує цей вибір. Версія відстежує зміни продукту з часом. Це найбільш важливо для виробників. Уявіть деталь, яка виконує ту саму функцію, але змінюється після затвердженого інженерного оновлення. Версія дозволяє компанії відрізняти першу версію від другої під час руху ланцюгом постачень. Отже, не кожен мастер товар потребує всіх п'яти вимірів. Футболці можуть знадобитися лише колір і розмір. Обладнанню може знадобитися конфігурація та версія. Група вимірів діє як набір правил для сімейства товарів. Вона вказує Dynamics 365, які параметри застосовувати під час створення та ідентифікації варіантів. Це рішення визначає продукт від самого початку.

Можливо, ви запитаєте про вагу, висоту, довжину, ширину або об'єм. Ці деталі описують фізичний продукт, але вони не створюють варіанти. Пара джинсів може мати зазначену вагу чи розмір упаковки, що не перетворює її на інший товар, як це роблять колір чи розмір. Фізичні розміри описують товар. Розміри продукту ідентифікують конкретний варіант. Розмежування цих двох понять запобігає плутанині в майбутньому. Якщо на складі потрібно знати, скільки місця займає коробка. Фізичні розміри стануть у пригоді. Якщо в замовленні потрібні чорні джинси розміру LATCH, знайдіть правильний варіант. Є один початковий вибір, який впливає на все подальше. Як компанія створюватиме та контролюватиме ці варіанти продукту. І саме це ми розглянемо далі. Налаштування продуктів без створення хаосу. Вибір розмірів підказує Dynamics 365, як ідентифікувати варіант. Але компанія все одно повинна вирішити, як створювати ці варіанти.

Цей вибір залежить від продукту. Управління ланцюгами постачання підтримує три основні підходи. Попередньо визначені варіанти – конфігурація на основі розмірів та конфігурація на основі обмежень. Назви звучать технічно, тому дозвольте пояснити їх простими словами. Попередньо визначені варіанти підходять для товарів із відомим обмеженим набором комбінацій. Уявіть ретейлера, який продає асортимент джинсів, про який ми щойно говорили. Компанія вже знає, які кольори та розміри вона закупуватиме, зберігатиме та продаватиме. Сині бувають розмірів Extra Small, Small та Medium. Чорні бувають розмірів Medium, Large та Extra Large. Коричневі бувають розмірів Large, Extra Large та Double Extra Large. Ці дев'ять варіантів можна створити заздалегідь як окремі варіанти. Бізнесу не потрібна кожна можлива комбінація кольору та розміру. Він створює лише ті комбінації, які існують. Це підтримує каталог у порядку і не дає комусь замовити коричневі джинси розміру Extra Small, коли ніхто їх не виготовляє.

Попередньо визначені варіанти добре працюють, коли асортимент залишається передбачуваним. Швейна компанія – дистриб'ютор із фіксованими розмірами упаковок, бізнес, що продає стандартні кольори меблів. Усі вони можуть підготувати товари, з якими очікують працювати. Кожен варіант існує як відомий товар до надходження замовлення, тому відділи закупівель, складські команди та персонал з продажу можуть працювати з чітким вибором продуктів. Наступний підхід – конфігурація на основі розмірів. Він часто зустрічається у виробництві. Уявіть компанію, яка виготовляє промислові насоси. Одне сімейство насосів може використовувати багато однакових деталей, але клієнт може обрати певну конфігурацію. Цей вибір впливає на те, які компоненти входять до складу готового насоса. Dynamics 365 може використовувати розмір конфігурації, щоб контролювати це. Продукт використовує одну спільну специфікацію матеріалів.

Її часто називають BOM – Bill of Materials. Специфікація матеріалів – це просто перелік деталей для створення чогось. У межах цього списку деякі деталі застосовуються лише тоді, коли клієнт обирає конкретну конфігурацію. Наприклад, насос, розрахований на одну напругу, може потребувати одного двигуна. Для іншої напруги потрібен інший двигун. Замість того, щоб підтримувати окремий перелік деталей для кожного можливого насоса, компанія веде один спільний список. У ньому позначено, які позиції належать до якої конфігурації. Коли обрана конфігурація потрапляє до планування чи виробництва, Dynamics 365 використовує лише ті позиції, що відповідають цьому вибору. Це значно економить час на дублюванні налаштувань. Це також надає виробникам чіткіший спосіб керування родиною продуктів, які мають спільну основу, але відрізняються контрольованими параметрами. Розміри ідентифікують обраний продукт. Специфікація визначає, які деталі входять у цю збірку.

Далі йде конфігурація на основі обмежень. Цей підхід підходить для продуктів, де клієнти можуть обирати з багатьох варіантів, але не кожен варіант сумісний з іншим. Уявіть спеціалізовану машину, лабораторне обладнання або продукт, зібраний із багатьох частин. Клієнт може обрати тип живлення, корпус, двигун, опцію безпеки та панель керування. Деякі комбінації працюють, деякі просто ні. Певний корпус може не підійти для більшого двигуна. Одна напруга може вимагати спеціальної панелі керування. Захисна кришка може працювати лише з одним розміром машини. Без правил менеджер з продажу міг би обрати комбінацію, яку завод не може виготовити. Конфігурація на основі обмежень вносить ці правила в модель конфігурації продукту. Модель описує можливі вибори та правила, що їх обмежують. Коли хтось конфігурує продукт, система спрямовує його до допустимих варіантів. Вона запобігає вибору опцій, що конфліктують між собою.

Це зупиняє неможливе замовлення ще до того, як воно потрапить у виробництво. Я хочу зупинитися тут, оскільки це важливе рішення на ранньому етапі проєктування. Компанія повинна обрати технологію конфігурації, яка відповідає її бізнес-процесу, перш ніж створювати родину продуктів. Dynamics 365 не конвертує продукт з однієї моделі конфігурації в іншу пізніше. Тому ретейлер, що продає фіксований асортимент, не повинен налаштовувати складну модель користувацького продукту лише тому, що це звучить гнучко. А виробник обладнання під замовлення не повинен втискати кожен можливий варіант у довгий список визначених раніше моделей, якщо вибір залежить від правил. Почніть із реального процесу купівлі, продажу та виробництва. Запитайте себе просте питання. Чи знаємо ми всі комбінації продукту до надходження замовлення? Чи клієнт сам створює вибір продукту через набір дозволених опцій? Відповідь вказує бізнесу на правильний підхід.

Коли компанія знає, яким може бути продукт, їй потрібен спосіб чітко описати його та впорядкувати цю інформацію. Категорії, атрибути та контроль інформації про продукт. Назва продукту говорить вам, як він називається, але цього недостатньо, щоб купити, зберігати, продати або пояснити його клієнту. Ось тут на допомогу приходять категорії. Сприймайте категорії як відділи у добре організованому магазині. Компанія може групувати продукти за тим, чим вони є. О, одяг в одному ряду, інструменти в іншому, офісне приладдя – у третьому. Або ж їх можуть групувати за типом роботи, яку потрібно виконати людям. У будь-якому разі мета однакова. Зробити продукти легшими для пошуку та керування. Візьмемо акумуляторний дріль. Відділу продажів потрібно знайти його серед електроінструментів. Команда продукту може віднести його до категорії обладнання на акумуляторах. І тут ося справа в тому, що один продукт може перебувати в кількох категоріях одночасно, якщо вони відповідають різним бізнес-потребам.

Сенс не в тому, щоб намагатися запхнути кожен товар в одну ідеальну папку. Категорії надають бізнесу структурований спосіб організації інформації про продукти, пошуку товарів та роботи з групами пов'язаних позицій. Вони також допомагають людям застосовувати правильну інформацію до товарів, що належать до однієї групи. Категорії роблять багато, але вони не можуть містити кожну деталь. Ось тут і з'являються атрибути. Для пляшки для води атрибутами можуть бути матеріал, місткість, тип кришки, ізоляція, бренд та інструкції з догляду. Для деталі машини це можуть бути розміри, вимоги доживлення, температурний діапазон або технічний стандарт. Атрибути перетворюють загальну назву на корисну інформацію про продукт. Саме на ту, що вам справді потрібна для виконання роботи. Категорії можуть містити атрибути, які мають сенс для продуктів всередині них. Для одягу потрібні дані про тканину, розмір і вказівки щодо прання.

Для електронного обладнання потрібна напруга, деталі гарантії та інформація про сумісність. Це означає, що нікому не потрібно вигадувати випадкові поля для кожного запису продукту. Вони просто використовують деталі, що підходять для цієї групи товарів. Зображення та вкладені файли додають ще один рівень. Фото допомагає працівнику складу, продавцю або клієнту побачити товар, про який йде мова. Вкладення може містити допоміжні матеріали, як от документ від постачальника, специфікацію чи інші папери. Іноді самої лише назви недостатньо. Переклади важливі, коли компанія працює з різними мовами. Назви та описи продуктів можна перекладати, щоб люди на різних ринках отримували зрозуміло їм інформацію. Продукт залишається тим самим, але слова навколо нього адаптуються до аудиторії. Компанії також потрібен контроль над тим, хто може змінювати цю інформацію. Не кожен працівник повинен мати можливість редагувати кожен запис продукту, перейменовувати товар або змінювати деталі, від яких залежать інші команди.

Dynamics 365 дозволяє застосовувати правила доступу до даних про продукти на рівні категорії або для окремого товару. Наприклад, команда «Відповідальна за промислове обладнання» працює з цією категорією, тоді як інша група займається споживчими товарами. Продукт з обмеженим доступом може потребувати суворішого контролю, ніж звичайне офісне приладдя. Бізнес сам вирішує, хто може працювати з кожною ділянкою даних про продукти. Це захищає інформацію, на яку покладаються люди. Запис тепер може містити правильні деталі, документи, категорії та засоби контролю. Але він усе ще потребує схвалення. Перш ніж підрозділи компанії, які купують, продають, зберігають або виробляють його, зможуть фактично ним користуватися. Випуск продуктів для юридичних осіб. Завершене визначення продукту тепер готове до використання всіма автоматично. О, ще ні. Компанія часто працює через кілька юридичних осіб, які є окремими компаніями всередині більшого бізнесу.

Одна юридична особа може купувати та зберігати продукт у Німеччині. Інша продає той самий продукт у Сполучених Штатах. Третя його виробляє. Усі вони можуть розпочинати роботу з одного спільного визначення продукту. У Dynamics 365 це спільне визначення стає випущеним продуктом, коли компанія схвалює його для використання конкретною юридичною особою. Вважайте випуск наданням цьому бізнес-підрозділу дозволу на використання продукту у своїй повсякденній роботі. Продукт не змінює свою ідентичність. Його загальна назва, опис, категорія, розміри та інші спільні деталі залишаються пов'язаними з центральним визначенням, але кожна юридична особа може додати налаштування, необхідні перед замовленням, продажем, зберіганням або виробництвом цього продукту. Одна компанія може купувати продукт у постачальника, інша може лише продавати його. Виробничій компанії потрібні налаштування виробництва, тоді як дистриб'юторські, налаштування складу та запасів.

Деталі продажу відрізняються залежно від юридичної особи. Місцеві бізнес-правила також відрізняються. Випуск дозволяє кожній юридичній особі підготувати продукт для своєї роботи без створення повністю окремого визначення продукту. Уявіть компанію, яка продає ту саму пляшку води в кількох країнах. Команда з розробки продукту створює одне центральне визначення продукту. Потім компанія випускає його для юридичної особи у Великій Британії. І ця юридична особа додає налаштування, необхідні для купівлі та зберігання пляшки. Пізніше той самий продукт випускається для канадської юридичної особи, де працівники завершують налаштування для місцевих продажів та запасів. Обидві компанії використовують той самий продукт. Їм не потрібно починати спочатку з назвою, описом та даними про сімейство продуктів. Вони заповнюють лише ту інформацію, яка стосується їхньої власної юридичної особи. Такий поділ зберігає спільні факти та локальну бізнес-роботу на своїх місцях.

Спільне визначення продукту відповідає на запитання, що це за продукт, а випущений продукт відповідає на інше. Як саме ця конкретна компанія буде його використовувати? Це невелика різниця у формулюванні, але вона запобігає великій кількості дублювання роботи, коли бізнес працює через кілька юридичних осіб. Dynamics 365 може випускати продукти для однієї юридичної особи або кількох одночасно. Це допомагає, коли компанія запроваджує стандартний асортимент продукції для багатьох бізнес-підрозділів. Все ж таки, випуск продукту тепер не є завершальним етапом, натиснув і забув. Кожна юридична особа може потребувати додаткових даних, перш ніж її команди зможуть безпечно працювати з продуктом. Робоча область обслуговування випущених продуктів допомагає стежити за цим процесом. Вона показує нещодавно випущені продукти та перевіряє, чи завершено необхідне налаштування для цієї юридичної особи. Якщо потрібно додати атрибути продукту, категорії, налаштування замовлень або переклади, робоча область надає місце для пошуку цих завдань і відкриття відповідних сторінок продукту.

Вона також допомагає командам виявляти незавершені справи щодо зміни продукту. Це важливо, оскільки продукт може виглядати готовим у центральному поданні, тоді як локальні налаштування залишаються неповними. Робоча область надає юридичній особі практичний список продуктів, що потребують уваги, замість того, щоб змушувати людей переглядати довгі списки. Тож випускник копіює продукт в окремий світ. Він пов'язує одне затверджене визначення продукту з юридичною особою, надаючи їй можливість застосувати власні операційні деталі. Після цього інформація про продукт може бути використана в роботі із замовленнями, запасами та потребами клієнтів. Отже, як PIM поєднує роботу навколо продукту, то як управління інформацією про продукт насправді поєднує роботу навколо продукту. Ось найпростіше визначення. PIM не виконує кожен бізнес-процес самостійно. Натомість він надає інформацію про продукт, необхідну для цих процесів.

Він повинен знайти правильний товар у замовленні на закупівлю. Складська команда потребує правильний товар під час приймання або відбору запасів. Відділ продажів потребує деталі продукту, які мають бути у комерційній пропозиції. Іншим програмам Dynamics 365 також можуть знадобитися дані про продукти. PIM дає всім цим командам одну спільну відправну точку, єдине джерело істини. Тепер, звідки надходять ці дані про продукт? Визначення продуктів можуть створюватися всередині Dynamics 365 Supply Chain Management. Це добре працює, коли компанія керує інформацією про продукт там із самого початку. Але багато компаній вже використовують іншу систему для розробки продукту або обліку продукції. Наприклад, дані про продукт можуть надходити із системи управління життєвим циклом продукту, яку часто називають PLM. Система PLM допомагає командам керувати продуктом під час його проєктування та розробки.

Існує також управління даними про продукт або PDM, яке обробляє дані про продукт та супутні документи. Деякі компанії навіть використовують окрему систему PIM до того, як інформація про продукт потрапляє до Supply Chain Management. Ось хороші новини. Dynamics 365 може імпортувати визначення продуктів із цих систем. Це означає, що вам не потрібно вводити ті самі деталі продукту знову тільки тому, що продукт переходить від проєктування до ланцюга поставок. Supply Chain Management може стати місцем, де зберігаються майстер дані про продукти і для інших екземплярів системи. Це важливо для великих компаній, що мають більше, ніж один екземпляр системи. Один екземпляр керує центральними визначеннями продуктів, а потім експортує та імпортує ці дані в інші. Microsoft надає об'єкти даних для такого обміну, структуровані способи переміщення визначених даних між системами. Але це ще не все. Microsoft Dataverse розширює цей шлях розповсюдження.

Dataverse – це спільна хмарна служба даних Microsoft, яку використовують багато бізнес-додатків. Управління ланцюгами постачання може експортувати визначення продуктів у Dataverse, а інші бізнес-додатки, як от Dynamics 365 Sales, можуть використовувати ці дані про продукти. Це не означає, що тепер кожен додаток виконує ту саму роботу. PM організовує та підтримує інформацію про продукт. Dynamics 365 Sales займається процесами продажу. Інші додатки відповідають за власне обслуговування клієнтів, комерцію, фінанси, виробництво або операційні завдання. Вони можуть використовувати відповідні дані про продукти, але кожен додаток зберігає своє призначення. Розгляньмо практичний процес. Команда з продуктів створює або імпортує нове визначення продукту. Бізнес надає його юридичним особам, яким це потрібно. Ці підрозділи завершують своє локальне налаштування. Відділ закупівель може працювати із затвердженим товаром.

Працівники складу можуть отримувати та опрацьовувати його. Відділ продажів може посилатися на правильний продукт, замість того, щоб створювати власну версію. Результат проявляється у звичайних моментах. Покупець замовляє потрібний товар. Клієнт бачить правильні деталі, а складський працівник може зіставити замовлення з товаром перед собою. Коли інформація про продукт змінюється, команди мають чіткіший шлях використання поточних затверджених даних замість пошуку старих копій. Це зменшує кількість помилок при замовленні, застарілої інформації та повернень через неправильні дані про продукт. Управління інформацією про продукт – це частина, яка тримає визначення продукту впорядкованим, поки решта підключеної платформи використовує цю інформацію в роботі. Висновок «Одна спільна історія продукту в Dynamics» 365 Product Information Management перетворює ідею продукту на один контрольований запис, який юридичні особи та бізнес-команди можуть використовувати у своїй роботі.

Це ваш самородок знань на сьогодні. Підписуйтесь на улюбленій подкаст-платформі та поділіться цим із тими, хто вивчає Dynamics 365. А потім переходьте до наступного епізоду, щоб побачити, як усі ці блоки поєднуються між собою.