2027年末の「SAP ERP 6.0（ECC6.0）」の標準保守終了まで残り3年。いよいよ「SAP S/4HANA」への移行が待ったなしの状況になってきた。日本における独SAPのERP（統合基幹業務システム）導入企業数は約2000社。日本でS/4HANAの導入コンサルティングが可能なベンダーは2024年時点で100社程度。約6割しか移行を終えられていない状況だという。ではどうするか。これまでの失敗事例は何が問題だったのか、Fit to Standardへの取り組み方は……。残り3年で失敗しないS/4HANAへの移行のポイントを現役のコンサルタントが全4回で解説する（本記事は日経xTECHで2024年11月18～21日に掲載された特集記事を再掲載したものです。著作権は筆者に帰属します）。
第1回：SAP「2027年問題」を抱えるユーザー企業とコンサル業界、何が問題なのか
前回「2027年問題」における業界の状況およびユーザー企業、ベンダーのそれぞれの課題に触れた上で、2027年問題への対応は「まだ間に合う」と述べた。第2回は失敗事例を踏まえ、その対応策について解説する。
IN THIS ARTICLE
IN THIS ARTICLEinpage
独SAPの「SAP S/4HANA」への移行の際、筆者が所属する会社では以下のフェーズに分けてプロジェクトを進めている。
図 S/4HANA化へのプロジェクトフェーズ
Determine：アセスメント・構想策定
プロジェクトの方向性や進め方を定義し、会社として意思決定
Prepare：プロジェクト準備
業務プロセスやシステムの概要設計および現行の課題などを整理し、システム導入のコンサルティング会社（IT導入ベンダー）を選定
Explore：要件定義
業務要件を定義し、業務オペレーションを整理。業務要件を固め、その内容についてS/4HANAの標準機能で適応可能な点を確認し、現行業務に適応できない点（Gap）について対応策を検討（Fit＆Gapを検証）。後続フェーズの開発に続くシステム要件を策定
Realize：開発
アドオンなどのシステム設計、開発、テストおよびデータ移行を実施。システム稼働後のハイパーケア体制（稼働直後のサポート体制）の検討や移行／教育などを計画
Deploy：導入・展開
検討済みのハイパーケア体制を構築し、本番稼働を実施
Run：運用・保守
ハイパーケア体制から通常の運用・保守体制への移行、ナレッジの引き継ぎ
構想策定では、現状の業務課題やシステム課題などを含めて、業務やシステムに対する要望を取りまとめ、「SAP ERP 6.0（ECC6.0）」からS/4HANAへ移行する際の概算見積もりや次期基幹システムをどのような開発手法で構築するのか、プロジェクトの方向性を決定する。
この検討が不十分な状態で後続フェーズに突入してしまうと、プロジェクトが円滑に進まず、「失敗」につながってしまう。
以下のような例が挙げられる。
- システムのバージョンアップがシステム開発の目的となっている事例（手段の目的化）
- 稼働時にマスターを変更するリスクが正しく認識されていない事例（リスクヘッジの軽視）
- 「Fit to Standard」を目標に掲げているが、大量のアドオンを作成した事例（スピードを犠牲にした複雑化）
バージョンアップが目的となっている場合の対応策
構想策定の後続フェーズであるプロジェクト準備フェーズで、システム導入の見積金額を含めた概算金額を算出する。そのため提案依頼書（RFP）をシステムベンダーやコンサルティング会社に提示する。その内容に基づいて各社は概算金額を算出するため、RFPに記載している内容に抜け漏れがないことが重要となる。
筆者が過去に受領したRFPの例では、導入の目的が「S/4HANAへのバージョンアップ」となっており、業務／システムの観点での改善要望の記載がなかった。提案書作成のための質疑の中でも業務課題やシステム課題を確認したが、「現行の仕様を基に、S/4HANA化する際、対応が必要な部分のみカスタマイズを設定する」との返答だった。そのため、BPR（ビジネス・プロセス・リエンジニアリング）などの業務変更を伴わないブラウンフィールドで提案した。
この事例の場合、システムを何も変更せず、ECC6.0からS/4HANAへ変更するだけのプロジェクトである。そのため予算金額の申請の際に現行と同様のシステムをつくる意味を問われることが多い。現行と同じ仕様で数億～数十億円を投資することになるからである。最悪の場合、当初想定していた後続フェーズ開始時期の見直しやプロジェクトの頓挫につながる。
同様の事例はこれまで数件経験しているが、いずれもプロジェクトリード（主管部門）がIT部門の場合に発生している。IT部門の立場からすれば、ECC6.0が使えなくなるためS/4HANAへ移行する必要があるわけだが、システム導入の目的がS/4HANAの導入自体になってしまっており、経営陣からの承認取得が難しい。
経理部や経営企画部などの業務部門が主管部門を担当し、IT部門はプロジェクト推進をサポートする形を選択した場合、RFPに現行の業務やシステムの課題が盛り込まれる。その業務課題の解決がS/4HANAへの移行プロジェクトの目的となる。そのため多額の費用をかけるプロジェクトの承認が得られやすくなると考える（当然、経営陣には定量、定性両面の効果を示す必要がある）。
ブラウンフィールドを選択したとしても、開発プロジェクトが開始された際は、従来のシステム構成から一部が変更・廃止・追加される。経理部や購買部門などユーザー部門の協力が不可欠となる。
新システムを構築するためユーザー部門に時間を割いてもらう必要がある場合も、プロジェクトの目的が業務課題の解決だと協力を得やすい。業務要件やシステム要件を導入ベンダーなどの関係者と擦り合わせる会議（セッション）への協力を要請するケースなどが挙げられる。ユーザー部門の業務課題やシステム課題を改善するシステムを作成することにつながるため、積極的な協力が得られやすいプロジェクトとなり得る。
以下に筆者がこれまで経験した課題の例を挙げる。似たような課題を抱えているケースは多いのではないだろうか。
業務課題の例
- グローバルでは原価計算方法が異なり、原価比較ができない
- 品目コードが統一されていないため、在庫の融通が会社単位や地域単位で実施できない
- 得意先や仕入れ先コードが統一されていないため、同一製品をどこと取引するのが最も良いのかが分からない
- 会社単位で減価償却方法が異なるため、どの会社がもうかっているのかを把握できない
システム課題の例
- アドオンが多く、バージョンアップに時間とコストがかかっている
- サーバー構成が複雑でメンテナンスが煩雑である
業務課題はIT部門にとって課題として認識されていないこともある。システム上の仕様は固まっているから変えられない（変更できない）と考えるからであり、変更可能との認識を持ちにくいためだ。
構想策定はIT部門とユーザー部門が互いの理解を深められるフェーズでもある。IT部門はS/4HANAの勉強会などを開催して業務側のメンバーのシステムに対する理解を深めるとともに、業務側のメンバーはIT部門に対して自分たちが抱える業務課題を共有する。S/4HANAの導入を機に解決すべき課題や要望が明確になり、業務課題の解決を目的としたプロジェクト体制の構築が可能となる。
稼働時にマスター変更のリスクが正しく認識されていない
前回の構築から長い期間運用されてきたシステムは、利用しているマスター以外に現在は使われなくなったマスターやトランザクションデータが大量のごみとして登録されている例が多い。S/4HANAへ移行する際、それらを除外して「きれいな」環境を構築したいというニーズは存在する。
一例を挙げると、過去の製品を製造するためのBOM（部品表）と所要量計算などの関連情報や品目マスターなどが大量に蓄積されているケースだ。数百万件のデータをデータクレンジングし、新システムへ移行したプロジェクトも存在する。
親会社と子会社でECC6.0を利用しているが、マスターの体系が異なることでデータを共有できないなどの弊害を抱えている企業もある。この場合、全社統一のマスター体系整備から始める。現行システムが使用しているマスターの項目と新システムが利用するマスターの項目をマッピングし、データ移行の際に変換する。ただし、マスターの項目が一対一で変換できない場合、その対応は難度が増して膨大な時間が必要となる。
これらの事例では、S/4HANAの導入をきっかけにマスターを整備するという方針を構想策定時に計画した。だが、そのボリュームやデータクレンジングの難度を考慮したスケジュールの見積もりが甘かった。結果的にデータ移行時のマスター整備が間に合わないことに起因した新システム稼働日変更にまで至った。
ここで挙げた事例は、変更を予定する各事象で発生が想定されるリスクやその影響度について、対応方針・対応策をどこまで検討していたかが重要となる。特にマスター関連の変更についてはS/4HANAを開発するベンダーは関与せず、移行データの準備はユーザー企業側のタスクとなる場合がある。
そのため構想策定時にどのマスターを整備したいのか、整備にはどの程度の工数が必要かを把握し、潜在的なリスク（移行時までにマスターが間に合わないなど）を認識したロードマップの作成が必須である。マスター整備の難度を試算するため、事前に一部のデータをサンプルとして変更作業を行い、潜在的なリスクの有無を確認し、ロードマップの作成に生かすことでリスクの回避が可能となる。
「Fit to Standard」を掲げたが大量のアドオンを作成
「Fit to Standard（F2S）」を掲げているSAP ERP関連のプロジェクトをよく耳にする。筆者も様々なF2Sプロジェクトを経験している。アドオンプログラムを数本に抑え、S/4HANAの標準機能に適合する率（Fit率）が90％以上というケースもあれば、アドオンを数百本作成したプロジェクトまで様々である。
多くのプロジェクトは、アドオンプログラムを作成する前にアドオン作成の判定会議を開く。アドオンプログラムの意義や目的、工数（金額）などを考慮し、本当に必要なプログラムかを判断した上で開発する。本来であればこの会議の審議によってアドオンプログラムの本数は抑えられることになる。
だが、多くのプロジェクトでは、利用部門から「アドオンプログラムがないと業務が回らない」といった反対意見が強く出て、アドオン開発が減らないのが現状である。プロジェクトを推進するIT部門は、利用部門の反対を押し切れるほどの力がないことも多く、当初の方針とずれた大量のアドオンプログラムを生み出すF2Sプロジェクトとなる。
F2Sへの取り組み方の詳細を本特集の第3回で解説するが、構想策定フェーズでの対応によってF2SのFit率に影響が及ぶことは確認しておきたい。
3つの失敗例を挙げて対応策に触れたが、構想策定フェーズではIT部門だけではなく、関連する業務部門をプロジェクトに巻き込み、業務とIT双方の現状の課題認識を合わせることが重要である。その上で、各課題への対応についての最終的な落としどころを決め、プロジェクトの方針とする必要がある。
構想策定フェーズでコンサルタントを起用する場合、経験豊富なコンサルタントであれば多岐にわたる事例に対応可能であり、まずは課題を共有し、対応策をディスカッションすることをお勧めする。
第3回はF2Sの取り組み方を解説する。
関連情報
お問合せ
お問合せ