WEBVTT

00:00:00.000 --> 00:00:06.120
販売部門の製品名と倉庫の製品名が一致せず オンラインストアには昨年の写真が掲載されたままだったらどうなるでしょうか

00:00:06.120 --> 00:00:12.700
誰かが間違った商品を注文してしまいます 購入者が詳細を尋ねても誰も答えられずスタッフはスプレッドシートや古いメール

00:00:12.700 --> 00:00:18.700
サプライヤーの pdf 5つもの異なるシステムを確認し始め 単純な質問に答えるためだけに奔走します

00:00:18.700 --> 00:00:27.840
m 365踏みを積むどもペターズによるナレッジナゲットへようこそ 今日はダイナミクス365の製品情報管理

00:00:27.840 --> 00:00:32.500
略してピムを取り上げます この動画を見終わる頃にはピムがどのように製品レコードを一つに共有

00:00:32.500 --> 00:00:38.040
保持するのかを理解できるはずです 製品がどのように多様な形態で存在しその情報が必要なビジネス部門へどのように

00:00:38.040 --> 00:00:44.420
届けられるのかを見ていきます 全社で一つの製品レコードを外から見ると製品とはシンプルなものに思えるかもしれません

00:00:44.420 --> 00:00:50.820
単なる名前と価格そして写真があるだけのように見えます しかし裏側ではその同じ製品が企業のほぼすべての部門に関わっています

00:00:50.820 --> 00:00:58.020
その仕組みはこうです 購買部門にはサプライヤーの詳細と単位が必要ですが倉庫チームには商品の受け入れ保管ピッキングのための情報が必要です

00:00:58.020 --> 00:01:04.080
販売部門には明確な名称が必要です 経理部門には正確な設定が必要でオンラインストアには正確な写真と説明文が必要です

00:01:04.080 --> 00:01:10.200
各チームは同じ製品を異なる角度から見ています 情報の共有場所がないと人々は各自でコピーを作成しがちです

00:01:10.200 --> 00:01:14.900
製品チームはスプレッドシートを管理します 販売部門はシステムにより短い名前を入力します

00:01:14.900 --> 00:01:21.720
倉庫部門は異なる説明がついた品目番号を使い マーケティング部門は共有フォルダに画像を保存しカスタマーサービスは過去のメールを掘り返します

00:01:21.720 --> 00:01:28.640
そのようなやり方では最初は小さな違いが生まれやがてそのズレが拡大していきます 断熱水筒を販売する会社を想像してみてください

00:01:28.640 --> 00:01:36.540
サプライヤーが容量を500mlから750mlに変更し 購買チームはその詳細を把握していてもオンラインストアには古い容量のまま記載されているかもしれません

00:01:36.540 --> 00:01:42.260
販売担当者は顧客に間違った使用書を送り 倉庫スタッフは注文と一致しない製品ラベルを目にすることになります

00:01:42.260 --> 00:01:47.220
誰も問題を起こそうとしたわけではありません 各チームがそれぞれ異なるコピーを見て作業していただけなのです

00:01:47.220 --> 00:01:55.380
ダイナミクス365の製品情報管理は企業に唯一の中心的な製品定義を提供します 製品情報の共有ファイルキャビネットのようなものだと考えてください

00:01:55.380 --> 00:02:00.500
すべての部門が独自のフォルダを持つ代わりに製品レコードが合意済みの詳細情報を保持する唯一の場所となります

00:02:00.500 --> 00:02:08.680
人々はその定義を業務全体で利用し同じ情報を何度も入力し直す必要はなくなります 製品番号がそのレコードの中心に位置します

00:02:08.680 --> 00:02:14.580
たとえ異なるチームが異なる言葉でその製品を呼んでいたとしても会社として一貫して製品を識別する助けとなります

00:02:14.580 --> 00:02:22.160
その番号に付随して名前や説明を保存しそれが在庫可能な物理的製品なのか会社が提供するサービスなのかを識別します

00:02:22.160 --> 00:02:26.960
その記録には製品の購入販売保管または係数の際に使用する単位も含まれます

00:02:26.960 --> 00:02:31.340
箱、子、キログラム、リットル、パレットといった単位は日々の業務において全く異なる意味を持つことがあります

00:02:31.340 --> 00:02:35.460
これらの単位が明確であれば購買業務や倉庫業務はより良い出発点に立つことができます

00:02:35.460 --> 00:02:41.260
製品情報には画像、添付ファイル、カテゴリ、属性、名前や説明の翻訳データなども保持できます

00:02:41.260 --> 00:02:44.540
つまり製品記録にはラベル以上の情報を含めることができるのです

00:02:44.540 --> 00:02:55.380
製品を説明するサプライヤーの資料、製品を識別するための写真、異なる言語を使用するチームや顧客向けの翻訳された説明文、さらに素材、ブランド、取扱説明といった詳細情報も保持できます

00:02:55.380 --> 00:02:58.140
共有定義はローカルでの使用に先立ちます

00:02:58.140 --> 00:03:02.720
企業は製品を一度定義すれば、あとはビジネスの各部門が必要に応じてそれを利用できるようになります

00:03:02.720 --> 00:03:07.780
共有された記録は共通の事実を一箇所にまとめ、各部門が後から独自のビジネス設定を適用できるようにします

00:03:07.780 --> 00:03:12.040
チームが製品を必要とするたびに、ゼロから作り直す必要はありません

00:03:12.040 --> 00:03:18.720
これは非常にスッキリとした業務の進め方ですが、名前と説明だけでは製品のすべてを語ることはできません

00:03:18.720 --> 00:03:23.160
ジーンズも色やサイズが加われば、いくつものアイテムに分かれます

00:03:23.160 --> 00:03:26.700
製品マスターとバリアント、それはファミリーツリーのようなものです

00:03:26.700 --> 00:03:30.180
ではいつ、一つの製品が多くの製品へと変わるのでしょうか?

00:03:30.320 --> 00:03:31.880
ジーンズを例に考えてみましょう

00:03:31.880 --> 00:03:36.400
あなたはジーンズを一つの製品とみなすかもしれませんが、倉庫では黒のLサイズという注文に対して

00:03:36.400 --> 00:03:37.940
どのジーンズでも良いというわけにはいきません

00:03:37.940 --> 00:03:42.220
また、営業部門も実際には存在しない青のXSサイズという組み合わせを約束することはできません

00:03:42.220 --> 00:03:45.080
そこでダイナミクス365のシンプルなアイデアが役立ちます

00:03:45.080 --> 00:03:47.900
それは基本的な製品と製品マスターを分けるという考え方です

00:03:47.900 --> 00:03:50.500
シンプルな製品とは、一つの固定されたアイテムのことです

00:03:50.500 --> 00:03:54.780
一つのサイズ、一つの色、一つの形式で販売されるプリンター用紙の箱を想像してみてください

00:03:54.780 --> 00:03:58.840
その製品にはアイテムの内容を変えるような選択肢がないため、専用の製品記録が一つだけ存在します

00:03:58.840 --> 00:04:00.860
製品マスターは異なる仕組みで機能します

00:04:00.860 --> 00:04:03.280
それは製品ファミリー全体の親記録となります

00:04:03.280 --> 00:04:07.240
そこには共有される詳細情報や個別のアイテムを作成するための選択ルールが保持されています

00:04:07.240 --> 00:04:08.340
仕組みはこうです

00:04:08.340 --> 00:04:13.640
ジーンズの製品マスターには、その範囲内のすべてのジーンズに共通する名前、基本説明、共通情報が記載されています

00:04:13.640 --> 00:04:18.400
そして、個々のバリアントが実際に購入、保管、生産、出荷される特定のジーンズを識別します

00:04:18.400 --> 00:04:20.780
バリアントとは、販売可能な特定のアイテムのことです

00:04:20.780 --> 00:04:23.060
ジーンズの場合青のMサイズが一つのバリアントになります

00:04:23.060 --> 00:04:24.980
黒のLサイズが別のバリアントになります

00:04:24.980 --> 00:04:27.760
これらは同じ製品ファミリーに属していますが、互換性はありません

00:04:27.760 --> 00:04:30.500
一方は倉庫の棚にあり、もう一方は在庫切れという状況もありえます

00:04:30.500 --> 00:04:32.220
一方は異なるラベルを使用するかもしれません

00:04:32.220 --> 00:04:33.960
一方は独自のバーコードを持っているかもしれません

00:04:33.960 --> 00:04:35.900
この親とこの構造が重要な考え方です

00:04:35.900 --> 00:04:37.680
製品マスターがファミリーを定義します

00:04:37.680 --> 00:04:39.840
製品バリアントは個々のメンバーです

00:04:39.840 --> 00:04:45.620
同じ基本情報を何度も入力する代わりに、マスターから始めてビジネスに必要な実際の組み合わせを作成します

00:04:45.620 --> 00:04:47.280
具体的な例を挙げましょう

00:04:47.280 --> 00:04:50.360
ジーンズのラインナップに青、黒、茶色があると想像してください

00:04:50.360 --> 00:04:54.580
サイズもXS、S、M、L、XL、XXLと揃っています

00:04:54.580 --> 00:04:57.720
全ての色が全てのサイズであれば18通りの組み合わせができます

00:04:57.720 --> 00:05:00.400
しかし、全ての可能な組み合わせを販売する企業は稀です

00:05:00.400 --> 00:05:02.820
例えば、青はXSからMまでしかないかもしれません

00:05:02.820 --> 00:05:04.580
黒はMからXLまでです

00:05:04.580 --> 00:05:06.020
茶色はLから始まります

00:05:06.020 --> 00:05:09.720
ダイナミクス365は許可された各組み合わせを個別のバリアントとして扱います

00:05:09.720 --> 00:05:13.560
誰かが注文にジーンズを追加するとき、正確な製品を特定するディメンションを選択します

00:05:13.560 --> 00:05:16.560
色とサイズで顧客がどのバリアントを求めているかをシステムに伝えます

00:05:16.560 --> 00:05:18.740
箱にどのペアを入れるか迷うことはありません

00:05:18.740 --> 00:05:21.300
これらの選択肢は製品ディメンションと呼ばれます

00:05:21.300 --> 00:05:22.940
ダイナミクス365

00:05:22.940 --> 00:05:25.640
サプライチェーン管理にはそのうち5つが含まれています

00:05:30.400 --> 00:05:33.080
ディメンションを選択し、その製品マスターに対してグループ化します

00:05:33.080 --> 00:05:34.800
これらを簡単に見ていきましょう

00:05:34.800 --> 00:05:36.020
色は単純です

00:05:36.020 --> 00:05:37.720
青、黒、茶色、赤

00:05:37.720 --> 00:05:39.440
サイズも馴染み深いものです

00:05:39.440 --> 00:05:42.460
S、M、L、あるいは靴のサイズ番号などです

00:05:42.460 --> 00:05:45.460
スタイルは名前は同じでも見た目が異なる製品を区別できます

00:05:45.460 --> 00:05:47.840
シャツならレギュラーフィットやスリムフィットなどがあります

00:05:47.840 --> 00:05:50.480
椅子なら標準フレームや異なる仕上げなどがあるでしょう

00:05:50.480 --> 00:05:53.140
構成は選択されたビルドやセットアップを表します

00:05:53.140 --> 00:05:56.980
例えば機械には特定のモーター、電圧、一連の部品が必要になる場合があります

00:05:56.980 --> 00:05:59.260
構成ディメンションはその選択を識別します

00:05:59.260 --> 00:06:02.060
バージョンは時間の経過に伴う製品の変更を追跡します

00:06:02.060 --> 00:06:04.340
これは製造業者にとって最も重要です

00:06:04.340 --> 00:06:08.360
目的は同じでも承認されたエンジニアリングの更新後に変更される部品を想像してください

00:06:08.360 --> 00:06:12.460
バージョンによりサプライチェーン内を移動する際にバージョン1とバージョン2を区別できます

00:06:12.460 --> 00:06:15.560
すべての製品マスターが5つすべてのディメンションを必要とするわけではありません

00:06:15.560 --> 00:06:17.940
Tシャツなら色とサイズだけで十分かもしれません

00:06:17.940 --> 00:06:20.580
機器であれば構成とバージョンが必要になるでしょう

00:06:20.580 --> 00:06:23.720
ディメンショングループは製品ファミリーのルールシートのように機能します

00:06:23.720 --> 00:06:28.380
バリアントを作成、識別する際にどの選択肢が適用されるかをダイナミクス365に伝えます

00:06:28.380 --> 00:06:30.840
その決定が最初から製品を片づくります

00:06:30.840 --> 00:06:34.680
重量、高さ、長さ、幅、体積についてはどうだろうと思うかもしれません

00:06:34.680 --> 00:06:38.680
それらの詳細は物理的な製品を説明しますがバリアントを作成するものではありません

00:06:38.680 --> 00:06:41.240
ジーンズには記載された重量やパッケージサイズがあっても

00:06:41.240 --> 00:06:44.040
それによって色やサイズのように別アイテムに変わることはありません

00:06:44.040 --> 00:06:46.580
物理的寸法は製品そのものを表します

00:06:46.580 --> 00:06:49.220
製品寸法は特定のバリエーションを識別します

00:06:49.220 --> 00:06:52.140
この2つの考え方を分けておくことで5の混乱を防げます

00:06:52.140 --> 00:06:55.120
倉庫でカートンがどれだけのスペースを占有するかを知る必要がある場合

00:06:55.120 --> 00:06:56.500
物理的寸法が役に立ちます

00:06:56.500 --> 00:07:00.380
黒いジーンズのLサイズという注文があれば製品寸法で正しいバリエーションを見つけます

00:07:00.380 --> 00:07:03.180
その後の全てに影響する重要な選択が最初に1つあります

00:07:03.180 --> 00:07:06.360
会社はどのように製品バリエーションを作成し管理するのでしょうか

00:07:06.360 --> 00:07:08.500
それこそが次に説明することです

00:07:08.500 --> 00:07:11.120
混乱を招かずに製品を構成する方法についてです

00:07:11.120 --> 00:07:14.740
寸法を選択することでダイナミクス365にバリエーションの識別方法を伝えます

00:07:14.740 --> 00:07:17.860
しかし企業はバリエーションをどのように作成するかを決める必要があります

00:07:17.860 --> 00:07:19.860
その選択は製品によって異なります

00:07:19.860 --> 00:07:23.220
サプライチェーン管理では3つの主要なアプローチをサポートしています

00:07:23.220 --> 00:07:24.700
定義済みバリエーション

00:07:24.700 --> 00:07:25.920
寸法ベースの構成

00:07:25.920 --> 00:07:28.340
そして制約ベースの構成です

00:07:28.340 --> 00:07:31.440
名前は専門的ですが分かりやすく説明しましょう

00:07:31.440 --> 00:07:35.260
定義済みバリエーションは組み合わせが限定的で基地の製品に適しています

00:07:35.260 --> 00:07:38.200
先ほど議論したジーンズを扱う小売業者を想像してください

00:07:38.200 --> 00:07:41.540
会社はどの色とサイズを仕入れ在庫し販売するかをすでに把握しています

00:07:41.540 --> 00:07:43.860
青はXSSMサイズがあります

00:07:43.860 --> 00:07:46.220
黒はMLXLサイズがあります

00:07:46.220 --> 00:07:49.120
茶色はLXLXXLサイズがあります

00:07:49.120 --> 00:07:52.240
これら9つの選択肢は個別のバリエーションとしてあらかじめ作成できます

00:07:52.240 --> 00:07:55.440
企業は考えられる全ての色とサイズの組み合わせを持つ必要はありません

00:07:55.440 --> 00:07:58.080
実際に存在する組み合わせのみを作成すれば良いのです

00:07:58.080 --> 00:08:03.040
これによりカタログはすっきりと持たれ存在しないはずの茶色のXSサイズの注文を防ぐことができます

00:08:03.040 --> 00:08:06.280
定義済みバリエーションは範囲が予測可能な場合にうまく機能します

00:08:06.280 --> 00:08:11.120
医療品会社固定パッケージサイズの販売業者標準的な家具の色を販売するビジネスなどが挙げられます

00:08:11.120 --> 00:08:14.120
これらはいずれも扱うと予想される品目をあらかじめ準備できます

00:08:14.120 --> 00:08:17.020
注文が届く前に各バリエーションが基地の品目として存在するため

00:08:17.020 --> 00:08:20.620
購買・倉庫・販売の担当者は明確な選択肢に基づいて作業できます

00:08:20.620 --> 00:08:23.260
次のアプローチは寸法ベースの構成です

00:08:23.260 --> 00:08:25.080
これは製造業でよく見られます

00:08:25.080 --> 00:08:27.620
工業用ポンプを製造する会社を想像してください

00:08:27.620 --> 00:08:32.080
同じポンプ製品群でも多くの部品を共有しますが顧客は特定の構成を選択できます

00:08:32.080 --> 00:08:35.640
その選択が完成したポンプに含まれるコンポーネントを決定します

00:08:35.640 --> 00:08:39.280
ダイナミクス365では構成寸法を使用してそれを制御できます

00:08:39.280 --> 00:08:42.160
この製品は共通の部品表ボムを使用します

00:08:42.160 --> 00:08:44.540
ああボムボムと呼ばれることもよくありますね

00:08:44.540 --> 00:08:47.720
部品表とは単に何かを構築するための部品リストのことです

00:08:47.720 --> 00:08:52.040
その一つのリストの中で特定の構成を選択した場合のみ適用される部品があります

00:08:52.040 --> 00:08:55.820
例えば特定の電圧用に製造されたポンプには特定のモーターが必要になる場合があります

00:08:55.820 --> 00:08:58.160
異なる電圧には別のモーターが必要です

00:08:58.160 --> 00:09:01.020
考えられるすべてのポンプに対して個別の部品リストを管理する代わりに

00:09:01.020 --> 00:09:02.680
会社は一つの共有リストを保持します

00:09:02.680 --> 00:09:05.600
そしてどの業がどの構成に属するかをマークするのです

00:09:05.600 --> 00:09:11.300
選択された構成が計画や生産の段階に達するとダイナミクス365はその選択に適合する部品構成のみを使用します

00:09:11.300 --> 00:09:14.060
これにより重複した設定作業が大幅に削減されます

00:09:14.060 --> 00:09:19.580
また製造業者は基本構造は共通でも一部が異なる製品群をより明確に管理できるようになります

00:09:19.580 --> 00:09:22.380
ディメンションによって選択された製品が特定されます

00:09:22.380 --> 00:09:25.640
部品表ボムがその構成に必要な部品を案内します

00:09:25.640 --> 00:09:27.800
次に製薬ベースの構成があります

00:09:27.800 --> 00:09:30.960
この手法は顧客が多くの選択肢から選べる製品に適しています

00:09:30.960 --> 00:09:33.940
しかし全ての選択肢が他の全ての選択肢と組み合わさるとは限りません

00:09:33.940 --> 00:09:37.820
カスタム機械や実験装置あるいは多くの部品から組み立てられる製品を想像してください

00:09:37.820 --> 00:09:42.360
顧客は電源タイプ、ハウジング、モーター、安全オプション、操作パネルを選択するかもしれません

00:09:42.360 --> 00:09:45.060
うまく機能する組み合わせもあればそうでないものもあります

00:09:45.060 --> 00:09:47.780
あるハウジングには大型のモーターが収まらない場合があります

00:09:47.780 --> 00:09:50.480
特定の電圧では特定の操作パネルが必要になることがあります

00:09:50.480 --> 00:09:53.140
安全カバーは特定の機械サイズでしか使えないかもしれません

00:09:53.140 --> 00:09:57.040
ルールがなければ営業担当者が工場では製造不可能な組み合わせを選んでしまう可能性があります

00:09:57.040 --> 00:10:00.720
制約ベースの構成はそれらのルールを製品構成モデルに組み込みます

00:10:00.720 --> 00:10:03.920
モデルは可能な選択肢とそれらを制限するルールを定義します

00:10:03.920 --> 00:10:07.580
ユーザーが製品を構成する際システムは有効な選択肢へと導きます

00:10:07.580 --> 00:10:09.900
互いに矛盾する選択を防ぐことができます

00:10:09.900 --> 00:10:13.000
これにより不可能な注文が生産現場に届くのを未然に防ぎます

00:10:13.000 --> 00:10:16.520
これは設計の初期段階で決めるべき重要な決定事項ですので少し詳しく説明します

00:10:16.520 --> 00:10:21.840
企業は製品ファミリーを構築する前に自社の業務プロセスに適した構成技術を選択する必要があります

00:10:21.840 --> 00:10:26.560
ダイナミクス365では後から製品を別の構成モデルに変換することはできません

00:10:26.560 --> 00:10:32.720
そのため固定の製品範囲を販売する小売業者が単に柔軟そうだからといって複雑なカスタム製品モデルを構築すべきではありません

00:10:32.720 --> 00:10:36.420
また受注生産の装置を製造するメーカーも選択にルールが伴うならば

00:10:36.420 --> 00:10:39.720
考えられるすべての構成を事前に定義された長いリストに押し込めるべきではありません

00:10:39.720 --> 00:10:42.920
実際の購入販売および生産プロセスから始めてください

00:10:42.920 --> 00:10:44.560
シンプルな質問をしてみましょう

00:10:44.560 --> 00:10:47.540
注文が来る前にすべての製品の組み合わせを把握していますか

00:10:47.540 --> 00:10:50.800
それとも顧客が許可された選択肢の中から選んで製品を作り上げますか

00:10:50.800 --> 00:10:53.780
その答えが企業にとっての正しいアプローチを指し示します

00:10:53.780 --> 00:10:59.300
製品がどのようなものになるかが決まったらそれを明確に説明し情報を整理しておく必要があります

00:10:59.300 --> 00:11:02.880
カテゴリー属性そして製品情報の管理です

00:11:02.880 --> 00:11:09.680
製品名はそれが何であるかを示しますがそれだけでは購入保管販売あるいは顧客への説明には不十分です

00:11:09.680 --> 00:11:11.620
そこでカテゴリーの出番となります

00:11:11.620 --> 00:11:14.860
カテゴリーは整理された店舗の通路のようなものだと考えてください

00:11:14.860 --> 00:11:17.560
企業は製品をその種類ごとにグループ化するかもしれません

00:11:17.560 --> 00:11:21.480
例えばある通路には衣類別の通路には工具さらに別の通路には事務用品が並んでいます

00:11:21.480 --> 00:11:24.260
あるいは人々の作業の種類ごとに分類されているかもしれません

00:11:24.260 --> 00:11:26.100
どちらにせよ目的は同じです

00:11:26.100 --> 00:11:28.180
製品を見つけやすく管理しやすくすることです

00:11:28.180 --> 00:11:29.620
コードレスドリルを例に挙げましょう

00:11:32.880 --> 00:11:35.680
バッテリー駆動機器というカテゴリーに入れるかもしれません

00:11:35.680 --> 00:11:38.700
ここで重要なのはビジネス上のニーズが異なれば

00:11:38.700 --> 00:11:42.120
一つの製品を同時に複数のカテゴリーに分類できるという点です

00:11:42.120 --> 00:11:46.360
大切なのは全ての製品を一つの完璧なホルダに無理やり詰め込もうとしないことです

00:11:46.360 --> 00:11:49.280
カテゴリーにより企業は製品情報を体系的に整理し

00:11:49.280 --> 00:11:52.600
製品を検索し関連するアイテム群を管理できるようになります

00:11:52.600 --> 00:11:56.100
また関連する製品に対して適切な情報を適用するのにも役立ちます

00:11:56.100 --> 00:11:57.580
カテゴリーには多くの役割がありますが

00:11:57.580 --> 00:11:59.600
全ての詳細情報を保持できるわけではありません

00:11:59.600 --> 00:12:01.500
そこで登場するのが属性です

00:12:01.500 --> 00:12:07.480
水筒の場合属性には素材、容量、蓋のタイプ、断熱性、ブランド、お手入れ方法などが含まれます

00:12:07.480 --> 00:12:12.820
機械部品の場合、寸法、電力要件、温度範囲、技術規格などが含まれるでしょう

00:12:12.820 --> 00:12:16.540
属性は大まかなラベルを有用な製品情報へと変えてくれます

00:12:16.540 --> 00:12:19.180
つまり業務に必要な情報そのものです

00:12:19.180 --> 00:12:23.020
カテゴリーにはその中の製品に適した属性を持たせることができます

00:12:23.020 --> 00:12:26.440
衣類には記事、フィット感、選択方法が必要です

00:12:26.440 --> 00:12:30.540
電子機器には電圧、保証の詳細、互換性情報が必要です

00:12:30.540 --> 00:12:34.060
つまり製品レコードごとにその都度ランダムなフィールドを作成する必要はありません

00:12:34.060 --> 00:12:36.740
製品グループにあった詳細情報を使用すれば良いのです

00:12:36.740 --> 00:12:39.180
画像や添付ファイルはさらなる詳細を補足します

00:12:39.180 --> 00:12:44.020
写真があれば倉庫の作業員、営業担当者、顧客は扱っているあるいは話題にしているアイテムをすぐに指認できます

00:12:44.020 --> 00:12:48.600
添付ファイルにはサプライヤーの文書、使用書その他の書類などの参考資料を保持できます

00:12:48.600 --> 00:12:51.480
時には名称だけでは不十分なこともあります

00:12:51.480 --> 00:12:54.620
他言語でビジネスを展開する場合、翻訳が重要になります

00:12:54.620 --> 00:12:59.140
製品名や説明を翻訳することで異なる市場の人々にも理解できる情報を届けられます

00:12:59.140 --> 00:13:02.480
製品自体は同じでも周囲の説明をターゲット層に合わせることができます

00:13:02.480 --> 00:13:05.740
企業はまた誰がこの情報を変更できるかを管理する必要があります

00:13:05.740 --> 00:13:12.040
すべての従業員がすべての製品レコードを編集したり、アイテム名を変更したり、他チームが依存する詳細情報を変更できたりすべきではありません

00:13:12.040 --> 00:13:17.760
ダイナミクス365では製品データへのアクセスルールをカテゴリ単位、または個々の製品単位で適用できます

00:13:17.760 --> 00:13:23.700
例えば、産業機器を担当するチームはそのカテゴリを扱い、別のグループが消費者向け製品を担当するといった具合です

00:13:23.700 --> 00:13:27.860
制限付きの製品には一般的な事務用品よりも厳格な管理が必要になる場合があります

00:13:27.860 --> 00:13:31.480
製品データの各領域を誰が扱えるかを決定するのは企業自身です

00:13:31.480 --> 00:13:34.020
それにより人々が頼りにする情報が保護されます

00:13:34.020 --> 00:13:37.920
記録には適切な詳細、文書、カテゴリ、および管理項目が備わっているかもしれません

00:13:37.920 --> 00:13:43.480
しかし製品の購入、販売、在庫、製造を行う部門が実際に使用する前には承認が必要です

00:13:43.480 --> 00:13:45.680
製品を法的実態にリリースする

00:13:45.680 --> 00:13:50.480
完成した製品定義ができれば自動的に誰もが使える状態になるのでしょうか

00:13:50.480 --> 00:13:51.600
いいえ、まだです

00:13:51.600 --> 00:13:57.000
企業は多くの場合、複数の法的実態、大きな組織内の個別の会社を通じて運営されています

00:13:57.000 --> 00:13:59.860
ある法的実態はドイツで製品を購入し在庫するかもしれません

00:13:59.860 --> 00:14:02.080
別の法的実態は同じ製品をアメリカで販売します

00:14:02.080 --> 00:14:04.300
3番目の法的実態はそれを製造するかもしれません

00:14:04.300 --> 00:14:06.880
これらすべてが同じ共有の製品定義から開始できます

00:14:06.880 --> 00:14:13.560
ダイナミクス365ではその共有定義が特定の法的実態による使用を会社が承認した時点でリリース製品となります

00:14:13.560 --> 00:14:18.380
リリースとはそのビジネスユニットが製品を日々の業務に組み込むための許可を与えることだと考えてください

00:14:18.380 --> 00:14:21.060
製品がその同一性を変えるわけではありません

00:14:21.060 --> 00:14:25.940
共通の名称、説明、カテゴリ、寸法、その他の共有詳細は中央の定義と繋がったままですが

00:14:25.940 --> 00:14:31.140
各法的実態はその製品の注文、販売、保管、または製造を行う前に必要な設定を追加できます

00:14:31.140 --> 00:14:33.840
ある会社はサプライヤーから製品を購入するかもしれません

00:14:33.840 --> 00:14:35.980
別の会社は販売のみを行うかもしれません

00:14:35.980 --> 00:14:40.560
製造会社には製造設定が必要ですが流通会社には倉庫や在庫の設定が必要です

00:14:40.560 --> 00:14:43.280
販売の詳細は法的実態ごとに異なります

00:14:43.280 --> 00:14:45.140
現地のビジネスルールも異なります

00:14:45.140 --> 00:14:48.960
リリース機能により各法的実態は全く別の製品定義を作成することなく

00:14:48.960 --> 00:14:51.060
自らの業務に合わせて製品を準備できます

00:14:51.060 --> 00:14:54.360
複数の国で同じ水筒を販売する会社を想像してみてください

00:14:54.360 --> 00:14:57.340
製品チームが一つの中央製品定義を作成します

00:14:57.340 --> 00:15:00.700
次に会社はその製品をイギリスの法的実態にリリースします

00:15:00.700 --> 00:15:05.060
そしてその法的実態は水筒の購入と保管に必要な設定を追加します

00:15:05.060 --> 00:15:08.240
その後同じ製品がカナダの法的実態にリリースされ

00:15:08.240 --> 00:15:10.920
現地の販売と在庫のための設定が完了します

00:15:10.920 --> 00:15:12.960
両社とも同じ製品を使用します

00:15:12.960 --> 00:15:17.260
名前や説明製品ファミリーの詳細を最初から入力し直す必要はありません

00:15:17.260 --> 00:15:20.340
自社の法的実態に属する情報のみを保管すれば良いのです

00:15:20.340 --> 00:15:23.980
この分離により共有の事実と現地の業務がそれぞれ適切な場所に維持されます

00:15:23.980 --> 00:15:27.580
共有製品定義はこの製品は何なのかという問いに答えます

00:15:27.580 --> 00:15:29.460
リリース製品は別の問いに答えます

00:15:29.460 --> 00:15:32.300
この特定の会社はそれをどのように使うのかという問いです

00:15:32.300 --> 00:15:33.840
言葉の上ではわずかな違いですが

00:15:33.840 --> 00:15:37.700
複数の法的実態にまたがって事業を行う際の多くの重複作業を防ぐことができます

00:15:37.700 --> 00:15:42.600
ダイナミクス365では製品を一つの法的実態または複数の法的実態に同時にリリースできます

00:15:42.600 --> 00:15:47.040
これは企業が多くのビジネスユニット全体で標準的な製品群を導入する際に役立ちます

00:15:47.040 --> 00:15:51.200
それでもリリースは今やボタンを押して忘れるだけのステップを模倣するものとなっています

00:15:51.200 --> 00:15:55.840
各法人はチームがその製品を安全に取り扱う前に追加の詳細情報を必要とする場合があります

00:15:55.840 --> 00:15:59.600
リリース済み製品のメンテナンスワークスペースはそのプロセスの監視に役立ちます

00:15:59.600 --> 00:16:05.000
これには最近リリースされた製品が表示されその法人に必要な設定が完了しているかどうかが確認されます

00:16:05.000 --> 00:16:09.360
製品の属性カテゴリ注文設定または翻訳を追加する必要がある場合

00:16:09.360 --> 00:16:13.600
このワークスペースから該当する作業を見つけ関連する製品ページを開くことができます

00:16:13.600 --> 00:16:17.420
またチームが未完了の製品変更案件を見つけるのにも役立ちます

00:16:17.420 --> 00:16:22.640
中央のビューでは製品が準備完了に見えてもローカル設定が不完全な場合があるためこれは重要です

00:16:22.640 --> 00:16:28.760
このワークスペースは長いリストを検索させる代わりに法人が対応を必要とする製品の実用的なリストを提供します

00:16:28.760 --> 00:16:32.440
つまりリリースは製品を別の世界にコピーするわけではありません

00:16:32.440 --> 00:16:38.380
承認された一つの製品定義を法人に接続しその法人が独自の運用詳細を適用する余地を与えます

00:16:38.380 --> 00:16:43.900
それが完了すると製品情報は注文在庫顧客ニーズに関連する業務へと移行できます

00:16:43.900 --> 00:16:47.020
ではピムは製品にまつわる業務をどのように結びつけるのでしょうか

00:16:47.020 --> 00:16:50.540
製品情報管理は具体的にどのように製品にまつわる業務を結びつけるのでしょうか

00:16:50.540 --> 00:16:52.460
最もシンプルな定義は次の通りです

00:16:52.460 --> 00:16:55.260
ピムは全てのビジネスプロセスを単独で実行するわけではありません

00:16:55.260 --> 00:16:58.300
その代わりにそれらのプロセスが必要とする製品情報を供給します

00:16:58.300 --> 00:17:01.080
製品データのマスターファイリングキャビネットと考えてください

00:17:01.080 --> 00:17:04.200
購買担当者は発注書き上げで適切な品目を見つける必要があります

00:17:04.200 --> 00:17:07.820
倉庫チームは在庫の受け入れやピッキングの際に正しい品目を確認する必要があります

00:17:07.820 --> 00:17:11.020
営業チームは見積り注文に必要な製品詳細を必要とします

00:17:11.020 --> 00:17:14.420
また他のダイナミクス365アプリも製品データを必要とする場合があります

00:17:14.420 --> 00:17:18.400
ピムはそれらすべてのチームに信頼できる唯一のソースへの共通の出発点を提供します

00:17:18.400 --> 00:17:20.900
ではその製品データはどこから来るのでしょうか

00:17:20.900 --> 00:17:24.860
製品定義はダイナミクス365サプライチェーンマネジメント内で作成を開始できます

00:17:24.860 --> 00:17:28.580
企業が最初からそこで製品情報を管理している場合これはうまく機能します

00:17:28.580 --> 00:17:32.620
しかし多くの企業は製品開発や製品記録のためにすでに別のシステムを使用しています

00:17:32.620 --> 00:17:36.760
例えば製品データはPLMと呼ばれることが多い製品ライフサイクル管理システムから取得できます

00:17:36.760 --> 00:17:40.860
PLMシステムはチームが設計や開発業務を通じて製品を管理するのに役立ちます

00:17:40.860 --> 00:17:45.240
製品データや関連ドキュメントを扱う製品データ管理PDMというものもあります

00:17:45.240 --> 00:17:49.740
製品情報がサプライチェーンマネジメントに入る前に別のPIMシステムを使用している企業もあります

00:17:49.740 --> 00:17:51.160
ここで良いニュースがあります

00:17:51.160 --> 00:17:54.740
ダイナミクス365はそれらのシステムから製品定義をインポートできます

00:17:54.740 --> 00:18:00.040
つまり製品が設計からサプライチェーン業務に移行したというだけで同じ製品詳細を再度入力する必要はありません

00:18:00.040 --> 00:18:04.620
サプライチェーンマネジメントは他のインスタンスのマスター製品データを保持する場所にもなり得ます

00:18:04.620 --> 00:18:07.880
これは複数のインスタンスを持つ大企業において重要なことです

00:18:07.880 --> 00:18:12.700
一つのインスタンスが製品定義を一元管理しそのデータを他のインスタンスへエクスポートやインポートを行います

00:18:12.700 --> 00:18:17.920
マイクロソフトはこのようなシステム間で定義されたデータを移動するための構造化された手法としてデータエンティティを提供しています

00:18:17.920 --> 00:18:19.540
しかしそれだけではありません

00:18:19.540 --> 00:18:22.280
マイクロソフトデータバースはその配付経路を拡張します

00:18:22.280 --> 00:18:26.580
データバースは多くのビジネスアプリで使用されるマイクロソフトの共有クラウドデータサービスです

00:18:26.580 --> 00:18:29.340
サプライチェーンマネジメントは製品定義をデータバースにエクスポートでき

00:18:29.340 --> 00:18:33.380
ダイナミクス365セールスなどの他のビジネスアプリケーションがその製品データを利用可能になります

00:18:33.380 --> 00:18:36.500
だからといって全てのアプリが突然同じ仕事をするようになるわけではありません

00:18:36.500 --> 00:18:39.520
PM製品情報管理は製品情報を整理し維持します

00:18:39.520 --> 00:18:42.080
ダイナミクス365セールスは営業業務を担当します

00:18:42.080 --> 00:18:46.820
その他のアプリはそれぞれのカスタマーサービスコマース財務製造または運用タスクを処理します

00:18:46.820 --> 00:18:50.260
関連する製品データは共有されますが各アプリはそれぞれの目的を維持します

00:18:50.260 --> 00:18:52.020
実際的な流れを見てみましょう

00:18:52.020 --> 00:18:54.820
製品チームが新しい製品定義を作成またはインポートします

00:18:54.820 --> 00:18:57.460
ビジネス側がそれを必要とする法人に対してリリースします

00:18:57.460 --> 00:18:59.580
それらの法人がローカルでの設定を完了させます

00:18:59.580 --> 00:19:01.940
購買部門は承認されたアイテムを使用して業務を行います

00:19:01.940 --> 00:19:04.340
倉庫スタッフはそのアイテムを受け取り取り扱うことができます

00:19:04.340 --> 00:19:07.440
営業部門は独自のバージョンを作る必要なく正しい製品を参照できます

00:19:07.440 --> 00:19:09.600
その成果は日常的な場面で現れます

00:19:09.600 --> 00:19:11.500
購入者は正しいアイテムを注文できます

00:19:11.500 --> 00:19:13.300
顧客は正しい詳細情報を確認し

00:19:13.300 --> 00:19:15.600
倉庫作業員は目の前の在庫と注文を照合できます

00:19:15.600 --> 00:19:18.720
製品情報が変更された際チームは古いコピーを追うのではなく

00:19:18.720 --> 00:19:21.420
現在承認されている詳細情報をより明確に利用できます

00:19:21.420 --> 00:19:23.760
これにより発注ミスや古い情報

00:19:23.760 --> 00:19:26.820
不正確な製品詳細による返品が減少します

00:19:26.820 --> 00:19:29.380
製品情報管理は製品定義を整理し

00:19:29.380 --> 00:19:34.020
接続されたプラットフォームの他の部分がその情報を活用できるようにする役割を担います

00:19:34.020 --> 00:19:37.580
結論ダイナミクスにおける共有された一つの製品ストーリー

00:19:37.580 --> 00:19:40.660
365の製品情報管理は製品アイデアを

00:19:40.660 --> 00:19:44.560
法人やビジネスチームがそれぞれの業務で利用できる一つの管理されたレコードへと変えます

00:19:44.560 --> 00:19:46.540
本日の知識のヒントは以上です

00:19:46.540 --> 00:19:48.460
お気に入りのポッドキャストプラットフォームで登録し

00:19:48.460 --> 00:19:51.020
ダイナミクス365を学習している人にシェアしてください

00:19:51.020 --> 00:19:52.360
次のエピソードに進んで

00:19:52.360 --> 00:19:55.560
全ての構成要素がどのように連携するかを確認しましょう