最近のMDMプロジェクトはグローバルまたはグループ企業を対象としたものが多く、その中でマスタの識別子を統一する話しが出てきます。（ここでは、グローバルまたはグループの両方を指して、これらの識別子をGコードと呼ぶことにします）
マスタデータを統合するためには、1件1件のデータの粒度を調整する必要があり、Gコード統一は必須の作業となります。
今回のデータマネジメント通信では、このGコード統一作業の注意点をご説明します。とはいえ、数多くある注意点すべてを記述できませんから、私の考えるもっとも重要な注意点1つに絞ります。
その注意点とは、
「設計者自身がどういうスタンスでこの作業を進めるか」です。
もう少し具体的に言えば、
「商品コードは1物1コードが原則だから、すべての商品が1コードで表現できるように統一すべきだ」
とか
「社内組織、顧客、取引先などはPartyパターンで統合するのが良いと言われているからそうしよう」
と考え作業を進めることを指します。
結論から先に申し上げると、このような、原理原則らしき考え方やどこかのコンサルタントが言っているプラクティスを真に受けて、「1つに統一することが正しいことだ」と思い作業を進めてはいけません。
商品コードについて、少しだけ深堀して考えてみましょう。
商品コードはグループ全体で複数存在します。
設計用商品コード・・設計部門は、商品1つ1つの仕様を区別できるように商品コードを発番します。
製造用商品コード・・製造部門は、設計部門とほぼ同様に商品を識別しますが製造ラインや金型の違いによって、微妙に
商品の品質が異なったりすると、粒度を細かくした商品コードを発番します。
販売用商品コード・・販売部門は、お客様に売る商品を識別したいので、製造ラインや金型の違いによって、別な
商品コード値になっていると困ります。一般にカタログベースで同じに見える商品には1つの
コード値を与えます。
社内組織についても、少しだけ深堀してみましょう。社内組織コードもグループ全体で複数存在しますが、1企業内でみても次のような違いがあります。
人事用組織コード・・人事部門は、辞令を出すことと社員の在籍場所を管理できる粒度でコードを発番します。
物流用組織コード・・販売・物流部門が見る組織は、モノを置く場所を指定したり、営業成績を評価するために、人事組織
よりも細かい粒度になります。
会計用組織コード・・会計部門は、おさいふの管理すなわち費用予算の管理のために、人事組織よりも細かい単位の
組織コードを必要とします。
このように業務が違えば、対象を見る視点もかわります。そして、視点の数だけコードが必要になります。
Gコードを設計する際は
「業務の見方の数だけ正しさがある」と考え、、
「ほんとうに統一的に見たい視点が何か」を先に明らかにすべきです。
1物1コードなど幻想にすぎないのです。
« 趣味・娯楽での情報活用その2レコメンデーションロジック »
