製造業 ピッキング棚補充システム 導入を検討するとき、棚の在庫が減ったら通知する仕組みだけでは、欠品を防ぎきれません。予備在庫のどのロットを、誰が、いつ、どの棚へ運び、何を読み取って完了とするかまで決める必要があります。この記事では、タイの製造拠点を想定し、補充点の設定からWMSの作業指示、現物照合、例外対応、RFPとFAT/SATまでを一つの設計として整理します。数値例は説明用の仮定であり、特定製品の性能や費用を保証するものではありません。
まず定義する：ピッキング棚補充は何を完了させる業務か
ここでいうピッキング棚は、作業者が部品や副資材を取り出す手前の保管場所です。予備在庫は離れた倉庫や高段ラックにあります。補充は単に「倉庫から出した」時点では終わりません。予備棚で適格な現物を選び、搬送し、指定されたピッキング棚へ置き、数量・品目・ロットを照合し、システム上の移動を確定させて初めて完了します。その後にピッキングへ使用可能になる時刻も定義します。
OracleのWarehouse Management Cloudの説明は、補充を予備保管場所からピッキング場所への在庫移動と定義し、最小数量、最大容量比、現場スキャン、受注需要など複数の起動方法を区別しています。Oracleの補充仕様を参照しても、起動条件と作業完了条件は別に設計すべきだと分かります。Microsoftも、Min/Maxだけでなく需要連動、波次連動、即時補充を区別し、ピッキング場所を維持するための補充テンプレート、ロケーション指示、作業テンプレートを前提にしています。Microsoftの補充概要。
紙のカンバンや電子カンバンが補充の「知らせ」を担当する工場もあります。その場合でも、予備棚から現物が正しい棚へ着いたかを確定する作業は別です。電子カンバンシステムの導入設計は信号と上位システムの境界を扱っています。本稿は信号の後の実行管理、特に予備棚からピック面への移動と受領確認に焦点を当てます。
導入前に現場で測る6つの事実
システムの機能表より先に、代表品目と代表シフトで現物を測ります。第一に、品目ごとのピック面消費量を時刻別に見ます。日平均だけでは、始業直後や工程切替時の山が隠れます。第二に、棚が補充点を割ってから補充完了までの時間を、指示待ち、予備棚での探索、搬送、置場確認に分けます。第三に、ピック棚の物理容量、箱単位、積み付け制約を記録します。第四に、予備在庫の利用可能数量をロット、品質保留、引当済み、所在ごとに分けます。第五に、棚欠品、緊急搬送、誤置場、未確定移動の件数を測ります。第六に、夜勤、休日、通信断の運用を観察します。
例えば「一日の消費が120個、補充所要時間が30分」だけでは補充点を決められません。30分の中に工程切替による集中消費があるか、作業員が棚補充と通常ピッキングを兼務するか、品質保留ロットを除外すると利用可能在庫がいくつかで結果が変わります。導入前の測定表には品目・棚ID・時刻・開始在庫・消費・実補充数量・依頼時刻・搬送開始時刻・棚スキャン時刻・確定時刻・例外理由を残します。データが欠けた箇所は平均で埋めず、欠測として扱います。
| 測定項目 | 最小単位 | 設計で使う理由 |
|---|---|---|
| ピック面消費 | 品目×棚×時間帯 | 補充点と優先度の見直し |
| 補充リードタイム | 指示から棚確定まで | 欠品前に着くかの判定 |
| 棚容量 | 箱・個・容積 | 最大値と安全な置き方 |
| 適格予備在庫 | 品目×ロット×状態 | 指示が実行可能かの判定 |
| 例外 | 理由×発生工程 | 現場画面と復旧ルール |
予備棚とピック棚の在庫状態を分ける
補充の設計図には最低でも予備ロケーション、移動中、ピックロケーションの三つを描きます。ピック棚に到着していない箱を、先にピック可能として数えると、画面には在庫があるのに棚は空という状態になります。逆に予備棚から引いたまま移動中を管理しなければ、輸送途中の箱の所在が消えます。WMSでどの時点に在庫所有場所を変えるかは製品の仕様と運用に依存しますが、論理状態と現物位置がずれる期間を識別できることが必要です。
推奨するイベントは「補充候補生成」「タスク確定」「予備棚で現物取得」「移動中」「ピック棚への投入」「数量・ロット確定」「ピック可能」です。各イベントにタスクID、品目、ロット、数量、単位、元棚、先棚、操作者、端末、時刻、結果を付けます。再送しても同じ移動が二重計上されない識別子が必要です。作業者が数量を変更したときは元指示を上書きせず、指示数量、実績数量、差異理由を残します。
この境界が曖昧なままWMSを導入すると、棚卸し時に差異が見つかっても「補充が遅れた」「予備棚で不足した」「棚へ置いたが未確定」のどれかを判別できません。工程ラインへ供給する場合は、さらに「ピック棚から取り出し」「ラインに到着」「ラインで消費」の境界を分けます。補充システムに工程消費まで持たせるかは、MESとの役割分担で決めます。
Min/Max、発注点、需要連動をどう使い分けるか
最小値は補充を検討するトリガー、最大値は補充後に近づけたい棚量、発注点は調達・生産手配の判断点として混同しないでください。ピック棚のMin/Maxは庫内移動のルールです。購買の発注点は外部調達のリードタイムと安全在庫を含む別のルールです。名称が同じ「補充」でも、意思決定の対象と時間軸が異なります。
一般的な設計例では、ピック棚の利用可能数量がMinを下回ればタスク候補を作り、Maxと現在数量の差をベースに補充数量を計算します。ただし、未完了の補充タスク、既存引当、箱の入数、棚容量、ロット制約、作業時間帯を控除・調整しなければ過剰指示になります。SAP EWMは固定棚または保管タイプ単位で最小・最大量を設定し、計画補充、受注関連補充、自動補充、直接補充を区別しています。製品仕様をそのまま自社ルールとせず、候補生成、丸め、例外をRFPで確認します。SAP EWM補充制御。
需要連動は、計画変更や大口オーダーに対してMin/Max周期の隙間を埋めます。ただし同じ欠品に対して定時補充と需要補充が同時に作られるなら、未完了数量を差し引くルールが必要です。Microsoftの説明でも、需要補充が既存の未予約作業を利用する設定が示されています。製品ごとに実装が異なるため、RFPでは同一品目・同一棚への同時タスクをどう統合するかを実機で確かめます。
説明用の数量例：棚が20個を下回ったら何を指示するか
ここでは架空の部品Aを考えます。ピック棚のMinは20個、Maxは80個、箱入数は10個、現在の実棚数量は18個、未完了の補充指示は10個、予備棚の帳簿上の総数量は90個です。単純なMaxとの差は62個ですが、未完了10個を引くと新規候補は52個です。箱単位で切り下げる運用なら50個を新規指示し、全補充が正しく着けば18+10+50=78個となります。この計算は「未完了タスクが実行される」という仮定を明記して初めて成り立ちます。棚容量と箱入数を考慮して切り上げる設計では80個を超える可能性があるため、候補の丸め方は製品標準と現場規則を照合します。
| 条件 | 個数 | 扱い |
|---|---|---|
| 現在のピック棚実在庫 | 18 | Min 20未満で候補化 |
| 補充後の目標Max | 80 | 物理容量も確認 |
| 未完了の既存補充 | 10 | 二重指示を避けるため控除 |
| 新規の理論候補 | 52 | 80−18−10 |
| 箱10個単位の新規指示 | 50 | 切り下げを仮定 |
| 両タスク完了後の棚数量 | 78 | 18+10+50 |
ここで予備棚の総数量90個のうち40個が品質保留なら、利用可能なのは50個です。新規指示50個を完了できても、既存タスク10個の供給元まで同じ90個を見込んでいるなら、合わせて60個を確保できません。指示作成時に適格な予備在庫を予約するか、完了まで競合を許容して不足を例外にするかを決めます。WMSが「棚に移せる50個」と「引当可能な50個」を別の意味で使う可能性もあります。数量例をRFPに記載し、実画面でどう計算するかを確認してください。
WMSタスクは「誰が何をどこへ」を運用できる形にする
良い補充タスクには、タスクID、優先度、元ロケーション、先ロケーション、品目、ロット条件、数量と単位、容器・ラベル、期限、担当者または作業プール、状態、例外コードが必要です。Oracle WMS Cloudでは補充とピッキングを異なるタスク種別として扱い、タスクに担当、保留、解放、取消、優先度を設定できます。Oracleのタスク実行説明。ただし、採用する製品が同じ状態と権限を持つとは限らないので、候補製品で実演を求めます。
補充と通常ピッキングが同じ作業員・同じ通路を使うと、優先度が業務上の競合になります。「欠品寸前」を最優先にして全員を緊急補充へ回すと、出荷やライン供給の別の締切を失うことがあります。優先度は残量だけでなく、次の必要時刻、補充所要時間、影響するオーダー、代替棚の有無、供給可能な予備在庫で決めます。監督者が手動で変更したときは、その理由と変更履歴を残します。
タスク状態は少なくとも未割当、割当済、取得中、移動中、棚投入待ち、完了、保留、取消を区別します。「作業開始」と「在庫移動確定」を同じボタンにすると、途中で端末が故障した際の現物照合が難しくなります。通信が切れた場合、端末に未送信実績を保存できるか、再送時に重複するか、別端末が同じタスクを引き取れるかを試験します。端末の画面には、次にスキャンする対象を一つずつ明示し、棚番号を記憶に頼らせない設計が有効です。
スキャン確定の順序：予備棚、容器、先棚、数量
現物誤りを減らすため、まず予備棚のラベルと現物容器を読み、タスクで指定された品目・ロット・状態と照合します。次に移動後、先棚ラベルを読み、容器または品目を再確認し、実投入数量を入力・確定します。全項目を一度だけスキャンすればよいとは限りません。元棚での取り違えと先棚での置き間違いは異なる誤りなので、二つの場所の確認を分けるべきです。
バーコードの表現は現場のラベル仕様と一致させます。GS1は商品や場所の識別と、ロット番号・日付等の属性をバーコードで扱う標準を示しています。GS1バーコード標準。ただし、GS1の識別体系を採用していない社内ラベルに後からGS1コードを仮定してはいけません。既存ラベル、端末読取性能、汚れや擦れ、梱包単位の変更を実物で確認します。ロットが複数ある箱を一つのバーコードで代表させる運用は、ロット追跡に必要な粒度を満たすか別途検証します。
部分補充が許される場合は、指示50個に対して40個だけ置いたときの扱いを決めます。40個を完了、残り10個を再タスクにするのか、タスクを継続して別ロットを追加するのか。後者を許すなら、ロット別実績と先棚の混載条件が必要です。スキャンをせずに監督者が手入力で完了させる権限を残す場合は、理由と承認者を監査ログに残します。スキャンは「入力手段」ですが、何を照合し何を例外として止めるかが統制の中身です。
欠品と補充不能を同じ例外にしない
ピック棚が空でも、予備在庫があるなら補充遅延です。予備在庫が品質保留なら利用可能在庫不足です。予備棚の帳簿にはあるが現物がないなら棚差異です。先棚に別品目が入っていて置けないならロケーション異常です。同じ「欠品」画面にまとめると、担当者が適切な処置を選べません。例外コード、一次対応者、エスカレーション先、暫定運用、解消条件を分けます。
| 例外 | 現場で止める条件 | 一次処置 | 解消の証拠 |
|---|---|---|---|
| 予備棚の現物不足 | 指定数量を取得できない | 実数を数え、在庫差異を起票 | 棚卸しと差異承認 |
| ロット・品質不適格 | 保留・期限・先入順に違反 | 別ロット候補を確認 | 承認されたロットと履歴 |
| 先棚の容量不足 | 指定箱が安全に置けない | Maxと棚配置を見直す | 棚写真または現場確認 |
| 誤棚・誤品 | ラベルがタスクと一致しない | 置かずに保留する | 再スキャンと修正記録 |
| 端末・ネットワーク障害 | 確定が返らない | 現物を識別して一時保管 | 再送・照合・重複排除ログ |
Oracleは、補充待ちに依存するピッキングタスクを補充完了まで保留する設定を説明しています。補充依存ピッキングの保留・解放。このような連動を採用するなら、「補充が物理的に終わったが通信断で未確定」のときにピッキングを解放してよいか、現物確認の代替手順まで決めます。安易な自動解放は誤出荷につながり、無期限保留は操業を止めます。
FIFO・ロット・品質状態を補充の時点で守る
補充では「どのロットを先棚へ持っていくか」が後続ピッキングの選択肢を決めます。倉庫でFIFOを使っていても、ピック棚に新旧ロットを無秩序に積むと、現場で古いロットから取れないことがあります。期限品ならFEFOの適用が必要な場合もあります。ロット選択の順序、混載可否、棚内の手前・奥の置き方、残ロットの扱いを設計します。品質保留やリコール対象ロットは、候補から除外するだけでなく、既にピック棚にある在庫を隔離できる必要があります。
GS1のトレーサビリティ標準は、品目IDとロットID、物流単位IDの関係を記録して追跡する考え方を示しています。GS1 Global Traceability Standard。補充イベントで元容器、ロット、先棚、数量をつなげれば、出荷・ライン投入後の追跡範囲を説明しやすくなります。ただし、GS1を引用しただけでは自社システムの追跡性能は証明されません。返品、詰替え、容器分割、混載の試験データで、後からロットを引けるか検証します。
ERP・WMS・MESの正本と同期範囲を決める
一つの構成例は、ERPを調達・原価・会計・品目基本情報の正本、WMSを棚別在庫と補充タスクの正本、MESを製造指示と工程消費の正本にするものです。ただし実際にはERPの倉庫機能がWMS役を担う場合もあります。名称よりもイベントごとの責任を決めてください。特に「在庫をいつ減らすか」「品質保留を誰が解放するか」「工程へ渡した数量がいつ消費になるか」を一つの表にします。
補充タスクには指示と実績の相関IDが必要です。通信断中に端末が実績を再送しても二重移動しないこと、取消済みタスクの遅延メッセージを反映しないこと、ERPとWMSの単位換算が一致することを確認します。例えば箱10個を「1ケース」と表示する場合、実棚でバラ2個を足した数量をケース単位に丸めて記録してはいけません。ロット属性や品質状態が片方のシステムだけで変わった場合の同期遅延も監視対象です。既存のピッキングシステム選定の記事で扱うDPS/DASや表示機器は作業を案内しますが、棚別在庫の正本と補充完了の判定は別途決める必要があります。
RFPに入れるべき機能ではなくシナリオ
「Min/Max対応」「ハンディ対応」というチェック欄だけでは製品差が見えません。RFPには、自社の棚構成と数量を示したシナリオを入れ、各社に同じ入力データで画面・計算・ログを実演してもらいます。たとえば、部品Aのピック棚18個、Min20、Max80、箱10、既存タスク10、適格予備在庫50という条件で、新規候補が何個になり、誰が承認し、どのロットを選ぶかを示してもらいます。標準機能、設定、カスタマイズ、手作業を区別して回答を求めます。
| RFPシナリオ | 見せてもらう結果 | 合否で重視する点 |
|---|---|---|
| 同時トリガー | 定時補充と需要補充を同時に起動 | 未完了タスクの二重計上防止 |
| 品質保留 | 予備棚に保留ロットのみ存在 | 誤指示を作らず理由を示す |
| 部分補充 | 指示50に対し40だけ投入 | 差異と残タスクの追跡 |
| 誤棚スキャン | 隣の棚のコードを読む | 完了を止めて修正経路を示す |
| オフライン復旧 | 投入直後に通信断、再送 | 二重移動なしに状態を照合 |
| ロット回収 | 対象ロットを使用不可へ変更 | ピック棚の残量と履歴を抽出 |
製品比較ではライセンス費だけでなく、棚・品目マスタの整備、ラベル、端末、無線、連携、教育、保守、現場停止時間を見積項目に分けます。提供会社へは、導入後に自社で変更できる設定と、ベンダー作業を要する変更を明示してもらいます。タイ語・英語・日本語の画面、現地サポート時間、端末故障時の代替運用も確認します。
FATとSATで「補充できた」をどう証明するか
FATはベンダー環境でルールと例外を試験し、SATは実際の棚、端末、無線、作業シフトで運用できるか確認します。両者の試験データは接続します。FATで成功した同じ数量例をSATの現場棚へ持ち込み、棚容量やラベル読取で条件が変わったら差分を記録します。試験は正常な一往復だけでなく、上表の誤棚、部分補充、ロット保留、端末再送、タスク競合を含めます。
合格条件は「画面で完了と出た」だけでは不足です。予備棚の残量、移動中残量、ピック棚の現物、WMSの数量、ERPとの必要な連携、監査ログが一致することを確認します。棚へ置く前に先棚在庫が増えないこと、投入後にスキャンを取り消した場合の逆仕訳や例外が説明できること、同じタスクIDの再送で数量が再加算されないことも必要です。FAT/SATの責任者、試験証跡、失敗時の再試験条件、運用移行の判定者を決めます。
段階導入は品目数ではなく例外の代表性で区切る
初回から全棚を切り替えると、補充点の設定値と現場作業の差が大量に出ます。まず、箱単位の高頻度品、バラ品、ロット管理品、品質保留がある品、複数ピック棚を持つ品など、振る舞いが異なる代表群を選びます。一つのエリアと一つのシフトで補充タスクの起動から確定までを通し、例外の処理時間を測ります。安定したら夜勤や別工程へ広げます。単に品目数を増やすより、例外類型を先に覆う方が再設計を減らせます。
導入前後の比較指標は、ピック棚起因の欠品回数、補充依頼から棚確定までの時間、緊急補充率、誤棚・誤ロット率、棚差異、未完了タスク滞留時間です。欠品が減った代わりに過剰在庫が増えていないかも見ます。改善率を記事の一般値として置くことはできません。初期値と測定期間、品目構成、シフトをそろえ、自社の変化として評価します。季節性や生産計画変更があれば注記します。
補充点の見直しを日々の管理作業にする
MinとMaxは導入時に一度登録して終わる値ではありません。生産計画、部品の箱入数、棚の配置、搬送ルート、作業員配置が変われば、同じ棚でも補充の到着時間は変わります。毎週または品目の変更時に、補充指示が出た時刻、実際の棚残量、到着時刻、欠品時刻を見比べます。Min到達から欠品までの残り時間が、通常の補充リードタイムを下回るなら、Minの引き上げ、定時補充の時刻変更、予備在庫の配置変更を検討します。Maxを上げる前に、棚の物理容量と通路安全、古いロットが奥に残るリスクも確認します。
見直しの責任者は品目マスタ担当だけでなく、倉庫現場、製造、品質を含めます。設定変更申請には旧値・新値・理由・想定される一日のタスク件数・棚容量確認・承認者・適用時刻を残します。複数拠点で同じ品目コードを使っても、ピック棚の容量や補充リードタイムは拠点ごとに違います。全拠点へ一括でMin/Maxを配る場合は、上書きできる拠点別値と共通値を区別してください。廃番品は定時補充を止め、移行期間の残在庫を別に扱います。
管理画面には「候補生成数」だけでなく、補充完了までの滞留、予備在庫不足で却下された候補、欠品発生後に完了したタスク、誤棚スキャン、手入力による完了を出します。すべての指標を一つの改善率にまとめる必要はありません。欠品が少なくても緊急作業が多いなら設定に余裕がない可能性があり、タスクが増えすぎればピッキング時間を圧迫します。数字の読み方と現場の制約を一緒にレビューします。
マスタ、ラベル、端末を稼働前に整える
補充の自動化はマスタの正しさに依存します。品目IDと別名、箱入数と最小単位、ロット管理要否、品質状態、予備棚とピック棚の許容組合せ、棚容量、補充単位、代替品の扱いを揃えます。棚ラベルは、作業者が遠目で読める表記と端末で読めるコードの両方を持たせます。似た棚番や上下段が連続する場所では、印字の位置とコードの向きまで現場で確認します。ラベルを貼ってもスキャンできない高さなら、手入力が常態化します。
端末は画面言語と通信だけで選ばず、手袋着用、照明、粉じん、振動、充電、落下、オフライン時の表示を確認します。作業者が箱を抱えたまま二つの棚をスキャンするなら、端末の持ち方と安全な仮置き場所を試します。共有端末のログイン切替が遅いと作業者IDが誤って記録されます。シフト交代、端末の貸出・返却、故障端末の隔離、アプリ更新時のロールバックまで運用手順に含めます。ネットワーク接続が必要な棚では、稼働時間帯に実機で電波を測ります。
ピッキングと補充の干渉を現場レイアウトで解く
同じ通路をピッキング作業者と補充カートが同時に使うと、ソフトウェアで優先度を整えても物理的に滞留します。棚の片側から補充し反対側でピックできるか、補充をピック前の時間帯に寄せられるか、短い通路では一方通行にできるかを確認します。箱の一時置きが避難経路をふさがないこと、フォークリフトと歩行者の交差が増えないことも重要です。これはシステム画面の設定だけでは解決できません。
物理レイアウトを変更できない場合は、少なくともタスクの作業窓と通路単位の割当を定義します。補充のためにピッキングを止める判断を誰が行うか、止めたオーダーはどう再開するかを明確にします。長い搬送を一人に割り当てると緊急タスクへの対応が遅れるため、予備棚から中継点、ピック棚から最終確認と工程を分けることも検討します。ただし工程を分割すると、移動中の所有者と容器の識別が増えるので、監査ログと現物置場をセットで設計します。
稼働切替と初期運用の照合をどう進めるか
本番切替の前日には、移行対象の棚について「最後に信頼できる現物数量」を確定します。WMS上の予備棚、移動中、ピック棚の数量を一覧にし、現物と照合します。既存の紙指示やExcelで進行中の補充があれば、タスクIDに相当する移行管理番号を付け、切替前に完了させるか、新システムへ引き継ぐかを一件ずつ決めます。移動中の箱を予備棚とピック棚の両方へ計上してしまうと、稼働初日から原因の分からない差異が生まれます。切替時刻をまたぐ作業は原則として止めるか、箱の保管場所と担当者を明示した引継票で管理します。
マスタ移行の対象には、品目と棚の対応だけでなく、ロット、単位換算、箱入数、品質状態、棚の上限、補充Min/Max、旧システムで未完了の作業が含まれます。複数の品目コードが同じ現物を指す場合や、旧コードを後工程だけで使う場合は、変換表を承認してから読み込みます。読み込み件数が合うだけでは十分ではありません。代表品目を選び、旧システムの残量、現物、移行後のピック可能数量を突き合わせます。品質保留品が移行後に通常在庫へ変わっていないか、ロットの先入順が崩れていないかも確認します。
切替当日の最初の補充は、担当者がタスク生成、元棚スキャン、搬送、先棚スキャン、数量確定を横で見ながら通します。現場に「画面が完了と表示した箱」と「棚に実在する箱」の差がないことをその場で確認します。タスクを一括で大量生成する前に、同一棚の重複指示、予備在庫の競合、端末のログイン、無線の弱い場所を確認します。初日だけ例外処理を現場判断で飛ばすと、後から原因を追えません。特例を認める場合でも、承認者、理由、箱ID、棚ID、事後照合の期限を記録します。
稼働後の数日は、シフト終了時に三つの残量を照合します。第一は予備棚から引いた数量、第二は移動中として残る数量、第三はピック棚へ確定した数量です。作業者の申告とシステム数量が違えば、その日のタスク履歴とスキャン時刻から追い、翌日まで差異を持ち越す条件を決めます。利用可能な予備在庫が尽きた場合は、誤って補充タスクを作り続けるのではなく、計画担当と購買・製造へ不足を通知します。欠品の根本原因が調達遅延なら、補充点を上げても現物は増えません。
ロールバック条件も先に決めます。たとえば端末で完了した補充がWMSに反映されない、同じ箱が二重に棚在庫へ加算される、品質保留ロットがピック可能になる、といった事象は安全な運用継続の妨げになります。単に旧画面へ戻すだけでは、切替後に動かした箱の所在が消えます。切替後のタスクを凍結し、現物を数え、差異を承認してから旧運用へ戻すか修復して再開します。停止の判断者、連絡先、現場で使う紙の記録様式、復旧の合格条件をSATの一部として試しておきます。
初期運用のレビューでは、欠品ゼロだけを成功条件にしないでください。欠品を抑えるためにMaxを過大にし、通路へ箱を置き、古いロットが奥に滞留している可能性があります。棚あたりの平均在庫、緊急補充率、補充リードタイムのばらつき、手入力確定率、品質保留の誤候補、シフト間の未完了タスクを併せて見ます。設定値を変えた後は変更日を残し、変更前後で品目構成や生産計画が同じか確認します。改善の数字は顧客固有の実測結果として扱い、一般的な効果として外部へ転用しません。
よくある質問
ピッキング棚補充システムとWMSは同じですか？
補充はWMSに含まれることが多い業務機能です。ただし、WMS導入済みでも補充点、タスク、スキャン、例外、ロットが現場に合わせて設定されていなければ棚欠品は残ります。専用システムを追加するか、既存WMSの設定を直すかは、正本の場所と必要な変更範囲で判断します。
Min/Maxだけで欠品を防げますか？
定時のMin/Maxだけでは、急な需要、補充の遅れ、品質保留、予備棚の現物差異に対応できません。需要連動トリガー、優先度、適格在庫確認、未完了タスクの控除、例外対応を組み合わせます。設定値は消費実績とリードタイムを見て定期的に見直します。
電子カンバンと補充システムはどう分担しますか？
電子カンバンが消費や空容器を検知して補充要求を出す場合、WMSなどが供給元とロットを決めてタスク化し、現物取得と先棚投入を確定する構成が考えられます。どちらがタスクID、数量、取消、再送の正本を持つかを決め、同じ要求から二つの指示が生まれないようにします。
導入費用を見積もる前に何を準備しますか？
対象棚、品目、箱入数、ロット条件、時間帯別消費、現場リードタイム、端末・ラベル・無線、ERP/MES連携、例外シナリオを用意します。RFPに代表数量例とFAT/SATの合格条件を入れ、各社の標準機能・設定・開発作業を分けて比較します。実測が無い項目は仮定として明記します。
まとめ
製造業のピッキング棚補充システムは、Min/Maxの通知器ではなく、予備棚の適格在庫を選び、作業を割り当て、元棚と先棚で現物を確認し、移動とロットを記録し、欠品や通信断から復旧する仕組みとして設計します。導入の判断は、代表品目の実測、数量例を使ったRFP、例外まで含むFAT/SATで行います。ピック棚へ確実に着いた時点を定義することが、在庫画面と現物を合わせる第一歩です。
タイ工場で予備棚からピッキング棚への補充を見直す段階なら、棚構成と現行の補充記録を持ち寄ってお問い合わせください。Min/Max、WMSタスク、スキャン、ロット、FAT/SATの検討範囲を一緒に整理できます。
