■ 前回までに人事給与システムへのデータ移行の難しさについてお話ししましたが、それを踏まえ、どう対応すれば少しでもリスク軽減できるのかをお伝えします。何を始めるにあたっても計画や方針が重要です。この移行方針をどのような観点を盛り込んで作成し、合意形成すべきかをここでは考えます。

◆ プロジェクトの稼働リスク（延期）の大きな要素として、データ移行の品質は良く課題にあがります。それくらいデータ移行は難解で遅延しやすい箇所でもあります。

◆ ではそのデータ移行のリスクヘッジを少しでも抑えるためには何が必要かを考えてみます。

◆ データ移行は、ボリュームが非常に読みにくい作業となるため、いち早く方針を明確し、作業タスク・スケジュール・作業者の役割を明確化することが必要です。

◆ データ移行方針の定義

 対象システムの整理

　　　　　

⇒人事の各領域データを、現行のどこから、新のどこへ移行するのかを明確化する。
各領域とは、「人事」「組織」「給与」「社保」などの領域で、それを現行システムのどこから、新システムのどこへ移行させるのかを明確化させる必要があります。
例）人事：COMPANY⇒SAP-HCM（SuccessFactors）、勤怠：COMPANY⇒リシテアなど

 移行対象従業員数ボリュームの整理

　　　　　

⇒ 従業員数は、新システムでの管理対象者に則りますが、対象者数が増えると、イレギュラー対応が増え、それだけ移行作業の労力がかかることになります。

　　　　　

⇒ 正社員のデータ移行は基本ですが、パートや派遣、役員のデータ移行を行うか、退職者についてはどこまで移行させるのかを明確化する必要があります。

 データ群ごとのデータ移行範囲の明確化

　　　　　

⇒ 本作業は、一番大変ではありますが後々のデータ移行ツール、本番業務で大きくかかわってくるので、一つ一つ明確化して整理する必要があります。

　　　　　

⇒ 本作業では、各領域：人事・組織・給与などを更に細分化し、データ群：従業員情報・所属歴・発令歴などにわけていき、そのデータ群ごとの「データ移行対象有無」「移行期間」「退職者の移行有無」などを定義します。このデータ群ごとの方針を明確化することで、テーブルごとの移行範囲の検討が容易になります。

 役割の整理

　　　　　

⇒ ここでは、データ移行の各作業において、ベンダ作業とクライアント作業を一つ一つ明確化して方針上に落とし込んでいくことを言っています。
　　　　　

⇒ プロジェクトにより、データ移行のやり方は様々ではありますが、一例として以下の作業のタスク責任者を明確化した方が良いと考えます。

　　　　　

✓ 新システム項目定義 ：新システムで管理する項目定義（移行のみの項目も含む）

　　　　　

✓ 現新コード・項目マッピング：現行と新システムでの項目マッピングとその項目のコードマッピングの定義

　　　　　

✓ データ抽出 ：現行システムからデータ抽出する作業

　　　　　

✓ 移行データファイル作成 ：現行から新システムへの項目変換・コード変換、また新システムへ取り込めるファイルを作成する二つの作業

　　　　　

✓ 移行データファイル登録：作成した移行データファイルを新システムへ取り込む作業

　　　　　

✓ 投入結果確認 ：　投入後のシステム的な確認作業方法

　　　　　

✓ 最終確認 ：投入後の業務的な確認作業方法

◆ データ移行は、手順・やり方・実施・確認は、データ移行単体のリハーサルで確認はできますが、最終的には、投入されたデータが業務で使用出来るものでなければ何ら意味を持ちません。

◆ 「移行データ」と「業務で使用する機能」が、正しく重なり合って初めて業務が遂行できるため、移行データを使用した、総合テスト・給与突合テストで「データ」「システム」「業務」の確認がされます。このテストをもって移行データの品質担保が行われる形となるため、方針については業務側と移行側双方で確認することが重要となります。

◆ このテストで、移行データ漏れ・マッピング不備・想定と異なる結果が発生し、再度検討を行うなどして、最終的に本番移行を迎える形となるため、総合テスト・給与突合テストの確認がされないと移行データの品質保証は出来ない形となります。