【第100回】在庫談義

在庫管理は生産管理や生産管理システムの目的のひとつかもしれない。
適正な在庫を最小限維持してなおかつ生産活動が停滞しない在庫管理は製造業の理想のオペレーションといえるであろう。トヨタのかんばん方式も在庫を最小限におさえつつ必要量を確実に確保する管理手法である。
我々は生産管理システムを提供するベンダーなので、在庫というデータをどうとらえるかというのはとても重要なフィロソフィーである。
ところがみんな在庫を漫然と捉えていてその価値観も各人各様である。
そこで本コラム100回記念として、在庫データは生産管理システムの中でどう管理されるべきなのかを説明してみたい(ちなみに世の中の本は“生産管理”業務 と“生産管理”システムを同じ生産管理でくくってごっちゃにしていますが、そもそも扱う対象物がまったく異なる別の概念なのです。“生産管理”業務は生産 現場や在り物を扱うのに対して“生産管理”システムはデータを扱います。そもそも管理対象が全く異なります)。
まずは一般的な在庫管理とは何ぞや?を引用してみよう。


■在庫管理
在庫管理(ざいこかんり)とは、狭義の場合と広義の場合がある。
狭義の”在庫管理”とは、保管・管理される在庫物に対して、品質の低下・機能の低下とこれらによる価値(価格)の低下を最小限の費用で防止し、要求される搬入・搬出時の量と時間を十分満足できる状態に保つことである。
これに対し広義の”在庫管理”とは、狭義の”在庫管理”に加え、常に変動する需要(出庫数量)を満足するように入庫数量を確保することが加わったものである。生産管理との垣根は限りなく低くなっている。

在庫を抱えることはコスト要因になるため、在庫管理ではできるだけ在庫を少なく抑えることが目標になる。しかしながら、在庫が不足するとサービスレベルが下がる可能性があるため、在庫を持つことに伴う在庫コストと、サービスレベルをうまくバランスさせる必要がある。
なお、在庫補充のモデルは経営学における主要な研究対象である。経営学では、最適な発注量を経済的発注量(EOQ:Economic Order Quantity)と呼び、これを最適化する方法が研究されている。

【背景】
以前は”計画生産”という言葉で代表されるように、需要の伸びを見越した右肩上がりの計画が基となり、搬入(生産)された物をどのように出庫(販売)するかという点に力が入れられ、狭義の”在庫管理”が求められた。
しかし、需要がより多様化を求めるようになると、このような”計画生産”は用をなさなくなり、後には在庫が山と積まれる事態が生じた。トヨタ自動車のカン バンで代表される、”引取り方式”がこの問題の解決方法として浮上した1970年代後半、各企業はこぞってこれを導入した。これ以降、在庫管理とは広義 の”在庫管理”を指すようになった。

【在庫】
在庫には原材料、仕掛品、製品、輸送段階にある在庫、予備在庫等の区別がある。

【在庫の過不足】
在庫に過不足があると、例えば以下のような問題が発生する。
需要に対して製品在庫が不足すると、販売機会を喪失する。いわゆる「品薄」の状態。
原材料や部品の在庫が足りない場合には、製造が停止し結果として販売機会を喪失する。
製品在庫が多すぎると、販売しきれずに売れ残りが生じる。売れ残った製品は倉庫のスペースを圧迫し、流通や他製品の保管などに齟齬をきたす。売れ残りを避けるために乱売を行った場合には価格下落を引き起こす。
原材料や部品の在庫が多すぎると使い切れずに無駄に廃棄することになる。また部品価格が徐々に低下している場合、平均して高い調達コストをかけることになる。

【管理の方法】
在庫管理とは、簡単に言えば、製品の需要予測に応じて生産量及び製品在庫を決定し、それに応じて原材料・部品の調達量及び原材料・部品在庫量を決めるものである。しかしながら最初の需要自体が予測値でしかないなど様々な困難がある。

(以上、フリー百科事典『ウィキペディア(Wikipedia)』より引用)



数字というのは面白い概念であると思う。
弊社で実際にこういう問答があった。

A部長:「×××プロジェクトの見積りをお客様から求められているんだけど、
     ザックリどれくらいかな?現行システムで100本のCOBOLで、在庫
     管理と工程管理をやりたいみたいなんだけど」
B君: 「それだったら、1億2,436万7,890円かかります」
A部長:「ウソこけ!億単位の計算しかできないパラメータなのに、何で1円
     単位まで答えが出せるんだ。まるっきり根拠のない数字だろう」


数字というのは細かく表示すればするほど、一見正確に見えるのだが、計算の土台であり前提となる数字が億単位のデータであれば、当然出る答えも億単位にならなければならない。数字には同じデータでもその用途によって持っている付加価値が異なるのである。
例えば、健康診断で身長を計ったときに、「えー、身長は170cm47mm968ミクロンですね」と、答えられたら、この人は本当に真面目に自分の身長を測っているんだろうかと疑うであろう。
また、肉屋で100g、88円のひき肉を買おうとして、店員が量ったところ、「101.0023gなので88.882024円ですね」と言われたら、面倒くさくて買うのを諦めてしまうかもしれない。
同じデータでも使う人、使う目的、使う立場によって数字は変化するのである。
これは不正確ということではないのである。
生産管理システムがよく判っていないSEも同様に、在庫の数字は1つと思い込んでいるようで、1つのデータ(数字)を、生産計画担当も、物流担当も、経理 担当も、品質保証も、自動倉庫担当も、ピッキングステーション担当も、営業も、社長も、エンドユーザーも皆で使えると思い込んでいるようである。
これは大きな誤解である。
1つの品目の在庫のデータでもその姿は実に多様なのである。在庫データと現在庫は必ずしも同じ数字ではないし、また、それでよいのである。
昔のMRPの教科書では在庫の概念を以下のように分類している(以下引用)。


■製造工業における在庫という概念
前章で簡単に述べておいたように、米国ではMRPは工場内の在庫管理システムの1つの方法として説明され、理解されていることが多い。しかし、これは、 MRPに対するせまく、また旧い考え方なのであって、最近ではMRPは生産における4つの基本機能(プライオリティ計画、キャパンティ計画、キャパシ ティ、コントロール、プライオリティコントロール)をみたすためのシステムなのであって、在庫管理はその1つの副産物であると解されるように変わってきて いる。日本では工場での在庫は持つべきでない、あるいは持たないほうがよいという考え方がはびこっているから、在庫を管理(工場で)するといういい方はタ ブーである。
しかし、実はこれはタテマエなのであって、ホンネのほうはどうか、というえば“管理されない形での工場在庫”はゴロゴロしているのである。しかも、この在 庫は計画的に持たれたものではなく、計画、管理が拙劣なために、“結果として”生じてしまったものである。したがって、その管理はインフォーマル(かげで こっそり)に行われ、フォーマルシステムのもとに堂々と行われているものではないのである。
ここでしばらく、工場における在庫の正体をのぞいてみることにしよう。在庫のなかには計画的に発生させるもの、あるいは止むを得ず発生するものと、管理が 悪いために発生してしまうものとがある。両者とも経理的には資産とみなされるが、その性質は全く異なる。いままでの工場では両者を混同させてしまっていた が、MRPでは両者を分け、後者を省き、前者のみ(しかも、それもできるだけ少なくするように)を管理対象とするように努めるのである。このような在庫の 種類をあげてみよう。
工程から工程に移動する間に発生する在庫
ある工程の加工が終了したあと、つぎの工程の加工に移るまでの短期間の状態も一種の在庫とみることができる。
これを“在庫”と呼ぶことには異論があろうが、MRPでは明らかに在庫と考え、むしろ、これに積極的な役割を演じさせている。すなわち、前章で述べておいた、“in stock状態”がこれに対応する。

ロットサイズ化から発生する在庫
図2.9の計算では、第9週、第12週の所要量、それぞれ、700個、500個を第5週、第8週にそれぞれ同じ数量ずつ手配するようにしていた。すなわ ち、所要量をそのまま手配ロットとしていた。もちろん、これをさらに細かいロットに分けることもできるし、まとめて、たとえば第5週に1,200個のように 大ロットにすることもできる。MRPにおけるロットの決め方については、あとで項を改めるが、完全な連続生産にしない限り、ロットで作業されるのだから、 そこにある種の在庫が発生することは当然である。これをロットサイズ在庫という。ある政策をとったために止むを得ず発生した在庫であり、その政策をとる限 り、これをなくすことはできない。

変動から発生する在庫
需要量や供給量などが変動(fluctuate:フラクチュエート)するために生ずる在庫、あるいは投入量と産出量との間に差があるために発生する在庫で ある。たとえば、安全在庫とか、加工用機械(ワークセンター)の前で加工されるのを待っている仕事の列もそれである。この在庫を減少するには変動を押える とか、加工能力を相対的に大きくするとかしなくてはならないので、担当者レベルだけの努力では非常に難しい。MRPを使うとこの種の在庫は大幅に減少す る。

将来に備えるための在庫
将来、発生するであろう需要や要求に対し準備しておく在庫である。このほかには季節的に増大する需要に対応するための生産、大売出し前の生産、リードタイ ムの長い品物についての予測先行手配、休暇やストライキに対処するための事前生産なども含まれる。これも、政策を変更しないかぎり、あるいは何らかの方法 でリードタイムを減少しないかぎり、在庫量の減少をすることが難しいものである。

輸送中の品物
資材や製品がある地点から他の地点に輸送、移動させられているときに発生する在庫である。工場内で移動中の品物も厳密にはこの分類に属する。移動に要する 時間はリードタイムのなかに含まれるから、リードタイムに関係する在庫と考えてもよい(前述1.に述べておいた工程間在庫も広義にはこれに属するともみら れる)。これも、輸送方法を変えたり、生産、加工の場所を変えたりしなければ減少し難いものである。広義にはロジスティックスシステムであるから当然、 MRPの範囲であるが、輸送機能そのものはMRPの対象ではない。
以上は、いわば、止むを得ず発生する在庫であり、その発生の源泉に立ち入らないと減少させることは難しいものである。MRPでは1.については、これを加工の流れにおける in stock状態の情報源として利用し2.に対しては、従来の適正ロットサイズの考えとは異なる考え方を導入して本章の3で扱い、3.については、需要や要求の変動をそのまま受け入れ、必要量だけ生産する方法をとるのでマスタープロダクションスケジュール(第5章)で扱う。また、ワークセンターの前での侍行列についてはキャパシティの管理と考え、インプット/アウトプットコントロール(第8章)で論ずる。
4.の将来発生するであろう需要に対応する在庫に対しては、MRPではマスタープロダクションスケジュールの問題と考え、MRPそのものでは取り扱わない。5.の輸送、移動についてもMRPに対する所与条件と考えるので、範囲外である。

 (以上、「MRPシステム」吉谷龍一/中根甚一郎 著、日刊工業新聞社、P63~66から引用)



今までの生産管理システムは(生産管理ではない。生産管理は現場や在り物を扱い、生産管理システムはその写像である生産管理データを扱うので、そもそも管 理する対象物が異なる)現場の写像をそのままシステム化したので、在庫も在り物(現物)のデータしか管理しなかった。過去や未来のデータは管理してこな かったし、また管理できなかったのである(コンピュータのリソースと能力も限られていました)。
これからの生産管理システムは従来の在り物のみを管理したデータベースから、データを時間軸と空間軸(View)で仮想の状態で連続的に管理しなければならないのである。
そしてまたそれを様々な用途目的に応じて多元的に利用できなければならない。
たとえばここにAという品目があったとする。
いままでの生産管理システムは現在の100個という数字をデータベースにもっているだけであった(入出庫の記録は残っているかもしれませんが一瞬で取り出 せないとあらゆる計算はできません。まして入出庫番号のようなキーがついているとそれだけでデータの連続性をファイル間でとることは困難です)。過去の データも未来のデータも管理していないので、多年度の原価であるとかリアルタイムな原価であるとか、未来の原価は全く算出不能である。
また今日の需給変動が未来のデータをどう反映するかを記録する場所もない。
未来のデータがないということは未来の在庫を使った擬似MRPをまわすこともできないということになるのである(ちなみに未来の時間軸に向かってMRP計算を擬似的に実行してシミュレーションすることを筆者は立体MRP計算と呼んでいます)。
筆者の設計する在庫データは過去から現在、現在から未来へと時間軸をもって管理される。
過去から現在までのAの在庫データを何に使うかといえば、Aという品目の5年分の原価を算出したり、リアルタイム原価を算出したりするのに使用される。その際に過去の在庫の変動値は連続的に必要になるのである。
また、現在から未来へとなると、需要予測をしたり、生産計画を立案したり、未来原価を決定するための未来原価を算出したりするために必要となる。
現実の工場の建屋にない在庫情報も生産管理システムでは重要な計算要素なのである。

たとえば、家のお金というデータがあったとする。家のお金の過去のデータは何に使うかというと、来月、再来月の家計の支出を予測する基礎データとして使用 される。一年分の過去データがあれば年収を算定する根拠にもなるだろう。これがもし現在のデータしかなかったならば、1ヶ月先、2ヶ月先の支出を予測する ことができないので、現時点でいくら使えるお金があって、いくら貯金しなければならないかも判らないであろう。
それゆえ、データのみでは未来をコントロールすることは出来ないのである。
在庫データを連続的に持つことによって未来のデータで未来のMRP計算をまわすことができる。この考え方がエンジニアリング・チェーン・マネジメントの最新理論である、立体MRPという考え方である。
また、家のお金は見る人の立場で様々な属性にフィルタリングされる(Viewによるデータのフィルタリング)。例えば、食費、娯楽費、交通費のような変動 費、家賃、小遣い、ローンの支払いのような固定費である。こうした使う立場で在庫のデータをフィルタリングすると、在庫の属性は以下のようなViewで フィルタリングされ、それぞれの立場でまるめたデータとして活用される。

 1. 製品属性(キー:製番、品番)
   生産計画、MPS、需要予測、原価等の属性
 2. 場所属性(キー:倉庫、ロケーション)
   物流、需給ルート、等の属性
 3. 荷姿属性(キー:パレット、ロット)
   入庫、出庫、ピッキング、倉庫管理の属性
 4. 保管属性(キー:棚、段、アイル)
   ピッキング、倉庫管理、入出庫、等の属性
 5. 発注(購買)属性(キー:発注先)
   発注仕入先等の切り口からの属性
 6. 経理原価属性(キー:原材料品目、仕掛品、完成在庫品目、中間在庫品目)
   原価計算、売上、販売管理、支給品管理等の属性


以上のようなカテゴリー別に在庫データは用途別に管理されなければならない。
当然、それぞれの切り口で管理精度も異なる。こういう属性の切り口多元化をしていないと枝番や連番や意味有りコードを多用して在庫のアルゴリズムを品目番 号に付加するような運用をしてしまいがちであるが、これをやるとシステムの透明性が損なわれ、長い間の業務の変化に耐えない、硬直的なシステムができあ がってしまう。
あくまでも、“データをして語らしめよ”という設計原則は貫かれなくてはならない。これが鉄則である。
倉庫の入庫ステーションの受け入れ担当は受け入れた瞬時の在庫の変動を記録するが、生産管理の立案担当の使用する手持ち在庫の値はタイムバケットの期間のアベレージでよいのである。丸める単位もデータ更新のタイミングも異なるのである。
こうしたデータは上記のキーを巧みに組み合わせた在庫データ群として管理してよいのである。

使用するViewによって抽出されるデータはフィルタリングされる。
そしてそれらすべてのデータが連続的に管理されるのである。
このデータベースを統合化在庫マスタと呼ぶのである。
これがエンジニアリング・チェーン・マネジメントの次の中核を担うデータベースとなる。