リアルタイムで数百件のテーブルを扱いつつ、大量のデータを取り込むといった処理が基幹システムに集中することで、以下の3つの課題が浮上した。

1. インフラ増強費用の肥大
   • 分析需要の急増に伴って、オンプレミスのSAP BWのバックエンドであるSAP HANAを継続的にスケールアップする必要が生じた。
2. システムリソースの逼迫（ひっぱく）
   • SAP BWでのリアルタイムデータ消費が集中し、処理能力の上限に達しつつあった。
3. 運用・監視工数の肥大化
   • 連携先のシステム群を含めた性能監視、Azure Data Lake向けデータパイプラインの整合性の確保やスナップショット維持に、多大な工数を割かれていた。

　本番のERPシステムに重いクエリを投げることは、SLA（サービス品質保証）の観点から許容できない。基幹業務の安定稼働を守りつつ、増大するデータ需要に応えられる新たなアーキテクチャがZeissには必要だった。

リアルタイムデータ統合アーキテクチャ「FeRDI」の設計

　Zeissのデータチームは、これらに対処するために2つのアプローチを採用した。1つ目は、「Microsoft Azure」を用いて各事業部がデータを自律管理しつつ、共通ルールで統制する「連邦型（フェデレーテッド）ガバナンス」の導入。2つ目は、基幹システムに直結するリアルタイムデータ統合基盤FeRDIの内製開発だ。

リアルタイムのデータ集約

　全社ERPにある数百件のビジネスクリティカルなテーブルを、リアルタイムにSAP HANA Cloudに複製・集約する。これによって、本番ERPに負荷をかけずに「発生元システムと同一状態の生データ」をクラウドサービス内に再現した。

分析ハブと仮想データ共有

　SAP HANA Cloudに集約されたデータは、データ統合・管理ツール「SAP Datasphere」に引き渡す。SAP DatasphereはSAP BWとも連携して、データを重複して丸ごと二重保存（永続化）することなく、Azure Data LakeやDatabricksへと仮想的に中継・共有する。

参照系インタフェースの集約

　FeRDIはデータ分析だけではなく、一部の業務システムが必要とする参照系データの供給口としても機能する。これによって、システム間で1対1のインタフェースを都度開発する非効率さを解消した。

データオブザーバビリティによる品質統制

　クラウド移行と同時に、Zeissはデータパイプラインの信頼性を確保するためにデータオブザーバビリティ（可観測性）の仕組みを実装した。監視の柱として以下の要素を定常トラッキングしている。

• 鮮度と遅延
  • ERPでのデータ発生から連携先までの到達時間。
• データ量
  • 転送レコード数の異常な増減。
• データの来歴（リネージ）
  • データの生成元から下流レポートまでの依存関係。
• スキーマドリフト
  • ERPシステムでの列追加・型変更などテーブル定義の検出。

　これによって、元システムでスキーマが変更されても、下流の分析レポートやエンドユーザーに障害が顕在化する前にデータチームが即座に検出できる体制を構築した。本番ERPに負荷を掛けずに業務ルールに基づいたデータ品質検証が可能になり、システム的な整合性の確保だけではなく、各事業部門の商取引や業務プロセスがルール通りに運用されているかどうかを監査するガバナンスとしても機能している。

年200万ユーロ削減から生成AI連携へ

　FeRDIの導入によって、Zeissは1043件のテーブル、合計3.6TBのデータをSAP HANA Cloud経由で運用する体制を構築。6000人以上のエンドユーザーが新システムを利用している。

　システム刷新によって得られた成果は以下の通りだ。

• 運用費用の削減
  • 運用効率化やインフラ最適化によって、年間200万ユーロを削減。
• データ提供リードタイムの短縮
  • データの抽出や整合性確認といった下準備が不要になり、データ提供スピードが向上。
• 現場オペレーションの即時化
  • 翌朝にバッチ処理で更新していた業務レポートがリアルタイムに更新されるようになり、数時間のタイムラグが解消したことで、より迅速かつ的確な意思決定が可能になった。

　Zeissは今後に向けて、FeRDIを土台にしたデータインフラを整備し、AIアシスタント「SAP Joule」とMicrosoftのAIアシスタント「Microsoft 365 Copilot」を組み合わせた取り組みを進めている。両者を連携させることで、エンドユーザーが自然言語で社内データに安全にアクセスして、インサイトを得られる仕組みの実現を目指す。