生産管理システムの導入から運用まで幅広くサポートします
株式会社アルカス
資料請求

f-MRPについて


ここでは、TPICSの「f-MRP」について解説します。
(長いページですがご容赦ください)

その1:雑誌「工場管理」'89/10号"緊急提言"原稿抜粋
株式会社 ティーピクス研究所 二ノ宮 良夫氏(社長)

生産管理のコンピュータ化と言うのは、全く厄介なもので、やって行くと本当に次から次へと難問が出てきます。
そして、実に多くのユーザーが、「過去」失敗してきました。
それらは夫々色々な問題が重なりあい「不幸な結果」に至ったわけですが、私は大きな問題の1つが、従来の”MRP”そのものの中にあったと思っています。
コンピュータ生産管理の”考え方”の代表である”MRP”は、それ自身非常に大きな問題をはらんでいるのです。

この「緊急提言」では、
従来のMRPシステムに内在する本質的問題点を浮き彫りにしながら、その解決方法として当社の「生産管理システムTPiCS-V(注:現在はTPiCS-Xに継承されています)」で採用している”フレキシブルMRP(f-MRP)”の考え方を提言したいと思います。



「営業は 今日、明日の注文を貰って来るけど資材は2ヶ月先まで発注しなければならない。
製品の在庫を持っているけど、読み違えでしょっちゅう現場がかき回される。」

多少の違いはあれ、全ての工場で直面している現状だろうと思います。

もうひとつのパターン

「親会社(客先)は。”手前一週間は「確定」で、その先は「内示」”だと言うけど、うちの仕入れは2ヶ月先まで注文しておかないと間に合わない。
親会社は、「内示」だからと先の計画をころころ変えて来るけど、 うちの仕入れはそんなに簡単に変えられない。」

です。

どちらも本質的には、全く同じ問題です。
つまり、資材を発注しなければならない期間が受注(計画を確定できる)期間より長いのです。



つまり 時間の逆転 です。

この問題に対し、従来の”MRP”はあまりにもひ弱でした。



どこにでも有る問題であり、また今後益々大きくなる問題ですが、従来の”MRP”には、どこを探してもその答えは有りません。
従来の”MRP”は「資材を発注する」つまり資材の計画を確定する為には製品の計画を確定しなければなりません。
例えば、資材の計画を2ヶ月先まで確定するためには、製品の計画を2ヶ月先まで確定しなければなりませんでした。




この問題を従来のMRPシステムの中で、運用面にだけ頼って逃げようとすると、
  1. 出来ないものは出来ないのだから、ある期間以内の受注は受けない。
    こんなバカな話は最近でこそ少なくなってきましたが、以前はよくあった話です。
    「うちは、コンピュータ管理していますから、そのご注文は受けられません。」
    何を考えているのでしょう?
  2. 2ヶ月先までMRPシステムで発注します。
    その時、計画変動に耐えるように製品在庫、部品在庫を沢山もつようにする。
    (実は、この方法にもMRP独特の偉大なる不自由さがありますがそれについては、また別の機会にゆずります。)
  3. そうそう大きな在庫を抱えるわけにはいかないので、在庫を持つのは、足の長い資材だけにし、他は手作業で計画変更に対応することにする。
    MRPシステムとしては2ヶ月間発注するが、変更のきく資材は手作業で計画修正していきます。
  4. 足の長い資材はそれほど多くないので、MRPシステムとしては、2週間先までの計画を確定することにし、足の長い資材の先行きの計画を手作業で発注する。
    間近の計画変動と 発注済み分との整合性は、常に資材担当が目を光らせる。
  5. 2ヶ月前に注文した資材が今回の計画でOKか否かをチェックします。
    (ここまで 具体的な方法をあげると 手配担当の方なら、だんだん寒気を感じてくると思います。)
  6. “内示”として受けたものは“内示”として指示する。
    (こうなると トランプのババのようで、引いてしまったババを一刻も速く次に回してしまおうという感じです。)
    勿論“内示”により、関連企業がついて来てくれるような大企業ならこれでもかまわないのですが、“内示です”と言って、振返った時、誰もついて来てくれないような企業の場合、この方法は使えません



具体的な運用の方法論ですから、いくらでも“手”はあると思いますが、それらは皆、本質的な解決ではありません。
“内示”であろうと“確定”であろうと、作る時には作り、注文するものは注文しないと間に合わないのです。現に皆さん ご自分のリスクで これらのことを おやりになっているはずです。
しかし 従来のMRPは、この問題に対し 何の答えも与えてくれませんでした。



逆に この問題を 従来のMRPの中ではどう説明してきたかと言いますと、

「だから、“計画”が大事なんです。
販売予測、事業計画の精度を向上して、“内示”の精度を上げるのです。全社一丸となって、目標をたて、計画を守り、成長する。
これが、企業の体質強化に繋がり、それが、会社のあるべき姿です。
計画のない所に繁栄はありません...」


もっともな話です。



しかし、これは「マクロの話」の中で“もっとも”なのであって、「ミクロの話」の中でこれを持出すのは“システム屋の欺瞞”です。
商品開発計画、設備計画、人員計画、資金計画等は、足の長い仕事です。これらの計画は、会社の生死を左右する程 大事なものです。
しかし、これと 毎日の手配の仕事を一緒にしては困ります。
ただし“生産計画”には、“枠取り計画”としての位置付けと“明細計画”としての役割があります。“枠取り計画”は、ある程度 長期間 計画として、明示されなければなりません。
しかし“明細確定計画”については、着手直前で良いはずです。
この差は、はっきり区分しなければ ならないはずなのに、従来のMRPの説明では、それらをゴチャマゼにしてきました。




では これら従来のMRPが抱える問題点についてもう少しミクロな考察をしてみます。
「なぜ このような問題が発生し、また解決出来なかったか?」
それは従来のMRPは“全ての資材の計画を 同一期間内で、「一度に」確定してしまう”からです。
考えて下さい。今あなたが扱っている資材は、全て同じリードタイムが必要ですか?

今日注文すれば明日持ってきてくれる物もあれば、2ヶ月前に注文しておかなければ納品してくれない物もあるはずです。
また、例えば社内の最終完成作業 つまり 組立や 仕上工程などは、必要資材があれば、明日の計画は 今日確定し 現場に指示すれば良いはずです。それを従来のMRPは“一律に確定”してきたのです。
もっと間近で計画変更出来る資材も、逆にもっと先まで注文しておかなければならないものも皆一律に確定してしまうのです。
“既確定期間”という“聖域”の中で変動が起きる場合、従来のMRPでは全くお手上げになります。
断っておきますが、MRPを説いているどの本を読んでも“全資材の計画を一律に確定すべし”などとは書いてありません。
ではなくてどの本にも書いてある“MRPの計算方法”からでは、一律確定のシステムしか作れないのです。それは“従来のMRPの計算方法”の中には“計画変動に対する緩衝材としての在庫”の考え方が入ってないからです。
一つ一つの計画(計算値)が、キッチリ繋がっているため、製品の計画が少しでも変われば、素材の計画まで、全て影響を受けてしまうのです。




「f-MRP」を説明するキーワードは「2ヶ月先の資材を発注しておきながら、3日先の製品の計画を変更出来るシステム」です。
もう一つのキーワードは「必要な時に必要なものを 必要なだけ 集める為に、必要な時に 必要なものを、必要なだけ“手配”する」です。




f-MRPは生産計画の全期間に渡って、“既に確定している計画”と“未確定の計画”が混在します。そしてその確定計画と未確定計画の隙間を在庫で埋めていきます。

f-MRPでは 全ての資材の計算を、次のようにして行います。
  • 前回 既に確定している計画と今回必要とする計画を差異分析しながら、出来る限り前回の計画を変更しないよう計算します。
  • 日毎の在庫を、資材ごとに決めた在庫許容範囲と比較します。
  • その結果、確定期間内の計画をどうしても変更しなければならない場合は、計算の途中 その旨のメッセージを出します。
  • ユーザーは、変更メッセージをチェックし、資材計画を変更するか、製品の計画を見直すか、判断します。そして必要に応じ、再計算します。
  • 資材毎にインプットした確定期間に従い、発注処理(伝票発行)が行われます。今回発注された期間内が、次回確定計画として扱われ、次の所要量計算に繋がっていきます。



「f-MRP」によるシステムも、実稼働してから2年以上(88/3リリース)経ちました。その間 ユーザーから 尻をたたかれたり おだてられたりしながら、改善機能強化を繰返し、今では “森”になってしまいましたが、これが「f-MRP」の“幹”です。



勿論f-MRPは手品ではありませんから、変更計画に従って必要資材が“湧いて出る”わけではありません。“コントロールされた在庫”を使って、計画を安定させ、逆に 変更出来る所と出来ない所をはっきりさせます。f-MRPは、別の言い方をすると「製品の計画と 部品の計画を 独立して扱う考え方」と言えます。f-MRPは、システムの手から離れてしまう期間がありませんから、常に“本日”からが 所要量計算の対象になります。つまり本日の計画も変更出来るのです。
発注後2ヶ月かかる資材があっても、本日の計画を見直すことが出来る為、f-MRPによって最終的に全体としての工期を短縮することが出来ます。

その2:'01/03/30"TPiCSレポートNo.60"抜粋
株式会社 ティーピクス研究所 二ノ宮 良夫氏(社長)

第1話
うれしいことに「○○工場で巧くいったから、次は△△工場で使いたい」とか、「いろいろ心配を掛けたが、○○工場が巧く動くようになったので、一度見に来て下さい」などと言って下さる方が、最近ますます増えて来ました。
ところが「??億円のお金をつぎ込んでERPパッケージを入れたが失敗し、もう一度別のERPパッケージに??億円かけて導入したが、それも失敗した。いろいろ検討した結果“TPiCSを使おう”という結論になりそうなのだが、100万円のTPiCSを使うシステムの稟議書がなかなか書けないで困っている」という話を、また聞いてしまいました。
「いいんですよ 気にしなくたって、そういう話が結構あるのです」と言ってあげたくなります。
しかし実際にはつらい立場だろうと思います。
億の単位のお金をつぎ込んでERPパッケージを導入したが、それが巧く働かず、気がついてみると100万円のパッケージのTPiCSだといけそうだという結論を出さざるを得ないのは。
以前のシステム開発実施の決断をなさった方と、今回のTPiCSで行くという決断をなさった方が、同じ人物だとしたら、その方はすばらしい方だと思います。
「真実を見る力があり、過去の失敗を認める勇気がある方」です。
億の単位のお金をつぎ込めば、思うようなシステムを作ることが出来ると考えるのは、当然のことです。
それだけの予算が動くシステムであれば一人で考えたわけではなく、複数の人が検討し考えた結果でしょう。
現在の日本の常識がそうなのですから、そのような結論を出しても不思議はないのです。
何年前に立案したシステムだか聞きませんでしたが、例えば10年前だとしたらバブル景気の余韻がまだ残っている時期で、今ほどまでに製造業が厳しい要求をされる時代ではなかったはずです。とすれば なおさら、その時出した結論は、責めには値しないと思います。
このユーザーの場合、従来のシステムのどこに問題があって、TPiCSの何が良かったのか、分かりませんが、チャンスがあったら是非お聞きしたいものです。



第2話
あるコンピュータ販売店様からの電話です。
「私のお客さんで、システムの検討をなさっているので、複数の候補を比較しているのだが良ければTPiCSを、お薦めしたいと思う。TPiCSの資料も取り寄せたり、ホームページをみたりして、大体のことはわかったが、No.53のレポートに“バッファの概念”と“本日から所要量計算できるシステム”と書いてあるのですが、それはどういう意味ですか」
お話では、生産管理はだいぶ詳しいご様子。
私は、長い経験から(?)、このまま説明しても絶対理解していただけないと思い「どのようにご説明すればよいですか?」と逆に聞き返します。
「“本日から所要量計算する”のは、どんなシステムでも出来るんじゃないですか。例えばSAP社のR3でも、“タイムフェンス”という概念を持って処理していますし...」
私は“ほらきた”と思い、
「“タイムフェンス”って、今おっしゃいましたが、“タイムフェンス”てなんですか?」
「本日を計算するためには毎日棚卸(?二ノ宮)をしたり、またその通り実施すれば現場は混乱するし、実際には処理が出来ないので“タイムフェンス”という機能を持って...」
「ということは“本日は計算の対象にしない”のでしょ」
「いや、計算したって使い物にならないから...」
「でもそれが出来るとしたら良さそうではありませんか? 毎日棚卸をする必要も無く、その通りに実施しても現場に混乱が発生せず、そしてお客様の注文に迅速に対応できるとしたら、良いとは思いませんか?
TPiCSのf-MRPはそれが本当に出来るのです。」
しかし、“物を作る人間”にとって、電話の方が考えるような“壁”が存在することは事実です。





これは、20年近く前(1982〜3年頃)私がまだ ある自動車メーカーに勤めていた時、お客様の注文を頂いてから納車するまでの期間を短くする“生産の短サイクル化”のプロジェクトで書いていた図です。
私は、システム側の人間ではなく、生産側の人間としてそのプロジェクトに参加していました。
当時、汎用機を使って、生産計画を作り、部品展開をし、注文データ、注文書を作って、それが部品メーカーに届くまで、1週間程かかっていたと思います。
また、部品メーカーさんが発送し、部品が届いてから車体を溶接し、塗装をし、エンジンを載せ、完成するまでも、確か1週間程度必要だったと思います。
とすると、注文をいただいてから出荷するまでの期間はどんなにがんばっても2週間以下に短縮することが出来ません。月を上中下旬の3分割して計画を立てていたので「旬」の後の生産に引き当ったり、配車の期間等を加えると、実際には1ヶ月近くかかっていました。

これは自動車メーカーで、強大な購買力を背景にした部品調達、生産指示システムの“壁(限界)”です。
強大な購買力を持つ場合は、部品メーカーに対し、「内示」を出し、用意させておいて「納入指示」で最終的な計画を示すことが出来ますが、一般的な製造業の場合、そのようなことは出来ません。注文書を発行した後、発注リード日数分経ってから納品されます。
つまり、発注リード日数分遅くなってしまいます。

これを何とかしてもっと速く納車できるようにしなければならないということで、当時考え出したのは「計画の巻き替え」という技です。
計画としてリリースした個々の計画データを変更する方法です。
私が退職したのは「ボディーカラーの巻き替え」を実施出来るようにし、次に「オプションの巻き替え」の準備をしている頃でした。
「オプションの巻き替え」といっても、エンジンやミッションに影響する巻き替えは次のステップとし、車体側の簡単な部品だけしか変更できないような仕組みでした。



この仕組みは“巻き替え”という言葉に現されるように、“発注済みの期間の注文内容を変更する”という考え方です。
しかし、この解決方法は圧倒的な購買力があるメーカーだから出来ることで、一般の製造業の場合、この仕組みが成り立ちません。
私は製造業というのは「おたがいさま」だと思います。
発注先に無理難題を強いれば、最後は自分に返ってきます。納期遅れがあったり、コストアップになり、ひいては品質劣化につながったりします。
ここで誤解があってはいけないのが「だから進歩が無くてもよい」と言っているわけではありません。
「おたがいさま」に、皆が努力及び進歩しなくてはならないのですが、それぞれ会社 工場ごとにその対応力が異なります。
状況、対応力が違う多数の部品、多数の取引先とどうやって付き合って行くかが問題になるわけです。

私は自動車会社を退職後、生産管理システムを作るにあたりいつもこの問題を頭におきながら考えて来ました。
と言いながら、TPiCSの初期バージョンから今のf-MRPが実現できたわけではありません。
はじめは、レベルバイレベルに タイムバケットを計算するだけの極シンプルなMRPシステムでした。
それでも何本か“勇気ある方”に、初代TPiCSを使っていただけるようになりました。
ある時「二ノ宮さん、ウチの商品は“売れる”“売れない”の変化が激しい商品なんです。季節性というか、気候の変化に敏感というか、例えば“暑くなった”というと売行きが急に伸びたり、“秋風が吹けば”バッタリ売れなくなったりします。新商品を出しても予想以上にヒットしたり、勿論そうでなかったり。しかし部品は3ヶ月4ヶ月かかるものもありますが、注文すると3日後には納品してくれるものも結構あるんです。
なんかここいらへん、巧く管理できないかと思っているのです」
私は、自動車会社時代の経験から、それは多かれ少なかれ製造業は 皆 同じ問題を抱えているはずだし、この問題は今後さらに重要な問題になるはずだと思い、一生懸命考えはじめました。
「発注した分は変更出来ない(したくない)けど、使う数量は変わったって問題ないんだよなー。でも使う数量が大幅に増えれば、生産できないなー。それをどうやって掴んだらいいのだろう。使う数量が変化すると、在庫が変化するなー。
そうだ!“最小在庫”と“最大在庫”を部品ごとに設定できるようにすればいいんだ」





1987年11月、これがTPiCS f-MRPの出発点でした。
「生産管理は異常を管理するもの」という言い方があります。
本来 私は「生産管理は、異常が起きないように管理するもの」と考えますが「発生してしまった異常を管理しなければならない」のも事実です。
沢山の方と生産管理についてお話をしていると、発生してしまった異常事態を処理する機能については、強い興味を持っていますが、計画面での異常については、あまり熱心に検討なさらないように思えます。
つまり「今日、飛び込みで注文が入ったらどうするのか」「今日の生産がキャンセルになったらどうするのか、明日作る予定の注文が違う製品に変更されたらどうするのか」「あさって作る予定の製品の設計変更があったらどうするのか」「内示でもらっている計画がドタンバで変わったらどうするのか」など、計画面の異常事態を処理することに関しては、実に鷹揚で「それは特別処理で...」で納得してしまうようです。
TPiCSのなかでは、それらは“当然のこと”として扱いますから、異常処理でも特別処理でもありません。
例えば「内示が変更になった場合どのように処理すればよいのですか?」と質問を頂くことがあります。TPiCSではあまりにも自然な流れで処理してしまうので、マニュアルはサラリとしか書いていないので気が付かないのだろうと思います。
また、TPiCSの中には「オーダー発行後の変更」という概念が弱い(強くする必要が無い)ので、通常の画面で操作出来るようになっています。
しかし先程の“巻き替え”的な発想で作られたシステムだと、重要な機能になるはずですから「オーダー発行後の変更」という専用画面があったりして豪華な機能が盛り込まれているのかもしれません。
「オーダー発行後にも変更があるのはあたりまえだ、そのときの操作性は重要だ」と考え、“豪華な変更機能の方が使いやすそうだ”なんて思われる方がいそうで少し心配です。



第3話
「お客様にTPiCSさんのカタログをお見せしたら“これだよ探してくれと頼んだのは”といっていただきました」と言いながら、お客様と一緒にご来社いただきました。
エンドユーザーは自動車部品のメーカーさんです。
私が自動車メーカーの出身ですから、自動車産業のお客様だと一言二言会話をするだけですぐデモをすることが出来ます。
私が説明をする度に、お客様同士 小声で話しながら頷きあいます。
「これができるんだー」
「あれが困っていたんだ!」
これまでよほどご苦労なさったのだと思います。
一通りの説明が終わる頃には、「資料を読んで想像していた通りでした」と言っていただきました。
お客様は、一緒にご来社くださった販売店さんの方に、「我々同業者は、みんなこの問題で困っているんだから、紹介してあげれば喜ぶよ。他社のシステムもいろいろ見たし、??会でも“どんなシステム使ってるか”しょっちゅう話題になるけど、どこも今のウチのシステムとそう変わりなく、みんなこの問題で困っているんだよね」

f-MRPは、理屈として説明すると難しいかもしれません。しかし、実際に物を作っている方、それも速いサイクルで生産している方は、あるいは、ご自分で「どうやって実現しようか」と一生懸命悩んだ方が見れば、すぐ分かっていただけるものなのです。


f-MRPは株式会社ティーピクス研究所の登録商標です。
取得特許番号 3055993号 知的所有権登録番号 026300,026301,026302