WEBVTT 00:00:00.000 --> 00:00:08.200 m 365 fm の知識の小ネタようこそおいでくださいましたホストのミルコピーターズです 本日は在庫管理についてお話しします見えない在庫は損失につながります 00:00:08.200 --> 00:00:15.280 倉庫にある一つの品目について今すぐ5つの質問に答えられますか 在庫はいくつありますかどこにありますか販売は可能ですか所有者は誰ですか 00:00:15.280 --> 00:00:24.080 原価はいくらですか多くの企業ではこれらの回答がバラバラの場所に存在しています スプレッドシート倉庫の棚卸し財務データでそれぞれ数値が異なるのです 00:00:24.080 --> 00:00:32.920 ダイナミクス365の在庫管理は会社が扱うあらゆる箱 部品製品のための共有キャビネットのようなものです品物が動けばその記録も動きます 00:00:32.920 --> 00:00:39.980 このエピソードの終わりまでには一つの品物をサプライヤーからの納入から顧客への出荷まで 金額情報を含めて追跡できるようになります 00:00:39.980 --> 00:00:50.400 なぜ在庫管理が必要なのかコーヒーマシンを販売していると想像してください 顧客から注文が入りましたが倉庫に在庫がなく営業担当がそれでも納期を約束して 00:00:50.400 --> 00:00:55.160 しまいました 購買担当は慌ててサプライヤーに連絡しますが顧客は他社で買うことを決めるかもしれません 00:00:55.160 --> 00:01:04.860 これが欠品です在庫が少なすぎると注文の遅延販売の機械損失顧客の不満につながります 生産そのものが停止することもあります機械を製造していて小さな部品が一つ切れただけでライン 00:01:04.860 --> 00:01:09.260 全体が止まる可能性があるのです かといって棚を余分な在庫で埋めれば解決するというわけではありません 00:01:09.260 --> 00:01:16.540 棚にあるすべての箱は会社がすでに支払ったお金そのものです 保管コストがかかりますし商品が破損したり期限切れになったり時代遅れになったり単純に売れ 00:01:16.540 --> 00:01:21.840 なくなることもあります 倉庫に眠っている間その資金はサプライヤーへの支払いや新規プロジェクト給与支払いに充てることができません 00:01:21.840 --> 00:01:29.680 在庫管理はそのバランスを取るためのものです 顧客の需要を満たす十分な在庫は必要ですが倉庫が高価な物置にならないようにしなければなりません 00:01:29.680 --> 00:01:36.880 在庫とは顧客向けの完成品だけを指すのではありません 家具メーカーであれば木材ねじ布の塗料を原材料として追跡します 00:01:36.880 --> 00:01:44.380 作業員が椅子を作り始めればその未完成の椅子は仕掛け品となります そして販売可能な状態になればそれは完成品となります 00:01:44.380 --> 00:01:53.680 また予備部品清掃用品梱包材あるいは修理用の交換部品なども追跡する必要があるかもしれません これらは最終製品には含まれませんが事業運営には不可欠です 00:01:53.680 --> 00:01:58.140 ではこれまでの昔ながらの方法を想像してみてください 購買部門が注文リストを管理し 00:01:58.140 --> 00:02:04.060 倉庫担当が到着数を数え営業が注文を追い 生産部門が使用量を記録し財務部門がコストを計算するのです 00:02:04.060 --> 00:02:10.600 各チームは懸命に取り組んでいますがリストが分かれていると数値にズレが生じます 誰かが納品を受け取ってもスプレッドシートの更新は後回しになります 00:02:10.600 --> 00:02:16.880 パレットを別の倉庫に移動しても営業への連絡を忘れてしまいます 注文を出荷しても財務部門がそのコストを把握するのは数日後です 00:02:16.880 --> 00:02:21.200 その結果実際にどれだけの在庫があるのかという単純な疑問で揉めることになります 00:02:21.200 --> 00:02:30.020 ダイナミクス365の在庫管理はこれらのチームに共通の在庫記録を提供します 購買は入荷を記録し倉庫担当は移動を記録し営業は出荷を記録し 00:02:30.020 --> 00:02:37.840 生産は使用した資材を記録し財務はそれらの動きの背後にある価値を把握します 毎週金曜日に同じスプレッドシートの新しいバージョンを作成する必要はもうありません 00:02:37.840 --> 00:02:46.440 目標は倉庫を技術的にすることではなく必要な時に現在の共通の答えを人々に提供する ことですこの注文に対応できるか次の配送先はどこにするべきか 00:02:46.440 --> 00:02:53.000 なぜ実地棚卸しとシステム上の数値が異なるのか これらの問いに答えるためにダイナミクスには製品名と数字以上のものが必要です 00:02:53.000 --> 00:02:58.680 アイテムが移動するたびに何が変わったかを明確に記録する必要があります すべてのアイテムの背後にあるデジタル記録です 00:02:58.680 --> 00:03:06.560 m365fmがお届けするマイクロソフト知識ナゲットの新しいエピソードへようこそ 司会を務めるのはマルコピーターズです今日は在庫が場所を移動する際 00:03:06.560 --> 00:03:14.900 ダイナミクス365の内部で何が起こるかについてお話しします ではアイテムが人の手に渡ったり場所が変わったりした時ダイナミクス365は正確に何を記録するのでしょうか 00:03:14.900 --> 00:03:25.460 最もシンプルな定義を説明します数量保管場所使用可否所有者コストの5つを追跡します 単純に聞こえますが各項目は異なるビジネス上の問いに答えています 00:03:25.460 --> 00:03:33.080 細かく見ていきましょう数量はコーヒーマシンがいくつあるかを教えてくれます 保管場所はどの建物倉庫棚にあるかを答えます 00:03:33.080 --> 00:03:41.400 ステータスは販売可能かそれとも検査待ちかを教えてくれます 所有権は私たちがすでに所有しているのかそれともサプライヤーが預けているのかを説明します 00:03:41.400 --> 00:03:50.300 そしてコストはこの在庫にどれだけの価値があるかを答えます これらすべての出発点は製品レコードですすべてのアイテムはシステム内で識別される必要があります 00:03:50.300 --> 00:03:58.400 通常それはアイテム番号と明確な説明です また時間個数箱パレットキログラムメートルといったカウント単位も定義します 00:03:58.400 --> 00:04:07.240 ここで小さなことが大きな問題に発展する可能性があります 購買がコーヒーフィルターを箱で買い営業がパックで売る場合ダイナミクスはその単位の関係を理解する必要が 00:04:07.240 --> 00:04:11.820 あります そうでなければあるチームは10箱あると考え別のチームは10個あると考えてしまいます 00:04:11.820 --> 00:04:17.680 それは混乱のもとです一部の製品にはバリエーションもあります t シャツには s m l のサイズがあるかもしれません 00:04:17.680 --> 00:04:26.440 色も黒青白などがあります一つの製品でもサイズ色スタイル構成が異なる場合があります システムはそれぞれの組み合わせを独自の在庫記録として扱うことができます 00:04:26.440 --> 00:04:33.340 つまり単に t シャツがあるだけではないのです ある倉庫に黒の m サイズ t シャツが12枚別の場所に白の l サイズ t シャツが6枚あるといった状況です 00:04:33.340 --> 00:04:41.180 顧客が特定の品物を求めている場合こうした詳細情報が重要になります ダイナミクスは在庫ディメンションを使ってそれらの詳細を正しく管理します 00:04:41.180 --> 00:04:48.500 専門用語のように聞こえますが要はシステムが在庫を識別するためのラベルのことです これにより実用的な2つの疑問に答えることができます 00:04:48.500 --> 00:04:53.160 その品物はどこにあり具体的にどの品物なのか 主な構成要素に分けて見ていきましょう 00:04:53.160 --> 00:05:00.660 まずは保管ディメンションですこれは在庫が置かれている場所を表します ダイナミクスでは拠点倉庫そして倉庫内のロケーションを追跡できます 00:05:00.660 --> 00:05:07.080 品物の住所のようなものだと考えてください 拠点は工場エリアや配送センターといった広域な事業拠点を示します 00:05:07.080 --> 00:05:14.020 その拠点内には複数の倉庫を設けることができます 例えば入荷用製品用返品用といった具合です 00:05:14.020 --> 00:05:21.360 さらに深く掘り下げることも可能です ロケーションは通路ラック棚瓶など倉庫内の正確な位置を指し示します 00:05:21.360 --> 00:05:29.060 そのため作業員に機械部品は倉庫へのどこかにあると伝えるのではなく 通路4ラック2棚3瓶1を確認してと指示を出せます 00:05:29.060 --> 00:05:36.460 これにより在庫を素早く見つける時間を短縮できます 保管ディメンションが場所を示すのに対し追跡ディメンションはそれがどの在庫かを示します 00:05:36.460 --> 00:05:46.240 バッチ番号ロット番号とも呼ばれますは同時に入荷または生産された品物をグループ化します これは賞味期限や検査結果後で必要となるサプライヤー情報がある場合に重要です 00:05:46.240 --> 00:05:53.720 食品会社が同じソースを2回納品したと想像してください 瓶は同じに見えますが片方のバッチは6月もう片方は9月に期限が切れます 00:05:53.720 --> 00:05:58.620 品質問題が発生した場合すべての棚から全商品を回収することなく影響を受けたバッチだけを特定する必要があります 00:05:58.620 --> 00:06:06.340 シリアル番号はさらに詳細な情報を提供します シリアル番号はノートパソコン医療機器産業機械などの個別の品物を識別します 00:06:06.340 --> 00:06:15.600 これにより製品単位で追跡できるため修理保証対応返品リコールに役立ちます ダイナミクスで手持ち在庫を表示すると会社全体の曖昧な数値が表示されることはありません 00:06:15.600 --> 00:06:25.720 拠点倉庫ロケーションバッチシリアル番号などビジネスに必要な詳細単位で在庫を確認できます 数量が物理的にどこにあるのか使用可能か注文用に確保されているかあるいは保留中かを確認することも 00:06:25.720 --> 00:06:32.000 できます これが製品名だけでは不十分な理由です最後の構成要素は品目の取引履歴です在庫の入庫 00:06:32.000 --> 00:06:40.640 出荷移動棚卸し修正または製造への投入が行われるたびにダイナミクスは取引を記録します その履歴により推測ではなく調査を行うことができます 00:06:40.640 --> 00:06:49.860 在庫数が間違っているように見えれば品目記録を遡りどの動きでこの数値が変わったのか を確認できますこれこそがその魔法です次に一つの品目の日常的な流れを追ってみましょう 00:06:49.860 --> 00:06:58.560 在庫が動き始めるとこれらの記録ははるかに理解しやすくなるからです サプライヤーの納品から顧客の注文までコーヒーマシン事業でサプライヤーに給水ポンプを100個 00:06:58.560 --> 00:07:05.860 発注したと想像してください 発注書がその度の始まりです発注書には何を期待しているか何個注文したか誰が送るかどこに到着すべきかが 00:07:05.860 --> 00:07:14.100 記録されますトラックが建物に到着する前にビジネスとして明確な見通しが立っています 予定されている納品は販売可能な在庫ではないためこれは重要です貨物が到着すると 00:07:14.100 --> 00:07:20.440 担当者が発注書と照らし合わせて納品内容を確認します サプライヤーは正しいポンプを送ってきましたか送られてきたのは100個ですかそれとも98個ですか 00:07:20.440 --> 00:07:28.180 正しい倉庫に到着しましたか入庫が記録されるとダイナミクスはポンプが物理的に 到着したことを認識しますシステムは物理的な在庫記録を増やせますがそれが常に 00:07:28.180 --> 00:07:35.580 顧客の注文に対応できる状態であることを意味するわけではありません 先に検査が必要な商品もあります食品会社ならバッチの損傷や賞味期限をチェックするかもしれません 00:07:35.580 --> 00:07:42.680 製造業であれば生産工程に入る前に部品をテストするでしょう 既製品を扱う企業であれば出荷が規則を満たしているという証明が必要になるかもしれません 00:07:42.680 --> 00:07:50.220 ダイナミクスでは在庫検疫エリアに入れたり早期に使用できないようなステータスを 設定したりできます倉庫スタッフはポンプが到着したことを確認できます 00:07:50.220 --> 00:07:58.340 営業や製造部門もそれらがまだ使用可能ではないことを確認できます これによりまだ承認が必要な在庫顧客に約束してしまうという厄介なミスを避けられます 00:07:58.340 --> 00:08:06.500 検査後ポンプは受入エリアから通常の保管場所へ移動します これは格納2ウェイと呼ばれますが実際の作業にはフォークリフトパレットトラックあるいは人が小さな箱を 00:08:06.500 --> 00:08:12.220 棚まで運ぶといった動作が含まれるかもしれません この移動が重要です搬入口はポンプが今後6ヶ月間置かれるべき場所ではありません 00:08:12.220 --> 00:08:16.160 注文が入った時にすぐに見つけられるよう 倉庫チームはそれらを適切な場所に置く必要があります 00:08:16.160 --> 00:08:22.320 ダイナミクスは受入エリアから割り当てられた倉庫の場所への内部移動を記録します さて別の拠点で需要が変化したと想像してください 00:08:22.320 --> 00:08:27.620 メイン倉庫には80個のポンプが保管されています 別の都市のサービスセンターから修理用に20個の依頼がありました 00:08:27.620 --> 00:08:31.920 サービスチームが棚から勝手に持ち出し誰かが後でリストを更新するのを期待する ような管理ではいけません 00:08:31.920 --> 00:08:38.860 転送オーダーを使えば倉庫や拠点間の移動や要求を記録できます 商品が移動中ダイナミクスではそれを輸送中として扱えます 00:08:38.860 --> 00:08:43.860 商品は消えたわけではなくまだ目的地にも到着していません これにより双方が状況を明確に把握できます 00:08:43.860 --> 00:08:48.740 発送側の倉庫は在庫が減ったことを認識できます 受取側の倉庫は何が届く予定かを把握できます 00:08:48.740 --> 00:08:54.100 もしトラックの荷物が不足していても記録が残るため原因を調査できます やがて顧客から注文が入ります 00:08:54.100 --> 00:09:02.120 受注伝票には顧客が何をいつ必要としているかが記載されます 在庫がありそれをその顧客に割り当てる場合ダイナミクスで数量を確保できます 00:09:02.120 --> 00:09:10.580 確保とはそのポンプが単なる一般在庫ではなくなることを意味します 特定の注文用に確保されるため他の営業担当者が同じ在庫を別の人に約束することはありません 00:09:10.580 --> 00:09:18.120 これは在庫が少ない場合や顧客の納期を守る必要があるときに特に重要です 倉庫スタッフは保管場所からそのポンプをピッキングします 00:09:18.120 --> 00:09:26.080 小規模な運用なら作業員がピッキングリストを印刷して商品を集めます 大規模な運用では倉庫管理システムがモバイル端末やルールで作業を指示します 00:09:26.080 --> 00:09:31.680 どちらの場合も在庫記録は常に連動しています ピッキング後注文は梱包と出荷の工程に進みます 00:09:31.680 --> 00:09:41.540 出荷が完了するとダイナミクスがポンプの出荷を記録します 利用可能な在庫数が変わり品目の履歴には仕入れから保管顧客への納品までの全過程が記録されます 00:09:41.540 --> 00:09:47.840 しかし実際の倉庫業務が常に理想通りに進むわけではありません 顧客から破損による返品があるかもしれません 00:09:47.840 --> 00:09:54.220 棚で破損した商品を2つ見つけることもあるでしょう 棚卸し中に実在庫とシステム上の数値が食い違うこともあります 00:09:54.220 --> 00:10:01.680 ダイナミクスは返品や棚卸し際移動修正手動調整を記録できます こうした操作をミスを隠すために使ってはいけません 00:10:01.680 --> 00:10:07.340 これらは何がいつなぜ変更されたかを示す追跡記録となります その記録がチームが傾向を見つける助けになります 00:10:07.340 --> 00:10:12.060 特定の場所で繰り返しカウントミスが起きているのかもしれません 仕入れ先からの出荷にいつも不足があるのかもしれません 00:10:12.060 --> 00:10:17.860 返品された商品を在庫に戻す前により厳格な検品が必要なのかもしれません 数量は状況を教えてくれますが 00:10:17.860 --> 00:10:26.720 すべてのポンプにはコストが伴いそこが倉庫業務と財務が直結する点です お好みのポッドキャストプラットフォームで登録しこれから学び始める誰かにシェアしてください 00:10:26.720 --> 00:10:33.620 在庫に紐づくお金のことについてです 倉庫の棚に置かれたポンプは単に出荷を待つ物理的なもの以上の存在です 00:10:33.620 --> 00:10:40.880 それらは会社がすでに支出したお金そのものです その資金はポンプが販売使用廃棄あるいはその他の方法で在庫からなくなるまで 00:10:40.880 --> 00:10:46.120 会社の財務記録上で資産として残ります この単純なつながりが受領に対するあなたの見方を変えるはずです 00:10:46.120 --> 00:10:54.220 例えば100台のポンプが到着した時倉庫チームは単に100個のユニットとして認識します しかし財務部門は在庫として追加されたその価値を把握する必要があります 00:10:54.220 --> 00:11:00.380 そしてポンプが顧客に出荷される時倉庫チームは棚の空きスペースを意識しますが 財務部門は出ていく商品の原価を記録しなければなりません 00:11:00.380 --> 00:11:05.080 ダイナミクスはこれら2つの視点を自動的に結びつけます そこで活躍するのが品目グループです 00:11:05.080 --> 00:11:09.500 品目グループとは類似した製品を整理しシステムがその財務処理を理解できるようにするための 仕組みと考えてください 00:11:09.500 --> 00:11:15.060 例えばスペアパーツを1つのグループに完成したコーヒーマシンを別のグループに そして原材料を3つ目のグループにまとめることができます 00:11:15.060 --> 00:11:22.920 バックグラウンドではこれらのグループが購入販売調整生産活動などの財務的影響を どの相関上元町に反映させるかをダイナミクスに指示しています 00:11:22.920 --> 00:11:30.480 会計の専門家でなくてもこの仕組みを理解することは難しくありません 相関上元町とは単なる会社の主要な財務記録であり財務部門が資産 00:11:30.480 --> 00:11:40.200 費用売上など全体像を追跡するための公式な帳簿です 在庫管理機能は品目グループに設定されたルールに従ってすべての在庫関連金額をその記録に送信します 00:11:40.200 --> 00:11:47.300 つまり月末に倉庫チームと財務チームが異なるシステムを見比べてどちらの数字が 正しいか議論する必要はなくなるのです 00:11:47.300 --> 00:11:52.240 両者はダイナミクス上の同じ品目アクティビティを見ていますがまだ答えるべき大きな 問いが一つ残っています 00:11:52.240 --> 00:11:56.860 ポンプ1台の実際の原価はいくらでしょうか それは選択した原価計算方法によって異なります 00:11:56.860 --> 00:12:01.160 原価計算方法とは在庫から払い出されるストックにダイナミクスがコストを割り当てる際の ルールのことです 00:12:01.160 --> 00:12:04.780 例を挙げてみましょう ファイホとは先入れ先出し法のことです 00:12:04.780 --> 00:12:09.540 例えば1月に50台のポンプを1台20ドルで仕入れ 2月にさらに50台を1台24ドルで仕入れたとします 00:12:09.540 --> 00:12:13.980 ファイホを使用して10台を出荷する場合 ダイナミクスは最も古いポンプから順に出荷されたとみなします 00:12:13.980 --> 00:12:17.600 そのためその10台は1月のバッチから1台20ドルで計算されます 00:12:17.600 --> 00:12:23.560 この方法は食料品や医薬品など新しい在庫より古い在庫を物理的に先に消費したい商品に適しています 00:12:23.560 --> 00:12:26.080 過重平均法は異なるアプローチを取ります 00:12:26.080 --> 00:12:32.680 出荷するユニットごとに1月のコストと2月のコストを分けるのではなく 利用可能なすべてのユニットのコストを一つに平均化します 00:12:32.680 --> 00:12:39.880 例えば同じポンプを異なる価格で購入した場合 システムは総在庫額を総ユニット数で割ってポンプ1個あたりの平均原価を算出します 00:12:39.880 --> 00:12:44.560 個々のユニットが混在し個別の納品分を追跡する必要がない場合には理にかなっています 00:12:44.560 --> 00:12:49.820 移動平均も平均値を用いますが新しい価格で在庫が補充されるたびに平均値が変動します 00:12:49.820 --> 00:12:57.680 標準原価の仕組みは少し異なります 企業が品目ごとの予定原価を設定しその予定原価と実際の支払額との差異を記録します 00:12:57.680 --> 00:13:03.820 どの方法も同じ問いに対してそれぞれの答えを出します 在庫から払い出す際どの原価を適用すべきかということです 00:13:03.820 --> 00:13:12.200 しかし原価は納品や出荷の時だけに変動するわけではありません 製造業では原材料を生産に投入し完成品として新しい原価を付与して在庫に戻すことがあります 00:13:12.200 --> 00:13:20.280 棚卸し債の修正によっても在庫評価額は変わります 破損品の廃棄によっても評価額は減少しますまさにこの理由から在庫管理を財務から切り離すことはできません 00:13:20.280 --> 00:13:28.200 倉庫の記録ではポンプが500個あっても財務上の評価が450個分であれば問題が生じます たとえ倉庫の現場で誰も気づいていなくてもです 00:13:28.200 --> 00:13:39.940 利益現金購買販売に関するあらゆる意思決定は数量と原価の正確さに依存しています ダイナミクスで記録が統合されれば単なる今日の在庫数に留まらず日々の在庫判断をよりスマートに行えるようになります 00:13:39.940 --> 00:13:46.520 可視性発注そして日々の管理です 在庫記録を信頼できるようになれば日々の判断は大幅に楽になります 00:13:46.520 --> 00:13:56.740 バイヤーが各倉庫に電話をかけて誰かに原品を確認してもらう必要もありません 拠点、倉庫、ロケーションを横断して輸送中や検査待ちの在庫を含め手元にある在庫を正確に把握できます 00:13:56.740 --> 00:14:03.560 その区別が重要なのです 合計で500個所有していても顧客に約束できるのはそのうちの300個だけかもしれません 00:14:03.560 --> 00:14:12.620 輸送中のもの品質検査待ちのものすでに他の注文で予約済みのものがあるからです ダイナミクスを使えば単純に最大の数値を見るのではなく利用可能な数量を把握できます 00:14:12.620 --> 00:14:20.340 その明確な視界はより適切な発注にも役立ちます どの企業もいつ追加発注すべきかを知る必要がありますがその答えは今日の数量だけで決まるわけではありません 00:14:20.340 --> 00:14:29.300 商品の売れ行き、仕入れ先のリードタイム、急な需要増に備えたバッファ在庫の量も考慮しなければなりません この余分なクッションが安全在庫です 00:14:29.300 --> 00:14:38.340 計画通りにいかない日のためのバックアッププランと考えてください 仕入れ先の納品遅延、予想外の大量注文、あるいは生産ラインでの想定以上の材料消費などです 00:14:38.340 --> 00:14:45.000 そのバッファがなければ一度のトラブルですべてが停止してしまいかねません しかし在庫が多すぎれば棚に現金を眠らせているのと同じです 00:14:45.000 --> 00:14:51.060 ダイナミクスを活用すれば需要や仕入れのリードタイムの変化に応じて在庫レベルをより適切に設定見直しするためのデータが得られます 00:14:51.060 --> 00:14:57.740 ただしこれらすべてはシステム上の記録が現実と一致して初めて機能します だからこそ棚卸しは今でも日々の管理業務の一部なのです 00:14:57.740 --> 00:15:02.400 年に一度すべてを棚卸しするチームもあれば年間を通じて少人数のグループで順次数えるチームもあります 00:15:08.340 --> 00:15:17.700 上の理論在庫数と比較し差異があれば修正を反映させる前に調査を行います 差異の原因としては破損盗難スキャンの漏れ置き場所の間違いあるいは過去の移動履歴における 00:15:17.700 --> 00:15:24.800 ミスなどが考えられます修正作業で数字を合わせ調査によってプロセスを改善するのです ダイナミクスは長期間動いていない在庫を特定するのにも役立ちます 00:15:24.800 --> 00:15:33.700 在庫経過分析エイジングレポートにより長期間動きのないアイテムを可視化できます これは消費期限のある商品季節商品古いスペアパーツあるいは顧客の需要がなくなった製品にとって不可欠です 00:15:33.700 --> 00:15:42.760 古い在庫を早期に発見すれば選択肢が広がります割引価格で販売する需要の高い場所へ移動する 契約に基づき返品するあるいは単に追加発注を止めることも可能です 00:15:42.760 --> 00:15:49.460 古い在庫で棚が埋まるまで放置すればそうした選択肢は失われてしまいます またすべてのアイテムに同じレベルの注意を払う必要もありません 00:15:49.460 --> 00:15:55.880 abc分析はアイテムを財務的インパクトに基づいて分類するのに役立ちます 極少数のアイテムが在庫金額の大半を占めている場合もあります 00:15:55.880 --> 00:16:03.300 そうしたアイテムこそ綿密なカウントや厳格な発注判断そして慎重な見直しが必要です 頻繁に動く低コストのアイテムであれば管理を簡素化できるでしょう 00:16:03.300 --> 00:16:09.160 目的はすべてを平等に扱うことではありません ミスがビジネスに最も大きな影響を与える部分に時間を集中させることです 00:16:09.160 --> 00:16:17.100 知っておくべき特別なケースとして予納在庫コンサインメント在庫があります サプライヤーが自社の部品を汽車の倉庫に置いているものの所有権はサプライヤーにある状態を想像してください 00:16:17.100 --> 00:16:23.620 在庫は製造チームのすぐそばにあり必要な時にすぐ使えますが実際に所有権を取得するまでは汽車の在庫にはなりません 00:16:23.620 --> 00:16:30.400 ダイナミクスならその違いを追跡できます 現場チームは部品が手元にあることを確認し財務部門は所有権を明確に管理できます 00:16:30.400 --> 00:16:38.840 その部品を使用するとシステムが所有権の変更を記録しコストが汽車のものとなります これは前払いせずに在庫に素早くアクセスしたい場合に非常に有効です 00:16:38.840 --> 00:16:44.160 これらすべてが機能するのは購買販売製造倉庫財務の各チームが共通のデータに基づいて動いているからです 00:16:44.160 --> 00:16:51.000 すべてのレポートは同一の在庫履歴から作成されます 他のビジネスシステムも個別のリストを作成することなくその履歴に接続できます 00:16:51.000 --> 00:16:59.480 それでもダイナミクスの新規ユーザーを混乱させる共通の勘違いが一つあります 在庫管理と倉庫管理は密接に関係していますが同じ意味ではありません 00:16:59.480 --> 00:17:06.480 それについては別のナレッジナゲットで扱います 在庫管理と倉庫管理は関連していますが同一ではありません 00:17:06.480 --> 00:17:12.100 よくある混乱を解消しましょう 在庫管理と倉庫管理は異なる問題を解決するものです 00:17:12.100 --> 00:17:17.140 在庫管理は全社的な在庫記録を保持するものです 在庫管理はどれだけあるかという大きな問いに答えます 00:17:17.140 --> 00:17:24.320 それはどこに記録されているのかそれを使用できるのか そしてその価値はどれくらいかその記録は購買販売生産移動返品 00:17:24.320 --> 00:17:29.980 棚卸しを通じて在庫のあらゆる動きを追跡します 倉庫管理は倉庫内での物理的な作業に関するものです 00:17:29.980 --> 00:17:38.460 商品の受け入れ棚入れ注文のピッキング出荷の積み込みなどの作業をスタッフに指示します より詳細な設定ではモバイル端末でバーコードをスキャンし 00:17:42.100 --> 00:17:47.780 見てください在庫管理はマスターとなる書類棚です ビジネス全体の在庫に関するストーリーがすべてそこに収められています 00:17:47.780 --> 00:17:57.800 倉庫管理はその棚の情報を使い倉庫現場での作業を遂行する手助けをします 一方はストーリーを記録しもう一方は物理的な場所で正確かつ迅速な在庫処理を支援します 00:17:57.800 --> 00:18:04.540 すべての企業に同じ深さの機能が必要なわけではありません 小規模な卸売業なら明確な品目記録倉庫移動棚卸から始めれば良いでしょう 00:18:04.540 --> 00:18:13.920 作業員棚パレットが多く注文が高速に動く大規模な運用ではより詳細な倉庫プロセスが 必要になるかもしれませんしかしどちらの場合もすべての部門が同じ品目履歴を必要としています 00:18:13.920 --> 00:18:20.940 結論として共有された一つの在庫ストーリー ダイナミクス365の在庫管理はサプライヤーからの受領と保管から顧客への出荷 00:18:20.940 --> 00:18:26.660 財務的価値に至るまで在庫の全ライフサイクルを記録します それはビジネス全体で共有される一つの在庫ストーリーです 00:18:26.660 --> 00:18:33.020 ナレッジナゲットをご視聴いただきありがとうございます m365fmで私ミルコピーターズの今後のエピソードをぜひチャンネル登録してください 00:18:33.020 --> 00:18:40.760 そして次のエピソードではダイナミクス365サプライチェーンマネジメントが同じ在庫記録を機に購買 倉庫計画をどのように結びつけるかをご紹介します