SAP BW/4HANAとBW on HANAの違いを比較｜設計・移行・運用の判断ポイント

SAP BW on HANAからSAP BW/4HANAへの移行を検討するときは、単純なデータベース変更として扱わず、データウェアハウスの設計要素と運用方法を比較する必要があります。両者はHANAのインメモリ処理を利用できますが、利用できるオブジェクト、データフロー、モデル設計の考え方が異なります。

特に判断材料になるのは、既存のInfoProvider構成、データ取得方式、変換ロジック、レポートへの公開方法、そして移行後に維持したい運用手順です。この記事では、設計と移行判断に必要な差分を実務の観点で整理します。

01BW/4HANAとBW on HANAの位置づけ

BW on HANAは、従来のSAP BWの機能をHANAデータベース上で動かす構成です。既存のInfoCube、古いデータフロー、互換性を考慮したオブジェクトを含む環境を段階的にHANAへ適応できます。そのため、既存資産を活用しながらデータベース移行の効果を得やすい点が特徴です。

SAP BW/4HANAは、HANAを前提にデータウェアハウスのオブジェクトとデータフローを整理した製品です。永続化、統合、仮想化、クエリ公開の役割を、より明確なオブジェクト構成で設計します。不要になった旧来オブジェクトを整理し、運用対象を標準化しやすいことが大きな違いです。

BW/4HANAでは、従来のモデルをそのまま実行することよりも、ADSOやCompositeProviderを中心にデータフローを再設計することが重要になります。既存システムの資産量が多い場合は、技術的な変換可否だけでなく、再設計に必要な工数も評価します。

02データモデルの違い

BW on HANAでは、従来型のInfoCube、DSO、InfoObject、マスターデータ、プロセスチェーンなどが混在しやすく、長年の拡張によってオブジェクトの役割が分かりにくくなっている場合があります。HANA上で高速に動作していても、設計上の重複や不要な中間層が残ることがあります。

BW/4HANAでは、ADSOを中心とした永続化が基本的な設計軸になります。ADSOは、データの取り込み、統合、変更履歴、レポート用の保存など、用途に応じて構成を選択できます。旧来の複数オブジェクトを一つのデータフローに整理できる場合があります。

InfoObjectは、項目の意味、マスターデータ、属性、階層などを統一的に管理するために使用します。すべての項目を機械的にInfoObject化するのではなく、再利用性、マスターデータ管理、分析要件を確認して採用します。既存のInfoObjectを移行する場合は、キー、属性、テキスト、時間依存性の扱いを個別に確認します。

詳しい項目設計は、SAP BW/4HANAのInfoObject設計で確認できます。移行前に、使用中のInfoObjectとデータフローの依存関係を一覧化しておくと、不要な定義を整理しやすくなります。

03ADSOと従来オブジェクトの比較

ADSOは、BW/4HANAでデータの保存と統合に使用する中心的なオブジェクトです。用途に応じて、入荷データの一時保持、統合済みデータの保存、変更履歴を持つデータの管理、クエリ向けの提供などを設計します。データのライフサイクルを一つのデータフローで追跡しやすい点が利点です。

BW on HANAの既存環境では、標準DSOからInfoCubeへロードし、さらに別のProviderへ集約するような多段構成が見られます。BW/4HANAへ移行するときは、各層の目的を確認し、ADSOとCompositeProviderの組み合わせに再構成できるかを判断します。

比較では、次の項目を確認します。

• データを受け取る層と、業務ルールを適用する層
• データを保持する期間と削除の単位
• キー項目と変更履歴の扱い
• データロード後に必要な有効化や集約処理
• クエリから直接参照するデータと中間データ
• 障害発生時に再実行する範囲

SAP BW/4HANA Advanced DataStore Objectの設計では、ADSOの役割分担とデータフローへの組み込み方を整理しています。移行対象ごとに、既存オブジェクトと移行後のADSOの対応表を作成するとレビューが進めやすくなります。

04CompositeProviderによる統合

CompositeProviderは、複数のデータソースを統合して、分析やクエリに提供するための仮想化レイヤーです。物理的にデータを再ロードせず、複数のADSOや他のProviderを結合またはユニオンして公開できるため、データフローの構造を簡素化できます。

BW on HANAで複数のInfoCubeを統合していた場合、同じ業務領域のADSOを整理し、CompositeProviderで共通の分析モデルを構成する方法を検討します。ただし、結合条件、カーディナリティ、ナビゲーション属性、フィルター条件を確認しないと、想定外のレコード増加やクエリ性能低下につながります。

CompositeProviderの設計では、次の観点を分けて評価します。

1. どのデータをユニオンするか
2. どの項目で結合するか
3. 参照データを物理保存するか仮想参照するか
4. クエリ利用者に公開する項目をどこで制限するか
5. データ更新のタイミングとクエリ実行の関係

CompositeProviderのモデル設計では、統合モデルの構成と確認ポイントを扱っています。移行プロジェクトでは、既存クエリの参照元を確認し、移行後のCompositeProviderに同じ意味の項目が公開されることを検証します。

05変換とデータフローの違い

BW on HANAでは、古いデータフローの中に、複数段階の変換、ルーチン、更新処理、ロード後処理が含まれていることがあります。BW/4HANAでは、変換をデータ取得からADSOへの格納、さらに分析用Providerへの提供まで、責任範囲ごとに整理します。

変換ロジックを移行するときは、単に定義をコピーするのではなく、入力項目、出力項目、参照データ、エラー処理、再実行条件を確認します。特に、開始ルーチンや終了ルーチンに含まれる業務ルールは、変換の前後で処理順序が変わると結果に影響します。

SAP BW/4HANAのTransformation設計では、変換、ルーチン、エラー処理をデータフローに配置する考え方を説明しています。リンク先へ進む際は、実際の移行対象について入力と出力のサンプルを用意し、件数と主要項目の値を比較できる状態にします。

移行検証では、ロード件数だけでなく、キーの重複、NULLや初期値、通貨・単位、時間特性、マスターデータ参照結果を比較します。日次ロードだけでなく、再処理、部分ロード、エラー訂正後の再実行も検証対象に含めます。

06新機能と運用上の効果

BW/4HANAの新しいモデルでは、データの保存、変換、統合、公開の責任を分離しやすくなります。これにより、影響範囲の把握、データフローの監視、障害時の再実行手順を標準化しやすくなります。

運用面では、オブジェクトの種類を整理できることが重要です。開発者は、データを保存するADSO、統合するCompositeProvider、変換するTransformationという役割に沿って設計し、運用担当者はロード、エラー、データ有効化、クエリ影響を確認します。

一方、BW/4HANAへの移行直後は、モデルの単純化と引き換えに、既存のカスタム処理を見直す作業が発生します。旧環境で使われているルーチン、特殊な抽出、手作業の再処理、独自の監視表を洗い出し、標準的なデータフローへ置き換えられるか評価します。

07移行可否を判断する手順

移行方針を決めるときは、次の順序で棚卸しを進めます。

1. 使用中のProvider、InfoObject、データソース、Transformationを一覧化する
2. 各オブジェクトの利用クエリ、ロード頻度、保持期間を確認する
3. 旧来オブジェクト、カスタムルーチン、外部連携を分類する
4. ADSO、CompositeProvider、Transformationへの対応関係を設計する
5. データ件数、主要項目、クエリ結果、ロード時間を比較する
6. 切り替え手順、戻し方、運用監視を文書化する

移行対象を一括で判断するのではなく、業務領域やデータフロー単位で優先順位を付けます。依存関係が少なく、業務影響を検証しやすい領域から開始すると、設計標準を確立しやすくなります。

既存環境の変換を計画する場合は、SAP BW/4HANAの移行アプローチも参照してください。移行方式を決める前に、技術的な変換可否、再設計の必要性、停止時間、並行稼働期間、運用チームの習熟度を合わせて評価します。

08どちらを選ぶべきか

既存のSAP BW資産を短期間でHANAへ適応し、現在のデータフローを大きく変えずに運用したい場合は、BW on HANAの構成が適することがあります。既存オブジェクトの利用範囲が明確で、移行後も現在の運用を維持することが優先されるケースです。

新しいデータウェアハウスを構築する場合や、長期的にデータモデルを標準化したい場合は、BW/4HANAを中心に設計します。ADSOとCompositeProviderを基本単位にし、変換と公開の責任を分けることで、将来の拡張と障害対応を整理しやすくなります。

既存環境からの移行では、製品名だけで判断せず、次の条件を比較します。

• 現行オブジェクトをどこまで再利用するか
• カスタムロジックを標準モデルへ置き換えられるか
• 連携元と連携先に必要な変更があるか
• クエリと利用者への影響をどの範囲で許容できるか
• テスト、切り替え、運用引き継ぎに割ける期間

この比較を行うと、BW on HANAを維持する領域と、BW/4HANAへ再設計する領域を分けた段階的な計画を作成できます。

09まとめ

BW on HANAは、既存SAP BW資産をHANA上で活用する構成として評価し、BW/4HANAは、ADSO、CompositeProvider、Transformationを軸にデータウェアハウスを再整理する基盤として評価します。両者の違いはデータベースだけではなく、モデル、データフロー、運用責任の設計にあります。

移行を成功させるには、オブジェクト対応表、変換ロジックの棚卸し、クエリ結果の比較、ロードと再処理の検証を一体で進めます。最終的には、現在の資産を守る範囲と、将来の保守性のために再設計する範囲を明確にすることが判断の中心になります。