パッケージの場合

creation date：2003/3/1
last update date：2003/3/1

困ってしまうケース

トップダウン型の経営をしている企業では、｢このパッケージを入れなさい｣と、上から指示が降りてきます。それならそれでいいのですが、それとともに｢カスタマイズは極力避けて、パッケージの機能をそのまま使うようにしなさい。現在の業務に合わない場合は、パッケージ機能に業務を合わせるようにしなさい｣という指示も一緒に出して欲しいと思います。これであれば、業務がうまく回らなくなったとしても、それは上層部の指示で実行したことであり、上層部の責任ということになります。

困るのは、上層部がパッケージを入れる決断だけをして、どのように導入するのか曖昧という場合です。

そういう場合、業務担当者達はパッケージを入れることは仕方なく認めるものの、自分達の使い勝手の良いように、どんどんカスタマイズすることになります。しかし、それではパッケージ導入の意味がありません。パッケージでは、極力、その機能を活かし、どうしても利用できそうにない機能だけをカスタマイズするべきです。多くのパラメータにより、多くの機能を実現できるように作られているERPパッケージでさえ、やはり開発元の文化と導入側の文化での差異が大きくあります。

ですから、導入前の評価が最も重要です。

パッケージの導入

パッケージの導入に当たって、まず、パッケージの機能評価を行います。そのためには、目指すシステム像がなければなりません。現在、利用しているシステムと、そこで不足している機能、さらに、もっと先のいずれ実現したい理想的な機能を明確にしておかねばなりません。そういった目指すシステム像と、パッケージがどれだけ合っているかを評価するのです。例えば受注データを登録する時に、一つの取引先に対して複数の明細を入れたいのか、その明細の最大件数はどれぐらいか、登録した瞬間に受注書が印刷されなければならないのか、後でまとめて出票するのか、受注書の書式はどうか、登録した瞬間に引き当てするのか、引当は他の受注と調整してから別途行うのか、項目は間に合っているか、逆に使わない項目が多すぎないか、など一例を挙げただけですが、受注データの登録だけでもいろいろな検討事項があります。

そういった、あるべき機能に対して、パッケージに備わっている機能で満足しているかどうかを一つ一つ検討しなければなりません。あるべき機能を文章にしてしまえば、評価は誰がやってもいいように思えますが、できうれば、システムを実際に利用する人が自ら行うべきです。間に人が入れば入るほど、情報の正確性がおかしくなっていきます。もし、ある機能の評価をISに依頼し、ISがパッケージの販売企業に確認し、販売企業が開発したベンダに確認してみる、という道筋を辿ったとすると、やはりその回答には、100%の信頼を置くことはできないでしょう。最後には、やはりエンドユーザ自身で確認してみないと、本当に自分が必要とする機能が備わっているかどうかは、分からないことです。

そうやって、いくつかのパッケージソフトを評価し、比較検討してどのパッケージを導入するか、あるいは導入を断念するかを決定します。機能が不足していれば、カスタマイズするのか、業務的に多少の我慢をするのかも考えます。勿論、機能比較だけではなく、価格の比較も必要です。安い製品なら、多少カスタマイズが増えても、総費用が抑えられるのなら、悪い買物ではないでしょう。また、バージョンアップについても考えなければなりません。大きなバージョンアップの場合、カスタマイズした機能がそのまま使える保証はありませんし、バージョンアップ作業自体が大きな工数を伴うケースもあります。長い目で見れば、パッケージ導入ではなく一から作り上げる方が、コスト的にも、業務効率から見ても、良かったりしますから、なかなか難しいですね。