S/4HANA移行パートナーの選び方

SAP ECCからS/4HANAへの移行パートナーを選ぶには、SAPのパートナー認定を使って候補リストを作り、そのうえで2つのことで決めます。自社と似た移行の事例と、自社の業務に即したパートナーのハイレベル設計です。回答が一般論ばかりのパートナーは見送り、スコープの主導権は自社で握ってください。

結論から言えば、認定はパートナーを候補リストに載せます。契約を勝ち取らせるのは、事例と設計です。

この記事は、アプローチ、スケジュール、期限を扱った私のECCからS/4HANAへの移行ガイドの一部です。ここではパートナーの決定だけを扱います。選んだパートナーがアプローチ、計画、スコープを提案するので、その後の大半を左右するのがこの決定です。

移行パートナーは、導入パートナーと同じ買い物ではありません。ブラウンフィールドのコンバージョンで買うのは、技術的なコンバージョンのスキル、カスタムコードの修正、データの準備、そして一度で成功するカットオーバーです。グリーンフィールドでは、プロセス設計も買うことになります。

多くの選定プロセスはこれを見落としています。単価と方法論のスライドを比べますが、本当の作業はスライドにはめったに出てこない、いくつかの箇所にあります。

1. カスタムコード。 私の経験では、移行で最も超過しやすいフェーズであり、企業が最も見落としやすい隠れたコストです。
2. データ。 私が見てきたプログラムでは、データ移行が工数の30から40%を占めます。
3. カットオーバー。 ブラウンフィールドでは本番前に模擬コンバージョンを3回計画し、私が見てきたダウンタイムは週末1回から1週間までです。
4. 設計。 パートナーが最初の数か月で提案する設計上の判断が、その後何年ものコストを決めます。

ですから、問うべきは「どのパートナーが最も優れているか」ではありません。自社のシステムについて、この4つの領域をどう扱うかを根拠とともに示せるのはどのパートナーか、です。

SAPはパートナープログラムであるSAP PartnerEdgeを、コンピテンシーの枠組みで運営しています。2022年に導入した際には、7つのコンピテンシーと、それぞれにエッセンシャル、アドバンスト、エキスパートの3つの段階を設け、各コンピテンシーの中に製品やプロセスのレベルでのスペシャライゼーションを置きました。パートナーは、専門知識、顧客の成功、習熟度に基づいてそれを獲得します。

これらの認定はSAP Partner Finderに表示され、パートナーを検索し絞り込めます。SAPは2025年1月のPartnerEdgeの更新で、パートナーのレベルを決めるうえで専門性がさらに大きな役割を果たすようになったと述べています。

RISE with SAPには別の認定があります。2024年6月に導入されたRISE with SAP Validated Partnerの認定は、複数のコンピテンシーでエキスパートレベルを求めます。そこには、RISE with SAP S/4HANA Cloud Private Edition、SAP Business Technology Platform、SAP Business Process Transformationが含まれます。

SAPによる2025年7月の認定の説明は、デリバリー面の要件を加えています。デリバリーチーム全体でのRISE with SAP Methodologyの適用、主要な役割への認定資格保有者の配置、SAP Cloud ALMに記録されたClean Coreの品質ゲートを求めています。

それぞれのシグナルから分かること、分からないことは次のとおりです。

シグナル	確認できること	確認できないこと
コンピテンシーの段階（エッセンシャル、アドバンスト、エキスパート）	その分野でSAPが測定する知識、完了したプロジェクト、顧客の成果を企業が持っていること	自社のプログラムに提案された人材がその仕事をしたこと
スペシャライゼーション	特定のSAP製品やプロセスでの実績	自社の業種や、自社のような移行についての深い知見
RISE with SAP Validated Partner	エキスパートレベルのコンピテンシー、RISEの方法論、SAP Cloud ALMでのClean Coreのゲート	パートナーが自社のカスタムコード、データ、決算を理解していること
SAP Partner Finderへの掲載	認定が表示される登録済みのSAPパートナーであること	適合性についてのすべて

認定はフィルターとして使ってください。関連するコンピテンシーを持たないパートナーは、大規模な移行の候補リストに載るべきではありません。すべての認定を持つパートナーでも、次の2つのテストには合格しなければなりません。

私ならパートナーの決定をこう進める

1. 01

   評価

   市場に出る前にSAP Readiness Checkを実行し、カスタムコードとデータの規模を把握する。

2. 02

   スコープを握る

   パートナーが自社の事実に基づいて回答するよう、スコープと決めてほしい事項を書く。

3. 03

   候補リスト

   SAPの認定とPartner Finderを使い、関連するコンピテンシーを持つ企業を探す。

4. 04

   検証

   事例を確認し、最終候補の各パートナーにハイレベル設計を求める。

5. 05

   契約

   支払いとスコープの変更を、検証した設計に結びつける。

パートナーの決定について助言するとき、私にとって決め手は2つです。事例と、パートナーのハイレベル設計です。提案書のそれ以外はすべて補足資料です。

自社と似た移行の事例

事例が役に立つのは、自社の状況と一致する場合だけです。別の業種のグリーンフィールドの事例は、ブラウンフィールドの製造業にはほとんど何も教えてくれません。

次の3点が一致する事例を求め、自分で連絡を取ってください。

1. アプローチ。 ブラウンフィールド、グリーンフィールド、選択的データ移行のうち、自社と同じもの。
2. 規模。 エンティティ、国、カスタムオブジェクトの数が近いこと。
3. 人。 事例の担当者に誰が作業を主導したかを尋ね、その人たちが自社への提案に入っているかを確認します。

電話では、カスタムコードの数が開始時と終了時にいくつだったか、模擬コンバージョンを何回実行したか、カットオーバーで何がうまくいかなかったかを尋ねてください。それに答えられない事例の担当者は、作業に十分近いところにいなかったということです。

自社の業務に即したハイレベル設計

2つ目のテストは、署名前に最終候補の各パートナーに、自社のS/4HANAの将来システムのハイレベル設計を求めることです。Readiness Checkの結果と自社で書いたスコープを渡し、自社のプロセス、カスタムコード、データをどう扱うかを尋ねてください。

良いハイレベル設計は、自社のエンティティ、重要なプロセス、重要なカスタムオブジェクトを名指しします。何を廃止し、何を残すのか、そしてその理由を述べます。データロードとカットオーバーをどう組み立てるかを示します。

パートナーがClean Coreを維持できるかどうかも、ここで分かります。カスタマイズは最小限にとどめ、きちんと管理すべきです。設計がSAPを旧システムのように動かそうとしているなら、それこそが将来のアップグレードのたびにコストを押し上げる習慣です。

私が見送る危険信号は、一般論の情報です。自社の業務に即していない提案や、質問への回答です。

見ればすぐに分かります。提案書は方法論を詳しく説明し、自社については1段落しか書いていません。カスタムコードについての質問には「アクセラレーター」の話が返ってきます。

計画には、先月別の企業の資料で見たのと同じフェーズと期間が並んでいます。

一般論の回答が意味するのは2つのうちどちらかです。パートナーが自社を理解する努力をしていないか、署名後までそのつもりがないかです。いずれにしても、本当の設計はExploreの間に自社の予算で行われることになります。

テストは簡単です。それぞれの回答の自社名を競合他社の名前に置き換えてみてください。それでも問題なく読めるなら、自社のために書かれたものではありません。

移行予算の問題の大半の背後にあると私が見ている根本原因は、ベンダーにスコープを握らせることです。予算はExploreフェーズで、WRICEFオブジェクト（ワークフロー、レポート、インターフェース、コンバージョン、拡張機能、フォーム）が膨らむにつれて打撃を受けます。スコープを書くパートナーは、変更要求も書きます。

悪意の問題ではありません。パートナーの商業的な動機は、始めること、そして作業を見つけたら追加することです。自社の動機は、取締役会に示した金額の範囲で終えることです。

それは別々の仕事であり、スコープは支払う側のものです。

実務では、次の4つの方法でスコープの主導権を自社側に残してください。

1. 市場に出る前にスコープを書く。 パートナーのディスカバリーワークショップではなく、自社のReadiness Checkと自社のカスタムコード分析に基づいて書きます。
2. デザインオーソリティを設ける。 業務部門とITが共同で、新しいWRICEFオブジェクトを一つ残らず承認または却下する権限を持ちます。
3. WRICEFリストのベースラインを定める。 契約署名時にオブジェクトを数え、ステアリングコミッティのたびにその数を報告します。
4. 契約を検証した設計に結びつける。 その設計に対する変更は、理由とコストを添えて変更管理を通します。

それでも超過には備えてください。私なら10から20%の予備費を確保します。サービスがプログラム総コストの35から50%を占めることも忘れないでください。アプローチ別に金額を左右する要因は私のS/4HANA移行のコストのガイドで、商用条件は私のERP契約交渉に関するメモで扱っています。

これに対する私の答えは短いものです。事例次第です。

自社の業種で比較可能なブラウンフィールドの事例を持たないグローバルSIは、それを3件手がけたブティックより弱い選択です。自社の規模での事例を持たないブティックは、それを持つSIより弱い選択です。企業規模から分かるのは人材の層の厚さと対応範囲であり、その人たちが自社の移行をこなせるかどうかは事例が教えてくれます。

米国のSAP導入パートナーをティア別にまとめた記事を別に書いており、各ティアが得意なことと、失敗しやすい点を説明しています。ここでは一覧を繰り返しませんし、パートナーのランク付けもしません。その記事でトレードオフを理解し、最終候補に残った企業に上記の2つのテストを実施してください。

規模についてもう一点あります。大規模なプログラムの多くは複数のパートナーを使います。たとえば、中核の移行を担う元請けと、選択的データ移行やカスタムコードを担う専門パートナーです。これは、自社がスコープを握り、1社のパートナーが統合に責任を持つ場合に機能します。

提案依頼書を1通でも送る前に、アセスメントを実施してください。SAP Readiness Checkと移行アセスメントによって、パートナーが回答の前提にすべきカスタムコード、データ、簡素化の事実が手に入ります。それがなければ、各パートナーは自分たちの前提で空白を埋め、回答を比較できなくなります。

すでに署名していてプログラムが遅れているなら、問うべきことは違います。まず何を確認すべきかは、私のSAPプログラムの立て直しのガイドで扱っています。

私が主導または立て直した21のSAPプログラムを通じて、私が見る最大の誤りは、開始時にきちんと計画しないことです。パートナー選定は、その計画が始まる場所です。最終候補や提案について独立した視点が必要でしたら、私が支援します。こちらからご連絡ください。

SAP S/4HANAの移行パートナーはどう選べばよいですか？

SAPのコンピテンシーとPartner Finderを使い、関連する専門性を持つパートナーの候補リストを作ります。そのうえで、自社と似た移行の事例と、自社の業務に即した各パートナーのハイレベル設計で決めます。回答が一般論ばかりのパートナーは見送り、スコープの主導権は自社で握ってください。

RISE with SAP Validated Partnerとは何ですか？

大規模で複雑なクラウドERPプロジェクトを手がけるパートナー向けに、SAPが2024年に導入した認定です。認定パートナーは、RISE with SAP S/4HANA Cloud Private Editionを含む複数のSAPコンピテンシーでエキスパートレベルを持っています。SAPはまた、RISE with SAP Methodologyの適用、主要な役割への認定資格保有者の配置、SAP Cloud ALMに記録されたClean Coreの品質ゲートを求めています。

S/4HANA移行には大手SIとブティックのどちらを使うべきですか？

事例次第です。同じアプローチで、近い規模、近い業種で、自社と似た移行を手がけた人材がいる企業を選んでください。企業規模から分かるのは人材の層の厚さと対応範囲であり、そのチームが自社の移行をこなせるかどうかではありません。

署名前にSAPパートナーにどんな質問をすべきですか？

類似の移行の事例を求め、自分で連絡を取ってください。Readiness Checkの結果と自社のスコープに基づく、将来システムのハイレベル設計を求めてください。カスタムコードをどう見積もり、どう削減するのか、模擬コンバージョンを何回計画しているのか、誰が具体的にプログラムに入るのかを尋ねてください。

SAP導入パートナーを選ぶ際の危険信号は何ですか？

最大のものは一般論の情報です。どの企業にも当てはまる提案や回答です。ほかには、どの計画とも同じに見える計画、カスタムコードとデータについての曖昧な回答、署名後に自社のディスカバリーワークショップでスコープを定義したがるパートナーがあります。

SAPのエキスパート認定を持つパートナーなら移行の成功は保証されますか？

いいえ。SAPのコンピテンシーの段階は、企業レベルでの知識、完了したプロジェクト、顧客の成果を確認するものです。自社のプログラムに提案された人材がその仕事をしたことや、パートナーが自社のカスタムコードとデータを理解していることは確認できません。

認定はフィルターとして使い、そのうえで事例と設計を検証してください。