顧客がウェブサイトで購入ボタン を押したときその商品は倉庫にあるかもしれませんし街の反対側 の店舗あるいは配送業者の手元にあるかもしれませんしかし顧客 が本当に期待しているのはたった2つのことだけです明確な約束 と玄関先に届く荷物ですm365fmのマイクロソフトナレッジナゲッツ へようこそ私はもうピーターズです今日はダイナミクス365インテリジェント オーダーマネジメントについてわかりやすく解説しますチェック アウトのクリックから実際に商品が配送されるまでのプロセス を追っていきましょうこれは忙しいオフィスビルの中央管理デスク のようなものだと考えてくださいオンラインショップを追加する わけでも箱詰めをするわけでもありません適切な担当者やシステム に指示を出しあるべき場所で作業が完了するように導くのですなぜ 注文処理は複雑になるのでしょうかウェブサイト実店舗オンライン マーケットプレイスコールセンターで同じヘッドホンを販売している と想像してください顧客にとってこれらはすべてヘッドホン を買うための手段にすぎませんしかし舞台裏では各チャンネル が全く異なるシステムに注文詳細を送っていますウェブサイトは 独自の記録を持ち店舗のポスは別の記録をマーケットプレイス は独自の形式を送りコールセンターの担当者はまた別の場所に注文 を作成します顧客への一つのシンプルな約束 が互いに連携しない複数の断片に分断されてしまうのですさらに 在庫が複雑さに拍車をかけますメインの倉庫には20個あるかもしれません 街の反対側の店舗には5個別の倉庫にも在庫があるかもしれません しかしそこは遠くて送料が高くつくかもしれません一部の在庫 は他の注文用返品用あるいは店頭購入者用に確保されていることも ありますですから製品の横に表示された数値を見るだけでは問題 は解決しないのです次にどのように配送するかを決め なければなりません倉庫から発送すべきでしょうか 店舗から発送すべきでしょうかそれとも顧客が近くの店舗で 受け取れるようにすべきでしょうかもし誰かが2つの商品を買いどちら の場所にも両方揃っていない場合注文を2つの荷物に分けますかそれとも 全て揃うまで待ちますかあらゆる選択がコスト配送時間そして顧客 との約束に影響を与えます20年前企業はこうした業務を個別のシステム とチームで運用していました営業が注文を受けます誰かが在庫 を確認します倉庫に依頼が届きます配送業者に別の依頼が届きます 請求処理は後で担当部署が行います注文が単純で件数が少なかった 頃はそれでうまくいっていましたしかし問題はここにあります システム間の情報の更新が遅いと人間がその隙間を埋め始め なければなりませんカスタマーサービスの担当者が 一つの画面を確認し倉庫チームにメールを送り配送業者に電話 をかけるその間に在庫情報がウェブサイトに反映されるより 早く別のチャンネルで商品が売れてしまう可能性があるのです在庫 のない商品の注文を受けてしまう状況ですこれが売り越しという 問題を引き起こします配送手段の決定に時間がかかる のもそのためですチーム間で詳細をコピーし続けるため顧客には 明確な回答ではなく曖昧な報告しか届きません顧客にとって そのような複雑さは関係ありません彼らが聞きたいことは一つだけ です注文したものはどこにあるの企業に必要なのは全てのビジネス アプリを連携させそれぞれの得意分野を生かしながら注文の流れ を一元管理できる場所です販売部門は受注を管理します倉庫部門は ピッキングと梱包を管理します配送部門は配達を管理します経理 部門は支払いを管理します既存のシステムを全て捨てる必要はありません 必要なのはそれらを統合するコーディネーターです空いた 注文を受け取り次に何をすべきかを把握し手作業による引き継ぎ を減らして業務を指示できる場所ですそれが課題なのですダイナミクス 365インテリジェントオーダーマネジメントはまさにこの課題に答えるもの ですではダイナミクス365インテリジェントオーダーマネジメントとは具体的 に何でしょうか今日はその仕組みをわかりやすく解説します最もシンプル な定義はこうです注文発生から履行そして請求まで企業がすでに 使用しているすべてのシステムをクラウド上で一括して管理する アプリです忙しい鉄道駅を想像してください列車は様々な方面 から到着します乗客はそれぞれの目的地へ向かいますスムーズ な乗り継ぎもあれば待ち時間が必要な場合もありますインテリジェント オーダーマネジメントはその駅の指令室のような役割を果たします 列車を運転したりチケットを売ったりはしませんが全体の経路を把握 し各システムに次にすべきことを指示しますマイクロソフト はデータバースの上にインテリジェントオーダーマネジメントを構築しました データバースは多くのダイナミクス365やパワープラットフォームアプリ を支える共通のデータ基盤です簡単に言えばビジネスアプリに 情報を保存するための共通の場所と共通の形式を提供しますこれ により画面やシステムごとに注文データが全く別の意味を持つとい ったことがなくなりますこの共通基盤は便利ですがインテリジェント オーダーマネジメントを利用するために他のすべてのダイナミクス 365アプリを購入する必要はありませんダイナミクス365ファイナンス やサプライチェーンマネジメントを運用している企業もあれば別の 倉庫システムやオンラインストア他社の配送サービスを利用している 企業もあるでしょうこのアプリはマイクロソフト 正解なかを問わずあらゆるビジネスアプリと連携できますその接続 点はプロバイダーと呼ばれますプロバイダーはインテリジェント オーダーマネジメントと外部システムの間で注文情報や利口 情報をやり取りしますプロバイダーは玄関口の通訳 のようなものだと考えてくださいあるシステムが独自の形式で注文 を送信するとプロバイダーがその形式を理解して情報をインテリジェント オーダーマネジメントに渡し相手のシステムが理解できる形式で 次の要求を送り返しますつまりこのアプリは注文がどこ から始まったかに関わらず注文情報を一元管理しますアイオコマースサイトを通じて 購入する顧客もいればホスシステムを通じて注文する 顧客もいます法人顧客がB2Bプロセスを通じて 電子注文を送ることもあるでしょうインテリジェント注文管理システム を使えば企業はそうした注文を一箇所で確認しそれぞれの利口 状況を把握できます全ての注文が同じ経路をたどる わけではありません在庫を待つ必要がある注文もあれば 既に倉庫に準備されている注文もあります配送後に請求手続きが必要な 注文もあるでしょうアプリがその状態を追跡するため チームは単に注文を受領したこと以上の状況を把握できます注文が現在どのような工程に あるのか正確に確認できるのですここで見落とされがちなポイント がありますインテリジェント注文管理システム は全ての業務を肩代わりするわけではありません倉庫作業員のピッキング画面 や配送業者のネットワーク財務チームの請求システムにとって 変わるものではありませんそれらの連携アプリは引き続き 専門的な業務を遂行しますインテリジェント注文管理システム はそれらの間の引き継ぎを制御しますリクエストを受け取りルート を確認し作業を引き継ぎ次の更新を待ちますそれでは一つの注文が辿る道のり を見てみましょう注文の過程を追うことで全体の 仕組みがより理解しやすくなります注文の過程を決定づけるのは業務 を支持するルールです例えば顧客が午後の遅い時間に ウェブサイトから商品を2点注文し翌日の配送を希望したとしますオンラインストアは顧客名配送先 住所注文品目配送オプションなどの注文情報を取得しますプロバイダーがその注文をインテリジェント 注文管理システムに取り込むと注文の過程が始まります履行を開始する前にシステムは 注文を検証し旅に必要な情報が全て揃っているか会社のルール に従っているかを確認します注文ヘッダーの顧客情報や配送 詳細を確認します各注文明細の製品と数量をチェック します住所が配送に十分な情報を含んでいる かを確認しその販売チャンネルのルールに適合しているかを判断 します最初のチェックにより誤った 情報が下流に流れて問題を引き起こすのを未然に防ぎますアパート番号が欠落している注文 を想像してみてくださいもしそのまま倉庫へ送られ配送 業者に渡ってしまったら配達できない事態になって初めて問題が発覚 するかもしれません検証プロセスがあれば顧客への 連絡や注文の一時保留といった対応が間に合う段階で問題を特定 できますこの作業の根幹となるのがオーケストレーション フローです専門用語に聞こえるかもしれません が仕組みは単純ですオーケストレーションフローとは 注文情報の到着や連携システムからのイベント発生に応じて何を 行うべきかをインテリジェント注文管理システムに示す視覚的なマップ ですこのマップは記者のビジネスプロセス に合わせて作成します基本的な注文フローは新規注文 の到着とともに始まりますヘッダーと迷彩を検証しますフルフィルメント配送の判断 のために注文を送信しますその後適切な接続システムへフルフィルメント 注文を送信します作業が適切な段階に達すると請求 プロバイダーへ注文情報を送信できます各アクションには明確な役割 があります注文ヘッダーの検証は注文の主要 な詳細を確認します注文明細の検証は個々の製品と 数量を確認しますフルフィルメントへ送信はその作業 を扱うプロバイダーに注文を引き渡します請求へ送信は注文情報を請求 プロバイダーに渡しますこれらの名称は工場の制御パネル のラベルのように聞こえますがラベルがフローのその地点で 何が起こるかを正確に示してくれるため便利ですしかし実際のビジネスでは単なる 直線的な流れでは不十分な場合がよくありますウェブサイトからの注文は一つの 経路をたどり法人顧客からの注文は別の経路をたどるかもしれません特定の製品には特別な承認が 必要になる場合もあります最初のステップが成功した場合にのみ 注文が次に進めるということもあるでしょうインテリジェント注文管理にはその ような選択のための条件が含まれています条件によってはいのパスといいえ のパスが作成されます前のステップが成功すれば注文 ははいのパスに進むことができます失敗した場合はフローによって 別のパスへ注文を振り向けることができますこれで全ての問題が解決するわけ ではありませんがチームが偶然エラーを発見するのを待つのでは なくプロセスに計画的な対応を組み込めますスプリッター分岐もありますスプリッターは定義したルール に基づいてフローを複数のパスに分岐させます異なるソースからの注文に個別 のチェックが必要な場合や作業の各部分に異なるルートが必要な 場合に使用できます分岐したパスの一部は後で統合 されることもあればそれぞれ独立して進むこともありますカスタムアクションは特定のビジネス に固有の作業をカバーします企業が独自の製造システムを持って いたり標準のアクションではカバーされないパートナーシステムを 使用していたりする場合があるでしょうカスタムアクションを使えばその ステップを注文フローに統合できるため一部の作業がメール や手作業に隠れることなくプロセス全体を可視化できます2品目の注文の例に戻りましょうシステムはウェブサイトから注文 を受け取り顧客の詳細住所製品ラインを確認します次に注文はフルフィルメントの 決定ステップに到達します両方の品目が同じルートを通れる 場合フローはフルフィルメントのリクエストを一つの単位として 先に送れます会社のルールで異なる結果が求め られる場合は別のパスをたどらせることができます2つの品目に別々のフルフィルメント 要求が必要だったり異なる配送オプションが必要だったりする かもしれませんフローは推測を行いませんビジネスが作成したルールと接続 されたシステムから返されるイベントに従います最後の部分が重要ですインテリジェント注文管理は作業 を支持できますが作業が進むにつれて接続されたシステムが報告 を返してくるのですフルフィルメントプロバイダー がリクエストを受け取ることができます請求プロバイダーが注文の詳細 を受け取ることができますこうしたイベントによって注文 の旅路はフローの中を進み続けますつまりこのアプリは巨大な代替 システムではありませんこれは専門システム同士をつなぎ 必要な仕事を適切なタイミングで各システムに割り振る一連 のルールですオンラインストアが注文を補足 しますフルフィルメントシステムが配送 を処理します請求システムが支払いを処理 しますインテリジェント注文管理はそれら の業務間のルートを管理します注文プロセスを担当する人々 はアプリ内で直接これらのフローを設計できます全ての経路を従来のコードとして 記述する必要はなくビジネスルールを変更するたびにIT管理者に依頼 する必要もありませんこれによりサプライチェーンチーム は実際に必要なプロセスをモデル化できるようになりますとはいえこうした変更には慎重 差が必要ですオーケストレーションフローは構築 やテストの段階では非公開の状態にもたれますその段階では入ってくるデータが フロー内を流れることはありません公開するとデータがシステム に入力された際にフローとそのアクションが実行されます公開した後はその公開済フロー を直接編集することはできませんビジネス上の変更が必要な場合 チームは公開されたフローを停止することで未公開の状態に戻せ ますフローを編集し準備が整ったら 新しいバージョンを公開できますこの仕組みによりチームは実際 の注文が流れる前にルートをテストするよう促されますルートは何が実際に利用可能な 在庫であるかを把握して初めて機能しますそこで各フルフィルメントの 決定を支えるライブ在庫情報が必要となります在庫の可視化つまり実際に販売 可能なものを把握することです明白な事実をお伝えしましょう在庫があることを知らなければ 注文を履行することはできません当たり前に聞こえるかもしれません が在庫は倉庫店舗パートナーの拠点あるいは同一企業内の異なる 法人のどこかに隠れていることがあります各拠点が独自のカウントを保持 していると今この顧客に何を約束できるのかという基本的な 質問に答えられません在庫の可視化によりインテリジェント 注文管理はサプライネットワーク全体の在庫をライブで把握できます配送センターにある在庫ボード のようなものだと考えてください全ての棚に電話をかけて確認を 依頼する代わりに注文プロセスは全てのシステムからデータが 集まる単一の共有ビューを参照しますただしどこかに在庫として表示 されているからといってあらゆる注文を履行 できるわけではありません製品が倉庫にあってもすでに予約 済みであったり店頭販売用で出荷負荷であったりあるいは顧客が 選択した配送約束を守るには単に遠すぎたりする場合もありますどこかに存在する在庫と今すぐ この注文を履行できる在庫の間には大きな違いがあるのですある顧客がオンラインでジャケット を購入し明日届けて欲しいと望んでいるとしましょうメインの倉庫にはもう在庫が残 っていません最新の在庫データがなければウェブ サイトは古い情報のまま注文を受け付けてしまい倉庫には発送不可能 な商品の依頼が届くことになり顧客は決済後にそれを知ることになりますこれでは誰にとっても余計な手間 が増えるだけです在庫情報が連携されていればインテリジェント な注文管理システムがメイン倉庫には在庫がないものの近く の店舗にはあることを認識しますその店舗が配送に対応していれば そこから注文を履行できます顧客が店舗受取を選択した場合 はその店舗がそのまま受け取り場所となります意思決定は在庫をより的確に把握 することから始まります複数の法人を持つ企業の場合 この把握は全ての法人の在庫を対象としますこれは複数の国や地域事業部門 で展開しており在庫が一括管理されていない場合に重要となります注文プロセスはリアルタイム の在庫データを使用してどの経路で対応するかを決定します倉庫や店舗その他の在庫ソース はそれぞれが個別の在庫記録を管理しています在庫の可視化により現在の数値 が広範な注文プロセスに取り込まれ利口ルールで活用できる ようになりますこれにより過去のデータに基づく 約束を避け顧客からの予定通りに届くかという問い合わせに 対しカスタマーサービスが明確に答えられるようになります複数のシステムを検索して情報 が一致することを願うのではなく注文チームは利口の選択に至った 在庫状況を把握できますもちろん全ての場所が見えるだけ では全ての疑問が解決するわけではありません商品が5つの場所で見つかる かもしれません顧客に最も近い場所在庫が豊富な 場所あるいは両方の製品をまとめて発送できる3番目の場所などですそれでも誰かあるいは何かが 選択する必要がありますその役割を担うのがフルフィルメント 最適化ですフルフィルメント最適化フルフィルメント注文利口において 発送に最適な場所を選ぶことです最適化は注文に対して考えられる 発送場所を比較し企業が設定したルールに基づいて一つを選択します簡単に言えばこの注文はどこから 発送すべきかという問いに答えるものですベストが必ずしも最寄りお意味する とは限りません最寄りの店舗に在庫があっても そこからの発送ではコストが高くなる可能性があります遠方の倉庫の方が両方のアイテム をまとめて梱包できたり別の場所では在庫があっても顧客が 希望する配送日に間に合わなかったりすることがあります企業はそれぞれどのルールを優先 するかを決定しなければなりません配送スピードを最優先する企業もあります送料を抑えることを望む企業もありますまた来店客のために店舗在庫を確保したい あるいは選択の余地がない場合を除き注文を複数の荷物に分けることを 避けたいと考える企業もあるでしょうインテリジェントな注文管理は そうした選択を反映したフルフィルメント戦略を採用します配送トラックのルート選びのような ものだと考えてください最短の道が最速とは限りません交通渋滞や工事あるいは思いがけない 立ち寄りが必要になるかもしれないからです同様に在庫コストサービスへの約束 配送の選択肢を考慮すると必ずしも一番近い拠点が最適な フルフィルメント結果をもたらすとは限りませんオンラインで2つの商品を購入した 顧客の例に戻ってみましょう10分先の店舗に1つ目の商品があります倉庫には両方の在庫がありますが 場所は遠くなります店舗から1つ目 倉庫から2つ目を発送すれば納期には間に合うかもしれませんが 送料は高くなってしまいます倉庫からなら両方の商品をまとめて 送ることができるかもしれませんもし約束した納期に間に合うのであればその場所から1つの荷物で送る方が 懸命な選択かもしれませんルールによって配送回数を減らし 送料を抑えることを優先できますしかしまとめて送ることよりも 翌日の配送が重要であればシステムは一方を店舗から もう一方を倉庫から選ぶことがありこれが分割出荷です分割出荷はシステムが失敗したことを 意味するわけではありませんどの単一拠点でも注文全体を適切に 処理できない場合それが意図した選択となるのです分割が妥当かどうかはビジネスが設定する フルフィルメント戦略によって判断されます同じ考え方がオンラインで購入し 店舗から発送する仕組みにも活かされています顧客がウェブサイトで注文しても 近くの店舗に在庫があり素早く発送できる場合がありますその場合顧客が一度も訪れたことのない 店舗であってもそこがフルフィルメントの拠点となりますまたオンラインで購入し店舗で受け取る 仕組みも同様ですシステムは在庫と位置情報を使用して 受け取り可能な店舗を見つけ顧客は地元の受け取り場所を選択でき企業は注文を適切な場所へと振り向けますこれらの選択肢は販売チャンネルごとに 個別に設定する必要はありません共通のフルフィルメント判断プロセスがなければウェブサイトマーケットプレイスコールセンターのそれぞれに 独自のルーティングルールが必要になってしまいます配送ポリシーを変更したり店舗をフルフィルメントに 活用し始めたりする際チームは複数のシステムを更新しなければならなくなりますフルフィルメント最適化はその判断プロセスを 注文ジャーニー内の一箇所に集約しますウェブサイトは注文を受け続け マーケットプレイスも注文を受け続け店舗は商品の販売を続けますしかし企業は全てのチャンネルでルールを作り直すことなくフルフィルメント拠点の選択方法を変更できますこれにより在庫の変動や納期の変更 新しい選択肢の追加にも柔軟に対応できるのですとはいえフルフィルメント戦略は 関連システムから必要な情報が届いて初めて拠点間の比較が可能になります注文が入り在庫情報が更新され フルフィルメントのパートナーが業務を受け取り進捗を報告し返すという連携が不可欠ですその接続作業はプロバイダーに依存していますプロバイダーと接続は建物への入り口のようなものですインテリジェントオーダーマネジメントがその役割を果たすには周囲のあらゆるものと確実に対話する方法が必要ですそれを実現するのがプロバイダーですプロバイダーとはインテリジェントオーダーマネジメントと他のシステムの間で注文詳細やフルフィルメントの更新情報をやり取りするための接続です情報は双方向に流れるため手動でコピーする必要はありません多くの搬入口がある建物を想像してください一つのドアはオンラインストアからの注文を受け取ります別のドアは在庫システムに接続します三つ目のドアは倉庫や配送パートナーに作業を送信しますそれぞれのドアには明確な目的がありプロバイダーが各ドアを通過する情報を管理しますマイクロソフトはこれらのコネクタの一部を自社で構築していますこれらはファーストパーティープロバイダーと呼ばれますこれらはインテリジェントオーダーマネジメントをダイナミクス365サプライチェーンマネジメントダイナミクス365コマースダイナミクス365ファイナンスなどのアプリと接続しますインテリジェントオーダーマネジメント内の在庫サービスやフルフィルメントサービスもこれらのプロバイダーを使用してデータを交換しますさておそらくお客様はすでに他のシステムをお使いのことでしょうそこで登場するのがサードパーティープロバイダーですこれらはマイクロソフトが構築していないサービスを接続します既存のeコマースプラットフォームマーケットプレイス物流企業倉庫システムなどが該当します特定のアプリセットへの移行を強制することが目的ではありませんそうではなくすでにお客様のビジネスに適合しているシステムを接続できるようにすることが目的です舞台裏ではこれらのプロバイダーはパワーオートメートコネクタを使用していますパワープラットフォームには200以上の事前構築済みコネクタがあるため出発点には事書きませんもしそれらが適合しない場合でもお客様やパートナーが独自のプロバイダーを構築できます接続された各アプリはそれぞれ独自の役割を果たし続けますオンラインストアが購入を記録します在庫システムが在庫を追跡しますフルフィルメントパートナーが注文を梱包し配送します請求システムが財務を処理しますインテリジェントオーダーマネジメントはそれらすべての間のメッセージと次のステップを調整しますこれらのシステムが更新を共有すればビジネス全体で注文プロセスで何が起こっているかを把握できます個別の画面を追いかける必要はもうありません洞察と全体像が得られます共有された情報により注文業務の全体像がより鮮明になりますインテリジェントオーダーマネジメントにはPower BIダッシュボードが含まれており注文とフルフィルメントの指標を一元管理できますカスタマーサービスは動きが止まった注文を見つけることができます運用部門はブロックされたルートやフルフィルメントの遅延を発見できますそしてビジネスリーダーはプロセス全体に渡るパターンを探ることができますそのような視点がなければ遅延は個別の問題のように見えるかもしれませんしかしデータを統合すれば特定のフルフィルメントパートナーで注文が停滞していることや特定の配送オプションで予期せぬ例外が発生していることにチームが気づくかもしれませんダッシュボード自体が問題を解決するわけではありませんがどこを見るべきかを正確に把握する助けとなりますオフィスビルを思い出してみてくださいインテリジェント注文管理は依頼を受ける受付在庫を示す掲示板配送拠点を選ぶルート計画そして状況を確認する報告室を一つにまとめますそれぞれ役割は異なりますが注文がそれらすべてをつなぎます結論として一つの注文が一つの連携した旅路を生むのです今回のミニ知識にお付き合いいただきありがとうございましたインテリジェント注文管理は注文の取り込みから最終的な請求までインテリジェント注文の直通ルートを描き出しますお気に入りのポッドキャストプラットフォームで登録して次のエピソードもぜひご覧くださいダイナミクス365とパワープラットフォームが裏側でどのように業務を処理しているのかが詳しくわかります