WEBVTT

00:00:00.000 --> 00:00:04.720
職場で新しいノートPCや生産用の原材料あるいは清掃サービスが必要になった時何が起こるでしょうか

00:00:04.720 --> 00:00:10.720
多くの企業では従来はメールスプレッドシート市の書類を使い何週間も経ってから誰かが請求書を追跡するような状況でした

00:00:10.720 --> 00:00:14.620
マイクロソフトのウルジナゲットソンM365FMへようこそ

00:00:14.620 --> 00:00:15.920
ミルコピーターズです

00:00:15.920 --> 00:00:21.760
今日は企業がベンダーから商品やサービスを購入するための一連のプロセスである調達とソーシングについて見ていきます

00:00:21.760 --> 00:00:24.400
オフィスビルの受付窓口を想像してみてください

00:00:24.400 --> 00:00:29.420
すべての依頼承認発注納品請求支払いが同じ場所を通ります

00:00:29.420 --> 00:00:34.580
最初の依頼から舞台裏で機能する管理プロセスまで一つの購入事例を追跡します

00:00:34.580 --> 00:00:38.120
一つ目は調達とソーシングが実際に何をカバーしているかです

00:00:38.120 --> 00:00:41.640
調達とソーシングは単に物を買うにしては長い名称に聞こえるかもしれません

00:00:41.640 --> 00:00:44.940
確かに購入に関することですがこの2つの言葉は異なる役割を表しています

00:00:44.940 --> 00:00:48.140
ソーシングとは適切なベンダーを見つけて選定する作業のことです

00:00:48.140 --> 00:00:52.140
手袋ヘルメット安全標識保護眼鏡が必要な会社を想像してください

00:00:52.140 --> 00:00:56.980
発注を行う前に誰が適切な製品を許容範囲内の価格で必要な期日までに

00:00:56.980 --> 00:00:59.600
会社が合意できる条件で供給できるかを決めなければなりません

00:00:59.600 --> 00:01:01.000
それがソーシングです

00:01:01.000 --> 00:01:04.660
調達は会社が実際の購入プロセスを管理する必要がある段階から始まります

00:01:04.660 --> 00:01:08.780
これには依頼承認発注書納品請求書支払いまでが含まれます

00:01:08.780 --> 00:01:11.540
これらを合わせてソーストペープロセスと呼びます

00:01:11.540 --> 00:01:14.020
この名前は全体の道のりを表しています

00:01:14.020 --> 00:01:19.220
企業がニーズを特定しサプライヤーを選び発注を送り商品やサービスを受け取り

00:01:19.220 --> 00:01:21.840
ベンダーから請求書を受け取り経理がベンダーに支払います

00:01:21.840 --> 00:01:23.760
各ステップは次へと繋がっています

00:01:23.760 --> 00:01:25.560
当たり前のことのように思えるかもしれませんが

00:01:25.560 --> 00:01:28.280
多くの企業では今でもこれらのステップを別々の場所で実行しています

00:01:28.280 --> 00:01:29.860
従業員がメールで依頼を送り

00:01:29.860 --> 00:01:31.600
マネージャーがチャットメッセージで承認し

00:01:31.600 --> 00:01:33.920
担当者がスプレッドシートで注文詳細を管理し

00:01:33.920 --> 00:01:35.620
倉庫が紙の納品書を確認し

00:01:35.620 --> 00:01:38.820
経理が注文との関連性が不明確な請求書を受け取るといった状況です

00:01:38.820 --> 00:01:42.020
それでも購入は可能ですが経緯がわからなくなってしまいます

00:01:49.220 --> 00:01:52.780
マネージャーはお金が会社から出ていった後に初めてコストを知ることになります

00:01:52.780 --> 00:01:55.320
誰かが誰がこれを承認したのかと尋ねた時

00:01:55.320 --> 00:01:58.040
その答えを見つけるには受信トレイを長時間検索しなければなりません

00:01:58.040 --> 00:02:01.820
ダイナミクス365はその追跡記録を一つの接続されたプラットフォームに集約します

00:02:01.820 --> 00:02:04.780
ダイナミクス365サプライチェーンマネジメントにおける調達

00:02:04.780 --> 00:02:08.720
ソーシングは企業が商品の移動や在庫状況を管理する基盤であり

00:02:08.720 --> 00:02:11.580
財務や買いかけ金管理と連携して請求書の記録

00:02:11.580 --> 00:02:14.240
未払金の追跡支払処理を行います

00:02:14.240 --> 00:02:16.920
つまり購買は孤立した業務ではありません

00:02:16.920 --> 00:02:21.440
倉庫部門は商品の到着を記録し財務部門は購入に関連する請求書を確認でき

00:02:21.440 --> 00:02:26.020
買いかけ金管理部門は注文内容と到着品そしてベンダーからの請求金額を称号できます

00:02:26.020 --> 00:02:30.640
各チームは必要な情報のみを参照しますが購入プロセスは一つの繋がった記録として保持されます

00:02:30.640 --> 00:02:32.740
購買には大きく分けて2つの種類があります

00:02:32.740 --> 00:02:37.020
直接調達とは企業が製造または販売する製品に直接結びつく商品やサービスのことです

00:02:37.020 --> 00:02:40.900
家具メーカーが木材ネジ布地を購入するのは直接材料の購入にあたります

00:02:40.900 --> 00:02:44.020
これらの材料がなければ販売する製品を製造できないからです

00:02:44.020 --> 00:02:48.680
間接調達とはビジネスを運営するために必要なものの販売製品の一部にはならないものを指します

00:02:48.680 --> 00:02:53.120
ノートPCオフィス家具研修修理清掃ソフトウェアホームアドバイスなどが含まれます

00:02:53.120 --> 00:02:55.980
どちらも重要ですが多くの場合開始のきっかけが異なります

00:02:55.980 --> 00:02:58.740
生産需要によって会社に部品が必要であることが判明します

00:02:58.740 --> 00:03:01.040
従業員が新しいモニターをリクエストすることもあります

00:03:01.040 --> 00:03:03.460
施設管理者が修理サービスを必要とすることもあります

00:03:03.460 --> 00:03:07.500
ダイナミクス365はこれらすべての異なるニーズを扱いながら購買経路を明確に保ちます

00:03:07.500 --> 00:03:10.480
このエピソードでは一つのシンプルな例を使って説明しましょう

00:03:10.480 --> 00:03:14.060
倉庫マネージャーがチームに新しい安全装備が必要だと気づいたとします

00:03:14.060 --> 00:03:17.180
ヘルメットが破損しており保護手袋の在庫も不足しています

00:03:17.180 --> 00:03:19.380
マネージャーはチームのために十分な装備を必要とし

00:03:19.380 --> 00:03:21.880
会社は資金を投入する前に明確な記録を必要とします

00:03:21.880 --> 00:03:24.320
購買はニーズから始まり管理されたすべての購入は

00:03:24.320 --> 00:03:26.380
誰かが何かを要求することから始まります

00:03:26.380 --> 00:03:29.760
次は社内のリクエストから適切なベンダーへの発注についてです

00:03:29.760 --> 00:03:32.620
購買プロセス全体がどのように始まるのかを見ていきましょう

00:03:32.620 --> 00:03:34.960
倉庫マネージャーが安全装備の必要性に気づくと

00:03:34.960 --> 00:03:38.640
ダイナミクス365内で最初に作成される記録が購買依頼です

00:03:38.640 --> 00:03:41.740
購買依頼とは社内で何かを購入するための申請です

00:03:41.740 --> 00:03:44.040
これには誰が何をどれくらい必要としているか

00:03:44.040 --> 00:03:46.340
そして多くの場合どこへ配送すべきかが記載されます

00:03:46.340 --> 00:03:49.900
この段階ではベンダーに対して何らかの約束をしているわけではないことに注目してください

00:03:49.900 --> 00:03:53.640
この区別があることで購買の初期段階を自社の管理下に置くことができます

00:03:53.640 --> 00:03:57.040
倉庫マネージャーはヘルメット20個と手袋数箱を依頼できますが

00:03:57.040 --> 00:04:00.360
関係者が承認するまでサプライヤーに注文が送られることはありません

00:04:00.360 --> 00:04:03.780
一般的な購入の場合リクエストは製品カタログから始まることがあります

00:04:03.780 --> 00:04:07.100
カタログは会社が承認したショッピング棚のようなものだと考えてください

00:04:07.100 --> 00:04:10.140
安全手袋といった曖昧な依頼を入力する代わりに

00:04:10.140 --> 00:04:14.500
従業員は説明、サプライヤー、価格があらかじめ設定された承認済製品を選択できます

00:04:14.500 --> 00:04:16.340
これにより時間が短縮されるだけでなく

00:04:16.340 --> 00:04:19.280
社内規定に合わない勝手な製品の購入を防ぐこともできます

00:04:19.280 --> 00:04:21.840
すべての要望がカタログに収まるわけではありません

00:04:21.840 --> 00:04:23.560
一度限りの修理やコンサルタントの研修

00:04:23.560 --> 00:04:26.600
あるいは物理的な製品として保管されないサービスが必要になる場合もあります

00:04:26.600 --> 00:04:29.860
そのような場合ダイナミクス365では調達カテゴリを使用できます

00:04:29.860 --> 00:04:32.720
調達カテゴリは支出の内容に基づいてグループ化します

00:04:32.720 --> 00:04:37.940
例えば安全用品、建物の修繕、ホームサービス、コンピュータ機器といったカテゴリを利用できます

00:04:37.940 --> 00:04:41.480
棚に在庫番号がない場合でも申請者は必要なものを説明し

00:04:41.480 --> 00:04:43.460
適切なカテゴリに分類することができます

00:04:43.460 --> 00:04:45.300
もっとも送信ボタンを押しただけで

00:04:45.300 --> 00:04:47.440
要望がそのまま購入に結びつくわけではありません

00:04:47.440 --> 00:04:50.820
会社は支出限度額、予算チェック、承認ワークフローを設定できます

00:04:50.820 --> 00:04:54.080
手袋のような奨学の要望は倉庫管理者に送られるかもしれません

00:04:54.080 --> 00:04:55.980
安全装備のようなより大きな要望には

00:04:55.980 --> 00:04:59.140
部門の予算責任者や購買チームの承認が必要になることもあります

00:04:59.140 --> 00:05:03.980
承認ルートは金額、部門、あるいはその支出タイプに関連付けられた購買ルールに基づいて変わります

00:05:03.980 --> 00:05:08.240
そのため従業員一人一人が全ての承認ルールを覚える必要はありません

00:05:08.240 --> 00:05:11.760
ダイナミクス365は要望を正しいルートに送り

00:05:11.760 --> 00:05:14.040
その履歴はシステム内に保持されます

00:05:14.040 --> 00:05:16.220
マネージャーが大量の機器を要望し

00:05:16.220 --> 00:05:19.400
どのベンダーに発注すべきか未定であると仮定します

00:05:19.400 --> 00:05:22.940
購買部門は見積もり以来通称RF9を作成できます

00:05:22.940 --> 00:05:26.540
RF9は同じニーズに対して複数のベンダーに入札を求めるものです

00:05:26.540 --> 00:05:31.140
バイヤーはヘルメットの種類、手袋のサイズ、数量、希望納期などの要件を提示します

00:05:31.140 --> 00:05:33.620
各ベンダーは価格と取引条件を変身できます

00:05:33.620 --> 00:05:36.460
あるベンダーは価格は安いものの納品まで3週間かかるかもしれません

00:05:36.460 --> 00:05:39.320
別のベンダーは少し高いですが次の火曜日には全て供給できるかもしれません

00:05:39.320 --> 00:05:41.600
バイヤーは選択する前にそれらの回答を比較できます

00:05:41.600 --> 00:05:43.900
価格は重要ですがそれだけが全てではありません

00:05:43.900 --> 00:05:49.320
納期、製品の詳細、割引、そして要望を満たすベンダー自身の能力が選択の決め手となります

00:05:49.320 --> 00:05:54.380
システムは入札情報を電子メールのやり取りに埋もれさせることなく要望に紐付けて管理します

00:05:54.380 --> 00:05:59.240
バイヤーがベンダーを選択する前にダイナミクス365はベンダー記録も保持します

00:05:59.240 --> 00:06:06.420
ベンダー記録にはベンダー名やビジネス関係に必要な情報など購買に必要な会社情報が含まれています

00:06:06.420 --> 00:06:12.860
ベンダーカタログはベンダーが供給する製品を示しベンダーがカタログを公開することで情報を最新に保てます

00:06:12.860 --> 00:06:16.600
より厳格な管理のために製品には承認済みベンダーリストを持たせることができます

00:06:16.600 --> 00:06:20.360
これによりバイヤーはその製品に対して会社が承認したベンダーを確認できます

00:06:20.360 --> 00:06:24.740
これは選択の指針となり会社が意図していないサプライヤーが選ばれることを防ぎます

00:06:24.740 --> 00:06:28.540
一部のベンダーとの関係ではあらかじめ交渉済みの条件が適用されることもあります

00:06:28.540 --> 00:06:32.100
購買契約は企業と仕入れ先との間の長期的な取引を記録するものです

00:06:32.100 --> 00:06:36.120
企業はある一定期間に一定の数量を購入あるいは一定の金額を支出することに合意し

00:06:36.120 --> 00:06:38.000
仕入れ先はその条件に従うことに同意します

00:06:38.000 --> 00:06:42.440
取引契約は特定の期間中に適用される仕入れ先の価格や割引を記録します

00:06:42.440 --> 00:06:46.460
例えば安全装備の仕入れ先が今後6ヶ月間グローブを値下げすることに合意した場合

00:06:46.460 --> 00:06:49.020
ダイナミクス365はその取り決めを保存できるため

00:06:49.020 --> 00:06:51.440
購入担当者が個別に覚えておく必要はありません

00:06:51.440 --> 00:06:55.560
リベート契約では企業が一定の購入額や購入数量に達した後に

00:06:55.560 --> 00:06:57.880
仕入れ先から返金を受けるケースも追跡可能です

00:06:57.880 --> 00:06:59.580
この時点で企業は何が必要か

00:06:59.580 --> 00:07:02.680
誰から調達できるかどのような条件が適用されるかを把握できています

00:07:02.680 --> 00:07:03.920
調査は完了しましたが

00:07:03.920 --> 00:07:06.400
仕入れ先には依然として正式な発注が必要です

00:07:06.400 --> 00:07:09.820
3つ目は購買発注で企業が約束を書面で提示します

00:07:09.820 --> 00:07:12.560
購入担当者は安全装備の仕入れ先を選定しました

00:07:12.560 --> 00:07:15.820
次に企業には購買発注通常ポーと呼ばれますが必要です

00:07:15.820 --> 00:07:18.620
購買発注とは企業が何をどれだけ購入するつもりかを

00:07:18.620 --> 00:07:20.360
仕入れ先に正確に伝える正式な文書です

00:07:20.360 --> 00:07:24.400
そこには仕入れ先名品目やサービス数量合意した価格

00:07:24.400 --> 00:07:26.700
そして納品日や支払い条件が記載されます

00:07:26.700 --> 00:07:28.880
倉庫向けであればポーにはヘルメット20個

00:07:28.880 --> 00:07:29.780
グローブ10箱

00:07:29.780 --> 00:07:32.060
来週火曜日の納品日が記載されるかもしれません

00:07:32.060 --> 00:07:35.940
これにより購入の決定が双方が作業を進めるための明確な記録へと変わります

00:07:35.940 --> 00:07:38.720
どのタイプのグローブを注文したか何個必要か

00:07:38.720 --> 00:07:41.900
あるいはどの価格で合意したかを推測する必要は誰にもありません

00:07:41.900 --> 00:07:44.240
購買発注はいくつかの方法で開始できます

00:07:44.240 --> 00:07:47.360
最も多いのは承認済みの購買依頼に基づくケースです

00:07:47.360 --> 00:07:49.180
倉庫マネージャーが安全装備を依頼し

00:07:49.180 --> 00:07:50.980
適切な担当者がそれを承認し

00:07:50.980 --> 00:07:52.500
購買部門が法を作成します

00:07:52.500 --> 00:07:54.940
また購買契約から作成されることもあります

00:07:54.940 --> 00:07:57.840
企業が安全装備の仕入れ先と長期契約を既に締結している場合

00:07:57.840 --> 00:08:00.100
購入担当者は詳細を1から入力する代わりに

00:08:00.100 --> 00:08:01.980
その契約に基づいたリリースオーダーを作成できます

00:08:01.980 --> 00:08:04.340
需要に応じて注文が作成される場合もあります

00:08:04.340 --> 00:08:07.740
企業は将来の生産需要を見越して資材の購入を計画することがあり

00:08:07.740 --> 00:08:11.120
ダイナミクス365はその需要から計画購買発注を作成できます

00:08:11.120 --> 00:08:12.960
企業が計画注文をリリースすると

00:08:12.960 --> 00:08:14.920
それが正式な購買発注となります

00:08:14.920 --> 00:08:16.740
他にも直接購入があります

00:08:16.740 --> 00:08:19.720
前述の依頼や契約計画された需要がない場合でも

00:08:19.720 --> 00:08:21.940
購入担当者が手動デポを作成できます

00:08:21.940 --> 00:08:24.180
これは購入担当者が企業に必要なものと

00:08:24.180 --> 00:08:26.420
供給元の仕入れ先を既に把握している場合に起こります

00:08:26.420 --> 00:08:28.980
開始点は異なっても行き着く先は同じです

00:08:28.980 --> 00:08:32.540
購買発注が進む前に企業は承認を必須とすることができます

00:08:32.540 --> 00:08:34.440
購入担当者が注文書を作成しますが

00:08:34.440 --> 00:08:36.160
社内の承認金額ルールに基づき

00:08:36.160 --> 00:08:38.600
ベンダーに送る前に内部承認が必要となる場合があります

00:08:38.600 --> 00:08:40.840
これにより2つの意思決定が分かれます

00:08:40.840 --> 00:08:42.760
まず会社が自社の支出を承認し

00:08:42.760 --> 00:08:45.080
次にベンダーと注文を確認することで

00:08:45.080 --> 00:08:46.760
双方の合意事項を明確にします

00:08:46.760 --> 00:08:50.160
確認済みの注文書法は単なる社内メモ以上の意味を持ちます

00:08:50.160 --> 00:08:52.040
これは注文がベンダーに到達し

00:08:52.040 --> 00:08:54.620
購入に関する合意が成立したことを記録するものです

00:08:54.620 --> 00:08:56.500
ダイナミクス365を使えば

00:08:56.500 --> 00:08:58.520
慣れ親しんだベンダーに発注するたびに

00:08:58.520 --> 00:09:00.580
同じ情報を入力し直す手間も省けます

00:09:00.580 --> 00:09:01.580
ベンダーレコードには

00:09:01.580 --> 00:09:04.440
配送情報や支払い条件などの一般的な設定が

00:09:04.440 --> 00:09:05.580
あらかじめ入力されています

00:09:05.580 --> 00:09:07.540
購入担当者は注文内容を確認し

00:09:07.540 --> 00:09:09.360
必要に応じて詳細を変更できますが

00:09:09.360 --> 00:09:11.440
基本的な情報は正しい状態で開始されます

00:09:11.440 --> 00:09:12.760
これにより入力の手間が減り

00:09:12.760 --> 00:09:14.780
繰り返しの注文に一貫性が保たれます

00:09:14.780 --> 00:09:17.560
配送は常に1日1箱で完了するとは限りません

00:09:17.560 --> 00:09:19.160
例えば手袋は全て揃っているが

00:09:19.160 --> 00:09:21.260
ヘルメットは半分しか準備できていない場合を想像してください

00:09:21.260 --> 00:09:22.580
配送スケジュール機能を使えば

00:09:22.580 --> 00:09:23.940
1つの注文書を分割し

00:09:23.940 --> 00:09:25.880
異なる日付の配送予定を立てることができます

00:09:25.880 --> 00:09:28.580
注文書にはヘルメット10個が来週火曜日に到着し

00:09:28.580 --> 00:09:30.320
残りの10個が1週間後に届き

00:09:30.320 --> 00:09:32.160
手袋は最初の便で届くよう記載できます

00:09:32.160 --> 00:09:34.180
1つの注文として紐付けられたまま

00:09:34.180 --> 00:09:36.540
実際の配送計画を反映させることが可能です

00:09:36.540 --> 00:09:39.140
購入品が自社に一度も届かないケースもあります

00:09:39.140 --> 00:09:41.120
直送とはベンダーが製品を直接

00:09:41.120 --> 00:09:44.640
企業の顧客IoTMSSの顧客へ発送することを意味します

00:09:44.640 --> 00:09:46.860
例えば専門的な商品を販売しているが

00:09:46.860 --> 00:09:48.900
自社の倉庫に在庫を持たないビジネスが挙げられます

00:09:48.900 --> 00:09:50.820
この場合顧客向けの販売注文と

00:09:50.820 --> 00:09:53.280
それに関連するベンダーへの購入注文を作成できます

00:09:53.280 --> 00:09:55.500
ベンダーが顧客へ直接発送する間

00:09:55.500 --> 00:09:57.860
ダイナミクス365が裏側で関連する

00:09:57.860 --> 00:09:59.860
販売と購買のプロセスを連携させます

00:09:59.860 --> 00:10:02.660
これにより自社倉庫への不要な立ち寄りを回避し

00:10:02.660 --> 00:10:05.500
顧客注文とベンダー注文を紐付けることで

00:10:05.500 --> 00:10:08.720
取引の両面から同じ品目を追跡できるようになります

00:10:08.720 --> 00:10:11.680
購入注文には主要品目以外のものを含めることも可能です

00:10:11.680 --> 00:10:14.140
製品によっては関連アイテムが必要になる場合があります

00:10:14.140 --> 00:10:15.460
ヘルメットを注文する際

00:10:15.460 --> 00:10:18.420
交換用のバイザーや取り付けパーツが必要になることもあります

00:10:18.420 --> 00:10:21.920
ダイナミクス365は必須、オプション

00:10:21.920 --> 00:10:24.480
または無料の付随品を提案することができます

00:10:24.480 --> 00:10:27.060
注文作成中にこうした関連ニーズを確認できるため

00:10:27.060 --> 00:10:29.660
メインの荷物が届いてから不足に気づくことを防げます

00:10:29.660 --> 00:10:31.680
さらに書がかり、チャージもあります

00:10:31.680 --> 00:10:35.180
運賃、荷扱い料、その他の関連費用も購入注文に含めることができます

00:10:35.180 --> 00:10:37.160
書がかりは会社の記録方法に応じて

00:10:37.160 --> 00:10:39.980
注文全体または特定の注文業に適用することができます

00:10:39.980 --> 00:10:41.740
配送に多額の料金がかかる場合

00:10:41.740 --> 00:10:43.920
製品単価が安くても総コストは変わるため

00:10:43.920 --> 00:10:45.100
それが重要になります

00:10:45.100 --> 00:10:47.000
注文時に請求を記録することで

00:10:47.000 --> 00:10:48.720
コストを別途管理するのではなく

00:10:48.720 --> 00:10:50.460
購入と紐付けて管理できます

00:10:50.460 --> 00:10:53.760
ベンダーは品目、価格、日付、条件が明確に記載された

00:10:53.760 --> 00:10:54.960
注文書を確認済みとなります

00:10:54.960 --> 00:10:56.640
しかし注文書の確認はあくまで

00:11:01.680 --> 00:11:03.840
X365でその証明が必要となります

00:11:03.840 --> 00:11:07.400
4番目、商品の受取と請求書の称号です

00:11:07.400 --> 00:11:10.520
ヘルメットと手袋を積んだトラックが倉庫に到着しました

00:11:10.520 --> 00:11:12.080
注文を完了とする前に

00:11:12.080 --> 00:11:15.260
倉庫チームは実際に何が届いたかを確認する必要があります

00:11:15.260 --> 00:11:16.720
彼らは到着を登録し

00:11:16.720 --> 00:11:18.520
出荷品と注文書を称号し

00:11:18.520 --> 00:11:20.660
その注文に対して製品受領を転記します

00:11:20.660 --> 00:11:21.720
製品受領とは

00:11:21.720 --> 00:11:24.840
商品が到着したことをシステムに記録するための単純な仕組みです

00:11:24.840 --> 00:11:26.060
ここに10点あります

00:11:26.060 --> 00:11:28.960
注文書にはヘルメット20個と手袋10箱とありますが

00:11:28.960 --> 00:11:31.900
ドライバーはヘルメット10個と手袋10箱すべてを届けました

00:11:31.900 --> 00:11:34.080
倉庫側は到着を予定していた数量ではなく

00:11:34.080 --> 00:11:35.800
実際に受け取った数量を転記します

00:11:35.800 --> 00:11:36.940
残りのヘルメット10個分は

00:11:36.940 --> 00:11:37.860
ベンダーが納品するか

00:11:37.860 --> 00:11:39.000
バイヤーが注文を変更するまで

00:11:39.000 --> 00:11:40.460
注文書き上げで未完了として残ります

00:11:40.460 --> 00:11:42.500
これにより記録の正確性が保たれます

00:11:42.500 --> 00:11:43.900
製品受領が転記されると

00:11:43.900 --> 00:11:45.420
注文書の内容が更新されます

00:11:45.420 --> 00:11:47.960
システムは注文数量と受領数量を分けて管理するため

00:11:47.960 --> 00:11:49.980
バイヤー、倉庫スタッフ、経理部門は

00:11:49.980 --> 00:11:51.160
互いに連絡を取り合うことなく

00:11:51.160 --> 00:11:52.520
注文状況を確認できます

00:11:52.520 --> 00:11:53.520
在庫品の場合

00:11:53.520 --> 00:11:55.820
受領処理によって在庫状況も更新されます

00:11:55.820 --> 00:11:57.900
手袋は利用可能な在庫として反映され

00:11:57.900 --> 00:12:00.040
倉庫チームがすぐに使用できるようになります

00:12:00.040 --> 00:12:02.260
金目が特定のプロジェクトや固定資産

00:12:02.260 --> 00:12:04.020
直送に関連する場合は

00:12:04.020 --> 00:12:06.640
ダイナミクス365でその用途に応じて

00:12:06.640 --> 00:12:07.660
購入を記録できます

00:12:07.660 --> 00:12:10.920
企業は手袋を購入したという事実以上の情報を把握できます

00:12:10.920 --> 00:12:13.120
手袋が到着したか何個届いたか

00:12:13.120 --> 00:12:14.860
どこに保管すべきかまでわかるのです

00:12:14.860 --> 00:12:17.900
ただし全ての購入品が搬入口に届くわけではありません

00:12:17.900 --> 00:12:19.840
例えば安全トレーナーを1日雇ったり

00:12:19.840 --> 00:12:21.440
ソフトウェアのアクセス券を購入したり

00:12:21.440 --> 00:12:23.360
外部の修理サービスを依頼したりする場合などです

00:12:23.360 --> 00:12:24.440
これらには現物がなく

00:12:24.440 --> 00:12:25.680
数えるパレットもなく

00:12:25.680 --> 00:12:27.320
倉庫での到着登録もありません

00:12:27.320 --> 00:12:29.800
サービスやその他の非物理的な購入については

00:12:29.800 --> 00:12:31.480
よりシンプルな手順が利用できます

00:12:31.480 --> 00:12:32.840
購入の設定に応じて

00:12:32.840 --> 00:12:34.460
倉庫でのステップを省略して

00:12:34.460 --> 00:12:36.720
注文書き上げで直接受領登録を行うか

00:12:36.720 --> 00:12:39.000
そのままベンダー請求書に進むことができます

00:12:39.000 --> 00:12:40.860
それでも問いは同じです

00:12:40.860 --> 00:12:43.560
会社は合意した通りのものを受け取ったでしょうか

00:12:43.560 --> 00:12:44.760
研修サービスであれば

00:12:44.760 --> 00:12:46.980
研修が実施されたかどうかが答えになります

00:12:46.980 --> 00:12:47.920
修理であれば

00:12:47.920 --> 00:12:49.840
誰かが作業完了を確認することになります

00:12:49.840 --> 00:12:51.680
企業が何かを受け取ったことを証明するために

00:12:51.680 --> 00:12:53.280
記録は箱やバーコードを必要としません

00:12:53.280 --> 00:12:55.400
やがてベンダーからの請求書が届きます

00:12:55.400 --> 00:12:57.680
請求書は買いかけ金管理に入力されます

00:12:57.680 --> 00:12:59.480
これはダイナミクス365の一部で

00:12:59.480 --> 00:13:01.400
企業がベンダーに支払うべき金額を記録し

00:13:01.400 --> 00:13:02.620
支払いを準備する機能です

00:13:02.620 --> 00:13:04.380
請求書は発注書と紐付けられるため

00:13:04.380 --> 00:13:05.560
買いかけ金管理において

00:13:05.560 --> 00:13:07.880
履歴のない独立した請求書として扱われることはありません

00:13:07.880 --> 00:13:09.400
ここで単純なチェックを行うことが

00:13:09.400 --> 00:13:10.940
多くのトラブルを防ぐことにつながります

00:13:10.940 --> 00:13:12.280
ダイナミクス365は

00:13:12.280 --> 00:13:13.200
会社が発注したもの

00:13:13.200 --> 00:13:14.100
会社が受け取ったもの

00:13:14.100 --> 00:13:15.780
ベンダーが請求したものの3つを称号します

00:13:15.780 --> 00:13:17.500
これは一般的にマッチングと呼ばれます

00:13:17.500 --> 00:13:18.100
簡単に言えば

00:13:18.100 --> 00:13:20.140
請求内容が取引と一致しているかを確認するのです

00:13:20.140 --> 00:13:20.960
例えば発注書には

00:13:20.960 --> 00:13:23.060
合意した価格でヘルメットが20個と記載されているかもしれません

00:13:23.060 --> 00:13:23.900
製品受領書には

00:13:23.900 --> 00:13:26.180
これまでに届いたヘルメットは10個のみと記録されているかもしれません

00:13:26.180 --> 00:13:28.420
もしベンダーが20個分の請求書を送ってきた場合

00:13:28.420 --> 00:13:30.720
システムは支払いを行う前にその差分を提示できます

00:13:30.720 --> 00:13:32.860
これが3社間称号の自動化です

00:13:32.860 --> 00:13:34.120
その3つの記録とは

00:13:34.120 --> 00:13:36.760
発注書、製品受領書、そして請求書です

00:13:36.760 --> 00:13:37.740
これらが一致すれば

00:13:37.740 --> 00:13:40.260
買いかけ金担当者はスムーズに業務を進められます

00:13:40.260 --> 00:13:41.380
価格が異なる場合や

00:13:41.380 --> 00:13:43.600
請求数量が受領数量を上回っている場合

00:13:43.600 --> 00:13:45.360
あるいは注文していない項目がある場合

00:13:45.360 --> 00:13:46.780
会社は処理を止めて調査できます

00:13:46.780 --> 00:13:49.080
ベンダーが請求書を早く送っただけかもしれません

00:13:49.080 --> 00:13:50.660
あるいは別途計上された運賃を

00:13:50.660 --> 00:13:52.220
バイヤーが確認する必要があるのかもしれません

00:13:52.220 --> 00:13:54.740
あるいは単にベンダーが数量を打ち間違えただけかもしれません

00:13:54.740 --> 00:13:57.140
重要なのは悪意を疑うことではありません

00:13:57.140 --> 00:13:59.160
銀行から支払いが完了した後ではなく

00:13:59.160 --> 00:14:01.280
まだ明確に問い合わせができる段階で

00:14:01.280 --> 00:14:03.040
差異を捉えるために自動化されているのです

00:14:03.040 --> 00:14:04.380
それぞれの請求書は

00:14:04.380 --> 00:14:07.360
会社の財務記録のどこかに計上される必要があります

00:14:07.360 --> 00:14:09.860
それが会計配分の自動化という作業です

00:14:09.860 --> 00:14:11.900
会計配分はダイナミクス365に対して

00:14:11.900 --> 00:14:13.160
その費用をどう記録するかを指示します

00:14:13.160 --> 00:14:14.320
安全手袋の費用は

00:14:14.320 --> 00:14:16.040
倉庫運営費に分類されるかもしれません

00:14:16.040 --> 00:14:17.100
新しいフォークリフトは

00:14:17.100 --> 00:14:18.980
固定資産環状に属する可能性があります

00:14:18.980 --> 00:14:20.420
プロジェクトのための購入であれば

00:14:20.420 --> 00:14:21.240
そのプロジェクトに対して

00:14:21.240 --> 00:14:22.520
費用を記録する必要があるでしょう

00:14:22.520 --> 00:14:25.520
1枚の請求書を複数の場所に分割することも可能です

00:14:25.520 --> 00:14:27.300
例えば2つの倉庫チームで

00:14:27.300 --> 00:14:28.940
手袋の注文を共有する場合

00:14:28.940 --> 00:14:31.120
両部門で費用を分割して計上できます

00:14:31.120 --> 00:14:32.400
そうすれば財務部門は

00:14:32.400 --> 00:14:35.000
曖昧な請求書の説明から後で再構築することなく

00:14:35.000 --> 00:14:36.700
資金の使途を正確に把握できます

00:14:36.700 --> 00:14:37.860
請求書が称号され

00:14:37.860 --> 00:14:39.280
必要なチェックが完了すると

00:14:39.280 --> 00:14:40.820
承認プロセスに進むことができます

00:14:40.820 --> 00:14:41.860
請求書を転記すると

00:14:41.860 --> 00:14:43.440
企業がベンダーに対して支払うべき金額が

00:14:43.440 --> 00:14:44.380
買いかけ金として記録されます

00:14:44.380 --> 00:14:45.560
こうして請求は支払い義務

00:14:45.560 --> 00:14:46.440
買いかけ金となります

00:14:46.440 --> 00:14:48.840
支払い条件によって支払い期日が決定されます

00:14:48.840 --> 00:14:49.900
買いかけ金担当者は

00:14:49.900 --> 00:14:51.800
期日通りに請求書の支払い準備を行い

00:14:51.800 --> 00:14:52.920
支払いが処理されると

00:14:52.920 --> 00:14:55.180
ダイナミクス365がその請求書に対する

00:14:55.180 --> 00:14:56.300
ベンダー残高を消し込みます

00:14:56.300 --> 00:14:58.600
発注は今や配送予定からコストの記録

00:14:58.600 --> 00:15:00.380
そして支払い完了へと移行しました

00:15:00.380 --> 00:15:01.660
しかしこの一連の流れは

00:15:01.660 --> 00:15:03.480
単に1枚の請求書を支払う以上の意味を持っています

00:15:03.480 --> 00:15:05.320
その購入に関連するあらゆる決定と

00:15:05.320 --> 00:15:07.140
引き継ぎの有用な記録を会社に提供します

00:15:07.140 --> 00:15:07.840
5つ目は

00:15:07.840 --> 00:15:08.920
可視性の管理と

00:15:08.920 --> 00:15:10.640
より良いベンダー選定の判断です

00:15:10.640 --> 00:15:12.520
一元化された購入記録により

00:15:12.520 --> 00:15:15.080
問題が財務部門に達する前に購入を制御できます

00:15:15.080 --> 00:15:17.320
購入ポリシーが基本ルールを定めます

00:15:17.320 --> 00:15:18.940
従業員が何を要求できるか

00:15:18.940 --> 00:15:20.320
どのベンダーを利用できるか

00:15:20.320 --> 00:15:21.860
そして会社のお金を使う前に

00:15:21.860 --> 00:15:23.200
いつ承認が必要かを導きます

00:15:23.200 --> 00:15:25.500
安全装備の要求について考えてみましょう

00:15:25.500 --> 00:15:28.200
会社は倉庫スタッフに承認済みの安全製品を選択させ

00:15:28.200 --> 00:15:29.520
新しいベンダーの選択は

00:15:29.520 --> 00:15:31.060
購買チームのみに限定するかもしれません

00:15:31.060 --> 00:15:33.420
小さな交換注文なら承認は1つで済みますが

00:15:33.420 --> 00:15:35.240
新しいチーム向けの大きな注文なら

00:15:35.240 --> 00:15:36.580
予算所有者と購買マネージャーの

00:15:36.580 --> 00:15:37.980
承認が必要になる場合があります

00:15:37.980 --> 00:15:40.160
ルールはプロセスの中に組み込まれています

00:15:40.160 --> 00:15:42.260
従業員はポリシー文書を検索したり

00:15:42.260 --> 00:15:43.880
誰が承認すべきか推測したり

00:15:43.880 --> 00:15:45.020
誰かから返信があるまで

00:15:45.020 --> 00:15:46.560
メールを転送したりする必要はありません

00:15:46.560 --> 00:15:48.260
ダイナミクス365は

00:15:48.260 --> 00:15:50.280
部門、金額、購入タイプ

00:15:50.280 --> 00:15:52.100
または付随するポリシーに基づいて

00:15:52.100 --> 00:15:53.160
要求をルーティングできます

00:15:53.160 --> 00:15:55.200
そのルートはワークフローと呼ばれます

00:15:55.200 --> 00:15:56.080
ワークフローは

00:15:56.080 --> 00:15:58.020
要求、注文書、請求書に

00:15:58.020 --> 00:16:00.520
次から次へと進む明確な道筋を与えます

00:16:00.520 --> 00:16:02.260
各担当者は承認、拒否

00:16:02.260 --> 00:16:04.340
または変更のための差し戻しが可能で

00:16:04.340 --> 00:16:06.080
システムはその操作を記録します

00:16:06.080 --> 00:16:07.320
長いメールチェーンの中で

00:16:07.320 --> 00:16:08.520
承認が完了したかどうかを

00:16:08.520 --> 00:16:09.660
悩む必要はもうありません

00:16:09.660 --> 00:16:11.760
これは誰かが不在の時にも役立ちます

00:16:11.760 --> 00:16:13.160
業務がその人のアウトルックの

00:16:13.160 --> 00:16:14.200
受信トレイに消えてしまい

00:16:14.200 --> 00:16:15.240
どこで止まっているのか

00:16:15.240 --> 00:16:16.320
わからなくなることはありません

00:16:16.320 --> 00:16:18.140
会社は現在のステップを確認し

00:16:18.140 --> 00:16:19.200
それに対処できます

00:16:19.200 --> 00:16:20.800
ベンダーポータルを利用すれば

00:16:20.800 --> 00:16:22.460
ベンダーもプロセスに参加できます

00:16:22.460 --> 00:16:23.540
ベンダーポータルは

00:16:23.540 --> 00:16:25.560
ベンダーが共有された見積もり依頼や

00:16:25.560 --> 00:16:27.480
注文書を確認できる場所を提供します

00:16:27.480 --> 00:16:29.520
ベンダーは見積もり依頼に応答でき

00:16:29.520 --> 00:16:31.460
会社が確認依頼を送れば

00:16:31.460 --> 00:16:32.980
注文を直接確定できます

00:16:32.980 --> 00:16:35.260
これにより双方が同じ文書に基づいて

00:16:35.260 --> 00:16:36.340
作業できるようになります

00:16:36.340 --> 00:16:38.540
バイヤーがPDFを送信して返信を待ち

00:16:38.540 --> 00:16:40.720
その内容をシステムに入力し直す代わりに

00:16:40.720 --> 00:16:42.520
ベンダーが接続されたプロセスを通じて

00:16:42.520 --> 00:16:43.440
詳細を確認できます

00:16:43.440 --> 00:16:45.680
バイヤーは手作業で記録を作り直すことなく

00:16:45.680 --> 00:16:46.940
回答を確認できます

00:16:46.940 --> 00:16:48.860
購入がシステムを通じて行われると

00:16:48.860 --> 00:16:50.880
新しいスプレッドシートを作成しなくても

00:16:50.880 --> 00:16:52.260
有用な情報が収集されます

00:16:52.260 --> 00:16:54.840
支出分析はお金はどこに使われているのか

00:16:54.840 --> 00:16:56.580
というシンプルな問いに答えます

00:16:56.580 --> 00:16:59.720
購買マネージャーはベンダー、製品、調達カテゴリー

00:16:59.720 --> 00:17:01.420
または部門別に支出を確認できます

00:17:01.420 --> 00:17:03.860
会社は一つのサプライヤーから手袋を買っていると思っていても

00:17:03.860 --> 00:17:05.680
記録を見ると複数のチームが異なるベンダーから

00:17:05.680 --> 00:17:07.180
似たような手袋を買っていることがわかります

00:17:07.180 --> 00:17:08.900
あるいはある部門が予想以上に

00:17:08.900 --> 00:17:10.440
外部の修理費を使っているかもしれません

00:17:10.440 --> 00:17:12.780
それらの詳細情報は会社が次の購入の前に

00:17:12.780 --> 00:17:14.500
より適切な質問をするための根拠となります

00:17:14.500 --> 00:17:15.840
ベンダーパフォーマンス分析は

00:17:15.840 --> 00:17:17.860
同じ状況をベンダーの視点から見るものです

00:17:17.860 --> 00:17:20.760
購買担当者は将来の発注先を決定する際に

00:17:20.760 --> 00:17:22.280
仕入れと納品の成果を比較できます

00:17:22.280 --> 00:17:23.640
ベンダーの納品が遅れたり

00:17:23.640 --> 00:17:25.120
不完全な注文を出荷したり

00:17:25.120 --> 00:17:27.040
合意した条件を満たせなかったりする場合

00:17:27.040 --> 00:17:29.000
書類上の価格が安くても魅力は薄れます

00:17:29.000 --> 00:17:31.060
企業はベンダーとの関係を見直す際に

00:17:31.060 --> 00:17:32.520
自社の購入記録を活用できます

00:17:32.520 --> 00:17:34.840
次に監査証跡オーディットトレイルがあります

00:17:34.840 --> 00:17:37.560
監査証跡があれば購入の全履歴を追跡できます

00:17:37.560 --> 00:17:38.840
最初の要求から始まり

00:17:38.840 --> 00:17:40.880
承認者を確認し発注書をレビューし

00:17:40.880 --> 00:17:42.880
受領書を称号し請求書を見つけ

00:17:42.880 --> 00:17:44.200
支払いの完了を確認できます

00:17:44.200 --> 00:17:46.180
この記録は財務や監査チームに役立つだけでなく

00:17:46.180 --> 00:17:48.780
一般の社員が日常的な疑問を解決するのにも役立ちます

00:17:48.780 --> 00:17:50.160
なぜこれを購入したのか

00:17:50.160 --> 00:17:51.620
誰がこのベンダーを選んだのか

00:17:51.620 --> 00:17:52.820
商品は到着したか

00:17:52.820 --> 00:17:54.360
請求書はすでに支払われたか

00:17:54.360 --> 00:17:56.440
その答えは購入記録の中にあります

00:17:56.440 --> 00:17:58.420
最初のオフィスビルに戻ってみましょう

00:17:58.420 --> 00:18:00.920
購買デスク、受取ドック、財務デスクには

00:18:00.920 --> 00:18:02.380
それぞれ異なる仕事がありますが

00:18:02.380 --> 00:18:04.560
バラバラの書類を部屋間でやり取りするのではなく

00:18:04.560 --> 00:18:07.380
全員が同じ購入プロセスの各部分を共有しています

00:18:07.380 --> 00:18:10.880
倉庫マネージャーが作成したヘルメットと手袋のTMS要求には

00:18:10.880 --> 00:18:12.740
今や完全な履歴が残っています

00:18:12.740 --> 00:18:15.080
その要求は社内規定に従ったものでした

00:18:15.080 --> 00:18:16.840
適切な担当者が承認しました

00:18:16.840 --> 00:18:18.540
ベンダーが備品を供給しました

00:18:18.540 --> 00:18:20.440
倉庫スタッフが納品を記録しました

00:18:20.440 --> 00:18:23.400
買いかけ金担当者が請求書と称号し支払いを完了させました

00:18:23.400 --> 00:18:26.540
シンプルな区別がこれらの構成要素を明確に保ちます

00:18:26.540 --> 00:18:28.920
ソーシングは購入先の選定を支援し

00:18:28.920 --> 00:18:32.700
調達、プロキュアメントは購入決定後のプロセスを管理します

00:18:32.700 --> 00:18:33.640
結論です

00:18:33.640 --> 00:18:36.320
リードから支払いまで全てが一つの記録で繋がります

00:18:36.320 --> 00:18:37.700
全体像はこうです

00:18:37.700 --> 00:18:40.200
調達とソーシングは散在していた引き継ぎ作業を

00:18:40.200 --> 00:18:42.260
追跡可能な一つの企業プロセスへと変えます

00:18:42.260 --> 00:18:43.900
要求が受信ボックスで消えたり

00:18:43.900 --> 00:18:45.840
承認が誰かの記憶だけに頼ったり

00:18:45.840 --> 00:18:49.020
背後にある決定が不明なまま請求書が届いたりすることはありません

00:18:49.020 --> 00:18:51.240
代わりに企業は購入の全過程をたどる

00:18:51.240 --> 00:18:52.780
繋がった一つの記録を保持します

00:18:52.780 --> 00:18:55.100
それにより必要な時に明確な答えが得られます

00:18:55.100 --> 00:18:56.860
購買担当者は注文を確認できます

00:18:56.860 --> 00:18:58.560
倉庫は入荷予定を把握できます

00:18:58.560 --> 00:19:00.300
財務は会社の負債を把握できます

00:19:00.300 --> 00:19:02.800
そしてマネージャーは支出の行き先を正確に把握できます

00:19:02.800 --> 00:19:06.240
購入には今も人、ベンダー、商品、サービス、そして決定が関わっています

00:19:06.240 --> 00:19:08.840
ダイナミクス365はそれらを取り除くわけではありません

00:19:08.840 --> 00:19:10.400
それらの記録を統合することで

00:19:10.400 --> 00:19:12.800
不確実性や問題を減らした購入が可能になります

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

00:19:14.940 --> 00:19:18.160
ダイナミクス365の調達とソーシングを学び始めた仲間に

00:19:18.160 --> 00:19:19.180
この知識をシェアしてください