本文へスキップ

SAP導入のRFP:何を求め、どう採点するか

SAPのRFPでは、パートナーに3つのことを証明させるべきです。類似プロジェクトのリファレンス、参画させる人材の質、そして説明できるアーキテクチャと計画です。何を求め、回答をどう採点するかを解説します。

白いデスクの上に置かれたRFP文書、重み付きの採点表、提案比較のグラフ
目次
  1. RFPではなく、スコープから始める
  2. SAP導入のRFPに盛り込むもの
  3. パートナーに渡すもの
  4. パートナーに求めるもの
  5. SAP導入の提案をどう採点するか
  6. プレゼン:デリバリーチームに計画を説明させる
  7. リファレンスコールと一般論の回答
  8. リファレンスコール
  9. 一般論の回答の見抜き方
  10. 次の一歩
  11. よくある質問

SAP導入のRFPでは、パートナーに約束ではなく裏付けを求めるべきです。類似プロジェクトのリファレンス、参画させる人たちの経歴書、そして自社のスコープに向けたアーキテクチャと計画です。提案は届く前に固定した重みで採点し、そのうえでプレゼンを使って、デリバリーチームが計画を説明できるかを確かめてください。

結論から言えば、RFPは人材と計画を試すものであって、方法論のスライドを試すものではありません。

この記事は、提案依頼書(RFP)の段階だけを扱います。ロングリストから契約までの選定プロセス全体は、私のSAP導入パートナーの選び方のガイドにあります。

私が主導または立て直してきた21件のSAPプログラムを通じて、最も多く目にする失敗は、最初にきちんと計画しないことです。自社のスコープがわからないうちに送ったSAPのRFPは、どのパートナーにも空白を自社の前提で埋めさせてしまいます。そうなると提案を比較できません。それぞれが別のプログラムを見積もっているからです。

だから順序が重要です。スコープ、対象とするプロセスと対象外のプロセス、法人と国、インターフェース、データを定義し、そのうえでRFPを組み立ててください。

スコープは後で予算も守ります。予算が打撃を受けるのはSAP ActivateのExploreフェーズです。SAPの方法論では、ここでFit-to-Standardワークショップを行い、ギャップをバックログに記録します。

そこでWRICEFリスト(ワークフロー、レポート、インターフェース、データ変換、拡張、帳票)が膨らみ、新しいオブジェクトはどれもコストになります。自社のスコープに基づいたRFPがあれば、その膨張を測る基準線が手に入ります。

RFPは、少なくとも3社のショートリストに送ってください。

ロングリストはSAP Partner Finderで作ります。SAPはそこでパートナーがSAP PartnerEdgeのもとで保有するコンピテンシーを、essential、advanced、expertの3段階で示しています。バッジはリストに載る資格を与えます。契約を勝ち取る資格は与えません。

選定全体には、最初から最後まで約12週間かかります。

SAPのRFP段階の進め方

  1. スコープ

    どのパートナーにも見せる前に、スコープ、プロセス、法人、インターフェース、データを自社で書く。

  2. RFP

    採点の重みを固定したうえで、少なくとも三社のショートリストに同じ資料一式を送る。

  3. 書面の提案

    各提案を重みに沿って採点し、一般論の回答には印を付ける。

  4. プレゼン

    提案されたデリバリーチームに、アーキテクチャと計画を対面で説明させる。

  5. リファレンス

    自社と似たプロジェクトのリファレンスに電話し、そこでのパートナーの経験を尋ねる。

  6. 契約

    勝った提案の工数、指名された人材、前提条件を作業範囲記述書に引き継ぐ。

SAPのRFPは2つに分かれます。パートナーに渡すものと、パートナーに返してもらうものです。

パートナーに渡すもの

すべてのパートナーに、同じ資料一式を同時に渡してください。資料がよいほど、回答は具体的になります。

  1. 背景と目的。 なぜSAPを導入するのか、導入後に業務で何ができなければならないのか、重要な日程。
  2. スコープ。 対象とするプロセスと対象外のプロセス、法人、国、グループ別のユーザー、使用を想定するSAP製品。
  3. インターフェースとデータ。 SAPと接続すべきシステム、移行するデータオブジェクト、その品質についてわかっていること。
  4. 自社のチーム。 誰をプログラムに出せるか、その人の時間のどれだけを割けるか、パートナーにどの役割を担ってほしいか。
  5. 回答形式。 同じ条件で比較できるよう、決まった構成とページ数の上限。
  6. 評価基準と重み。 どう採点されるかをパートナーに伝えてください。重要な質問に答えさせることにつながります。
  7. スケジュール。 質問の締切、提案の締切、プレゼンの日程、決定日。

パートナーに求めるもの

たいていのSAPのRFPは、パートナーに自社の紹介を求めますが、パートナーはそれがとても上手です。代わりに、確認できるものを求めてください。

  1. 類似プロジェクトのリファレンス。 同じSAP製品、同程度の規模、同様の業種で、電話できる連絡先があるもの。
  2. 指名されたデリバリーチーム。 経歴書、各人が担う役割、自社のプログラムに割く時間の割合、自社の日程での参画可否。
  3. 確認できる認定資格。 SAPは認定資格をリアルタイムで検証できるデジタルバッジとして発行しています。会社全体の認定数ではなく、指名された人たちのバッジのリンクを求めてください。
  4. アーキテクチャと計画。 自社のスコープに向けたハイレベル設計と、マイルストーンと依存関係を含むSAP Activateのフェーズ別の計画。
  5. フェーズ別・役割別の工数。 総額だけでなく、各フェーズにおける役割ごとの見積人日。
  6. 詳細な前提条件と除外事項。 価格が依存しているすべてのことと、価格がカバーしないすべてのこと。
  7. 契約形態と単価表。 役割別・デリバリー拠点別の単価、出張と経費、変更をどう価格付けするか。
  8. Exploreでのスコープ拡大をどう管理するか。 新しいWRICEFオブジェクトを扱う方法と、誰が承認するか。

契約形態については、工数を定量化したタイム・アンド・マテリアル(準委任型)を推奨します。フェーズ別・役割別の見積工数を契約に書き込み、毎月、実績工数をそれと比べて追跡できるようにします。RFPの段階でそれを求めておくことが、後でそれを可能にします。

単価については、数字を示してパートナーを誘導しないでください。単価表を求め、私のSAPプロジェクトの要員配置計画のガイドにある範囲と比べてください。

前提条件と除外事項は、顧客が作業範囲記述書で最も書き漏らしがちな部分です。RFPで詳しく求めておけば、交渉の前に手元にそろいます。それが契約にどう引き継がれるかは、私のSAPの作業範囲記述書のガイドで示しています。

重みは提案が届く前に固定し、回答を読んだ後で変えないでください。後から重みを変えるのは、本命を選んで後付けで正当化するやり方です。

クライアントのパートナー選定を手伝うとき、最も重みを置くのは顧客リファレンスです。合計点がどうであれ、私が入札を見送る理由は2つあります。提案された人材の質が低いこと、そしてアーキテクチャと計画を説明できないパートナーです。採点にはその両方を反映させるべきです。

下の表は、こうした優先順位に基づいた重み付けの例です。割合は自社のプログラムに合わせて調整してください。ただし、リファレンスを最上位に置き、2つの見送り基準は残してください。

評価基準重みの例高得点の条件見送りの兆候
リファレンス30%類似プロジェクトで、連絡がつき、パートナーの役割を裏付けてくれるリファレンス比較できるプロジェクトのリファレンスがない、またはパートナーが電話を許さないリファレンス
人材の質25%関連する経歴書、確認できる認定資格、確定した参画可否を備えた指名人材名前のない役割、薄い経歴書、または「参画は状況次第」とされた主要人材
アーキテクチャと計画25%自社のスコープに向けた設計と、マイルストーン、依存関係、リスクを含むフェーズ計画一般的な計画、またはプレゼンで説明できない設計
商務条件10%フェーズ別・役割別の工数、明確な単価、詳細な前提条件と除外事項工数の裏付けがない総額のみの価格
アプローチ10%スコープ管理、テスト、データ、知識移転についての明確な方法自社に固有の内容がない方法論のスライド

各基準を1から5のような単純な尺度で、理由を書き添えて採点します。各評価者がまず単独で採点し、その後パネルで比べます。

2つの見送り兆候は、点数ではなく関門として扱ってください。商務条件がどれほど強くても、弱いチームを買い戻すことはできません。商務条件の重みを低くしているのは意図的です。日額単価は、工数や手戻りに比べれば小さな変数です。

会議室でアーキテクチャと計画を説明できないパートナーは、現場でもそれをデリバリーできません。

書面の提案でわかるのは、提案チームが何を書けるかです。プレゼンでわかるのは、実際に作業する人たちがそれを理解しているかどうかです。

実際にプログラムを担当する人たちを、名前で指定して求めてください。ソリューションアーキテクト、プログラムマネージャー、最大規模のワークストリームのリードが同席すべきです。パートナーが別のチームを連れてきたら、それを採点に記録してください。

そのうえで、できればスライドなしで、自社のスコープに向けたアーキテクチャと計画を説明させてください。使える質問は次のとおりです。

  1. 当社で最も複雑な2つのプロセスについて、設計を順に説明してください。 自社のプロセス名、法人、システムが出てくるかに耳を傾けてください。
  2. ExploreでWRICEFリストが3分の1増えたら、どうなりますか。 方法、意思決定の場、コストの話し合いが出てくるかに耳を傾けてください。
  3. 提案の前提条件のうち、最もリスクが大きいのはどれですか。 自社の計画を理解しているパートナーなら、すぐに挙げられます。
  4. このチームの誰が、以前どこでこれを経験していますか。 その答えをリファレンスコールで確認してください。
  5. 当社のチームに、いつ、何を求めますか。 本物の計画には、日付付きの顧客側の依存関係があります。

会議室でアーキテクチャと計画を説明できないパートナーは、現場でもそれをデリバリーできません。それが、私が入札を見送る2つ目の理由です。

私はプログラムの途中でパートナーを替えたことがあります。質の高い人材を出せなかったからです。署名前に最も厳しく試すべきは、よい人材を確保できるかどうかです。

リファレンスコール

リファレンスコールは重要ですが、形式的に行われることがよくあります。きちんと行ってください。私がリファレンスに尋ねるのは、自社と似たプロジェクトでのパートナーとの経験です。

電話の前に、リファレンスを自社のプログラムと照らし合わせます。同じ製品、同程度の規模、同様の業種かどうかです。一致が弱ければ、パートナーに別のリファレンスを求めてください。

電話では、パートナー側の誰が作業を主導したか、何がうまくいき、どこで苦労したかを尋ねます。そのうえで、その人たちが自社への提案に入っているかを尋ねてください。

一般論の回答の見抜き方

一般論の回答は、どのSAPのRFPでも危険信号です。どの企業にも送れる回答は、どの企業向けにも書かれたものです。

最も手早い確認は、回答の中の自社名を競合他社の名前に置き換えることです。それでも回答が通用するなら、あなたのために書かれたものではありません。移行についてのこの確認は、私のS/4HANA移行パートナーの選び方のガイドで詳しく扱っています。

RFPの回答では、一般論はたいてい次の箇所に現れます。

  1. スコープの章が、RFPをそのまま繰り返している。 自社のプログラムの何が難しいかについての見解がありません。
  2. 計画のどのフェーズも、きりのよい期間になっている。 自社の法人、データ、インターフェースに左右される部分が何もありません。
  3. 自社のプロセスについての質問に、アクセラレーターの話で答えている。 ツールの名前は出ても、自社でどう使うかは出てきません。
  4. リスクが業界共通のものばかり。 「データ品質」や「変化への抵抗」は出てきても、自社のシステムに固有のものは何も出てきません。
  5. チームの章に、人ではなく役割が並んでいる。 これはたいてい、言い方を変えただけの人材の弱さという問題です。

一般論の回答は、よく書けていても低く採点してください。

パートナーの文書を評価する場面でも、独立した視点が役に立ちます。入札していないアドバイザーなら、設計と工数見積りを、後には成果物を検証できます。そのトレードオフは、私のSAPパートナーと独立コンサルタントの比較で扱っています。

何よりも先に、自社のスコープを書き出してください。プロセス領域ごとに1ページで、対象、対象外、法人、関係するシステムを挙げます。これがなければ、提案の数字はすべてパートナーの前提の上に成り立つことになります。

ティア別のパートナー名は、私の米国のSAP導入パートナー ティア別ガイドをご覧ください。

RFP、採点、受け取った提案について独立した意見が必要であれば、私がお手伝いします。こちらからご連絡ください。

SAP導入のRFPには何を盛り込むべきですか?

パートナーには、背景と目的、スコープ、インターフェースとデータ、自社が出せるチーム、決まった回答形式、評価基準、スケジュールを渡します。パートナーには、類似プロジェクトのリファレンスと、経歴書付きの指名されたデリバリーチームを求めてください。SAP Activateのフェーズ別のアーキテクチャと計画、フェーズ別・役割別の工数、詳細な前提条件と除外事項も求めます。

SAP導入パートナーの提案はどう採点しますか?

提案が届く前に、重み付きの評価基準を固定します。リファレンス、人材の質、アーキテクチャと計画、商務条件、アプローチです。各評価者が単純な尺度で理由を書き添えて単独で採点し、その後パネルで比べます。人材の弱さと、パートナーが説明できない計画は、合計点がどうであれ提案を退ける理由として扱ってください。

SAPのRFPは何社に送るべきですか?

少なくとも3社です。SAP Partner FinderとSAPのコンピテンシーの段階からロングリストを作り、関連するリファレンスを持つパートナーをショートリストに残してください。

SAPパートナーの選定にはどのくらいの期間がかかりますか?

ロングリストから契約まで、最初から最後で約12週間です。RFPそのものはその一部にすぎません。時間の大半は、プレゼン、リファレンスコール、勝った提案を作業範囲記述書にまとめる作業にかかります。

SAPのRFPでは固定価格とタイム・アンド・マテリアルのどちらを求めるべきですか?

私は工数を定量化したタイム・アンド・マテリアルを推奨します。すべてのパートナーにフェーズ別・役割別の見積工数を求め、それを契約に書き込んで、実績工数と比べて追跡できるようにしてください。工数の裏付けがない総額だけの価格は、比較も追跡もできません。

SAPパートナーの提案における危険信号は何ですか?

どの企業にも当てはまる一般論の回答、役割はあっても指名された人がいないチームの章、ほかでも見たのと同じ期間の計画、そしてパートナーがプレゼンで説明できないアーキテクチャです。リファレンスへの電話を許さないパートナーも、もう1つの警告サインです。

Noel D'Costa

執筆者

Noel D'Costa

航空、政府、金融、小売、製造の各分野で、SAPとOracleのERPプログラムに25年携わってきました。財務出身です。経営陣とともに変革の範囲を誠実に定め、難航するプログラムを立て直し、本稼働後の最初の1年を乗り越えるシステムを構築します。

次のステップ

いまERPプログラムを進めていますか?

この記事が、いま進行中のプログラムに関わる内容だったなら、社内でさらに1週間分析を重ねるよりも、30分の対話のほうが多くの場合ずっと前に進めます。