SAPデータ移行とは!? 移行データの種類とデータ移行の流れを解説
基幹システムのデータ移行(Data Migration)とは
SAP導入プロジェクトは、要件定義 → 設計・開発 → テスト → トレーニング → 移行 → 本番稼働 の流れで進みます。
このうち移行(Data Migration)は、基幹システムを稼働させるために必要なデータを投入する作業を指します。
スマホを機種変更したときに電話帳のデータを移行するのと本質的には変わりありません。
個人が使うスマホと比べて、基幹システムはシステムの規模が桁違いに大きいため、導入プロジェクトの中でも相当大きな工数を占めます。
投入するデータ全体の依存関係を把握し、各データごとの状況を見渡す必要があるため、データ移行専任のチーム・担当者を設置する必要があります。
データ移行は本番稼働の直前に行う作業であるため、遅延した場合に顧客業務に与えるインパクトが大きく、導入のタスクの中でも特に神経を使う作業と言えます。
例えば、勘定科目の残高を正しく移行できなかった場合、新システム(SAP)で出力する財務諸表は不正なデータということになり、最悪決算発表を延期する可能性もあるため、ステークホルダーへ多大な迷惑をかける場合もあります。
なお、SAPのデータ移行方法は下記の3種類がありますが、本記事の解説では New implementationを前提に進めます。
また本記事では、すべてのモジュール(会計/販売/購買/生産など)を一度に導入するパターンを前提に話を進めます。
①New Implementation(GreenField)
②System conversion(BrownField)
③Selective data transition
移行データの種類
データ移行は限られたシステム停止期間で完了しなければならないため、なんでもかんでも移行するわけにはいきません。
データの種類ごとに優先度をつける必要があります。
この章では、カスタマイズ、マスタ、バランス、トランザクションという4種類のデータについて解説します。
これらのデータの移行の優先度は、カスタマイズデータ > マスタデータ > バランスデータ > トランザクションデータとなります。
①カスタマイズデータ(コンフィグデータ)
カスタマイズデータ(コンフィグデータ)とは、マスタデータやトランザクションデータの動きを定義する設定データ(会社コード、購買組織など)を指します。
SAPで言うと、トランザクションコード:SPROで登録するものと考えて下さい。
マスタデータに含めて考える人もいますが、マスタデータがエンドユーザーが登録するのに対し、カスタマイズデータはシステム担当が登録するという違いがあります。
カスタマイズデータはデータ投入というより環境設定の感覚に近いため、移行データとみなさない人もいます。
いずれにせよ、本番稼働するために必要なデータであることに間違いありません。
②マスタデータ
マスタデータとは、業務を遂行する際の基礎情報となるデータを指します。
SAPシステムでは、品目マスタ、ビジネスパートナーマスタ、勘定科目などがこれに該当します。
マスタデータもバランスデータやトランザクションデータの移行に必要となるため、カスタマイズデータの次に移行します。
裏返すと、バランスデータやトランザクションデータに含まれないデータ(例えば廃盤になった商品)は移行対象から外しておく必要があります。
③バランスデータ
バランスデータとは、本番稼働時点でモノがいくつ、カネがいくらあるのかを表すデータ(GL勘定残/在庫残/債権債務残など)を指します。
マスタデータ、カスタマイズデータが「動かない」データに対して、バランスデータ、トランザクションデータは「動く」データです。
このため、バランスデータとトランザクションデータを移行するためには、移行元のシステムを停止しなければなりません。
バランスデータをトランザクションデータに含めて考える人もいますが、受発注残などと比べて移行の優先度が高い(基本的に移行元と完全一致しなければならない)ため、それぞれ分けて考えたほうが望ましいです。
在庫残がシステムに入っていないと、例えば本番稼働した時に商品を出荷できなかったり、債権残が入っていないと入金消込できないなどの問題が発生します。
④トランザクションデータ
トランザクションデータとは、いわゆる「伝票」のデータを指します。
SAPシステムでは、発注残、受注残などがこれに該当します。
トランザクションデータは必ずしも移行する必要はなく、可能であれば移行しないことをオススメします。
その理由は下記の通りとなります。
①実運用と同じ粒度でデータを登録しなければならない
バランスデータがマスタデータおよび転記日付、金額など限られた項目しか入力しなくて良いのに対して、トランザクションデータは実運用の登録と同じように伝票で使用される全ての項目に値を入力しなければなりません。
場合によっては受注であれば在庫引当情報も入力しなければならず、バランスデータと比べて入力負荷が高いと言えます。
②現行システムを並行稼働させれば、必ずしも移行する必要がない
SAPの本番稼働後もしばらくの間現行システムを並行稼動させておけば、必ずしもトランザクションデータを移行する必要はありません。
例えば、本番稼働の10日前に受注し、本番稼働の5日後に出荷しなければならない受注があるとします。
このような受注は現行システムで出荷日をトレースしておき、出荷日が到来したら、SAPに受注→出荷と入力すれば業務が止まることはありません。これを後追い入力と言います。
データ移行の流れ
本番移行するためには、プロジェクトの進め方同様、適切なプロセスを経てデータ移行を実施する必要があります。
それでは、データ移行の流れに沿って、1つずつのプロセスを見ていきましょう。
①ビジネスプロセスの理解
要件定義を進める中で、SAPのどのデータを使うのか、現行システムにはどんなシステムやデータがあるのか把握します。
顧客の業務フローで使われるマスタデータやトランザクションデータを移行対象として洗い出します。
そして、それらのデータがビジネス上どう使われるのか、どのような依存関係になっているのかを把握しておきます。
②データマッピング
現行システムの項目とSAPの項目を突き合わせてマッピングします。
顧客が業務を遂行するために必要な項目が網羅されているかを吟味します。
この過程で、顧客にとって無いと困るような項目があれば、必要に応じてSAPのマスタデータやトランザクションデータに項目を追加します。
③データクレンジング
長年システムを運用していると、徐々にデータが汚れていくため、新システムへの移行を契機に現行システムから移行するデータをクレンジングすることで、データをキレイに整えます。
・テキスト項目の全角半角、大文字小文字の違いを統一する
・特殊文字(①、㈱など)を変換する
・不要データを削除する(物理削除あるいは論理削除)
・重複しているマスタを削除する(人によってはこの作業を名寄せと呼びます)
・コード体系を変換する
例えば、現行システムの商品コードの桁数は50桁で、SAPの品目コード(MATNR)の桁数が40桁とします。
この場合、現行システムで40桁以上のコードを40桁以下に変換しなければなりません。
また、現行システムでは商品コードを、商品区分2桁、顧客区分3桁、連番5桁としていたのを、
SAPでは品目タイプXXX, 品目階層YYY, 連番ZZZZZとするなどの変換を行います。
④試験投入
LTMC(S/4HANA標準の移行ツール)からデータシートをダウンロードし、クレンジングしたデータから1、2レコードをサンプリングし、インポートしていきます。
最初のうちはエラーが噴出するため、一つずつ原因を潰しながら、インポートできるまでこれを繰り返します。
インポートが完了したら、インポートしたデータが意図した項目にマッピングされているか確認します。
可能であれば、実際にインポートしたデータを使用して伝票を登録し、想定通りの動作をするか確認しましょう。
例えば、品目マスタ、購買情報、仕入先マスタを取り込み、品目を発注処理してみて不足している情報がないか確認します。
1レコードのインポートに成功したら、徐々にデータパターンを増やし、移行リハーサルまでに課題を潰していきます。
⑤移行リハーサル
移行におけるエラーを潰し終えたら、本番移行を想定し、本番時に使用する手順やデータで全件インポートします。
問題なくインポートが完了したら、然るべき確認方法で移行元のシステムと数字や件数が合致しているか確認します。
例えば、品目の件数であれば、トランザクションコード:SE16Hでテーブル:MARAの品目タイプごとの件数を調べます。
在庫情報であれば、SAPの在庫数/簿価と現行システムの在庫数/簿価を突き合わせて、誤差がないか確認します。
移行リハーサルで投入した本番想定のデータをユーザーテスト、総合テストなどに使用する場合が多いです。
本番想定で行う移行リハーサルですが、データ検証/試験投入で潰しきれなかったエラーの対応をしなければならないため、可能であれば最低でも2回は移行リハーサルを実施することをオススメします。
⑥本番移行
本番稼働に向けて、本番環境でデータ移行を実施します。
本番移行は移行元のシステム(現行システム)を停止した状態で作業しなければならないため、通常はGWや年末年始の長期休暇や月末月初に実施することが非常に多いです。
また、本番移行作業は休日返上だけでなく、24時間連続で作業をすることが多いです。
また、リハーサルを行ったとしても本番移行後全く障害が発生しないということは滅多に無いため、本番稼働後も移行データのトラブル対応に奔走することになります。
本番稼働後に運用が落ち着いてきたら、たっぷり代休を取るようにしましょう。