生産管理パッケージ活用の留意点(その6)

更新日

投稿日

◆生産管理パッケージ導入のポイント

 
 MRP前回のその5、MRPパッケージの苦手部分を補強するに続いて解説します。今回は、実際に生産管理パッケージを利用する際に注意すべき内容を紹介します。
 

1.現場要求によるカスタマイズは極力しない

 
 最初に注意すべきことはカスタマイズ(改造)作業を極力行わないようにすることです。これは生産管理パッケージだけでなく、すべてのパッケージソフトに共通する話です。パッケージソフトに対して大幅なカスタマイズを施してしまうと、それは実質的にパッケージシステムとはいえません。その会社オリジナルの個別システムを作ることと同じことになります。
 
 パッケージベンダーの中には、カスタマイズ作業は売上金額が増えるので喜ぶ会社もいますが、カスタマイズしたパッケージが増えると、いずれパッケージベンダーにはサポート負担がのしかかってくるようになります。パッケージベンダーは、パッケージを一度作ってしまえばそれで開発はおしまいということにはなりません。継続的な機能追加開発も求められます。パッケージの基盤として利用するOS、データベース、ハードなども継続サポートするバージョン(世代)に応じた修整管理もしていかねばなりません。それでいて、個別色の強いカスタマイズ部分の保守対応まで面倒をみることができるのでしょうか。
 
 パッケージベンダーの勢いが強くパッケージが売れている時は、サポート体制を維持する費用はそれほど気にならないかもしれません。しかし、いったんパッケージの売れ行きが落ち込みはじめると、サポート体制を維持していくための負担が重くのしかかってきます。それに耐えられるだけの余裕を持つことができるベンダーがどれだけいるでしょうか。

 数年前まで飛ぶ鳥を落とす勢いだったERPベンダーでさえも、ERPブームが一段落した現在、経営状態はかなり厳しくなってきているようです。他社に身売りしたり、ソフト保守料を値上げしたりして何とか食いつなごうとしている企業も多いようです。大手のERPベンダーですらそうなのに、中小の生産管理ベンダーが開発したパッケージソフトであれば、なおさら厳しい状況に追い込まれても不思議ではありません。また、生産管理パッケージの場合は、MRPに代表される生産管理理論に基づいて開発されていますので、大きなカスタマイズ改造をしてしまうことで論理的な整合性がとれなくなる恐れもあります。
 
 生産管理システムの場合は、それでなくても現場関係者が利用するため、操作性やデータ項目などで細かいカスタマイズ要求が出やすい傾向にあります。現場の要求を抑えるのは大変なことですが、できるだけカスタマイズはしないようにすることが大事です。そして、カスタマイズを抑制するためには、導入目的をしっかり押さえてシステム構築に入ることです。致命的な問題がないかぎり、導入目的と無関係なカスタマイズ作業は行わない、という決意をもってシステム導入作業に取り掛かるようにしてください。
 
 こう書くと「オフコンや汎用コンピュータ時代の生産管理パッケージは平気でカスタマイズをしていた」と反論される方もいると思います。当時のCOBOLベースで作られていたパッケージソフトは、ユーザーに対してソースコードを原則公開していましたので、ユーザーはそれを使って自らカスタマイズしたり、保守をしたりすることができました。たとえベンダーがサポートを停止しても、ソースを引き取ることでユーザー側で保守できました。パッケージというよりもテンプレート素材といった方が近いかもしれません。
 
 ところが、現在のパッケージはブラックボックス化されているため、ベンダーでないとカスタマイズや保守ができません。その違いがCOBOLパッケージ時代にはそれほど気にしなくてよかった「パッケージの寿命」という問題を顕在化させました。
 
 もしも工場現場の独自性が強く、カスタマイズをしなければならない場合は、無理に生産管理パッケージを使おうとするのではなく、APSなどに内蔵されているスケジューリング機能や部品展開機能(MRP計算機能)を利用して、残りの部分は個別開発で対応するといったことも考えられます。「Sapiens」や「GeneXus」など、個別開発に適した超高速開発ツールもいくつか登場してきていますので、下手にパッケージシステムをカスタマイズするよりも簡単かつ安価に個別システムを開発することができるようになってきています。
 

2.実績データの2次利用を前提にした設計をする

 
 今までの回で繰り返し述べてきましたが、MRPをベースとした生産管理パッケージは、データ活用面からみると不十分な点がかなり多くあります。それを補うために、APSソフトの活用や流動数曲線管理との組み合わせなどを紹介してきました。さらに会計システムや経営管理用のBI(ビジネスインテリジェンス)システムといったシステムにデータを渡して、より高度な工場経営管理につなげていくアプローチも考えられます。

 また、Excel...

◆生産管理パッケージ導入のポイント

 
 MRP前回のその5、MRPパッケージの苦手部分を補強するに続いて解説します。今回は、実際に生産管理パッケージを利用する際に注意すべき内容を紹介します。
 

1.現場要求によるカスタマイズは極力しない

 
 最初に注意すべきことはカスタマイズ(改造)作業を極力行わないようにすることです。これは生産管理パッケージだけでなく、すべてのパッケージソフトに共通する話です。パッケージソフトに対して大幅なカスタマイズを施してしまうと、それは実質的にパッケージシステムとはいえません。その会社オリジナルの個別システムを作ることと同じことになります。
 
 パッケージベンダーの中には、カスタマイズ作業は売上金額が増えるので喜ぶ会社もいますが、カスタマイズしたパッケージが増えると、いずれパッケージベンダーにはサポート負担がのしかかってくるようになります。パッケージベンダーは、パッケージを一度作ってしまえばそれで開発はおしまいということにはなりません。継続的な機能追加開発も求められます。パッケージの基盤として利用するOS、データベース、ハードなども継続サポートするバージョン(世代)に応じた修整管理もしていかねばなりません。それでいて、個別色の強いカスタマイズ部分の保守対応まで面倒をみることができるのでしょうか。
 
 パッケージベンダーの勢いが強くパッケージが売れている時は、サポート体制を維持する費用はそれほど気にならないかもしれません。しかし、いったんパッケージの売れ行きが落ち込みはじめると、サポート体制を維持していくための負担が重くのしかかってきます。それに耐えられるだけの余裕を持つことができるベンダーがどれだけいるでしょうか。

 数年前まで飛ぶ鳥を落とす勢いだったERPベンダーでさえも、ERPブームが一段落した現在、経営状態はかなり厳しくなってきているようです。他社に身売りしたり、ソフト保守料を値上げしたりして何とか食いつなごうとしている企業も多いようです。大手のERPベンダーですらそうなのに、中小の生産管理ベンダーが開発したパッケージソフトであれば、なおさら厳しい状況に追い込まれても不思議ではありません。また、生産管理パッケージの場合は、MRPに代表される生産管理理論に基づいて開発されていますので、大きなカスタマイズ改造をしてしまうことで論理的な整合性がとれなくなる恐れもあります。
 
 生産管理システムの場合は、それでなくても現場関係者が利用するため、操作性やデータ項目などで細かいカスタマイズ要求が出やすい傾向にあります。現場の要求を抑えるのは大変なことですが、できるだけカスタマイズはしないようにすることが大事です。そして、カスタマイズを抑制するためには、導入目的をしっかり押さえてシステム構築に入ることです。致命的な問題がないかぎり、導入目的と無関係なカスタマイズ作業は行わない、という決意をもってシステム導入作業に取り掛かるようにしてください。
 
 こう書くと「オフコンや汎用コンピュータ時代の生産管理パッケージは平気でカスタマイズをしていた」と反論される方もいると思います。当時のCOBOLベースで作られていたパッケージソフトは、ユーザーに対してソースコードを原則公開していましたので、ユーザーはそれを使って自らカスタマイズしたり、保守をしたりすることができました。たとえベンダーがサポートを停止しても、ソースを引き取ることでユーザー側で保守できました。パッケージというよりもテンプレート素材といった方が近いかもしれません。
 
 ところが、現在のパッケージはブラックボックス化されているため、ベンダーでないとカスタマイズや保守ができません。その違いがCOBOLパッケージ時代にはそれほど気にしなくてよかった「パッケージの寿命」という問題を顕在化させました。
 
 もしも工場現場の独自性が強く、カスタマイズをしなければならない場合は、無理に生産管理パッケージを使おうとするのではなく、APSなどに内蔵されているスケジューリング機能や部品展開機能(MRP計算機能)を利用して、残りの部分は個別開発で対応するといったことも考えられます。「Sapiens」や「GeneXus」など、個別開発に適した超高速開発ツールもいくつか登場してきていますので、下手にパッケージシステムをカスタマイズするよりも簡単かつ安価に個別システムを開発することができるようになってきています。
 

2.実績データの2次利用を前提にした設計をする

 
 今までの回で繰り返し述べてきましたが、MRPをベースとした生産管理パッケージは、データ活用面からみると不十分な点がかなり多くあります。それを補うために、APSソフトの活用や流動数曲線管理との組み合わせなどを紹介してきました。さらに会計システムや経営管理用のBI(ビジネスインテリジェンス)システムといったシステムにデータを渡して、より高度な工場経営管理につなげていくアプローチも考えられます。

 また、Excelにデータを渡して細かい管理資料を作成したいと考える企業も多くいるでしょう。こうしたデータ連携作業を効率良く行うようにするためには、生産管理システムの構築時にデータの2次利用を前提に設計することが求められます。あらかじめデータ連携の必要なシステムなどを洗い出して、データ項目名、データ形式、桁数などの情報を整理しておければそれにこしたことはありません。
 
 生データをあとになってつじつま合わせ的に使おうとすると余計な変換工数がかかることもあり得ます。また必要とするデータが収集できないことも考えられます。生産管理パッケージの機能だけですべて管理できるとは思わずに、自社にとって真に必要な管理機能は何か、その管理を実行するためにはどんなデータが必要かまで考慮したシステム設計作業を行うことが大切です。
 
 生産管理パッケージではこうしたデータ連携のためのデータ収集が難しいようであれば、パッケージ利用ではなく、前述したAPS+個別開発でのシステム導入も選択肢です。
 
 

   続きを読むには・・・


この記事の著者

本間 峰一

高額投資したにもかかわらず効果の上がっていない生産管理システムを利益に貢献するシステムに再生させます!

高額投資したにもかかわらず効果の上がっていない生産管理システムを利益に貢献するシステムに再生させます!


「MRP」の他のキーワード解説記事

もっと見る
リードタイムと待ち時間 生産管理システムはどうあるべきか(その4)

   【目次】 1. 多工程受注生産の生産管理 2. 何が利用を難しくしているのか 3. 内示情報で受注生産 4. リードタイムと...

   【目次】 1. 多工程受注生産の生産管理 2. 何が利用を難しくしているのか 3. 内示情報で受注生産 4. リードタイムと...


工程間滞留時間の分析 生産管理システムはどうあるべきか(その7)

   【目次】 1. 多工程受注生産の生産管理 2. 何が利用を難しくしているのか 3. 内示情報で受注生産 4. リードタイムと...

   【目次】 1. 多工程受注生産の生産管理 2. 何が利用を難しくしているのか 3. 内示情報で受注生産 4. リードタイムと...


多工程受注生産の生産管理 生産管理システムはどうあるべきか(その1)

   【目次】 1. 多工程受注生産の生産管理 2. 何が利用を難しくしているのか 3. 内示情報で受注生産 4. リードタイ...

   【目次】 1. 多工程受注生産の生産管理 2. 何が利用を難しくしているのか 3. 内示情報で受注生産 4. リードタイ...