職場で新しいノートPCや生産用の原材料あるいは清掃サービスが必要になった時何が起こるでしょうか多くの企業では従来はメールスプレッドシート市の書類を使い何週間も経ってから誰かが請求書を追跡するような状況でしたマイクロソフトのウルジナゲットソンM365FMへようこそミルコピーターズです今日は企業がベンダーから商品やサービスを購入するための一連のプロセスである調達とソーシングについて見ていきますオフィスビルの受付窓口を想像してみてくださいすべての依頼承認発注納品請求支払いが同じ場所を通ります最初の依頼から舞台裏で機能する管理プロセスまで一つの購入事例を追跡します一つ目は調達とソーシングが実際に何をカバーしているかです調達とソーシングは単に物を買うにしては長い名称に聞こえるかもしれません確かに購入に関することですがこの2つの言葉は異なる役割を表していますソーシングとは適切なベンダーを見つけて選定する作業のことです手袋ヘルメット安全標識保護眼鏡が必要な会社を想像してください発注を行う前に誰が適切な製品を許容範囲内の価格で必要な期日までに会社が合意できる条件で供給できるかを決めなければなりませんそれがソーシングです調達は会社が実際の購入プロセスを管理する必要がある段階から始まりますこれには依頼承認発注書納品請求書支払いまでが含まれますこれらを合わせてソーストペープロセスと呼びますこの名前は全体の道のりを表しています企業がニーズを特定しサプライヤーを選び発注を送り商品やサービスを受け取りベンダーから請求書を受け取り経理がベンダーに支払います各ステップは次へと繋がっています当たり前のことのように思えるかもしれませんが多くの企業では今でもこれらのステップを別々の場所で実行しています従業員がメールで依頼を送りマネージャーがチャットメッセージで承認し担当者がスプレッドシートで注文詳細を管理し倉庫が紙の納品書を確認し経理が注文との関連性が不明確な請求書を受け取るといった状況ですそれでも購入は可能ですが経緯がわからなくなってしまいます

マネージャーはお金が会社から出ていった後に初めてコストを知ることになります誰かが誰がこれを承認したのかと尋ねた時その答えを見つけるには受信トレイを長時間検索しなければなりませんダイナミクス365はその追跡記録を一つの接続されたプラットフォームに集約しますダイナミクス365サプライチェーンマネジメントにおける調達ソーシングは企業が商品の移動や在庫状況を管理する基盤であり財務や買いかけ金管理と連携して請求書の記録未払金の追跡支払処理を行いますつまり購買は孤立した業務ではありません倉庫部門は商品の到着を記録し財務部門は購入に関連する請求書を確認でき買いかけ金管理部門は注文内容と到着品そしてベンダーからの請求金額を称号できます各チームは必要な情報のみを参照しますが購入プロセスは一つの繋がった記録として保持されます購買には大きく分けて2つの種類があります直接調達とは企業が製造または販売する製品に直接結びつく商品やサービスのことです家具メーカーが木材ネジ布地を購入するのは直接材料の購入にあたりますこれらの材料がなければ販売する製品を製造できないからです間接調達とはビジネスを運営するために必要なものの販売製品の一部にはならないものを指しますノートPCオフィス家具研修修理清掃ソフトウェアホームアドバイスなどが含まれますどちらも重要ですが多くの場合開始のきっかけが異なります生産需要によって会社に部品が必要であることが判明します従業員が新しいモニターをリクエストすることもあります施設管理者が修理サービスを必要とすることもありますダイナミクス365はこれらすべての異なるニーズを扱いながら購買経路を明確に保ちますこのエピソードでは一つのシンプルな例を使って説明しましょう倉庫マネージャーがチームに新しい安全装備が必要だと気づいたとしますヘルメットが破損しており保護手袋の在庫も不足していますマネージャーはチームのために十分な装備を必要とし会社は資金を投入する前に明確な記録を必要とします購買はニーズから始まり管理されたすべての購入は誰かが何かを要求することから始まります次は社内のリクエストから適切なベンダーへの発注についてです購買プロセス全体がどのように始まるのかを見ていきましょう倉庫マネージャーが安全装備の必要性に気づくとダイナミクス365内で最初に作成される記録が購買依頼です購買依頼とは社内で何かを購入するための申請ですこれには誰が何をどれくらい必要としているかそして多くの場合どこへ配送すべきかが記載されますこの段階ではベンダーに対して何らかの約束をしているわけではないことに注目してくださいこの区別があることで購買の初期段階を自社の管理下に置くことができます倉庫マネージャーはヘルメット20個と手袋数箱を依頼できますが関係者が承認するまでサプライヤーに注文が送られることはありません一般的な購入の場合リクエストは製品カタログから始まることがありますカタログは会社が承認したショッピング棚のようなものだと考えてください安全手袋といった曖昧な依頼を入力する代わりに従業員は説明、サプライヤー、価格があらかじめ設定された承認済製品を選択できますこれにより時間が短縮されるだけでなく社内規定に合わない勝手な製品の購入を防ぐこともできますすべての要望がカタログに収まるわけではありません一度限りの修理やコンサルタントの研修あるいは物理的な製品として保管されないサービスが必要になる場合もありますそのような場合ダイナミクス365では調達カテゴリを使用できます調達カテゴリは支出の内容に基づいてグループ化します例えば安全用品、建物の修繕、ホームサービス、コンピュータ機器といったカテゴリを利用できます棚に在庫番号がない場合でも申請者は必要なものを説明し適切なカテゴリに分類することができますもっとも送信ボタンを押しただけで要望がそのまま購入に結びつくわけではありません会社は支出限度額、予算チェック、承認ワークフローを設定できます手袋のような奨学の要望は倉庫管理者に送られるかもしれません安全装備のようなより大きな要望には部門の予算責任者や購買チームの承認が必要になることもあります承認ルートは金額、部門、あるいはその支出タイプに関連付けられた購買ルールに基づいて変わりますそのため従業員一人一人が全ての承認ルールを覚える必要はありませんダイナミクス365は要望を正しいルートに送りその履歴はシステム内に保持されますマネージャーが大量の機器を要望しどのベンダーに発注すべきか未定であると仮定します購買部門は見積もり以来通称RF9を作成できますRF9は同じニーズに対して複数のベンダーに入札を求めるものですバイヤーはヘルメットの種類、手袋のサイズ、数量、希望納期などの要件を提示します各ベンダーは価格と取引条件を変身できますあるベンダーは価格は安いものの納品まで3週間かかるかもしれません別のベンダーは少し高いですが次の火曜日には全て供給できるかもしれませんバイヤーは選択する前にそれらの回答を比較できます価格は重要ですがそれだけが全てではありません納期、製品の詳細、割引、そして要望を満たすベンダー自身の能力が選択の決め手となりますシステムは入札情報を電子メールのやり取りに埋もれさせることなく要望に紐付けて管理しますバイヤーがベンダーを選択する前にダイナミクス365はベンダー記録も保持しますベンダー記録にはベンダー名やビジネス関係に必要な情報など購買に必要な会社情報が含まれていますベンダーカタログはベンダーが供給する製品を示しベンダーがカタログを公開することで情報を最新に保てますより厳格な管理のために製品には承認済みベンダーリストを持たせることができますこれによりバイヤーはその製品に対して会社が承認したベンダーを確認できますこれは選択の指針となり会社が意図していないサプライヤーが選ばれることを防ぎます一部のベンダーとの関係ではあらかじめ交渉済みの条件が適用されることもあります購買契約は企業と仕入れ先との間の長期的な取引を記録するものです企業はある一定期間に一定の数量を購入あるいは一定の金額を支出することに合意し仕入れ先はその条件に従うことに同意します取引契約は特定の期間中に適用される仕入れ先の価格や割引を記録します例えば安全装備の仕入れ先が今後6ヶ月間グローブを値下げすることに合意した場合ダイナミクス365はその取り決めを保存できるため購入担当者が個別に覚えておく必要はありませんリベート契約では企業が一定の購入額や購入数量に達した後に仕入れ先から返金を受けるケースも追跡可能ですこの時点で企業は何が必要か誰から調達できるかどのような条件が適用されるかを把握できています調査は完了しましたが仕入れ先には依然として正式な発注が必要です3つ目は購買発注で企業が約束を書面で提示します購入担当者は安全装備の仕入れ先を選定しました次に企業には購買発注通常ポーと呼ばれますが必要です購買発注とは企業が何をどれだけ購入するつもりかを仕入れ先に正確に伝える正式な文書ですそこには仕入れ先名品目やサービス数量合意した価格そして納品日や支払い条件が記載されます倉庫向けであればポーにはヘルメット20個グローブ10箱来週火曜日の納品日が記載されるかもしれませんこれにより購入の決定が双方が作業を進めるための明確な記録へと変わりますどのタイプのグローブを注文したか何個必要かあるいはどの価格で合意したかを推測する必要は誰にもありません購買発注はいくつかの方法で開始できます最も多いのは承認済みの購買依頼に基づくケースです倉庫マネージャーが安全装備を依頼し適切な担当者がそれを承認し購買部門が法を作成しますまた購買契約から作成されることもあります企業が安全装備の仕入れ先と長期契約を既に締結している場合購入担当者は詳細を1から入力する代わりにその契約に基づいたリリースオーダーを作成できます需要に応じて注文が作成される場合もあります企業は将来の生産需要を見越して資材の購入を計画することがありダイナミクス365はその需要から計画購買発注を作成できます企業が計画注文をリリースするとそれが正式な購買発注となります他にも直接購入があります前述の依頼や契約計画された需要がない場合でも購入担当者が手動デポを作成できますこれは購入担当者が企業に必要なものと供給元の仕入れ先を既に把握している場合に起こります開始点は異なっても行き着く先は同じです購買発注が進む前に企業は承認を必須とすることができます購入担当者が注文書を作成しますが社内の承認金額ルールに基づきベンダーに送る前に内部承認が必要となる場合がありますこれにより2つの意思決定が分かれますまず会社が自社の支出を承認し次にベンダーと注文を確認することで双方の合意事項を明確にします確認済みの注文書法は単なる社内メモ以上の意味を持ちますこれは注文がベンダーに到達し購入に関する合意が成立したことを記録するものですダイナミクス365を使えば慣れ親しんだベンダーに発注するたびに同じ情報を入力し直す手間も省けますベンダーレコードには配送情報や支払い条件などの一般的な設定があらかじめ入力されています購入担当者は注文内容を確認し必要に応じて詳細を変更できますが基本的な情報は正しい状態で開始されますこれにより入力の手間が減り繰り返しの注文に一貫性が保たれます配送は常に1日1箱で完了するとは限りません例えば手袋は全て揃っているがヘルメットは半分しか準備できていない場合を想像してください配送スケジュール機能を使えば1つの注文書を分割し異なる日付の配送予定を立てることができます注文書にはヘルメット10個が来週火曜日に到着し残りの10個が1週間後に届き手袋は最初の便で届くよう記載できます1つの注文として紐付けられたまま実際の配送計画を反映させることが可能です購入品が自社に一度も届かないケースもあります直送とはベンダーが製品を直接企業の顧客IoTMSSの顧客へ発送することを意味します例えば専門的な商品を販売しているが自社の倉庫に在庫を持たないビジネスが挙げられますこの場合顧客向けの販売注文とそれに関連するベンダーへの購入注文を作成できますベンダーが顧客へ直接発送する間ダイナミクス365が裏側で関連する販売と購買のプロセスを連携させますこれにより自社倉庫への不要な立ち寄りを回避し顧客注文とベンダー注文を紐付けることで取引の両面から同じ品目を追跡できるようになります購入注文には主要品目以外のものを含めることも可能です製品によっては関連アイテムが必要になる場合がありますヘルメットを注文する際交換用のバイザーや取り付けパーツが必要になることもありますダイナミクス365は必須、オプションまたは無料の付随品を提案することができます注文作成中にこうした関連ニーズを確認できるためメインの荷物が届いてから不足に気づくことを防げますさらに書がかり、チャージもあります運賃、荷扱い料、その他の関連費用も購入注文に含めることができます書がかりは会社の記録方法に応じて注文全体または特定の注文業に適用することができます配送に多額の料金がかかる場合製品単価が安くても総コストは変わるためそれが重要になります注文時に請求を記録することでコストを別途管理するのではなく購入と紐付けて管理できますベンダーは品目、価格、日付、条件が明確に記載された注文書を確認済みとなりますしかし注文書の確認はあくまで

X365でその証明が必要となります4番目、商品の受取と請求書の称号ですヘルメットと手袋を積んだトラックが倉庫に到着しました注文を完了とする前に倉庫チームは実際に何が届いたかを確認する必要があります彼らは到着を登録し出荷品と注文書を称号しその注文に対して製品受領を転記します製品受領とは商品が到着したことをシステムに記録するための単純な仕組みですここに10点あります注文書にはヘルメット20個と手袋10箱とありますがドライバーはヘルメット10個と手袋10箱すべてを届けました倉庫側は到着を予定していた数量ではなく実際に受け取った数量を転記します残りのヘルメット10個分はベンダーが納品するかバイヤーが注文を変更するまで注文書き上げで未完了として残りますこれにより記録の正確性が保たれます製品受領が転記されると注文書の内容が更新されますシステムは注文数量と受領数量を分けて管理するためバイヤー、倉庫スタッフ、経理部門は互いに連絡を取り合うことなく注文状況を確認できます在庫品の場合受領処理によって在庫状況も更新されます手袋は利用可能な在庫として反映され倉庫チームがすぐに使用できるようになります金目が特定のプロジェクトや固定資産直送に関連する場合はダイナミクス365でその用途に応じて購入を記録できます企業は手袋を購入したという事実以上の情報を把握できます手袋が到着したか何個届いたかどこに保管すべきかまでわかるのですただし全ての購入品が搬入口に届くわけではありません例えば安全トレーナーを1日雇ったりソフトウェアのアクセス券を購入したり外部の修理サービスを依頼したりする場合などですこれらには現物がなく数えるパレットもなく倉庫での到着登録もありませんサービスやその他の非物理的な購入についてはよりシンプルな手順が利用できます購入の設定に応じて倉庫でのステップを省略して注文書き上げで直接受領登録を行うかそのままベンダー請求書に進むことができますそれでも問いは同じです会社は合意した通りのものを受け取ったでしょうか研修サービスであれば研修が実施されたかどうかが答えになります修理であれば誰かが作業完了を確認することになります企業が何かを受け取ったことを証明するために記録は箱やバーコードを必要としませんやがてベンダーからの請求書が届きます請求書は買いかけ金管理に入力されますこれはダイナミクス365の一部で企業がベンダーに支払うべき金額を記録し支払いを準備する機能です請求書は発注書と紐付けられるため買いかけ金管理において履歴のない独立した請求書として扱われることはありませんここで単純なチェックを行うことが多くのトラブルを防ぐことにつながりますダイナミクス365は会社が発注したもの会社が受け取ったものベンダーが請求したものの3つを称号しますこれは一般的にマッチングと呼ばれます簡単に言えば請求内容が取引と一致しているかを確認するのです例えば発注書には合意した価格でヘルメットが20個と記載されているかもしれません製品受領書にはこれまでに届いたヘルメットは10個のみと記録されているかもしれませんもしベンダーが20個分の請求書を送ってきた場合システムは支払いを行う前にその差分を提示できますこれが3社間称号の自動化ですその3つの記録とは発注書、製品受領書、そして請求書ですこれらが一致すれば買いかけ金担当者はスムーズに業務を進められます価格が異なる場合や請求数量が受領数量を上回っている場合あるいは注文していない項目がある場合会社は処理を止めて調査できますベンダーが請求書を早く送っただけかもしれませんあるいは別途計上された運賃をバイヤーが確認する必要があるのかもしれませんあるいは単にベンダーが数量を打ち間違えただけかもしれません重要なのは悪意を疑うことではありません銀行から支払いが完了した後ではなくまだ明確に問い合わせができる段階で差異を捉えるために自動化されているのですそれぞれの請求書は会社の財務記録のどこかに計上される必要がありますそれが会計配分の自動化という作業です会計配分はダイナミクス365に対してその費用をどう記録するかを指示します安全手袋の費用は倉庫運営費に分類されるかもしれません新しいフォークリフトは固定資産環状に属する可能性がありますプロジェクトのための購入であればそのプロジェクトに対して費用を記録する必要があるでしょう1枚の請求書を複数の場所に分割することも可能です例えば2つの倉庫チームで手袋の注文を共有する場合両部門で費用を分割して計上できますそうすれば財務部門は曖昧な請求書の説明から後で再構築することなく資金の使途を正確に把握できます請求書が称号され必要なチェックが完了すると承認プロセスに進むことができます請求書を転記すると企業がベンダーに対して支払うべき金額が買いかけ金として記録されますこうして請求は支払い義務買いかけ金となります支払い条件によって支払い期日が決定されます買いかけ金担当者は期日通りに請求書の支払い準備を行い支払いが処理されるとダイナミクス365がその請求書に対するベンダー残高を消し込みます発注は今や配送予定からコストの記録そして支払い完了へと移行しましたしかしこの一連の流れは単に1枚の請求書を支払う以上の意味を持っていますその購入に関連するあらゆる決定と引き継ぎの有用な記録を会社に提供します5つ目は可視性の管理とより良いベンダー選定の判断です一元化された購入記録により問題が財務部門に達する前に購入を制御できます購入ポリシーが基本ルールを定めます従業員が何を要求できるかどのベンダーを利用できるかそして会社のお金を使う前にいつ承認が必要かを導きます安全装備の要求について考えてみましょう会社は倉庫スタッフに承認済みの安全製品を選択させ新しいベンダーの選択は購買チームのみに限定するかもしれません小さな交換注文なら承認は1つで済みますが新しいチーム向けの大きな注文なら予算所有者と購買マネージャーの承認が必要になる場合がありますルールはプロセスの中に組み込まれています従業員はポリシー文書を検索したり誰が承認すべきか推測したり誰かから返信があるまでメールを転送したりする必要はありませんダイナミクス365は部門、金額、購入タイプまたは付随するポリシーに基づいて要求をルーティングできますそのルートはワークフローと呼ばれますワークフローは要求、注文書、請求書に次から次へと進む明確な道筋を与えます各担当者は承認、拒否または変更のための差し戻しが可能でシステムはその操作を記録します長いメールチェーンの中で承認が完了したかどうかを悩む必要はもうありませんこれは誰かが不在の時にも役立ちます業務がその人のアウトルックの受信トレイに消えてしまいどこで止まっているのかわからなくなることはありません会社は現在のステップを確認しそれに対処できますベンダーポータルを利用すればベンダーもプロセスに参加できますベンダーポータルはベンダーが共有された見積もり依頼や注文書を確認できる場所を提供しますベンダーは見積もり依頼に応答でき会社が確認依頼を送れば注文を直接確定できますこれにより双方が同じ文書に基づいて作業できるようになりますバイヤーがPDFを送信して返信を待ちその内容をシステムに入力し直す代わりにベンダーが接続されたプロセスを通じて詳細を確認できますバイヤーは手作業で記録を作り直すことなく回答を確認できます購入がシステムを通じて行われると新しいスプレッドシートを作成しなくても有用な情報が収集されます支出分析はお金はどこに使われているのかというシンプルな問いに答えます購買マネージャーはベンダー、製品、調達カテゴリーまたは部門別に支出を確認できます会社は一つのサプライヤーから手袋を買っていると思っていても記録を見ると複数のチームが異なるベンダーから似たような手袋を買っていることがわかりますあるいはある部門が予想以上に外部の修理費を使っているかもしれませんそれらの詳細情報は会社が次の購入の前により適切な質問をするための根拠となりますベンダーパフォーマンス分析は同じ状況をベンダーの視点から見るものです購買担当者は将来の発注先を決定する際に仕入れと納品の成果を比較できますベンダーの納品が遅れたり不完全な注文を出荷したり合意した条件を満たせなかったりする場合書類上の価格が安くても魅力は薄れます企業はベンダーとの関係を見直す際に自社の購入記録を活用できます次に監査証跡オーディットトレイルがあります監査証跡があれば購入の全履歴を追跡できます最初の要求から始まり承認者を確認し発注書をレビューし受領書を称号し請求書を見つけ支払いの完了を確認できますこの記録は財務や監査チームに役立つだけでなく一般の社員が日常的な疑問を解決するのにも役立ちますなぜこれを購入したのか誰がこのベンダーを選んだのか商品は到着したか請求書はすでに支払われたかその答えは購入記録の中にあります最初のオフィスビルに戻ってみましょう購買デスク、受取ドック、財務デスクにはそれぞれ異なる仕事がありますがバラバラの書類を部屋間でやり取りするのではなく全員が同じ購入プロセスの各部分を共有しています倉庫マネージャーが作成したヘルメットと手袋のTMS要求には今や完全な履歴が残っていますその要求は社内規定に従ったものでした適切な担当者が承認しましたベンダーが備品を供給しました倉庫スタッフが納品を記録しました買いかけ金担当者が請求書と称号し支払いを完了させましたシンプルな区別がこれらの構成要素を明確に保ちますソーシングは購入先の選定を支援し調達、プロキュアメントは購入決定後のプロセスを管理します結論ですリードから支払いまで全てが一つの記録で繋がります全体像はこうです調達とソーシングは散在していた引き継ぎ作業を追跡可能な一つの企業プロセスへと変えます要求が受信ボックスで消えたり承認が誰かの記憶だけに頼ったり背後にある決定が不明なまま請求書が届いたりすることはありません代わりに企業は購入の全過程をたどる繋がった一つの記録を保持しますそれにより必要な時に明確な答えが得られます購買担当者は注文を確認できます倉庫は入荷予定を把握できます財務は会社の負債を把握できますそしてマネージャーは支出の行き先を正確に把握できます購入には今も人、ベンダー、商品、サービス、そして決定が関わっていますダイナミクス365はそれらを取り除くわけではありませんそれらの記録を統合することで不確実性や問題を減らした購入が可能になりますお気に入りのポッドキャストプラットフォームで登録しダイナミクス365の調達とソーシングを学び始めた仲間にこの知識をシェアしてください