erpkaizen

価値の測り方

配車ボードを ERP の中に置くことの ROI

実測あり 2026年9月23日 約8分

卸売の出荷計画はたいてい共有の表計算として生まれ、実際に機能します。問題が出るのは1日数百件を超えてから。治療法は表計算を捨てることではなく、その操作感をシステムの中へ移すことです。

配車業務の2時間には、いくらの値打ちがあるか

必要なのは1日の出荷件数と、改善後に残る配車時間だけです。人件費、傭車、突合はそこから導かれます — すべて書き換えられます。

全シフト合計で倉庫から出ていく件数
システムがまとめて割り振ったあとに残る分
1シフトあたりの準備時間

これは事務の工数であって、トラックが何分早く出るかではありません。車両のクリティカルパスに乗っている分はもっと小さく、出典は1シフトおよそ45分と見積もっています。

前提 — クリックして一つずつ確認・変更できます

人と工数

車両

誤配と突合

導入費用

効果はどこから来るのか 棒にカーソルを合わせると内訳が出ます
配車と倉庫の工数
傭車が減ること
誤配が減ること
代引突合が減ること
月あたりの効果の合計
年間の効果の合計
導入費用
回収までの期間

これは見積りであって約束ではありません。「傭車が減ること」が最も柔らかい項目で、実際に傭車費を払っている場合にしか成り立ちません。払っていなければ零にして、もう一度合計をご覧ください。

卸売の現場では、出荷計画はたいてい共有の Google スプレッドシートとして生まれます。 そして実際に機能します。目で見えて、融通が利き、打てばすぐ映る。 それが長く生き延びる理由であって、誰かが ERP を避けているからではありません。

問題が出るのは1日数百件を超えてからです。そしてよく選ばれる治療法のほうが間違っています。 配車担当を ERP の入力フォームへ押し戻すというものです。この記事はもう一つの治療法を数字にします。 表計算の操作感はそのままに、それを ERP の中へ置く というやり方です。

1. 共有ファイルはどこで壊れるのか

表計算が悪いからではありません。表計算には持てない三つのものがあるからです。

  1. どの行も誰のものでもない。 複数のチームが同時に開いていて、VLOOKUP が固まり、 行を一つドラッグでずらしたりセルを一つ消したりするだけで、その日の配車全体が止まります。 何もエラーになりません。
  2. 切り貼りがシフトの最初の2〜3時間を食う。 路線で絞り込み、運転手ごとのタブにコピーし、 伝票を1枚ずつ印刷し、それから手で足し上げて倉庫のピッキングリストと運転手の受渡明細を作ります。
  3. 配車の数字と在庫の数字が二つの別々の真実になる。 運転手に割り当てたのに ERP が引き落としていない品物。 あるいは在庫が尽きたのにシートは割り当て続けている品物。結果は配送の失敗、そして再配送の費用です。

三つ目は最初の記事がデータの分断と呼んだものの写しです。 ここではそれが部門と部門の間ではなく、ファイルとシステムの間にあります。

2. 改善とは実際に何をすることか

表計算を捨てることではありません。表計算をシステムの中へ移すことです。

  1. グリッド操作をそのまま残す。 キーボードショートカット、列での絞り込み、ドラッグでの複製、 複数行の貼り付け。再教育が要らず、さらに大事なことに、古いファイルへ戻る理由がなくなります。
  2. 自動でまとめ、便を組む。 地域別、路線別、積載量別 — 人がやると遅くてばらつく部分を、機械は速く、毎回同じやり方でこなします。
  3. 1便につき1回だけ印刷する。 倉庫が一度の巡回で集められる統合ピッキングリストと、 バーコード・停車地一覧・回収する代引金額・署名欄を載せた受渡明細。
  4. 便の承認は通知ではなく記帳である。 承認を押せば在庫が引き当てられ、出庫伝票が作られ、 代引金が正しい人の勘定に乗ります。これが表計算との本当の違いです。
ERP の中で列ごとに絞り込み・並べ替えができるグリッド表示の出荷伝票一覧
この記事が言っているのはこれです。表計算のようなグリッドが ERP の中にある。列で絞り込み、行を選び、表示件数を変える — 慣れた操作はそのままで、数字のほうは写しではなくシステム自身のものです。写っている306件は機械生成のデモデータです。

3. 四つの数字と、どれを信用できるか

A. 配車と倉庫の工数

月あたりの節約 = (配車の節約時間 × 配車の時間単価 + 倉庫の節約時間 × 倉庫の時間単価) × 稼働日数

最も堅い項目です。ストップウォッチを当てられる時間だけに立っているからです。1シフト測れば基準値になります。

配車2人 × 2.5時間 × 2シフト = 1日10時間、改善後は1時間 → 9時間の節約。 倉庫はピッキングリストの手集計に 1.5時間 × 2シフト = 3時間。(9 × 80,000 + 3 × 60,000) × 26 = 月 23,400,000 đ → 年 280,800,000 đ。

B. 早く出庫することで傭車が減る

早く出れば渋滞を避けられ、停車地を増やせます。ただしこれは 最も柔らかい 項目で、 本当に傭車費を払っている場合にしか成り立ちません。払っていなければ零にして、 もう一度合計を読んでください。残る額はそれでも大きいはずです。

一つ名指ししておく誤解があります。1日12時間の事務工数を空けることは、 トラックが12時間早く出ることを 意味しません。その仕事の大半は車両のクリティカルパスの外にあります。 実際に出庫を早める部分はずっと小さく、出典は1シフトおよそ45分と見積もっています。

C. 誤配が減る

節約 = 月あたりの件数 × 誤配になる割合 × 積み戻し・梱包し直し・再配送の費用

この種のミスの大半は不注意ではありません。4人が同時に開いているファイルで、 行が一つドラッグでずれたところから始まります。

D. 代引の突合が減る

受渡明細が運転手ごとの預り金を確定させるので、1日の終わりの足し算が消えます。 四つのうち最も小さく、1週間以内に最も簡単に確かめられる項目です。

4. 中規模の例

トラック15台とバイク20台、1日600件、配車は2シフト。

項目月あたり年あたり
配車と倉庫の工数2,340万2.808億
傭車が減ること1,500万1.80億
誤配が減ること300万3,600万
代引突合が減ること180万2,180万
合計(導入費用8,000万に対して)4,320万約1.85か月で回収

上の試算はこの表を再現します。四つのうち三つはぴたりと一致し、合計は0.3%以内、 回収期間は1.85か月に着地します。

5. 持ち帰るべきこと

人が Google スプレッドシートにしがみつくのは、それが便利だからであって、ERP に抵抗しているからではありません。 ここで動機を読み違え、間違った治療法を選ぶプロジェクトが実に多いのです。 新しいシステムが古い道具より入力が遅いなら、規定が何と言おうと人は古い道具へ戻ります。 表計算に勝つ唯一の方法は、表計算の操作感をシステムの中に置き、そのうえで 表計算にはできないことを足すことです。

そして様式の記事と同じく、これを早めにやる値打ちがあるのは、 いちばん大きいからではなく、使う人が最初のシフトで効果を体感するからです。

業務のやり方は、その脇を通る近道より速いときにだけ生き残ります。 便利な道具を取り上げておいて、もっと便利なものを返さないのは、導入ではありません。 規律に賭けているだけです。

数字は中規模の卸売業者を例示したもので、どの顧客のシステムから取ったものでもありません。 上の試算でご自身の数字に置き換えてください。

次に読む