基幹システムのいま・これから
2022/02/24
SAPソリューション部 第一技術室
はじめに
会計システム、購買システム、販売システムなど、企業の業務処理の中枢を担うシステム群は基幹システムと呼ばれています。2000年以降、多くの大企業ではERPと呼ばれる統合パッケージ製品を基幹システムに採用していますが、パッケージ製品といってもそのまま利用されるわけではなく個社の業務に合わせて拡張開発されるケースが多く、後になってERPパッケージ上の膨大な自社独自機能の取り扱いに頭を悩ませる企業が増えています。今回のコラムでは、そんな基幹システム界隈の最新事情をお伝えするとともに、将来に向けての課題と今後の展望について考察します。
Fit & Gapの課題とFit to Standard
ERPパッケージの導入にはFit&Gap分析と呼ばれる導入手法が用いられてきました。これは、自社内の一つ一つの業務プロセスに対して、ERPパッケージの機能が適合(Fit)しているか、あるいは乖離(Gap)があるか、を判定するというものです。Gapがあると判定された業務プロセスに対しては、システム化せずシステム外で業務処理を行う、あるいはERPパッケージ上でアドオンと呼ばれる拡張開発を行う、といった対処を施しますが、Gapが大きければアドオンの量も膨大になりがちです。膨大なアドオンによりシステムが複雑化するとバージョンアップを容易に行うことができず、基幹システムが古いまま塩漬け状態となり最新の技術を取り入れることも出来ません。2018年に経済産業省が発表した「DXレポート ～ITシステム「2025年の崖」克服とDXの本格的な展開～」（*1）では、このように複雑なシステムを抱えた企業がデジタルトランスフォーメーション(DX)の恩恵を享受できず競争力を失っていく可能性について「2025年の崖」という表現を用いて指摘され、膨大なアドオンを保持し続けることへの危機感が日本国内でも広く認識されるようになりました。
このように従来のFit&Gapアプローチにおける課題が明らかになる中で、現在注目されている新たなERPパッケージ導入手法がFit to Standardです。Fit to Standardは、Fit&Gap分析のように自社業務プロセスにシステムを適合させるのではなく、ERPパッケージの提示する標準業務プロセス(Best Practice)に自社業務を適合させようというもので、大企業向けERPパッケージ最大手の欧州SAP社(以下SAP)が同社のERP製品であるSAP S/4HANA®を導入する際の方法論として提唱しています。Gapを発生させないようにパッケージに業務を合わせて拡張開発のボリュームを極小に抑えることで、塩漬けになりがちだったERPパッケージの頻繁なアップデートが可能となります。そして、常に最新バージョンのERPパッケージを利用できるようになることで、最新技術を取り込んだ新機能の活用が可能となり、DXの力による自社業務の効率化が期待できます。
■Fit&GapとFit to Standardの違い
（*1）参考：経済産業省「DXレポート～ITシステム「2025年の崖」の克服とDXの本格的な展開～」
https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/pdf/20180907_01.pdf
ERP拡張開発手法の進化とCore Clean
しかし、Fit to Standardを実践すれば拡張開発をなくせるかというと、そうではありません。精一杯合わせようとしても、ある程度の量のGapが以下のような理由でどうしても発生してしまいます。
● ERPパッケージの提供する標準業務プロセスのシナリオおよび標準機能が不足している
● 国固有・業界固有の商習慣にERPパッケージが対応しきれていない
● 管理会計の分析項目のように会社ごとに異なる要件があり各社で個別に拡張開発することが前提となっている領域がある
● 周辺システムとのデータ連携のように各社の周辺環境に合わせて個別に機能構築することが前提となっている領域がある
このようなGapに対して、SAPは「Side-by-Side拡張」「In-App拡張」という2つの新しい拡張開発手法を提示しています。
■従来のアドオンと新しい拡張開発手法の違い
① Side-by-Side拡張
ERPパッケージ外にある、SAP® Business Technology Platform (以下 SAP BTP)という環境を利用して拡張開発を行う手法です。SAP BTPはSAP製品の拡張開発を目的として用意されたPaaS環境で、ワークフロー、RPA、機械学習、といった基幹システムの拡張開発に有用な機能群がサービス提供されています。
疎結合の形で外付け開発を行うことでERPパッケージ本体のバージョンアップ時に受ける影響を小さくできますが、ERPパッケージ本体と別の場所に構築するためデータ連携や独立したユーザ管理を行う必要があり、開発・保守運用コストが大きくなりがちです。これに対してSAPはSAP BTPのサービス充実やローコードノーコード(LCNC)ベンダーAppGyverの買収・統合といった取り組みを通じて、Side-by-Side拡張のコスト低減を推進しています。
② In-App拡張
SAP S/4HANA(ERPパッケージ本体)内の、SAPが製品バージョンアップの影響を受けないことを保証する場所で拡張開発を行う手法です。従来のアドオンでは、ERPパッケージ内の標準機能のすべてのプログラム部品やテーブル類を自社の拡張開発機能と直接連携できましたが、In-App拡張ではバージョンアップの影響を受けないことをSAPが保証する限られた種類のインタフェースを介してのみパッケージ標準機能との連携が可能です。
In-App拡張の課題として、「キーユーザ拡張」と呼ばれるウィザード形式でのローコードノーコード拡張しか許可されておらず拡張開発の自由度が低い点が挙げられます。これに対してSAPは2021年11月に「デベロッパ拡張」(通称: Embedded Steampunk)と呼ばれる、開発者によるプログラム開発を可能とする新しいIn-App拡張のオプションを発表しました。2022年夏以降の提供開始が予定されており、今後In-App拡張においても開発の自由度向上が期待されます。
|
✓ 拡張開発要件に対して疎結合(Side-by-Side) / 密結合(In-App)を見極めて実装手法を適切に選択する |
| Side-by-side拡張に適した基幹システム拡張開発要件 | 対応するSAP BTPサービスの名称 |
| システムを跨いだプロセス自動化 | SAP® Process Automation (SAP® Workflow Management, SAP® Intelligent RPA) |
| 周辺システムとのシングルサインオン・ユーザ連携 | SAP® Cloud Identity Services (Identity Authentication, Identity Provisioning) |
| 周辺システムとのトランザクション・マスタデータ連携 | SAP® Integration Suite |
| システムメニューの統合・ポータルサイトの構築 | SAP® Launchpad Service, SAP® Work Zone |
| データウェアハウス構築・高度なデータ分析機能の実装 | SAP® Data Warehouse Cloud (DWC), SAP® Analytics Cloud (SAC) |
| 高度な機械学習(ディープラーニング)を用いた機能の実装 | SAP® AI Launchpad, SAP® AI Core |
| チャットボットを活用した機能の実装 | SAP® Conversational AI (CAI) |
| In-App拡張に適した基幹システム拡張開発要件 | 対応するSAP S/4HANAキーユーザ拡張の機能名称 |
| パッケージ標準機能への不足管理項目の拡張 | カスタム項目, カスタムビジネスオブジェクト |
| パッケージ標準機能のトランザクション・マスタ項目値自動編集 | カスタムロジック |
| パッケージ標準画面へのエラーチェック追加 | カスタムロジック |
| パッケージ標準画面のレイアウト調整 | UI適応 |
| 簡易なデータ分析レポートの実装 (Embedded Analytics) | カスタムCDSビュー, カスタムクエリ, KPIおよびレポート管理 |
| 簡易な機械学習を用いた機能の実装 (Embedded ML) | インテリジェントシナリオ管理 |
■Side-by-Side拡張とIn-App拡張の使い分け
2つの拡張開発手法に共通して言えることは、ERPパッケージ本体のバージョンアップの影響を受けない場所で拡張開発を行うという点です。このコンセプトはKeep the Core Cleanと呼ばれており、SAP S/4HANAのコア部分にアドオンせずクリーンな状態を保ったまま利用することでERPパッケージ本体を頻繁にバージョンアップできるようになり、基幹システムに新技術・新機能をスムーズに取り込めるようにする、という狙いがあります。
懸念点と今後の展望
ここまで述べてきたように、この数年で基幹システムの新たな導入手法や技術が続々と登場してきました。実際にこれらの新しい技法を用いて基幹システムを導入する動きが少しずつ広がり始めていますが、まだ登場して間もないこともあって十分に理解されていない面もあり、以下のようにFit to StandardやCore Cleanの考え方に懐疑的な声も聞かれます。
● システムに業務を合わせるというFit to Standardの考え方に対する抵抗感
● ERPパッケージの頻繁なバージョンアップのたびにパッケージ標準機能や拡張開発用のインタフェースに予期せぬ仕様変更や不具合が発生し、基幹システムの安定稼働を妨げる心配
● 新しい技法を十分に理解して実践できる高スキルな人材の育成・確保に対する不安
これらの疑念に対しては、今後世の中全体でFit to Standardや新しい拡張開発手法に対する経験が蓄積され対策が進むことで、少しずつ理解が得られていくことでしょう。
もう一つ大きな課題として、既にERPパッケージ上に膨大なアドオンを保持している企業がFit to Standard・Core Cleanの世界にどのように移行していけばよいのかというテーマがあります。思い切って一から基幹システムを作り直す方法、既存の基幹システムをバージョンアップしながら少しずつ新しい考え方に沿って作り変えていく方法が考えられますが、特に後者についてはまだ事例も乏しく、今後ノウハウが積み上げられていくことが期待されます。
また、歴史のある大企業においては、自社で長年かけて醸成されてきた業務プロセスが企業文化の一部として定着している場合もあり、Fit to Standardを敢行して既存の業務プロセスを捨て去るのが難しいケースもあるでしょう。おそらく将来の基幹システムは、新興企業を中心にFit to Standardの世界に飛び込んで手を掛けずに進化を目指す企業と、逆に手を掛けながらバージョンアップさせ独自の進化を遂げる企業とで、大きく二極化が進んでいくのではと想像します。
おわりに
今回のコラムではFit to Standard, Core Cleanという新しいキーワードと基幹システムの今後の展望についてお伝えしてきました。今回ご紹介した新しいトレンドが果たして今後新たなデファクトスタンダードとして世の中に定着していくのか、引き続き注目していきたいと思います。
三井情報ではお客様それぞれの事情を酌んだうえで最新トレンドを踏まえた基幹システムの最適解をご提案できるよう、これからもSAP最新技術動向のキャッチアップを継続してまいります。
執筆者
奥平 耕
SAPソリューション部 第一技術室
お客様基幹システムの導入プロジェクト・プリセールス・ソリューション開発の活動に従事する傍ら、SAP技術動向を観察しERPパッケージの使い方を研究中。
|
|
|
|
SAP、SAPロゴ、記載されているすべてのSAP製品およびサービス名はドイツにあるSAP SEやその他世界各国における登録商標または商標です。またその他記載された会社名およびロゴ、製品名などは該当する各社の登録商標または商標です。 |
|
