新人必修!在庫数の計算問題

中小企業の現場で求められている在庫管理とは、「いま、その商品があるのかないのか」 「どこに何個あるのか」というシンプルなレベルのはず。 にもかかわらず自動発注システムまで活用している中小企業が少ないということは、現在理論在庫数を正しく計算することがいかに難しいかということ。


若ゾウ諸君のための練習問題

じゃあ今日は、
在庫数計算の練習問題をやってみようかね。
キミがプログラマの卵で、
これから業務アプリに取り組む立場なら、
きっとおもしろいぞ。
簡単な四則演算で済む計算トレーニングなんだが、
基幹系業務全般と関わってくるという、
なかなかやりがいのある課題だ。
ひとくちに「在庫管理」といっても、
その意味する範囲はあいまいなので、
このテーマを持ち出すときは、
どの範囲の在庫管理を指しているかをはじめに明確にしておく必要があるな。
わたしがこの場で取り上げる
在庫管理
とは、
もっとも単刀直入に
在庫数の計算

指している。
在庫金額の計算もテーマに含まれるが、
置き場所の問題(どの倉庫のどの棚にあるか)とか、
ピッキング方法とか、
賞味期限とかは扱わない。
中小企業の現場で求められているものは──
いま、その商品があるのかないのか?
どこ(店とか倉庫とか)に何個あるのか?

で、
ほとんどの場合、
問題はずいぶんシンプルなのだ。
在庫数の計算が正しく行われさえすれば、
補充のための発注などは簡単に自動化できるし、
定番品であれば需要予測に基づく発注コントロールもそれほどむずかしくない。
なのに、
中小企業で自動発注システムまで活用しているところがほとんどないということは、
現在理論在庫数を正しく計算する
という
たったそれだけのことが
よほどむずかしいんだろうと推測できるね。
別のページですでに述べたことの復習になるが、
この式をもういちど復習しておこう。
過不足=仕入-売上+生産-消費+発注-受注+生産予定-消費予定
製造業でなければこの式はもう少し短くて
過不足=仕入-売上+発注-受注
だったね。
つまり、
もっともシンプルな四則演算だけで済ませられる在庫数の計算でさえ、
仕入管理や販売管理や受発注管理や生産管理という、
企業の基幹系業務の中枢データベースからデータを引っぱってくる必要があるってわけ。
あ、いま、
「データを引っぱってくる」って言ったけども、
これは実は適切ではないな。
在庫数を知りたいときに、
いちいちそれぞれのデータベースを読みに行ってたんじゃ、
よけいなまわり道が多すぎて効率的じゃないんじゃない?
‥‥くらいのことは
若ゾウ諸君でもわかるよね?
いちおう念のためにことわっておきますが、
在庫管理のためだけに、
別途データを入力するという話はここでは論外ですよ。
販売管理や受発注管理で日常的に行っているデータ入力によって、
それ以上の手間をかけずに理論在庫を増減させるという話でなければ本末転倒。
モノと伝票(すなわちデータ)がいっしょに動く
というのが商売の原則なのでね。

理論在庫の計算ステップ

まぁ、そういうわけなので、
この在庫数の計算問題は、
ニーズの高さに反してそのニーズが満たされていない率がきわめて高く、
業務アプリの開発スキルをこれから磨きたい若ゾウ諸君にはちょうどいい教材なわけだ。
やがて経営の全域に関わっていく学びの多い話なので
聞いておいて損はないぞ。
さぁ、
そこで例題。
コード番号が「333番」である「部品Z」の最近の出入りを下記のとおりとしよう。
▼2012年4月の「部品Z」
02日 棚卸 90個 受注残が20で発注残はなし
04日 販売 20個 02日より前の受注に対するもの
07日 受注 30個
09日 販売 30個 07日の受注に対するもの
10日 発注 50個
12日 仕入 30個 10日の発注に対する分納1回め
12日 受注 50個
14日 発注 70個
15日 販売 40個 12日の受注に対する分納1回め
15日 照会1
18日 仕入 20個 10日の発注に対する分納2回め
22日 販売 10個 12日の受注に対する分納2回め
25日 仕入 20個 14日の発注に対する分納1回め
25日 受注 90個
25日 照会2

質問その1
4月15日現在の「部品Z」の理論在庫は何個でしょう?
質問その2
「部品Z」は4月15日の時点で、
けっきょく足りているんでしょうか、
それとも足りないんでしょうか?
質問その3
では4月25日の時点では、
「部品Z」はいくつあるはずでしょうか?
それで足りるんでしょうか?
──はい、
いかがですか。
最初の質問はわりと簡単だね。
棚卸の時点で90個あったものが、
販売されると数が減り、仕入では増える。
受発注を除く動きは以下のとおり。
02日 棚卸 90個
04日 販売 20個
09日 販売 30個
12日 仕入 30個
15日 販売 40個

 現在理論在庫 = 90-20-30+30-40 = 30
正解は30個です。
で、
4月15日の時点で30個の在庫があるってことなんだが、
これでこの部品は足りているのかどうか。
追加発注しなくていいのかどうか。
それを調べるためには受注残と発注残を合計する必要がある。
単純に受注の数と発注の数を足すのではないことに注意だな。
注文をもらっても、
それに対してすでに商品を出荷(販売)したならそれは数えなくていいってこと。
なので受発注だけを抜き出してみると──
02日 受注残20個 →04日に販売処理済
07日 受注 30個 →09日に販売処理済
10日 発注 50個 →12日に30個の仕入処理→あと20個
12日 受注 50個 →15日に40個の仕入処理→あと10個
14日 発注 70個

という具合で、
未処理の残数としては、
発注残(増える見込み)が90個と受注残(減る見込み)が10個ある。
 過不足 = 30+90-10
の計算により、
残りの受発注がすべて処理されても110個残る
という意味で、
在庫は「足りている」といえる。
さて、
あらためて‥‥
ある品目の在庫数を知りたいとき、
売上、仕入、受注、発注、生産、消費といった
別々のデータベースに散らばった在庫増減に関わるデータを、
いちいち読みに行ってたんじゃ処理速度的にもロスが大きすぎる。
ではどうするか?

最適アルゴリズムの検討

とりあえずクラウド播磨王が採用したベストアンサーは、
在庫増減ジャーナル
とでも呼ぶべきグローバル変数を、
売上、仕入、受注、発注、生産、消費、などのその他のジャーナル入力の際に、
ついでに生成させておくという方法。
在庫計算に必要な最低限の情報(処理内容、品名、日付、数量)だけが、
あらかじめ別のグローバル変数として書き出されるようにして、
なおかつその在庫増減ジャーナルは、
もちろんはじめから品名毎にインデックスされてアクセスが最速になるように考えておく。
在庫照会のリクエストは、
この例題と同様に2つのパラメータをもっているよね。
つまり
  • 品名コード‥‥在庫数を知りたい品目のコード
  • 日付‥‥いつの時点の在庫か

の2つ。
上の例であれば、
コード「333」の商品について「4月15日」現在の在庫情報が知りたい
という具合。
そこでさっき、
キミらが質問1~2に答えたのと同じ計算ステップをシステムが通るわけだ。
じゃあ次に3番めの質問だが、
コード「333」の商品について「4月15日」現在の在庫情報が知りたい
というリクエストに対して、
キミたちの脳はどう反応するだろうか?
4月15日までの計算はさっきやったから、
次の日からの変動分だけを計算しようとするはずだな?
わざわざもう1回、
4月2日の棚卸からやり直したりしないわな?
つまり、
同じ計算を何度もくりかえすのは無駄だと考えるわけだが、
それと同じように、
システムにも同じことをさせない工夫が必要だね?
在庫照会リクエストを受け取ったシステムが、
計算ステップを最短にするために、
在庫計算完了日付
っていう変数を準備しておこう。
○月○日までの在庫計算はもう終わってますから、
ここまでの計算をくりかえす必要はありませんヨ

って日付のことだ。
はじめて在庫照会のリクエストが来たときは、
在庫計算完了日付はセットされていないので、
棚卸が行われた日が
実質的にそれと同じ意味になる。
システムは、
在庫計算完了日付から、
指定された日付までの在庫増減ジャーナルを調べ、
足したり引いたりして現在理論在庫と過不足を計算する。
そしてまた
「この品目についてはいついつまでの在庫計算が終わってますよ」
ということを示す在庫計算完了日付を更新する。
基本はそのくりかえしなんだね。
例題に戻ると、
質問その1~2が終わった時点で、
キミたちの頭の中の在庫計算完了日付「4月15日」だ。
15日 在庫 30個 発注残90で受注残10 ←これがすでに計算で導き出されている
18日 仕入 20個 →発注残が90から70に
22日 販売 10個 →受注残が10からゼロに
25日 仕入 20個 →発注残が70から50に
25日 受注 90個

上のとおりの推移によって、
仕入分が増えて販売分が減るので
 現在理論在庫 = 30+20-10+20 = 60
発注残(増える見込み)は50に、
受注残(減る見込み)はいったんゼロになるが
25日の新規受注で90に増えるので
 過不足 = 60+50-90 = 20
ということで、
きわどいところだがまだ足りている‥‥という計算結果になります。
Σ(・ω・;|||

つくってみるか?在庫アプリ

実際のアプリケーション構築にあたっては、
販売、仕入、受発注データなどの修正や削除によって、
在庫計算完了日付よりも前の日付のデータが変更になることが頻繁に起こる。
そういう場合、
いったん在庫計算完了日付は無効にして、
棚卸まで戻ってやり直しってことになる。
とても大切な前提は、
販売データ、仕入データの入力時に、
それぞれ対応する受注データ、発注データの残数を消し込みながら入力するってこと。
同様に、
生産データや材料消費データの入力時には、
対応する計画データの残数を消し込みながら入力する必要がある。
つまり、
在庫の過不足を正確に日々追跡していくためには、
販売、仕入、受発注、さらには生産、材料消費、
組立のある場合は部品管理にいたるまで、
幅広く整合性の取れたIT化が前提となる
わけだ。
ε=( ̄。 ̄;)
と、
ここまで読んで、
>いちおう話はわかったけど、
>だったらここでこんな矛盾が出てくるんじゃないのか?

くらいのスルドい突っこみを入れたキミは、
プログラマとしてじゅうぶんやっていけるだけの才能はあるだろう。
よく意味がわからず計算も合わず、
くじけそうになっているキミも、
最後まで読んだだけでエラいw(゚o゚)w
きっと先輩からかわいがられる存在になるだろう。
それぞれの道をたくましく行けよ ̄O ̄)ノ