販売部門の製品名と倉庫の製品名が一致せず オンラインストアには昨年の写真が掲載されたままだったらどうなるでしょうか誰かが間違った商品を注文してしまいます 購入者が詳細を尋ねても誰も答えられずスタッフはスプレッドシートや古いメールサプライヤーの pdf 5つもの異なるシステムを確認し始め 単純な質問に答えるためだけに奔走しますm 365踏みを積むどもペターズによるナレッジナゲットへようこそ 今日はダイナミクス365の製品情報管理略してピムを取り上げます この動画を見終わる頃にはピムがどのように製品レコードを一つに共有保持するのかを理解できるはずです 製品がどのように多様な形態で存在しその情報が必要なビジネス部門へどのように届けられるのかを見ていきます 全社で一つの製品レコードを外から見ると製品とはシンプルなものに思えるかもしれません単なる名前と価格そして写真があるだけのように見えます しかし裏側ではその同じ製品が企業のほぼすべての部門に関わっていますその仕組みはこうです 購買部門にはサプライヤーの詳細と単位が必要ですが倉庫チームには商品の受け入れ保管ピッキングのための情報が必要です販売部門には明確な名称が必要です 経理部門には正確な設定が必要でオンラインストアには正確な写真と説明文が必要です各チームは同じ製品を異なる角度から見ています 情報の共有場所がないと人々は各自でコピーを作成しがちです製品チームはスプレッドシートを管理します 販売部門はシステムにより短い名前を入力します倉庫部門は異なる説明がついた品目番号を使い マーケティング部門は共有フォルダに画像を保存しカスタマーサービスは過去のメールを掘り返しますそのようなやり方では最初は小さな違いが生まれやがてそのズレが拡大していきます 断熱水筒を販売する会社を想像してみてくださいサプライヤーが容量を500mlから750mlに変更し 購買チームはその詳細を把握していてもオンラインストアには古い容量のまま記載されているかもしれません販売担当者は顧客に間違った使用書を送り 倉庫スタッフは注文と一致しない製品ラベルを目にすることになります誰も問題を起こそうとしたわけではありません 各チームがそれぞれ異なるコピーを見て作業していただけなのですダイナミクス365の製品情報管理は企業に唯一の中心的な製品定義を提供します 製品情報の共有ファイルキャビネットのようなものだと考えてくださいすべての部門が独自のフォルダを持つ代わりに製品レコードが合意済みの詳細情報を保持する唯一の場所となります人々はその定義を業務全体で利用し同じ情報を何度も入力し直す必要はなくなります 製品番号がそのレコードの中心に位置しますたとえ異なるチームが異なる言葉でその製品を呼んでいたとしても会社として一貫して製品を識別する助けとなりますその番号に付随して名前や説明を保存しそれが在庫可能な物理的製品なのか会社が提供するサービスなのかを識別しますその記録には製品の購入販売保管または係数の際に使用する単位も含まれます箱、子、キログラム、リットル、パレットといった単位は日々の業務において全く異なる意味を持つことがありますこれらの単位が明確であれば購買業務や倉庫業務はより良い出発点に立つことができます製品情報には画像、添付ファイル、カテゴリ、属性、名前や説明の翻訳データなども保持できますつまり製品記録にはラベル以上の情報を含めることができるのです製品を説明するサプライヤーの資料、製品を識別するための写真、異なる言語を使用するチームや顧客向けの翻訳された説明文、さらに素材、ブランド、取扱説明といった詳細情報も保持できます共有定義はローカルでの使用に先立ちます企業は製品を一度定義すれば、あとはビジネスの各部門が必要に応じてそれを利用できるようになります共有された記録は共通の事実を一箇所にまとめ、各部門が後から独自のビジネス設定を適用できるようにしますチームが製品を必要とするたびに、ゼロから作り直す必要はありませんこれは非常にスッキリとした業務の進め方ですが、名前と説明だけでは製品のすべてを語ることはできませんジーンズも色やサイズが加われば、いくつものアイテムに分かれます製品マスターとバリアント、それはファミリーツリーのようなものですではいつ、一つの製品が多くの製品へと変わるのでしょうか?

ジーンズを例に考えてみましょうあなたはジーンズを一つの製品とみなすかもしれませんが、倉庫では黒のLサイズという注文に対してどのジーンズでも良いというわけにはいきませんまた、営業部門も実際には存在しない青のXSサイズという組み合わせを約束することはできませんそこでダイナミクス365のシンプルなアイデアが役立ちますそれは基本的な製品と製品マスターを分けるという考え方ですシンプルな製品とは、一つの固定されたアイテムのことです一つのサイズ、一つの色、一つの形式で販売されるプリンター用紙の箱を想像してみてくださいその製品にはアイテムの内容を変えるような選択肢がないため、専用の製品記録が一つだけ存在します製品マスターは異なる仕組みで機能しますそれは製品ファミリー全体の親記録となりますそこには共有される詳細情報や個別のアイテムを作成するための選択ルールが保持されています仕組みはこうですジーンズの製品マスターには、その範囲内のすべてのジーンズに共通する名前、基本説明、共通情報が記載されていますそして、個々のバリアントが実際に購入、保管、生産、出荷される特定のジーンズを識別しますバリアントとは、販売可能な特定のアイテムのことですジーンズの場合青のMサイズが一つのバリアントになります黒のLサイズが別のバリアントになりますこれらは同じ製品ファミリーに属していますが、互換性はありません一方は倉庫の棚にあり、もう一方は在庫切れという状況もありえます一方は異なるラベルを使用するかもしれません一方は独自のバーコードを持っているかもしれませんこの親とこの構造が重要な考え方です製品マスターがファミリーを定義します製品バリアントは個々のメンバーです同じ基本情報を何度も入力する代わりに、マスターから始めてビジネスに必要な実際の組み合わせを作成します具体的な例を挙げましょうジーンズのラインナップに青、黒、茶色があると想像してくださいサイズもXS、S、M、L、XL、XXLと揃っています全ての色が全てのサイズであれば18通りの組み合わせができますしかし、全ての可能な組み合わせを販売する企業は稀です例えば、青はXSからMまでしかないかもしれません黒はMからXLまでです茶色はLから始まりますダイナミクス365は許可された各組み合わせを個別のバリアントとして扱います誰かが注文にジーンズを追加するとき、正確な製品を特定するディメンションを選択します色とサイズで顧客がどのバリアントを求めているかをシステムに伝えます箱にどのペアを入れるか迷うことはありませんこれらの選択肢は製品ディメンションと呼ばれますダイナミクス365サプライチェーン管理にはそのうち5つが含まれています

ディメンションを選択し、その製品マスターに対してグループ化しますこれらを簡単に見ていきましょう色は単純です青、黒、茶色、赤サイズも馴染み深いものですS、M、L、あるいは靴のサイズ番号などですスタイルは名前は同じでも見た目が異なる製品を区別できますシャツならレギュラーフィットやスリムフィットなどがあります椅子なら標準フレームや異なる仕上げなどがあるでしょう構成は選択されたビルドやセットアップを表します例えば機械には特定のモーター、電圧、一連の部品が必要になる場合があります構成ディメンションはその選択を識別しますバージョンは時間の経過に伴う製品の変更を追跡しますこれは製造業者にとって最も重要です目的は同じでも承認されたエンジニアリングの更新後に変更される部品を想像してくださいバージョンによりサプライチェーン内を移動する際にバージョン1とバージョン2を区別できますすべての製品マスターが5つすべてのディメンションを必要とするわけではありませんTシャツなら色とサイズだけで十分かもしれません機器であれば構成とバージョンが必要になるでしょうディメンショングループは製品ファミリーのルールシートのように機能しますバリアントを作成、識別する際にどの選択肢が適用されるかをダイナミクス365に伝えますその決定が最初から製品を片づくります重量、高さ、長さ、幅、体積についてはどうだろうと思うかもしれませんそれらの詳細は物理的な製品を説明しますがバリアントを作成するものではありませんジーンズには記載された重量やパッケージサイズがあってもそれによって色やサイズのように別アイテムに変わることはありません物理的寸法は製品そのものを表します製品寸法は特定のバリエーションを識別しますこの2つの考え方を分けておくことで5の混乱を防げます倉庫でカートンがどれだけのスペースを占有するかを知る必要がある場合物理的寸法が役に立ちます黒いジーンズのLサイズという注文があれば製品寸法で正しいバリエーションを見つけますその後の全てに影響する重要な選択が最初に1つあります会社はどのように製品バリエーションを作成し管理するのでしょうかそれこそが次に説明することです混乱を招かずに製品を構成する方法についてです寸法を選択することでダイナミクス365にバリエーションの識別方法を伝えますしかし企業はバリエーションをどのように作成するかを決める必要がありますその選択は製品によって異なりますサプライチェーン管理では3つの主要なアプローチをサポートしています定義済みバリエーション寸法ベースの構成そして制約ベースの構成です名前は専門的ですが分かりやすく説明しましょう定義済みバリエーションは組み合わせが限定的で基地の製品に適しています先ほど議論したジーンズを扱う小売業者を想像してください会社はどの色とサイズを仕入れ在庫し販売するかをすでに把握しています青はXSSMサイズがあります黒はMLXLサイズがあります茶色はLXLXXLサイズがありますこれら9つの選択肢は個別のバリエーションとしてあらかじめ作成できます企業は考えられる全ての色とサイズの組み合わせを持つ必要はありません実際に存在する組み合わせのみを作成すれば良いのですこれによりカタログはすっきりと持たれ存在しないはずの茶色のXSサイズの注文を防ぐことができます定義済みバリエーションは範囲が予測可能な場合にうまく機能します医療品会社固定パッケージサイズの販売業者標準的な家具の色を販売するビジネスなどが挙げられますこれらはいずれも扱うと予想される品目をあらかじめ準備できます注文が届く前に各バリエーションが基地の品目として存在するため購買・倉庫・販売の担当者は明確な選択肢に基づいて作業できます次のアプローチは寸法ベースの構成ですこれは製造業でよく見られます工業用ポンプを製造する会社を想像してください同じポンプ製品群でも多くの部品を共有しますが顧客は特定の構成を選択できますその選択が完成したポンプに含まれるコンポーネントを決定しますダイナミクス365では構成寸法を使用してそれを制御できますこの製品は共通の部品表ボムを使用しますああボムボムと呼ばれることもよくありますね部品表とは単に何かを構築するための部品リストのことですその一つのリストの中で特定の構成を選択した場合のみ適用される部品があります例えば特定の電圧用に製造されたポンプには特定のモーターが必要になる場合があります異なる電圧には別のモーターが必要です考えられるすべてのポンプに対して個別の部品リストを管理する代わりに会社は一つの共有リストを保持しますそしてどの業がどの構成に属するかをマークするのです選択された構成が計画や生産の段階に達するとダイナミクス365はその選択に適合する部品構成のみを使用しますこれにより重複した設定作業が大幅に削減されますまた製造業者は基本構造は共通でも一部が異なる製品群をより明確に管理できるようになりますディメンションによって選択された製品が特定されます部品表ボムがその構成に必要な部品を案内します次に製薬ベースの構成がありますこの手法は顧客が多くの選択肢から選べる製品に適していますしかし全ての選択肢が他の全ての選択肢と組み合わさるとは限りませんカスタム機械や実験装置あるいは多くの部品から組み立てられる製品を想像してください顧客は電源タイプ、ハウジング、モーター、安全オプション、操作パネルを選択するかもしれませんうまく機能する組み合わせもあればそうでないものもありますあるハウジングには大型のモーターが収まらない場合があります特定の電圧では特定の操作パネルが必要になることがあります安全カバーは特定の機械サイズでしか使えないかもしれませんルールがなければ営業担当者が工場では製造不可能な組み合わせを選んでしまう可能性があります制約ベースの構成はそれらのルールを製品構成モデルに組み込みますモデルは可能な選択肢とそれらを制限するルールを定義しますユーザーが製品を構成する際システムは有効な選択肢へと導きます互いに矛盾する選択を防ぐことができますこれにより不可能な注文が生産現場に届くのを未然に防ぎますこれは設計の初期段階で決めるべき重要な決定事項ですので少し詳しく説明します企業は製品ファミリーを構築する前に自社の業務プロセスに適した構成技術を選択する必要がありますダイナミクス365では後から製品を別の構成モデルに変換することはできませんそのため固定の製品範囲を販売する小売業者が単に柔軟そうだからといって複雑なカスタム製品モデルを構築すべきではありませんまた受注生産の装置を製造するメーカーも選択にルールが伴うならば考えられるすべての構成を事前に定義された長いリストに押し込めるべきではありません実際の購入販売および生産プロセスから始めてくださいシンプルな質問をしてみましょう注文が来る前にすべての製品の組み合わせを把握していますかそれとも顧客が許可された選択肢の中から選んで製品を作り上げますかその答えが企業にとっての正しいアプローチを指し示します製品がどのようなものになるかが決まったらそれを明確に説明し情報を整理しておく必要がありますカテゴリー属性そして製品情報の管理です製品名はそれが何であるかを示しますがそれだけでは購入保管販売あるいは顧客への説明には不十分ですそこでカテゴリーの出番となりますカテゴリーは整理された店舗の通路のようなものだと考えてください企業は製品をその種類ごとにグループ化するかもしれません例えばある通路には衣類別の通路には工具さらに別の通路には事務用品が並んでいますあるいは人々の作業の種類ごとに分類されているかもしれませんどちらにせよ目的は同じです製品を見つけやすく管理しやすくすることですコードレスドリルを例に挙げましょう

バッテリー駆動機器というカテゴリーに入れるかもしれませんここで重要なのはビジネス上のニーズが異なれば一つの製品を同時に複数のカテゴリーに分類できるという点です大切なのは全ての製品を一つの完璧なホルダに無理やり詰め込もうとしないことですカテゴリーにより企業は製品情報を体系的に整理し製品を検索し関連するアイテム群を管理できるようになりますまた関連する製品に対して適切な情報を適用するのにも役立ちますカテゴリーには多くの役割がありますが全ての詳細情報を保持できるわけではありませんそこで登場するのが属性です水筒の場合属性には素材、容量、蓋のタイプ、断熱性、ブランド、お手入れ方法などが含まれます機械部品の場合、寸法、電力要件、温度範囲、技術規格などが含まれるでしょう属性は大まかなラベルを有用な製品情報へと変えてくれますつまり業務に必要な情報そのものですカテゴリーにはその中の製品に適した属性を持たせることができます衣類には記事、フィット感、選択方法が必要です電子機器には電圧、保証の詳細、互換性情報が必要ですつまり製品レコードごとにその都度ランダムなフィールドを作成する必要はありません製品グループにあった詳細情報を使用すれば良いのです画像や添付ファイルはさらなる詳細を補足します写真があれば倉庫の作業員、営業担当者、顧客は扱っているあるいは話題にしているアイテムをすぐに指認できます添付ファイルにはサプライヤーの文書、使用書その他の書類などの参考資料を保持できます時には名称だけでは不十分なこともあります他言語でビジネスを展開する場合、翻訳が重要になります製品名や説明を翻訳することで異なる市場の人々にも理解できる情報を届けられます製品自体は同じでも周囲の説明をターゲット層に合わせることができます企業はまた誰がこの情報を変更できるかを管理する必要がありますすべての従業員がすべての製品レコードを編集したり、アイテム名を変更したり、他チームが依存する詳細情報を変更できたりすべきではありませんダイナミクス365では製品データへのアクセスルールをカテゴリ単位、または個々の製品単位で適用できます例えば、産業機器を担当するチームはそのカテゴリを扱い、別のグループが消費者向け製品を担当するといった具合です制限付きの製品には一般的な事務用品よりも厳格な管理が必要になる場合があります製品データの各領域を誰が扱えるかを決定するのは企業自身ですそれにより人々が頼りにする情報が保護されます記録には適切な詳細、文書、カテゴリ、および管理項目が備わっているかもしれませんしかし製品の購入、販売、在庫、製造を行う部門が実際に使用する前には承認が必要です製品を法的実態にリリースする完成した製品定義ができれば自動的に誰もが使える状態になるのでしょうかいいえ、まだです企業は多くの場合、複数の法的実態、大きな組織内の個別の会社を通じて運営されていますある法的実態はドイツで製品を購入し在庫するかもしれません別の法的実態は同じ製品をアメリカで販売します3番目の法的実態はそれを製造するかもしれませんこれらすべてが同じ共有の製品定義から開始できますダイナミクス365ではその共有定義が特定の法的実態による使用を会社が承認した時点でリリース製品となりますリリースとはそのビジネスユニットが製品を日々の業務に組み込むための許可を与えることだと考えてください製品がその同一性を変えるわけではありません共通の名称、説明、カテゴリ、寸法、その他の共有詳細は中央の定義と繋がったままですが各法的実態はその製品の注文、販売、保管、または製造を行う前に必要な設定を追加できますある会社はサプライヤーから製品を購入するかもしれません別の会社は販売のみを行うかもしれません製造会社には製造設定が必要ですが流通会社には倉庫や在庫の設定が必要です販売の詳細は法的実態ごとに異なります現地のビジネスルールも異なりますリリース機能により各法的実態は全く別の製品定義を作成することなく自らの業務に合わせて製品を準備できます複数の国で同じ水筒を販売する会社を想像してみてください製品チームが一つの中央製品定義を作成します次に会社はその製品をイギリスの法的実態にリリースしますそしてその法的実態は水筒の購入と保管に必要な設定を追加しますその後同じ製品がカナダの法的実態にリリースされ現地の販売と在庫のための設定が完了します両社とも同じ製品を使用します名前や説明製品ファミリーの詳細を最初から入力し直す必要はありません自社の法的実態に属する情報のみを保管すれば良いのですこの分離により共有の事実と現地の業務がそれぞれ適切な場所に維持されます共有製品定義はこの製品は何なのかという問いに答えますリリース製品は別の問いに答えますこの特定の会社はそれをどのように使うのかという問いです言葉の上ではわずかな違いですが複数の法的実態にまたがって事業を行う際の多くの重複作業を防ぐことができますダイナミクス365では製品を一つの法的実態または複数の法的実態に同時にリリースできますこれは企業が多くのビジネスユニット全体で標準的な製品群を導入する際に役立ちますそれでもリリースは今やボタンを押して忘れるだけのステップを模倣するものとなっています各法人はチームがその製品を安全に取り扱う前に追加の詳細情報を必要とする場合がありますリリース済み製品のメンテナンスワークスペースはそのプロセスの監視に役立ちますこれには最近リリースされた製品が表示されその法人に必要な設定が完了しているかどうかが確認されます製品の属性カテゴリ注文設定または翻訳を追加する必要がある場合このワークスペースから該当する作業を見つけ関連する製品ページを開くことができますまたチームが未完了の製品変更案件を見つけるのにも役立ちます中央のビューでは製品が準備完了に見えてもローカル設定が不完全な場合があるためこれは重要ですこのワークスペースは長いリストを検索させる代わりに法人が対応を必要とする製品の実用的なリストを提供しますつまりリリースは製品を別の世界にコピーするわけではありません承認された一つの製品定義を法人に接続しその法人が独自の運用詳細を適用する余地を与えますそれが完了すると製品情報は注文在庫顧客ニーズに関連する業務へと移行できますではピムは製品にまつわる業務をどのように結びつけるのでしょうか製品情報管理は具体的にどのように製品にまつわる業務を結びつけるのでしょうか最もシンプルな定義は次の通りですピムは全てのビジネスプロセスを単独で実行するわけではありませんその代わりにそれらのプロセスが必要とする製品情報を供給します製品データのマスターファイリングキャビネットと考えてください購買担当者は発注書き上げで適切な品目を見つける必要があります倉庫チームは在庫の受け入れやピッキングの際に正しい品目を確認する必要があります営業チームは見積り注文に必要な製品詳細を必要としますまた他のダイナミクス365アプリも製品データを必要とする場合がありますピムはそれらすべてのチームに信頼できる唯一のソースへの共通の出発点を提供しますではその製品データはどこから来るのでしょうか製品定義はダイナミクス365サプライチェーンマネジメント内で作成を開始できます企業が最初からそこで製品情報を管理している場合これはうまく機能しますしかし多くの企業は製品開発や製品記録のためにすでに別のシステムを使用しています例えば製品データはPLMと呼ばれることが多い製品ライフサイクル管理システムから取得できますPLMシステムはチームが設計や開発業務を通じて製品を管理するのに役立ちます製品データや関連ドキュメントを扱う製品データ管理PDMというものもあります製品情報がサプライチェーンマネジメントに入る前に別のPIMシステムを使用している企業もありますここで良いニュースがありますダイナミクス365はそれらのシステムから製品定義をインポートできますつまり製品が設計からサプライチェーン業務に移行したというだけで同じ製品詳細を再度入力する必要はありませんサプライチェーンマネジメントは他のインスタンスのマスター製品データを保持する場所にもなり得ますこれは複数のインスタンスを持つ大企業において重要なことです一つのインスタンスが製品定義を一元管理しそのデータを他のインスタンスへエクスポートやインポートを行いますマイクロソフトはこのようなシステム間で定義されたデータを移動するための構造化された手法としてデータエンティティを提供していますしかしそれだけではありませんマイクロソフトデータバースはその配付経路を拡張しますデータバースは多くのビジネスアプリで使用されるマイクロソフトの共有クラウドデータサービスですサプライチェーンマネジメントは製品定義をデータバースにエクスポートできダイナミクス365セールスなどの他のビジネスアプリケーションがその製品データを利用可能になりますだからといって全てのアプリが突然同じ仕事をするようになるわけではありませんPM製品情報管理は製品情報を整理し維持しますダイナミクス365セールスは営業業務を担当しますその他のアプリはそれぞれのカスタマーサービスコマース財務製造または運用タスクを処理します関連する製品データは共有されますが各アプリはそれぞれの目的を維持します実際的な流れを見てみましょう製品チームが新しい製品定義を作成またはインポートしますビジネス側がそれを必要とする法人に対してリリースしますそれらの法人がローカルでの設定を完了させます購買部門は承認されたアイテムを使用して業務を行います倉庫スタッフはそのアイテムを受け取り取り扱うことができます営業部門は独自のバージョンを作る必要なく正しい製品を参照できますその成果は日常的な場面で現れます購入者は正しいアイテムを注文できます顧客は正しい詳細情報を確認し倉庫作業員は目の前の在庫と注文を照合できます製品情報が変更された際チームは古いコピーを追うのではなく現在承認されている詳細情報をより明確に利用できますこれにより発注ミスや古い情報不正確な製品詳細による返品が減少します製品情報管理は製品定義を整理し接続されたプラットフォームの他の部分がその情報を活用できるようにする役割を担います結論ダイナミクスにおける共有された一つの製品ストーリー365の製品情報管理は製品アイデアを法人やビジネスチームがそれぞれの業務で利用できる一つの管理されたレコードへと変えます本日の知識のヒントは以上ですお気に入りのポッドキャストプラットフォームで登録しダイナミクス365を学習している人にシェアしてください次のエピソードに進んで全ての構成要素がどのように連携するかを確認しましょう