取引先マスタの責任者設計｜作成・変更・重複解消・廃止を分担する

取引先名が営業、請求、サポートで別々に作られると、重複を見つけても誰が直すか決まらない。マスタ設計は項目一覧だけでなく、作成、変更、統合、廃止の判断責任まで含む。

CRMへ入れる項目の意味はCRM導入前のデータ定義、移行前の構造確認はデータ構造の棚卸し、重複行の直し方はNotion顧客DBの重複対策、営業での名寄せはチーム顧客管理の方法が扱う。この記事は取引先マスタを日々維持する責任分担に絞る。

最初に取引先IDと正本を決める

表示名だけで同一判定せず、自社の取引先IDを置く。法人名、事業所、請求先、担当者は同じ粒度ではないため、何を一つの取引先と数えるか、各項目の根拠をどこに置くか決める。

作成申請を営業が行い、重複確認を管理が行い、請求情報を経理が確認するように、作業者と最終責任者を分ける。すべてを全員確認にすると止まり、誰でも変更可にすると根拠が消える。

名称変更、請求先変更、統合は影響が異なる。変更前後、根拠、申請者、承認者、適用日、影響先を記録し、過去の帳票や取引履歴まで無断で書き換えない。

デジタル庁はデジタル社会推進標準ガイドライン群を公開し、実践ガイドブックも同じページから提供している（標準ガイドライン群、実践ガイドブック）。対象は行政情報システムだが、情報資産の管理主体とライフサイクルを明確にする考え方は社内マスタの責任表にも応用できる。

データ管理を含む改善事例は業務改善カテゴリで確認できる。

一人に全項目を任せません。営業名、請求先、法人識別情報など項目群ごとに正本と確認担当を決め、マスタ全体の最終責任者を置きます。

業務上必要な場合は申請入口を広くできますが、重複確認、必須項目、承認、採番を分けます。作成ボタンの権限だけで責任設計を終えません。

受注、請求、問い合わせなど参照先を確認し、統合先ID、旧ID、変更履歴を残します。履歴を失う削除はせず、再利用を防ぐ廃止状態にします。