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年問題」を抱えるユーザー企業とコンサル業界、何が問題なのか
第2回：プロジェクトで発生する課題と対応策、失敗事例から学ぶ「2027年問題」対応
「SAP ERP 6.0（ECC6.0）」の標準保守が2027年末に終了する「2027年問題」。「SAP S/4HANA」への移行が急がれるが、移行の際の有力な手法が「Fit to Standard（F2S）」である。第3回は2027年問題に「間に合わせる」観点から、F2Sを解説する。
F2SはERP（統合基幹業務システム）の導入手法を指す用語である。業務内容に合わせてシステムの機能を変更したり、追加のプログラム（アドオンプログラム）を開発したりするのではなく、業務をERPの標準機能に合わせること、標準機能を業務に使うことを指す。独SAPのERPだけで使われる用語ではないが、S/4HANAの導入案件でがぜん注目されるようになった。
S/4HANAを始めとするSAP製品はパッケージシステムである。どの会社でも使われることを前提とした汎用的なシステムであり、全ての業界、全ての会社の業務に必ずしも合っているとは限らない。SAP製品が発展する中で、様々な業界の業務に対応できる機能が標準機能として備わってきているものの、自社の業務運営上必要な機能がパッケージシステムに装備されていないことはままある。その場合はアドオンプログラムを開発し、システムを業務に合わせる形を採用してきた。
SAPはパッケージシステムへの定期的なアップデートプログラムを利用企業に提供している。そのアップデートプログラムが本特集の第1回で触れたEHP（SAP enhancement package for SAP ERP）である。SAPが提供する標準機能のみで構成した社内システムであれば、簡易な動作検証のみで利用が可能だ。
しかし、アドオンプログラムを用いたシステムの場合、その動作検証に工数がかかる。それもアドオンプログラムが多ければ多いほど、検証作業の負荷は高くなる。そのためEHP6.0以上へのアップデートを見合わせていた企業は多い。こうした反省もあり、S/4HANAへの移行段階では、F2Sによる導入を目指す企業が増えている傾向にある。
S/4HANAの導入に限った話ではないが、2つの進め方がある。
1つは、やや先進的な取り組み方で、S/4HANAを標準機能の範囲でのみ使用する方法である。この進め方は、要件定義フェーズでS/4HANAの標準機能を説明し、標準機能を使って業務運営をする手法である。業務要件を一切確認しないため、標準機能に業務オペレーションがマッチしない場合は、業務オペレーションを変えるためのコンサルティングを実施する。
この進め方の場合、S/4HANAへのインターフェースプログラム以外のアドオンプログラムは基本的に作成しない。そのため、システム導入自体は短期間、低コストで対応可能である。この導入手法は、事業規模が小さな企業や取引形態がシンプルな業界で需要が高い。
SAPの「SAP R/3」が日本で導入された約30年前の導入手法はこの手法が主流であり、会計システムのみの導入の場合、数カ月で設定が完了した。ユーザー教育やデータ移行などを含めても短期間で導入、低コストで開発が可能だった。そのため、SAPの導入プロジェクトは開発ベンダーの売り上げに貢献せず、業務をシステムに合わせる手法が導入手法として採用されるようになったと考えられる。
2つ目は、アドオンプログラムを開発するものの、最小限にとどめる進め方である。ECC6.0までの業務要件定義では、現行業務を確認した上でその業務にシステムが合うかを検討する進め方をしていた。そのためアドオンプログラムの開発件数が多くなる傾向にあった。
一方、S/4HANA化のプロジェクトでF2Sを目指す企業に対しては、S/4HANAの標準機能を紹介し、まずは標準機能で業務オペレーションが可能かを確認してもらう。標準機能でカバーできない業務に対しては、業務オペレーションの変更を検討する。業界慣習などで業務オペレーションが変更できない場合は、S/4HANA以外のシステムで対応することを検討する。どうしてもS/4HANAで対応しなければならない業務のみ、アドオンプログラムを開発するように進める。
実際、筆者が経験したFI（財務会計、GL〔総勘定元帳〕、AP〔債務管理〕、AR〔債権管理〕）とCO（管理会計、PCA〔利益センター会計〕、CCA〔原価センター会計〕）の導入プロジェクトでは、前述の進め方でアドオンプログラムを最小化し、2本のアドオンプログラムのみに、具体的には周辺システムとのインターフェース連係のプログラムとファームバンキングデータを活用した入金消込プログラムのみに抑えた事例がある。「標準機能のFIT率」で90％以上は非常に高い数値だが、実現できないわけではない。
S/4HANAを標準機能の範囲でのみ使用する進め方は、S/4HANAとのインターフェースプログラム以外はアドオンプログラムを開発しない。そのため以下で説明するプロジェクトにおける機能は必要ない。
2つ目の進め方の場合、業務要件定義で整理した業務要件を実現するため、必要なアドオンプログラムの開発を判定する会議を設ける。この会議では、アドオンプログラムの必要性（法対応で必要な情報を保持するための項目など）や開発工数、開発難度などを説明し、開発可否を判断する。
アドオン判定会議の判定者がIT部門のメンバーだけで構成されていると、業務部門が説明するアドオンプログラムの必要性について妥当性を判断しきれない場合がある。また、アドオンプログラムを不採用とする場合、該当業務を知らないIT部門の判定者だと、業務オペレーションの変更などに対する代替案の提示が難しい場合が多い。
業務部門がIT部門より「力」が強い場合、IT部門は業務部門から要望された事項にノーと言えないことも多く、業務部門が必要だと説明するアドオンプログラムを結局は開発するプロジェクトが多い。
IT部門が判定者の問題点
アドオンの妥当性、開発しない場合の影響や回避策を正しく判定できない、業務部門に対してノーが言いにくい……
業務部門がアドオンの妥当性を正しく説明できない理由
変化を嫌う、プロジェクトへの参画意識が乏しい、F2Sの目的やプロジェクトの方針を理解していない、回避策が他システムに関連する場合の知見がない……
では、F2Sをプロジェクト方針としている場合、どのような対応が取れるだろうか。
まず、F2Sをプロジェクト方針とし、プロジェクトの共通認識事項にしてプロジェクトメンバー全員に理解してもらうことが重要である。具体的には、システム開発時およびシステム稼働後の影響を理解してもらう。
開発時
稼働後
といったことだ。
次にIT部門だけではなく、プロジェクトの主管部門の部長や役員がアドオンプログラム開発判定会議にアドオンプログラム判定者として参加してもらう。その必要性を当該業務部門から説明してもらい、開発可否を判断する。つまり、アドオン判定会議の判定メンバーの構成次第でアドオン採用率は下げられる。
さらにアドオンプログラムの抑制が必要な場合は、各部門の年度目標として標準機能のFIT率を採用し、いかにアドオンプログラムの開発を回避するかを「自分事」として考える仕組みも有用である。
筆者は、S/4HANA化のプロジェクトの主管部門をIT部門ではなく、経理部や経営企画部、購買部門などの業務部門とし、IT部門は主にプロジェクト全体を運営する体制を推奨している。S/4HANA化のプロジェクトでは、業務部門に長期間にわたり長時間のセッションに参加してもらう必要がある。IT部門が主管部門の場合、IT部門は原則敷かれたレールに乗るだけの存在になる。いずれにせよ業務部門は、業務要件やシステム要件の検討に工数を割かなければならない。その役割を率先して担うためにも各業務部門が主体となってS/4HANA化のプロジェクトを推進する方が望ましいと考える。
S/4HANAでは、複数のアドオンプログラムの開発手法（拡張方法）がある。ここでは（1）「クラシック拡張」（2）「In-App拡張」（3）「Side-by-Side拡張」の3つを紹介する。手法によっては将来のアップグレード時の影響を避けられる。
クラシック拡張
従来の開発手法であり、ERP環境の中にアドオンプログラムを開発する。SAPのERP用プログラミング言語であるABAP（Advanced Business Application Programming）を活用して様々な要件に対応しやすい。ただし、アップグレード時の影響が大きく、アップグレード時の動作検証に工数がかかる。
In-App拡張
S/4HANA内部でABAPを用いて開発する手法だがSAPが事前に用意したAPI（アプリケーション・プログラミング・インターフェース）を使って開発する。この拡張方法は以下の2種類の方法が存在する。
Side-by-Side拡張
ERP環境とは別のSAP BTP（Business Technology Platform）上でアドオンプログラムを開発する。疎結合でデータをやりとりする方法であり、S/4HANAの外に開発することでバージョンアップ時の確認工数がIn-App拡張に比べて少ない。半面、開発工数は多くなる。
S/4HANAになり、クラシック拡張以外のIn-App拡張やSide-by-Side拡張といったアドオンプログラムの開発手法を採用することで、バージョンアップ時に与える影響は小さくなったと言える。しかし、従来の開発方法（クラシック拡張）に比べて新しい開発手法（In-App拡張やSide-by-Side拡張）は開発工数が多くなる。この点を考慮すると、最良の方法とは言い難い。SAPは新方式の開発手法を拡充している段階であり、全てのアドオンプログラムが新しい手法で開発できるわけではない。そのため、従来のクラシック拡張の対応も継続している。
現在、筆者が関与しているプロジェクトは、業界慣習的に一部の機能がSAPには向かない業種である。そのため、S/4HANAで実現しようとすると多数のアドオンプログラムを開発しなければならない。そこで、主にS/4HANAでアドオンプログラムを開発するのではなく、S/4HANA以外の外部パッケージシステムやスクラッチシステムを作成。S/4HANAに合わない機能群をまとめてモジュール化して外部システムで管理し、データ連係だけ行う方法を採用している。
この選択の効果は、アドオンプログラムを最小限に抑え、開発費用もS/4HANA環境にアドオンプログラムを作成するよりも安価である。開発技術者の確保についてもSAPを活用した業務およびシステム設計をするコンサルタント（SAPコンサルタント）に比べれば容易である。
S/4HANAを活用するメリットは、購買／在庫情報から販売、会計までデータがつながり、各取引がリアルタイムで多次元（品目別、顧客別、地域別など）にデータ分析できる点だと考えている。このメリットを最大限生かすのは、業務改革を併せて実行し、標準機能でS/4HANAを活用できる場合である。アドオンプログラムだらけの状態では、定期的なバージョンアップが必要なS/4HANAの維持管理が困難であり、S/4HANAのメリットを享受し続けるのは容易ではない。
そのため、業務運用がしやすい形のシステム構成や運用面を考慮した結果がS/4HANA＋周辺システムの組み合わせとなった。決して新しい発想ではないものの、業界特性などによって業務をシステムに合わせられない領域が多い企業は、全てをS/4HANAに詰め込む必要はない。データ連係しやすいシステム構成で開発することによって、より使いやすい形を実現できる。
第4回は、第1回で述べたグローバルリソースを活用したプロジェクトにおける課題とその対応策を提示する。
