物流システムの導入プロジェクトにおいて、ユーザーやコンサルタント同士で必ずと言っていいほど熱い議論になるトピックがあります。それは、「棚卸で在庫差異が見つかった際、システム上でどう処理すべきか」という問題です。
今のWMS（倉庫管理システム）、特にSAP EWMなどの高度なシステムを使えば、ボタン一つで実在庫に合わせてシステム在庫を増減させることは容易です。「現物がないのだから、まずはシステムを現物に合わせて、差異はあとで分析すればいい」――そんな声も聞こえてきそうです。
しかし、果たしてそれは本当に「正しい在庫管理」と言えるのでしょうか。
私は、安易な在庫調整は現場の規律を緩め、本質的な課題を闇に葬ってしまうリスクがあると考えています。極論を言えば、在庫差異とは単なる数字のズレではなく、出荷や入荷といった「本来なされるべき計上の漏れ」そのものです。
今回の記事では、棚卸差異を単なる「帳尻合わせ」で終わらせないために、実務者が向き合うべき「差異の正体」と、それを防波堤となって食い止めるためのシステム設計のあり方について、私の考えを深掘りしてみたいと思います。
システムの便利さと、その「落とし穴」
近年のWMS（倉庫管理システム）、特にSAP EWMのような高度なパッケージを導入すると、棚卸の実務は非常にスムーズになります。現場でハンディターミナルを使ってカウント値を入力すれば、システム上の在庫数との差分が即座に算出され、あとはそれを「確定」するだけです。
特にEWMには、「Difference Analyzer（差異分析）」という優れた機能が備わっています。これは、棚卸で発生した差異をすぐにERP（会計側）へ反映させるのではなく、一旦専用のトランザクションに蓄積し、管理者が内容を精査した上で「書き出し（Post）」を実行できる仕組みです。倉庫内の実在庫と、会社の資産としての在庫情報の間に一呼吸置くための「防波堤」と言えます。
しかし、ここには大きな落とし穴があります。この便利な機能があるがゆえに、実務上の「分析」がいつの間にか「単なる承認作業」に形骸化してしまうのです。
「差異が出たけれど、現物がないのだから仕方ない。とりあえずシステムを現物に合わせて、業務を先に進めよう」
この考え方が定着してしまうと、在庫管理の精度は徐々に、しかし確実に蝕まれていきます。
EWMを使った棚卸の処理はこちらの記事に記載していますのでこちらも良ければ読んでください。
「在庫差異」の正体は何か？
ここで一度、原点に立ち返って「在庫差異」の本質について考えてみましょう。なぜ、システムと目の前の現物に差が生まれるのでしょうか。
極論を言えば、在庫差異というのは「出荷計上（GI）」または「入荷計上（GR）」の漏れ、すなわち在庫のプラスマイナスの申告漏れに過ぎません。
棚卸調整機能を使って在庫を増減させるのは、あくまで最終手段であるべきです。本来であれば、在庫が増減するはずだった「理由」を追求し、あるべき姿（本来のトランザクション）で在庫を調整するのが望ましい姿です。
具体例：出荷の計上漏れ（GI漏れ）が引き起こす「経営上の不備」
例えば、棚卸で「あるはずの製品が1つ多い」というプラスの差異が発生したとします。通常なら「在庫を1つ増やす」という棚卸調整をして終わりですが、これを掘り下げると非常に恐ろしい事実が見えてくることがあります。
- システム上は出荷伝票が作成され、出庫確認（GI）まで完了している。
- しかし、現場での積み忘れや梱包ミスにより、現物が倉庫内に取り残されていた。
この事態を「在庫を増やして解決」してはいけない理由は、単に帳簿が汚れるからだけではありません。会社としての「お金の動き」と完全に矛盾してしまうからです。
「システム上で出庫が完了しているということは、会計上は『売上が計上され、顧客へ請求が飛んでいる』状態を意味します。つまり、届けてもいない商品に対して代金を請求している、極めて不誠実な状態なのです」
ここで安易に棚卸調整で在庫を増やすと、システム上は「謎の理由で在庫が1つ増えた（棚卸益）」ことになります。しかし、その裏では「届いていない商品への請求」という爆弾を抱えたままになります。顧客から「モノが来ていない」とクレームが入った際、既に棚卸で在庫を増やしてしまっていたら、一体どの伝票の不足分として補填すればよいのか、トレース（追跡）すら不可能になります。
倉庫の使命は「現物を合わせる」ことではない
本来あるべき対応は、出荷伝票までさかのぼり、「システム的には出荷済みだが、現物が届いていない」という事実を突き止めることです。そして、後追いで（システム外の実務として）その現物を顧客へ送り届ける。あるいは、正しいプロセスで出荷の赤黒処理を行う。これこそが「現物一致」の本来の意味です。
在庫管理やトレース（追跡性）の確保は、倉庫に課せられた最大の使命です。
もし、差異が出るたびに都度在庫調整で「帳尻合わせ」をしているのであれば、それはもはや倉庫としての機能を果たしているとは言えません。それはただの「物置」であり、管理とは程遠い状態です。在庫調整はあくまで最終手段。棚卸を「在庫を合わせる作業」ではなく、「業務プロセスの不備を見つけ出し、会社の資産を守る活動」と捉え直す必要があります。
実務で守るべき「防衛ライン」
では、現場やプロジェクトでどのようにこの問題に向き合うべきでしょうか。私は、Difference Analyzerに差異が流れる前、すなわち「棚卸伝票の入力・確定段階」でいかに踏みとどまって調査できるかが勝負だと思っています。
「差異が出たからといって、すぐに調整ボタンを押してはいけません。その一押しが、本来解決すべき業務上の課題を消し去ってしまうからです」
実務上のプロセスとしては、以下のような「泥臭い調査」が不可欠です。
- 仮説を立てる：「出荷の積み忘れではないか？」「入荷時の検品ミスで、別の商品と取り違えていないか？」
- 伝票ログを追う：直近数日間の入出庫履歴（トランザクションログ）を確認し、不自然なキャンセルや未完了の伝票がないかを確認する。
- 現場と突き合わせる：事務所のPC上だけでなく、現場の「棚の隅」や「梱包エリア」に実物が残っていないか確認する。
あらゆる手を尽くしてなお、どうしても原因が特定できないもの。それだけを最終的に「棚卸損益」としてシステムで調整する。この「棚卸調整は最終手段」という優先順位を徹底することが、倉庫管理の質を左右します。
システム制御による規律の維持（コンサル視点）
また、コンサルタントの視点からは、ユーザーの「善意」や「努力」だけに頼るのではなく、「システム的に安易な調整ができない仕組み」を作っておくことも重要だと考えています。
具体的には、棚卸伝票において製品や荷役単位（HU）を自由に追加できる機能を、一定のルールで制限（エラー処理）しておく設計が有効です。
「EWMでは通常、システムに存在しない荷役単位（HU）を棚卸伝票で追加しようとするとエラーになります。これは非常に正しい挙動です」
実在しないHUを勝手にシステム上で生み出すことは、在庫の「捏造」に繋がりかねません。一方で、システム上は「別の棚」にあるはずのHUを、棚卸伝票に追加することは許可されることが多いです。これは「在庫の増減」ではなく、あくまで「倉庫内の移動」として整理されるべきものだからです。
「何でもかんでもシステムで増やしたり減らしたりできる」状態をあえて作らず、システム側で適切な制約を設ける。それが結果として、ユーザーに「なぜエラーになるのか？（＝なぜ差異が出ているのか？）」を調査させる動機付けになります。
まとめ：システムを合わせるのではなく、実務を合わせる
在庫管理のプロフェッショナルとして、差異調整の「手軽さ」という誘惑には抗わなければなりません。
在庫差異が発生したとき、私たちが真っ先に行うべきは「システム上の数字をいじること」ではなく、「現実の世界で何が起きたのかを特定すること」です。
「システムを実態に合わせる」のは簡単です。しかし、本当に目指すべきは「実務をあるべき姿に合わせ、その結果としてシステムと現物が一致している」という状態です。次の棚卸では、Difference Analyzerに並んだ数字の裏側にある「現場のドラマ」に、一歩踏み込んでみてはいかがでしょうか。
コメント