在庫のイメージから入りたい方は、まず『在庫ロケーション』でGoogle画像検索してみてください。
なるほど倉庫だな、という画像が確認できるかと思います。
次に、自社、あるいは関わった案件について、いち企業の在庫、いち部門の在庫がどれほどあるのか、想像してみてください。
この想像がつくのなら、もう十分な水準だと思います。
私自身はそこまでたどり着いていなくて、「あれとこれと、これを調べていけば分かるかな」という、調査手段を連想できる程度です。
倉庫を管理している人、工場を管理している人であれば、どこそこに凡そ何トン、何万個、金額にして約○○億円、のような概数まで把握なさっていると思います。
彼らの頭の中では、物理的な（現実の）保管場所があります。何階建てで、どのような区画があり、どこにエレベーター、搬入経路、搬出経路、など。
但し、最新の数量は、毎日自分の目で確認する訳にはいきません。システムの画面や帳票で教えてくれる数字を見ています。よって、システムが止まれば、最新の数量は分からなくなります。
物理的な倉庫のイメージと、データを頭の中でリンクさせる為には、データの粒度が現実と対比できなければなりません。
「工場の倉庫にある」では大雑把すぎて分かりません。
「工場のＡ倉庫の中にある」でも探せません。Ａ倉庫が狭ければともかく。
「工場のＡ倉庫の１階にある」で、分かる場合もあると思います。が、もう少し管理したい。
何故なら、在庫は常に動くものであり、毎回、急いでいるものだからです。
倉庫から取り出す（出庫）ときは、誰か必要としている人（仕事）がいます。
お客様への出荷かも知れない、製造現場への搬入かもしれない。
その時に、「どこにあるんだろう」なんて探している暇はありません。
自分が探している間に、次の出庫依頼で訪れた担当者が来て、なんて状況は倉庫内が混乱します。
倉庫は、収納力と入出庫効率など、様々な要素のバランスで最適化されているので、何人もウロウロしているスペースはありません。
では、データの要件として求められる粒度はどの程度かというと、私の感覚では下記のようなレベルです。
例）福島工場 － Ａ倉庫 － １階 － １３番置き場 － 棚Ｎｏ５ － ３段目
システムで在庫データを扱うシーンは多岐に及び、「ユーザー業務の流れ」の殆どは、直接間接に在庫へと繋がります。
それらのユーザー業務、例えば前述の出庫だけでなく、入庫も急いでいます。
入出庫の前には、出庫指示や入庫指示が行われています。これらも誰かが目と手で行っている訳で、やっぱり急いでいます。
急いでいるから効率的で高い操作性のシステムが必要、且つ、在庫データをキッチリ管理できないと、システムが成り立たない。
結果、データベースでは詳細な粒度で管理するものの、業務画面ではショートカットできる（エコ入力できる）ことが求められます。
複数の意味を纏めたり、途中までの指定で一意に決まるものはシステムが自動判断したり、といった工夫を仕込んでいきます。
例えば、下記のような纏めを行います。
| 場所 | 場所コードで、「住所」まで判別可能とする。在庫場所マスタ管理で、工場／外部倉庫の別、電話番号等を管理する。 |
| ロケ | ロケコードで、「建屋」「フロア」「置き場所」程度まで判別可能とする。ロケマスタ管理で、室内か屋外か、危険物の保管可否、空調設備（設定温湿度帯）※等を管理する。 |
| 棚No | 棚Noで、ロケ内の棚を特定可能とする。棚Noマスタは設置しなくてもよい。ロケマスタの中に、一覧として登録し、Noの存在有無が判別できる程度でも問題ない。当然ながら、目的がある環境では、設置する。 |
※ロケについては、必要に応じて温度／湿度などを管理することも求められます。
※保管する在庫が劣化しにくい環境を備えているかどうか（当該製商品を保管してもよいかどうか）を人間／システムでチェックする際に利用する為です。
これらの情報を各在庫データにつけることが出来れば、何がどこにあるかは分かるようになります。在庫場所別の集計なども可能になります。
一方で、在庫データにこれらの情報を付けるということは、「在庫の動きがある度に、これらの情報を指定し続ける」必要があることを意味します。
在庫を動かす時だけではありません、動きに繋がる関連業務全てになります。
例えば、販売管理から、出荷するためのロックをするにも指定が必要、製造した製品を入庫するにも必要、倉庫間で移動するにも必要。予定（計画）と実績でそれぞれ必要。
システム的には、色々と支援が出来るところです。
「場所」と「品番（或いは品目グループ）」が分かればロケを自動判定する、そんな感じの検討を考えられるだけ考えます。
大規模な在庫場所では厳密に管理しながら、小規模な在庫場所では自動判定するような工夫も考える必要があります。
特定の業種、特定の企業に応じて、効率化の考えどころですね。いわば心臓部の在庫データ、効率的で柔軟な扱いが出来るかどうかで、全体の質が左右されます。
「ロケ」を2段階に分割することもありです。
逆に、「ロケ」を持たない管理もありです。
例えば、在庫場所に余裕がある、あるいは取扱い品番数が少ない場合などは、「個々の在庫データにロケ情報は持たない」という管理が成り立ちます。
ルールとして、「この品番はこの場所にしか置かない」と決めてしまって、関係者共通の「当たり前」を作り上げてしまうやり方です。効率さでは、随一です。（収納力はダウン）
このような感じで、在庫ロケーションというものが管理されています。
いつも以上に乱文になってしまい、申し訳ないです。
在庫に関しては、波及範囲が広すぎて、更に周辺機能に与える影響が大きすぎて、僅かな側面を話すだけでも長くなってしまいます。
複雑極まる在庫管理、これを複雑なままシステム化したのでは、拡張コスト・運用維持コストが非常に高くなり、システム全体が少しずつ腐っていきます。
システム実装を記事にするときは、保守性・柔軟性のあり方についても触れていきたいと思っています。
一概に言えない要素が多数存在し、特効薬はない世界ですが、一つ一つは決して難しくありません。
一気に全部を考えると混乱するだけです。
今後、史記の列伝を参考に、少しずつ角度を変えて記事にしていく予定なので、読み物感覚で気軽に読み、イメージを組み立てていってください。