いよいよ私の得意分野。MRPです。
-1、受注所要量計算
算数としては単純です。
現状の受注済型式・台数に部品表を掛けて、使用部品数を計算するんです。
ただし、１製品でネジ類を除いても数百の部品を使うし、受注の都度その受注品をいつ作るか仮に決めて、日当たりで結果を出し、現状在庫と納入予定を加え、日々の部品毎の在庫数を計算するのです。
計算の規模がべらぼうになります。
DCの生産管理システムでは、３回/日、システムが自動計算してました。
たいして大きくないサーバーでもそう時間をかけずに出来てました。
これは、システム設定の妙です。器械にとって不合理だが人間にとっては楽ってのが、システムを考えていくといくつも出てくるんですが、それを”これは器械に譲ろう、ここは器械が頑張って”ってのが設定です。
結果として、どの部品がいつなくなるのか常に判る状態が手に入りました。システムが警告を出してくれますから。
私は、”親会社のホストコンピューターが使えなくなる”＝”独自のシステムを導入しなくちゃならない”って状況を初めて知った時にかなりワクワクしました。
私は、社内で実務家としてはダントツに理解度が高い自負が有ったので、新しいシステムをどうするかってなった時に担当者として自分が選ばれるに違いないという確信があったのです。
というより、あんな事もこんな事もしちゃったからなぁ、選ばれなかったらどうしようって感じでしたが。（笑）
勿論、私が関われるのは情報管理屋がどのシステムを使うか選定し、選ばれたシステム屋さんが会社に乗り込んできて、「さあどういうのが欲しいのっ？」てなってからでしたがね。
幸福な１年間でした。それまで欲しくて仕方が無かった、いろいろな情報が手に入る環境を自分が作れちゃう。
しかも、こっちが勝手にくっちゃべった事をシステム屋さんが常に議事録を取り、私のランダム系の記憶力が悪い欠点を補ってくれるんです。
もちろん、ここはやばいってところは上司に相談するんですが、当時の上司は頭のいい人だったので、そこはツーカーで大概私に賛成してくれました。
－２、予測所要量計算（勝手にMRP fc と訳してました）
それまでのホストコンピューターは、動き出すとあっという間に結果が出ますが、動かす前後に手間が掛かる印象で、日に３度も計算するなんて芸当は出来ず、２回/月がせいぜいでした。
なので所要量計算もシンプルで、受注済・受注予測を分けずに全型式を月単位でぶち込んで月単位で結果を見るやり方でした。
ところが、新システムは日々計算をしています。なので、受注済分は計算済、予測分だけを追加する方法が必要でした。結構、実務家としてはめんどかったりするんです。
一旦、受注済の生産計画を所要量元表に取り込んで、それに穴を埋めるような入力方法で営業に入れて貰ってました。
それでも何台分かはダブって「あれ結果がおかしいぞ、何だ何だ」なんてこともしょっちゅうでした。
いろいろなアイディアをぶちこみましたよ。
例えば、安全在庫。
このぎざぎざのグラフは、手配システムを作る時に嫌と言うほど見せられました。https://enterprisezine.jp/iti/detail/3890一体いくつ余裕を見れば欠品せずに当たらない受注予測の下で、多すぎない在庫で済むかという問題です。
使用数の少ないものは固定数、多いものは使用数に対する比率、とここまでは通常どんなシステムも持っています。が、「これで良いですね」って念押しされるんです。すると何か引っかかる。
「ちょっと待って」つって、１日考えてみました。
1回/月取入れの部品が月初にもう余裕が0に近くなったら、誰でも当月分で補充を考える。でもそれが月末で、次の月初には新たな納入があるって判ってたら何日かなら安全在庫が少なくても良いかなって思うでしょ。
また、当月分の取入れを月半ばに追加するんですから、少ないにこしたことはないんです。いたずらに取引先に無理をさせる事になりますからね。
それをシステムに取り込めないかって考えたんです。
結果は”変動在庫数”。安全在庫を月初から月末にかけて漸減する方法です。DCのシステムにはこれが入ってます。これで特許を取ろうってシステム屋さんに言った時の対応が面白かったです。
大慌てで拒否されました。面倒なシステムを作れって言われてでも、システム屋としてのノウハウになるからつって嫌々引き受けたのに特許までなんて冗談じゃぁない、それでは自社のシステムとして次の顧客には使えなくなる。勘弁してくれって感じでした。
逆に彼らが慌てたので、結構、いい線行ってんだなって思いましたよ。
0 件のコメント:
コメントを投稿