元外資系コンサルのガラクタ箱

揺りかごから墓場まで。ユーザマスタを移行する時の注意点

既存データを調査して新システムとマッピングする手順はどのデータについても同じですが、マッピング設計時の注意点はデータごとに異なります。

本記事では、ユーザマスタを移行する時の注意点を紹介します。

ユーザマスタとは

そのシステムにログインするユーザのことです。

一見当たり前に見えるユーザという言葉も、ディーラーとユーザのように自動車業界で言葉を並べると、ユーザは実際に車を使うお客様を示すことになります。言葉の定義は重要ですね。

ユーザマスタが持つ項目

主な項目は以下の通りです。

ユーザマスタの一生(作成から削除まで)

入社時に、ユーザマスタにデータが登録され、退社時に削除されます。

在職中には、部門異動で所属部門が変わったり利用する権限が変わります。昇進を通じて役職とともに権限が変わることもあります。会社の合併や分社化によりメールアドレスが変わることもあります。

項目ごとの注意点

ユーザID・・・移行時に変換することはほとんどないと思いますが、しいていえば先頭0がある場合に誤って消さないことでしょうか。

氏名・・・後述する旧姓のケース

メールアドレス・・・新システムで送付先として使用する場合、機械的な「@」チェックをクレンジングの際に行っておくとよいかもしれません。Lotus NotesのアドレスだとNotes以外で使えないのでいわゆるインターネットのEメールアドレスであることは移行元に確認しましょう。

電話番号・・・単なる属性情報として持つだけならテキスト情報として細かな制御は不要です。ハイフン有無や国番号などの統一も必要があれば。

所属部門・・・従業員に部門異動はつきものなので古い情報になっていないか注意が必要です。

役職・・・属性情報としての表示のほかに、ワークフローで承認階層を設定するのに使うこともあります。

権限・・・新システムでの利用画面や機能、データの参照や更新範囲を指定するものです。移行元システムでの利用権限から変換することもありますが、移行に向けて新規で検討し設定することが多いです。
削除フラグ・・・退職時にユーザは削除されます。とはいえ、在職中に関わったデータに担当者として登録されることもあります。設計にはよりますが、その場合の氏名をマスタから参照する場合もあるので、ユーザ情報を物理削除するのはお勧めしません。そのための削除フラグです。

ユーザマスタに関連するマスタ

そのほかの注意点

ユーザマスタが全社統一の従業員マスタを元にする場合、所属部門として原籍が表示されてしまい、海外現地法人などへの出向先情報が取得できないことがあります。多くは出向先が別会社の場合はそちらでユーザIDやメールアドレスを作成されます。やみくもに移行してしまうのではなく、業務として利用するのはどちらのユーザIDなのかを確認し移行するよう注意が必要です。

結婚後も旧姓で仕事をされる方もいらっしゃいます。新システムが姓や名前と別に表示名を持っている場合は、そちらに仕事で使いたい姓を反映します。もしくはミドルネーム項目を使うのも一つの手です。注意が必要なのは、移行時には旧姓を設定したのに、人事マスタ等から情報をインターフェースする際に上書きされてしまうケースです。

上記以外にも様々な使われ方や例外ケースがありえますので、移行時には運用経験のある方にもヒアリングし考慮事項を洗い出すことをお勧めします。

 

名寄せは大丈夫?顧客マスタを移行する時の注意点

mhisaeda

電子書籍「システム導入のためのデータ移行ガイドブック」著者。

新卒から外資系コンサルティングファームに所属。15年に渡り販売物流、特にCRM領域のコンサルティングに従事。 100名を超えるプロジェクトのPMOなど全体を推進していく役回りや、ユーザ企業への出向を通じた実務経験を持つ。

このブログでは、自身がかき集めた知識や経験を共有する。クライアントへの提案やソリューション開発に直結しないガラクタのようなもの。将来再利用する自分のために。同じような悩みを抱える誰かのためにブログ「元外資系コンサルのガラクタ箱」を運営。

カテゴリー

モバイルバージョンを終了