（1）プロジェクトチームには明確な役割と権限を

ERPの導入プロジェクトは他のIT製品と比較して関係者が多くなるため、うまくプロジェクトをまとめるマネジメント力が問われます。ERPの選定やプロジェクト推進で豊富な支援経験を持つコンサルタントの須藤俊也氏は、体制・役割・権限を明確にすることが重要だと言います。

「よくある問題として、体制図と組織図がかみ合っておらず、プロジェクトを推進したくても組織図上の上下関係や力関係が邪魔してしまうというケースが挙げられます。そうならないようにプロジェクト体制に役割と権限を与えることが、選定段階から必要です。外野の声や途中から出てくる意見を遮るためにも、体制をしっかりと作っておくことが重要になります」（須藤氏）

しっかりとした体制づくりのためにはプロジェクトメンバーの選出にも配慮が欠かせませんが、ITの知識やスキルを持った人材は社内にそう多くはいません。また、ERPはシステムのリプレイス間隔が長いため、退職などにより既存システムを熟知した人材が不足してしまうケースも少なくないでしょう。

（2）過去のプロジェクト経験は役立つが過去にとらわれすぎないように

既存システムを熟知した過去のプロジェクトメンバーの存在は重要ですが、一方で次の製品選定に何らかの先入観をもたらしてしまう可能性にも気をつけなければなりません。
経験者が語る「以前のプロジェクトでは～」という話は、当然役立つこともありますが、逆に過去のシステムの考え方やアーキテクチャに引っ張られてしまうことも考えられます。
実際に、方法論やテクノロジーが急速に変わりゆく中で、過去のプロジェクトの進め方や考え方、採用したテクノロジーに影響されてしまい、うまくいかなかったという失敗事例を、ここ数年で何度も目の当たりにしてきたと須藤氏は言います。

「ERP入れ替えの理由がレガシーシステムの欠陥や、業務プロセスの刷新、データ構造などアーキテクチャの見直しといった場合では、以前のプロジェクトの知識が邪魔になるケースがありますので、改めてリフレッシュして進めることが大切です。メンバーによってプロジェクトの成否はある程度決まってしまうので、人選はプロジェクトを進める上で根幹とも言うべきプロセスです」（須藤氏）

もちろん担当者個人、あるいは組織がシステム刷新の経験を持つことは大きな強みであり、それらがプロジェクトを成功に導く場合もあります。一方で、ERP導入経験が乏しいメンバーも、特にナーバスになる必要はありません。

「その分新しい視点を取り入れやすいのだと前向きに考えてはいかがでしょうか。経験者も、過去の成功体験に固執しないことが大切です。一般企業が自社のERPを頻繁に入れ替えることはあまりないので、知見が十分に蓄積されているはずはなく、過去のノウハウも特に技術面では陳腐化しやすくなるからです」（須藤氏）

（1）目的と選定基準を「全員合意」で明確に

須藤氏はプロジェクトの目的の明確化と、それに基づいた製品の選定基準への落とし込みを、RFPを作成する前に終えておくことが重要だと強調します。

「プロジェクトの目的が曖昧だと選定基準を決められませんし、選定基準が固まっていなければ後になってプロジェクトが頓挫しかねません。ところが実際には、選定基準がぼんやりしたまま情報収集を終え、RFPを作成してベンダーに提案書を作成してもらっている間に考えようとしていたり、受け取った提案書を見ながら考えたりしているケースも見られます。そのようにして進めるとERPパッケージの選定に行き詰まりやすくなります」（須藤氏）

ERP導入には、必ず背景があり目的があります。例えば「ハードウェアやパッケージの保守切れ」「不祥事の発生に伴う再発防止とコンプライアンス強化」「業務プロセスの改善」などです。

「ERPありきでプロジェクトを始めると本来の目的を果たせないことがありますので、そもそもERPの導入によって目的を達成できるのか、目的に近づけるのかを振り返る機会を設けるべきです」と須藤氏は続けます。これは一見すると当たり前のように思えるかもしれませんが、多くの関係者からのさまざまな意見の中で、導入の目的が段々と曖昧になってしまうことがあると言い、次のように指摘します。

「既存製品の保守切れが理由だとしても、コスト意識の高い経営層は当然投資対効果を求めます。そのため、ERPの導入・刷新では現状維持に留まるのではなく、DXの推進をテーマに掲げ、導入に付加価値を与えようとする例がしばしば見られます。しかし、このような形で生まれたDX推進のテーマは、目的とその後の選定基準がおぼろげになりがちです。だからこそ、目的を明確にという基本的なことをあえて強調する必要があるのです」（須藤氏）

また、目的を明確にしてからは、できるだけ早い段階に関係者全員が合意した選定基準・評価基準を作るようにしましょう。

「後から入ってきた重要人物が付き合いのあるベンダーを連れてきたり、新しい意見を発したりすると、選定過程が振り出しに戻ってしまいスケジュール通りに進まないなど、プロジェクトの失敗要因になってしまいます。その発言で場を乱す意図はなく独り言のような内容であっても、鶴の一声だと受け止めて神聖化され、絶対的な基準になってしまうことがあります。そうならないためにも、選定が進む前の段階で一部のメンバーだけでなく選定に携わる関係者全員で基準を決めてしまうべきなのです」（須藤氏）

（2）情報収集はフラットな目線で 特定製品ありきの「儀式」にしない

目的や選定基準が明確になると、次はそれをもとに情報収集を始めていきます。ネット検索、日頃から付き合いのあるベンダーとの会話、セミナー参加などを通じて情報を集めてロングリストを作成し、そこから絞ってショートリストにまとめるというのが一般的な流れです。
このとき、担当者や関係者の頭の中には、導入したい製品がある程度浮かんでおり、その製品ありきで選定を進めてしまうケースがある点に注意が必要です。

「既に付き合いがあるベンダーがあっても、まずロングリスト/ショートリストの段階ではフラットに情報を収集します。情報収集を通して見えてくる選定基準もあると思いますが、基準を考えながらリストを作成していくと、どうしても恣意的な要素が混ざってしまいます。儀式や個人の好みにしないためにも、事前に導入目的に沿った選定基準や評価基準を定めておくことが望ましいのです」（須藤氏）

（1）RFP作成のポイントと提案評価の視点

リストを絞り込むと、RFPを作成し、対象のベンダーに提案を依頼するフェーズに入ります。これまで数多くのRFP作成に携わってきた須藤氏は、作成のポイントを以下のように挙げます。

「まずは導入目的や方針、つまり何をしたいかをしっかり書きます。その企業のプロジェクトにかける思いや方向性そのものですから、とりあえずベンダーの提案を聞いてみようというスタンスではうまくいきません。導入目的を明瞭にしないままのRFPでは解釈の余地が広すぎてしまい、返ってくる提案書の内容がベンダーによってまちまちになるため、決めきれなくなってしまいます」（須藤氏）

また、このような問題のあるRFPでは依頼する側とベンダーとの認識も合いにくいため、後の要件定義フェーズや設計フェーズに入ってから「話が違う」などとトラブルの火種になってしまい、予算上の乖離にもつながる恐れがあります。さらに、トラブル発生のリスクを考えて、ベンダーからの見積が高額になったり提案依頼を辞退されてしまったりする可能性が高くなります。選定フェーズで比較検討を正しく行えるようにするためにも、RFPの作成では「曖昧な箇所を残さない」、「明確に記載する」といったことが重要です。
そして、その後ベンダーから提出された提案書の評価については、RFPに示した項目であるサポート体制、スケジュール、スコープ、レスポンスの体制やスピードなどについて、どれだけ目的を実現できるのかという観点で冷静に見極めていきます。普段のやり取りでわかったことも、当然評価の対象になってきます。RFP提出以前のやり取りも含め、日頃のコミュニケーションで常にベンダーの力量やサポート体制などについて気にかけておくことが重要です。

（2）選定期間は延長しない 一貫してスケジュール通りに進行することが重要

ERPは一般的に、他のシステム導入に比べてプロジェクト実施期間が長くなります。選定期間も長くなりがちで、よりよい選定にしようという思いから、さらに期間を延ばしたいと考える担当者もいるでしょう。しかし、そうしてしまうと「こんな意見やあんな意見も」といったノイズが入り込みやすくなり、当初の導入目的から徐々にずれてくることがあります。結果として、例えば「最終的に残った3社のうちどれを選んでも目的に合致しなくなってしまった」というケースになることもあります。

「もちろん、そこには経営環境が変わってしまったなどやむを得ない事情もあるでしょう。しかし、当初掲げた目的を実現するためにシステム選定を行っているにもかかわらず、目的にそぐわない候補の中から選択することになってしまうのでは本末転倒です」（須藤氏）

このようなリスクを避けるための方法として、須藤氏は「当初のスケジュール通りに厳密に実行するべき」とアドバイスします。先述のように、期間が長引けばその分ノイズが入りやすくなる上に、ベンダーとしても予定していた体制を組めなくなってしまい、辞退されることも少なくないからです。
だからこそ、スケジュールをしっかりとしたRFPを作成することが重要です。そのほうがベンダー側も提案しやすく、「本気度」を感じて提案内容のレベルや精度も高まります。

「スケジュールを先延ばしにする会社に対して、ベンダーはリスクを感じますし、熱量が下がって行く様子は横で見ているとよくわかります。一貫してスケジュール通りに選定を進めることは、非常に重要です」（須藤氏）

（1）ビッグバンよりも適材適所のモジュール選定に

須藤氏は最近、「ERP」という言葉を意識して使う場面が少なくなっていると言います。

「1990年代後半から2000年代初頭にかけて日本でもERPが徐々に浸透してきましたが、その当時、統合パッケージを導入している企業は珍しく、業務のベストプラクティスをつかめていませんでした。そんな中、ERPの導入によってベストプラクティスに業務を合わせましょう、というお題目が広く受け入れられたのです。もちろん、現在でもそのような効果は期待できますが、ERPの全モジュールをビッグバン導入（一括で導入・稼働）しようとするプロジェクトはほとんど実施されません」（須藤氏）

昨今では、企業は独自の強みを発揮するため、顧客やビジネスごとに使用するシステムやITインフラも最適なものを選択するようになっており、須藤氏も、「単一パッケージを自社のあらゆる業務に適用することは、もはやビジネスにそぐわなくなりつつあります」と話します。例えば、「競争領域になりにくい会計システムにはこのERPを、競争領域である生産管理業務にはこの生産管理パッケージを」といったように、ベスト・オブ・ブリード^※の考え方でシステムが構築されるようになっています。

また須藤氏は、導入の方法論も変わってきていると説明します。巨大プロジェクトが途中で止まるのは大きなリスクだと捉え、プロジェクトやシステム更新のスコープを細切れにして連続的にリリースしていく会社が多くなっていると言います。その理由はリスクの最小化だけではなく、部分的に早くリリースすることで早めに成果を実現したい、投資対効果を高めたいといった狙いもあります。

※各分野で最も適した製品を選定し、それを組み合わせてシステム構築を行うこと