多くの企業は、プロセスの整理が終わる前にSAPのモジュールを選んでしまいます。そのリストがSIに渡され、SIはそのリストをもとに見積もりを出し、半年後にはスコープが倍に膨らみます。モジュールが支えるはずだったプロセスの半分が、そもそも合意されていなかったからです。この順序こそ、私が目にするスコープクリープの最も多い原因です。
この順序を逆にするために、このツールをつくりました。業種、規模、実際に動かしている業務プロセスを入力してください。出発点となるモジュール一覧、検討に値するBTPコンポーネント、モジュール間の依存関係を踏まえた段階的な展開計画が返ってきます。これは議論の入り口であって、答えではありません。答えは、ブループリントから出てきます。
出力はベンダー中立です。GROWよりRISEを、BTPよりコア内の拡張を推すことはありません。アーキテクチャがおそらくどのような形になるかを示すので、SIとの協議に、質問ではなく自分の立場を持って臨めます。
ドロップダウンから業種を選び、企業規模を設定し、実際にスコープに含まれる業務プロセスを選択します。ツールは、業種への適合度に応じてコアモジュールに重みを付け、該当する場合は業種別バリアントを加え、ギャップが実在する箇所にBTP拡張を提案し、全体をフェーズに並べます。
ロードマップを生成する前に、提案内容を編集できます。事業のことは、ツールよりも皆さん自身がよくご存じです。ツールの役目は、議論がゼロから始まるのを防ぐことです。
- コアモジュール一覧。FI/CO、MM、SD、PP、HCMなど、プロセスに必要なERP基幹モジュール。
- 業種別モジュール。該当する場合の、銀行、小売、ヘルスケア、製造向けのバリアント。
- BTP拡張。標準のSAPと実際の業務とのギャップを埋める、Integration Suite、Build、AI Coreなどのプラットフォーム機能。
- 連携マップ。モジュール同士の位置関係と、明らかな連携ポイントがどこにあるか。
- 段階的なロードマップ。どのモジュールをフェーズ1に入れ、どれをフェーズ2に回すか、そして崩せない依存関係はどれか。
Create your SAP implementation roadmap
Fields marked * are required.
- FI（財務会計）。総勘定元帳、買掛金管理、売掛金管理、固定資産会計。譲れない中核です。
- CO（管理会計）。原価センタ、利益センタ、内部オーダ、製品原価計算。通常はFIとセットで導入します。
- MM（在庫購買管理）。調達、在庫、仕入先管理、請求書照合。
- SD（販売管理）。受注から入金まで、価格設定、出荷、請求。
- PP（生産計画）。個別生産、プロセス製造、繰り返し生産。プロセス産業向けにはPP-PI。
- HCM（人的資本管理）またはSuccessFactors。コアHR、給与、タレント。新規構築の多くは、フロント業務にSuccessFactorsを採用し、現地の法令遵守が求める場合にはSAP Payrollを残します。
- EWM（拡張倉庫管理）。基本的な保管場所を超えるあらゆる機能。ウェーブ管理、スロッティング、労働力管理。
- PM（プラント保全）。設備資産の多い業種向け。保全オーダ、予防保全、通知。
- QM（品質管理）。検査、不適合、サンプリング。特に規制の厳しい業種向け。
- PS（プロジェクトシステム）。プロジェクト主導型の事業。建設、エンジニアリング、設備投資の追跡。
- TM（輸送管理）。貨物輸送、ルート計画、運送会社との連携。
- GTS（グローバルトレードサービス）。通関、制裁リストのスクリーニング、特恵貿易。
- BTP（Business Technology Platform）。Integration Suite、Build、AI Core、HANA Cloud。コアに置くべきでないあらゆるものを受け持つ拡張レイヤーです。
- インダストリークラウド（小売、銀行、公益事業などの業種向けS/4HANA）。S/4HANAの上に載る、業種別のデータモデルとプロセス。
まずプロセスから始めてください。モジュールからではありません。受注から入金まで、購買から支払まで、記録から報告まで、採用から退職までの流れを、自社で今動いている姿のとおりに説明できないなら、モジュールを選ぶ準備はできていません。グリーンフィールドかブラウンフィールドかの議論がこじれるのを私は何度も見てきましたが、そのすべてが、この手順を踏まずに始まっていました。
思い切ってフェーズ2に回してください。ほとんどのお客様は、すべてをフェーズ1に入れたがります。実際に必要なお客様は、ほぼいません。EWM、TM、GTS、PS、そして高度な分析レイヤーは、たいてい後でも間に合います。まずFI、CO、MM、SD、PPを安定させます。残りは、事業が変化を消化してから加えます。
クリーンコアの原則は、スローガンではなく規律として扱ってください。コアへのカスタマイズは、2度のコストを生みます。作るときに1度、そしてその後10年間のアップグレードのたびにもう1度です。プロセスに独自ロジックが必要なら、BTPに置きます。コアはクリーンなまま保たれ、拡張は移植しやすいまま残ります。ほとんどのプログラムで、これが最も大きなアーキテクチャ上の判断ですが、フェーズ1で正しく判断できている例はほぼありません。
BTPは、先進的に見える場所ではなく、ギャップが実在する場所に使ってください。Integration Suiteが真価を発揮するのは、スコープ内にSAP以外のシステムが3〜4つを超えるときです。Buildが真価を発揮するのは、Fioriの標準に収まらないワークフローやローコードアプリが必要なときです。AI Coreが真価を発揮するのは、明確なユースケースがあるときであり、スライドに「何かAIでやるべきだ」と書いてあるときではありません。
- 製造業（個別生産とプロセス製造）
- 小売・消費財
- 金融サービス・銀行
- ヘルスケア・ライフサイエンス
- 物流・運輸
- エネルギー・公益事業
- 建設・エンジニアリング
- 公共部門・政府機関
- プロフェッショナルサービス
- 通信
- ホスピタリティ
- 教育
業種ごとに、モジュールの組み合わせが変わります。製造業ではPP、QM、多くの場合EWMが加わります。小売ではSD、MM、そしてインダストリークラウドのバリアントが中心になります。銀行と保険は、S/4HANA上に独自のデータモデルを持ち込みます。ヘルスケアでは、標準モデルが備えていないコンプライアンスと患者記録の複雑さが加わります。
- ベンダー選定の前にアーキテクチャの規模を見積もるCIOとITディレクター。
- ステアリングコミッティの精査に耐える段階的な展開計画をつくるプログラムディレクター。
- パートナーが提案したモジュール一覧の妥当性を確認するCFOと財務責任者。
- 顧客との協議に向けて、根拠のある出発点をまとめるアドバイザーと独立系コンサルタント。
- SIを迎える前に、初期のアーキテクチャ検討を進める社内の変革チーム。
- 根拠のある出発点。SIの見積書ではなく、プロセスの論理から導いたモジュール一覧です。
- ブループリントが速く進む。数週間ではなく、議論を始めて数時間で前に進みます。
- フェーズ分けが組み込み済み。ロードマップは、パートナーが先に売りたいものではなく、依存関係の順にモジュールを並べます。
- BTPとコアの切り分けが明確。何をプラットフォームに置き、何をコアに置くかの、最初の線引きです。
- ベンダー中立。RISE、GROW、特定のエディションを推す動機はありません。
- 無料で、プライバシーも守られます。ブラウザー上で動作します。データがお使いのマシンの外に出ることはありません。
このツールは、特定のSAP製品を推奨しますか、それともモジュールだけですか？
特定のSKUではなく、カテゴリー単位でモジュールとBTPコンポーネントを提案します。表示されるのは、FI/CO、MM、SD、PP、Integration Suite、AI Coreなどの構成要素です。RISE with SAP、GROW with SAP、オンプレミスのS/4HANAのどれを選ぶかは決めません。その判断は、モジュールの組み合わせではなく、導入形態の希望、インフラ、契約面での考え方で決まるからです。
製品エディションの協議では、モジュール一覧をベンダーとの話し合いに持ち込み、各オプションでの価格を提示してもらってください。
BOM（構成表）をエクスポートできますか？
はい。出力はフェーズ付きのモジュール一覧で、スプレッドシート、ブループリント文書、提案書にそのままコピーできます。一覧は、SAPパートナーの価格テンプレートにきれいに対応する構造になっています。
BOMにもっと厚みのある説明を付けたい場合は、私のSAP導入コスト計算ツールが、組み合わせて使える費用の枠組みを示します。
提案にはRISE with SAPが組み込まれていますか？
いいえ。RISEは、S/4HANA Cloud、BTPクレジット、マネージドサービスを包む商用パッケージです。このツールが見るのは、機能面で何が必要かです。それをRISEで利用するか、GROWで利用するか、従来型のライセンスで利用するかは別の判断で、ホスティングの希望、ITの運用モデル、運用のどこまでをSAPに任せたいかで決まります。
モジュール一覧はどちらの場合も同じです。変わるのは契約の形です。
BTP拡張にも対応していますか？
はい。Integration Suite、Build（ローコードとプロセス自動化）、AI Core、HANA Cloud、そしてより広い拡張レイヤーも対象です。BTPが役立ちそうな場面を示します。SAP以外との連携が数件を超える場合、独自のワークフローが必要な場合、明確なAIのユースケースがある場合です。BTPを、それ自体が目的であるかのように提案に加えることはありません。
BTPレイヤーの考え方の軸は、クリーンコアの原則です。カスタマイズが避けられないなら、ERPのコアではなくBTPに置きます。
業種別のバリアントはどうなりますか？
インダストリークラウドのバリアント（小売、銀行、公益事業、プロフェッショナルサービスなどの業種向けS/4HANA）は、選択した業種が該当する場合に組み込まれます。業種別モジュールも同様です。プロセス製造向けのPP-PI、公益事業向けのIS-U、銀行向けのIS-Bなどです。これらは独立した項目として表示されるので、なぜ提案されたのかがわかります。
複数の業種にまたがる場合（サービス部門が強い製造業や、製造部門を併せ持つ小売業など）は、主となる業種を選び、副次的なモジュールは手動で追加してください。
新規のSAPユーザー向けですか、既存ユーザー向けですか？
どちらにも使えます。新規のお客様は、ベンダー選定の前に初期アーキテクチャの案をつくるために使います。既存のお客様は、現在の構成を検証したり、本来導入しておくべきだったモジュールを見つけたり、フェーズ2の拡張範囲を見極めたりするために使います。モジュールを導入済みとしてマークすれば、フェーズ分けのロジックは既存の構成を踏まえます。
ECCからS/4HANAへの移行の途中であれば、何を引き継ぎ、何を廃止し、何を追加するかを決める助けになります。その場面ではBTPの提案がより重要です。従来のECC環境の多くは、新しいコアの外に置き場所が必要なカスタムコードを抱えているからです。
フェーズ分けの提案はどのくらい正確ですか？
フェーズ分けには、ほとんどのプログラムに当てはまる依存関係のロジックが反映されています。FIとCOはMMの前、MMはSDの前、コアERPはEWMとTMの前、BTPによる連携は、SAP以外のシステムとの本格的な結合の前です。一方、組織としての変化への対応力、規制上のスケジュール、決算サイクルは反映されません。それに応じて調整してください。
すべてを一度にやろうとするプログラムを見てきました。うまくいきません。フェーズ1は、事業が新しいプラットフォーム上で帳簿を締め、顧客に対応できるための最小限にとどめるべきです。それ以外はすべてフェーズ2です。
このツールは無料ですか？
はい。登録もメールアドレスの入力も支払いも不要です。提案はすべてブラウザー上で処理され、データが保存されたり送信されたりすることはありません。
出力を実際のブループリントに仕上げたい、またはパートナーの提案を検証したいという場合は、30分の通話を予約してください。