SAP プロジェクトの難関「データ移行」はなぜ難しいのか

INDEX LINK

はじめに

SAP ERP導入プロジェクトの山場といえば、移行フェーズです。移行フェーズは、入念に準備したとしてもトラブルが起こりやすいため、どのプロジェクトでも専任のチームを配置する傾向にあります。では、なぜデータ移行はここまで難航するのでしょうか。今回は、SAP ERPプロジェクトにおけるデータ移行の難しさについて紹介します。

1．サイロ化のツケが巡ってくる

データ移行が難航する理由のひとつとして、データのサイロ化が挙げられます。SAP ERPは、複数の業務分野に対して横断的に適用することが多いため、複数の部門・部署からデータを集約しなくてはなりません。このとき、部門・部署単位でサイロ化が起こっていると、まずはデータ仕様の一元化から着手しなくてはなりません。

例えば、販売部門で顧客データを「顧客ID」単位で管理しているとしましょう。この販売部門では、顧客IDと伝票番号の紐づけで販売実績を抽出しています。一方、財務部門では領収書に顧客IDが記載されず、独自に採番した「顧客ナンバー」で支払い情報を管理していたとします。この時点で販売部門と財務部門の間では、「どの顧客がいつ何を購入し、どれだけ支払ったか」の紐づけが不可能になってしまいます。

こうした状況が長年にわたって積み上げられた結果、各部門でデータのサイロ化が起こり、まったく紐づけのない大量のデータが蓄積されてしまうわけです。データ移行では、こうしたデータを探索・整理する作業が含まれます。この作業は、とても地道で根気のいるものです。

重複チェック用のプログラムを作ろうにも、チェック時にキーとなる項目が存在しないため、共通項目の定義とデータの紐づけから始めなくてはいけません。つまり、一旦対象データをローカルPCにダウンロードし、共通項目を挿入して2つのデータを紐づけ、重複がないかをチェックしていくという極めて地味な作業を延々と続ける必要があるのです。

「これは移行チームの仕事なのか？」と思う方もいらっしゃるかもしれませんが、本番移行直前になってこのようなデータが見つかることは珍しくないと感じています。部門・部署の担当者も全てのデータを網羅的に把握しているわけではないため、考慮漏れや見落としは必ず発生するものです。

２．新旧のシステムに精通した人材がいない

データ移行が難しくなる理由のふたつ目は、人材不足です。人材不足といっても単に人手が足りないという意味ではありません。

データ移行では、レガシーシステムの仕様を完全に把握している人材が不足しがちです。前述のサイロ化にも言えることですが、「レガシーシステムがどういうデータ構造であり、その理由は何なのか」まで知る人物が不在だったりします。

データ移行では、本当に削除して良い項目なのか、何か意味があって設けられたものなのかなど、データの「文脈」を理解している必要があります。特にアドオンで新設した項目やテーブルについては、レガシーシステムの有識者が入念にチェックしなくてはなりません。こうした知見を持つ人材は、外注で賄うことができず、クライアント企業の中から探し出す必要があります。

もし見つからない場合は、コンサルタントや開発者が総出でデータを洗い出し、新旧のシステム間でデータのマッピングを進めていくことになるでしょう。これには、膨大な工数が必要で、時間が限られている移行フェーズが破綻する遠因にもなります。

３．リハーサルが形骸化している

データ移行の難易度があがる理由の3つ目は、リハーサルの形骸化です。SAP ERPのプロジェクトでは、本番のデータ移行前に何度もリハーサルを行いますよね。このリハーサルの精度はプロジェクトによってまちまちです。

完全にデータの精査やマッピングが終わっており、あとは移行時のパフォーマンスだけをチェックすればよいというレベルもあれば、「とりあえずダミーデータを流して全体の流れを理解しておこう」というレベルもあります。

前者の場合は、本番移行でも何ら問題なく作業が進むでしょう。しかし後者の場合は、高確率で本番移行時にトラブルが発生するかもしれません。ダミーデータのみでのリハーサルは、移行ツールの動作だけを確認しているようなもので、あまり意味がないからです。

データ移行で起こるトラブルの大半は、データの不整合や不正値の存在からくるエラーであり、その修正作業です。つまり、本番用のデータに近いものでなければリハーサルの意味がありません。

しかし、プロジェクトの都合で移行リハーサル時にデータの整備が間に合わず、やむを得ずダミーデータだけを使う場合もあります。どのプロジェクトも余裕があるわけではないので致し方ありませんが、移行リハーサルは「実際に使用されているデータ」を用意し、「本番と同等の規模」を意識した内容にすべきです。

４．最終的には人海戦術になることも

データ移行はカットオーバー直前の一大イベントであり、プロジェクトの総力を挙げて対応することも珍しくありません。普段は、開発チーム、アプリチーム、権限チームなどに分散されている人材が、移行チームとして再編成されることもあります。こうなると、単純な「頭数」は足りていたとしても、認識や知見の差が生じて思わぬミスを誘発することがあるのです。

例えば、開発チームのメンバーは、データ移行専用の移行ツールが存在することを知っており、ツールを使ってデータの整備を行っていたとしましょう。しかしアプリチームから召集されたメンバーは、このツールの存在を知らず、手作業でデータを整備しています。移行ツールには、レガシーシステムからダウンロードしたデータを編集する機能があるため、手作業でダウンロード・編集したデータとは、若干内容が異なります。

つまり、ツールで整備したデータと手作業で対応したデータには差異が発生しており、データ移行時に不整合を起こしてしまう可能性があるのです。

かなり初歩的なコミュニケーションミスなのですが、本番移行直前で皆余裕がなく、なおかつ急造の移行チームとなれば仕方ないのかもしれません。SAP ERPプロジェクトの難しいところは、「人海戦術が必ずしも吉にならない」という点です。扱うデータが非常に広範かつ複雑であるため、認識の異なる人材が集まったところで作業が効率化されるわけではないのです。

頭数だけに囚われて無理に移行チームを編成したもののミスを連発し、さらにミスの原因調査に工数を取られて本番稼働に間に合わない…というのでは、本末転倒になってしまいます。もし移行チームを編成する場合は、間に合わせの急造チームではなく、専任のチームを目指したいところです。