拠点間移動オーダーで在庫を追跡可能にする

火曜日の午前、福岡の拠点責任者がある顧客に「代替用のモーターは金曜日に届きます」と答えました。大阪倉庫の在庫画面には12個と表示されています。東京倉庫には4個。しかし、どちらの数字が正しいか誰も確信が持てません。なぜなら先週、大阪から福岡へトラックで3個のモーターが送られましたが、誰がその移動を承認し、いつ出発し、到着したのか、記録されていないからです。顧客には、現場が本当に守れるかどうか分からない約束をしてしまいました。

複数の拠点で在庫を管理している方にとって、この光景は馴染みのあるもののはずです。在庫そのものは存在します。しかし記録が食い違っています。動かした人と、その件で説明責任を負う人が違います。基幹システムが存在する大きな理由の一つは、まさにこうした事態を防ぐことであり、その中で拠点間移動オーダーは、最も整理された手段の一つです。

拠点間の在庫移動が見た目よりも難しい理由

多くのチームは移動の作業量を甘く見ます。それは出荷の問題のように見えるからです。しかし実際には、責任の所在を問う問題です。商品がある場所を出発し、別の場所に到着するたび、3つの記録が同時に正確でなければなりません。何が出発したか、移動中のものが何か、何が着いたかです。このうち一つでもずれれば、次の判断、つまり発注するかどうか、納期をどう答えるか、ロットをリコールするか、すべて誤った情報の上に行われます。

日本ではこの圧力がとりわけ強まっています。いわゆる2024年問題、トラック運転手に課された時間外労働の上限規制が、陸上輸送網が運べる貨物量を縮小させています。業界分析によれば、物流の配送能力は2024年までに約14%低下すると試算され、対策を打たなければ2030年までにさらに34%落ち込むとされています。2023年の東京商工リサーチの調査では、約80%のトラック運送事業者が人手不足を感じていると回答しました。1キロ、1便ごとのコストが上がり、予約も取りにくくなる中、最初の移動を杜撰に行って後から緊急便で修正するような、ずさんな拠点間移動はもはや許されません。

移動オーダーを備えた基幹システムがあれば、場当たりではなく、意図を持って在庫を動かせます。各移動は、番号、出発元、到着先、日付、責任者を持つ構造化された文書になります。電話と「なんとか願う」だけの対応ではありません。

拠点間移動オーダーとは具体的に何か

専門用語は一旦脇に置きましょう。移動オーダーとは、特定数量の特定商品をある場所から別の場所へ動かす、正式な依頼のことです。そして会社全体が見える形で記録されます。出荷文書の社内版、ただし両端が自社に属しているものと考えてください。

Kikan System の基幹システムでは、拠点間移動オーダーは、後から移動の正当性を説明しなければならないときに備えて、必要な情報をすべて保持します。システムが発行する文書番号（例えば ITO20260001）があるため、誰がどの移動を指しているのか曖昧になりません。出発元と到着先が明示され、同じ場所を選べないようになっています。当たり前に聞こえるかもしれませんが、長いリストから誤った拠点を選んでしまうスプレッドシートのミスがどれほど多いかを考えれば、この制約の価値が分かります。さらに、移動の実行責任者、配送方法、移動日、加えて任意の予定到着日が記録されます。

各オーダーは1行以上の明細を持ちます。明細には商品、在庫単位での数量、そして包装単位が記載されます。この最後の項目は、多くの人が考える以上に重要です。3箱を動かすのと、300個を動かすのとでは、受け取る側の倉庫の数え方がまったく異なります。包装単位と包装数量は、後付けのメモではなく、独立した正式な項目として扱われます。

全員の記録を正しく保つライフサイクル

多くのチームが間違えるのはワークフローです。在庫は動いたか、動かなかったか、どちらかです。優れた移動オーダーは、誰かが思い出したときに更新する自由入力のステータスではなく、定義されたライフサイクルでその現実を映し出します。

このシステムでは、すべての移動オーダーが管理された一連の状態を遷移します。まずドラフトとして始まり、数量や経路を詰めている間は自由に編集できます。次に確認済みとなり、意図が確定し、責任が割り当てられます。そこから、商品が実際に動いた時点で完了となり、計画が変わればキャンセルされます。一度完了またはキャンセルされたオーダーは、編集も削除もできません。完了した移動は、書き直すための下書きではなく、歴史的事実だからです。

遷移は提案ではなく、強制されます。ドラフトを一足飛びに完了にすることはできません。すでに完了したものをキャンセルすることもできません。キャンセルされたオーダーは、計画が再び動き出せば、ドラフトまたは確認済みに復元できます。硬く聞こえるかもしれません。しかし「先月出荷したはずの移動」が本当にあったのかどうかで、二つの倉点が言い争うのを見たことがあれば、この制約の意味が分かります。強制された状態こそが、その議論を消し去ります。

オーダーの配下では、各明細が自身の配送進捗を持ちます。未配送、一部配送、全配送、のいずれかです。重要なのは、これらが疲れた担当者がクリックするチェックボックスではなく、オーダーに対して実際に記録された配送からシステムが計算する点です。一度でも一部配送または全配送になった明細は保護されます。すでに動いた在庫の記録を、こっそり削除することはできません。この一つのルールが、四半期ごとの大掃除の何倍も在庫精度に貢献します。

現実のシナリオ：東大阪の精密部品メーカー

東大阪に本社を置き、従業員約70名の精密部品メーカーを想像してください。名古屋の加工パートナーに併設された第2の在庫拠点と、福岡から九州の顧客に向けた小さな配送拠点を持ちます。年商は約4億8000万円です。この会社が抱える最大の悩みは、生産ではありません。突き合わせです。

毎月、経理チームは3拠点が「手元にある」と言う在庫と、記録上「あるはず」の在庫とを照合するために、ほぼ3営業日を費やしています。拠点ごとに2%から4%の差異が出るのが当たり前です。名古屋にあるはずのアルミニウム原材料のロットが、福岡の棚卸しで見つかります。顧客の納期に間に合わせるため九州へ移動した完成品が、東大阪から出庫された記録に残っていません。一つ一つの不一致が調査になり、一つ一つの調査が、誰にも請求されない時間になります。

こうした会社が基幹システムを導入し、拠点間の移動を移動オーダーとして経由させるようになると、変化は魔法ではなく機械的に起きます。名古屋の在庫拠点が東大阪へアルミニウムの補充を依頼します。その依頼は移動オーダー ITO20260001 となり、確認済みになり、責任者が明示され、予定到着日が記録されます。トラックが名古屋で荷下ろしすると、明細は配送済みに切り替わります。移動オーダーとして経由させることで、その移動は連携する在庫移動の記録を通じて各拠点の在庫数に反映されます。出発元の在庫は商品が出荷されたときに減り、到着先の在庫は受け取られたときに増えます。二つ目のスプレッドシートも、月末の探偵作業も、「本当に動いたのか」という論争もありません。

これを四半期数百回の移動に広げれば、3日間かかっていた突き合わせは数時間へと縮みます。それが本当の成果です。ベンダーのスライドに載る派手な数字ではありません。回収されたスタッフの時間と、守られた顧客への約束です。

ルールがあなた自身からあなたを守る場所

移動オーダーシステムにおける二つの設計選択は、あなたを救うまでは見落とされがちです。

一つ目は並行処理の保護です。二人が同じオーダーを操作するとき、システムはバージョン番号による楽観的排他制御を使います。名古屋の担当者と東大阪の担当者が同時に移動 ITO202600014 を開き、一方が先に保存した場合、もう一方の保存は、最初の変更を黙って上書きするのではなく、明確な競合として拒否されます。単一拠点の事業ではめったに問題になりません。異なる時間帯の3拠点にまたがれば、唯一の正しい記録と、三つの食い違う記録の違いになります。

二つ目は監査証跡です。すべてのオーダーは、誰が作成し、誰が最後に更新したかを、タイムスタンプ付きで記録します。内部統制のレビューに備える日本企業にとって、これは「あると嬉しい」ものではありません。在庫がなぜそう動いたのかを監査人が問うたとき、具体的な人、具体的な日付、具体的な状態遷移を指し示せることこそが、監査人が見たいものです。状態遷移そのものも帰属します。確認や完了のたびに、誰がいつ変更したかが記録されるため、移動の各段階は、名指しされた人と名指しされた日付にまで遡って追跡できます。

正直な限界：移動オーダーが自動ではやらないこと

信頼できるベンダーは、自社製品ができないことを伝えます。ここでは率直に申し上げます。

移動オーダーは在庫の記録を動かします。このシステムでは、自社の拠点間で商品が移動したとき、自動的に総勘定元帳へ会計の評価替え仕訳を計上することはありません。自社が所有する二つの倉庫間での在庫移動は社内移動であり、売上や購買ではないため、売上請求書や購買請求書のように仕訳を自動生成することはありません。貴社の会計方針が、原価部門間の正式な評価替え移動を求める場合、その仕訳は今日は手動で作成します。ここで自動的な元帳への転記を期待するのは間違いです。

また、移動オーダーはそれ自体で、在庫がどこにあるべきかを最適化しません。需要予測、発注点の計算、倉庫のレイアウト配置の論理は実行しません。移動オーダーは実行の道具であり、貴社が決めた移動を、きれいに、追跡可能にします。何を、いつ動かすかという決定は、依然として数字を読む人のものです。もし販売者が「当社の移動モジュールは補充まで自動で決定します」と主張したら、貴社のデータで実際に動くところを見せてもらってから信じてください。

多通貨はこの範囲には含まれません。円建ての自社拠点間の社内在庫移動としては、これで正しい設定です。もし通貨の境界をまたぐ拠点間移動を評価する必要が出てきたら、それは別の話であり、別の設定になります。

これらの限界は弱点ではありません。確実に動く機能と、過剰な約束をする機能の、境界線です。基幹システムは、言ったことを正確に行い、それ以外について正直であることで信頼を得ます。

運用全体とのつながり

移動オーダーは、孤立した島でないときに最も価値を持ちます。受注、発注、在庫棚卸と同じ基幹システムの中に存在するため、数字は手動の同期なしで一貫性を保ちます。福岡の受注が、物理的には名古屋にある在庫から引き当てるとき、それに続く移動依頼は、同じ商品、同じ単位、同じ拠点の記録を使います。古くなってずれていく二つ目のマスターファイルは存在しません。

ロットを管理している会社では、リコールを支えるのと同じロットの規律が、移動をまたいで商品に伴います。東大阪から名古屋へ移動した商品は、同じロットの同一性を持つ同じ商品です。そのため、顧客からの問い合わせや品質上の問題が浮上したとき、システムから離れることなくその経路を追跡できます。この連続性こそが、本当のERPと、切り離されたアプリの寄せ集めを分けるものです。

→ 関連記事：ロット管理とリコール対応

よくある質問

うちの規模では正式な移動オーダーは不要ではありませんか。

単一拠点で、在庫を一度も動かさないのであれば、そのとおりです。しかし二つ目の拠点、パートナー倉庫、委託在庫の保管庫を持ち始めた瞬間、非公式な移動は、記録するという規律よりも高いコストを生み始めます。損益分岐点は、多くの人が予想するより早く来ます。

切り替えで現在の棚卸が狂いませんか。

本当のリスクはソフトウェアではなく、定着です。最もきれいな進め方は、まず一組の拠点ペアで既存の棚卸プロセスと並行して移動オーダーを運用し、1か月間双方を突き合わせ、チームが数字を信頼できるようになってから拡張することです。初日からすべての拠点を一斉に切り替えるよう迫るベンダーは、助言しているのではなく、売り込んでいます。

コストはいくらで、効果はどれくらいありますか。

直接的な効果は、回収されたスタッフの時間と、減った緊急便です。間接的な効果は、実際に守れる顧客への約束であり、それは、現実的な納期を答えられる競合に奪われていた売上を守ります。前述の東大阪のシナリオでは、回収された突き合わせの日数だけでも、最初の四半期で導入費用を回収しました。Kikan System は最大2ユーザーまで無料、クレジットカード不要で始められるため、ご自身の人員と差異率で、自社のデータで同じ計算を始める前に確かめられます。

既存の移動履歴は移行できますか。

過去の移動は、原則として、元の日付と責任者を伴う完了済みオーダーとして入力できるため、監査証跡はゼロから始まりません。これは週末の作業ではなく、計画的なプロジェクトとして進め、過去数年分を完璧に再構築することよりも、未完了の移動の正確性を優先してください。

ポイント： 基幹システムは、3つの拠点が「どの棚卸が正しいか」で言い争うのをやめ、「何がどこへ動いたか」の一つの共有された記録を信頼し始めたその日に、移動オーダーモジュールの対価を回収します。

一つの正しい記録で在庫を動かし始める

もし貴社のチームが今も、メールとスプレッドシートで拠点間の棚卸を突き合わせているなら、それこそが基幹システムが解決するために作られた問題です。Kikan System は、強制されたステータスライフサイクル、明細ごとの配送追跡、明示された責任、そして「誰が、何を、いつ行ったか」の完全な記録を備えた拠点間移動オーダーを提供し、貴社の拠点間のすべての移動を、意図的で、説明可能なものにします。

まずは2ユーザーまで無料、カード不要で始められます。拠点間の在庫が一つの記録にまとまったとき、現場の突き合わせがどう変わるかを、ぜひご自身の目でお確かめください。

→ 無料で始める

拠点間移動オーダーで在庫を追跡可能にする｜基幹システムの活用法