SAP PMOとは？S/4HANA移行・2027年問題で失敗しない体制の作り方

「2027年末で今のSAPの標準保守が切れる。S/4HANAへの移行を決めたものの、社内にSAP経験のあるPMがいない」——この記事は、そんな状況にある情シス・経営企画の方に向けて書いています。先に結論を言うと、発注側にまず必要なのは「SAPに詳しい人」そのものではありません。SAP特有の構造を理解したうえで、プロジェクト全体を計画に落とし切り、多ベンダー体制を回せる管理機能。つまりSAP PMOです。本記事では、SAP案件特有の難しさ、SAP Activateの文脈でのPMOの動き方、多ベンダーコントロール、2027年問題からの逆算計画、支援会社の選び方までを発注側視点で整理します。

SAP PMOとは、SAP導入・S/4HANA移行プロジェクトに特化して、進捗・課題・品質・ベンダー間調整といった管理機能を担うチーム、またはその支援サービスを指します。SAP専用論に入る前に押さえておきたいPMO支援サービス全般の支援内容と提供形態は、別記事で解説しています。ERPや基幹システム導入のPMO一般については別記事で扱うので、ここではSAPならではの話に絞ります。

そもそもSAPとは何か。僕のYouTubeチャンネルで、現役のSAPコンサルタントをゲストに迎えて根掘り葉掘り聞いた回があります。彼の説明はこうでした。

format_quote

SAPっていうのはドイツにある会社の名前で、そこがERPパッケージ——会社の会計だとか物流だとか在庫だとか、あとは人事とか、そういった基幹システムを1つのパッケージにしたシステムを開発して、そのパッケージのことをみんなSAPと言っているんです。

会計・物流・在庫・購買・人事。会社の中枢業務がまるごと1つのパッケージに乗る。だから導入・移行の規模も大きく、対談の中でも、プライムベンダーは大手コンサルファームが多く、大規模案件ではプロジェクト総額が数十億〜数百億円規模に達することもあるという話が出ました。この規模になると、プロジェクト管理は「優秀なPMを1人置けば済む」次元を超えます。管理そのものを専門機能として体制に組み込む必要がある。SAP PMOという言葉が独立して語られるのは、それだけの構造的な理由があるからです。

SAPの全体像をつかみたい方には、この対談が入口としてちょうどいいはずです。動画で詳しく知りたい方は、以下もあわせてご覧ください。

「【SAPコンサルが解説】SAPとは何か【プロジェクトマネジメントの教室】」

止めれば業務が止まるシステムを、動かしながら替える

SAP案件の難しさの根っこは、対象が基幹システムであることに尽きます。対談でゲストが語っていた言葉が端的でした。

format_quote

基幹システムと言われるものを止めちゃうと、業務が止まる。インパクトが大きすぎるってところがありますね。

Webサービスなら障害が起きても「サイトが見られない」で済む場面が、SAPでは「出荷ができない」「決算が締まらない」になる。実際、切替直後に在庫データが合わず出荷が止まった事例も対談で話題になりました。稼働直後の1〜2ヶ月は監視とリカバリーで繁忙期になる、というのが現場の実感だそうです。事後対処のコストは事前対処の3〜5倍かかるというのが僕の経験則ですが、SAPの場合はその倍率がさらに跳ね上がると考えたほうがいい。だからこそ、切替判定基準や移行リハーサルを計画段階で作り込む「前始末」が効きます。

移行は「できて当たり前」の減点方式

format_quote

移行は、僕もそうなんですけど、みんなやりたくないんです。できて当たり前と思われる風習があって、失敗すると怒られる、減点方式みたいな感じなんですよ。

大企業のマスターデータとトランザクションは量が膨大で、時期によっては24時間2交代での移行作業といった泥くさい運びが必要になります。成功しても褒められず、失敗すれば大事故。この非対称性のせいで、移行工程は計画上も軽視されがちです。発注側が「移行はベンダーの作業でしょ」と構えた瞬間、リハーサルの回数やデータクレンジングの工数が削られていく。ここに目を光らせるのがPMOの仕事です。

アドオンの膨張——遅延は症状、真因はスコープのズレ

SAPは標準機能に業務を合わせる「Fit to Standard」が原則ですが、大企業ほど業務が複雑で、標準で吸収できない部分にアドオン（追加開発）が発生します。問題は、標準に合わせるか作り込むかの判断基準を持たないまま要件定義に入ると、現場の「今のやり方を変えたくない」がそのままアドオン要件に化けること。気づけば開発規模が膨らみ、スケジュールが遅れ始めます。僕はいつも、遅延は症状であって、本当の問題はスコープの定義がプロジェクトの目的とずれていることだと考えています。SAP案件でこの「ズレ」の最大の発生源が、アドオン判断なのです。

SAP案件には、SAP社が提供する標準の導入方法論「SAP Activate」があります。発注側が全フェーズを暗記する必要はありませんが、PMOがどこで何をすべきかはこの流れに沿って整理できます。

開発プロジェクトの7割は上流で決まる、というのが僕の持論です。SAP案件でいえば、Exploreフェーズを終えた時点で成否はほぼ見えている。ここでアドオン判定基準が機能せず、未決事項が「持ち帰り」のまま滞留したプロジェクトは、Realize以降で必ず苦しみます。だからSAP PMOの働きどころは、工程の後半で火を消すことではなく、Explore終了時に「何を作り、何を作らず、何が未決か」を仕分けし切ることにあります。

もう1つ。PMOという役割を、僕は戦闘における遊撃隊のようなものだと説明しています。あらかじめカチッと決められた守備範囲があるのではなく、プロジェクト成功のために必要なところへ縦横無尽に入っていく。SAP案件は次に述べるとおり関係者が多く、「誰の担当でもない問題」が構造的に生まれやすいので、この遊撃機能の価値がとりわけ大きいのです。

S/4HANA移行の体制は、典型的にはこれだけの登場人物がいます。

• プライムベンダー（コンサルファーム・大手SIer）
• アドオン開発・カスタマイズを担うパートナー
• 周辺システム側の改修を行う既存ベンダー（複数社になりがち）
• ベーシス（SAP特有の環境構築・基盤）チーム
• データ移行チーム
• 発注側の業務部門・情シス

僕はプロジェクトの失敗原因は発注側にも受注側にもあると考えていますが、多ベンダー体制ではこれが顕著です。各社は自社スコープには責任を持つ一方、会社間の境界に落ちる課題——インターフェース仕様の齟齬、テストデータの受け渡し、周辺システム側の遅れがSAP側テストを塞ぐ、といった問題——は、放っておくと誰も拾いません。プライムに全部任せているつもりでも、プライムの契約範囲外で起きる問題は発注側が裁くしかない。境界課題を最初から誰かの名前付きの仕事にしておく——SAP案件でPMOを入れる実利は、突き詰めればこの一点です。具体的には次の3点を最初に固めます。

1. 課題管理の一元化：ベンダーごとにバラバラの課題管理表を許さず、境界課題が見える1つの台帳に集約する
2. 裁定ルールの明文化：境界課題の担当と期限を誰がどの会議で決めるかを定義し、「持ち帰って調整」の滞留を防ぐ
3. レポートラインの設計：各社の報告フォーマットと提出タイミングを揃え、発注側の意思決定者に判断材料が同じ粒度で届くようにする

こうした多ベンダー統制の土台となるベンダーコントロールの基本原則は別記事に譲りますが、SAP案件では「境界課題を拾う機能を最初から体制図に描いておく」こと、これが肝です。

対談でゲストは市場の状況をこう表現していました。

format_quote

今SAPの案件はもうバブルだと言われていて、なぜならば2027年でSAPの旧バージョンをSAP社がサポートしないよと言っているんですね。SAPを導入している企業さんはみんな、新しいS/4HANAというバージョンへの切り替えを差し迫られている。

いわゆる2027年問題です。SAP ERP（ECC 6.0）の標準保守は2027年末に終了し、SAP社の発表では追加費用を払う延長保守を使っても猶予は2030年までとされています。つまり期限が動かせないプロジェクトです。発注側の計画で押さえるべきは3点あります。

第一に、移行方式の決定を最初の関門として扱うこと。 新規に作り直すグリーンフィールド、現行を変換するブラウンフィールド、その中間の選択的データ移行。どれを選ぶかで期間もコストも体制もまるで変わるため、ここを曖昧にしたまま「まずベンダーに聞こう」と進めると、各社の得意な方式に誘導された提案を比較できずに終わります。

第二に、稼働日から逆算して線を引くこと。 規模にもよりますが、方式選定からパートナー選定、Explore、Realize、複数回の移行リハーサルを経て稼働まで、年単位の期間を要するのが通例です。2026年半ばの今から始めるなら、2027年末の稼働はかなりタイトで、延長保守の活用を織り込んだ計画のほうが安全度は高い。期限に間に合わせるために計画を圧縮するのは、いちばん高くつく選択です。僕は、プロジェクトの成功で一番重要なのは徹底した計画をきちんと立て切ることだと考えています。計画にはコストがかかりますが、その分だけ品質が上がる。期限が固定されたSAP移行こそ、この原則が効きます。

第三に、人の確保を計画リスクとして扱うこと。 バブルということは、SAP経験者は市場で取り合いです。ベンダー側の要員も、発注側を支えるPMO人材も、動き出しが遅いほど選択肢が減ります。良い体制は待っていても組めません。

※保守期限やサポート条件は変更される可能性があります。最新の情報はSAP社の公式発表をご確認ください。

最後に、外部のPMO支援を入れる場合の見極めポイントです。SAP経験の確認と並行して、PMO支援会社選び全般の共通フレームもあわせて使うと比較がぶれません。そのうえで、商談の場でそのまま使えるSAP特有のチェックリストがこちらです。

• SAPの構造を会話できるか：SAP Activate、移行方式、モジュール構成、ベーシスといった言葉で議論が成立するか。SAP案件の経験が組織として蓄積されているかを確認する
• 管理の専門性が本物か：SAP知識はあってもプロジェクトマネジメントは我流、という人は珍しくありません。我流でうまくやっているPMは常にうっすら燃えているもので、大規模SAP案件では致命傷になります。管理の方法論を体系立てて説明できるかを見る
• 多ベンダー調整の場数：会社間の境界課題を裁いた具体的な経験を語れるか。「進捗を取りまとめます」しか言えない会社は議事録係で終わります
• 発注側の隣に立てるか：プライムベンダーの報告を鵜呑みにせず、発注側が判断できる形に翻訳してくれる中立性があるか。プライムと資本・営業関係が近すぎないかも見ておく
• 体制の継続性：担当者個人の力量頼みでなく、交代時の引き継ぎやバックアップ体制が用意されているか

1つ補足すると、PMOに求めるのはモジュールコンサルの代わりではありません。会計や物流の専門知識はプライム側にあります。発注側が持つべきは、その専門家たちの仕事を計画と数字で束ね、経営の判断材料に変換する機能。これを内製できないなら、外から入れる価値は十分にあります。

• SAP案件は基幹システムゆえに失敗の影響が桁違いで、管理を専門機能として体制に組み込む必要がある
• 成否の7割は上流で決まる。Exploreフェーズでのアドオン判定と未決事項の仕分けがPMOの最大の働きどころ
• 多ベンダー体制では「境界課題を拾う機能」を最初から体制図に描く。課題の一元化・裁定ルール・レポートラインの3点セット
• 2027年問題は期限固定のプロジェクト。移行方式の決定と逆算計画、人材確保を先に打つ
• 支援会社はSAP文脈の会話力と管理の専門性、発注側の隣に立つ中立性で見極める

期限が迫るなかで焦って体制を組むと、計画の粗さが後工程で3倍5倍のコストになって返ってきます。逆に言えば、いま計画と体制に時間を使うことが、2027年に向けた一番の近道です。あなたの会社のS/4HANA移行が「できて当たり前」を静かに達成できるよう、この記事がその設計図の下書きになれば嬉しいです。

---

SAP・S/4HANA移行のPMO体制づくりにお悩みの方へ

「この移行計画で本当に2027年に間に合うのか、第三者の目で確かめたい」「プライムベンダーの報告が妥当なのか、社内で判断できる人がいない」「ベンダーが増えるたびに、どこにも集約されない課題が増えている」——そんな状態のまま走り出すと、問題は必ず後工程で大きくなって返ってきます。

クリエイティブテックスタジオでは、発注側の隣に立つPMO支援を提供しています。僕自身、金融系SIerで大規模プロジェクトのPMを4年間務め、担当した全プロジェクトでQCD未達ゼロを達成してきました。その経験をもとに、移行計画の妥当性評価から多ベンダー体制の設計まで、貴社の状況に合わせてご支援します。サービスの詳細はPMO支援サービスをご覧ください。

まずは現状の計画と体制をお聞かせください。お話を伺った結果、僕たちより適した支援先がある場合は、その旨も正直にお伝えします。無料相談はこちらからどうぞ。