発注の手間を減らす方法

適正在庫にお悩みの方にここで質問です。

次の発注間隔のうち、どの方法が一番在庫を減らせるでしょうか？

1. 半年に１回の発注をする
2. ３か月に１回
3. １か月に１回
4. 1週間に１回の発注をする

答えは、４ですね。
発注間隔が長くなればなるほど、在庫は増えます。

在庫が増える最大の原因は何か？

在庫を増やす要因は次の２つです。

1. 日数在庫
   在庫は少なくとも発注間隔分だけ持たなければいけない。
   例えば、１か月に１回であれば、１か月分の在庫量が必要です。
2. 安全在庫
   予測期間が長くなればなるほど予測精度は低くなる。
   １か月先の事よりも、１週間先を読むほうが精度が高くなります。
   さらに、安全在庫は日数分必要なので、精度以上により多くの在庫が必要です。

高い発注精度は、短い発注間隔

発注者として一番やりたいのは、「精度の高い発注数」ではないでしょうか？
それを実現するためには、難しい需要予測をするのではありません。
適正在庫の基本は発注間隔を短くすることに尽きます。
それは、在庫日数と安全在庫の点から見ても明らかです。

ただ、下記４つの条件が揃うのであれば、発注間隔はどれだけ長くても
良いと思います。

• 置き場の制約が無い
• 在庫金額の制約が無い
• 不良在庫（滞留期間）の制約が無い
• 期限切れ（品質保持や終売）の制約が無い

普通の会社であれば、恐らく何らかの制約はあるはずだと思います。

発注を妨げる制約条件

次のような制約条件がある場合に限っては、制約に従った発注が
必要です。

仕入先との発注条件

仕入先と発注条件を決めている場合があります。
適正在庫を考えるうえで最も大切な発注条件は、発注間隔に関することです。
もし、仕入先との取決めで「１か月に１回しか発注をしない」といった
ような発注条件であれば、１か月に１回の発注にせざるを得ません。
発注条件の取決めが無く、毎日発注しても受注してくれる仕入先であれば、
毎日発注を目指すのが良いでしょう。
資金繰りの観点からも発注間隔は大切な指標です。
１日の使用量10個として、シュミュレーションしてみます。
（現金仕入れ、現金払いとします）
１か月に１回発注、仕入れ単価100円、販売金額200円

• 仕入れ金額は、10個×30日×100円=30000円。
• 原価を回収できるのは、30000円÷200÷10＝15日
• 仕入れ金の回収は20日後。
  仮に１週間に１回の発注に切り替えて、単価を20％ＵＰ
  にするとどうでしょう？

１週間に１回の発注、単価を120円、販売金額200円

• 仕入れ金額は、10個×7日×120円=8400円。
• 原価を回収できるのは、8400円÷200÷10＝4.2日
• 仕入れ金の回収は約4日後。
  資金繰りの観点から行けば、約3.6倍になります。
  資金繰りが厳しい場合には、単価を少し上げて発注間隔を
  短くすれば、資金繰りは一気に改善させることも可能です。

配送スケジュール

特に船を使っている場合は、１週間に１回しか出港しない。
という条件が付くため、発注間隔を短くするのを妨げることが
あります。

船便の場合は、配送量（コンテナ）などの制約もあり、
より在庫を増やす原因になります。

上記のような場合は、制約条件のめいいっぱいのところで発注をして
出来る限り発注数を減らします。
ただ、契約や方法の見直しによって変更することができるのであれば、
検討の余地はあるでしょう。

物流費

発注間隔を短くすると、当然配送頻度が増えます。
そこで気になるのは、「物流費」です。
物流費は、仕入原価と捉えます。
ここでも１つシュミュレーションしてみます。

１か月に１回発注、仕入れ単価100円、販売金額200円、使用数10個／日
購入ロット：500個、物流費2000円

• １個当たりの物流費：2000÷1000＝2円
  ‐原価率51％（仕入原価：102円）
• １回の購入金額＝100×500＋2000＝52000円
• 原価を回収できるのは、52000円÷200÷10＝26日

１週間に１回発注、仕入れ単価120円、販売金額200円、使用数10個／日
購入ロット100個、物流費2000円

• １個当たりの物流費：2000÷100＝20円
• 仕入原価70％
• １回の購入金額＝120×100＋2000＝26000円
• 原価を回収できるのは、26000円÷200÷10＝13日

特に資金繰りが厳しい時は、物流頻度を高めると良いでしょう。

発注の手間を減らす方法は基準値を決めること

発注間隔を短くしようとすると問題になるのが、
「発注する手間」です。
発注では、発注する手間をいかに減らすかがポイントです。
実は、この発注する手間を減らすのが、発注のスパンを問わず
発注作業の効率を上げる一番大切な「カギ」になります。

発注作業の目的は何か？

発注作業でやることは、「発注が必要な在庫を見つける」ことです。
これまで、様々な会社でコンサルティングを行いましたが、
「発注が必要な在庫を見つける」ことに時間と労力を使っている
ケースがとても多いことが分かりました。
つまり、発注が必要な在庫を見つけることさえできれば発注作業
の効率を大幅に上げられます。

発注のトリガーが分かる基準値を設定する

「発注が必要な在庫を見つける」ための基準値を設定すればいいのです。
基準数は、

• 在庫数が●●個より少なくなった時
• 在庫が●●％減った時

など、何らかの情報を基に基準値を作ります。
その基準値を超えたものだけを発注対象にすれば良いので、
全明細を見る手間は省けます。

基準値は定期的にメンテナンスしなければいけません。

システム上で発注数を決めるために必要なこと

発注数の決めるための簡単な公式は、

発注数＝現在庫数－使用数（予定数）

現在庫数がシステム上で分かっている事が一番大切な情報です。
システムで発注する前提は、「システム上の在庫数量が正しい」ことです。
現在庫が狂っている（分からない）と、精度の高い発注はできません。

例えば、 現在庫が分かるのが月に１回の在庫確認作業（棚卸等）であり、
そのため月に１回しか発注できないという理由であれば、それは制約条件には
なりません。日常管理で十分解決できます。

まず、システム上で現在庫を分かるようにすることが必要になります。
「システム上で現在庫を分かるようにすること」 を実現するためには、
日常の入出庫作業をキチンと行い、その結果を毎日システムに入力することです。
バーコードやＱＲコードを使った入出庫作業であれば、システム入力は不要です。

システム無しで発注数を決める方法

システムを導入していくても大丈夫です。
システム無しでも手間なく発注することができます。

「発注点」を活用します。
置き場に「●●個になったら連絡してください」といったようなものを作っておき、
その数量になった時に、現場に連絡をしてもらう方法です。
これであれば、システムは無くても発注できます。

この方法でも決めなければいけないのは、「発注点」です。
発注点の決め方は、
発注点＝１日の使用数×仕入のリードタイム＋安全在庫

基準値は需要動向でメンテナンスする

一度設定した基準値は、必ず見直しが必要です。
需要動向は、刻々と変化するためです。

使用数量の動向は必ず記録しておかなければいけません。
需要動向を基に、基準値を定期的に見直し、欠品・過剰在庫を
未然に防ぎます。

発注間隔が長くても良い在庫は無いのか？

「計画の修正」が少ない在庫は発注間隔が長くても良いです。
計画の修正とは、当初決めた数字（発注数・納期）が理由を問わず「変更」されることです。計画の修正によって起こる発注の変更は次の通りです。

1. 数量の追加
2. 数量の 減少
3. 納期調整（前倒し、先送り）
4. 発注の削除

仮に１か月に１回の発注にしたとしても、「 計画の修正」によって発注の調整や変更をしていれば、都度発注をしているのと全く同じです。

最初に決めた数字に変更が無い（少ない）のであれば、
頻度を減らしてもいいと思います。
ただし、極端に言えば「大量に発注しておけば」発注頻度は少なくて済みます。
なので、ここでも基準を持つ必要があります。
例えば、下記のような基準です。

1. 「少ない」：１か月間の修正が●●回に収まっている。
2. 「在庫日数」： １か月間の在庫日数が●●日以内に収まる。（安全在庫込み）
3. 「在庫金額」： １か月間の在庫金額が●●円以内に収まる。 （安全在庫込み）

この定義が決まっており、設定した基準に収まる品目であれば、
発注間隔を長くして、発注回数を減らす一つの方法として検討する余地はあります。

発注方法をミックスして手間を減らす

多くの企業ではなぜか発注方法が１つになっているケースが多いようです。
しかし、発注方法を１つに限定しなければいけないといったルールはありません。
使用の動向や、システムの活用状況などによって、
品目によって変えて良い（変えるべき）だと考えています。

発注作業に必ず必要なこと

いずれの方法を取るにしても、次の２点は絶対にやらないといけないことです。
１．現在庫の把握
２．基準値や定義を作る

上記２つをクリアしない限り、仮に発注間隔を延ばしたとしても
確認・修正作業が頻繁に発生するため発注の手間は絶対に減らないでしょう。

発注作業を減らすために

在庫管理110番では、現在庫を減らす方法、データ管理の効率を
上げる方法を在庫管理の教科書にまとめています。
詳しくはこちら