SAPデータ移行が失敗する理由と、その対処法

SAPのデータ移行が失敗する原因は、ほかのどれよりも、ひとつに集約されます。計画が、抽出結果が示すデータの姿ではなく、業務側が思い描くデータの姿を前提に作られていることです。このガイドは、S/4HANAプログラムに携わるプログラムディレクター、データリード、財務リーダーに向けたものです。移行が壊れる理由、カットオーバー失敗の大半に共通する5つのミス、そのまま使えるモックロード計画、そして2026年にどのSAPツールがどの作業に向くかを扱います。今週ひとつだけやるなら、顧客、仕入先、品目のマスタを全件抽出し、レコード数を自分で数えてください。

ある製造業の会社は、SAP導入に18か月と450万ドルを費やしました。稼働日がやってきました。誰もが緊張しつつも、高揚していました。そして、データ移行が失敗しました。

何ひとつ、まともに動きませんでした。顧客データが欠けていました。在庫の数字は間違っていました。経理は帳簿を締められませんでした。CEOは激怒しました。

原因はソフトウェアではなく、導入チームでもありませんでした。失敗は、業務側が思い描いていたデータの姿と、実際のデータの姿との、ギャップにありました。

SAPのデータモデルは、フラットなインポートではありません。レコード同士が依存し合っています。品目マスタには、一般データ（MARA）、プラントデータ（MARC）、評価データ（MBEW）があり、MRPエリアを使う場合は、MRPエリアデータ（MDMA）も加わります。ヘッダーだけをロードして、従属するビューをロードしなければ、その品目は存在していても、トランザクションでは使えません。

S/4HANAには、独自のルールがあります。顧客と仕入先は、ビジネスパートナです。レガシーの顧客は、顧客ロールを持つビジネスパートナになり、仕入先は、仕入先ロールを持つビジネスパートナになります。与信限度額、銀行情報、税番号は、そのビジネスパートナに紐づきます。レガシーシステムが欠落を許容していたレコードは、ここでは検証に失敗します。

さらに、量の問題があります。ほとんどの企業は、実際に持っているデータの量に驚きます。あるクライアントは、品目マスタのレコードが約50,000件だと考えていました。すべてのバリアントとプラント固有のレコードを数えると、その数は500,000件に近いものでした。最初の数字に合わせて立てた計画は、2番目の数字には耐えられません。

業務側の見積もり全件の抽出

対象の品目マスタのレコード数500,000+450,000 · +900%

業務側の見積もり50,000

全件の抽出500,000

• すべてのバリアントとプラント固有のレコードを数えた
• 見積もりに合わせた計画は、この数字には耐えられない

それは、データ移行の問題ではありませんでした。データ移行の問題になった、スコープの問題でした。

プロジェクトの開始時のデータ品質アセスメントは、たいていデータの記述であって、検査ではありません。財務責任者は、仕入先マスタはきちんと管理されていると言います。倉庫マネージャーは、品目はおおむねきれいだと言います。それらは、印象にすぎません。

最初の抽出が、真実を教えてくれます。何年も前に整理されるはずだったのに、されなかった仕入先。ずっと前に生産終了になったのに、無効化されていない品目。国コードが統一されていない顧客住所。電子送金で支払う仕入先に欠けている銀行情報。

これらはどれも、技術的な修正ではなく、業務上の判断を必要とします。重複した2つの仕入先のどちらが正しいかは、買掛管理の部門にしか言えません。どの廃止済みの品目をブロックし、どれを移行せずに残すかは、購買部門にしか言えません。こうした判断には時間がかかり、データを知っている人が必要です。アセスメントが実際の抽出に基づいていなければ、計画は、データに触れた途端に崩れる前提の上に立つことになります。実際の件数がわかったら、私の無料のデータ移行見積もりツールが、工数の見積もりに役立ちます。

1. 移行を、後から行う技術的な作業として扱う

移行は、SAP Activateのすべてのフェーズに属します。Exploreでは、スコープ、つまりオブジェクト、移行元システム、量、品質を定めます。Realizeでは、テンプレートを作り、モックロードを実行します。Deployでは、最終リハーサルとカットオーバーのロードを行います。Runでは、本番データでの最初の期末決算を照合します。

Deployで移行作業を始めるプロジェクトは、数か月遅れで始めています。Realizeで解決されているべき品質の問題が、カットオーバーの数週間前の最初のモックで、表面化します。移行が全体の計画のどこに位置するかは、私のSAPスケジュール計画ガイドで示しています。

2. 業務側の関与が少なすぎる

移行は、実行の面では技術的で、意思決定の面では業務の活動です。重複した仕入先のリストを、ITは作れません。どの顧客アカウントを有効なものとして移し、どれを履歴として残すかは、財務の判断です。廃止済みの品目の整理には、購買、倉庫、製品管理が必要です。

移行を技術者だけで担当させ、業務側を最後の承認者として扱うプログラムは、ロードはできるデータを作ります。ただし、事業の観点では、間違ったデータです。

3. モックロードの計画が少なすぎる

うまく運営されたSAPのデータ移行には、カットオーバーの前に最低3回のモックロードが必要で、複雑なプログラムではさらに必要です。1回か2回で計画するプロジェクトは、きれいなデータときれいなマッピングを前提に計画しています。そうしたシナリオは、まれです。サイクルが増えるのは、移行が行き詰まっている印ではありません。適切に計画されている印です。

4. 試行ロードを照合しない

ロードジョブがエラーなく終わることは、検証ではありません。検証とは、ロードされたものを、期待されたものと比べることです。レコード数、財務の合計、未決済明細の残高です。そのうえで、プロセスのスモークテストによって、データがトランザクションで使えることを確認します。

照合されない試行ロードにも、時間はかかります。それが生んだギャップは、次のモックにもそのまま残り、しかも原因までたどるのが難しくなっています。次のロードを始める前に、すべてのロードを照合してください。

5. リハーサルと違うカットオーバーのロード

カットオーバーの移行は、最後のモックをそのまま繰り返すものであるべきです。同じ抽出スクリプト、変換ロジック、ロードの順序、チェック、タイミングです。カットオーバーでの変更は、すべて、プログラムで最もプレッシャーの高い時点での、未テストのリスクです。

最もテストされていない部分は、たいてい差分です。最後のモックとカットオーバーの間にも、業務は仕入先を追加し、注文を変更し、在庫を動かし続けます。データフリーズの日付を定め、最終モックの一部として、差分ロードをリハーサルしてください。

このサイクルの構成を、出発点として使ってください。各サイクルには目的と終了基準があり、照合に署名が入るまでは完了ではありません。

サイクル	目的	終了基準	責任者
モック1	構造：すべてのオブジェクトが依存関係の順にロードされる	オブジェクトごとに、マッピングのギャップと形式のエラーが記録されている	データ移行リード
モック2	品質：マッピングの修正をテストし、データの問題を明らかにする	オブジェクトごとにエラー率が下がっている。クレンジングの判断が記録されている	データスチュワード
モック3	業務ルール：例外とエッジケース	各ドメインで、照合済みのサンプルをスチュワードが受け入れている	データスチュワード
モック4	本番規模でのボリュームとタイミング	フルロードが、カットオーバーの時間枠内に完了する	カットオーバーマネージャー
最終リハーサル	差分とフリーズを含む、カットオーバーのリハーサル	件数と財務の合計が照合され、署名されている	財務コントローラーとデータリード

この計画の周りで、差を生むものが5つあります。

1. Prepareでの全件抽出。 サンプルではなく、すべてです。完全性、正確性、一貫性、重複をプロファイリングし、その結果からクレンジングとスケジュールの規模を見積もります。
2. オブジェクトごとのマッピング。 各オブジェクト（ビジネスパートナ、品目、未完了の購買・販売オーダー、未決済明細、在庫、固定資産）について、移行元から移行先への項目、変換ルール、検証チェック、例外ルールを文書化します。
3. 名前の挙がったデータスチュワード。 顧客と仕入先の財務データは、財務が担います。品目マスタは、購買が担います。在庫は、倉庫が担います。各スチュワードは、サイクルのたびに、自分のドメインを承認します。
4. あらかじめ定義された照合。 どの件数と合計がロードの正しさを証明するかを、最初のモックの前に合意しておきます。そうすれば、カットオーバーで誰もそれをめぐって争いません。
5. 文書化されたカットオーバーの手順。 フリーズ、抽出、変換、ロード、検証、業務の承認、go/no-go。最終リハーサルと同じ手順です。

S/4HANAの新規導入では、SAP S/4HANA Migration Cockpitが、初期ロードのためにSAPが推奨するツールです。S/4HANA 2020以降は、Fioriアプリ「Migrate Your Data」として動きます。トランザクションLTMCは非推奨で、既存のLTMCプロジェクトは、表示のみ可能です。このアプリには、2つのアプローチがあります。ステージングテーブル（ファイルや独自のツールで埋めます）を使ってデータを移行する方法と、SAPの移行元システムから直接データを移行する方法です。オンプレミスとプライベートクラウドのチームは、トランザクションLTMOM、つまり移行オブジェクトモデラーを使って、標準オブジェクトを調整したり、独自のオブジェクトを作ったりします。このコックピットは、初期ロードのためのもので、定期的なインターフェースや一括変更のためのものではありません。

SAP Data Servicesは、SAPのETLプラットフォームです。大量のデータ、複雑な変換ロジック、複数の移行元システムがある場合や、プロジェクトより長く使える、再利用可能なデータ品質のフレームワークがほしい場合に使います。

サードパーティのETLツール、たとえばInformatica、Talend、Microsoft SSISは、組織がすでにそれらを所有し、スキルも持っている場合に、意味があります。

SAP Datasphereは、現在はSAP Business Data Cloudの一部で、移行ツールではありません。その役割は、本稼働後のアナリティクス層です。履歴をレガシーシステムに残しながら、その履歴についてもレポートを出す必要がある場合に、重要になります。

標準的な導入のほとんどでは、Migration Cockpitがオブジェクトの大半をカバーします。大量のデータ、大幅にカスタマイズされたレガシーシステム、特殊な移行元の構造がある場合は、通常、Data ServicesかETLツールを併用する必要があります。ECCからのコンバージョンは、別の取り組みで、私のECCからS/4HANAへの移行ガイドで扱っています。

SAPのデータ移行とは何ですか？

SAPのデータ移行とは、導入またはコンバージョンの一環として、レガシーシステムからデータを抽出し、SAPの構造とルールに合うように変換し、SAPにロードすることです。典型的なオブジェクトは、ビジネスパートナ（顧客と仕入先）、プラントデータを持つ品目、未完了の購買・販売オーダー、在庫残高、財務の未決済明細、固定資産です。難しいのは、SAPが、レガシーシステムでは多くの場合なかった依存関係と検証ルールを強制するからです。

SAPのデータ移行には、どんな主なアプローチがありますか？

新規導入（グリーンフィールド）は、選んだマスタデータと未決済明細を、新しいS/4HANAシステムにロードし、履歴をレガシーシステムかアーカイブに残します。システムコンバージョン（ブラウンフィールド）は、既存のECCシステムとその履歴を、その場で変換します。選択的データ移行は、その中間に位置し、選んだ会社コード、オブジェクト、期間の断面を移します。適切な選択は、データ品質、履歴の要件、古いプロセスをどれだけ残したいかによって決まります。

SAP Migration Cockpitとは何で、どんなときに使うべきですか？

SAP S/4HANA Migration Cockpitは、S/4HANAへの初期データロードのためにSAPが推奨するツールで、すべてのエディションで使えます。S/4HANA 2020以降は、Fioriアプリ「Migrate Your Data」として動き、トランザクションLTMCは非推奨です。事前定義された移行オブジェクトを備え、転記の前にデータを検証し、エラーを項目レベルで報告します。通常の量の標準オブジェクトに使います。データ量、変換ロジック、移行元の構造がテンプレートの扱える範囲を超える場合は、SAP Data Servicesか、ほかのETLツールを追加します。

SAPのデータ移行では、モックロードを何回計画すべきですか？

最低3回で、最後の1回は、カットオーバーの完全なリハーサルにします。複雑なプログラムでは、さらに必要です。典型的な計画では、1回目で、構造上のマッピングのギャップを見つけます。2回目で、修正をテストし、データ品質の問題を明らかにします。3回目で、業務ルールとエッジケースを処理します。最終回は、カットオーバーをそのまま繰り返し、その照合結果が、本稼働日の基準になります。

顧客と仕入先は、SAP S/4HANAにどう移行しますか？

ビジネスパートナとして移行します。S/4HANAでは、顧客と仕入先のマスタデータは、ビジネスパートナを通じて保守され、顧客ロールと仕入先ロールが割り当てられます。新規導入では、Migration Cockpitが、ビジネスパートナのオブジェクトを通じてそれらをロードします。ECCからのコンバージョンでは、コンバージョン自体の前に、顧客・仕入先統合を設定し、実行しておく必要があります。

SAPのデータ移行は、なぜカットオーバーで失敗するのですか？

カットオーバーの失敗の大半は、5つのパターンによります。モックロードが少なすぎる。カットオーバーの手順が、通しでテストされたことがない。最後のモックの後に、レガシー側で変更があり、差分ロードが未テストである。照合のギャップが、未解決のまま残る。業務の承認が、抜き取りのチェックに基づいている。「最初の1,000件は問題なさそうだった」は、検証ではありません。本稼働には、照合された件数と合計が必要です。