ITmediaのTechTargetジャパンから「失敗しないERPの選び方」として会計・人事・生産管理の各モジュールごとに製品選択のポイントが解説されています。
最近のERP導入プロジェクトはテンプレートを用いた短期間の導入が主流となっていますが、それでも”稼働延期（または稼働しない）””予算オーバー””期待していたのと違う”など問題が出てしまうプロジェクトもあるようです。これまでの経験から一つ言えるのは、失敗するプロジェクトに共通しているのは、ユーザー部門が積極的に関与しないということです。次の事象は導入過程でよく見かける状況ですが、振り返れば製品選択時の関わり方にすでにその兆候があったりもします。
情報システム部門、ベンダー任せのプロジェクト
現業を抱えながらプロジェクトワークに参加することが難しく、とかくユーザーの要件整理も含めて情報システム部門に任せてしまうケースがあります。どのようなシステムにしたいのかと質問しても、口頭ないしドキュメントベースで要件を整理して説明するのは意外と難しく、上手にリードするメンバーがいないと、”現状と同じ機能が実現できればいい”という安易な着地になるときすらあります。こんなとき情報システム部門は困ってしまいます。以前のようにスクラッチから自社で開発するような場合はまだしも、近年のように単純なパッケージの導入や、パッケージをベースとしたアドオンによる開発方針のもとではユーザーの要件をどのように実現するのが良いかわからずベンダーを頼ることになります。
情報システム部門にとって導入するパッケージ製品は初めて扱うことがほとんどでプロジェクト開始・進行と並行して、ベンダー主催の教育研修コースを受講するなどして必要なスキルを積んでいきますが、プロジェクト期間中は現状把握しているユーザーの要望をベンダーに伝達することが主な役割となってしまうことがあります。導入ベンダーは製品に詳しくても会社業務や業種・業態特有の要件についてまで十分理解する時間的余裕はあまりないのが通常です。最悪の場合、プロジェクトがある程度進行した段階で「こんなシステムは使えない」というユーザーからのクレームが出てしまいます。
業務の見直しをしないプロジェクト
以前に比べてERPの機能は充実しており、製品間の機能差も少なくなっています。とはいえ、自社の業務との適合分析を実施した結果、機能的なギャップが抽出されたときに、既存の業務運用を見直すことで対処することを検討せずにアドオン開発に振ってしまうことがあります。情報システム部門、導入ベンダーがユーザーを説得できない（パッケージの標準機能を活かして業務見直し案を提示できない）のも一因で、業務上の課題もシステム上の課題となってしまう感じです。
パッケージ製品選択時にできること
“パッケージ機能に業務を合わせる”と方針を立て合意したつもりで進めても、プロジェクトリーダーが相当なリーダーシップを発揮して進めない限り、ユーザー部門からの揺り戻しは発生するものです。ERP導入プロジェクトを進めるうえで、上記のような失敗を少しでも回避するためにはパッケージ製品の選択時からユーザー部門が積極的に関与する必要があります。具体的には、RFP（提案依頼）の作成・評価プロセスの中で少なくとも次ような点をおさえておきます。
- ユーザーにとって業務上必須の機能は何か
（パッケージ標準機能を活用するとしても、そもそも標準で機能がないまたは不十分であればアドオン開発してでも実現したい機能） - 当該機能についてベンダーからの回答は「標準機能で対応」「アドオン開発で対応」のいずれになっているか
- 「アドオン開発で対応」の場合、実現できる機能レベルや想定される開発工数は妥当か
- 「標準機能で対応」の場合、ユーザーに対してどのような業務運用を求めているか
（要件に対応する機能が、パッケージの標準機能にあるからといって業務で使えるとは限らない点に注意が必要です）
ポイントはパッケージ製品選択のプロセスの中で、ユーザーが仮にこの製品を選択したときには「今の業務運用のここの部分をこのように見直さなければならない」「新しい業務運用はこうなる」というように具体的な運用イメージがわくようにすることです（特に上記4点目）。ベンダーから通り一遍の説明とデモンストレーションを見せてもらう（ましてやコストを比較する）だけで決定するのではなく、いくつかの重要なトピックについてはユーザーが納得いくまで確認をすることが必要です。期間さえ許せばRFPに先だってRFI（情報提供依頼）のプロセスを踏んで少し広めの製品情報の収集することも有用です。
