SAP BW/4HANAコンバージョンの進め方：評価から移行後検証までの実務手順

SAP BWからSAP BW/4HANAへ移行するプロジェクトでは、システムを新しく構築する作業だけでなく、既存のデータフロー、抽出元、権限、運用ジョブ、レポートを一体で確認する必要があります。特に、移行方式を先に決めてしまうと、後から変換できないオブジェクトや業務停止時間の制約が判明し、計画を作り直すことになります。

この記事では、移行方式の選定から移行後の検証までを、実際のプロジェクトで使いやすい順序に整理します。対象システムの構成や利用中のオブジェクトを棚卸しし、変換ツールの結果だけに依存せず、業務データと運用手順まで確認することが重要です。

01コンバージョン全体の進め方

SAP BW/4HANAへの移行は、次の段階に分けると管理しやすくなります。

1. 現行環境と対象範囲を棚卸しする
2. 移行方式と停止時間の条件を決める
3. 変換対象と再設計対象を分類する
4. 開発環境で事前変換と機能検証を行う
5. 品質環境でデータ量、性能、権限を検証する
6. 本番カットオーバーと移行後監視を実施する

移行対象には、InfoObject、データストアオブジェクト、インフォキューブ、マルチプロバイダ、CompositeProvider、変換、DTP、プロセスチェーン、クエリ、分析権限などが含まれます。データを保持するオブジェクトだけでなく、参照関係と実行順序も一覧化してください。

現行モデルの確認には、SAP BW/4HANAの概要を参照し、用語と主要な構成要素をチーム内でそろえておくと、設計レビューの認識差を抑えられます。

02移行方式を選ぶ判断基準

移行方式は、既存システムを同じ環境で変換する方法、別環境へ移行する方法、必要なデータフローだけを再設計する方法に大きく分けて検討します。プロジェクトでは、一般にインプレース変換、リモート変換、シェル変換などの候補を比較します。

インプレース変換

同じシステムを基盤として変換する方式です。既存の接続、データ、運用設定を活用しやすい一方、停止時間、未対応オブジェクト、アドオン、カスタム開発の影響を詳細に確認する必要があります。変換前のバックアップと復旧手順を確立し、変換作業そのものをリハーサルしてください。

リモート変換

別のSAP BW/4HANA環境を用意し、対象データやオブジェクトを移行する方式です。新旧環境を並行稼働させやすく、段階的な検証に向いています。ただし、接続設定、データ転送量、初期ロード時間、差分ロードの設計が必要です。

シェル変換・再設計

メタデータや必要な構造だけを移し、不要な履歴や旧式オブジェクトを整理する方式です。長期間使われていないデータフローを整理できる反面、業務部門との対象範囲合意とデータ保持要件の確認が欠かせません。

判断では、次の項目を表にして比較します。

03現行環境の棚卸し

最初に、開発・品質・本番の各環境について、システム構成、ソフトウェアレベル、データ量、日次処理時間、利用ユーザー数を記録します。棚卸しの基準日は固定し、後から追加されたオブジェクトを別途識別できるようにします。

オブジェクト一覧には、技術名、説明、担当業務、最終利用日、データ保持期間、依存先、移行判定、検証担当者を含めます。使用実績のないオブジェクトを移行対象に残すと、テスト範囲とカットオーバー作業が不必要に広がります。

InfoObjectとマスターデータ

InfoObjectは、キー、属性、テキスト、階層、マスターデータのロード方式を確認します。既存のInfoObjectをそのまま移行するか、モデル整理の一環で統合するかを決めます。属性変更やテキスト更新のタイミングは、クエリの表示結果と権限評価にも影響します。

詳細な確認項目は、SAP BW/4HANAのInfoObjectに整理されています。特に、使用箇所とロード順序を一覧にしてから変換を開始すると、後工程の調査を短縮できます。

データストアとプロバイダー

既存のデータストアオブジェクト、インフォキューブ、マルチプロバイダー、CompositeProviderの関係を図にします。データを保持する層、統合する層、クエリへ公開する層を分けると、変換対象と再設計対象を判断しやすくなります。

データストアオブジェクトの構造、キー、変更ログ、アクティブ化、データ削除の運用は、移行後のロード結果に直結します。SAP BW/4HANA Advanced DataStore Objectを参照し、既存オブジェクトとの役割を対応付けてください。

04移行コックピットを使った事前分析

SAP BW/4HANAの移行コックピットは、既存環境のオブジェクトを分析し、変換可能性や追加作業を確認するために使用します。最初の出力を最終判定にせず、技術担当者と業務担当者が一覧をレビューする工程を設けます。

事前分析では、次の分類を作成します。

• 自動変換の対象
• 変換後に設定変更が必要な対象
• 手動で再設計する対象
• 保持するが移行しない対象
• 廃止候補

移行コックピットの結果には、オブジェクトの依存関係や周辺設定がすべて表現されるとは限りません。クエリ、プロセスチェーン、バリアント、接続、権限、外部スケジューラーの定義を別の一覧で照合します。

変換対象のプロバイダーについては、SAP BW/4HANA CompositeProviderで、結合、ユニオン、フィールド対応、参照元の扱いを確認できます。設計変更が必要なものは、変換作業と同じチケットで管理せず、再設計として工数と受入条件を分けてください。

05変換と再設計の実施

開発環境では、本番と同じ構成を完全に再現することよりも、主要なデータフローと代表的な業務シナリオを早く通すことを優先します。最初の反復では、マスターデータ、トランザクションデータ、エラー処理、デルタ処理を含む小さな縦方向の流れを完成させます。

変換の単位を決める

変換単位は、単一オブジェクトではなく、ロードの始点からクエリの終点までのデータフローで切り出します。InfoObject、データストア、変換、DTP、CompositeProvider、クエリを一つの検証単位にすると、原因の切り分けが容易になります。

変換ロジックを確認するときは、項目マッピング、ルーチン、単位変換、通貨換算、時間特性、エラー処理を比較します。特に、旧環境で暗黙に動作していた変換ロジックは、移行後に同じ結果になることをデータサンプルで確認してください。

SAP BW/4HANAの変換では、変換ルールとデータフローの確認点を扱っています。変換後のオブジェクト名を変更する場合は、依存するクエリや運用手順の更新を同じリリース計画に含めます。

再設計の基準

次の条件に該当するものは、単純変換ではなく再設計として扱います。

• 複数の旧式プロバイダーが同じ業務データを重複保持している
• 利用されていない履歴やロード処理が残っている
• 変換ロジックが複数箇所に分散している
• 連携元の変更により、抽出方式を見直す必要がある
• クエリの利用実態とモデル構造が一致していない

再設計では、現行結果を完全に再現することだけを目標にせず、業務上必要な粒度、保持期間、更新頻度、利用者を定義します。設計変更を行う場合は、旧新の件数と金額などの業務キーを比較できるようにします。

06データ移行と検証

データ検証は、件数だけでなく、集計値、キーの一意性、NULL、重複、期間境界、デルタの連続性を確認します。検証対象は、ロード直後のデータ、アクティブ化後のデータ、プロバイダー経由の表示結果、クエリ結果の四層に分けると原因を特定しやすくなります。

最低限、次の照合を実施します。

テストデータには、通常値だけでなく、境界日、取消、再処理、遅延到着、マスターデータ未登録のケースを含めます。移行元と移行先の比較結果は、抽出条件、実行日時、対象データ範囲を記録したうえで保存します。

07カットオーバー計画

カットオーバー計画には、作業担当者、開始条件、停止対象、最終ロード、検証、業務承認、利用者解放、切り戻し判断を時系列で記載します。作業時間だけでなく、検証で不一致が出た場合の調査時間も確保してください。

代表的な流れは次のとおりです。

1. 変更凍結を開始する
2. 旧環境の未完了ロードとジョブを確認する
3. 最終データを抽出・転送する
4. 移行先でロードと後処理を実行する
5. 件数、集計値、クエリ、権限を検証する
6. 業務責任者が受入判定を行う
7. 接続先とスケジュールを切り替える
8. 旧環境を参照用に保全し、監視を強化する

切り戻し条件は、単に「問題があれば戻す」とせず、許容できないデータ不一致、重要クエリの実行不能、ロード未完了、権限欠落など、観測可能な基準で定義します。切り戻しを行う場合のデータ差分と業務連絡も、事前に手順化します。

08移行後の運用確認

稼働開始後は、最初のロードサイクル、日次処理、月次処理、例外処理の順に確認します。プロセスチェーンの実行時間、失敗ステップ、データ量、クエリ応答時間、ユーザーからの問い合わせを記録し、旧環境の実績と比較します。

移行後に見つかった問題は、モデル、データ、権限、スケジュール、外部接続の分類で管理します。再処理の前に、どの層で不一致が発生したかを確定すると、不要な再ロードを避けられます。

09失敗しやすいポイント

棚卸しが技術オブジェクトだけになる

テーブルやプロバイダーの一覧だけでは、業務上重要なクエリ、手動処理、外部ジョブ、利用者固有の作業を見落とします。業務担当者へのヒアリングと、実行ログや利用状況の確認を組み合わせます。

自動変換の結果をそのまま受け入れる

自動変換は作業を効率化しますが、業務要件やデータ品質を判断するものではありません。変換後の構造、ロード結果、権限、性能を受入条件に沿って確認します。

データ検証を本番直前に始める

検証ロジックを早い段階で作成し、開発環境の小規模データで繰り返し実行します。検証SQLや集計表の作成が本番直前になると、不一致の原因調査に必要な時間を確保できません。

運用手順を後回しにする

移行後の担当者が、ジョブ再実行、エラー確認、データ再ロード、権限申請、障害連絡を実行できる状態を稼働条件に含めます。運用担当者によるリハーサルをカットオーバー前に実施してください。

10実務で使える成果物一覧

移行プロジェクトでは、次の成果物を一つの管理場所で更新します。

• 現行環境の構成図とオブジェクト一覧
• 移行方式の比較表と決定記録
• 変換・再設計・廃止の判定表
• データフローと依存関係の一覧
• テストケースと期待結果
• 件数・集計値・デルタの照合結果
• カットオーバー手順と切り戻し手順
• 権限、接続、ジョブ、監視の確認表
• 移行後の課題一覧と担当者

この構成にすると、ツールで変換できたかどうかだけでなく、業務データを継続的に提供できるかを基準に進捗を判断できます。