WEBVTT

00:00:00.000 --> 00:00:08.680
数値を受け取るをクリックしても数百の棚からその正確な品目を探し出し 間違いがないかを確認し正しいトラックに積み込む作業が依然として必要です

00:00:08.680 --> 00:00:16.680
スプレッドシートは50個の在庫がどこかに存在することを示せます しかし在庫が毎分動く忙しい倉庫内で作業者を直接案内することはできません

00:00:16.680 --> 00:00:25.200
そこでダイナミクス365ウェアハウスマネジメントの出番となります これは倉庫内のデジタルガイドとして機能し商品到着の瞬間から注文品が積み込み

00:00:25.200 --> 00:00:32.740
ドックを離れるまでの作業を指示します 最後まで見れば入荷保管ピッキング出荷そしてすべての活動がビジネスの他の部分とどう

00:00:32.740 --> 00:00:39.320
つながるかを理解できるはずです なぜ倉庫管理が必要なのか忙しい図書館を想像してみてください

00:00:39.320 --> 00:00:48.880
すべての本がパレットで届き部屋から部屋へと移動し1時間以内に読者の元へ届ける必要がある状況です 本は製品であり棚は保管場所です図書館スタッフにはどこにあるかという

00:00:48.880 --> 00:00:55.420
大まかな把握以上のものが必要ですどこの棚のどの正確な位置にあるか そして別の読者に貸し出し予約がされていないかを知る必要があります

00:00:55.420 --> 00:01:01.100
倉庫も同じ問題を抱えています ただし本を間違えると顧客の注文品を誤って出荷することになります

00:01:01.100 --> 00:01:06.900
長い間チームは紙のピッキングリスト手作業でのカウント そして個別のシステムでこの作業の多くを処理してきました

00:01:06.900 --> 00:01:14.740
作業員が移動させた品目を書き留め後で誰かがコンピュータに入力していました 午前9時に棚から在庫が移動しても昼食時になってもシステム上では棚にあるまま

00:01:14.740 --> 00:01:19.820
ということが起こり得ます そのタイムラグが混乱を生みます 購買チームはサプライヤーから何が届いたかを尋ねます

00:01:19.820 --> 00:01:24.920
営業チームはその品目が今日出荷できるかを尋ねます 倉庫管理者はパレットがどこにあるかを尋ねます

00:01:24.920 --> 00:01:31.700
財務部門は会社がどのような在庫を保有しているかを知る必要があります チームごとに答えが異なれば人々はスプレッドシートを確認し現場を歩き回り

00:01:31.700 --> 00:01:35.120
電話で連絡を取り合うことになります 作業は急速に遅延します

00:01:35.120 --> 00:01:40.700
ダイナミクス365サプライチェーンマネジメントはビジネス全体のより広範な商品の流れを 接続します

00:01:40.700 --> 00:01:49.960
サプライヤーからの購入製品製造在庫移動顧客への販売返品対応などをカバーします ウェアハウスマネジメントはこの接続されたプラットフォーム内で倉庫内の物理的な作業に

00:01:49.960 --> 00:01:52.720
焦点を当てています 次に何をすべきかを作業者に指示します

00:01:52.720 --> 00:01:56.720
作業者は配送品を受け取ることができます 別の作業者は製品を保管場所に移動できます

00:01:56.720 --> 00:02:02.840
また別の人は顧客の注文をピッキングし箱詰めし出荷準備ができます 各アクションは発生した瞬間に同じビジネスシステムに記録されます

00:02:02.840 --> 00:02:08.400
この共有された記録が会話を変えます 誰がどうやってその部品を動かしたのかと尋ねる代わりに

00:02:08.400 --> 00:02:15.700
ああ倉庫のタスクステータスそして在庫の場所が見えるようになります 印刷されたリストを送って読みやすい手書きで戻ってくることを期待する代わりに

00:02:15.700 --> 00:02:23.160
作業者はモバイル端末の指示に従いスキャンで各動作を確認します さて在庫管理と倉庫管理は響きが似ているため混同されることがよくあります

00:02:23.160 --> 00:02:32.140
在庫管理は今在庫はどれくらいあるかという問いに答えるものです これは企業全体の数量コスト製品詳細そして在庫状況を追跡します

00:02:32.140 --> 00:02:37.000
倉庫管理は別の問いに答えるものです それはその在庫は正確にどこにあるのかということです

00:02:37.000 --> 00:02:42.280
そして作業者は次に何をすべきかということです 製品の箱を200個持っていると知ることは確かに有益です

00:02:42.280 --> 00:02:49.820
40箱が受け入れドックにあり120箱がバルク保管エリアに20箱がピッキングエリアにあり 残り20箱が顧客の注文用に確保されていると知ることこそが

00:02:49.820 --> 00:02:54.280
倉庫運営の要となります つまり在庫管理は在庫の記録と考えてください

00:02:54.280 --> 00:03:00.180
倉庫管理はその記録を具体的な作業指示へと変えるものです 配送トラックがちょうどに受けドックに到着しました

00:03:00.180 --> 00:03:06.020
サプライヤーは荷卸しを待ちますがシステムがすべての品目の行き先を判断したとき 本当の仕事が始まります

00:03:06.020 --> 00:03:15.460
倉庫のマップサイト倉庫ロケーションそして在庫の詳細です 在庫を管理する前にシステムは物理的な空間のマップを必要とします

00:03:15.460 --> 00:03:20.880
サイトとは工場キャンパス配送センター地域拠点など より広いビジネスの場だと考えてください

00:03:20.880 --> 00:03:28.780
そのサイト内に一つまたは複数の倉庫を配置できます 倉庫は建物全体を指すこともあれば同じ建物内の独立した保管エリアを指すこともあります

00:03:28.780 --> 00:03:38.680
原材料用完成品用返品用など倉庫を分けて管理することもあるでしょう 次にロケーションですロケーションとは作業が行われる場所または在庫が置かれる正確な位置のことです

00:03:38.680 --> 00:03:44.840
受け入れドックラック棚瓶梱包テーブルなどがそれに当たります 検査町の製品を置く検疫エリアである可能性もあります

00:03:44.840 --> 00:03:49.720
この詳細なレベルが推測による作業を排除します ブルーウィジェット100という製品を想像してください

00:03:49.720 --> 00:03:56.660
ロケーション管理がなければシステムは倉庫aに200個あるとしか教えてくれません 作業者は結局それを探し回る必要があり

00:03:56.660 --> 00:04:04.720
これでは先週見たという人に尋ねるのと大差ありません 倉庫管理があれば記録には通路4ラック b 棚03に80個あると表示されます

00:04:04.720 --> 00:04:10.020
さらに60個がバルク保管エリアにあります 残りは梱包エリアの近くにあり受注への対応準備が整っているかもしれません

00:04:10.020 --> 00:04:16.440
すべての製品は独自のアイデンティティから始まります それには品目番号カウントに使用する単位そして適用されるルールが含まれます

00:04:16.440 --> 00:04:25.720
ボトル入りの水はケースでボルトは個数で床タイルはパレットで数えるかもしれません 製品によっては重量物壊れやすいもの冷蔵品回転の早いものなど特別な保管ルールが必要です

00:04:25.720 --> 00:04:35.340
システムは複数の詳細情報を同時に追跡して在庫管理できます サイト倉庫ロケーションを追跡可能です必要に応じてバッチ番号シリアル番号またはライセンスプレートも追跡できます

00:04:35.340 --> 00:04:43.740
それぞれの詳細は同じ物理的な製品に関する異なる疑問に答えるものです バッチ番号は同じ製造工程や配送で入荷したアイテムをグループ化しますこれは食品

00:04:43.740 --> 00:04:54.040
医薬品化学薬品など問題が発生した際に特定のグループまで遡る必要がある商品で重要となります シリアル番号は個々のアイテムを識別します機械ノートパソコンあるいは高価な部品を

00:04:54.040 --> 00:05:02.600
販売する場合どのユニットが到着しどこへ移動しどの顧客へ届いたかを正確に把握する必要があります それによりアイテムの故障や返品が必要になった際に明確な追跡が可能になります

00:05:02.600 --> 00:05:11.320
次にライセンスプレートを持つアイテムがあります名前に反してトラックとは一切関係ありません ライセンスプレートとはパレットカートン等とその他のコンテナに対する固有の id です

00:05:11.320 --> 00:05:17.480
空港の荷物タグのようなものだと考えてください タグをスキャンすればシステムはそのコンテナが何を指し何が入っているのかを把握します

00:05:17.480 --> 00:05:23.700
すでに内容が登録されたライセンスプレートがパレットに重複されていれば 作業員がパレット上のすべての箱を一つずつスキャンする必要はありません

00:05:23.700 --> 00:05:30.920
これは時間の節約になりますが記録が正確に保たれている場合に限ります ですから手持ち在庫について語るとき必ずしも単なる合計数だけを指すわけではありません

00:05:30.920 --> 00:05:37.160
システムは在庫がどれだけありどこに配置され使用可能かどうか そしてどのバッジシリアル番号コンテナに属しているかを表示できます

00:05:37.160 --> 00:05:45.040
物理的には倉庫内にあっても使用できない在庫もあります 損傷している可能性があります検査待ちである場合もあります顧客の注文文である場合もあります

00:05:45.040 --> 00:05:49.880
システムはこれらの違いを明確に保持しているため 作業員が誤って倉庫から出してはいけないものを取り出すことはありません

00:05:49.880 --> 00:05:58.920
このマップがあればトラックが到着した際に作業員は何をスキャンすべきか判断でき ダイナミクス365がそれらの保管ルールに基づき次の作業を割り当てることができます

00:05:58.920 --> 00:06:08.160
配送トラックから適切な棚までの入荷作業です 配送はトラックが到着した時に始まるわけではありませんそれより前の購買発注から始まります

00:06:08.160 --> 00:06:14.000
購買発注はどの製品がいくつ通常いつ到着するのか サプライヤーから何を期待しているのかを企業に伝えます

00:06:14.000 --> 00:06:19.540
トラックがドックに到着すると倉庫チームは物理的な納品物と期待される記録を 称号できます

00:06:19.540 --> 00:06:27.540
あてもなく荷物を受け取る必要はありません 作業員は製品をスキャンするかパレットのライセンスプレートをスキャンして到着した数量を確認します

00:06:27.540 --> 00:06:32.560
サプライヤーが100ケースを送ったはずがトラックから98ケースしか下ろされなかった場合 その際は直ちに判明します

00:06:32.560 --> 00:06:39.040
シフト終了時に誰かがコンピュータにメモを入力するのを待つ必要はありません 企業は何が到着し何がまだ不足しているのかを把握できます

00:06:39.040 --> 00:06:44.860
受け入れ作業には数量チェック以上のことが求められる場合もあります 食品サプライヤーは検査が必要なバッチの製品を納品することがあります

00:06:44.860 --> 00:06:52.480
製造業では製造現場に届く前に承認が必要な部品を受け取ることがあります そのような場合ダイナミクス365は在庫検疫場所に送ることができます

00:06:52.480 --> 00:06:57.820
検疫とは商品は物理的に建物内に泊まるものの 作業員はそれらを通常の在庫として使用したり出荷したりできない状態を指します

00:06:57.820 --> 00:07:05.920
品質管理チームは製品を検査し承認拒否または問題の記録を行うことができます その決定が下されるまで倉庫システムは在庫通常の作業から隔離します

00:07:05.920 --> 00:07:12.760
これにより未承認のパレットが誤って顧客の注文に紛れ込むのを防ぐことができます 在庫の受け入れが完了したら保管場所が必要です

00:07:12.760 --> 00:07:20.380
このステップは棚入れと呼ばれます 作業員がパレットの保管場所を考えるのではなくモバイルデバイスが特定の場所へ誘導します

00:07:20.380 --> 00:07:27.420
パレットを受け入れドックからバルクラック 冷蔵保管ゾーンあるいは梱包エリア近くのピッキング場所へ運ぶよう指示します

00:07:27.420 --> 00:07:33.440
システムはロケーションディレクティブを通じてその選択を行います 専門的な名称に聞こえますが考え方はシンプルです

00:07:33.440 --> 00:07:38.420
ロケーションディレクティブとはこのアイテムは今どこへ行くべきかという問いに答えるルールセットのことです

00:07:38.420 --> 00:07:44.100
ルールは製品サイズ保管ニーズ倉庫ゾーンのスペース制限 そしてアイテムの用途に応じた場所を考慮します

00:07:44.100 --> 00:07:51.120
重量のある在庫は地上レベルのラックに配置される可能性があります 小型で回転の早いアイテムは作業員が注文をピッキングする場所に近い棚へ配置されます

00:07:51.120 --> 00:07:58.380
冷却が必要な在庫は承認された冷蔵保管場所にしか配置できません 作業員は複雑な倉庫のルール表ではなく明確な指示としてその結果を確認します

00:07:58.380 --> 00:08:03.860
ワークテンプレートは作業そのものを構成します ワークテンプレートはシステム内の反復可能なジョブカードだと考えてください

00:08:03.860 --> 00:08:06.740
サプライヤーからの納品に対しては2つのステップが作成されます

00:08:06.740 --> 00:08:15.240
ドックで在庫を受け取りルールによって選択された場所に棚入れするというステップです モバイルデバイスが各ステップを正しい順序で表示し各スキャンによってそのステップが完了したことが確認されます

00:08:15.240 --> 00:08:22.020
異なる人が異なるシフトで働く場合そのような一貫性が重要となります 新しいチームメンバーはすべての保管ルールを覚える必要はありません

00:08:22.020 --> 00:08:31.400
デバイスが適切なスキャンを求め次の作業を表示し移動を記録します 管理者は在庫がドックで待機中か保管場所に移動中かすでに割り当てられた場所にあるかを確認できます

00:08:31.400 --> 00:08:41.180
しかし保管エリアは新たな問題を生む可能性があります 多くの倉庫では大量の在庫をバルク保管場所に置き小さなピッキング場所には日々の注文に必要な分だけを置きます

00:08:41.180 --> 00:08:48.340
ピッキング場所の在庫が少なくなってきたら棚が空になる前に補充が必要です これが補充リプレニッシュメントです

00:08:48.340 --> 00:08:58.320
ダイナミクス365はバルク保管場所からピッキング場所へ在庫を移動する作業指示を作成できます これは注文を待ってから慌てて探すのではなく計画的な補充を行う仕組みです

00:08:58.320 --> 00:09:05.260
商品は仕入れ先への発注以外のルートでも入荷します 移動オーダーはある倉庫や拠点から別の場所へ在庫を移動させます

00:09:05.260 --> 00:09:13.340
製造オーダーにより完成した製品は工場での製造完了後保管場所へ入庫する必要があります いずれの場合も倉庫は同じ基本的なパターンに従います

00:09:13.340 --> 00:09:20.400
入荷品を確認し適切なルールを適用し正しい場所へ誘導します これで在庫は保管され確認され作業の準備が整いました

00:09:20.400 --> 00:09:25.800
しかしそれが報われるのは注文した顧客のために再びその在庫を見つけ出せた時だけです 次に追加すべき工程があります

00:09:25.800 --> 00:09:31.840
顧客注文からニズミドックまでの出荷作業です 顧客の注文が倉庫の出荷プロセスを開始します

00:09:31.840 --> 00:09:39.480
営業チームは顧客の希望必要数量出荷予定日を記録します その注文は在庫記録と同じ連携プラットフォームに入力されます

00:09:39.480 --> 00:09:46.580
そのため倉庫は別のメールリストを元に作業する必要がありません ピッキング開始前にビジネス上の判断でその注文のために在庫を確保することができます

00:09:46.580 --> 00:09:55.000
予約とはシステム上で特定の在庫を確保し他の注文が割り当てられないようにすることです もし在庫が10個しかなく一人の顧客がすでに10個すべてを注文していれば

00:09:55.000 --> 00:10:00.080
倉庫と営業チームはそれらが確保済みであることを確認できます これにより後で気まずい会話を交わす事態を避けられます

00:10:00.080 --> 00:10:07.700
注文には依然として物理的な作業が必要です 誰かが正しい場所へ歩いていき正しい品物を取り数量を確認し梱包してニズミドックまで運ぶ必要があります

00:10:07.700 --> 00:10:14.880
ダイナミクス365ウェアハウスマネジメントは顧客の注文をこれらのステップへと変換します 忙しい倉庫では注文を一つずつ処理することは稀です

00:10:14.880 --> 00:10:20.140
その代わりに倉庫はウェーブを作成できます ウェーブとはチームがまとめて処理したい注文を計画的にグループ化したものです

00:10:20.140 --> 00:10:25.760
すべての注文が同じトラックで出荷される場合などがあります あるいは配送日倉庫のゾーンまたは顧客の配送ルートが共通している場合などです

00:10:25.760 --> 00:10:31.880
システムは作業者がピッキングを始める前に作業をグループ化します ウェーブとは家を出る前に一連の用事を準備するようなものだと考えてください

00:10:31.880 --> 00:10:40.340
スーパーと薬局が同じルートにあるなら一度帰宅してからまた出かけるような非効率なことはしません 作業をまとめることで歩行時間を減らし注文処理の時間を増やすことができます

00:10:40.340 --> 00:10:46.260
倉庫でウェーブがリリースされるとシステムによって作業が作成されます その作業はセットアップ時に選択されたルールに従います

00:10:46.260 --> 00:10:53.460
最初にピッキングタスク次に梱包エリアへの移動タスク 最後に完成したで荷物を適切なドックドアに配置するタスクが作成されます

00:10:53.460 --> 00:11:01.260
作業者は長い紙のリストを読み解く代わりにハンドヘルドデバイスで次の行動を確認します デバイスはまずその場所をスキャンするよう作業者に指示できます

00:11:01.260 --> 00:11:06.280
これにより正しい棚や瓶に到達したことが確認されます 次に製品をスキャンし数量を確認します

00:11:06.280 --> 00:11:10.220
もし作業者が間違ったアイテムをスキャンしてもシステムは箱に入れる前に作業を停止させる ことができます

00:11:10.220 --> 00:11:17.040
こうした小さな確認が大きなミスを防ぎます 単純な注文であれば一人の作業者が顧客一人の全商品をピッキングして梱包へ運ぶこともあります

00:11:17.040 --> 00:11:25.100
しかし小さな注文が多い倉庫では代わりにクラスターピッキングが使われます クラスターピッキングでは一人の作業者が一度の移動で複数の注文文を収集できます

00:11:25.100 --> 00:11:29.060
作業者は異なる注文に紐付けられた個別の容器 トートを積んだカートを使用します

00:11:29.060 --> 00:11:37.460
商品を手に取るとデバイスがどのトートに入れるべきか指示を出します つまり通路を一度歩くだけで注文を混同させることなく複数の顧客注文を処理できるのです

00:11:37.460 --> 00:11:43.380
ピッキング後商品は梱包へと移動します 梱包では箱カートンパレットのそれぞれに何が入っているかを確認します

00:11:43.380 --> 00:11:51.480
倉庫では商品を格納する容器を記録しラベルを印刷して出荷準備を整えます 顧客が受け取るのは倉庫の作業指示書ではなく荷物であるためこのステップは重要です

00:11:51.480 --> 00:11:58.340
顧客は正しい中身と適切な配送詳細が記載された荷物を求めているからです 倉庫の棚に長く保管する必要のない商品もあります

00:11:58.340 --> 00:12:07.420
顧客がその日の朝にサプライヤーから届く商品を待っていると想像してください 入荷して在庫として保管し後で再びピッキングするのではなくクロスドッキングを利用できます

00:12:07.420 --> 00:12:15.300
クロスドッキングでは長期保管を挟まず入荷した在庫を直接出荷へと回します 取扱いが減ることで置き場所を間違えるリスクも少なくなります

00:12:15.300 --> 00:12:22.480
出荷物はその後ステージングエリアと積込ドッグへと運ばれます 倉庫で出荷作業が完了するとダイナミクス365が注文プロセス全体を更新します

00:12:22.480 --> 00:12:29.220
在庫状況がそれまでとは変わり利用可能数が更新されます 販売注文が進行し配送関連の作業で出荷詳細が利用可能になります

00:12:29.220 --> 00:12:37.020
単に箱が建物から運び出されるだけではありません 倉庫での動きは顧客との約束在庫記録そして注文を適切な車両に積み込むための次なるステップへと

00:12:37.020 --> 00:12:47.000
つながっていますしかし顧客からの注文は日々の倉庫業務の一部にすぎません 在庫は保管中も管理が必要だからです日々の管理移動棚卸しそして在庫の保護です

00:12:47.000 --> 00:12:54.340
在庫は棚に届いたからといってそのまま静止しているわけではありません ピッキングエリアの空きが必要な場合売れ筋商品を梱包エリアの近くに置く場合

00:12:54.340 --> 00:12:58.800
あるいは大きなパレットを一時保管エリアから移動させる場合など 倉庫では製品を移動させることがあります

00:12:58.800 --> 00:13:07.580
ダイナミクス365はこうした内部移動を記録するため移動の度にシステムと物理的な倉庫の 状態が一致し続けますその記録がなければシステム上には存在していても実際に必要とする

00:13:07.580 --> 00:13:14.340
作業者にとって商品は見つからない状態になってしまいます 棚卸しが重要なのも同じ理由です多くの人は棚卸しといえば通常の業務を停止し

00:13:14.340 --> 00:13:19.420
スタッフがすべての棚や箱を数える完全閉鎖をイメージします そうしたケースもありますが多くの倉庫では代わりにサイクルカウンティング

00:13:19.420 --> 00:13:25.160
循環棚卸しが採用されています 倉庫が稼働し続ける中で定期的に特定の場所や特定の製品をカウントします

00:13:25.160 --> 00:13:31.220
今週は特定の通路をカウントするかもしれません あるいは1日中入れ替わりが激しい売れ筋商品が頻繁にカウントされるかもしれません

00:13:31.220 --> 00:13:40.300
安価な梱包テープよりも高価な部品の方がチェックの頻度を高くする必要があるでしょう システムは棚卸し業務を作成し他の倉庫タスクと同様にモバイルデバイスへ送信できます

00:13:40.300 --> 00:13:47.700
作業者はその場所へ向かいスキャンを行い実際に確認できる数量を入力します ダイナミクス365がその数値と記録上の数量を称号します

00:13:47.700 --> 00:13:53.860
両方の数値が一致すれば棚卸しは完了です 数値が異なる場合誰かが在庫記録を変更する前に倉庫側で調査を行うことができます

00:13:53.860 --> 00:13:57.940
おそらくスキャンなしで何かが移動したのでしょう あるいはアイテムが間違った箱に入れられているのかもしれません

00:13:57.940 --> 00:14:01.840
前回のカウントに誤りがあった可能性もあります 際には説明が必要です

00:14:01.840 --> 00:14:06.980
未在庫数とシステム上のカウントが一致しない場合 承認された在庫調整によって記録を修正します

00:14:06.980 --> 00:14:14.320
この調整は企業が所有していると認識する内容を変えてしまうため管理が重要になります 適切な倉庫業務を怠るための近道にしてはなりません

00:14:14.320 --> 00:14:21.780
返品についても同様の注意が必要です 顧客が未開封の製品損傷したアイテムあるいはテストが必要なものを変装してくる場合があります

00:14:21.780 --> 00:14:30.740
倉庫側は返品を受け取りその状態を確認します 結果に応じて作業者は在庫に戻すか権益へ送るか再作業へ回すかあるいは使用可能な在庫から除外するかを判断します

00:14:30.740 --> 00:14:35.540
商品の状態が次の進むべき道を決めるのです 品質管理はこの作業に直結しています

00:14:35.540 --> 00:14:41.200
品質チェックにより仕入れ先からの配送返品または倉庫プロセスからの在庫を承認されるまで保留にすることができます

00:14:41.200 --> 00:14:47.540
これにより問題のある商品が通常の在庫の近くに置かれているという理由だけで 製造工程や顧客への出荷に紛れ込むのを防ぐことができます

00:14:47.540 --> 00:14:56.960
こうしたタスクはすべて作業現場で記録を行うことでより効率的に機能します 棚でのバーコードスキャンにより作業員が商品を扱うその場で品目場所コンテナ数量を記録できます

00:14:56.960 --> 00:15:04.240
後で記録しようとポケットに紙のメモをため込む必要はありません パレットが昼食前と昼食後のどちらに移動したか後から思い出そうとするような二度手間も発生しません

00:15:04.240 --> 00:15:15.880
スキャンがそのまま記録となりますそうしたスキャンを可能にするのがラベルです 倉庫では zpl ゼブラプログラミングランゲージと呼ばれるものを含め品目場所パレットコンテナ用のスキャン可能なラベルを印刷できます

00:15:15.880 --> 00:15:23.520
簡単に言えばシステムから対応するゼブラプリンターにラベルの指示を送ることで 作業員はスキャナーが認識できる id を作成できるということです

00:15:23.520 --> 00:15:33.300
明確なラベルは物理的な在庫にデジタル上の住所を与え移動棚卸し 返品品質チェックの際に重要となります現場でのすべてのアクションがオフィスと同じ記録を更新でき

00:15:33.300 --> 00:15:40.900
その連携が倉庫の精度を大きく向上させます 統合された一つのプラットフォームダイナミクス365の何が違うのでしょうか

00:15:40.900 --> 00:15:45.940
一部の倉庫システムはビジネスの他の部分から切り離されています あるシステムで誰かが発注書を入力します

00:15:45.940 --> 00:15:53.060
倉庫スタッフは別の場所で納品を追跡します あとから誰かが情報をコピーしたり両方の記録間の不一致を修正しようとしたりします

00:15:53.060 --> 00:16:02.800
それが遅延や重複作業を生みどの数値を信頼すべきかという議論を引き起こします ダイナミクス365の倉庫管理はダイナミクス365サプライチェーンマネジメントの中で機能します

00:16:02.800 --> 00:16:14.000
購買販売転送製造品質返品輸送のすべてが同じビジネス記録に接続できます 倉庫では物理的な作業が行われますがその作業は倉庫スタッフしか見られない隔離された場所で完結するわけではありません

00:16:14.000 --> 00:16:18.060
顧客からの注文が届いたと想像してみてください 販売部門がその注文を入力します

00:16:18.060 --> 00:16:25.260
倉庫部門がピッキング作業を作成し完了させます 出荷が進むと在庫記録が変更され同じビジネスイベントに従って財務処理を行うことができます

00:16:25.260 --> 00:16:32.640
商品が出荷されたことを経理部門に伝えるために完了した出荷情報を別のシステムに打ち直す必要はありません 各チームが同じストーリーの自分の担当部分を確認できます

00:16:32.640 --> 00:16:38.160
購買チームは予定された商品が到着したかどうかを確認できます 販売チームは注文が倉庫作業を経て進捗したかどうかを確認できます

00:16:38.160 --> 00:16:44.520
製造チームは材料及び完成品の記録を扱うことができます マネージャーは個別のツールからアップデートを収集する代わりに業務が滞っている場所を把握できます

00:16:44.520 --> 00:16:52.100
そのような共通のビューはしばしば信頼できる唯一の情報源と呼ばれます つまりオフィスチームと倉庫チームが同じ注文と同じ在庫状況を共有しているということです

00:16:52.100 --> 00:17:00.460
使用する画面や目的は異なっていても食い違った事実に基づいて作業を行うべきではありません パワー bi はその接続されたデータをレポート作成に活用できます

00:17:00.460 --> 00:17:05.240
マネージャーは注文の正確性フルフィルメント時間在庫レベル 倉庫の作業負荷などを追跡するかもしれません

00:17:05.240 --> 00:17:09.520
特定のエリアで定期的に遅延が発生する場合 データから問題の所在を突き止めることができます

00:17:09.520 --> 00:17:13.860
次に生じるのは実用的な疑問です ロケーションのレイアウトが移動距離を増やしていませんか

00:17:13.860 --> 00:17:17.880
特定のチームに負荷が集中していませんか ピッキングエリアで在庫切れが頻発していませんか

00:17:17.880 --> 00:17:25.260
システムが作業を記録するためマネージャーはパターンを分析できます 日々の指示の裏にはいくつかの設定項目がありこれらを正確に把握しておくことが重要です

00:17:25.260 --> 00:17:31.400
ロケーションディレクティブは在庫の移動元や移動先を決定します ワークテンプレートは作業者が完了すべき手順を構成します

00:17:31.400 --> 00:17:37.060
ウェーブは出荷作業のグループを適切なタイミングでリリースします それらのルールによって作業者のデバイスに表示される指示が生成されます

00:17:37.060 --> 00:17:43.740
つまり設定には最新の注意が必要だということです ロケーションルールが誤った場所を指せばスキャナーは作業者を忠実にそこへ誘導してしまいます

00:17:43.740 --> 00:17:49.000
作業手順が実際の倉庫運営と合致していなければ デバイスは効率かどころか逆に足枷となってしまいます

00:17:49.000 --> 00:17:57.360
システムは与えられたルールに従うだけです ルールが建物や製品そして現場の作業員と一致すれば個々のスキャンは単なるデバイスの警告音ではなく

00:17:57.360 --> 00:18:03.200
有益なビジネスイベントへと変わります まとめ倉庫現場のダイナミクスに関するデジタルガイド

00:18:03.200 --> 00:18:10.520
365ウェアハウスマネジメントは倉庫作業者にガイド付きのタスクを提供し 完了した各タスクはより広範なビジネス記録の一部となります

00:18:10.520 --> 00:18:16.480
この知識が在庫記録と倉庫作業の違いを明確にするのに役立ったならお好みの m 365 fm チャンネルを登録してください

00:18:16.480 --> 00:18:22.840
次のエピソードではダイナミクス365の在庫管理を取り上げ 企業が所有する資産と倉庫での保管場所を結びつける方法をご紹介します