この記事で分かること
- 倉庫別の数量と全体の数量を同じ画面で扱うための在庫モデル
- 倉庫間移動を依頼、出庫、輸送、入庫の状態で追跡する方法
- 受注引当や予約在庫を二重計上せず、出荷可能数を判断する考え方
- 棚卸の範囲、差異の承認、原因記録を一連の処理にする手順
- 拠点追加や既存データ移行を見据えた導入時の確認ポイント
複数倉庫の在庫管理で起きる問題
複数の倉庫を運営していると、在庫管理の問題は単純な入力漏れだけでは説明できません。大阪の倉庫から東京の倉庫へ商品を移したとき、出庫処理をした時点で全社在庫から減らすのか、到着して入庫するまで移動中として残すのかを決めていなければ、拠点別の数字と全体の数字が食い違います。さらに、受注分を確保した後に別の担当者が同じ数量を販売可能と判断すれば、帳簿上は在庫があるのに出荷できない状態になります。
現場が困るのは、在庫数が違うという事実だけではありません。どの処理をいつ誰が行ったかが分からないと、修正の判断が担当者の経験に依存します。急いで数字を合わせるために直接数量を上書きすると、後から履歴を再現できず、同じ問題が繰り返されます。まず在庫の状態を分け、数量が変わる出来事を履歴として残すことが、一元管理の出発点です。
「ある在庫」と「使える在庫」を分ける
商品が倉庫の棚に置かれていることと、すぐに注文へ割り当てられることは同じではありません。入荷したばかりで検品が終わっていない商品、破損確認のため隔離した商品、出荷先が決まって取り置いた商品は、それぞれ利用できる範囲が異なります。画面に総数量だけを表示すると、販売担当は実際より多い在庫があると受け取り、倉庫担当はすでに確保された商品を再び探すことになります。
最低限、物理的に存在する数量、品質確認が済んだ数量、受注などで予約された数量、出荷のために確保した数量を区別します。名称は会社の業務に合わせてよいものの、各区分の意味と数量の増減条件は文書化が必要です。数量の区分が決まれば、販売可能数を計算する式も担当者ごとに変わりません。
拠点ごとの在庫を同じ粒度で記録する
倉庫Aは商品コード単位、倉庫Bは商品名と仕入先単位というように、拠点ごとに管理の粒度が違うと、統合時に同じ商品を同じものとして集計できません。商品コード、ロット、賞味期限、保管場所、在庫状態など、何を在庫の単位にするかを先に決めます。商品コードの付け方を統一するだけでなく、コード変更や廃番の扱いまで定めると、過去の履歴を残したまま名称を更新できます。
倉庫のマスタには、拠点名、住所、営業日、出荷可能時間、在庫計上の基準時刻、担当部署を登録します。外部委託倉庫や返品専用の保管場所も、通常倉庫と別の拠点として扱うと、責任範囲と集計範囲が明確です。一時置き場を担当者のメモで管理するのではなく、システム上の保管場所として登録しておくことが、棚卸差異の追跡に役立ちます。
一元管理を支える在庫データの基本設計
一元管理では、全倉庫の合計を表示できれば十分というわけではありません。合計の根拠となる拠点別数量と、数量が変わった取引履歴をいつでも確認できることが重要です。画面で見える現在庫は、入荷、出荷、移動、返品、調整などの記録から計算される結果として扱います。必要なときだけ手入力で合わせる運用にすると、在庫表と実物の差異が発生した時点を見失います。
在庫レコードと在庫取引を分ける
在庫レコードは、商品、倉庫、保管場所、ロットなどの組み合わせごとの現在の数量を持つ情報です。在庫取引は、入庫や出庫のように数量を変化させた一件の記録です。現在庫だけを上書きする方式では、前日の数量や処理担当者を確認できません。在庫取引に伝票番号、処理日時、担当者、理由、元となる受注や移動依頼を持たせれば、差異が発生した箇所を絞り込めます。
取引には、数量を増やす処理と減らす処理だけでなく、ある倉庫から別の倉庫へ移す処理もあります。移動を一つの増減として扱うと、移動元の出庫と移動先の入庫の間に商品がどこにあるか分かりません。移動元、移動先、移動数量、出庫日時、入庫日時を同じ移動番号で結び、途中の状態を保持する設計にします。
在庫状態と数量の関係を明確にする
在庫状態は、良品、検品待ち、保留、破損、返品など、販売や出荷の可否を判断する分類です。状態を別の列で持つか、状態ごとに在庫レコードを分けるかは、検索や集計の要件で決めます。どちらの方式でも、状態を変えた理由と変更者を履歴に残すことが大切です。状態変更だけで数量が増減したように見える場合は、数量移動の取引と状態変更の履歴を分けると、実物の増減と品質判断を区別できます。
販売可能数は、たとえば良品の現物数量から予約済み数量と出荷作業中の数量を引いて算出します。ただし、受注を登録した瞬間に予約するのか、与信や納期確認が済んでから予約するのかは会社ごとに異なります。数式を画面の表示だけに隠さず、在庫区分と引当ルールとして定義し、担当者が同じ結果を説明できるようにします。
在庫を確認するための画面を分ける
管理者が見る全体集計と、倉庫担当が見る作業一覧では必要な情報が違います。全体集計には商品別の総在庫、倉庫別の内訳、移動中、予約済み、販売可能数を表示します。倉庫担当の一覧には、棚番、入出庫予定、ロット、期限、ピッキングの優先度を表示し、余分な集計項目を減らします。店舗や営業担当が参照する場合は、予約を含めた数量か、出荷可能数かを見出しに明記すると誤解を防げます。
一覧に表示する時点も決めます。リアルタイムで更新する画面と、夜間に集計する帳票が混在すると、同じ日に異なる数字が出ることがあります。集計日時、最終更新日時、未処理件数を表示し、数字が一致しない理由を利用者が把握できるようにします。遅延がある連携データは、受信済みと未反映を区別して示します。
倉庫間移動を正しく追跡する設計
倉庫間移動は、商品を物理的に運ぶ作業と、在庫を帳簿上で移す処理の両方を含みます。依頼を作成した時点、移動元で出庫した時点、輸送中、移動先で受け入れた時点を同じ状態として扱うと、途中の数量が不明になります。移動依頼を一つの伝票として管理し、状態が進むたびに時刻と担当者を記録する設計にすると、問い合わせに答えやすくなります。
移動依頼から入庫までの状態を持つ
基本の状態は、依頼中、承認済み、出庫待ち、輸送中、入庫待ち、完了、取消とします。名称は現場に合わせて変更できますが、状態を飛ばして完了にできる権限は限定します。依頼数量と実際の出庫数量が異なる場合には、差分理由を記録します。分納や複数便で運ぶ場合は、移動依頼の下に出荷単位を持たせると、一部だけ到着した状況を表現できます。
出庫時には移動元の物理在庫を減らし、移動中在庫を増やします。入庫時には移動中在庫を減らし、移動先の検品待ちまたは良品在庫を増やします。入庫前に販売可能数へ加えないルールにすれば、輸送中の紛失や破損を現場で確認できます。商品を先に到着処理し、後から伝票を作る運用が必要な場合は、仮入庫番号を発行して正式な移動伝票に結び付けます。
輸送中在庫を経営判断に使う
輸送中の数量を全社在庫から除外すると、仕入れや生産の判断で不足と見誤る場合があります。一方、販売可能数に輸送中を含めると、到着遅延による納期遅れを見落とす恐れがあります。全社の保有量、各倉庫の現物量、輸送中、販売可能数を別々に表示し、用途ごとに参照する数字を決めます。納期計算では、移動先の到着予定日と検品に必要な時間を加味します。
移動中の滞留を管理するため、出庫から一定時間を超えた伝票を一覧に出します。配送会社の追跡番号、便名、担当者、到着予定日を紐付けると、在庫管理担当者が倉庫へ個別確認する回数を減らせます。遅延理由を選択式で残しておけば、ルートや曜日ごとの改善にも使えます。
例外処理を通常フローに組み込む
移動先で数量不足が見つかったとき、移動元と移動先の双方の在庫を勝手に修正するのは危険です。検品結果として受領数量、破損数量、未着数量を記録し、差異を承認する処理を別に設けます。破損品は良品から隔離在庫へ移し、廃棄や返品を行った時点で処分取引を登録します。後から数量を合わせるのではなく、何が起きたかを取引として残すことが監査と再発防止につながります。
移動の取消も、単純な削除ではなく、取消理由と取消日時を履歴に残します。出庫済みの移動を取り消す場合は、移動元へ戻す入庫と移動中数量の減少を行う必要があります。すでに一部入庫している伝票を取消すときは、未着分だけを取り消すのか、受領済み分を返品として扱うのかを選べるようにします。
引当と予約在庫を一元管理する
引当は、注文や出荷予定に対して、どの倉庫のどの商品を使うかを確保する処理です。受注情報を登録しただけで数量を減らすのか、予約として確保するのか、ピッキング開始時に確定するのかを決めないと、在庫の意味が画面ごとに変わります。引当済み数量は現物数量と別に表示し、販売可能数から差し引くことで、全体の状況を一つの式で説明できるようにします。
引当の優先順位をルールにする
倉庫を選ぶ順番には、納品先までの距離、在庫の有効期限、配送契約、出荷能力、在庫回転など複数の条件があります。担当者の経験だけで割り当てると、繁忙期や担当交代で結果が変わります。まず通常時の優先順位を決め、特定の商品だけ別倉庫を使う例外や、緊急注文の扱いを追加します。
期限管理が必要な商品では、先に入荷したロットから使うのか、期限が近いロットから使うのかを明確にします。倉庫間移動を行う際にも、期限やロットが引き継がれるため、商品コードだけで引当できるとは限りません。引当画面にロットと期限を表示し、担当者が選択した根拠を確認できるようにします。
一部引当と引当解除を扱う
注文数量を一つの倉庫だけでそろえられない場合は、複数倉庫から出荷するか、分納するか、移動を待つかを判断します。システムが自動で分割する場合でも、送料や納期への影響を確認する承認点を置くと、意図しない分納を防げます。一部だけ引当した場合は、引当済み、未引当、移動待ちの数量を注文画面で分けて表示します。
注文変更やキャンセルが発生したら、確保していた数量を販売可能へ戻します。引当解除を行わずに注文を削除すると、見かけ上の在庫が減ったままになります。解除できるのは出荷確定前までにするなど、状態に応じた権限を決めます。出荷後の返品は引当解除ではなく、返品検品後の在庫取引として登録します。
引当の重複を防ぐ
同時に複数の担当者が注文を処理する場合、画面に表示された販売可能数をそのまま信じて引当すると、同じ数量を重複して確保する可能性があります。引当処理の確定時に数量を再確認し、確定後の残数が不足していれば処理を保留する仕組みが必要です。処理単位と確定時点を定め、失敗した引当を再実行しても二重に予約されない設計にします。
外部の受注モールや販売管理システムと連携する場合は、同じ注文の二重受信にも注意します。外部注文番号を一意に保持し、連携済み、引当済み、出荷済みの状態を記録します。連携が遅れた注文は未処理一覧に出し、手動処理をした後も元のデータと結び付けます。自動連携が止まったときに、担当者が別ファイルで処理を続ける場合の戻し方も事前に決めておきます。
棚卸で差異の原因まで追えるようにする
棚卸は、実物の数量を数えてシステム上の数量を修正する作業です。差異を一括調整するだけでは、一元管理を維持できません。数えた時刻、対象の倉庫と棚、数えた担当者、システム数量、実棚数量、差異、原因、承認者を記録します。出荷や入荷が進行している倉庫では、カウント中の取引を止めるか、カットオフ時刻を設けて取引を前後に分ける必要があります。
全品棚卸と循環棚卸を使い分ける
全品棚卸は、決算や拠点移転のように全商品の数量を確認する場合に向いています。ただし、期間中の入出庫を大きく止める必要があり、作業負担も大きくなります。循環棚卸は、商品をグループや重要度で分け、一定の周期で一部ずつ確認します。高額品や出荷頻度の高い品目は短い周期、動きが少ない品目は長い周期にするなど、在庫リスクに合わせて計画します。
棚卸対象は、通常の良品在庫だけでなく、移動中、返品検品待ち、保留、廃棄予定の数量も定義します。対象から漏れた場所に実物が残っていると、後日別の棚卸で差異が発生します。棚番や容器番号をバーコードで読み取り、対象を一つずつ確定させると、同じ場所を二度数えるミスを減らせます。
差異の承認と在庫調整を分ける
カウント結果を登録した担当者が、そのまま調整を確定できると、入力間違いと実際の紛失を区別しにくくなります。一定数量以上の差異や金額が大きい差異は、倉庫責任者や管理部門が再カウントと原因確認を行う流れにします。承認前は仮差異として扱い、販売可能数に反映するかどうかもルール化します。
差異理由には、入出庫の未処理、移動伝票の未完了、ロケーション間違い、破損や廃棄の未登録、数え間違いなどを用意します。自由記述だけにせず、理由を選び、必要に応じて写真や関連伝票を添付できるようにします。調整取引には棚卸番号を結び、後からその調整がどのカウントに基づくものか確認できるようにします。
棚卸結果を運用改善へつなげる
差異率を倉庫ごと、商品群ごと、棚番ごとに集計すると、問題の場所が見えてきます。特定の棚だけ差異が多いなら、ラベルの視認性や保管ルールを見直します。特定の移動ルートで差異が生じるなら、出庫検品と到着検品の方法を確認します。担当者を責めるための数字にせず、処理手順と環境の改善に使うことが、継続的な精度向上につながります。
棚卸後にシステム数量が合っていても、未処理の伝票や仮置き在庫が残っていないかを確認します。差異をゼロにしたことだけを完了条件にすると、原因記録が省かれやすくなります。調整件数、再カウント件数、承認に要した時間、原因別の割合を追い、次回の棚卸計画に反映します。
権限と操作履歴を設計する
複数倉庫では、誰がどの拠点を見て、どの処理を確定できるかを分けます。倉庫担当は自拠点の入出庫と移動出庫を処理し、全社在庫の調整やマスタ変更は管理責任者に限定するなど、業務分担に沿って権限を設定します。閲覧権限と更新権限を分け、販売担当には販売可能数を見せても棚卸の調整権限を付けないといった設計が可能です。
操作履歴には、操作した利用者、日時、対象となる商品や伝票、変更前後の値、理由を記録します。数量を直接編集できる機能を残す場合は、必須の理由入力と承認を組み合わせます。アカウントを共有すると履歴が追えないため、拠点や派遣スタッフを含めて個人単位のアカウントを用意し、異動や退職時に権限を停止します。
導入前に決めておきたい業務ルール
システムを導入する前に、在庫の定義、倉庫の範囲、取引のタイミング、責任者を決めます。現場の要望をそのまま機能一覧にするのではなく、受注から出荷、補充、移動、棚卸までの流れを一枚の業務図にします。現在の表計算ファイルや紙伝票を並べ、どの情報が重複し、どこで転記が発生しているかを確認すると、必要なデータ項目が整理できます。
現在の仕組みを改修して使うのか、別の在庫管理システムへ移行するのか迷う場合は、画面の追加だけで解決できる問題か、データ構造そのものを見直す問題かを切り分けます。要件と既存データの状態を確認してから進めたい場合は、開発前診断・ロードマップで現状の課題と進め方を整理できます。要件を決める前に、倉庫ごとの運用差や連携先の制約を洗い出すことが、後戻りを減らします。
マスタ整備と移行範囲を決める
移行前には、商品コード、商品名、単位、入数、ロット管理の有無、期限管理の有無を整理します。同じ商品に複数コードがある場合は、統合後の代表コードと旧コードの対応表を作ります。倉庫別の数量を移行する日付と、移行後に発生した取引をどの仕組みへ登録するかも決めます。古い履歴をすべて移すのか、一定期間の履歴だけにするのかは、検索の必要性と移行負荷で判断します。
在庫の初期数量を登録する際は、倉庫別、保管場所別、状態別の内訳を確認します。全社合計だけを移行すると、引当や棚卸の基準が失われます。移行リハーサルでは、入庫、移動、引当、出荷、返品、棚卸調整を一通り実行し、数量が意図した区分へ移るかを確認します。実際の担当者が操作し、例外処理まで試すことが重要です。
現場が続けられる入力方法にする
倉庫の作業中に長いフォームへ入力する設計では、後回しやまとめ入力が起きやすくなります。バーコード、スマートフォン、ハンディ端末など、現場の通信環境と作業姿勢に合う入力方法を選びます。入力項目は、処理を確定するために必須なものと、後から補足できるものを分けます。オフラインになる場所がある場合は、仮登録と同期エラーの確認方法を用意します。
入力ミスを減らすには、候補選択やバーコード照合だけでなく、数量の上限チェックや棚番の確認も役に立ちます。誤った倉庫を選んだまま処理を完了できないよう、利用者の所属拠点を初期値にする方法もあります。ただし、応援作業や代理処理がある場合は、代理先を明示して一時権限を付与します。現場の例外を無理に隠さず、監査できる形で扱うことが必要です。
運用開始後に見る指標
導入後は、在庫金額だけでなく、業務の精度と滞留を測ります。棚卸差異率は、実棚とシステム数量の差異を数量または金額で確認する指標です。引当後の欠品率は、確保したつもりの商品が出荷時に不足した割合を示します。倉庫間移動の完了時間や輸送中の滞留件数を見れば、移動フローの詰まりを把握できます。
指標の定義には対象期間と分母を明記します。返品を含めるのか、移動中を在庫回転の計算に含めるのかによって数値の意味が変わるためです。数字を毎日増やすだけでなく、異常値が出たときに担当者がどの履歴を確認するかを決めておくと、改善行動につながります。月次の会議では、差異の原因別推移、未完了の移動、引当解除の件数を確認し、ルール変更の効果を見ます。
よくある質問
倉庫ごとに違う在庫表をすぐに統合できますか？
まず商品コード、数量の単位、在庫状態、棚やロケーションの表記をそろえる必要があります。形式だけを一つにまとめても、片方が引当済みを含み、もう片方が含まない場合は合計が正しくなりません。移行前にサンプル商品を使って、現在庫、移動、引当、棚卸の結果が一致するか確認し、対応表と変換ルールを確定してから全件を移します。
移動中の在庫は販売可能数に含めるべきですか？
納期と入庫の確実性によって判断します。全社が保有する数量を確認する集計には移動中を表示できますが、すぐ出荷できる数量には含めない運用が一般的です。到着予定日、検品時間、配送遅延の扱いを決め、販売画面には販売可能数と移動中を分けて表示すると、営業や受注担当が誤った約束をしにくくなります。
引当済みの数量を在庫から減らすと二重計上になりませんか？
現物数量と引当済み数量を同じ項目で減らすと、二重計上が起きます。現物数量は棚に存在する数として保持し、販売可能数を「販売対象となる現物数量から予約や出荷作業中の数量を引いた数」として計算します。出荷を確定した時点で現物数量を減らし、引当を完了または消し込む状態にすると、処理の順序を説明できます。
棚卸差異を見つけたらその場で数量を修正してよいですか？
少額の差異を即時に調整する運用もありますが、誰がどの理由で調整したかを残すことが前提です。金額や数量が一定以上の場合は再カウントと承認を必須にし、入出庫の未処理や移動伝票の未完了を先に確認します。調整取引に棚卸番号を結び付けると、後から差異の根拠を追跡できます。
倉庫が増える予定でも最初から全機能を作るべきですか？
将来の拠点追加を想定した商品、倉庫、在庫取引の構造は最初に整えます。一方、初期リリースでは主要倉庫の入出庫と移動、引当、棚卸に絞り、例外や連携を段階的に追加する方法もあります。先に業務上の共通ルールと拠点固有の差分を整理し、追加拠点をマスタ登録だけで増やせるかを検証してから開発範囲を決めます。
まとめ
複数倉庫の在庫を一元管理するには、全拠点の数字を足し合わせるだけでなく、在庫の状態と数量が変わった理由を同じ基準で記録することが必要です。倉庫間移動は依頼から入庫までを状態で追い、輸送中を現物や販売可能数と分けて扱います。引当は予約と出荷確定を区別し、在庫不足やキャンセルが発生したときに解除と履歴が残るようにします。棚卸は差異を調整して終わりにせず、原因、承認、関連する取引を記録して改善につなげます。
既存の表計算やシステムを活かして段階的に整備する場合も、最初に商品コード、倉庫、在庫状態、取引履歴の定義をそろえることが重要です。現場で続けられる入力方法と、管理者が根拠を追える履歴を両立させると、拠点が増えても運用を安定させやすくなります。具体的な画面やデータ連携まで検討する場合は、在庫管理システムのサービス内容を確認し、自社の業務に必要な範囲を整理してください。
運用上の課題や既存システムとの関係を整理したい場合は、相談フォームから現在の倉庫数、在庫の管理方法、困っている処理を伝えると、検討すべき論点を具体化できます。
