今回は、実際に生産管理パッケージを利用する際に注意すべき内容を紹介します。
現場要求によるカスタマイズは極力しないようにする
最初に注意すべきことはカスタマイズ（改造）作業を極力行わないようにすることです。これは生産管理パッケージだけでなく、すべてのパッケージソフトに共通する話です。
パッケージソフトに対して大幅なカスタマイズを施してしまうと、それは実質的にパッケージシステムとはいえません。その会社オリジナルの個別システムを作ることと同じことになります。
パッケージベンダーの中には、カスタマイズ作業は売上金額が増えるので喜ぶ会社もいますが、カスタマイズしたパッケージが増えると、いずれパッケージベンダーにはサポート負担がのしかかってくるようになります。
パッケージベンダーは、パッケージを一度作ってしまえばそれで開発はおしまいということにはなりません。継続的な機能追加開発も求められます。パッケージの基盤として利用するOS、データベース、ハードなども継続サポートするバージョン（世代）に応じた修整管理もしていかねばなりません。それでいて、個別色の強いカスタマイズ部分の保守対応まで面倒をみることができるのでしょうか。
パッケージベンダーの勢いが強くパッケージが売れている時は、サポート体制を維持する費用はそれほど気にならないかもしれません。しかし、いったんパッケージの売れ行きが落ち込みはじめると、サポート体制を維持していくための負担が重くのしかかってきます。それに耐えられるだけの余裕を持つことができるベンダーがどれだけいるでしょうか。
数年前まで飛ぶ鳥を落とす勢いだったERPベンダーでさえも、ERPブームが一段落した現在、経営状態はかなり厳しくなってきているようです。他社に身売りしたり、ソフト保守料を値上げしたりして何とか食いつなごうとしている企業も多いようです。大手のERPベンダーですらそうなのに、中小の生産管理ベンダーが開発したパッケージソフトであれば、なおさら厳しい状況に追い込まれても不思議ではありません。
また、生産管理パッケージの場合は、MRPに代表される生産管理理論に基づいて開発されていますので、大きなカスタマイズ改造をしてしまうことで論理的な整合性がとれなくなる恐れもあります。
生産管理システムの場合は、それでなくても現場関係者が利用するため、操作性やデータ項目などで細かいカスタマイズ要求が出やすい傾向にあります。現場の要求を抑えるのは大変なことですが、できるだけカスタマイズはしないようにすることが大事です。
そして、カスタマイズを抑制するためには、導入目的をしっかり押さえてシステム構築に入ることです。致命的な問題がないかぎり、導入目的と無関係なカスタマイズ作業は行わない、という決意をもってシステム導入作業に取り掛かるようにしてください。
こう書くと「オフコンや汎用コンピュータ時代の生産管理パッケージは平気でカスタマイズをしていた」と反論される方もいると思います。
当時のCOBOLベースで作られていたパッケージソフトは、ユーザーに対してソースコードを原則公開していましたので、ユーザーはそれを使って自らカスタマイズしたり、保守をしたりすることができました。たとえベンダーがサポートを停止しても、ソースを引き取ることでユーザー側で保守できました。パッケージというよりもテンプレート素材といった方が近いかもしれません。
ところが、現在のパッケージはブラックボックス化されているため、ベンダーでないとカスタマイズや保守ができません。その違いがCOBOＬパッケージ時代にはそれほど気にしなくてよかった「パッケージの寿命」という問題を顕在化させました。
もしも工場現場の独自性が強く、カスタマイズをしなければならない場合は、無理に生産管理パッケージを使おうとするのではなく、APSなどに内蔵されているスケジューリング機能や部品展開機能（MRP計算機能）を利用して、残りの部分は個別開発で対応するといったことも考えられます。「Sapiens」や「GeneXus」など、個別開発に適した超高速開発ツールもいくつか登場してきていますので、下手にパッケージシステムをカスタマイズするよりも簡単かつ安価に個別システムを開発することができるようになってきています。