カテゴリー: Uncategorized

エネルギー事業者には、メールや電話で毎月数千件の顧客問い合わせが寄せられます。その多くは分割払い計画、支払期限の延長、請求書の再発行、引越し手続きといった定型案件です。大規模言語モデル（LLM）はこの業務の大部分を担えますが、それはSAPと安全かつ確実に接続されている場合に限ります。本番プロジェクトから得た教訓をご紹介します。

明確で件数の多い業務から始める

「カスタマーサービスでAIを使う」はユースケースではありません。次のようなものがユースケースであり、これらだけで日常業務の大きな割合を占めます。

• 分割払い計画：依頼内容を認識し、条件を確認して、SAP S/4HANA Utilitiesに分割払い計画を登録。
• 支払期限の延長：定められたルールの範囲内で支払期限の猶予を付与。
• 請求書の再発行：顧客と請求書を特定し、写しを自動送付。
• 引越し手続き：転入・転出データを取得し、SAPで引越しプロセスを起動。

AIによるメールの振り分け

受信したメールはすべてLLMが分類します：どの業務か、どの契約アカウントか、どのデータが不足しているか。明確な案件は自動処理され、それ以外は要約と回答案を添えてSAP Customer Engagementの適切なチームに振り分けられます。

ホットラインの接続：CognigyとSAP

同じ業務は電話でも利用できます。Cognigyベースのボイスボットが電話に応答し、顧客を特定し、請求書の写しの送付や支払期限延長の登録などをSAPで直接実行します。待ち時間はありません。

アーキテクチャ：Azure、Databricks、SAP BTP

• Azure OpenAIが言語モデルを提供し、データ保護要件を満たすリージョンで運用します。
• Databricksはデータ準備、分析、モデル周辺のAIパイプラインに使用します。
• SAP BTP Integration Suiteが統合レイヤーとして、モデルの出力を検証し、マスターデータで補完し、適切なSAP APIを呼び出し、エラーを処理します。
• SAP S/4HANA UtilitiesとSAP Customer Engagementは、引き続きすべての業務取引の基幹システムです。

重要：LLMがSAPバックエンドと直接やり取りすることはありません。統合レイヤーにより、モデルが誤ってもSAPの整合性が保たれます。

人の関与を残す

判断が難しい案件はAIの提案を添えて担当者に回します。完全自動化される案件の割合は、期待ではなく実績に基づいて段階的に増えていきます。

データ保護と権限

• モデルをどこで動かし、どのデータを参照させるかを定義する。
• システム呼び出しごとに最小権限の技術ユーザーを使う。
• 判断を記録し、追跡・監査できるようにする。

最初から運用を計画する

AIソリューションに「完成」はありません。プロンプト、モデル、SAPのリリースは変化し続けます。モニタリング、ChaRMやCloud ALMによるリリースプロセス、明確なオーナーが不可欠です。SAP AI Core、Joule、Model Context Protocol（MCP）といったSAP自身の製品動向にも注目しましょう。

まとめ

SAPのカスタマーサービスにおけるAIは、モデルの問題としてだけでなく、統合とガバナンスのプロジェクトとして取り組めば機能します。SAPにおけるAIサービスの詳細をご覧いただくか、お問い合わせください。

スイスの電力市場は、ここ数年で最大の変化を迎えています。2024年6月にスイス国民投票で承認された「再生可能エネルギーによる安全な電力供給に関する連邦法」（通称「Mantelerlass」）により、エネルギー事業者と送配電事業者は新しい市場モデルに対応しなければならず、それをSAP IS-UやSAP S/4HANA Utilities上で実現する必要があります。

エネルギー事業者にとって何が変わるか

• 地域電力コミュニティ（LEG）：同じ自治体内の消費者と発電者が、公共の送配電網を使って地域で発電した電力を共有でき、託送料金が軽減されます。
• 仮想自家消費グループ（vZEV）：接続点の内側での共同自家消費の選択肢が拡大します。
• ダイナミック料金や新しい料金モデル、さらに計量とデータ交換に関する追加要件。

SAPにとっての意味

SAP S/4HANA Utilitiesでは、これらの要件が機器・設備構造、料金計算と料金設計、エネルギーデータ管理（EDM）、市場間通信、顧客向けフロントエンドに影響します。業務面の変更に加えて技術面の変更も必要です：新しいFioriアプリ、新しいロールと権限、インターフェースの調整、そして整った移送・本番稼働プロセス。

現場からの教訓

• 権限はクリティカルパス上にある。新しいトランザクションやFioriアプリにはロールが必要で、権限不足は本番稼働時の最も多い問題の一つです。早めにトレースし、実際に近いユーザーでテストしましょう。
• まず標準機能を使う。SAPや業界パートナーは規制対応コンテンツをますます提供しています。アドオン開発の前に確認しましょう。
• 移送とChaRMを慎重に計画する。複数の規制プロジェクトが同じシステム上で並行することが多く、調整なしでは競合は避けられません。
• 運用パートナーを早期に巻き込む――ロール、移送、システムコピーのために。

私たちのご支援

私たちはLEGとMantelerlassの要件をS/4HANA Utilitiesに実装してきました。権限コンセプト、Fioriロール、移送、本番稼働支援も含みます。S/4HANA Utilitiesサービスの詳細をご覧いただくか、お問い合わせください。

多くのSAP環境では、今もSAP Process Orchestration（PI/PO）が基幹インターフェースを担っています。SAP PO 7.5のメインストリームメンテナンスは2027年末に終了し、延長メンテナンスは2030年まで提供されます。今こそSAP Integration Suiteへの移行を計画すべき時です。実際の移行の進め方をご紹介します。

1. 完全な棚卸しから始める

移行の前に、すべての統合シナリオを洗い出します：送信元と受信先、アダプタの種類、マッピング、メッセージ量、エラー率、業務上の責任者。多くの環境では、驚くほど多くのインターフェースがすでに使われていないか、標準APIで置き換えられます。廃止したインターフェースは移行する必要がありません。

2. 判断する：そのまま移行、再設計、置き換え

• そのまま移行：シンプルで安定したシナリオは、SAPの移行ツールと軽微な調整で移せることが多いです。
• 再設計：複雑なマッピングやBPMプロセスは、Groovyスクリプトと再利用可能なコンポーネントを使ったシンプルなiFlowとして作り直す方が良い場合がほとんどです。
• 置き換え：SAPや相手システムが最新のAPIを提供している場合は、ファイルやIDocのインターフェースではなくそちらを使います。

3. セキュリティと接続性を早期に固める

遅延の多くはマッピングではなく接続性に起因します：SAP Cloud Connectorの設定、証明書、OAuthクライアント、技術ユーザー、ファイアウォールの開放、SFTPキー。これらはBASISチームやホスティングパートナーと初日から計画しましょう。特に責任が貴社・SAP・運用事業者に分かれるRISE with SAPでは重要です。

4. BTPガバナンスを確立する

Integration SuiteはSAP BTPの一部です。アカウントとサブアカウントのモデル、命名規則、移送経路（例：SAP Cloud ALMやTransport Management Service）、モニタリングとアラート、そして誰が何をデプロイできるかを定義しましょう。これらのルールがなければ、新しいプラットフォームもすぐに旧環境と同じように混乱します。

5. ウェーブ単位で移行し、並行稼働させる

インターフェースを業務プロセスとリスクに応じてウェーブに分けます。業務部門とエンドツーエンドでテストし、ウェーブごとに切り替え、最後のウェーブが安定するまでPI/POシステムをフォールバックとして残します。

まとめ

PI/PO移行は単なる技術的義務ではなく、統合環境を整理する好機です。棚卸し、アーキテクチャ、実装の支援をご希望の場合はお問い合わせください。SAP BTP・Integration Suiteサービスの詳細もご覧ください。