多彩な機能を備えたパッケージシステムは、安価で素早く導入可能な点が、何よりのメリットです。ですが日本では、そうしたパッケージがそのまま使われることはほとんどありません。
その理由には、日本の企業が非常に保守的であることが挙げられます。現状の運用を変えることを嫌い、業務のシステム化を行おうというその時でも、企業独自のやり方を貫きたがるのです。
そこで行われるのが、パッケージの「カスタマイズ」です。
本来のシステムを改修し、クライアントの要求する独自の機能を加えて販売するのですが、散々な結果となることも少なくありません。
カスタマイズが失敗しがちな理由にはどんなものがあるか、検討してみましょう。

製品コンセプトに反した仕様を導入する

業務のシステム化を初めて行う企業にありがちなのが、パッケージの特徴をちゃんと理解しないまま導入を進めてしまう、というケースです。小売業など、会社ごとに独自ルールが多い業界が分かりやすい例ですね。
業務目的とシステムの相性が悪い場合、クライアントの要望に応えるために、システムの根幹に手を入れることになるでしょう。そうなれば「安価で素早い導入」というパッケージの利点が無くなります。当然、無理な改修を行えば、クォリティの低下も免れません。
導入の際は、クライアントの要求に叶うパッケージなのかどうか、慎重に検討するようにしましょう。

一部署からの要求に捉われすぎる

部署ごとの裁量が強い企業も、要注意なケースです。全ての部署で仕事の進め方が一本化されていないと、特定の部署のみがシステムと運用が噛み合わない、ということも有り得ます
一つの例として、有給申請の承認ルートを見てみましょう。
「全社的には『スタッフ ⇒ 店長 ⇒ 社長』というルートで有休を処理しているが、ある店舗では『スタッフ ⇒ 社長』というルートで処理している」という場合、特殊なカスタマイズが必要になります。
この時、全部署の業務をパッケージの運用に一新させることができれば問題ありませんが、その方法を選ぶ企業はまずないでしょう。
大規模な改修が必要になる場合は、コストパフォーマンスの面からも、導入を考えるべきだと言えます。

データキャパシティを無視してしまう

パッケージには本来、担保できるデータ量というものが決まっています。例えば100万件を想定したシステムなのに、1億件規模のデータを投入すれば、処理速度は大幅に落ちてしまうことでしょう。
クライアントが「ある程度遅くなっても大丈夫」などと楽観視しても、必ず後々チューニングを要求されることになります。このケースもシステムの根幹に手を加えることになり、最悪の場合はデータベース設計まで見直すことになるため、見積もり段階で良く検討しなければなりません。

理想は「余地を残す」こと

日本のＩＴ業界では、「パッケージ導入にはカスタマイズが付き物」というのが当然の風潮になっています。あまり効率的とは言えませんが、そういった前提があるならば、初めから「カスタマイズの余地」を用意しておくべきだと言えるでしょう。
例えば画面表示する情報を固定化するのではなく、パラメータを持たせて切り替えるようにできれば、対応も簡単になります。
カスタマイズ案件は、うまくはまれば優れたコストパフォーマンスを生み出すことも可能です。これからパッケージ開発を行う際は、「余地」について意識しつつ作ってみると、良いかも知れませんね。