既存データを調査して新システムとマッピングする手順はどのデータについても同じですが、マッピング設計時の注意点はデータごとに異なります。
本記事では、ユーザマスタを移行する時の注意点を紹介します。
ユーザマスタとは
そのシステムにログインするユーザのことです。
一見当たり前に見えるユーザという言葉も、ディーラーとユーザのように自動車業界で言葉を並べると、ユーザは実際に車を使うお客様を示すことになります。言葉の定義は重要ですね。
ユーザマスタが持つ項目
主な項目は以下の通りです。
- ユーザID
- 氏名
- メールアドレス
- 電話番号
- 所属部門
- 役職
- 権限
- 削除フラグ
ユーザマスタの一生(作成から削除まで)
入社時に、ユーザマスタにデータが登録され、退社時に削除されます。
在職中には、部門異動で所属部門が変わったり利用する権限が変わります。昇進を通じて役職とともに権限が変わることもあります。会社の合併や分社化によりメールアドレスが変わることもあります。
項目ごとの注意点
ユーザID・・・移行時に変換することはほとんどないと思いますが、しいていえば先頭0がある場合に誤って消さないことでしょうか。
氏名・・・後述する旧姓のケース
メールアドレス・・・新システムで送付先として使用する場合、機械的な「@」チェックをクレンジングの際に行っておくとよいかもしれません。Lotus NotesのアドレスだとNotes以外で使えないのでいわゆるインターネットのEメールアドレスであることは移行元に確認しましょう。
電話番号・・・単なる属性情報として持つだけならテキスト情報として細かな制御は不要です。ハイフン有無や国番号などの統一も必要があれば。
所属部門・・・従業員に部門異動はつきものなので古い情報になっていないか注意が必要です。
役職・・・属性情報としての表示のほかに、ワークフローで承認階層を設定するのに使うこともあります。
権限・・・新システムでの利用画面や機能、データの参照や更新範囲を指定するものです。移行元システムでの利用権限から変換することもありますが、移行に向けて新規で検討し設定することが多いです。
削除フラグ・・・退職時にユーザは削除されます。とはいえ、在職中に関わったデータに担当者として登録されることもあります。設計にはよりますが、その場合の氏名をマスタから参照する場合もあるので、ユーザ情報を物理削除するのはお勧めしません。そのための削除フラグです。
ユーザマスタに関連するマスタ
- 従業員マスタ・・・ユーザマスタは従業員マスタとパートナーマスタを元に作成することもあります。
- 部門マスタ・・・所属部門の名称や部門の階層を持ちます
- 権限マスタ・・・利用可能な画面や機能、データの参照や更新の範囲
- 役職マスタ・・・属性情報としての表示のほかに承認ワークフローに参照することもあります
そのほかの注意点
- 海外現地法人への出向
- 結婚後も旧姓で仕事したい
ユーザマスタが全社統一の従業員マスタを元にする場合、所属部門として原籍が表示されてしまい、海外現地法人などへの出向先情報が取得できないことがあります。多くは出向先が別会社の場合はそちらでユーザIDやメールアドレスを作成されます。やみくもに移行してしまうのではなく、業務として利用するのはどちらのユーザIDなのかを確認し移行するよう注意が必要です。
結婚後も旧姓で仕事をされる方もいらっしゃいます。新システムが姓や名前と別に表示名を持っている場合は、そちらに仕事で使いたい姓を反映します。もしくはミドルネーム項目を使うのも一つの手です。注意が必要なのは、移行時には旧姓を設定したのに、人事マスタ等から情報をインターフェースする際に上書きされてしまうケースです。
上記以外にも様々な使われ方や例外ケースがありえますので、移行時には運用経験のある方にもヒアリングし考慮事項を洗い出すことをお勧めします。