S/4HANAアップグレードで最も差が出るのは「カスタマイズ整理」
**SAP S/4HANAへのアップグレードを検討・実行する際、
多くのプロジェクトで最後まで悩み続けるテーマがあります。
それが 「既存カスタマイズをどこまで持っていくか」 です。
機能面や技術面の検討は進んでいても、
- この設定は本当に必要なのか
- S/4HANAでも同じやり方でよいのか
- 将来のアップグレードや拡張に耐えられるのか
といった問いに、明確な基準を持てないまま移行を進めてしまうケースは少なくありません。
S/4HANAは、ECCの後継製品ではありますが、
「ECCをそのまま新しい基盤に載せ替える製品」ではありません。
本記事では、S/4HANAアップグレードを前提に、
- 不要となったカスタマイズ
- 見直しが必須となるカスタマイズ
- S/4HANAで新たに重要になった設計観点
を整理し、なぜそう判断すべきなのかを解説します。
S/4HANAでは「カスタマイズの前提条件」が変わった
S/4HANAでカスタマイズの考え方が変わった最大の理由は、
技術基盤と設計思想の変化にあります。
データモデルの簡素化
S/4HANAでは、財務・管理会計を中心にデータモデルが大幅に整理されました。
代表例が Universal Journal（ACDOCA）です。
これにより、
- 集計用テーブル前提
- 転記・調整処理前提
- 二重管理を補うための設定
といった設計思想自体が不要になっています。
処理性能の前提変更
インメモリDBを前提としたS/4HANAでは、
ECC時代に常識だった
- 夜間バッチ
- 事前集計
- パフォーマンス回避のための分岐設定
は、設計理由そのものを失っています。
S/4HANAアップグレードで「不要になった」カスタマイズ
S/4HANAでは、以下のようなカスタマイズは
引き継ぐべきではない対象になります。
二重・冗長な勘定決定ロジック
ECCでは、FIとCO、あるいは管理目的ごとに
細かく勘定決定を分岐させる設計が多く見られました。
S/4HANAではデータが統合されているため、
このような分岐は保守性を下げるだけで、業務価値を生みません。
集計・実績管理用のZテーブル
「レポートが重いから」「標準では足りないから」という理由で
作られた集計用Zテーブルも、S/4HANAでは不要になる代表例です。
リアルタイムで標準テーブルから集計できるため、
独自集計ロジックはむしろ障害要因になります。
バッチ前提の処理設計
夜間処理・締め処理前提で作られた設定やロジックは、
S/4HANAの強みを殺してしまう設計です。
「動くが、残すべきではない」見直し必須カスタマイズ
S/4HANAアップグレードで最も判断が難しいのが、
**「技術的には動作するが、残すべきではない」**カスタマイズです。
過剰に増えた伝票タイプ・移動タイプ
長年の運用の中で、
- 部門ごと
- 業務ごと
- 歴史的経緯
で増え続けた伝票タイプや移動タイプは、
S/4HANAでは整理対象になります。
Fit to Standardを前提とするS/4HANAでは、
標準プロセスを理解し、業務を寄せる判断が不可欠です。
独自チェックロジックによる制御
「業務ミス防止」を目的としたZチェックロジックも、
S/4HANAでは標準機能やBAdIで代替できるケースが多くあります。
ECC時代の「とりあえずZ」は、
S/4HANAでは将来負債になりがちです。
S/4HANAで新たに重要になるカスタマイズ観点
S/4HANAでは、「カスタマイズしない」ことが正解ではありません。
重要なのは “やり方”が変わった という点です。
Clean Core前提での設計
S/4HANAでは、SAPが公式に Clean Core を打ち出しています。
これは、
- コアを極力標準に保つ
- 差分は限定的に、影響範囲を明確に
という考え方です。
アップグレード時には、
このカスタマイズはコアに置くべきか？
を必ず問う必要があります。
拡張ポイント（BAdI）を第一選択に
S/4HANAでは、拡張ポイントが整理され、
従来よりも安全に拡張できるようになっています。
「Zプログラムを書く前にBAdIを探す」
という判断が、標準になります。
外部拡張という設計選択
S/4HANAでは、
すべてをERPの中で完結させる必要はありません。
アップグレードを機に、
- コアに残すもの
- 外に出すもの
を分けて設計できるかどうかが、
将来の保守性を大きく左右します。
アップグレードでよくある失敗パターン
S/4HANAアップグレード案件でよく見られるのが、
- 「とりあえず全部持っていく」
- 「移行後に考える」
- 「前は問題なかったから残す」
という判断です。
その結果、
- 不要な設定が温存される
- アップグレード対応が重くなる
- 新機能・AI活用がしづらくなる
という問題が後から顕在化します。
S/4HANAアップグレード成功の鍵は「減らす判断」
S/4HANAアップグレードで最も重要なのは、
何を追加するかではなく、何を捨てるかです。
- 技術的に不要になったもの
- 歴史的に残っているだけのもの
- 標準で代替できるもの
これらを整理できるかどうかで、
S/4HANAは「新しい基幹システム」にも
「重たいECCの延命」にもなります。
まとめ｜S/4HANAではカスタマイズは「設計思想そのもの」
S/4HANAのカスタマイズは、
単なる設定作業ではありません。
- 標準を理解し
- 業務と対話し
- 将来を見据えて削る
この意思決定こそが、S/4HANAアップグレードの成否を分けます。
ECC時代の成功体験を一度リセットし、
S/4HANAの前提で再設計すること。
それが、S/4HANAを「本当の刷新」にするための第一歩です。
※本記事は2025年12月時点の情報です。最新情報は公式サイトをご確認ください。
コメント