2025年06月16日
Fit to StandardによるS/4HANAの導入とは
S/4HANAの導入は、ERPの標準機能に業務を合わせる「Fit to Standard」のアプローチが基本となります。
Fit to Standardといっても、最小限の追加開発を行ったり、ERPの外に機能を準備するケースもあります。
今回は、前回の記事(ピークは2030年!?S/4HANAへの移行を考えよう)の中で触れたS/4HANAにおけるFit to Standardの狙い、開発のポイントについて、記したいと思います。
Fit to Standardアプローチの概要と背景
「Fit to Standard」とは、ERP(Enterprise Resource Planning)パッケージの導入手法に関する用語であり、業務プロセスをERPの標準機能に合わせること、標準機能を業務に活用することを指します。
ERPパッケージは、幅広い業界や企業に対応可能な汎用的なシステムとして設計されていますが、すべての業界や企業に完全に適合するとは限りません。
SAP製品の場合も同様で、多種多様な業界や業務に対応可能な機能が提供されていますが、日本企業の特定の業務要件を完全に満たす機能が不足する場面もありました。
過去の課題とアプローチの転換
こうした状況を受け、SAP社のパートナー企業は、これまでSAP ECC向けに業界・業務テンプレートをアドオンとして提供し、特定のニーズに対応してきました。
しかし、これらのアドオンは以下のような課題を引き起こしています。
●移行プロセスでの負担増大: ECCのアップグレードや、Enhancement Package(EhP)の適用、S/4HANAへの移行時において、大量の検証作業と多大な工数が必要となる。
●システムの複雑性: アドオンの導入により、システム全体が複雑化し、長期的な運用の効率が低下するリスク。
こうした経緯を踏まえ、最近では「Fit to Standard」アプローチが再評価され、S/4HANAの導入時には、GreenfieldでFit to Standardで再構築されるケースが増加しています。
Fit to Standardの現状と必要性
S/4HANAは、そのライフサイクルにおいて2年ごとに新バージョンがリリースされます。さらにその間、3回のFeature Package Stack(FPS)が提供され、新機能が随時追加されています。
特に、今後はAI関連の機能が急速に進展し、これらの新機能を活用することで、業務効率や意思決定がさらに改善されることが期待されています。
このような進化する環境下では、S/4HANAを効果的に活用するためにも、アドオンを極力少なく抑え、「Fit to Standard」のアプローチが求められています。
これにより、システムのアップグレードや保守作業にかかる負担を軽減し、新機能の恩恵を迅速に受けられるようになります。
Fit to Standardをプロジェクト方針とする際の課題
Fit to Standardを導入方針とする場合には、プロジェクトメンバー間で以下の点についての共通理解が重要となります。
●アドオン開発の負担: アドオン開発に必要な工数や納期、また稼働後の保守およびアップグレード時の検証作業が大きな負担となる可能性。
●標準機能への業務適合: 業務プロセスを標準機能に寄せることができないか、業務変更を前提にした検討。
●業務部門の理解: 標準機能に合わせることで既存業務が変更される可能性があるため、業務部門との十分な対話と理解が不可欠
業界特有の慣習や規制により業務プロセスを変更できない場合は、以下の対応策の検討が必要となります。
●S/4HANA以外のシステムを活用: 既存業務に適した別のシステムを選択する。
●最低限のアドオン開発: S/4HANAでのみ対応可能な業務に限り、必要なアドオンを開発する。
最近では、アドオン開発を行う際に、S/4HANAの外部で開発・運用するケースが増えています。これにより、標準機能との分離が図られ、アップグレード時の影響を最小限に抑えることができます。
S/4HANAにおけるアドオン開発の手法と考慮点
S/4HANAのアドオン開発には、大きく分けて以下の3つの手法があります。それぞれ特徴が異なり、要件に応じて適切な方法を選択することが重要です。
クラシック拡張
従来の開発手法であり、S/4HANA内部に直接アドオンを開発します。この方法では、S/4HANAの主要なプログラミング言語であるABAPを活用し、柔軟な対応が可能です。
ただし、以下の課題があります:
・アップグレード時に影響を受けやすく、検証工数が増大する。
・システムの複雑化により、長期的な運用負荷が増加する可能性。
In-App拡張
S/4HANA内部での開発ですが、SAP社が提供するAPIやツールを利用して拡張を行います。
この手法には以下の2つのタイプがあります:
・キーユーザ拡張:ローコード・ノーコードツールを利用して比較的簡単に開発が可能。
・開発者拡張:ABAPやADT(ABAP Development Tool)を活用した開発が可能。
In-App拡張はクラシック拡張に比べ、アップグレード時の影響を軽減できるため、よりモダンなアプローチとされています。
Side-by-Side拡張
SAP社のPaaSであるSAP BTP(Business Technology Platform)上でアドオンを開発する手法です。この方法では、S/4HANA外部で拡張機能を構築し、疎結合でデータをやり取りします。
その結果、以下の利点があります:
・S/4HANAのアップグレード時における検証工数が最小限で済む。
・独立性が高く、柔軟な設計が可能。
また、考慮すべき点としては、以下の2点が挙げられます。
コストと工数: In-App拡張やSide-by-Side拡張は新しい技術を活用する分、開発工数がクラシック拡張よりも多くなる場合があります。
実現性の限界: 新しい拡張手法では対応できない要件も存在するため、クラシック拡張が依然として必要になるケースもあります。
まとめ
JSOLは、1995年からSAP ERP導入ビジネスに取り組み、医薬業界や食品業界、消費財業界、組立製造業界を中心とした豊富な導入実績を誇ります。
特に医薬業界では、50社以上の導入経験を持ち、トップシェアを誇ります。
この豊富な導入実績を支えてきたのは、各業界向けのテンプレート「J-Model」があるからです(詳細はこちら)。
JSOLでは、ECC時代からF2Sでカバーできない、日本の業界慣習に合わせた機能をJ-Modelテンプレートとして拡大してきました。
一方、S/4HANAにおいては、アップグレードの影響を最小化するため、クリーンコアアプローチが重要視されています。
JSOLでは、S/4HANAをクリーンに保ち、S/4HANA外部のBTPでの提供にも取り組んでいます。
J-Modelの一部の機能について、BTPでの提供を始めています。
日本経済に求められるアジリティのためには、継続的なイノベーションが欠かせません。
このイノベーションをS/4HANAやSAPの各種Cloud製品から受けるためにも、中心となるS/4HANAはクリーンコアを維持できることがポイントと考えています。
JSOLの専門知識と経験を活かし、貴社のビジネスをサポートいたします。
ぜひ、弊社にご相談ください。
※本記事に記載されている製品・サービス名称は、各企業・団体の商標または登録商標です。
「RISE with SAP」の利用やSAPの「2025、2027年問題」など、SAP導入・移行に当たって必要となる「SAPベーシス」領域を取り巻く状況を見てきましたが、いかがでしたでしょうか。
特にS/4HANAへの移行に関しては、ERP6.0の保守サポート期限が2年間延長されましたが、SAPシステムの刷新の検討期間としては、十分に長い猶予が与えられた訳ではありません。この期間で自社のシステムの位置づけを再確認して、社会の変化に対応できる「システム」または「体制」を整えることの検討が必要です。
JSOLは、本ブログでご紹介しましたように、システム刷新や導入検討時にネックとなる体制のリソース不足解消の一助となるベーシスサービスを提供できます。
ぜひSAPシステムの導入・移行をご検討の際には、お声がけください。
SAP BASIS ソリューション
https://promotion.jsol.co.jp/sap/basis.html
RISE with SAPってなに?5分で知るRISE with SAP魅力とは
https://promotion.jsol.co.jp/sap/blog/rise-with-sap-vol1.html