導入事例：移すべきアドオン、捨てるべきアドオン、外に出すべきアドオン ― Emulus Consulting の ABAP → Spark ― S/4HANA 移行の前に、集計・加工系の Z プログラムを ERP の外へ
概要 提供：Innovational Office Solution お客様：Emulus Consulting 対象：Z / Y プログラム 320 本を分析し、うち集計・加工系 85 本を Spark へ変換 自動変換精度：70%～90%（残りは ABAP と Spark の両方に詳しい専門家が仕上げ） お問い合わせ：Admin@innovationalofficesolution.com 無料PoC：AnyBI to Power BI & AnyETL to Fabric ページ 背景：S/4HANA 移行で最も重いのは「アドオン」 SAP ERP 6.0 のメインストリーム保守は2027年末に終了し、延長保守も2030年末までです。Emulus Consulting でも S/4HANA への移行計画が進んでいましたが、見積もりの中で突出していたのがアドオン（カスタム ABAP コード）の改修工数でした。
日本企業の SAP は、「業務を SAP に合わせる」より「SAP を業務に合わせる」形で導入されてきた例が多く、帳票・集計・データ連携のための Z プログラムが数多く作られています。S/4HANA ではデータ構造が変わる箇所があるため、これらはそのままでは動かない可能性があり、一本ずつ確認と改修が必要です。
SAP 自身も、移行の少なくとも1年前から本番環境で ABAP の利用状況（ABAP Call Monitor：SCMON / SUSG）を収集し、使われていないコードを削除することを推奨しています。平均的な ECC システムでは、カスタムコードの多くが本番で一度も実行されていないためです。また SAP は、標準を極力変更せず拡張を外に出す「クリーンコア」の考え方を打ち出しています。
お客様の判断：アドオンを3つに分ける 利用データとコード解析の結果、Emulus のアドオンは次のように分類されました。 廃止 本番で 12 か月以上実行されていない S/4HANA へ持ち込まない
ERP 内に残す 伝票登録・更新、ワークフロー、画面拡張など業務トランザクションに必要 S/4HANA 向けに改修（SAP のツールを利用）
ERP の外へ出す（本事例の対象） 大量データの読み取り・集計・加工・帳票・外部連携ファイル作成 Microsoft Fabric の Spark へ変換
3つ目は、ERP の中で動かす必要がないにもかかわらず、夜間バッチで ERP のリソースを大きく使っていたプログラム群です。これらを S/4HANA 向けに改修するのではなく、データ基盤側に移すことで、改修対象のアドオンを減らし、同時に ERP の負荷も下げることにしました。
変換のステップ STEP 1｜コード・利用状況の収集 本番の SCMON / SUSG データ、ジョブ実行履歴（SM37）、ABAP ソースを収集。各プログラムの実行頻度、所要時間、読み取りテーブル、更新の有無を一覧化しました。
STEP 2｜「外に出せるか」の判定 AI アクセラレーターがソースを解析し、データベース更新（UPDATE / MODIFY / BAPI 呼び出し）の有無、画面処理の有無、読み取り中心かどうかを判定。読み取りと集計が中心で、ERP の業務トランザクションに関与しないものを候補としました。
STEP 3｜データの準備 対象プログラムが読んでいる SAP テーブルを OneLake に取り込み、Silver 層で型変換（日付・数量・通貨）とクライアント（MANDT）の絞り込みを実施しました。
STEP 4｜ABAP から Spark への AI 変換 SELECT … FOR ALL ENTRIES / JOIN → Spark SQL の JOIN 内部テーブルの LOOP・READ TABLE → DataFrame の結合・ウィンドウ関数 COLLECT・SUM による集計 → groupBy().agg() AT NEW / AT END OF（コントロールブレイク）→ ウィンドウ関数による区切り処理 選択画面（SELECT-OPTIONS / PARAMETERS）→ ノートブックのパラメーター ALV 出力 → Power BI レポート / ページ分割されたレポート 外部連携ファイル出力（OPEN DATASET）→ OneLake / ファイル出力 バックグラウンドジョブ → Data Factory パイプラインのスケジュール 初期自動変換精度は 70%～90% です。
STEP 5｜突合（PulseQA） 同じ選択条件で ABAP プログラムと Spark ノートブックを実行し、出力の件数・合計値・明細を自動比較しました。特に、ABAP の固定小数点（TYPE P）と Spark の DECIMAL の桁、日本円の金額桁、日付の初期値（00000000）の扱いを重点的に確認しています。
ABAP と Spark の対応表 ABAP Spark（Microsoft Fabric）
SELECT / JOIN / FOR ALL ENTRIES Spark SQL / DataFrame join
内部テーブル（STANDARD / SORTED / HASHED） DataFrame
LOOP AT … / READ TABLE 結合・フィルター・ウィンドウ関数
COLLECT / SUM groupBy().agg()
AT NEW / AT END OF ウィンドウ関数（row_number、lag など）
SORT / DELETE ADJACENT DUPLICATES orderBy / dropDuplicates
TYPE P（固定小数点） DecimalType（精度・スケールを明示）
SELECT-OPTIONS / PARAMETERS ノートブックパラメーター
ALV 出力 Power BI レポート / ページ分割されたレポート
OPEN DATASET（ファイル出力） OneLake / ファイル出力
バックグラウンドジョブ（SM36） Data Factory パイプライン
成果 アドオン 320 本のうち、廃止 35%、Spark へ移行 27%、S/4HANA 向け改修対象を 62% 削減 集計・加工系 85 本を 70%～90% の初期自動変換精度で Spark に変換 夜間バッチ：5 時間 → 28 分、ERP の夜間負荷を 45% 低減 S/4HANA 移行プロジェクトのアドオン改修見積もりを 48 人月削減 集計ロジックを Python / SQL で保守できるようになり、ABAP 技術者への依存を緩和 最も重い Z プログラムから 夜間バッチで最も時間のかかっている ABAP プログラム5本を Spark に変換し、処理時間と出力の突合結果を無料でお見せします。
Microsoft Solution Partner
S/4HANA 移行に向けたクリーンコア戦略。集計・データ加工系の Z プログラムを Microsoft Fabric Spark へ移行し、移行工数と ERP 負荷を削減します。
発行：Office Solution AI Labs（Microsoft Solution Partner for Data & AI）
#日本語 #SAP #ABAP #Spark #PySpark #Microsoft Fabric #クリーンコア #事例
0|
0
