SAP S/4HANAへの移行を、AI対応のデータ基盤へと変える

13:34

S/4HANAへの移行では、変革プログラム以外ではめったにないような形で、マスターデータが重要な課題として取り上げられることになります。

しかし通常、マスターデータの範囲は、S/4HANAプログラムの移行および運用に必要な項目を中心に最初に定義されます。資材・製品、ビジネスパートナー、財務データについては、ERPへの移行に十分な管理体制が整っている場合もありますが、製品情報管理（PIM）、製品ライフサイクル管理（PLM）、顧客関係管理（CRM）、サプライヤーシステム、および地域別アプリケーションにおける関連コンテンツ、関係性、分類については、プログラムの当面の範囲外にとどまっています。

問題は、AIイニシアチブにおいてサプライヤー、製品、財務データ間の整合性が必要となった際に、その基盤が整っていないことが判明して初めて表面化します。

その時点で、この取り組みを可能にしていたプログラム予算や経営陣の関心は、もはや失われているかもしれません。

マスターデータ管理（MDM）は、その基盤を築くための取り組みです。

これは、レコードの所有者、適用されるルール、接続するシステムを定義するものです。ほとんどのS/4HANAプログラムでは、ERPをサポートするのに十分なMDMが構築されています。しかし、AIの場合は、それよりもはるかに広範なMDMが必要となります。

ERP向けのMDMとAI向けのMDMには、どのような違いがあるのでしょうか？

ERP中心のMDMは、ERPに必要な運用モデルやプロセスに合わせて、ガバナンスが適用されたマスターデータを最適化します。

AI対応のMDMは、その基盤をドメイン、システム、および関係性にわたって拡張し、AIが孤立したレコードではなく、一貫性のあるビジネスコンテキストに基づいて推論できるようにします。

一部の人にとっては些細な違いに聞こえるかもしれませんが、これによりデータがサポートできる範囲が変わってきます。

サプライヤー、製品、財務データにまたがって動作するAIエージェントは、レコードを1つずつ読み取るわけではありません。関係性全体を横断して推論を行います。どのサプライヤーがどの原材料と結びついており、どの原材料がどの製品構成に組み込まれ、それが市場に応じて異なる価格を持つのか、といったことを把握するのです。

こうした広範な文脈は、S/4HANAプログラムからは自動的に導き出されるものではありません。SAP Master Data Governance（MDG）は、SAPおよびサードパーティのデータを統制・統合できますが、多くの企業では依然として関連するデータを別々のアプリケーションで管理しています。これらの領域が意図的に整合されない限り、同じエンティティであっても、システム全体を通じて異なる定義や関係性を持つことになりかねません。

例としては、次のようなものがあります：

PIMデータ
サプライヤーポータル
地域データベース
ECプラットフォーム
顧客マスターデータ

全社的なガバナンスモデルがなければ、識別子、定義、および関係性は、依然としてこれらのシステム間で一貫性を欠いたままになる可能性があります。

なぜS/4HANAへの移行が、AIに向けたマスターデータの整備に最適なタイミングなのでしょうか？

エンタープライズ・トランスフォーメーション・プログラムは、組織がマスターデータを大規模に整備するために必要な経営陣の指示と業務上の勢いの両方を兼ね備えている、数少ない機会の一つです。

こうしたプログラム以外では、その必要性は認識されていても、予算が確保されない場合があります。競合する優先事項によって、その対応は毎回先送りされてしまうのです。

S/4HANAプログラムは、通常は未解決のまま放置されがちな疑問を突きつけることになります：

このデータの所有者は誰か？
誰がルールを徹底させるのか？
地域ごとの差異はどのように調整されるのか？

移行・変換専用の予算とプロジェクトチームがあれば、これらの課題を解決するまたとない機会が得られます。システム稼働後は、こうした集中的な支援や資金提供が減少してしまうことがよくあります。

しかし、だからといってMDMプラットフォームがSAPの移行ツールの代わりになるわけではありません。SAPが移行を実行・検証する一方で、Stibo Systemsの信頼できるインテリジェンスプラットフォームであるSTEPの役割は、それらのプロセスが依存するマスターデータを準備、整合、ガバナンスし、本番稼働後もより広範なシステム環境全体でそのガバナンスを維持することにあります。

同じ問題は後になって再び表面化します。多くの場合、AIイニシアチブでデータの一貫性が求められるものの、活用できる基盤がなく、修正に充てる資金を提供するプログラムも残っていないという状況です。

S/4HANAだけでなく、AIにも対応できるデータ基盤とはどのようなものか？

1. ドメインを横断してデータを整合させる

ある製品は、調達部門、営業部門、財務部門のいずれが確認しても、同じ意味を持ちます。サプライヤーの分類は資材仕様と整合しています。市場の階層構造は、地域を問わず一貫しています。

2. ガバナンスを文書化するのではなく、組み込む

ルールはインフラ自体に組み込まれており、繁忙期には誰も確認しないポリシー文書に記されているのではなく、すべてのレコードに自動的に適用されます。

3. AIへの入力の追跡を可能にする

ガバナンスが施されたデータにリネージ、プロバンス、関係性、およびルールのコンテキストが含まれている場合、AIシステムに提供された情報は、その情報源まで遡って追跡することが可能です。これにより、モデルのあらゆる判断が本質的に説明可能になるわけではありませんが、データのコンテキストは監査可能となり、調査が容易になります。

4. ユースケースに必要な最新性のデータを提供する

価格設定、在庫の再調整、サプライヤーリスクの監視など、多くの運用型および自律型AIのユースケースでは、最新またはほぼリアルタイムのデータが必要です。定期的な照合のみを目的として設計された基盤では、これらをサポートできない可能性があります。

したがって、重要な違いは単にSAP対非SAP、あるいはバッチ処理対リアルタイム処理という問題ではありません。AIユースケースが実際に依存するシステムやデータの新鮮さ要件を横断して、ガバナンス、セマンティクス、およびデータ提供が設計されているかどうかが鍵となります。

SAPの範囲内でのMDMは、ERP内で最初の2つを実現できます。残りの2つ、特にSAPが所有していないシステムを横断するリアルタイム運用については、最初からAIを念頭に置いて構築された基盤が必要です。

S/4HANAへの移行中にマスターデータを修正することで、どのような4つの成果が得られるのでしょうか？

プログラムの過程でこれを適切に実施すれば、以下の4つの成果が得られます。

1. 本来ならもっと早く発見されるべきだったデータの不整合によって、テストや本番移行が頓挫することがなくなります。

資材、製品、サプライヤー、および主要な階層構造について明確な定義と責任者が定められていれば、プログラムを運営するチームは、テストサイクルの途中でデータの問題を追跡する必要がなくなります。

2. 国や事業部門をまたぐデータの整合化が迅速化します。属性、分類、測定単位における地域ごとの差異は、共有モデルに基づいて調整される一方で、重要な市場ごとの違いは維持されます。その結果、プログラム実施中の手直し作業が減り、本番稼働後のデータ修正作業も軽減されます。

3. 材料・製品、サプライヤー、その他のマスターエンティティに対するガバナンスの行き届いた標準モデルにより、特注のマスターデータマッピングが削減され、下流のシステム連携に対して一貫性のある意味論的ソースが提供されます。

4. 本稼働後の展開に向けた基盤が整います：

S/4HANAはプロセスの実行方法を標準化します
マスターデータは、データが何を意味するかを標準化します

Stibo Systemsが公開した製造業の顧客事例では、これが企業規模でどのように実現されるかが示されています。S/4HANAへの移行の一環として、この組織は500以上のアプリケーションと1,000以上のインターフェースにまたがる200以上のレガシーデータモデルを5つのセマンティックモデルに集約し、600以上のグローバルプロジェクトを支援しました。

エンタープライズMDMは、SAP MDGやSAP Business Data Cloudとどのように位置づけられるのでしょうか？

SAP MDGは、SAPマスターデータドメイン全体にわたる一元的なガバナンス、統合、および大量処理を行うための有力な選択肢であり、SAPおよびサードパーティのデータソースと連携可能です。また、SAPによるReltioの買収により、Business Data Cloud内におけるSAPのマルチドメインMDMの立場もさらに強固なものとなっています。

これにより、アーキテクチャに関する問いも変化します。もはや、SAPがS/4HANA以外のデータをガバナンスできるかどうかという問題ではなく、組織がSAP、非SAP、および将来のアプリケーション環境全体において、エンタープライズ・マスターデータの所有権、セマンティクス、およびガバナンスをどこに配置したいかという問題に変わりました。

STEPは、SAP MDGを補完したり、SAP Business Data Cloudと共存したり、あるいはより広範な環境全体にわたるエンタープライズ・マスターデータのコントロールプレーンとして機能したりできる、独立したマルチドメイン・ガバナンス層を提供します。STEPを活用することで、企業は以下のことが可能になります：

共有されたマルチドメインモデル内で、関係性や階層構造を明示的に定義し、製品、サプライヤー、顧客、および拠点データをガバナンス下に置く
SAP R/3、ECC、S/4HANA、および100以上の事前構築済みコネクタと統合ライブラリとの連携が可能
変更が人によるものであれ自動化によるものであれ、ガバナンスルール、ワークフロー、検証、および権限を適用する
トレーサビリティを確保するため、ガバナンス対象の変更に関する監査可能な履歴と出所情報を保持
「Data as a Service」およびStibo Systems MCP Serverを通じて、AIエージェントにガバナンス対象のマスターデータおよびセマンティックコンテキストへの標準ベースのアクセス権を付与し、エージェントの特注統合の必要性を低減します

まとめると

S/4HANAへの移行は、ERPの枠を超えて活用できるマスターデータを構築する、またとない機会となります。

プログラムの段階で範囲を適切に設定すれば、双方にメリットが表れます。テストはより円滑に進み、データの整合化に伴う手戻りが減り、統合もより簡単になります。

サプライヤー、製品、財務データにわたって推論を行うAIエージェントは、その基盤がすでに整っていることを前提としています。この好機を逃してしまうと、結局は後で同じ作業をやり直すことになり、当初それを可能にしたプログラム予算や経営陣の注目も得られなくなってしまいます。

なぜこの好機が特定のタイミングで訪れるのか、またAI対応のデータ基盤には何が必要なのかについてさらに詳しく知りたい方は、アクセンチュアと共同執筆したホワイトペーパー『AI at Scale』をダウンロードしてください。

よくある質問

SAP S/4HANA移行前に、材料およびサプライヤーデータをどのように標準化しますか？

まず、各ドメインの所有権を特定のチームに割り当て、その後、何が有効、完全、または重複データと見なされるかを決定するルールを文書に残すのではなく、コード化します。

そこから、ERP、PIM、サプライヤーポータルに存在する異なるバージョンを各エンティティごとに1つの管理されたレコードに統合し、そのレコードをそれを利用するすべてのシステムに接続します。

これをカットオーバー前に行うことで、移行チームは本番稼働中に不整合を見つけるのではなく、クリーンなデータに対してテストを行うことができます。

どのMDMプラットフォームがSAP S/4HANAと最も相性が良いですか？

普遍的な答えはありません。選択は、ターゲットアーキテクチャ、ガバナンス運用モデル、ドメイン、共存要件、および信頼できるマスターデータがSAPを超えてどの程度まで広がる必要があるかに依存します。

SAP MDGは、組織がSAP中心の中央ガバナンスと統合を望む場合に強く適しています。 STEPは、マルチドメインガバナンスがERPから独立して維持され、SAPおよびより広範な異種環境に対応する必要がある場合に強く適しています。一部のアーキテクチャでは、両者が共存しています。

SAP MDGと専用のマルチドメインMDM、どちらが長期的に見てより良い選択ですか？

それは「どちらのツールが優れているか」という一律の選択ではなく、アーキテクチャの責任に帰着します。 SAP MDGとSAP Business Data Cloud内のReltioは、SAPのお客様により広範なマスターデータの選択肢を提供します。

STEPのような専用の独立したマルチドメインプラットフォームは、組織が複数のERP、PLM/PIM、CRM、サプライヤーシステム、チャネル、将来のAI消費者にまたがる1つのガバナンスレイヤーとセマンティックモデルを望む場合に最も差別化されます。これにより、エンタープライズマスターデータの所有権が1つのアプリケーションスイートに依存しないようにします。