ERPパッケージ選定の流れ

　昨今では、大規模向けのERPパッケージはSAP、Oracleの製品に収束してきているが、中堅・中小企業（SMB）向けの製品は多様で特色のあるものも多く、まずは候補ベンダー／製品を絞り込むことから始める（図1）。業界のデファクトスタンダードとなっている製品や、深堀りして確認できる事例が豊富であればさほど悩まずに済むが、そうでない場合はRFI（情報要請書）をベンダーに発行して情報収集を行う。

図1●ERP選定の流れの例（出典：ITR）

　その際、漫然と製品の情報を集めるのではなく、絞り込みを行うことが重要である。ある企業などは、1年かけて30以上の製品／ベンダーに提案要請を行ったものの、「どの製品も大差ない」「ベンダーが何でもできると言っている」「違いが分からず選び切れない」「少しでも安い提案を選択すべきだ」などと意見が交錯し、混乱に陥ってしまった。逆に「あの製品は実績が多いから大丈夫」「あの企業も使っているから問題ないだろう」という思い込みにとらわれて、最初から1つの製品／ベンダーしか評価対象とすべきでないことも、第2回で挙げたポイント「事例を深堀りしない」の通りである。確かに会計分野でのパッケージ導入率は高く、販売や生産が少ないのは統計的に事実だが、だからといって「会計なら多少不自由かもしれないがパッケージに合わせれば何とかなるだろう」という先入観にとらわれてはいけない。まったく逆の場合も実際にあるからだ。

評価基準の重要性

　RFPの発行が終わると、提案書を受け取り提案会（プレゼンテーション）を実施することになるが、並行して評価基準の決定についてあらかじめ合意しておく必要がある。どのような評価項目で製品やサービスの優劣を決定するのかについて十分議論しておかないと、提案会が終わっても最終的な決定と通知を行うまでに長い時間を要したり、場合によっては結論を出せずに再提案を依頼したりすることにもなり得る。ともすれば、提案会を実施してから決めればいいといった流れになりがちだが、いわゆる後出しジャンケンのように、特定の製品／ベンダーに有利な評価基準を意図せず作ってしまう懸念もある。つまり、選定の客観性と公平性を損ねてしまうかもしれないので注意が必要である。

　RFPによる選定で盛り込むべき評価項目は、選定プロジェクトごとにバリエーションが出てくるといっても過言ではない（図2）。評価項目の数を絞ったり統合したりする場合もあるし、逆に「要件の充足度」を細分化したりする場合もある。また、性能や品質について懸念があれば別途評価項目を追加することもある。

図2●評価項目および基準の例（出典：ITR）《クリックで拡大》

　評価基準でよく議論になるのは「重み付け」である。図2では「スケジュール／計画」「コスト」よりも「要件の充足度」「予定担当者（PM）の経験とスキル」をやや重視した配分になっているが、もっと配分を傾斜させて倍の30や40といった数値にしたり、あるいは「コスト」への配分を増やしたりすることもあり得る。いずれにしろ、スコアだけでなくコメントの記入を必須にするなどして、なぜそう評価したのかの理由を明らかにすることで、感覚的な評価に陥らないようにする工夫が重要となる。また、各項目の評価の基準や評価の仕方について簡単な説明書を作成して理解を深めておくなど、できるだけ評価の品質を高めることも重要だ。

　最近の提案書はどんどん分厚くなる傾向があり、参考資料などを含めると500ページを超えることもある。だがその割には、自社製品の宣伝ばかりでRFPの質問に具体的に答え切れていない本末転倒のものが多い。一方、ユーザー企業側でも、分厚い提案書を読みこなせない、読みこなす時間がないといった問題がある。さらに、ITベンダーの使う専門用語が分からない、各ベンダーの記述レベルがバラバラになっていることから比較できないといった悩みもあるようだ。余裕のある選定スケジュールが組めない場合が多く難しい部分もあるが、提案会の開催までに担当ごとに分担を適切に割り振るなどの工夫をして、できるだけ提案書を読み込んでおこう。

　さて、提案会当日であるが、ベンダーのプレゼンテーション時間は限定されており、2時間程度の時間枠であればおおむね以下の通りの配分となるだろう。

• ベンダーの説明：1時間程度
• パッケージのデモ：30分程度
• 質疑応答：30分程度

　パッケージのデモについては、可能であれば事前に実施しておくことが望ましい。また、ベンダーが用意している標準的なデモではなく、なるべく自社の業務プロセスや業務シナリオに沿った内容にできるとなお良い。無償の依頼である以上、完全に自社仕様のデモを組み込むことはできないことは理解しておかねばならないが、事前デモで自社の業務に近い内容を選定メンバー全員が確認できていればベストだ。日程が厳しいなどの理由から事前デモが開催できなければ提案会で実施するしかないが、「一発勝負」となるため、ただ漠然と話を聞くようなことのないようにしたい。

　デモが終了したら、質問会となる。適切な質疑応答により、ユーザー自らが疑問点を晴らすことが重要であり、ベンダーの知識やノウハウを直接的に評価できる絶好の機会でもある。ただし、質問と回答が食い違っていたり、誤解したまま「これもできる、あれもできる」と思い込んでしまうようなリスクもある。そのようなときは、中立的な第三者の立場にあるオブザーバーに両者の仲介をしてもらうことが有効だ。

ベンダーへの丸投げは禁物

　ERPパッケージの選定には多くのポイントがあるが、最後にあらためて述べておきたいのは「ベンダーへの丸投げは避けるべき」ということだ。冒頭で述べた通り、これからは自己責任の時代であり、特に長く使い続けていくことになる基幹業務システムのパッケージ選定では、あらためて自らが「何が、どうできるか、どう動かしていけるのか」を評価する姿勢が求められる。昨今では、SaaS（Software as a Service）など外部のサービスを利用する選択肢も増えてきているが、基幹業務システムでは「10年使い続ける」ことを前提条件とする企業は多い。先行きが不透明な経済環境下、10年ではなく20年を前提とする企業も中にはあるが、全社員を巻き込むことになる基幹業務システムをできるだけ長く使い続けていきたいという実感の表れだろう。だからこそ、パッケージ選定に失敗する企業が少しでも少なくなるようにと切実に願う。

　それでは、パッケージ選定に失敗しないためにはどうすればいいのだろうか？　多くのパッケージ選定プロジェクトを調査してみると、システムの基本構想が不明確であることが主な失敗原因となっていることが多い。いくら分厚いRFPを作成し、多数の質問で機能評価を行っても、それを積み上げただけでは満足のいく結果は得られない。まして、現行システムのドキュメントを添付して「貴社製品の特性に応じて、最適な提案をお願いします」とだけ記述したRFPでは、依頼を受けたベンダーも雲をつかむようなものだろう。ITRでもベンダー／製品の評価や選定について、早くからRFIやRFPが重要であることを指摘してきたが、ここでは基本構想策定の重要性を中心に、RFPの前段として実施しておくべき作業について述べる（図3）。

図3●評価項目および基準の例（出典：ITR）

　昨今ベンダーの提案力やソリューション能力が低下しているといった指摘があるが、そもそも企業がどのようなシステムを構築したいかという「あるべき像」が不明確な点にも問題があるのではないだろうか。特にパッケージを前提とする場合は、パッケージに合わせる、パッケージが持つモデルをできるだけ有効活用することが過度に強調され、自社が求めるシステムのアーキテクチャ設計が省略されがちな傾向にある。

　アーキテクチャ設計とは、業務プロセス、データ、組織などの相関関係や配置を明らかにし、特に重要な主要要件（機能要件および非機能要件）を検証（verification）する中で、あるべきシステム像、およびゴールまでの妥当性（validation）を明らかにしていくコンセプトワークである。そして、コスト、機能、使用性（usability）のすべてを実現することが難しい場合は、どのような優先順位で評価するかを選定メンバー全員で整理し共有するプロセスでもある。

　もし、何かで迷いが生じたりふに落ちない部分が少しでもあったら、ぜひコンサルタントなどに相談してほしい。選定後の導入段階で大きな揺り戻しとなったり、最悪の場合にはシステムが導入できない、導入はしたものの性能問題で動かないといったことを、後で相談する羽目になることもあるからだ。社内にIT要員が十分配置できない事情がある企業ではなおさらである。ERPベンダーは今後、中堅・中小企業向けのソリューションや業種特化のサービスを強化していくと思われるが、想定外の重荷を背負うことのないように、製品やサービス内容を適切かつ事前に評価することの重要性はさらに増していくだろう。