製造業の倉庫ロケーション移動管理システム導入ガイド

製造業の倉庫で「物は棚を移ったのに、システム上は元の棚にある」というずれが起きると、探す時間だけでなく、ロット追跡、引当、出荷、生産への供給にも影響する。倉庫ロケーション移動管理システムを導入するなら、ハンディ端末を配る前に、何を一件の移動とみなし、誰がどの状態の在庫を動かせるかを決めたい。本稿はタイの製造拠点を想定し、倉庫内の棚から棚への移動を中心に、現場手順、ERP・WMS・MESの境界、RFP、FAT・SATの確認項目を整理する。

まず「ロケーション移動」の業務範囲を決める

この記事で扱うロケーション移動は、同じ倉庫の保管場所Aから保管場所Bへ、実在庫を移し、その履歴と現在地を在庫台帳へ反映する業務だ。購買品の入荷登録、販売品の出荷確定、工場間移送、棚卸差異調整とは起点も証跡も異なる。たとえば入荷待ちパレットを受入エリアから検査待ちエリアへ動かす、空きを作るために保管棚を集約する、出荷ドックの変更に合わせて仮置き場所を変える、といった作業が対象になる。Microsoftの倉庫管理資料にも、この三つに近い移動場面が例示されている。ただし、それは特定製品の説明であり、どのWMSでも同じ制御が使えるという意味ではない。導入時には自社の実物とシステム上の単位を突き合わせる必要がある。Microsoft: 予約を伴う在庫移動

倉庫移動は、前日のテーマであるピッキング棚への補充と重なるように見える。しかし、ピッキング棚補充の設計は需要や補充点を起点に「どこへ何を補うか」を決める運用が中心だ。本稿の主題は、補充以外も含む棚間移動の実行記録である。現場裁量で置き場を変える場合、品質判定後に隔離棚から合格棚へ移す場合、既存の移動指示を処理する場合では、承認と在庫引当の扱いが異なる。記事とシステム要件の境界をここで明確にしておく。

移動の単位は「品目だけ」では足りない

最小記録を「品目番号、数量、移動元、移動先」と決めてしまうと、同じ品目の異なるロットやパレットが混在した途端に追跡が切れる。現場の保管形態に応じて、倉庫、ロケーション、品目、ロット、シリアル、在庫ステータス、荷姿単位、ライセンスプレート（以下LP）、単位、数量を取引の識別要素として検討する。すべての品目で全項目を毎回入力させるのではない。ロット管理品ならロット、個体管理品ならシリアル、パレット運用ならLPを必須にする、といったマスタ連動の入力制御にする。数量だけを変えたのか、保管場所だけを変えたのか、品質ステータスも変えたのかも区別しなければ、後で帳票を見た人が移動理由を誤解する。

例えば同一品目AのロットL1とL2が同じ棚にあるとき、「Aを10個移動」とだけ記録しても、どちらのロットがどこにあるか分からない。ロット追跡が必要な工場では、移動行をロットごとに分け、移動後の残量も照合する。LPが複数の品目・ロットを積んだ混載パレットなら、LP全体を移すのか、その一部だけを分割するのかを明記する。Microsoftの移動メニュー設定には、全LP移動時の確認省略や、部分移動時に新しいLPが必要となる条件が示されている。これは候補製品に問うべき挙動の例であり、無条件に省略すべきだという推奨ではない。Microsoft: 手動移動メニュー

移動の理由と指示の作り方を三つに分ける

第一は現場起点の臨時移動だ。破損した棚を空ける、通路を確保する、荷崩れしたパレットを安全な場所に置き直す、といった状況では作業者や班長が移動を提案する。ただし「好きな棚へ自由に移す」権限を全員に与えると、容量超過や混載禁止、先入先出の逸脱が生じる。許可エリア、許可理由、役割、必要な承認を定義した上で、端末が移動元と移動先を確認する方式がよい。Microsoftの手動移動メニューでは、作業者が何をどこへ移すか決める構成が説明されている。Microsoft: 手動移動メニュー

第二はシステム指示の移動だ。品質検査完了後に合格品を通常棚へ入れる、危険品を指定区画へ移す、保管棚の容量・温度帯に応じて行先を決める場合には、候補棚をルールで提示し、作業者が実際の棚をスキャンして完了させる。Microsoftの「Movement by template」では、移動先を作業者の自由選択ではなく、作業テンプレートやロケーション指示で決める設計が記載されている。候補システムの提案を比べる際は、ロケーション候補の算出条件、代替棚の許容、満杯時の例外処理まで確認する。Microsoft: テンプレート移動

第三は既存の作業指示に紐付く移動だ。出荷用に確保されたパレットを別の出荷口へ動かす場合、保管場所だけを直すと、引当やピッキング作業の参照先が古いまま残り得る。Microsoftの資料では、予約済在庫を動かせる作業者の権限制御と、作業行の分割を避ける制約が示される。また同資料の対象条件では、予約を伴う移動は臨時移動に限られ、テンプレート移動では扱えないとされる。製品や版によって挙動は変わり得るため、候補製品ごとに実機で確認する。Microsoft: 予約を伴う在庫移動

スキャン順序は「取りに行く棚」と「置いた棚」を現物で閉じる

端末の基本画面は、指示番号または移動理由の選択から始まり、移動元ロケーション、LPまたは容器、品目、ロット・シリアル、数量、移動先ロケーションの順に確認する設計を基準に考える。実際の順番は、棚ラベルが先に見えるか、パレットラベルが先に見えるか、両手がふさがる工程かによって最適化する。重要なのは、画面に入力済みの値を見ただけで完了できないことだ。少なくとも「取った場所」と「置いた場所」が現場のラベルと一致した証拠を残す。移動先を候補から選ぶ場合も、到着時に実棚を読み取る。ネットワーク断で後送する場合は、いつ現物移動が起き、いつ台帳に反映されたかを別時刻として残す。

スキャンには読み間違いだけでなく、意味の取り違えがある。同じ数列でも品目コード、LP、棚ID、GS1識別子では意味が違う。ラベルの設計では、人が読める短い位置名と、機械が識別する一意のコードを対応させる。GS1はGLNを物理場所の識別に使う場合、ロケーション標示にAI (414)を用いると説明している。一方、AI (410)は配送先を意味する。自社棚コードを採用するかGLNを採用するかは取引先連携やラベル運用で決めればよく、「GLNなら棚番管理が自動で完成する」という話ではない。GS1: GLNで物理場所を識別

物流ラベルを外部と共通化する場合は、パレットなどの物流単位を識別するSSCCと、社内で使うLPの対応も定義したい。GS1物流ラベルのガイドラインは、物流単位の識別とラベル表示の基準を示す。社内LPを必ずSSCCに置き換える必要はないが、入出荷で二つの番号を混同すると、棚間移動履歴と取引先への出荷情報がつながらない。RFPには「入荷時に外部ラベルを読み、社内LPへどう紐付けるか」を書く。GS1物流ラベルガイドライン

確認機能を過信しない

「バーコード確認あり」と書かれた製品でも、すべての移動画面、すべての属性に確認が働くとは限らない。Microsoftの確認機能説明では、ロット、シリアル、LP、ロケーションの確認が適用される作業型に条件がある。また、手動移動でロケーションを自分で入力した場合、メニューで確認を有効にしていても同じ確認手順は実行されないという記述がある。したがってRFPでは「確認できる」とだけ求めず、どの画面で、誰が、何を、いつ再スキャンするかまでテストケースで指定する。Microsoft: ロット・LP・ロケーション確認

在庫の引当、品質ステータス、禁止棚を先に決める

一見空いている棚でも、危険品の混載禁止、温度帯、重量、寸法、顧客預かり品、先入先出の単位などで置けない場合がある。移動を登録する時点で「移動元に十分な実在庫があるか」「移動先は当該品目とステータスを受け入れられるか」「移動中に他の作業が同じ在庫を消費しないか」を照合する。設計上は、現在量、予約量、移動中量、利用可能量の意味を統一する。紙帳票から移行する際に、在庫数だけ合わせて予約の意味を曖昧にすると、出荷用に確保した物を臨時移動で探せなくなる。

品質ステータスは物理場所と別軸にする。検査待ち棚から合格棚への移動と、検査待ちから合格への状態変更が同時に起きるなら、二つのイベントを一つの画面で登録しても履歴上は区別できるようにする。逆に保管棚が変わっただけで品質ステータスまで自動で合格になる設計は危険だ。品目によっては隔離棚への移動を即時に可能にし、合格棚への戻しは品質担当者の承認が必要となる。権限は「移動作成」「実行」「例外承認」「取消」「在庫調整」を分ける。承認前の物を動かせるか、動かせるなら利用可能在庫に算入するかも明文化する。

現場でよく起きる競合は、二人が同じLPを別の目的で扱う場合だ。片方が移動元をスキャンし、もう片方が出荷指示を処理した後、先の端末で移動を完了すると、古い残量で台帳を更新してしまう恐れがある。取引開始時と確定時に在庫版数または残量を再検証し、競合時は片方を中止して現物を再確認する。これは特定製品の標準機能という主張ではなく、導入時に必要となるデータ整合性の要件である。オフライン端末を許す場合には、この競合が発生しやすい時間が長くなるため、許可範囲と再同期時の処理をFATで検証する。

「移動中」の所在を見失わないための状態設計

棚Aから棚Bへ運ぶのに数分かかる場合、取出時にAから減らしてBに増やすと、まだ運搬中の在庫がBにあるように見える。完了時にだけ更新すると、運搬中もAにあるように見える。どちらがよいかは作業時間と他業務への影響で決める。移動タスクに「未着手、取出済、移動中、格納済、取消済、例外」を持ち、現在地をA・搬送中・Bのいずれかで説明できるようにする方法がある。短距離の棚間移動で一括確定する設計でも、作業途中で端末が落ちたときに未確定取引を探せる必要がある。

状態遷移には締め切りと復旧責任も必要だ。「移動中」が夜勤をまたいで残った場合、誰が現物を確認し、タスクを完了または戻すか。出荷指示が先に進んでいる場合に、在庫の参照を止めるか。中断取引を管理者が強制完了するとき、理由と承認者をどう残すか。画面上の色だけで運用を決めず、一覧、通知、監査ログ、日次差異の確認まで含めて設計する。棚卸や現品照合の流れは仕掛品の実在庫管理ともつながるが、棚間移動ではイベント単位の所在確定を先に整える。

取消は「履歴を消す」操作ではない

移動元を誤読した、移動先の棚を間違えた、数量を多く登録した。こうした誤りは必ず起きる。運用上の取消には、まだ現物を動かしていない取引の破棄、移動中の取引の中止、完了済み移動の逆移動、在庫差異調整という異なる手段がある。完了済みの移動行を削除または上書きすると、監査時に「いつどこにあったか」が再現できない。逆移動なら元の取引IDへの参照、実行者、理由、承認、時刻を残す。物が既に別作業へ引き当てられているなら、単純な逆移動を禁止し、現物確認と再計画を求める。

同じバーコードを連続で二度読んだ場合の二重登録も見逃せない。端末からの送信には一意の操作IDを付け、通信再送でも同じ移動を二回計上しない設計が必要だ。日付だけでは重複判定できない。数量訂正も、元の10個を12個に上書きするのか、差分2個の追加入力にするのか、承認境界を決める。実物を戻していないのにシステムだけ逆移動することは避ける。端末は「物理的に戻しましたか」を問うだけでなく、戻し先ラベルを再スキャンして証跡を取るべきだ。

例外を通常作業へ混ぜない

棚ラベルが破れて読めない、指定棚が満杯、LPラベルが剥がれた、ロット表示が不鮮明、受入後に検査結果が変わった。このような例外は手入力で無理やり通すより、現場に分かる停止状態と代替手順を用意する。棚ラベルの再発行はロケーションマスタの照合後に行う。LPラベル再発行は既存LPへの紐付けと新規LP発番を区別する。品質判定の変更は棚間移動とは別の承認を要する。例外理由を選択式で記録し、自由記述も補足として残す。現場の停止時間を測れば、マスタ不備なのか、ラベル品質なのか、ネットワークなのかを改善対象として分けられる。

ERP・WMS・MESの境界を「台帳の正本」で決める

ERPは購買、販売、原価、全社の在庫評価と結び付く。WMSは倉庫内の棚、LP、作業タスク、スキャン履歴を細かく扱う。MESは製造指示、工程への投入、実績、仕掛品の状態を扱う場合が多い。ただし製品名だけで責任を決められない。単一ERPの倉庫モジュールを使う企業もあれば、独立WMSが棚別在庫の正本で、ERPへ集計結果を送る企業もある。導入前に「品目・ロット・倉庫・棚・LP・品質ステータス・予約・原価のそれぞれの正本はどこか」を一枚の表にする。

棚Aから棚Bへの単純な同一倉庫移動は、原価や所有者が変わらないならWMS内で完結し、ERPへ詳細または集計イベントを送る形が考えられる。ただしERP側も棚別残量を保持するなら双方更新が必要だ。一方、倉庫をまたぐ移送、品質区分の変更、材料を製造工程へ払い出す操作は、財務・生産の意味が変わることがある。これらを同じ「棚移動」ボタンに押し込むと、帳簿差異の原因になる。インターフェース仕様にはイベントの発生条件、受信側の確認応答、再送、順序保証、失敗時の保留、取り消し・逆仕訳との関係を書く。

設備が材料箱を自動搬送する場合、MESの工程要求とWMSの出庫・棚間移動が接続する。搬送装置の到着信号をそのまま在庫確定にするか、作業者の格納確認を要するかは、現物と台帳の一致を保証できる地点で決める。バーコードスキャナ、RFID、PLCの信号はそれぞれ観測対象が異なる。読み取っただけで移動完了にしない。タイムスタンプは端末時刻とサーバ時刻を区別し、工場間で時差がある場合も同じ順序で追えるようにする。

RFPで比較する機能と質問

製品選定では機能一覧の「○」より、例外を含む実演シナリオが役立つ。RFPには対象倉庫数、棚数、取扱品目、ロット・シリアル比率、日次移動件数、端末台数、無線が届かない場所、ラベルの種類、ピーク時間を記載する。数値は自社の実測を記入し、見積先の前提を揃える。拠点や工程を増やす予定があれば、追加費用と設定変更の担当範囲も明記する。

機能確認は少なくとも次を含める。①任意棚間移動と指示型移動を別権限にできるか。②移動元・移動先を実スキャンで照合できるか。③同じ棚に複数ロット・LPがあるとき誤選択を防げるか。④全LP移動と一部数量の分割をどう処理するか。⑤予約済み・出荷指示済み在庫を動かす権限と制約は何か。⑥品質保留、満杯、混載禁止、単位換算、オフライン再送をどう扱うか。⑦取消後に元取引と逆取引を追えるか。⑧ERP・MESとのAPIやファイル連携で再送、重複、失敗が可視化されるか。⑨タイ語・英語・日本語など必要な画面とラベルに対応できるか。⑩監査ログを誰が閲覧・出力できるか。

ベンダーの回答には、標準機能、設定で実現、追加開発、運用回避、未対応を分けて記入させる。特に「ロケーション確認あり」は、その確認が手動移動画面にも働くかをデモで見たい。Microsoft資料でも、手動で入力した場所には通常のロケーション確認手順が適用されないという条件がある。製品固有の制約をRFPで発見すれば、導入後の手戻りを減らせる。Microsoft: ロット・LP・ロケーション確認

FATとSATは「正常に動く」より「間違いを止める」を測る

FAT（工場受入試験）では、マスタと端末を試験環境に用意し、業務フローと連携を通す。代表的な正常ケースは、同一品目・単一ロットの棚間移動、混載LPの全量移動、LPから一部数量の分割、品質保留棚への移動、指示型移動先の提示、ERPへの結果連携である。ケースごとに、操作前後の移動元・移動先・予約量・利用可能量と、履歴IDを記録する。画面に成功と出たことだけを合格条件にしない。

異常ケースには、移動元の誤スキャン、ロット違い、数量超過、禁止棚、満杯、既に別作業が引き当てたLP、同じ操作IDの二重送信、通信断後の再送、端末の電池切れ、ERP受信失敗、取消と逆移動を入れる。予約済み在庫を部分移動できるかは製品固有の制約があるので、提案された処理方式そのものを試す。Microsoftの例では、既存作業行の分割を避けるため、100個の作業行から30個だけを別棚へ動かすことは制限される。また、ある条件では移動対象LP全体でなければならない。Microsoft: 予約を伴う在庫移動

SAT（現地受入試験）では、実棚ラベル、実端末、実ネットワーク、実際の作業導線で同じケースを試す。ラベルをフォークリフトから読めるか、棚番が似た列で誤読しないか、無線が途切れる場所で二重計上しないか、手袋着用時に操作できるか、タイ語の画面文言が現場で通じるかを確認する。稼働前に対象エリアの在庫を数え、データ移行後の残量と照合する。現物と台帳がずれたまま本番を始めると、その後の移動履歴が正しくても改善効果を判断できない。

合否は「すべてのケースが一度通った」ではなく、重大不具合の残件、操作教育の完了、例外時の連絡先、棚ラベル整備率、未処理インターフェースの監視体制まで含めて判定する。導入初週は棚間移動件数、未完了タスク件数、逆移動件数、棚不一致件数、スキャン例外、連携再送件数を日次で見る。数値の目標は工場ごとに基準値を測ってから設定する。根拠のない「在庫精度○％改善」という約束を先に置くより、どの誤りを何件減らすかを決める方が実装に結び付く。

導入を小さく始める手順

最初の対象は、移動が多く、棚ラベルと在庫データを整えやすい一つのエリアに絞る。保管品目、ロット、LP、移動理由、棚コード、権限を洗い出し、現在の紙帳票や口頭指示のどこで所在が途切れるかを観察する。次に、移動元・移動先のスキャンと完了履歴だけを最低限の機能として試す。品質ステータスやERP連携を削ってよいという意味ではない。稼働範囲を限定して確認し、在庫の正本を壊さない状態で段階的に広げるということだ。

試行では「スキャン回数が増えた」という現場の声も記録する。毎回同じ棚のコードを何度も読むなら画面順を変える余地がある。ただし利便性のために移動先確認を外すと、元の所在不明に戻る。不要な入力と必要な証跡を分け、マスタから安全に補完できる値だけを自動化する。班長と倉庫担当、品質、IT、ERP担当が同じ試験シナリオを読み、例外時の最終判断者を決める。マニュアルは画面の押し方に加え、「現物が見つからない」「別ロットがある」「指定棚が満杯」の判断手順を載せる。

本番後は履歴を改善に使う。同じ棚から何度も臨時移動が起きるならレイアウトや補充ルールに問題があるかもしれない。品質保留棚に長く滞留するなら判定待ちの運用に問題があるかもしれない。逆移動が多いなら棚ラベルや画面の類似コードを見直す。履歴は作業者を責めるためではなく、配置とルールの欠陥を見つけるために使う。倉庫ロケーション移動管理システムの価値は、単に棚番号がリアルタイムに変わることではなく、現物、作業指示、在庫引当の三者が同じ所在を語れることにある。

現場で決めておきたい五つの判断場面

1. 同じ棚の別ロットを取り違えた場合

端末に「棚Aに品目Aが20個」と表示されても、実物がロットL1の10個とL2の10個に分かれていれば、合計数量だけでは移動を確定できない。作業者がL1をスキャンした時点で、画面はL1の移動可能量を示し、L2の数字を足して許可しないようにする。スキャンしたロットが指示と違うなら、現物が間違って置かれているのか、指示が古いのかを切り分ける停止画面を出す。とりあえず移動を登録して後で帳尻を合わせる運用は、追跡を必要とする工場では避けたい。ロットラベルが読めない場合の責任者と再発行手順も決める。

ロット別の在庫が正しくても、混載パレットを一つのLPとして扱う場合は注意が要る。パレット全体を移したのか、一箱だけ抜いたのかで移動後のLPの構成が変わる。一部移動なら元LPの残数と移動先の容器IDを同時に記録する。二つの容器が同じLP番号を名乗る状態を許さない。将来、出荷時に箱単位で追跡するなら、その時に必要な粒度まで最初からIDを設計しておく。ただし全製品をシリアル管理へ引き上げる必要はなく、管理対象品目ごとのリスクで決める。

2. 指定された移動先が使えない場合

システムがB棚を提案したが、現場では既に別パレットが置かれている。この場合、作業者が空き棚Cを見つけても、そのまま移動先を書き換えて完了できるとは限らない。容量、品目の混載、所有者、品質ステータス、温度帯を再評価し、Cが許可候補なら理由付きで切り替える。候補外なら班長にエスカレーションする。B棚の台帳と現物が違うこと自体も差異として記録し、棚卸対象にする。「例外承認」は不正な棚を通す万能ボタンではなく、決められた条件内の代替を選ぶ手順である。

移動先で現物を置いた後、端末だけ失敗した場合も手順が必要だ。再操作で新しい移動を起こすのではなく、まず未確定の操作IDを照会し、サーバ側で受理済みか確かめる。受理済みなら同じIDを再送して結果を取得する。未受理なら現物の棚と数量を確認してから再実行する。二重計上を防ぐため、端末の「通信失敗」とサーバの「業務失敗」を区別して表示したい。これはRFPのデモで実際に通信を切って試せる。

3. 引当済みのパレットを動かす場合

出荷予定が決まっているパレットを通路工事のため移すなら、倉庫の都合だけでなく、出荷作業の参照先を更新する必要がある。移動を許す役割、動かせる単位、作業指示への通知、移動後のピッキング場所を一つのシナリオで確認する。移動元に100個の作業行があり、30個だけを別棚にしたい場合、既存作業を分割できない製品もある。Microsoftが説明する予約済在庫の移動制約はその具体例であり、候補製品でも同じかは必ず確認する。許可されない場合は、出荷指示の解除・再作成か、パレット全体の移動など、正式な代替手順を用意する。

同時に、何を「予約済み」と呼ぶかをERPとWMSで揃える。販売伝票上の確保、WMSのピッキング作業作成、現物の取り置きは別の段階になり得る。予約がまだ品目総量だけに掛かっているなら棚移動の自由度は高いかもしれないが、特定LPに結び付いた後では制限が必要になる。どの段階から誰の承認を要するかを業務フロー図に記載し、FATで状態を一段ずつ進めながら試す。

4. 品質保留の在庫を動かす場合

品質保留のパレットを検査室に近い棚へ移すのは物理的な作業であり、「使用可」の承認とは異なる。端末で移動先をスキャンした後もステータスは保留のままとし、工程への払出しや出荷には使わせない。検査結果が合格になったときは、品質担当者がステータス変更を承認し、必要なら別の棚間移動を指示する。これを一つのボタンで同時処理する場合でも、履歴には物理移動と品質判断の時刻、実行者、根拠を別々に残したい。

逆に不適合が判明したときは、現物がどの棚にあっても利用可能在庫から速やかに除外する。すでに移動タスクが進行中なら、端末に停止を通知し、移動先を隔離棚へ変更するか、作業者に現物保持を指示する。通知だけでは不十分で、現物を誰が確認したかを記録する。ここを運用で曖昧にすると、システムでは隔離中でも実物が通常棚に残るという、最も避けたいずれが起きる。

5. 夜勤から日勤へ未完了タスクを渡す場合

移動中のパレットが交代時に残ったら、口頭で「あとで片付けて」と伝えるだけでは場所が分からなくなる。未完了一覧には、最後にスキャンした元棚、LP、数量、移動予定先、担当者、最終操作時刻、現物確認の要否を表示する。交代する人はパレット現物と一覧を照合して引き受ける。元の担当者が後から端末を同期した場合の重複も考え、引継ぎ時に旧タスクを閉じるか担当を移すかを決める。

未完了が一定時間を超えたら班長へ通知する運用も有効だが、時間だけで自動確定してはいけない。現物を確認していない限り、台帳の場所を推測でBへ進めることになる。夜勤中にネットワークが落ちた場合は端末の未送信件数を確認し、復旧後に操作IDで再送状態を突き合わせる。作業の完了率だけでなく、例外が何時間滞留したかを測れば、端末や無線の改善優先度も分かる。

導入判断に使うデータと責任分担

投資判断では、棚移動の件数だけでなく、誤所在の影響を業務別に集めたい。探す時間、予定外の再ピック、出荷遅延、ライン停止の可能性、棚卸差異調査、ロット照会に要した時間などである。ただし原因がすべて棚移動ではないため、改善見込みを単純に合算しない。導入前に一定期間、移動の理由・発生棚・例外を記録し、標準作業と臨時作業を分ける。こうすれば、どの問題をシステムで減らし、どれをレイアウト変更や教育で減らすのか説明できる。

責任分担では、倉庫が現物確認と作業標準を持ち、品質がステータス変更を承認し、ITが端末・ネットワーク・インターフェースを支え、ERP担当が在庫評価との一致を確認する。マスタの変更権限も指定する。棚コードを増やしたとき、ラベルを貼る前に有効化するのか、現場確認後に有効化するのか。棚を廃止したとき、残在庫がゼロで未完了タスクがないことを誰が確認するのか。こうした日常の変更管理がないと、稼働直後は正確でも数カ月後にコードと現物がずれる。

ベンダーに問い合わせる際は、画面の概念図だけでなく、対象品目のマスタ例、棚ラベル写真、代表的な移動票、出荷予約の流れ、品質保留の規則を渡す。機密情報は匿名化してよいが、取引の複雑さは残す。提案比較で見るべきは「同じ例外を標準設定で止められるか」「追加開発なら保守は誰が行うか」「障害時に現場がどこまで復旧できるか」である。こうした具体物があれば、見積額の差が機能範囲の差なのか、実装方法の差なのか判断しやすくなる。

試行期間の評価は、単に作業時間の平均だけで行わない。移動タスクを開始してから現物を置くまで、台帳へ確定するまで、例外を解消するまでを別々に測る。作業者が一人で行う短距離移動と、フォークリフトと二人作業で行うパレット移動を同じ平均に混ぜると、画面の改善点が見えなくなる。移動の類型ごとに、スキャン回数、未完了率、誤棚率、逆移動率を比べる。現場にとって入力が増えたとしても、探索や再作業が減るなら全体では改善する可能性がある。一方、記録は正確でも棚前で長い待ち時間が生じるなら、無線や画面遷移、承認待ちのどこに原因があるかを直す。

運用契約にもデータの責任を明記する。障害時に一時的な紙票へ戻すなら、復旧後に誰がいつまでに取引を入力し、二重登録をどう防ぎ、どの残高を正とするのかを決める。端末交換時に未送信の移動履歴が残っていないかを確認する手順も必要だ。保守担当が棚マスタを変更する場合は、変更前後の一覧と承認者を残し、稼働中のタスクに影響する変更を避ける。契約に「サポートあり」とだけ書いても、現場の夜勤中に誰が在庫を確定できるかは分からない。対応時間、障害の優先度、代替手順の責任者まで確認したい。

提案価格が大きく違うときは、ライセンス単価より前提条件を照合する。安価な案がロット別LP分割、オフライン再送、逆移動、ERP連携の監視を対象外にしていれば、稼働後に現場の手作業が残る。高価な案がすべてを追加開発として見積もるなら、標準設定で代替できる範囲を問い直せる。見積書には初期構築だけでなく、棚やユーザーの増加、ラベル更新、障害対応、バージョン更新時の再試験を含める。比較表は同じ業務シナリオごとに費用と未対応事項を並べることで、投資判断に必要な差が見える。

よくある質問

ロケーション管理だけを先に導入できますか？

可能な場合はある。ただし、入出庫や品質判定が別台帳のままなら、棚別残量の正本をどこに置くかを先に決める。入荷した在庫がどの棚に発生し、出荷・製造投入時にどの棚から減るかがつながらないと、棚間移動だけ正しくても総量が合わない。初期範囲を絞るなら、一つの倉庫・品目群で受入から移動、消費までを閉じて検証する。

バーコードを導入すれば誤移動はなくなりますか？

なくならない。ラベルの貼り間違い、似た棚番、誤ったマスタ、読み取り後に別の棚へ置く行為、再送による二重登録が残る。実棚での移動先確認、エラー時に止まる画面、棚ラベルの保守、現物照合を組み合わせる。GS1のGLNや物流ラベルは識別体系を整える助けになるが、運用とシステム側の検証を代替するものではない。GS1: GLNで物理場所を識別

導入費用を見積もるには何を数えますか？

倉庫・棚・品目・端末・ユーザーの数に加え、ラベル更新、無線整備、ERP/MES連携、ロット・LPの扱い、例外処理、データ移行、教育、保守を数える。ソフトウェア利用料だけでは比較できない。現状の移動件数と誤所在による探索・再作業の実測も添え、同じ業務範囲で見積もりを取る。規模に応じた費用は提案を受けて判断する。

倉庫管理システムとERPのどちらで棚移動を確定しますか？

棚別在庫の正本を持つシステムで確定する。ERPの倉庫機能が正本ならERP内で、独立WMSが正本ならWMSで確定し、必要な結果をERPへ伝える。MESへは生産投入や工程引渡しに必要な粒度で渡す。両方で独立に同じ棚移動を登録する運用は、二重計上と差異調査の負担を生む。

まとめ

倉庫ロケーション移動管理の導入では、棚Aから棚Bへ数量を動かす画面より先に、移動単位、ロット・LPの識別、引当済在庫の権限、移動中の状態、取消・逆移動、台帳の正本を定義する。RFPには現場の例外を含め、FATとSATでは誤りを止められるか、履歴を再現できるかを試す。正確な棚別在庫は、端末の導入だけでなく、現物確認とシステム境界を一緒に設計した結果として得られる。

タイの製造拠点で棚間移動の記録方法やERP・WMSとの接続を検討中なら、現行の帳票と代表的な例外を整理する段階からTOMAS TECHへご相談ください。対象エリアを絞った要件整理から進められます。