WEBVTT

00:00:00.000 --> 00:00:02.720
顧客がウェブサイトで購入ボタン を押したときその商品は倉庫に

00:00:02.720 --> 00:00:05.700
あるかもしれませんし街の反対側 の店舗あるいは配送業者の手元

00:00:05.700 --> 00:00:08.420
にあるかもしれませんしかし顧客 が本当に期待しているのはたった

00:00:08.420 --> 00:00:12.920
2つのことだけです明確な約束 と玄関先に届く荷物ですm365fm

00:00:12.920 --> 00:00:16.300
のマイクロソフトナレッジナゲッツ へようこそ私はもうピーターズ

00:00:16.300 --> 00:00:19.300
です今日はダイナミクス365インテリジェント オーダーマネジメントについて

00:00:19.300 --> 00:00:22.140
わかりやすく解説しますチェック アウトのクリックから実際に商品

00:00:22.140 --> 00:00:24.740
が配送されるまでのプロセス を追っていきましょうこれは忙しい

00:00:24.740 --> 00:00:27.160
オフィスビルの中央管理デスク のようなものだと考えてください

00:00:27.160 --> 00:00:29.660
オンラインショップを追加する わけでも箱詰めをするわけでも

00:00:29.660 --> 00:00:33.100
ありません適切な担当者やシステム に指示を出しあるべき場所で作業

00:00:33.100 --> 00:00:37.060
が完了するように導くのですなぜ 注文処理は複雑になるのでしょうか

00:00:37.060 --> 00:00:40.780
ウェブサイト実店舗オンライン マーケットプレイスコールセンター

00:00:40.780 --> 00:00:43.940
で同じヘッドホンを販売している と想像してください顧客にとって

00:00:43.940 --> 00:00:46.520
これらはすべてヘッドホン を買うための手段にすぎません

00:00:46.520 --> 00:00:49.920
しかし舞台裏では各チャンネル が全く異なるシステムに注文詳細

00:00:49.920 --> 00:00:53.060
を送っていますウェブサイトは 独自の記録を持ち店舗のポスは

00:00:53.060 --> 00:00:56.460
別の記録をマーケットプレイス は独自の形式を送りコールセンター

00:00:56.460 --> 00:00:58.640
の担当者はまた別の場所に注文 を作成します

00:00:58.640 --> 00:01:02.120
顧客への一つのシンプルな約束 が互いに連携しない複数の断片

00:01:02.120 --> 00:01:05.600
に分断されてしまうのですさらに 在庫が複雑さに拍車をかけます

00:01:05.600 --> 00:01:09.720
メインの倉庫には20個あるかもしれません 街の反対側の店舗には5個別の

00:01:09.720 --> 00:01:12.920
倉庫にも在庫があるかもしれません しかしそこは遠くて送料が高く

00:01:12.920 --> 00:01:16.020
つくかもしれません一部の在庫 は他の注文用返品用あるいは店頭

00:01:16.020 --> 00:01:18.640
購入者用に確保されていることも ありますですから製品の横に表示

00:01:18.640 --> 00:01:20.600
された数値を見るだけでは問題 は解決しないのです

00:01:20.600 --> 00:01:22.600
次にどのように配送するかを決め なければなりません

00:01:22.600 --> 00:01:25.520
倉庫から発送すべきでしょうか 店舗から発送すべきでしょうか

00:01:25.520 --> 00:01:27.660
それとも顧客が近くの店舗で 受け取れるようにすべきでしょうか

00:01:27.660 --> 00:01:30.840
もし誰かが2つの商品を買いどちら の場所にも両方揃っていない場合注文を

00:01:30.840 --> 00:01:33.260
2つの荷物に分けますかそれとも 全て揃うまで待ちますかあらゆる

00:01:33.260 --> 00:01:37.320
選択がコスト配送時間そして顧客 との約束に影響を与えます20年前

00:01:37.320 --> 00:01:40.020
企業はこうした業務を個別のシステム とチームで運用していました

00:01:40.020 --> 00:01:44.200
営業が注文を受けます誰かが在庫 を確認します倉庫に依頼が届きます

00:01:44.200 --> 00:01:47.840
配送業者に別の依頼が届きます 請求処理は後で担当部署が行います

00:01:47.840 --> 00:01:50.400
注文が単純で件数が少なかった 頃はそれでうまくいっていました

00:01:50.400 --> 00:01:53.400
しかし問題はここにあります システム間の情報の更新が遅い

00:01:53.400 --> 00:01:55.220
と人間がその隙間を埋め始め なければなりません

00:01:55.220 --> 00:01:57.780
カスタマーサービスの担当者が 一つの画面を確認し倉庫チーム

00:01:57.780 --> 00:02:00.660
にメールを送り配送業者に電話 をかけるその間に在庫情報が

00:02:00.660 --> 00:02:02.920
ウェブサイトに反映されるより 早く別のチャンネルで商品が売れて

00:02:02.920 --> 00:02:05.620
しまう可能性があるのです在庫 のない商品の注文を受けてしまう

00:02:05.620 --> 00:02:07.880
状況ですこれが売り越しという 問題を引き起こします

00:02:07.880 --> 00:02:10.880
配送手段の決定に時間がかかる のもそのためですチーム間で詳細

00:02:10.880 --> 00:02:13.920
をコピーし続けるため顧客には 明確な回答ではなく曖昧な報告

00:02:13.920 --> 00:02:17.100
しか届きません顧客にとって そのような複雑さは関係ありません

00:02:17.100 --> 00:02:20.500
彼らが聞きたいことは一つだけ です注文したものはどこにある

00:02:20.500 --> 00:02:24.400
の企業に必要なのは全てのビジネス アプリを連携させそれぞれの得意

00:02:24.400 --> 00:02:27.860
分野を生かしながら注文の流れ を一元管理できる場所です販売部門

00:02:27.860 --> 00:02:30.880
は受注を管理します倉庫部門は ピッキングと梱包を管理します

00:02:30.880 --> 00:02:34.240
配送部門は配達を管理します経理 部門は支払いを管理します既存の

00:02:34.240 --> 00:02:37.180
システムを全て捨てる必要はありません 必要なのはそれらを統合する

00:02:37.180 --> 00:02:40.560
コーディネーターです空いた 注文を受け取り次に何をすべき

00:02:40.560 --> 00:02:44.040
かを把握し手作業による引き継ぎ を減らして業務を指示できる場所

00:02:44.040 --> 00:02:48.620
ですそれが課題なのですダイナミクス 365インテリジェントオーダーマネジメント

00:02:48.620 --> 00:02:53.320
はまさにこの課題に答えるもの ですではダイナミクス365インテリジェント

00:02:53.320 --> 00:02:56.780
オーダーマネジメントとは具体的 に何でしょうか今日はその仕組みを

00:02:56.780 --> 00:03:01.740
わかりやすく解説します最もシンプル な定義はこうです注文発生から

00:03:01.740 --> 00:03:06.400
履行そして請求まで企業がすでに 使用しているすべてのシステム

00:03:06.400 --> 00:03:10.720
をクラウド上で一括して管理する アプリです忙しい鉄道駅を想像

00:03:10.720 --> 00:03:14.240
してください列車は様々な方面 から到着します乗客はそれぞれ

00:03:14.240 --> 00:03:16.780
の目的地へ向かいますスムーズ な乗り継ぎもあれば待ち時間が

00:03:16.780 --> 00:03:19.440
必要な場合もありますインテリジェント オーダーマネジメントはその駅の

00:03:19.440 --> 00:03:22.060
指令室のような役割を果たします 列車を運転したりチケットを売った

00:03:22.060 --> 00:03:24.940
りはしませんが全体の経路を把握 し各システムに次にすべきこと

00:03:24.940 --> 00:03:27.440
を指示しますマイクロソフト はデータバースの上にインテリジェント

00:03:27.440 --> 00:03:30.660
オーダーマネジメントを構築しました データバースは多くのダイナミクス

00:03:30.660 --> 00:03:33.740
365やパワープラットフォームアプリ を支える共通のデータ基盤です

00:03:33.740 --> 00:03:37.440
簡単に言えばビジネスアプリに 情報を保存するための共通の場所

00:03:37.440 --> 00:03:41.100
と共通の形式を提供しますこれ により画面やシステムごとに注文

00:03:41.100 --> 00:03:43.320
データが全く別の意味を持つとい ったことがなくなります

00:03:43.320 --> 00:03:46.220
この共通基盤は便利ですがインテリジェント オーダーマネジメントを利用

00:03:46.220 --> 00:03:49.400
するために他のすべてのダイナミクス 365アプリを購入する必要はありません

00:03:49.400 --> 00:03:52.160
ダイナミクス365ファイナンス やサプライチェーンマネジメント

00:03:52.160 --> 00:03:55.420
を運用している企業もあれば別の 倉庫システムやオンラインストア

00:03:55.420 --> 00:03:58.080
他社の配送サービスを利用している 企業もあるでしょう

00:03:58.080 --> 00:04:01.040
このアプリはマイクロソフト 正解なかを問わずあらゆるビジネス

00:04:01.040 --> 00:04:04.200
アプリと連携できますその接続 点はプロバイダーと呼ばれます

00:04:04.200 --> 00:04:06.420
プロバイダーはインテリジェント オーダーマネジメントと外部

00:04:06.420 --> 00:04:08.820
システムの間で注文情報や利口 情報をやり取りします

00:04:08.820 --> 00:04:11.700
プロバイダーは玄関口の通訳 のようなものだと考えてください

00:04:11.700 --> 00:04:15.020
あるシステムが独自の形式で注文 を送信するとプロバイダーがその

00:04:15.020 --> 00:04:18.240
形式を理解して情報をインテリジェント オーダーマネジメントに渡し相手

00:04:18.240 --> 00:04:20.760
のシステムが理解できる形式で 次の要求を送り返します

00:04:20.760 --> 00:04:24.040
つまりこのアプリは注文がどこ から始まったかに関わらず注文

00:04:24.040 --> 00:04:25.200
情報を一元管理します

00:04:25.200 --> 00:04:27.840
アイオコマースサイトを通じて 購入する顧客もいれば

00:04:27.840 --> 00:04:30.140
ホスシステムを通じて注文する 顧客もいます

00:04:30.140 --> 00:04:34.040
法人顧客がB2Bプロセスを通じて 電子注文を送ることもあるでしょう

00:04:34.040 --> 00:04:37.100
インテリジェント注文管理システム を使えば企業はそうした注文を

00:04:37.100 --> 00:04:39.460
一箇所で確認しそれぞれの利口 状況を把握できます

00:04:39.460 --> 00:04:41.800
全ての注文が同じ経路をたどる わけではありません

00:04:41.800 --> 00:04:44.520
在庫を待つ必要がある注文もあれば 既に倉庫に準備されている注文

00:04:44.520 --> 00:04:44.840
もあります

00:04:44.840 --> 00:04:47.260
配送後に請求手続きが必要な 注文もあるでしょう

00:04:47.260 --> 00:04:49.980
アプリがその状態を追跡するため チームは単に注文を受領した

00:04:49.980 --> 00:04:51.140
こと以上の状況を把握できます

00:04:51.140 --> 00:04:54.120
注文が現在どのような工程に あるのか正確に確認できるのです

00:04:54.120 --> 00:04:56.020
ここで見落とされがちなポイント があります

00:04:56.020 --> 00:04:59.060
インテリジェント注文管理システム は全ての業務を肩代わりするわけ

00:04:59.060 --> 00:04:59.540
ではありません

00:04:59.540 --> 00:05:02.920
倉庫作業員のピッキング画面 や配送業者のネットワーク財務

00:05:02.920 --> 00:05:05.000
チームの請求システムにとって 変わるものではありません

00:05:05.000 --> 00:05:08.020
それらの連携アプリは引き続き 専門的な業務を遂行します

00:05:08.020 --> 00:05:11.300
インテリジェント注文管理システム はそれらの間の引き継ぎを制御します

00:05:11.300 --> 00:05:15.280
リクエストを受け取りルート を確認し作業を引き継ぎ次の更新

00:05:15.280 --> 00:05:15.760
を待ちます

00:05:15.760 --> 00:05:18.520
それでは一つの注文が辿る道のり を見てみましょう

00:05:18.520 --> 00:05:21.800
注文の過程を追うことで全体の 仕組みがより理解しやすくなります

00:05:21.800 --> 00:05:25.080
注文の過程を決定づけるのは業務 を支持するルールです

00:05:25.080 --> 00:05:28.840
例えば顧客が午後の遅い時間に ウェブサイトから商品を2点注文

00:05:28.840 --> 00:05:31.020
し翌日の配送を希望したとします

00:05:31.020 --> 00:05:35.840
オンラインストアは顧客名配送先 住所注文品目配送オプションなどの

00:05:35.840 --> 00:05:36.980
注文情報を取得します

00:05:36.980 --> 00:05:40.560
プロバイダーがその注文をインテリジェント 注文管理システムに取り込むと注文

00:05:40.560 --> 00:05:41.460
の過程が始まります

00:05:41.460 --> 00:05:45.660
履行を開始する前にシステムは 注文を検証し旅に必要な情報が

00:05:45.660 --> 00:05:48.560
全て揃っているか会社のルール に従っているかを確認します

00:05:48.560 --> 00:05:51.560
注文ヘッダーの顧客情報や配送 詳細を確認します

00:05:51.560 --> 00:05:54.100
各注文明細の製品と数量をチェック します

00:05:54.100 --> 00:05:57.660
住所が配送に十分な情報を含んでいる かを確認しその販売チャンネル

00:05:57.660 --> 00:05:59.300
のルールに適合しているかを判断 します

00:05:59.300 --> 00:06:02.600
最初のチェックにより誤った 情報が下流に流れて問題を引き

00:06:02.600 --> 00:06:03.720
起こすのを未然に防ぎます

00:06:03.720 --> 00:06:06.460
アパート番号が欠落している注文 を想像してみてください

00:06:06.460 --> 00:06:09.920
もしそのまま倉庫へ送られ配送 業者に渡ってしまったら配達できない

00:06:09.920 --> 00:06:11.800
事態になって初めて問題が発覚 するかもしれません

00:06:11.800 --> 00:06:15.340
検証プロセスがあれば顧客への 連絡や注文の一時保留といった対応

00:06:15.340 --> 00:06:17.000
が間に合う段階で問題を特定 できます

00:06:17.000 --> 00:06:19.900
この作業の根幹となるのがオーケストレーション フローです

00:06:19.900 --> 00:06:22.680
専門用語に聞こえるかもしれません が仕組みは単純です

00:06:22.680 --> 00:06:25.560
オーケストレーションフローとは 注文情報の到着や連携システム

00:06:25.560 --> 00:06:28.520
からのイベント発生に応じて何を 行うべきかをインテリジェント注文

00:06:28.520 --> 00:06:30.020
管理システムに示す視覚的なマップ です

00:06:30.020 --> 00:06:32.700
このマップは記者のビジネスプロセス に合わせて作成します

00:06:32.700 --> 00:06:35.520
基本的な注文フローは新規注文 の到着とともに始まります

00:06:35.520 --> 00:06:37.100
ヘッダーと迷彩を検証します

00:06:37.100 --> 00:06:39.700
フルフィルメント配送の判断 のために注文を送信します

00:06:39.700 --> 00:06:42.680
その後適切な接続システムへフルフィルメント 注文を送信します

00:06:42.680 --> 00:06:46.040
作業が適切な段階に達すると請求 プロバイダーへ注文情報を送信

00:06:46.040 --> 00:06:46.320
できます

00:06:46.320 --> 00:06:48.240
各アクションには明確な役割 があります

00:06:48.240 --> 00:06:51.180
注文ヘッダーの検証は注文の主要 な詳細を確認します

00:06:51.180 --> 00:06:54.440
注文明細の検証は個々の製品と 数量を確認します

00:06:54.440 --> 00:06:58.100
フルフィルメントへ送信はその作業 を扱うプロバイダーに注文を引き

00:06:58.100 --> 00:06:58.520
渡します

00:06:58.520 --> 00:07:01.920
請求へ送信は注文情報を請求 プロバイダーに渡します

00:07:01.920 --> 00:07:04.820
これらの名称は工場の制御パネル のラベルのように聞こえますが

00:07:04.820 --> 00:07:07.660
ラベルがフローのその地点で 何が起こるかを正確に示してくれる

00:07:07.660 --> 00:07:08.240
ため便利です

00:07:08.240 --> 00:07:11.320
しかし実際のビジネスでは単なる 直線的な流れでは不十分な場合

00:07:11.320 --> 00:07:11.800
がよくあります

00:07:11.800 --> 00:07:14.780
ウェブサイトからの注文は一つの 経路をたどり法人顧客からの注文

00:07:14.780 --> 00:07:15.940
は別の経路をたどるかもしれません

00:07:15.940 --> 00:07:18.420
特定の製品には特別な承認が 必要になる場合もあります

00:07:18.420 --> 00:07:21.140
最初のステップが成功した場合にのみ 注文が次に進めるということも

00:07:21.140 --> 00:07:21.420
あるでしょう

00:07:21.420 --> 00:07:23.880
インテリジェント注文管理にはその ような選択のための条件が

00:07:23.880 --> 00:07:24.340
含まれています

00:07:24.340 --> 00:07:27.200
条件によってはいのパスといいえ のパスが作成されます

00:07:27.200 --> 00:07:30.640
前のステップが成功すれば注文 ははいのパスに進むことができます

00:07:30.640 --> 00:07:33.660
失敗した場合はフローによって 別のパスへ注文を振り向けること

00:07:33.660 --> 00:07:34.060
ができます

00:07:34.060 --> 00:07:37.060
これで全ての問題が解決するわけ ではありませんがチームが偶然

00:07:37.060 --> 00:07:39.960
エラーを発見するのを待つのでは なくプロセスに計画的な対応を

00:07:39.960 --> 00:07:40.400
組み込めます

00:07:40.400 --> 00:07:42.320
スプリッター分岐もあります

00:07:42.320 --> 00:07:45.340
スプリッターは定義したルール に基づいてフローを複数のパス

00:07:45.340 --> 00:07:45.980
に分岐させます

00:07:45.980 --> 00:07:49.080
異なるソースからの注文に個別 のチェックが必要な場合や作業

00:07:49.080 --> 00:07:51.400
の各部分に異なるルートが必要な 場合に使用できます

00:07:51.400 --> 00:07:54.380
分岐したパスの一部は後で統合 されることもあればそれぞれ独立

00:07:54.380 --> 00:07:55.240
して進むこともあります

00:07:55.240 --> 00:07:58.240
カスタムアクションは特定のビジネス に固有の作業をカバーします

00:07:58.240 --> 00:08:01.160
企業が独自の製造システムを持って いたり標準のアクションではカバー

00:08:01.160 --> 00:08:03.100
されないパートナーシステムを 使用していたりする場合がある

00:08:03.100 --> 00:08:03.300
でしょう

00:08:03.300 --> 00:08:05.460
カスタムアクションを使えばその ステップを注文フローに

00:08:05.460 --> 00:08:08.760
統合できるため一部の作業がメール や手作業に隠れることなくプロセス

00:08:08.760 --> 00:08:09.640
全体を可視化できます

00:08:09.640 --> 00:08:11.660
2品目の注文の例に戻りましょう

00:08:11.660 --> 00:08:15.120
システムはウェブサイトから注文 を受け取り顧客の詳細住所製品

00:08:15.120 --> 00:08:15.920
ラインを確認します

00:08:15.920 --> 00:08:18.840
次に注文はフルフィルメントの 決定ステップに到達します

00:08:18.840 --> 00:08:22.080
両方の品目が同じルートを通れる 場合フローはフルフィルメント

00:08:22.080 --> 00:08:24.040
のリクエストを一つの単位として 先に送れます

00:08:24.040 --> 00:08:27.120
会社のルールで異なる結果が求め られる場合は別のパスをたどら

00:08:27.120 --> 00:08:27.820
せることができます

00:08:27.820 --> 00:08:30.920
2つの品目に別々のフルフィルメント 要求が必要だったり異なる配送

00:08:30.920 --> 00:08:32.320
オプションが必要だったりする かもしれません

00:08:32.320 --> 00:08:33.880
フローは推測を行いません

00:08:33.880 --> 00:08:37.200
ビジネスが作成したルールと接続 されたシステムから返されるイベント

00:08:37.200 --> 00:08:37.740
に従います

00:08:37.740 --> 00:08:39.400
最後の部分が重要です

00:08:39.400 --> 00:08:42.280
インテリジェント注文管理は作業 を支持できますが作業が進むに

00:08:42.280 --> 00:08:44.240
つれて接続されたシステムが報告 を返してくるのです

00:08:44.240 --> 00:08:46.400
フルフィルメントプロバイダー がリクエストを受け取ることが

00:08:46.400 --> 00:08:46.740
できます

00:08:46.740 --> 00:08:49.400
請求プロバイダーが注文の詳細 を受け取ることができます

00:08:49.400 --> 00:08:52.300
こうしたイベントによって注文 の旅路はフローの中を進み続け

00:08:52.300 --> 00:08:52.500
ます

00:08:52.500 --> 00:08:55.000
つまりこのアプリは巨大な代替 システムではありません

00:08:55.000 --> 00:08:57.940
これは専門システム同士をつなぎ 必要な仕事を適切なタイミング

00:08:57.940 --> 00:08:59.500
で各システムに割り振る一連 のルールです

00:08:59.500 --> 00:09:01.340
オンラインストアが注文を補足 します

00:09:01.340 --> 00:09:03.380
フルフィルメントシステムが配送 を処理します

00:09:03.380 --> 00:09:05.320
請求システムが支払いを処理 します

00:09:05.320 --> 00:09:08.440
インテリジェント注文管理はそれら の業務間のルートを管理します

00:09:08.440 --> 00:09:11.840
注文プロセスを担当する人々 はアプリ内で直接これらのフロー

00:09:11.840 --> 00:09:12.500
を設計できます

00:09:12.500 --> 00:09:16.100
全ての経路を従来のコードとして 記述する必要はなくビジネスルール

00:09:16.100 --> 00:09:18.620
を変更するたびにIT管理者に依頼 する必要もありません

00:09:18.620 --> 00:09:21.360
これによりサプライチェーンチーム は実際に必要なプロセスをモデル

00:09:21.360 --> 00:09:22.100
化できるようになります

00:09:22.100 --> 00:09:24.380
とはいえこうした変更には慎重 差が必要です

00:09:24.380 --> 00:09:27.220
オーケストレーションフローは構築 やテストの段階では非公開の状態

00:09:27.220 --> 00:09:27.680
にもたれます

00:09:27.680 --> 00:09:30.880
その段階では入ってくるデータが フロー内を流れることはありません

00:09:30.880 --> 00:09:34.040
公開するとデータがシステム に入力された際にフローとそのアクション

00:09:34.040 --> 00:09:34.720
が実行されます

00:09:34.720 --> 00:09:38.060
公開した後はその公開済フロー を直接編集することはできません

00:09:38.060 --> 00:09:41.160
ビジネス上の変更が必要な場合 チームは公開されたフローを停止

00:09:41.160 --> 00:09:42.940
することで未公開の状態に戻せ ます

00:09:42.940 --> 00:09:46.040
フローを編集し準備が整ったら 新しいバージョンを公開できます

00:09:46.040 --> 00:09:49.020
この仕組みによりチームは実際 の注文が流れる前にルートをテスト

00:09:49.020 --> 00:09:49.860
するよう促されます

00:09:49.860 --> 00:09:52.860
ルートは何が実際に利用可能な 在庫であるかを把握して初めて

00:09:52.860 --> 00:09:53.300
機能します

00:09:53.300 --> 00:09:56.580
そこで各フルフィルメントの 決定を支えるライブ在庫情報が

00:09:56.580 --> 00:09:57.320
必要となります

00:09:57.320 --> 00:10:01.120
在庫の可視化つまり実際に販売 可能なものを把握することです

00:10:01.120 --> 00:10:03.080
明白な事実をお伝えしましょう

00:10:03.080 --> 00:10:06.140
在庫があることを知らなければ 注文を履行することはできません

00:10:06.140 --> 00:10:09.100
当たり前に聞こえるかもしれません が在庫は倉庫店舗パートナーの

00:10:09.100 --> 00:10:11.880
拠点あるいは同一企業内の異なる 法人のどこかに隠れていることが

00:10:11.880 --> 00:10:12.120
あります

00:10:12.120 --> 00:10:15.160
各拠点が独自のカウントを保持 していると今この顧客に何を

00:10:15.160 --> 00:10:17.580
約束できるのかという基本的な 質問に答えられません

00:10:17.580 --> 00:10:20.720
在庫の可視化によりインテリジェント 注文管理はサプライネットワーク

00:10:20.720 --> 00:10:22.220
全体の在庫をライブで把握できます

00:10:22.220 --> 00:10:25.160
配送センターにある在庫ボード のようなものだと考えてください

00:10:25.160 --> 00:10:28.320
全ての棚に電話をかけて確認を 依頼する代わりに注文プロセス

00:10:28.320 --> 00:10:30.840
は全てのシステムからデータが 集まる単一の共有ビューを参照

00:10:30.840 --> 00:10:31.120
します

00:10:31.120 --> 00:10:33.200
ただしどこかに在庫として表示 されている

00:10:33.200 --> 00:10:35.800
からといってあらゆる注文を履行 できるわけではありません

00:10:35.800 --> 00:10:39.580
製品が倉庫にあってもすでに予約 済みであったり店頭販売用で出荷

00:10:39.580 --> 00:10:42.840
負荷であったりあるいは顧客が 選択した配送約束を守るには単

00:10:42.840 --> 00:10:44.160
に遠すぎたりする場合もあります

00:10:44.160 --> 00:10:48.140
どこかに存在する在庫と今すぐ この注文を履行できる在庫の間には

00:10:48.140 --> 00:10:49.340
大きな違いがあるのです

00:10:49.340 --> 00:10:52.320
ある顧客がオンラインでジャケット を購入し明日届けて欲しいと望んで

00:10:52.320 --> 00:10:52.800
いるとしましょう

00:10:52.800 --> 00:10:55.160
メインの倉庫にはもう在庫が残 っていません

00:10:55.160 --> 00:10:58.640
最新の在庫データがなければウェブ サイトは古い情報のまま注文を

00:10:58.640 --> 00:11:02.640
受け付けてしまい倉庫には発送不可能 な商品の依頼が届くことになり顧客は

00:11:02.640 --> 00:11:04.020
決済後にそれを知ることになります

00:11:04.020 --> 00:11:06.660
これでは誰にとっても余計な手間 が増えるだけです

00:11:06.660 --> 00:11:10.300
在庫情報が連携されていればインテリジェント な注文管理システムがメイン

00:11:10.300 --> 00:11:13.060
倉庫には在庫がないものの近く の店舗にはあることを認識します

00:11:13.060 --> 00:11:16.020
その店舗が配送に対応していれば そこから注文を履行できます

00:11:16.020 --> 00:11:18.940
顧客が店舗受取を選択した場合 はその店舗がそのまま受け取り

00:11:18.940 --> 00:11:19.420
場所となります

00:11:19.420 --> 00:11:22.260
意思決定は在庫をより的確に把握 することから始まります

00:11:22.260 --> 00:11:25.700
複数の法人を持つ企業の場合 この把握は全ての法人の在庫

00:11:25.700 --> 00:11:26.420
を対象とします

00:11:26.420 --> 00:11:30.520
これは複数の国や地域事業部門 で展開しており在庫が一括管理

00:11:30.520 --> 00:11:31.920
されていない場合に重要となります

00:11:31.920 --> 00:11:35.120
注文プロセスはリアルタイム の在庫データを使用してどの経路

00:11:35.120 --> 00:11:36.380
で対応するかを決定します

00:11:36.380 --> 00:11:40.380
倉庫や店舗その他の在庫ソース はそれぞれが個別の在庫記録を

00:11:40.380 --> 00:11:41.000
管理しています

00:11:41.000 --> 00:11:44.540
在庫の可視化により現在の数値 が広範な注文プロセスに取り込

00:11:44.540 --> 00:11:46.660
まれ利口ルールで活用できる ようになります

00:11:46.660 --> 00:11:50.320
これにより過去のデータに基づく 約束を避け顧客からの予定通り

00:11:50.320 --> 00:11:53.100
に届くかという問い合わせに 対しカスタマーサービスが明確

00:11:53.100 --> 00:11:54.100
に答えられるようになります

00:11:54.100 --> 00:11:57.100
複数のシステムを検索して情報 が一致することを願うのではなく

00:11:57.100 --> 00:12:00.140
注文チームは利口の選択に至った 在庫状況を把握できます

00:12:00.140 --> 00:12:03.540
もちろん全ての場所が見えるだけ では全ての疑問が解決するわけ

00:12:03.540 --> 00:12:04.040
ではありません

00:12:04.040 --> 00:12:06.300
商品が5つの場所で見つかる かもしれません

00:12:06.300 --> 00:12:09.880
顧客に最も近い場所在庫が豊富な 場所あるいは両方の製品をまとめて

00:12:09.880 --> 00:12:11.200
発送できる3番目の場所などです

00:12:11.200 --> 00:12:14.000
それでも誰かあるいは何かが 選択する必要があります

00:12:14.000 --> 00:12:17.300
その役割を担うのがフルフィルメント 最適化です

00:12:17.300 --> 00:12:20.700
フルフィルメント最適化

00:12:20.700 --> 00:12:24.600
フルフィルメント注文利口において 発送に最適な場所を選ぶことです

00:12:24.600 --> 00:12:28.220
最適化は注文に対して考えられる 発送場所を比較し企業が設定した

00:12:28.220 --> 00:12:29.580
ルールに基づいて一つを選択します

00:12:29.580 --> 00:12:33.180
簡単に言えばこの注文はどこから 発送すべきかという問いに答える

00:12:33.180 --> 00:12:33.580
ものです

00:12:33.580 --> 00:12:35.940
ベストが必ずしも最寄りお意味する とは限りません

00:12:35.940 --> 00:12:39.380
最寄りの店舗に在庫があっても そこからの発送ではコストが高くなる可能性があります

00:12:39.380 --> 00:12:42.200
遠方の倉庫の方が両方のアイテム をまとめて梱包できたり

00:12:42.200 --> 00:12:45.840
別の場所では在庫があっても顧客が 希望する配送日に間に合わなかったりすることがあります

00:12:45.840 --> 00:12:49.060
企業はそれぞれどのルールを優先 するかを決定しなければなりません

00:12:49.060 --> 00:12:51.360
配送スピードを最優先する企業もあります

00:12:51.360 --> 00:12:53.580
送料を抑えることを望む企業もあります

00:12:53.580 --> 00:12:57.580
また来店客のために店舗在庫を確保したい あるいは選択の余地がない場合を除き

00:12:57.580 --> 00:13:00.380
注文を複数の荷物に分けることを 避けたいと考える企業もあるでしょう

00:13:00.380 --> 00:13:03.540
インテリジェントな注文管理は そうした選択を反映したフルフィルメント

00:13:03.540 --> 00:13:04.440
戦略を採用します

00:13:04.440 --> 00:13:06.900
配送トラックのルート選びのような ものだと考えてください

00:13:06.900 --> 00:13:08.780
最短の道が最速とは限りません

00:13:08.780 --> 00:13:12.380
交通渋滞や工事あるいは思いがけない 立ち寄りが必要になるかもしれないからです

00:13:12.380 --> 00:13:16.320
同様に在庫コストサービスへの約束 配送の選択肢を考慮すると

00:13:16.320 --> 00:13:19.560
必ずしも一番近い拠点が最適な フルフィルメント結果をもたらすとは限りません

00:13:19.560 --> 00:13:22.580
オンラインで2つの商品を購入した 顧客の例に戻ってみましょう

00:13:22.580 --> 00:13:25.220
10分先の店舗に1つ目の商品があります

00:13:25.220 --> 00:13:28.480
倉庫には両方の在庫がありますが 場所は遠くなります

00:13:28.480 --> 00:13:32.000
店舗から1つ目 倉庫から2つ目を発送すれば

00:13:32.000 --> 00:13:35.600
納期には間に合うかもしれませんが 送料は高くなってしまいます

00:13:35.600 --> 00:13:38.940
倉庫からなら両方の商品をまとめて 送ることができるかもしれません

00:13:38.940 --> 00:13:40.700
もし約束した納期に間に合うのであれば

00:13:40.700 --> 00:13:43.420
その場所から1つの荷物で送る方が 懸命な選択かもしれません

00:13:43.420 --> 00:13:46.620
ルールによって配送回数を減らし 送料を抑えることを優先できます

00:13:46.620 --> 00:13:49.440
しかしまとめて送ることよりも 翌日の配送が重要であれば

00:13:49.440 --> 00:13:52.240
システムは一方を店舗から もう一方を倉庫から選ぶことがあり

00:13:52.240 --> 00:13:53.740
これが分割出荷です

00:13:53.740 --> 00:13:56.660
分割出荷はシステムが失敗したことを 意味するわけではありません

00:13:56.660 --> 00:13:59.300
どの単一拠点でも注文全体を適切に 処理できない場合

00:13:59.300 --> 00:14:00.860
それが意図した選択となるのです

00:14:00.860 --> 00:14:04.740
分割が妥当かどうかはビジネスが設定する フルフィルメント戦略によって判断されます

00:14:04.740 --> 00:14:08.180
同じ考え方がオンラインで購入し 店舗から発送する仕組みにも活かされています

00:14:08.180 --> 00:14:10.860
顧客がウェブサイトで注文しても 近くの店舗に在庫があり

00:14:10.860 --> 00:14:12.460
素早く発送できる場合があります

00:14:12.460 --> 00:14:15.040
その場合顧客が一度も訪れたことのない 店舗であっても

00:14:15.040 --> 00:14:16.540
そこがフルフィルメントの拠点となります

00:14:16.540 --> 00:14:20.100
またオンラインで購入し店舗で受け取る 仕組みも同様です

00:14:20.100 --> 00:14:24.240
システムは在庫と位置情報を使用して 受け取り可能な店舗を見つけ

00:14:24.240 --> 00:14:26.880
顧客は地元の受け取り場所を選択でき

00:14:26.880 --> 00:14:29.980
企業は注文を適切な場所へと振り向けます

00:14:29.980 --> 00:14:34.420
これらの選択肢は販売チャンネルごとに 個別に設定する必要はありません

00:14:34.420 --> 00:14:36.500
共通のフルフィルメント判断プロセスがなければ

00:14:36.500 --> 00:14:41.020
ウェブサイトマーケットプレイスコールセンターのそれぞれに 独自のルーティングルールが必要になってしまいます

00:14:41.020 --> 00:14:44.780
配送ポリシーを変更したり店舗をフルフィルメントに 活用し始めたりする際

00:14:44.780 --> 00:14:47.360
チームは複数のシステムを更新しなければならなくなります

00:14:47.360 --> 00:14:51.500
フルフィルメント最適化はその判断プロセスを 注文ジャーニー内の一箇所に集約します

00:14:51.500 --> 00:14:54.900
ウェブサイトは注文を受け続け マーケットプレイスも注文を受け続け

00:14:54.900 --> 00:14:56.660
店舗は商品の販売を続けます

00:14:56.660 --> 00:14:59.600
しかし企業は全てのチャンネルでルールを作り直すことなく

00:14:59.600 --> 00:15:02.240
フルフィルメント拠点の選択方法を変更できます

00:15:02.240 --> 00:15:07.360
これにより在庫の変動や納期の変更 新しい選択肢の追加にも柔軟に対応できるのです

00:15:07.360 --> 00:15:11.640
とはいえフルフィルメント戦略は 関連システムから必要な情報が届いて初めて

00:15:11.640 --> 00:15:13.340
拠点間の比較が可能になります

00:15:13.340 --> 00:15:17.740
注文が入り在庫情報が更新され フルフィルメントのパートナーが業務を受け取り

00:15:17.740 --> 00:15:19.920
進捗を報告し返すという連携が不可欠です

00:15:19.920 --> 00:15:22.580
その接続作業はプロバイダーに依存しています

00:15:22.580 --> 00:15:26.100
プロバイダーと接続は建物への入り口のようなものです

00:15:26.100 --> 00:15:28.460
インテリジェントオーダーマネジメントがその役割を果たすには

00:15:28.460 --> 00:15:31.080
周囲のあらゆるものと確実に対話する方法が必要です

00:15:31.080 --> 00:15:33.060
それを実現するのがプロバイダーです

00:15:33.060 --> 00:15:36.200
プロバイダーとはインテリジェントオーダーマネジメントと他のシステムの間で

00:15:36.200 --> 00:15:39.340
注文詳細やフルフィルメントの更新情報をやり取りするための接続です

00:15:39.340 --> 00:15:42.820
情報は双方向に流れるため手動でコピーする必要はありません

00:15:42.820 --> 00:15:45.200
多くの搬入口がある建物を想像してください

00:15:45.200 --> 00:15:47.820
一つのドアはオンラインストアからの注文を受け取ります

00:15:47.820 --> 00:15:50.020
別のドアは在庫システムに接続します

00:15:50.020 --> 00:15:53.060
三つ目のドアは倉庫や配送パートナーに作業を送信します

00:15:53.060 --> 00:15:54.860
それぞれのドアには明確な目的があり

00:15:54.860 --> 00:15:57.200
プロバイダーが各ドアを通過する情報を管理します

00:15:57.200 --> 00:16:00.200
マイクロソフトはこれらのコネクタの一部を自社で構築しています

00:16:00.200 --> 00:16:02.420
これらはファーストパーティープロバイダーと呼ばれます

00:16:02.420 --> 00:16:04.420
これらはインテリジェントオーダーマネジメントを

00:16:04.420 --> 00:16:06.100
ダイナミクス365サプライチェーンマネジメント

00:16:06.100 --> 00:16:07.520
ダイナミクス365コマース

00:16:07.520 --> 00:16:09.900
ダイナミクス365ファイナンスなどのアプリと接続します

00:16:09.900 --> 00:16:12.180
インテリジェントオーダーマネジメント内の在庫サービスや

00:16:12.180 --> 00:16:13.120
フルフィルメントサービスも

00:16:13.120 --> 00:16:15.340
これらのプロバイダーを使用してデータを交換します

00:16:15.340 --> 00:16:17.960
さておそらくお客様はすでに他のシステムをお使いのことでしょう

00:16:17.960 --> 00:16:19.960
そこで登場するのがサードパーティープロバイダーです

00:16:19.960 --> 00:16:22.360
これらはマイクロソフトが構築していないサービスを接続します

00:16:22.360 --> 00:16:24.220
既存のeコマースプラットフォームマーケットプレイス

00:16:24.220 --> 00:16:26.180
物流企業倉庫システムなどが該当します

00:16:26.180 --> 00:16:28.660
特定のアプリセットへの移行を強制することが目的ではありません

00:16:28.660 --> 00:16:31.300
そうではなくすでにお客様のビジネスに適合しているシステムを

00:16:31.300 --> 00:16:32.600
接続できるようにすることが目的です

00:16:32.600 --> 00:16:34.360
舞台裏ではこれらのプロバイダーは

00:16:34.360 --> 00:16:35.940
パワーオートメートコネクタを使用しています

00:16:35.940 --> 00:16:38.980
パワープラットフォームには200以上の事前構築済みコネクタがあるため

00:16:38.980 --> 00:16:40.360
出発点には事書きません

00:16:40.360 --> 00:16:41.700
もしそれらが適合しない場合でも

00:16:41.700 --> 00:16:43.880
お客様やパートナーが独自のプロバイダーを構築できます

00:16:43.880 --> 00:16:46.440
接続された各アプリはそれぞれ独自の役割を果たし続けます

00:16:46.440 --> 00:16:48.220
オンラインストアが購入を記録します

00:16:48.220 --> 00:16:50.040
在庫システムが在庫を追跡します

00:16:50.040 --> 00:16:52.640
フルフィルメントパートナーが注文を梱包し配送します

00:16:52.640 --> 00:16:54.520
請求システムが財務を処理します

00:16:54.520 --> 00:16:55.980
インテリジェントオーダーマネジメントは

00:16:55.980 --> 00:16:58.480
それらすべての間のメッセージと次のステップを調整します

00:16:58.480 --> 00:17:00.280
これらのシステムが更新を共有すれば

00:17:00.280 --> 00:17:03.180
ビジネス全体で注文プロセスで何が起こっているかを把握できます

00:17:03.180 --> 00:17:05.940
個別の画面を追いかける必要はもうありません

00:17:05.940 --> 00:17:08.700
洞察と全体像が得られます

00:17:08.700 --> 00:17:10.340
共有された情報により

00:17:10.340 --> 00:17:12.740
注文業務の全体像がより鮮明になります

00:17:12.740 --> 00:17:14.260
インテリジェントオーダーマネジメントには

00:17:14.260 --> 00:17:15.820
Power BIダッシュボードが含まれており

00:17:15.820 --> 00:17:18.020
注文とフルフィルメントの指標を一元管理できます

00:17:18.020 --> 00:17:18.980
カスタマーサービスは

00:17:18.980 --> 00:17:20.940
動きが止まった注文を見つけることができます

00:17:20.940 --> 00:17:21.740
運用部門は

00:17:21.740 --> 00:17:24.000
ブロックされたルートやフルフィルメントの遅延を発見できます

00:17:24.000 --> 00:17:25.100
そしてビジネスリーダーは

00:17:25.100 --> 00:17:27.180
プロセス全体に渡るパターンを探ることができます

00:17:27.180 --> 00:17:28.640
そのような視点がなければ

00:17:28.640 --> 00:17:30.700
遅延は個別の問題のように見えるかもしれません

00:17:30.700 --> 00:17:32.200
しかしデータを統合すれば

00:17:32.200 --> 00:17:35.060
特定のフルフィルメントパートナーで注文が停滞していることや

00:17:35.060 --> 00:17:37.900
特定の配送オプションで予期せぬ例外が発生していることに

00:17:37.900 --> 00:17:39.020
チームが気づくかもしれません

00:17:39.020 --> 00:17:41.460
ダッシュボード自体が問題を解決するわけではありませんが

00:17:41.460 --> 00:17:43.760
どこを見るべきかを正確に把握する助けとなります

00:17:43.760 --> 00:17:45.660
オフィスビルを思い出してみてください

00:17:45.660 --> 00:17:47.480
インテリジェント注文管理は

00:17:47.480 --> 00:17:48.980
依頼を受ける受付

00:17:48.980 --> 00:17:50.720
在庫を示す掲示板

00:17:50.720 --> 00:17:52.860
配送拠点を選ぶルート計画

00:17:52.860 --> 00:17:56.360
そして状況を確認する報告室を一つにまとめます

00:17:56.360 --> 00:17:58.200
それぞれ役割は異なりますが

00:17:58.200 --> 00:18:00.280
注文がそれらすべてをつなぎます

00:18:00.280 --> 00:18:01.260
結論として

00:18:01.260 --> 00:18:02.420
一つの注文が

00:18:02.420 --> 00:18:04.420
一つの連携した旅路を生むのです

00:18:04.420 --> 00:18:06.900
今回のミニ知識にお付き合いいただきありがとうございました

00:18:06.900 --> 00:18:08.440
インテリジェント注文管理は

00:18:08.440 --> 00:18:10.220
注文の取り込みから最終的な請求まで

00:18:11.460 --> 00:18:12.540
インテリジェント注文の直通ルートを描き出します

00:18:12.540 --> 00:18:14.360
お気に入りのポッドキャストプラットフォームで登録して

00:18:14.360 --> 00:18:15.840
次のエピソードもぜひご覧ください

00:18:15.840 --> 00:18:17.820
ダイナミクス365とパワープラットフォームが

00:18:17.820 --> 00:18:19.960
裏側でどのように業務を処理しているのかが詳しくわかります