「S/4HANA化」の成否は構想策定で決まる 後悔しないための実施事項と推進体制：「SAP 2027年問題」を再定義 手遅れを防ぐ初動と対策
SAP S/4HANA移行の成否は、要件定義前の「構想策定」で8割決まる。移行手法の選択や周辺システムの整理といった実務に加え、アドオン削減などの難題を突破するには業務部門を巻き込んだ推進体制が不可欠だ。後悔しないための具体的な実施事項を解説する。
この連載について
SAPの「2027年問題」の真のタイムリミットは保守期限ではなく、移行を担う「SAPコンサルタントの枯渇」にある。本寄稿連載は、ベンダーに放置される「移行難民」を回避するための初動から、成否の8割を握る構想策定の極意、RFP作成やアドオン削減を巡る業務部門との対立といった生々しい実務の壁を突破するための具体策を、全3回にわたって解説する。
連載1回目では、「SAP ECC 6.0」（以下、ECC 6.0）ユーザー企業が抱える「2027年問題」を解説し、SAPコンサルタント不足がいかに深刻か、また、すぐに導入の予定はなくとも早い段階で構想策定し、とり得る方向性やタイミングを見定める必要性について説明をした。その上で、「2027年問題」をひとごとと捉え、対策を先送りにすることは大きなリスクであり、一刻も早い初動が必要であることを強調した。
本稿では、移行プロジェクトの成否の8割を握ると言っても過言ではない「構想策定」の具体的な実施事項と、アドオン削減などの難題を突破するために不可欠な「推進体制」のポイントについて解説する。
加藤浩章氏（日本タタ・コンサルタンシー・サービシズ株式会社 グローバルコンサルティングプラクティス統括本部 コンサルティングパートナー）
べリングポイント（現PwCコンサルティング）、山九、野村信託銀行、あずさ監査法人、EYストラテジー・アンド・コンサルティング（EYSC）などを経て2024年から現職。
主に製造、金融、物流の国内およびグローバル企業におけるERP導入やIT中期経営計画の策定など業務とシステムの構想段階から要件定義までのコンサルティングに従事。その他、工場における製造現場の状況を踏まえた原価計算の再構築や決算早期化、内部統制対応までシステムから業務コンサルティングに至る幅広い経験を有する。
構想策定とその重要性
「ECC6.0をECC 6.0を『SAP S/4HANA』（以下、S/4HANA）に移行するだけであれば、要件定義から着手すればよい」と認識している人は多い。しかし、要件定義に入る前には、解決すべき課題や投資対効果を整理する構想策定が不可欠だ。
構想策定とは、プロジェクトの方向性や進め方を定義し、開始に向けて意思決定するフェーズだ。構想策定の主な検討事項は以下の通りだ。
S/4HANA化の手法を検討
S/4HANA化で採り得る手法は以下の2つだ。
- ブラウンフィールド： ECC6.0の全てのカスタマイズおよびデータを移行する手法。現行システムに不満がない場合に採用されることが多い。ただし、ECC6.0とS/4HANAのテーブル構成は一部異なるため要件定義が必要であり、ユーザーの関与が全く不要というわけではない
- グリーンフィールド： S/4HANAを新規で要件定義、設計・開発し、既存データを新環境に適する形に変換する。各マスターのコード桁数の変更なども想定し、データ移行する
現行業務の課題を整理
現行業務の課題を棚卸し、システム変更によって解決できる「システム要件」と、業務フロー自体の見直しが必要な「運用要件」に整理する。
S/4HANA化の対象業務と周辺システムを整理
ECC6.0を現在利用している部門に限定するのか、あるいは未利用の部門も含めてS/4HANA化を機にシステムを導入、刷新するのか、その適用範囲を整理する。また、周辺システムの棚卸しと整理を実施し、現行のインタフェースの状況についても詳細を把握する。
プロジェクト計画書を作成
プロジェクトのスケジュールや体制、目的、移行方法など、プロジェクトに必要な事項を検討、合意する。
要件定義フェーズのRFPを作成
構想策定フェーズと、その後の要件定義以降のフェーズを異なるベンダーに依頼する場合は、要件定義フェーズを任せるベンダーを選定するためのRFP（提案依頼書）を作成する。
構想策定はシステム部門のみで実施すべきではなく、各部門のエンドユーザーが関与することが望ましい。仮にブラウンフィールドを採用しても、テーブル構成などが変わるケースは多いことから、エンドユーザーのプロジェクト参画は必要不可欠であり、主たる業務と並行してプロジェクト活動に時間を割いてもらう必要がある。
こうした観点からも、社内の関係者と「プロジェクトに参加しなければならない」という共通認識を形成しておくことは重要だ。
また、機能面で大きな変更がないシステム構築に数億円〜数十億円規模のコストを投じるケースも想定される。そのため、社内（特に経営陣）の合意形成を図るに当たっては、単なるS/4HANA化にとどまらず、BPR（ビジネスプロセス・リエンジニアリング）の実現といった、より高い目標や大義名分を掲げることが不可欠となる。
BPR：社内の業務プロセスを根本から見直し、組織やシステム、職務などを再構築（リエンジニアリング）し、企業全体の生産性や競争力を向上させる経営手法。
繰り返しになるが、「構想策定の質が移行の成否の8割を決める」と断言できるほど、構想策定は重要だ。要件定義以降で迷走するプロジェクトの多くは、構想策定が不十分の状態で実施されていることに起因していると考えられる。
プロジェクトの推進体制や開発方針など「錦の御旗」を擁立する
プロジェクトの推進役は、業務部門が担うべきだ。Fit to StandardやClean Coreを掲げるプロジェクトでは、業務をシステム側に合わせる必要があるからだ。現行システムに多くのアドオンが残っていたり、それらを標準機能へ置き換えたりする場合、業務部門側で処理のステップ数が増える場合があり、従来の業務フローそのものの変更を余儀なくされるため、現場の主導的な関与が欠かせない。
また、会計システムや全社システムの刷新であれば、経理部門や経営企画部門がプロジェクトオーナーを担当すべきだ。
プロジェクトを主導するIT部門の多くは、経営陣にS/4HANAへ移行するための承認を得る際、業務の効率化に加え、定期的なバージョンアップが容易なシステムへと刷新することを掲げている。
この方針を実現するには、Fit to Standardに準拠して現行のアドオンを削減し、システムの保守工数を抑える必要がある。しかしエンドユーザー側には、現状の利便性を維持したまま、さらなる効率化や自動化を求めるニーズがあるため、両者の思惑は相反しやすい。
エンドユーザーのニーズが現行システムの標準機能で満たせれば問題ないが、実際はアドオンで対応しているケースが多く、移行後のシステムでもアドオンを維持する前提でプロジェクトを進めようとしがちだ。
こうした当事者間の思惑に食い違いが生じている企業のIT部門はアドオンを作らざるを得なくなり、Fit to StandardやClean Coreといった「錦の御旗」を掲げていてもアドオン開発だらけのプロジェクトになってしまう。
もしプロジェクトの推進役をユーザー部門が担う場合、経営陣への上申段階でFit to Standardの承認を得ていれば、業務部門がアドオン開発を要求してきた際もプロジェクト方針に沿って回避策を考え、アドオン数を削減し、Fit to Standardプロジェクトは成功に至るだろう。
アドオンの削減だけでなく、それ以外の側面においても業務部門の関与は不可欠だ。プロジェクトを成功させるには、業務部門自らが「自分たちの業務を改善する好機」と捉え、意欲的に取り組む機運を醸成することが欠かせない。こうした前向きな姿勢が、結果として業務部門主体のプロジェクト推進につながる。
構想策定終了時のチェックについて
構想策定を終えるまでに完了すべき事項を、あらかじめ明確にしておく必要がある。構想策定の本質とは、後続フェーズで発生し得るリスクを回避するため、検討方針や具体的な実施内容を事前に整理しておくことにあるからだ。
ITサービスベンダーに提示するRFPに盛り込むべき事項（スケジュール、利用モジュール、対象会社など）や経営陣の承認を取得するために必要な事項（開発費用の概算、スケジュール、人員体制など）を、この段階で十分に検討しておくべきだ。
普段からERPのような基幹システムを含む開発プロジェクトを経験しているユーザー企業であれば、自前で対応可能であろう。しかし、基幹システムのようなシステムを10年以上にわたって変更していない企業も多く、構想策定で実施すべき事項の網羅性に懸念がある場合は、第三者（構想策定を実施したITサービスベンダーとは異なる他のベンダー）に依頼することを推奨する。
各ベンダーは独自の基準で構想策定時に実施すべき事項のノウハウがあるため、構想策定を実施した内容とは異なる見解をもらえる可能性がある。また、特段の指摘事項がない場合は、第三者のお墨付きを得られたとも言え、今後の要件定義以降をスムーズに実施できるとも考えられる。
Copyright © ITmedia, Inc. All Rights Reserved.
